2017双11技术揭秘—阿里数据库计算存储分离与离在线混布.docxVIP

背景?随着阿里集团电商、物流、大文娱等业务的蓬勃发展，数据库实例以及数据存储规模不断增长，在传统基于单机的运维以及管理模式下，遇到非常多的困难与挑战，主要归结为：机型采购与预算问题?在单机模式下计算资源（CPU和内存）与存储资源（主要为磁盘或者SSD）存在着不可调和的冲突；计算与存储资源绑定紧密，无法进行单独预算。数据库存储时，要么计算资源达到瓶颈，要么是存储单机存储容量不足。这种绑定模式下，注定了有一种资源必须是浪费的。?调度效率问题?在计算与存储绑定的情况下，计算资源无法做无状态调度，导致无法实现大规模低成本调度，也就无法与在大促与离线资源进行混布。?大促成本问题?在计算资源无法做到调度后，离线混布就不再可能；为了大促需要采购更多的机器，大促成本上涨严重。?因此，为了解决诸多如成本，调度效率等问题，2017年首次对数据库实现计算存储分离；计算存储分离后，再将计算节点与离线资源混布，达到节省大促成本的目的。2017年数据库计算存储分离，使得数据库进行大规模无状态化容器调度成为可能！使得数据库与离线业务混布成为可能!使得低成本支持大促弹性成为可能！在高吞吐下，总存储集群整体RT表现平稳，与离线资源联合首次发力，完成2017年“11.11”大促的交易支撑。计算存储分离?在所有业务中，数据库的计算存储分离最难，这是大家公认的。因为数据库对于存储的稳定性以及单路端到端的时延有着极致的要求：存储稳定性?在分布式存储的稳定性方面，我们做了非常多的有意探索，并且逐一落地。这些新技术的落地，使得数据库计算存储分离成为可能：单机failover?单机failover我们做到业界的极致，5s内完成fo，对整体集群的影响在4%以内（以集群规模24台为例，集群机器越多，影响越小）。另外，我们对分布式存储的状态机进行加速优化，使得基于paxos的选举在秒级内进行集群视图更新推送。长尾时延优化?计算存储分离后，所有的IO都变成了网络IO，因此对于单路IO时延影响的因素非常多，如网络抖动，慢盘，负载等，而这些因素也是不可避免的。我们设计了“副本达成多数写入即返回的策略（commit majority feature）”，能够有效地使长尾时延抖动做到合理的控制，以满足业务的需求。以下是commit majority feature开起前后的效果对比。其中“蓝色”为优化后的长尾时延，“红色”为优化前长尾时延，效果非常显著。?流控?我们实现了基于滑动窗口的流控功能，使得集群后台活动（如backfill和recovery）能根据当前的业务流量进行自适配的调整，在业务与后台数据恢复之间做到最佳平衡。一般如果集群后端活动太低，会影响数据恢复，这会提高多盘故障的概率，降低了数据的可靠性。我们经过优化后，通过滑动窗口机制，做到了前后端数据写入的速动，在不影响业务写入的情况下，尽最大可能提高数据恢复速度，保证多副本数据的完整性。提高数据重平衡的速度，也是为了保证整个集群的性能。因为一出现数据倾斜时，部分盘的负载将变大，从而会影响整个集群的时延和吞吐。?流控效果如下：?高可用部署?在高可用部署上，我们引入的故障域的概念。多个数据副本存储在多个故障域，分布到至少4个RACK以上的机架上，用于保障底层机柜电源以及网络交换设备引起的故障等。为了能够更好的理解数据副本存储位置（data locality），需要知道数据散射度（scatter width）的概念。怎么来理解数据散射度？举个例子：我们定义三个copy set（存放的都是不同的数据）:{1，2，3}，{4，5，6}，{7，8，9}。任意一组copy set中存放的数据没有重复，也就是说一份数据的三个副本分别放置在：{1，4，7}或者{2，5，8}或者{3，6，9}。那么这个时候，其数据散射度远小于随机组合的C(9,3)。随机组合时，任意3台机器Down机都会存在数据丢失。而采用此方案后，只有当{1，4，7}或者{2，5，8}或者{3，6，9}其中的任意一个组合不可用时，才会影响高可用性，才会有数据丢失。综上可知，我们引入copy set的目标就是尽量的降低数据散射度“S”。下图中两组replica set，其中每一组的三个副本分别放置到不同的RACK中。?我们的优化还有很多，这里不再一一列举。数据库吞吐优化?当所有的IO都变成网络IO后，我们要做的就是如何减少单路IO的延迟，当然这个是分布式存储以及网络要解的问题。分布式存储需要优化自身的软件stack以及底层SPDK的结合等。而网络层则需要更高带宽以及低时延技术，如25G TCP或者25G RDMA，或者100G等更高带宽的网络等。但是我们可以从另外一个角度来考虑问题，如何在时延一定的情况下，提高并发量，从而来提高吞吐。或者说在关键路径上减少IO调用的次数，从而从某种程