totem协议详解


难度 中等

基本概念

SRP: The Totem Single-Ring Ordering and Membership Protocol

  • 基于以太网的组通信协议,节点间组成单环结构
  • 所有数据都采用UDP广播(message)、单播(token)
  • 消息的可靠性和有序性,基于token-passing实现
  • 每个节点都接收到同样的消息序列,故可容忍消息丢失、节点崩溃

SRP有四种状态:

  • Operational

    这个阶段是集群组建完成正常工作的状态,这个状态一个节点发送的消息其它节点都会全部有序提交给上层

  • Gather

    这个阶段用于每个节点向外界广播自己的存在并收集其它节点的存在

  • commit

     这个阶段会产生一个代表节点,该节点向其它所有节点收集信息,并将收集的信息传递给其它所有节点,用于后续阶段

  • recovery

    这个阶段用于新旧集群交替时,旧集群成员用新集群传递旧集群的消息,使旧集群成员达到所有节点消息全部有序提交到上层

SRP细分为三个子协议:

  • The Totem Ordering Protocol(OP)

    • 确保消息从Single-Ring中传播,到最终传递给Application时,满足Agreed Order或SafeOrder。

    • 工作在Operational状态

    • 确保消息从Single-Ring中传播,到最终传递给Application时,满足Agreed Order或SafeOrder。

    • 由Application在发送消息时,指定采用Agreed还是Safe方式。

    • 通过token,以“丢手绢”的方式,实现消息的有序传递。

  • The Membership Protocol(MP)

    • 当有新的Processor加入或旧的Processor离开时,自动形成新的Single-Ring。
    • 工作在Gather、Commit状态
  • The Recovery Protocol(RP)

    • 从Old Ring过渡到New Ring的过程中,恢复属于(残缺的)Old Ring的消息(使它们满足Agreed或SafeOrder)。
    • 工作在Gather、Commit状态

    recovery实现步骤如下:

    1. 与同属于相同的Old Ring的其它Processors交换消息(这个过程,与OP协议类似,不再详述),同一个New Ring中,可能有多个Old Ring并存;
    2. 把在本Processor的Old Configuration下,满足Agreed或Safe Order的消息直接delivery给Application(message.seq<=high_ring_delivered)
    3. 向Application传递第一个ConfingChangeMsg,即Transitional Configuration。内含在New Ring中与本Processor同属于一个OldRing的成员列表。
    4. 把在本Processor的Transitional Configuration下,满足Agreed或Safe Order的消息delivery给Application(注意与Step2的区别)。

RRP: The Totem Redundant Ring Protocol

  • 基于SRP,RRP嵌入于SRP的网络层(相当于修改了SRP的recv/send函数)
  • 通过使用冗余网络把多个节点连接起来,可容忍网络的损坏

术语概念

  • 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接收

消息传播

graph LR id1((a1))-->|m1m2m3|p1--->p2-->p3-->p4-->p1 p1-->id2>m1m2m3]

如上图:

  1. a1请求p1依次广播m1m2m3,这些消息暂存在p1的消息队列中;
  2. 假设p1已拿到token,p1依次向集群依次广播:m1,m2,m3;
  3. p1广播的消息也会保存在它自己的接收队列中;
graph id1((a1))-->|m1m2m3|p1(p1 recv m1m2m3)--->|seq:3 aru:3 aru_id:p1 rtr:|p2(p2 recv m1m2)-->p3(p3 recv m1m2m3)-->p4(p4 recv m1m2m3)-->p1

如上图:

  1. p2只收到m2m3,p3和p4收到m1m2m3;
  2. p1把token传递给p2,token中记录了max seq:3;
  3. p2通过比较token中的seq发现自己没有收到m3;
graph id1((a1))-->|m1m2m3|p1(p1 recv m1m2m3)--->p2(p2 recv m1m2)-->|seq:3 aru:2 aru_id:p2 rtr:3|p3(p3 recv m1m2m3)-->p4(p4 recv m1m2m3)-->p1 p3-->id3>m3]
  1. p2把token传递给p3,更新token的aru(all received up to)为2,在token的重传请求列表rtr中记录未收到的seq:3;
  2. p3收到token后,向集群广播M3,清楚rtr后,将token传给p4;
