分布式副本的探讨; Raft如何保证强一致性. 强一致性(分布式事务). 强一致性:这种一致性级别是最符合用户直觉的,它要求系统写入什么,读出来的也会是什么,用户 ...

Arvind发布于2018/06/13 00:00

注脚

1.基于Raft的分布式消息队列 RaftMq ( 二 )

2.意义 goal: 背景、问题 具体、清晰、使人信服 我们是 Raft+ 消息队列的一个结合 消息队列:子系统与子系统之间,解耦、缓冲 Raft: 强 一致性算法, 副本与副本之间的一致,强、容灾 结果:高可靠、高可用、强一致性 哪些场景需要 高可靠、高可用、强一致性? 金融、交易 接下来问题:现阶段分布式系统对于上述场景,具体实现? 我们这种组合有他们好吗?好在哪里? RabbitMQ 、分布式事务框架

3.意义(续) 发现 RabbitMQ 与我们类似 相同:强一致性、可靠 不同:一致性算法 ->QGuaranteed Multicast 希望 如果找到 RabbitMQ 的适用场景,我们是可以复用的。 比较 RaftMq 和 RabbitMQ 的一致性算法差异 -> 性能比较(比它厉害的地方)

4.相关知识介绍 在探讨场景前,先对一些知识进行解释 强一致性 我们这里探讨的数据存储一致性,不是指分布式事务保持强一致性 2pc 和 Raft 分布式副本的探讨 Raft 如何保证强一致性

5.强一致性 ( 分布式事务 ) 强一致性:这种一致性级别是最符合用户直觉的,它要求系统写入什么,读出来的也会是什么,用户体验好,但实现起来往往对系统的性能影响大。 例子:银行转账 A -> B( 两个不同的节点 ) 转账 1000 元 分布式事务: 强一致性 保持 ACID , lock {A-1000 , B+1000} unlock result : commit/rollback 弱一致性 ( 最终一致性 ) : 牺牲一定的一致性,来提高性能 A 先扣款, N 个工作日后 , B 到账;转账失败,则金额回归

6.强一致性 ( 副本 ) 多副本 : 提升一个分布式系统可靠性、可用性、性能以及可扩展性的必要手段 可靠性:防止一个副本破坏后,导致数据丢失,起到备份安全 性能:当服务器需要进行数量和地域的扩展,需要减少访问的负荷 引发问题:一致性问题 -> 分布式里一致性模型 强一致性:关键思想单个原子操作或事务的形式在所有副本上执行更新,更新本地副本时,需要将其他副本一并更新,才算执行成功。缺点:副本可能扩散在广域网中,快速更新是不可能,性能差。 顺序一致性

7.强一致性 ( 副本续 ) 复制 同步 / 异步 同步:主节点保证所有的备份节点写入成功,才可以算写成功 异步:主节点收到 client 的写请求后。。。在没有保证所有节点写入,就可以返回 client 写成功 中间。。。 省略了用的什么策略,很多复制协议不一样 直观来看的话,同步当然差啦 如果一个备份节点宕掉的话,就需要等待(当然现在有很多解决办法) 整体同步复制,性能差,时延高 优点:实现简单!可靠! 异步: 各个副本一致性的问题

8.对于一致性总结 从不同的角度看 客户端:一致性主要指的是多并发访问时更新过的数据如何获取的问题 服务端:更新如何复制分布到整个系统 不同的一致性 客户端:多进程并发访问时,更新过的数据在不同进程如何获取的不同策略,决定了不同的一致性 强一致性:关系型数据库,要求更新过的数据能被后续的访问都能看到 弱一致性:如果能容忍后续的部分或者全部访问不到 最终一致性:如果经过一段时间后要求能访问到更新后的数据

