详谈数据时代构建高可用数据库

　　近几年，随着移动互联网的发展、云计算的普及和各种新业务的出现，数据呈现爆发式增长，给整个业务系统带来了越来越大的挑战，特别是对于底层数据存储系统。完美的高可用系统，是所有公司最理想的追求。如果只从应用层和缓存层看高可用问题，是比较容易解决的。对于应用层来说，根据业务特点可以很方便地设计成无状态的服务，在大多数互联网公司中，在业务层的最上层使用动态DNS、LVS、HAProxy等负载均衡组件，配合Docker和Kubernetes实现弹性伸缩，能够很容易实现应用服务的高可用。对于缓存层来说，也有很多可选的开源方案来帮助解决，比如Codis、Twemproxy、Redis Cluster等等，如果对缓存数据的一致性和实时性要求不高，这些方案就可以很好解决缓存层面的问题。但对存储层来说，支持高可用非常困难。

　　在互联网架构中，最底层的核心数据存储一般都会选择关系型数据库，最流行的当属MySQL。大数据时代，大家渐渐发现传统的关系型数据库开始出现一些瓶颈：单机容量不能支撑快速增长的业务需求；高并发的频繁访问经常造成服务的响应超时；主从数据同步带来的数据不一致问题；大数据场景下查询性能大幅波动等等。

　　当前，数据库方案有了很多不一样的变化。首先，不同于早期的单机型数据库，在当下数据呈现爆发式增长，数据总量也从GB级别跨越到了TB甚至PB级别，远超单机数据库的存储上限，所以只能选择分布式的数据存储方案。其次，随着存储节点的增加，存储节点出问题的可能性也大大提高，光靠人工完全不现实，所以需要数据库层面保证自己高效快速地实现故障迁移。另外，随着存储节点的增加，运维成本也大大增加，对自动化工具也提出了更高要求。最后，新分布式数据库的出现，用户在OLTP数据库基本需求的基础上，对大数据分析查询的业务要求更高，在某种程度上OLTP和OLAP融合的新型数据库会是未来极具潜力的发展方向之一。

　　什么是高可用

　　Wikipedia的解释中，高可用即High Availability，一般通过SLA（Service Level Agrement）来衡量。这里从CAP角度来看待高可用问题。CAP是分布式系统领域一个非常著名的理论，由Berkerly的Brewer提出。该理论认为任何基于网络的分布式系统都具有以下三要素：

　　数据一致性（Consistence）：等同于所有节点访问同一份最新的数据副本；

　　可用性（Availability）：对数据更新具备高可用性；

　　分区容忍性（Partition tolerance）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A间做出选择。

　　三要素不能同时满足。但后来很多人将CAP解读为数据一致性、可用性和分区容忍性最多只能满足两个，这种解读本身存在一定的误导性，原因就在于忽略了特定条件。假想两个节点N1和N2，在某些场景下发生了分区（P）问题，即N1和N2分处分区的两侧。这时对于外部的写操作来说，如果允许任一节点可写的话就相当于选择了A，丧失了C。同样，如果为了满足C，那么写入操作就会失败，A就无法保证，所以存在分区问题时，无法同时保证A和C。虽然分区在局域网中出现的概率相对很低，但却无法避免，所以系统只能在CP和AP之间做出权衡。

　　当前有很多的NoSQL数据库，在CAP之间选择了AP，比如Amazon Dynamo和Cassandra，追求可用性，适当牺牲一致性，只实现最终一致性。这种选择允许短时间的数据不一致，并且可以交由用户自己来处理写入冲突，但是可以随时接受用户的读写请求。在这种场景下就需要特别注意数据不一致引起的各种奇怪问题，对于比较严肃的业务场景，比如订单、支付等，对事务和一致性要求比较高，这种AP类型的系统就不适用了。而且该系统放弃了SQL和ACID事务，给开发人员带来了更多的开发工作和额外的心智负担，很容易出现问题，所以NoSQL数据库牺牲一致性来获取服务的可用性，并没有彻底解决大数据时代数据库的高可用问题。

