RaftKeeper：构建跨机房高可用 OLAP 集群

演讲人：京东吴建超架构师 目录Contents 跨机房架构 项目简介 性能优化 01项目简介 项目背景 lZookeeper引起的问题 lRaftKeeper项目 项目研发的动机： Zookeeper在OLAP中的角色： 1.实际业务中问题越来越突出2.社区计划研发keeper替代Zookeeper 1.Meatdatastore：Table definition、Partition Info etc.2.Operation Log : Insertion、mutation、merge3.Coordinator：Service Discovery、Task Queue etc. 项目的目标： Zookeeper瓶颈导致的问题： •完全兼容ZK的用户接口•相对ZK更优的性能，支持更高（至少2倍）的请求吞吐量•降低ZK中的阻塞因素：JVM GC STW、状态机Map扩容、mntr命令等 1.Table ReadOnly导致插入失败2.分布式DDL操作超时或者失败3.后台PartsMerge失败等 RaftKeeper项目已开源，详见：Github Raft分布式共识算法 lRaft关键流程 lRaft共识算法简介 1.Leader选举 1.Raft用于解决分布式系统中副本间数据一致性的问题 1.采用majority的规则2.新Leader通过强制Follower复制它的日志来处理日志的不一致3.日志不全的服务器不会赢得选举，保证已经commit的请求不会回退 2.Raft相对Paxos算法而言容易理解，工程实践简单 3.广泛用于数据相关工程中：Kudu、TiDB、Etcd等 2.LogReplication 1.基于Log，且log连续没有空洞2.写操作只能由Leader发起3.Log只能从Leader流向Follower WhyNuRaft l算法方面 l实现方面 1.第三方依赖少，良好的示例，代码优雅、接口抽象的好 NuRaft在Raft算法的基础上做了一些有意义的补充： 1.Pre-vote机制：解决follower重连导致的重新选举的问题2.Leadership过期机制：可以解决网络分区情况下的多个leader问题。3.Leader指派机制：可以使某些节点不能或者较低的概率成为Leader4.自定义commit&leader electionquorumsize，增加了集群在可用性和一致性间调节的灵活性 2.Pipeline机制和Batch处理机制，具有优秀的性能 核心特性 1.完全兼容Zookeeper生态，客户端、监控管理工具等2.高性能，写吞吐Zookeeper性能的2倍，见：Benchmark3.查询平稳，TP99表现更稳定，见：Benchmark4.Session内请求响应的顺序性保证5.多路复用网络模型，支持30w长连接同时在线 02功能和架构 基础功能 l网络协议 l基础命令 CreateRemoveExistsGetSetGetACLSetACLSyncHeartbeatListCheckMultiAuthSetWatches 1.Zookeeper握手协议格式 l异常处理 2.Zookeeper create命令格式 #create /china ""Node already exists: /china #delete /not-exist-nodeNode does not exist: /not-exist-node #set /china"" 100version No is not valid : /china… 高级功能 l四字命令 1.用法：echo mntr |nclocalhost 5102 支持节点的：创建、删除、更新事件1.NodeWatch 2.新增命令Snap：统计snapshot情况，包括snapshot次数和执行时间 支持子节点的：创建、删除事件2.ParentNodeWatch l特殊节点 3.mntr命令优化•mntr命令在ZK中统计approximate_data_size指标的时候会遍历整个状态机•在2kwznode的ClickHouse集群中执行大概需要5-9s，经常导致监控指标采集超时。•RaftKeeper中的统计弃用了遍历数据的方式。 1.Ephemeral节点：随着session过期，自动删除的节点2.Sequential节点：子节点按照序号排列的节点3.SequentialEphemeral节点 架构设计 l整体架构要点 1.状态机是核心模块实现了数据存储和watch等高级功能 2.只有写请求才走LogReplication流程，读请求直接访问状态机 3.数据持久化采用snapshot+binlog的方式 4.LogStore设置了cache，大幅度提升性能 l一致性约束 1.同一个session内，保证响应按照请求的顺序执行2.所有Session范围内，已经提交的事物按照顺序执行 架构设计–session内一致性 PipeRunner:thread,connection,taskqueue 1.写请求：同一个session内的请求只会在同一个Pipe Runner内执行 2.读请求：同一个session的读写请求在Processor内按照xid的顺序执行 架构设计–状态机 Ø状态机职责 ØSession机制 1.功能实现，基础命令、watch、ephemeral节点等2.接收logcommit请求并应用到状态机，接收用户查询请求3.维护session信息，包括session过期机制 1.Session代表客户端和server端的一次会话2.状态机中维护了会话的watches、Ephemeralnodes这样的易失性状态 架构设计–存储结构 03性能优化 性能优化 假设需要从仓库运送100个包裹到一个小区，第一种方式是一个快递员一次运送一个包裹，那么总共需要花费100个小时。 性能优化-Batch 第一个优化方式是批量运送，假设一次运送10个包裹，只需要运送10趟，那么效率提升10倍，只需要10个小时就可以完成任务。 对应到RaftKeeper中，在请求最开始设置了一个专门攒批的组件，尽量将用户的写请求在处理最开始就按照批量的方式处理。 性能优化-pipeline 第二个优化方式是接力运送，比如在运送途中增加一名快递员，在运送过程中形成接力，那么时间可以从10个小时进一步降低到5个小时。 对应到RaftKeeper中我们将请求分解为：攒批、请求转发给leader、leader写本地日志并转发、follower写本地日志、leader提交请求、follower提交请求等一些环节，每个环节由一组线程完成，形成执行流水线，进而提升吞吐量。 延时优化–状态机Map l将阻塞时间控制在1s以下 l使用HashMap •根据实验数据，子哈希表的数据不能超过500w，如果支持1亿的节点，小哈希表的数量设置在16-32个是比较合理的。 •主要思路是使用多个哈希表替换单一的哈希表，消除长时间的阻塞和扩容时一次性空间消耗 延时优化–异步Snapshot（WIP） l异步的snapshot l同步的snapshot •异步snapshot消除了查询阻塞 •可能导致部分日志被apply两次。方案可行的关键点是，写请求都是幂等的或者状态机对不同写请求适配冲突方案： •当日志数量达到一定阈值的时候，会创建snapshot，将数据全量dump到磁盘中，该操作在数据同步过程中处理，会引起读写请求阻塞。 1.Create：ReturnNodeExistError2.Delete :ReturnNodeNotExistError3.Set：幂等的命令 l存在的问题 •下表是存储OLAP数据的服务做snapshot的时间统计•如果存储几千万级别的数据量，会造成100s的阻塞 优化小结 l性能优化 l延时优化 1.Pipeline和Batch执行模型2.添加环形队列，缓存最近的日志3.请求处理采用多线程的线程模型，多个读请求可以并行处理 1.状态机哈希表，采用TwolevelHashMap，减小阻塞时间 2.异步Snapshot，消除snapshot和compactlog阻塞的时间3.C++没有JVMGC的阻塞 上线情况 l2021年11月至今上线60+集群，经历3次大促考验 04跨机房架构 跨机房架构 l实施方案 •OLAP以副本为粒度跨2个机房部署•RaftKeeper按照2:2:1的方式部署在3个机房 l架构优势 •提供机房级别的业务高可用保障•相比双集群导数，提供了更强的数据一致性保障 lRaftKeepervsZookeeper •更优秀的性能和稳定性•可以指定Leader所在的zone RaftKeeper项目已开源，地址见：Github，欢迎试用参与开发 lNuRaft社区 lOLAP社区 1.RK开发过程中NuRaft社区给予了很多帮助2.同时也做了一些社区回馈，部分列举如下： 1.RaftKeeper项目源自OLAP社区，是其下游项目2.贡献一些Feature：4lwcommand、手工snapshot、session超时协商、session重连（ignored）3.发展思路不同，RK更倾向于替换Zookeeper，所以项目独立开发。 1.#293 Inconsistentlogwhenleaderswitches2.#296Fixcommit_ret_elemleak when client timeout3.#377 Make manually create snapshot resultknowable4.#372 avoid simultaneously snapshot5.#241Addconfcondition at the beginning ofsnapshot_and_compact. —THANKS— 感谢您的观看