在QCon2017的基础设施专场，笔者以表格存储[1]为基础分享了分布式系统设计的几点考虑，主要是扩展性、可用性和性能。每个点都举了一个具体的例子来阐述。这里对这次分享做一次简单的总结，细节见文后slice。
首先，说到了表格存储产生的背景。
图1 表格存储出现的背景
上面介绍，大规模、弱关系数据，对灵活schema变动的需求，传统数据库无法很好的满足，NOSQL的出现是一个很好的补充。NOSQL不是为了取代SQL，也无法取代SQL，是已有数据库生态的很好补充。我认为未来会出现更多种类的数据库，面向不同的业务，使用不同的硬件，数据库市场将迎来更多的成员。
下面描述了表格存储的功能、生态、架构以及数据模型，有了这些基础才能更好的理解后面的内容，比如面向公共云服务的产品和面向企业内部的产品在架构设计的时候会有不同的权衡。
图2 表格存储一览
下面介绍分布式系统第一个要素，扩展性。扩展性是个很广泛的话题，我们只讨论系统能否尽快的利用更多的机器资源。很多分布式系统都有分区的概念（Partition, Segment, Range …），分区就是将单体切割为多个子单位，这样才有可能利用多个物理机器。但是何时切割、如何切割、切割后怎么办都是值得讨论的问题。下面讨论的是其中一个子问题，就是如何切割。
图3 在连续分裂能力上，表格存储 vs HBase
熟悉HBase的同学知道，HBase在一次分裂之后，需要做Compaction才能继续分裂，而Compaction时间持续可能数个小时，也就意味着数个小时内无法进一步分裂从而分担读写压力。表格存储支持连续分裂，也就是1个分区分裂成2个后，可以立刻继续分裂。那么，为什么表格存储要支持连续分裂呢？主要原因在于公有云多租户服务和企业内自用产品的不同。对于表格存储而言，用户点点鼠标就可以开通，业务访问随时可能大幅上涨，用户不会提前告诉我们，即使告诉了我们也没那么多人随时响应。而访问量上涨有很大的可能导致分区内访问热点，这些热点会导致延时上涨或者访问错误，需要系统能够快速的处理，否则就要赔钱。这时候系统必须具备连续分裂的能力，1个分裂成2个，2个分裂成4个…
。HBase更多的是作为一个软件，在企业内部由专门的DBA独立运维。而在企业内部，业务一般可以预期，很难出现运维不期望的巨量上升，所以对于HBase而言，连续分裂的必要性就降低了。这个不同，看似技术的不同，实际则是用户不同、产品形态不同带来的的不同选择。
再介绍分布式系统第二个要素，可用性。可用性就更是一个关乎全局的话题，全链路上任何一点风吹草动都可能影响可用性。我们这里将可用性的讨论局限在硬件故障，局限在机器down这个很小的层面上。众所周知，分布式系统能够自主应对少部分机器down而不需要任何人工干预（如果不是，那一定是假分布式系统），以尽可能的减少因为机器down而产生的服务中断问题。此时，不同的系统有不同的设计抉择，服务中断时间各不相同，作为用户会希望服务中断时间越短越好。
图4 在down机可用性上，表格存储 vs BigTable/HBase
我们这里以谷歌的BigTable以及开源的HBase为例来介绍。谷歌BigTable和开源HBase都采用在worker层聚合日志以提高性能。这个思路很好理解，就是将多个分区的日志聚合在一起，写入文件系统中，这样就能减少文件系统的IOPS，提高性能。但是，这对可用性是个很大的伤害，因为一旦机器发生down机，日志文件需要被读出来按照分区进行分割，这些分割完的日志文件再被相应的分区replay，然后相应分区才能提供服务。显然，上面这个过程会使得机器down时分区不可用的时间变长（想想看谁来分割日志呢？这是否会成为瓶颈？）。如果考虑到全集群重启，或者交换机down导致较多机器失联，那么其对可用性的影响将十分可观。这里是一个可用性和性能的权衡，表格存储在设计之初，是选择了可用性的，也就是每个分区有独立的日志文件，以降低在机器failover场景下不可服务时间。但是这是否意味着性能的下降？是的，但是我们相信可用性优先级更高，而性能总会被解决，后来我们也找到了非常不错的办法，见下面描述。
本节讨论分布式系统设计的第三个问题，性能。性能总是能让程序员热血沸腾，吭哧吭哧码了那么多代码，如果性能有了显著的提升，真是让人十分开心的事情。前面说，为了可用性，我们放弃了性能，难道就一直忍受吗？作为有骨气的程序员，显然是不能接受的。现在难题是必须在不伤害可用性的前提下，提高性能。其实说到性能，有两个基本的招数，就是聚合和拆分，然而在哪里聚，在哪里拆是一个设计的抉择。
图5 全链路视角权衡聚合的层次，考虑可用性和系统通用性
如上图所示，就是聚合时机选择的问题。BigTable和HBase的核心思想是聚合以减少IOPS，从而提高性能；那么聚合是否一定要做在table server这一层做呢？是否可以下推做到分布式文件系统层？结论是当然可以，而且效果更好，受益方更多。具体架构见附件里面的说明，我们通过将聚合下推到文件系统、RPC层小包聚合、Pipeline传输等大幅改进了性能，在可用性和性能之间取得了很好的平衡。当然，随着硬件的演进，未来可能磁盘控制器就把聚合做好了，上面的应用都不需要关心，这样受益方就更多了。
至此，我们聊到了分布式系统的扩展性、可用性和性能，并以实际的例子进行了分析。下面就介绍一个表格存储的特性，PK串行自增列，在消息推送、分布式ID生成、Feed系统中非常有用。这是一个很好地例子，来展示作为一个平台，如何向用户学习。附件中给出了PK自增列用于消息推送系统的例子，这方面我们写过不少文章，见[3][4]。
图6 向用户学习，表格存储提供串行PK自增列
以上就是分享的核心内容，大多是笔者的一些实践总结，没有上升到理论高度，难免有一定的片面性，欢迎探讨。表格存储钉钉交流群：搜索群号11789671加入，群名是“表格存储公开交流群”。目前表格存储引擎组在北京、杭州均有团队，我们也在努力寻找KV存储/SQL引擎优化人才，欢迎讨论。
[1]. 表格存储：www.aliyun.com/product/ots
[2]. QCon 2017资料: ppt.geekbang.org/qconsh2017
[3]. 高并发IM架构：yq.aliyun.com/articles/66…
[4].
打造千万级Feed流系统：yq.aliyun.com/articles/22…
[5]. 演讲PPT下载：ppt.geekbang.org/slide/show/… （QCon）或yq.aliyun.com/attachment/… （云栖）
本文转载自: 掘金