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

《RaftKeeper：构建跨机房高可用 OLAP 集群.pdf》由会员分享，可在线阅读，更多相关《RaftKeeper：构建跨机房高可用 OLAP 集群.pdf（26页珍藏版）》请在三个皮匠报告上搜索。

1、RaftKeeper：构建跨机房高可用OLAP集群演讲人：京东 吴建超 架构师目录项目简介功能和架构性能优化跨机房架构Contents01 项目简介项目背景lZookeeper引起的问题lRaftKeeper项目Zookeeper在OLAP中的角色：1.Meat data store：Table definition、Partition Info etc.2.Operation Log:Insertion、mutation、merge3.Coordinator：Service Discovery、Task Queue etc.1.Table Read Only导致插入失败2.分布式DDL 操作

2、超时或者失败3.后台Parts Merge失败等Zookeeper瓶颈导致的问题：完全兼容ZK的用户接口 相对ZK更优的性能，支持更高（至少2倍）的请求吞吐量 降低ZK中的阻塞因素：JVM GC STW、状态机Map扩容、mntr命令等1.实际业务中问题越来越突出2.社区计划研发keeper替代Zookeeper项目研发的动机：项目的目标：RaftKeeper项目已开源，详见：GithubRaft分布式共识算法lRaft 共识算法简介1.Raft 用于解决分布式系统中副本间数据一致性的问题2.Raft相对Paxos算法而言容易理解，工程实践简单3.广泛用于数据相关工程中：Kudu、TiDB、E

3、tcd等lRaft 关键流程1.Leader选举1.基于Log，且log连续没有空洞2.写操作只能由Leader发起3.Log只能从Leader流向Follower2.Log Replication1.采用majority的规则2.新Leader通过强制Follower复制它的日志来处理日志的不一致3.日志不全的服务器不会赢得选举，保证已经commit的请求不会回退Why NuRaftl 算法方面1.Pre-vote机制：解决follower重连导致的重新选举的问题2.Leadership过期机制：可以解决网络分区情况下的多个leader问题。3.Leader指派机制：可以使某些节点不能或者较

4、低的概率成为Leader4.自定义commit&leader election quorum size，增加了集群在可用性和一致性间调节的灵活性l 实现方面1.第三方依赖少，良好的示例，代码优雅、接口抽象的好2.Pipeline机制和Batch处理机制，具有优秀的性能NuRaft 在Raft算法的基础上做了一些有意义的补充：核心特性1.完全兼容Zookeeper生态，客户端、监控管理工具等2.高性能，写吞吐Zookeeper性能的2倍，见：Benchmark3.查询平稳，TP99表现更稳定，见：Benchmark4.Session 内请求响应的顺序性保证5.多路复用网络模型，支持30w长连接同

5、时在线02 功能和架构基础功能l 网络协议1.Zookeeper 握手协议格式2.Zookeeper create命令格式CreateRemoveExistsGetSetGetACLSetACLSyncHeartbeatListCheckMultiAuthSetWatchesl 基础命令#create/china Node already exists:/china#delete/not-exist-nodeNode does not exist:/not-exist-node#set/china 100version No is not valid:/chinal 异常处理高级功能支持节点的

6、：创建、删除、更新事件l Watch机制1.用法：echo mntr|nc localhost 51022.新增命令3.mntr 命令优化 mntr命令在ZK中统计approximate_data_size指标的时候会遍历整个状态机 在2 kw znode的ClickHouse集群中执行大概需要5-9s，经常导致监控指标采集超时。RaftKeeper中的统计弃用了遍历数据的方式。l 四字命令Snap：统计snapshot情况，包括snapshot次数和执行时间1.Node Watch支持子节点的：创建、删除事件2.Parent Node Watchl 特殊节点1.Ephemeral节点：随着s