小米开源分布式KV存储系统Pegasus _hbase

作者｜孙伟杰
编辑｜小智
小米近日开源了分布式 KV 存储系统，这个小米自造的轮子背后，有着什么样的设计理念与技术细节？
写在前面
这次我给大家带来的主题是“分布式实现那些事儿—— 背后的故事” 。在这次演讲中，我着重讲解的是我们在的架构和实现之中遇到的一些的坑。
我来自小米，主要做的研发工作。是小米自己造的一个分布式 KV 存储的轮子。对于造轮子这件事情，不知道各位是什么样的想法，就我个人而言，造轮子是要竭力避免的。如果有一个较好的方案能解决问题，则应该优先使用别的方案；除非随着业务的发展，没什么好的方案可供选择了，那我们只能自己造一个出来了。
做的过程就是这个样子的。
的产生
在立项之前，小米的分布式存储主要使用 HBase 。经过 10 多年的发展，HBase 本身还是比较稳定的，并且功能接口上也较为方便。但由于设计和实现上的一些问题，我们在使用上还是会有一些坑。
记一次 HBase 事故
HBase 的架构，我相信大家应该对其也比较熟悉了。如上图所示，HBase 由一个节点来管理整个集群的状态。在节点的统筹管理之下，节点负责客户端的读写请求；的数据，存在一个外部的分布式文件系统 HDFS 之上。的心跳探活，以及的高可用都由来负责。
我们在实际使用时，很多问题都由而起。在设计之初，它是一个要求负载比较低的系，所以在小米这边，大多都由多个业务混合使用。除了 HBase 之外，很多其他业务的节点探活，服务注册等都依赖。但一些业务在使用时，会将超额的压力加到上，从而导致的不稳定。除此之外，一些对的误用，如访问时不共用连接，也是服务不稳定的来源。
各种误用因素的存在，会导致经常遇到崩溃。对 HBase 而言，的崩溃就意味着也随之崩溃掉。而小米的很多业务都依赖 HBase，一旦 HBase 崩掉，小米的很多业务也随之无法提供服务了。
HBase 的不足
通过对 HBase 的一系列问题进行复盘，我们认为有几点值得提一下：
1、对于 HBase 而言，它将“节点探活”这一重要的任务交给来做，是可以商榷的。因为如果运维不够细致的话，会使得成为影响 HBase 稳定性的一个坑。
在 HBase 中，对“ 会话超时”的处理方式是“自杀” 。而上“多个合写一个 WAL 到 HDFS”的实现方式会使得“自杀”这一行为的成本比较高，因为自杀之后重启时会拆分和重放 WAL 。这就意味着假如整个 HBase 集群挂了，想要将 HBase 重新给拉起来，时间会比较长。
2、即使我们能保证的稳定性，“节点探活”这一功能也不能非常稳定的运行。因为 HBase 是用 Java 实现的。GC 的存在，会使得把正常运行的误判为死亡，进而又会引发的自杀；在其之上的，需要其他的从 HDFS 上加载重放 WAL 才能提供服务。而这一过程，同样也是比较耗时的。在此期间内，所服务的 Key 都是不可读写的。
对于这一问题，可以通过将“节点探活”的时间阈值拉长来解决。但这会使得真正的“死亡”不能被及时发现，从而另一个方面引发可用性的问题。
3、GC 的另一个问题是，HBase 在读写延时上存在毛刺。我们希望在广告、推荐这种业务上能够尽量避免出现这种毛刺，即能够有一个比较稳定的延时。
把上面的三点概括一下，我们认为 HBase 在可用性和性能延时方面还是存在一些瑕疵的。对于这些问题，通过修修补补、调整参数的方式能够得以缓解。但想从根本上解决，还是不太容易。
的定位
既然搞不定 HBase，那么我们只好自己重新造一个。由于已有 HBase 这样一个标杆，我们在定位上也非常明确：对 HBase 取长补短。具体来看：