9.对于一致性总结 ( 续 ) 不同的一致性 服务端:如何尽快将更新后的数据分布到整个系统,降低达到最终一致性的时间窗口,是提高系统的可用度和用户体验非常重要的方面。 Quorum NWR:控制一致性的一种策略 N — 数据复制的份数 W — 更新数据是需要保证写完成的节点数 R — 读取数据的时候需要读取的节点数 一致性情况探讨 如果W+R>N,写的节点和读的节点重叠,则是强一致性。例如对于典型的一主一备同步复制的关系型数据库,N=2,W=2,R=1,则不管读的是主库还是备库的数据,都是一致的。

10.对于一致性总结 ( 续 ) 如果W+R<=N,则是弱一致性。例如对于一主一备异步复制的关系型数据库,N=2,W=1,R=1,则如果读的是备库,就可能无法读取主库已经更新过的数据,所以是弱一致性。 工业界通常把N设置为3。 N= 3 ,W= 2 ,R= 2 写入 2 个 node 就返回写成功, 需要读 2 个 node (刚好是 2 个写入的 node ok ; 1 个更新过的, 1 个旧的,选择新版本的) R>N-W,客户端如果读到不同版本的数据,这时只用选择出最新的数据即可 W越大,写性能越差。R越大,读性能越差。N越大,数据可靠性就越强。为了保障一致性,平衡读写性能,通常的配置是:W=Q, R=Q ,Q=N/2+1(N=3,R=2,W=2的配置就满足这个公式)。

11.Raft 的一致性 add jmp mov shl Log Consensus Module State Machine add jmp mov shl Log Consensus Module State Machine add jmp mov shl Log Consensus Module State Machine Servers Clients shl

12.Raft 的一致性 读写都通过 leader , follower 是来保证可靠性 从客户端的角度看,客户端必定读到最新的数据,强一致性 从服务端数据存储的角度来看,异步复制,最终所有的节点上的数据保持一致

13.场景 高可用、高可靠、强一致性消息应用场景 高可靠场景 ( 消息不允许丢失 ) case1 :用户下单成功后 ( 订单系统 ) ,需要给用户增加积分 ( 积分系统 ) case2 :通知服务,比如说注册(邮箱、短信);下单成功后通知用户成功 case3 :记账系统,如果失败,需要将失败的消息放入消息队列中,重试! 保证高可靠的三点 消息持久化 消费者消费成功后,返回 ACK 确认, queue 删除消息 如果宕机, follower 重新选举 leader ,新的 leader 跟原来的数据一致

14.场景 强一致性: client 能读取到最新的数据, 以 {N=2 ,W = 1, R = 1} 为例 , A 、 B 主备 case: 金融方面 顺序不一致 A : set x = 100 ; add x+= 10 ; mul x *= 110% B : set x = 100 ; mul x *= 110%; add x+= 10 case: 支付系统 长度不一致 A : set x = 100 ; add x+= 10 ; B : set x = 100 ; 上面两种会导致实时的交易出错问题 同步复制 读 leader/follower 都可以(强一致性) 异步复制 读只通过 leader (强一致性) 异步复制 W+R >N (强一致性)

15.几种消息队列的比较(一)

16.几种消息队列的比较(二) RabbitMQ:一个请求需要在所有节点上处理2次才能保证一致性,性能不高。 Kafka:kafka主要应用在日志、大数据等方向,少量丢失数据业务可以忍受,但不适合要求数据高可靠性的系统。 RocketMQ:未采用一致性算法,如果配置成异步模式可能丢失数据,同步模式下节点故障或网络分区都会影响可用性。 SQS:只提供最终一致性,不保证强一致性。

17.问题 现在互联网金融保证高可靠、高可用、强一致性(客) RabbitMQ 预期: RaftMq vs. RabbitMq 相同点:高可靠、高可用、强一致性 不同点:高可用的程度、吞吐量

