Totem协议（SRPRRP）讲解
基本概念
•SRP: The Totem Single-Ring Ordering and MembershipProtocol
–基于以太⽹的组通信协议，节点间组成单环结构
–所有数据都采⽤UDP⼴播(message)、单播(token)
–消息的可靠性和有序性，基于token-passing实现
–每个节点都接收到同样的消息序列，故可容忍消息丢失、节点崩溃
•RRP: The Totem Redundant Ring Protocol
–基于SRP，RRP嵌⼊于SRP的⽹络层（相当于修改了SRP的recv/nd函数）
–通过使⽤冗余⽹络把多个节点连接起来，可容忍⽹络的损坏
术语解释
•Processor：
–节点，组通信成员，它需要实现SRP/RRP协议，并对外提供组通信接⼝，例如corosync，它提供组通信服务（叫CPG）。•Application：
–，使⽤组通信服务的应⽤程序，它调⽤Processor提供的组通信接⼝。例如sheepdog就是调⽤corosync提供的CPG接⼝。•Broadcast：
–One Processor => all Processors
•Transmit/Forwardtoken：
–OneProcessor => next Processor
•Delivery：
棉花球
–OneProcessor => associatedApplication
基本概念
•Causal Order：
–消息的传播是可靠的，即每⼀个结点都能收到该消息
–所有消息都有先后次序，不存在并发的情况
–Processor将消息传送给Application时，严格按照消息的先后次序传送
•Agreed Order：
–满⾜Causal Order
–Processor在传送某个消息给Application时，必须确保该消息之前的所有消息都已经传送完毕，确保消息不会丢失
•Safe Order：
–满⾜Agreed Order
番怎么组词–Processor在传送某个消息给Application时，必须确保该消息之前的所有消息都已经被所有Processor接收
SRP细分为三个⼦协议
•The Totem Ordering Protocol（OP）：
–确保消息从Single-Ring中传播，到最终传递给Application时，满⾜Agreed Order或SafeOrder。
•The Membership Protocol（MP）：
–当有新的Processor加⼊或旧的Processor离开时，⾃动形成新的Single-Ring。
•The Recovery Protocol（RP）：
–从Old Ring过渡到New Ring的过程中，恢复属于（残缺的）Old Ring的消息（使它们满⾜Agreed或SafeOrder）。
SRP的四个状态
⼦协议与状态的关系
•TheTotem Ordering Protocol（OP）：
–⼯作在Operational状态
•TheMembership Protocol（MP）：
–⼯作在Gather、Commit状态
•TheRecovery Protocol（RP）：
–⼯作在Recovery状态
TheTotal Ordering Protocol
•TheTotem Ordering Protocol（OP）：
–⼯作在Operational状态
–确保消息从Single-Ring中传播，到最终传递给Application时，满⾜Agreed Order或SafeOrder。
–由Application在发送消息时，指定采⽤Agreed还是Safe⽅式。
–通过token，以“丢⼿绢”的⽅式，实现消息的有序传递。
消息传播⽰意图
ØA1请求P1依次⼴播三个消息：M1, M2, M3，这些消息暂存在P1的请求队列中
Ø假设P1已拿到token，P1向集群依次⼴播：M1,M2,M3
ØP1⼴播的消息，也会保存在它⾃⼰的接收队列中
消息传播⽰意图
ØP2只收到两个消息M2M1,P3,P4完整的收到三个消息M3M2M1
ØP1把Token传递给P2，Token中记录了P1接收队列中消息的max
q:3
ØP2通过⽐较Token中的q，发现⾃⼰没有接收到M3。
消息传播⽰意图
ØP2把token传给P3，更新token的aru(all-received-up-to)为:2
在Token的重传请求列表(rtr)中记录了未收到的消息序号:3
ØP3收到token后，向集群⼴播M3，清除token的rtr后，把token传给P4
ØP2收到P3⼴播的消息M3,
其它节点乎略消息M3
ØP4收到P3传过来的token，没做任务事情，把token传给P1
ØP1收到P4传过来的token，没做任务事情，把token传给P2
ØP1收到P4传过来的token，没做任务事情，把token传给P2
ØP2发现token中的aru_id是它⾃⼰，并且知道⾃⼰已经收到M3，
所以它更新token中的aru为3，⾄此P2知道集群的所有节点都收到了M3M2M1
ØP2把更新后的token传给P3
满⾜Agreed/Safe Order么？
•AgreedOrder
–在token的上述传递过程中，拿到token的Processor，把已接收到的消息按次序传递给Application，则满⾜Agreed
Order。
•SafeOrder
在token的上述传递过程中，如果连续两次转发的token的aru⼤于等于某个消息的序号，则把该消息传递给Application时满⾜Safe Order。
与OP协议相关的Corosync选项
•token_retransmit
–Processor在转发完token后，在多长时间内没有收到token或消息后，将引发token重传。
–默认值：238ms
–如果设置了下⾯的token值，本值由程序⾃动计算。
•token
–Processor在多长时间内没有收到token（中间包含token重传）后，将触发token丢失事件（将激活MembershipProtocol，进⼊Gather状态）。
–默认值：1000ms
本值等于Token在Ring中循环⼀圈的时间，这个时间取决了三个因素：结点数，结点之间的⽹络速率，每个结点在拿到token后可以发送的max_messages。
与OP协议相关的Corosync选项
•hold
–在Ring不怎么繁忙时，RingReprentative在转发token前，休息多长时间。
–默认值：180ms
–本值通常由程序根据地其他选项⾃动计算。
•token_retransmits_before_loss_const
–Token最⼤重传次数
–默认值：重传4次
–若设置本值，token_retransmit和hold的值，由程序根据地本值和token值计算。
•fail_recv_const
–在多少次token循环中，没有收到任何消息（本该收到消息：token.q>my_aru），超过这个次数将激活Membership
Protocol，进⼊Gather状态。
–默认值：2500次
TheMembership Protocol
•TheMembership Protocol（MP）：
–⼯作在Gather、Commit状态
–当有新的Processor加⼊或旧的Processor离开时，⾃动形成新的Single-Ring。新加⼊⼀个节点⽰意图
预备党员考察情况Ø设P4为新加⼊的节点，旧环为{P1,P2,P3}，旧环的q=100
旧环的三个结点都在各⾃的my_proc_t⾥记录了节点成员
ØP4加⼊集群后，⼴播⼀个join
msg。
ØP1,P2,P3收到join
msg后，进⼊Gather状态，根据msg的内容
做不同的动作
Ø当某个结点发现⾃⼰的my_proc_t中的所有成员都达到connsus后，
若它的id是成员中最⼩的id，则它发出⼀个CommitToken并进⼊commit状态，CommitToken’sring_id.q = max(old
ring_id and
JoinMsg’sring_id) + 4
Ø按照上⾯的过程，经过若⼲次JoinMsg的接收与转发，假设P1,P3,P4的
my_proc_t中的成员都已标记为connsus。
Ø设P2没有收到P3的JoinMsg，P2的connsus列表中connsus[P3]=fal。Ø上⼀张PPT讨论失败的情况，现在讨论正常的情况
Ø假设经过若⼲次JoinMsg的接收与转发，所有Processor的
my_proc_t中的成员都已标记为connsus。
ØP2接收到P1传过来的Commit Token后，更新memb_list和memb_idx，
转发Commit Token，并进⼊Commit状态
ØP3接收到P2传过来的Commit Token后，更新memb_list和memb_idx，
转发Commit Token，并进⼊Commit状态
ØP4接收到P3传过来的Commit Token后，更新memb_list和memb_idx，
转发Commit Token，并进⼊Commit状态
ØP1接收到P4传过来的Commit Token后，因为P1已处于Commit状态，
故P1知道此时所有成员，都已经进⼊了Commit状态。
ØP1第⼆次转发CommitToken，进⼊Recovery状态，
并持久化新ring_id (my_ring_id=CommitToken’sring_id)。
ØP2第⼆次转发CommitToken，进⼊Recovery状态，
并持久化新ring_id (my_ring_id=CommitToken’sring_id)。
ØP3第⼆次转发CommitToken，进⼊Recovery状态，
并持久化新ring_id (my_ring_id=CommitToken’sring_id)。
ØP4第⼆次转发CommitToken，进⼊Recovery状态，
并持久化新ring_id (my_ring_id=CommitToken’sring_id)。
Ø由于P4是新加⼊的结点，它的my_trans_memb只有它⾃⼰
Ø当P1第三次收到Commit Token时，所有结点都达到Reovery状态
与MP协议相关的Corosync选项
•join
•
–Processor在发送JoinMsg后，在多长时间内没有收到其他成员的JoinMsg，将引发JoinMsg重传。
–默认值：50ms
•nd_join
–当Processor数量⽐较⼤时（>30），某个节点的加⼊/离开，可能造成各节点瞬间同时发出JoinMsg，造成⽹络拥塞。通过设置此值，程序发送JoinMsg前，将随机等待[0,nd_join]区间内的某个时长。
–默认值：0ms
•connsus
淘宝双十一活动规则–Processor从进⼊Gather状态起，在多长时间内必须使（my_proc_t-my_fail_t）集合的成员达到connsus（被标记为true）。否则清除已被标记为true的成员，重发JoinMsg。
–若设置此值，必须>=1.2*token。
–若未设置此值，程序将按1.2*token值处理。
–注：为了简化PPT的讲解，前⾯的PPT没有介绍my_fail_t（它⽤来保存OldRing中失效的节点）
TheRecovery Protocol
•TheRecovery Protocol（RP）：
–⼯作在Recovery状态
–从Old Ring过渡到New Ring的过程中，恢复属于（残缺的）Old Ring的消息（使它们满⾜Agreed或SafeOrder）。
–在Rcovery状态中，Application发到新Ring的消息，不会被⼴播（需要等到Operational状态）。
步实现Recovery
•Step1：
–与同属于相同的Old Ring的其它Processors交换消息（这个过程，与OP协议类似，不再详述）。
–同⼀个New Ring中，可能有多个Old Ring并存。
初音未来壁纸•Step2：
–把在本Processor的Old Configuration下，满⾜Agreed或Safe
Order的消息直接delivery给Application（message.q<=high_ring_delivered）
•Step3：
–向Application传递第⼀个ConfingChangeMsg，即Transitional
Configuration。
–内含在New Ring中与本Processor同属于⼀个OldRing的成员列表。
•Step4：
–把在本Processor的Transitional Configuration下，满⾜Agreed或Safe
Order的消息delivery给Application（注意与Step2的区别）。
•Step3：
–向Application传递第⼀个ConfingChangeMsg，即Transitional
Configuration。
–内含在New Ring中与本Processor同属于⼀个OldRing的成员列表。
•Step4：
–把在本Processor的Transitional Configuration下，满⾜Agreed或Safe
Order的消息delivery给Application（注意与Step2的区别）。
•SRP的Flow Control Mechanism
–window_size:
在⼀次token的循环中，整个集群可以⼴播的最⼤的消息数。
–max_messages:
节点在拿到token后，可以⼴播的最⼤消息数。
–以上两个参数，也可以在Corosync中配置。
RPR协议简介
•⼯作原理
–基于SRP，RRP嵌⼊于SRP的⽹络层（相当于修改了SRP的recv/nd函数）
–通过使⽤冗余⽹络把多个节点连接起来，可容忍⽹络的损坏
RPR的三种Replication Styles
•Active replication
–所有消息都同时发送到N个冗余⽹络。
–每个消息都被接收N次。
–Processor的带宽消耗随着N的增⼤⽽减少。
印度低种姓
•Passive replication
–所有消息只发送到N个冗余⽹络的其中⼀个。
离岗创业–每个消息都只被接收到⼀次。
–Processor的带宽消耗与Sing-Ring相同。
大着肚子奔小康•Active-passive replication
混合模式，所有消息都同时发送到K（1<K<N，例如为3）个冗余⽹络。
•rrp_mode
–ReplicationStyle。
–可能的值：none, active, passive。
–⽬前corosync还不⽀持active-passive混合模式。
•rrp_token_expired_timeout
–在多长时间内，没有从任意⼀个冗余⽹络中收到token，则把ProblemCounter增1。–默认值：47ms。
•rrp_problem_count_timeout
–在多长时间内，如果某个⽹络没被标记为faulty，则把ProblemCounter减1。
–默认值：2000ms。
•rrp_problem_count_threshold
–当ProblemCounter达到某个值后，则把某个⽹络标记为faulty。
–本值*token_expired_timeout<=(token-50ms)
–默认值：10