graph id1((a1))-->|m1m2m3|p1(p1 recv m1m2m3)--->p2(p2 recv m1m2)-->p3(p3 recv m1m2m3)-->|seq:3 aru:2 aru_id:p2 rtr:|p4(p4 recv m1m2m3)-->p1
  1. p2收到p3的广播信息m3,其他节点忽略广播消息;
  2. p4收到p3传过来的token,没做任何事情,把token传给p1;
graph id1((a1))-->|m1m2m3|p1(p1 recv m1m2m3)--->|seq:3 aru:2 aru_id:p2 rtr:|p2(p2 recv m1m2)-->p3(p3 recv m1m2m3)-->p4(p4 recv m1m2m3)-->p1
  1. p1收到p4传过来的token,没做任何事情,将token传给p2;
  2. p2发现token中aru_id是自己,并且知道自己已经收到m3,p2更新token中的aru为3,至此p2知道所有的集群都收到了m3m2m1;
  3. p2把更新后的token传给p3;

reference

  1. https://www.cnblogs.com/yuzhaoxin/p/4911679.html
  2. https://its201.com/article/zancijun1666/83512038

文章作者: growdu
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 growdu !
  目录
分类导航
随笔2 AI27 算法1 计算机基础13 博客搭建7 ChatGPT2 集群63 计算机通信1 数据库34 数据库深入80 DPDK26 Docker11 Elasticsearch4 编辑工具4 FAQ1 Go Web1 hometown2 编程语言16 网络9 OPC1 Linux38 openGauss4 页面12 PostgreSQL54 程序员自我修养1 协议11 成长之路1 stock1 存储5 工具20 VPP18 视频作品1 Vue13 Web1 代码示例11 数据库15 BenchmarkSQL1 PostgreSQL 源码修炼之路14
最热文章
1
13 逻辑复制深入
数据库深入🔥 1570
2
0 Postgresql存储、索引及系统优化、主备切换
PostgreSQL🔥 1495
3
一文读懂openguass dcf网络模块
集群🔥 1420
4
逻辑复制源码分析
数据库深入🔥 1327
5
PostgreSQL 分区表:从一行 `PARTITION BY` 到路由热路径的全链路拆解
数据库🔥 1094
6
applyparallelworker.c 之 LA 端源码深度解析:Leader Apply Worker 的指挥中枢
数据库深入🔥 1082
7
PostgreSQL Background Worker 全解:从 `RegisterBackgroundWorker` 到逻辑复制 4 类 worker 的全生命周期
数据库🔥 1078
8
PostgreSQL的后台进程walsender分析 - 关系型数据库 - 亿速云
PostgreSQL🔥 1033
9
PostgreSQL 逻辑复制的监控:六张视图 + 一组可执行 SQL,把 publisher/subscriber 的速率与健康度彻底看透
数据库🔥 1032
10
PostgreSQL 逻辑复制支持 DDL 之后:DDL 与 DML 的时序难题(重点:分区表)
数据库🔥 999
11
reorderbuffer.c 源码深度解析:PostgreSQL 逻辑复制的"事务重组引擎
数据库深入🔥 953
12
PostgreSQL 内核开发:读取一张表的 9 步标准流程与缓存全景
数据库🔥 938
13
从 `postgres` 二进制到生产级守护 —— PostgreSQL 最外层模块与启动全流程拆解
数据库🔥 936
14
支持逻辑复制同步 DDL 适配 SQL Server 方案
数据库深入🔥 934
15
PostgreSQL 逻辑复制的 ReorderBuffer 与事务机制:从一行 WAL 到一致性变更流的全链路绑定
数据库🔥 913
16
DDL同步架构(美化版)
数据库深入🔥 908
17
PostgreSQL Latch 机制详解:从一行 SetLatch 到 epoll 的内核之旅
数据库🔥 871
18
pgbench 源码全解:一个 C 文件如何撑起 PostgreSQL 官方压测工具
数据库🔥 860
19
PostgreSQL libpq 机制与缓冲区详解
数据库🔥 850
20
PostgreSQL 逻辑复制 spill 文件深度剖析:从 `xid-*.spill` 到 TPC-C 的增长方程
数据库🔥 845