18.RabbitMq 镜像队列的可靠多播(Guaranteed Multicast) Guaranteed Multicast:发送者将消息发给集群中的每个节点,这要求集群节点是全联通的。当发送节点挂掉时,消息可能没有发到集群中的每个节点,这就引入了集群中哪些节点要为已挂掉节点负责、继续发送消息的问题。 环状结构:GM组将集群中的节点组成一个环 如果某一个节点宕掉了,左右相邻的节点会知道 上游节点负责将挂掉节点未转发的消息继续发给最近的下游节点

19.RabbitMq: GM消息传递流程

20.复制对比 复制对比 GM :所有节点同步之后才能向客户端返回成功,需要在所有的节点上进行两次处理才可以保证同步 Raft :确认同步大多数 follower ,就向客户端返回成功 RabbitMq 缺点: 时延高,在有大量消息堆积的情况下性能会下降

21.Raft 强一致性:虽然集群节点最终一致性(从数据存储的角度 ) ,但读写只通过 leader ,强一致性(从客户端角度看) 高可靠性:Committed的日志不会被修改,状态机只应用Committed的日志; leader 故障了,选举超时时间选取新的 leader 高可用性:确认 follower 大部分复制成功后,就可以返回 client 写成功 ACK ;

22.总结 此次 ppt 旨在完善背景和问题,应该比上次 详细多了 中间把一致性论述的较多,感觉还是有必要 范围:我们讨论的是 副本的一致性 ,而非那个事务的 consistency 角度:从 客户端的角度 来看,读到最新的数据,强一致性 找到了差不多的产品, RabbitMq 场景:高可靠、高可用、它也是保证的强一致性 之后就是比较两者,展现我们的优势 RabbitMq 的镜像队列 +GM 算法(核心,保证高可靠、一致性) 暂时只看懂了一点,目前我了解到的只有那个环状复制

23.未来 如果这次背景、问题描述的有 60 分的话 以后在实践过程中继续完善 下一步:分布式消息队列的知识补充(如何实现) 担心: 还是编程问题 还有可能写出来 ,没人家 RabbitMq 好呢 (哈哈哈)

24.附:RabbitMQ的Mirrored queue +GM https://my.oschina.net/hackandhike/blog/800334

user picture
  • Arvind
  • Apparently, this user prefers to keep an air of mystery about them.

相关Slides

  • 大规模实践基于Docker的MySQL私有云平台。集成高可用、快速部署、自动化备份、性能监控、故障分析、过载保护、扩容缩容等多项自动化运维功能。数据库高可用是不容忽视的,在Docker容器分配时如何保障主从不在同一宿主机上呢?我们通过自研Docker容器调度平台,自定义Docker容器的分配算法。实现了MySQL的高密度、隔离化、高可用化部署。同时结合我们自研的数据库中间件,支持了分片集群及无感知的高可用切换功能。截止目前平台支撑了目前总量90%以上的MySQL服务(实际数量超过2000个),资源利用率提升30倍,数据库交付能力提升70倍。并且经受住了十一黄金周、春节票务业务高峰期的考验。未来将致力于数据库自动化向智能化的推进。

  • 在云时代的今天,企业数据库面临着复杂的选择,数据库异构迁移往往达不到预期效果,樊文凯想大家分享了ADAM数据库和应⽤用迁移(Advanced Database & ApplicationMigration, 以下简称ADAM),ADAM是阿里云结合阿里巴巴多年年内部业务系统数据库和应⽤用异构迁移的经验(去IOE),⾃自主研发的、迁移ORACLE数据库和应⽤用⾄至阿⾥里里云相关云产品的专业产品,分享了ADAMA的结构、高性能、数据库割接、智能分析、所用的生态工具等,典型的数据库中出现的痛点。

  • 主要介绍阿里云MongoDB服务使用上的一些最佳实践,以及对MongoDB的部署、参数调优

  • Lindorm 是新一代面向在线海量数据处理的分布式数据库,阿里的技术专家通过分享这些多种场景下的数据存储技术实践,帮助企业更好地理解各种数据存储技术的特点,针对自己的业务发展对数据存储技术进行选择和组合。