当前位置:   article > 正文

多副本数据一致性技术分析_oceanbase 多副本同步

oceanbase 多副本同步

这里数据一致性指数据多副本数据一致的。

MySQL

MySQL通常采用半同步进行主备复制,这时能保证底层数据一致性。

当发生异常时,半同步退化为异步复制,主备数据写入存在延时,存在不一致情况,主实例如果故障,备实例会丢失部分数据。

master将每个事务写入binlog(sync_binlog=1),并发送到slave刷新到磁盘(sync_relay=1),同时主库提交事务(commit)。master等待slave反馈收到relay log,只有收到ack后master才将提交成功结果反馈给客户端。

TiDB

TiKV 利用 Raft 来做数据复制,每个数据变更都会落地为一条 Raft 日志,通过 Raft 的日志复制功能,将数据安全可靠地同步到复制组的每一个节点中。不过在实际写入中,根据 Raft 的协议,只需要同步复制到多数节点,即可安全地认为数据写入成功。

Raft日志复制过程:客户端请求服务端,服务端leader把这条命令作为新的日志条目加入到它的日志中,然后并行地向其他服务器发起 AppendEntries RPC请求 ,如果其他服务器大部分成功复制日志条目并反馈给leader,leader会将这个条目应用到自己的状态机中,然后把执行的结果返回客户端。其他服务器随后也会将这个日志条目应用到自己本地的状态机中。

https://docs.pingcap.com/zh/tidb/stable/tidb-storage#raft-协议

OceanBase

OceanBase使用日志流在多副本之间同步状态。

日志流使用自研的 Paxos 协议将 Redo 日志在本服务器持久化,同时通过网络发送给日志流的从副本,从副本在完成各自持久化后应答主副本,主副本在确认有多数派副本都持久化成功后确认对应的 Redo 日志持久化成功。从副本利用 Redo 日志的内容实时回放,保证自己的状态与主副本一致。

https://www.oceanbase.com/docs/enterprise-oceanbase-database-cn-10000000000881167#复制层

Pulsar

Pulsar采用计算与存储分离架构。Pulsar负责计算,Bookeeper负责存储。

BookKeeper中每个Ledger(由一个或多个Fragment组成)可以跨多个BookKeeper节点(Bookies)进行复制,以实现数据容灾和提升读取性能。每个Fragment都在一组不同的Bookies中复制(存在足够的Bookies)。

通过以下配置可以设置Topic数据一致性级别

  • Ensemble Size (E)

  • Write Quorum Size (Qw)

  • Ack Quorum Size (Qa)

  1. Ensemble表示将要写入的实际的Bookies数量,以下用E表示。E表示Pulsar需要使用的Bookies数量。Ensemble Size (E) 决定了Pulsar写入Ledger可用的Bookies池的大小。

  1. Write Quorum (Qw) 是Pulsar将要写入的实际的Bookies数量。可以等于或者小于E。

  1. Ack Quorum (Qa) 是确认写入Bookies的数量,Pulsar Broker将确认发送给客户端。为了一致性,Qa应该是:(Qw + 1) / 2 或者更大。

  1. 增加E以优化延迟和吞吐量。增加Qw牺牲吞吐量实现冗余。增加Qa提升数据的容灾但会增加延迟和单一节点响应慢导致的延迟增加。

在实际使用中配置为:

  • 5 3 2:5个Bookies的写入池,写入3个副本,有2个确认成功,就返回客户端写入成功。

  • 3 3 2:3个Bookies的写入池,写入3个副本,有2个确认成功,就返回客户端写入成功。

  • Qa<Qw,避免单点响应慢,改善响应延迟

某个Topic属于固定某个Broker,客户端连接到非所属Broker时,会重定向到Owner Broker上。
https://mp.weixin.qq.com/s/CIpCLCxqpLoQVUKz6QeDJQ 理解Apache Pulsar工作原理

ScyllaDB

ScyllaDB是C++版本的Apache Cassandra。

ScyllaDB所有节点都是对等的。

ScyllaDB可以通过CL与CF灵活设置复制策略:

  • Consistency Level 一致性级别(CL)确定集群中的多少副本在被视为成功之前必须确认读取或写入操作。

  • Replication Factor 复制因子或RF等于要复制数据的节点数。

RF=3 CL=2 时:

  • 写请求发送到对应的三个副本节点上,当有两个副本写入成功,返回给客户端写入成功

  • 读请求发送到其中的两个副本节点上,两个副本返回数据一致,返回给客户端读取的数据

CL与CF可在语句级别设置,灵活满足应用的不同场景的需求。
ScyllaDB节点对等,客户端发送请求到任一节点,节点根据数据分布,复制数据响应节点上。

总结

数据一致性技术有以下共性:

  1. 一个领导者

  1. 一个协调者

  1. 多个跟随者

  1. 多数派确认

分析如下

  • MySQL主实例作为领导者与协调者,负责接收数据请求,协调主备实例,写入数据,确认写入成功,保证数据一致性。

  • TiDB中TiKV通过选举产生领导者,同时作为协调者,负责接收数据请求,协调自身与追随者,写入数据,确认多数成功,保证数据一致性。即通过Raft协议保证数据一致性

  • OceanBase与TiDB过程相似。不过是通过Paxos协议保证数据一致性。

  • Pulsar中Broker作为领导者与协调者,负责接收数据请求,将数据写入多个bookies,确认多数bookies写入成功,保证数据一致性。Pulsar自行实现领导者选举。

  • ScyllaDB 任一节点作为领导者与协调者,负责接收数据请求,写入数据到多个节点,确认多数写入成功,保证数据一致性。

MySQL、TiDB与OceanBase:

  • 领导者负责接收数据请求,写入数据,commit数据

  • 协调者负责复制数据,多数派确认,通知跟随者commit数据

  • 领导者与协调者是逻辑角色,为了区分功能。

Pulsar 采用代理层与存储层结构,Broker作为代理,负责请求接收、转发与确认,不负责数据存储。

ScyllaDB 节点对等,合并代理层与存储层。

  • 请求数据如果没有落到本节点上,则只转发数据。其他对应节点写入数据。

  • 请求数据如果落到本节点,则写入本节点,同时转发数据写入到其他剩余节点。

本质上是两种模式:

  1. Leader-Follower 通过Paxos或类Paxos一致性协议保证数据一致性。

  1. Client-Server 通过客户端转发复制数据,多数派确认保证数据一致性。

  1. 两种模式实现表现不同,实质上还是多数派,保证数据一致性。

声明:本文内容由网友自发贡献,转载请注明出处:【wpsshop博客】
推荐阅读
相关标签
  

闽ICP备14008679号