基于Raft构建弹性伸缩的存储系统的一些实践素材.docx

基于Raft构建弹性伸缩的存储系统的一些实践 原创2016-07-18黄东旭聊聊架构聊聊架构聊聊架构微信号 archtime功能介绍 在这里煮酒聊架构。最近几年来，越来越多的文章介绍了 Raft 或者 Paxos 这样的分布式一致性算法，但主要集中在算法细节和日志同步方面的应用，但是呢，这些算法的潜力并不仅限于此，基于这样的分布式一致性算法构建一个完整的可弹性伸缩的高可用的大规模存储系统，是一个很新的课题，我结合我们这一年多以来在 TiKV 这样一个大规模分布式数据库的实践上谈谈其中的一些设计和挑战。本次分享的主要内容是如何使用 Raft 来构建一个可以「弹性伸缩」存储。其实最近这两年也有很多的文章开始关注类似Paxos或者 Raft 这类的分布式一致性算法，但是主要内容还是在介绍算法本身和日志复制，但是对于如何基于这样的分布式一致性算法构建一个大规模的存储系统介绍得并不多，我们目前在以Raft为基础去构建一个大规模的分布式数据库TiKV，在这方面积累了一些第一手的经验，今天和大家聊聊类似系统的设计，本次分享的内容不会涉及很多 Raft 算法的细节，大家有个Paxos或者 Raft 的概念，知道它们是干什么的就好。先聊聊Scale其实一个分布式存储的核心无非两点，一个是Sharding策略，一个是元信息存储，如何在Sharding的过程中保持业务的透明及一致性是一个拥有「弹性伸缩」能力的存储系统的关键。如果一个存储系统，只有静态的数据sharding策略是很难进行业务透明的弹性扩展的，比如各种MySQL 的静态路由中间件（如Cobar）或者Twemproxy这样的Redis中间件等，这些系统都很难无缝地进行 Scale。Sharding的几种策略在集群中的每一个物理节点都存储若干个Sharding单元，数据移动和均衡的单位都是Sharding单元。策略主要分两种，一种是 Range 另外一种是 Hash。针对不同类型的系统可以选择不同的策略，比如 HDFS 的Datanode的数据分布就是一个很典型的例子：1、Range策略Range的想法比较简单粗暴，首先假设整个数据库系统的 Key 都是可排序的，这点其实还是蛮普遍的，比如HBase中 Key 是按照字节序排序，MySQL 可以按照自增 ID 排序，其实对于一些存储引擎来说，排序其实是天然的，比如 LSM-Tree 或者BTree都是天然有序的。Range 的策略就是一段连续的 Key 作为一个Sharding单元：例如上图中，整个 Key 的空间被划分成 (minKey, maxKey), 每一个Sharding单元（Chunk）是一段连续的 key。按照 Range 的Sharding策略的好处是临近的数据大概率在一起（例如共同前缀），可以很好的支持 range scan 这样的操作，比如HBase的 Region 就是典型的 Range 策略。但是这种策略对于压力比较大的顺序写是不太友好的，比如日志类型的写入 load，写入热点永远在于最后一个 Region，因为一般来说日志的 key 基本都和时间戳有关，而时间显然是单调递增的。但是对于关系型数据库来说，经常性的需要表扫描（或者索引扫描），基本上都会选用 Range 的Sharding策略。2、Hash策略与 Range 相对的，Sharding的策略是将 Key 经过一个 Hash 函数，用得到的值来决定Sharding ID，这样的好处是，每一个 key 的分布几乎是随机的，所以分布是均匀的分布，所以对于写压力比较大，同时读基本上是随机读的系统来说更加友好，因为写的压力可以均匀的分散到集群中，但是显然的，对于 range scan 这样的操作几乎没法做。比较典型的 Hash Sharding策略的系统如：Cassandra 的一致性 Hash，Redis Cluster 和Codis的 Pre-sharding策略，Twemproxy有采用一致性 Hash 的配置。当然这两种策略并不是孤立的，可以灵活组合，比如可以建立多级的Sharding策略，最上层用 Hash ，每一个 Hash Sharding中，数据有序的存储。在做动态扩展的时候，对于 Range 模型的系统会稍微好做一些，简单来说是采用分裂，比如原本我有一个 [1, 100) 的 Range Region，现在我要分裂，逻辑上我只需要简单的将这个 region 选取某个分裂点，如分裂成 [1,50), [50, 100) 即可，然后将这两个 Region 移动到不同的机器上，负载就可以均摊开。但是对于 Hash 的方案来说，做一次 re-hash 的代价是挺高的，原因也是显而易见，比如现在的系统有三个节点，现在我添加一个新的物理节点，此时我的 hash