　　大数据时代，传统的关系型数据库必然会由单机扩展到分布式，追求数据一致性，所以必然会是一个CP类型的系统，像这种新型的、下一代的分布式关系型数据库，既具有传统单机数据库的SQL支持和ACID事务保证，又有NoSQL数据库的Scale特点，称为NewSQL数据库，包括Google的Spanner/F1、PingCAP的TiDB等等。但从CAP的角度看，选择CP并不意味着完全放弃了A，CP系统只是在某些产生分区的场景下不能实现100%的A，但完全可以通过有效的办法来实现高可用（HA）。由此可见，并不是CP系统就完全放弃了A，只不过在产生分区的场景下无法从理论上保证A，这是一个常见的误解。

　　澄清了CAP的问题，下面讨论如何打造高可用的数据库。数据库是一个非常大的概念，从传统单机SQL，到NoSQL，再到现在流行的NewSQL，这里面不同的实现方案实在太多，本文聚焦在关系型数据库，主要探讨最流行的MySQL数据库及其生态。最近几年，随着大家在分布式数据库领域的探索，出现了很多不同类型的解决方案，比如中间件/Proxy的方案，典型的比如TDDL、Cobar、Altlas、DRDS、TDSQL、MyCAT、KingShard、Vitess、PhxSQL等，还有一种新型的NewSQL数据库，比如Google Spanner/F1、Oceanbase、TiDB等。下面看下业界在打造高可用数据库方面新的技术进展，以及和传统方案选型的对比。

　　消除单点问题

　　为了实现数据库层面的高可用，必须要消除单点问题（SPOF）。存在单点服务的情况下，一旦单点服务挂掉，整个服务就不可用。消除单点问题最常用的方案就是复制（Replication），通过数据冗余的方式来实现高可用。

　　为什么必须要冗余？数据库本身是有状态的，不会像无状态的服务那样挂掉就可以重启，而数据库本身能够保证数据持久化，所以如果没有冗余副本，一旦数据库挂掉，只能等待数据库重启，在这段恢复时间服务完全不可用，高可用就无法保证。但如果有了额外的数据副本，高可用就变得可能了，主要能保证在检测到服务发生问题之后及时做服务切换。

　　对于MySQL来说，默认复制方式是异步的主从复制方式，虽然这种方案被很多的互联网公司所采用，但实际上这种方案存在一个致命问题——存在丢失数据的风险。数据传输经过网络，这也就意味着存在传输时延，那么对于异步复制来说，主从数据库的数据本身是最终一致性的，所以主库一旦出现了问题，切换从库极有可能会带来数据不一致的风险。

　　因为异步复制方式存在更大的问题，很多时候大家都会考虑用半同步复制方式Semi-Sync，这种数据复制方式在默认情况下会使用同步的数据复制方式，不过在数据复制压力较大的情况下，就会退化成异步的数据复制方式，所以依然会存在高可用问题。当然，也有人会选用完全同步的方式，但是这种复制方式在并发压力下会有明显的性能问题，所以也不常用。

　　那有没有一种数据复制方式，能同时保证数据的可靠性和性能？答案是有的，那就是最近业界讨论较多的分布式一致性算法，典型的是Paxos和Raft。简单来说，它们是高度自动化、强一致的复制算法。以Raft为例，Raft中基数个节点组成一个Raft Group，在一个Raft Group内，只要满足大多数节点写成功，就认为可以写成功了，比如一个3节点的Raft Group，只要保证Raft Leader和任意一个Raft Follower写成功就可以了，所以同步写Leader，异步写两个Follower，只要其中一个返回就可以，相比完全的同步方式，性能要好很多。所以从复制层面来看，Raft更像是一个自适应的同步+异步复制方案，同步和异步的最优选择通过Raft算法来保证。