原生分布式数据库与中间件的区别

编辑：徐宁

编者按：

本文作者宫学庆，是华东师范大学计算机科学与软件工程学院教授、博士生导师。 研究领域为数据库技术和分布式系统，主持过国家自然科学基金项目和多项企业合作项目，发表研究论文30多篇，曾参与交通银行分布式数据库系统研发项目，交流请联系xqgong@sei.ecnu.edu.cn。

以下为正文：

互联网和移动应用的普及让人们使用信息服务越来越方便，也使各类信息系统面临着越来越大的数据规模和访问请求的压力。随着分布式数据库在互联网行业的广泛应用，通过分布式数据库来扩展信息系统的处理能力，成为近年来服务提供商的一种普遍选择。目前，分布式数据库解决方案已经呈现百花齐放的态势，如何选择合适的分布式数据库又成为困扰决策者的一个问题。

从技术角度来看，分布式数据库解决方案大致可以分为两大类，即分布式数据库中间件和原生分布式数据库。分布式数据库中间件是架构在多个传统单点数据库系统上的中间层解决方案，通过将数据分拆到不同的数据库节点上，利用中间件来管理和访问各个数据库中的数据，通常需要用户参与到数据分拆和节点管理过程中。互联网行业最初所使用的分布式数据库方案多是基于中间件的，在解决服务压力问题上也取得了较好的效果，但同时也暴露出不少问题。原生分布式数据库是指从架构设计、底层存储和查询处理均面向分布式数据管理需求，数据库集群作为一个整体对外提供服务，用户无需关注集群内部的实现细节。由于原生数据库系统开发的难度大，最初的版本通常功能简单，限制了其应用的场景。随着版本的不断成熟，原生分布式数据库已经展现出了取代分布式数据库中间件的趋势。

本文将从数据可靠性、副本同步和服务可用性等几个方面进行分析，对比两种方案的区别。

数据可靠性

几乎所有的分布式数据库解决方案都宣称可以在普通PC服务器集群上实现超过高端共享存储的数据可靠性。这一点都是通过冗余来实现的，即将数据进行分片，然后将每个分片复制出n个副本，并且存储在集群中的n个不同节点上，当集群中宕机的节点数少于n时，总能保证有一个副本的数据不会丢失。由于节点宕机等原因导致分片副本的数量少于n时，需要通过将副本复制到新节点来保证副本数量。

在分布式数据库中间件方案中，由于底层的每个节点都是一个独立的数据库系统，中间件很难实现分片副本在不同节点间的复制，因此多利用底层数据库的主备同步机制为每个节点配置独立的备份节点。为了实现更好的数据可靠性，通常需要一主两备3个副本，这样会导致服务器利用率降低和管理的复杂性升高。对于原生分布式数据库系统来说，系统支持数据的自动分片，以及分片副本在集群节点间的自动迁移和复制，实现负载均衡，在服务器利用率和管理复杂性上均明显优于中间件方案。

副本同步

多副本技术虽然保证了分布式数据库中的数据可靠性，但同时带来了副本同步的问题，即如何保证数据分片不同副本的同步更新。具体实现副本同步的技术可以分为四类：

a)   更新主副本，同步复制到从副本：数据副本有主从之分，所有的更新发生在主副本，当更新被同步复制到从副本后，更新完成。这种方式可以保证副本间的数据一致性，但更新的性能会受节点间通讯影响。

b)   更新主副本，异步复制到从副本：数据副本有主从之分，所有的更新发生在主副本，且即时生效，主副本的更新以异步方式复制给从副本。这种方式的更新性能较好，但不同副本间存在更新延迟，在主副本宕机场景下有丢失更新的风险。

c)   并发更新不同副本：数据副本无主从之分，数据更新可以发生在任何副本，并且更新可以同步或异步方式复制到其它副本。这种方式需要解决不同副本间的更新冲突，即所有存在冲突的更新应当以相同顺序被写入所有的副本。在更新冲突较少的场景下具有很好的更新性能。

d)   集中保存更新，定期合并副本：数据副本无主从之分，所有的更新被保存在集群中的特定节点上，定期被合并到各个副本中。这种方式易于实现，能够保证副本间的数据一致性，并且更新性能较好，但查询数据时需要将更新与数据副本进行融合。

不同的原生分布式数据库系统根据针对的应用场景不同，可以选择其中的一种或多种实现技术，并且技术实现的细节对用户透明。对于分布式数据库中间件来说，由于其数据副本是依赖于底层数据库的主从复制机制实现的，只可能采用技术a或者b，并且用户需要对每个节点的主从复制进行配置和监控。

服务可用性

服务可用性是指集群中的任何一个或多个节点宕机都不会影响数据库服务的可用性。在分布式数据库系统中，通常都会有管理节点和服务节点两类角色。管理节点负责感知集群中各节点的状态，实现管理数据分布和节点上下线等功能；服务节点中保存数据分片副本，对外提供数据库服务。可容忍宕机节点的角色和数量是影响分布式数据库可用性的重要因素，一般来说管理节点宕机会直接影响服务可用性，而少于数据副本数量的服务节点宕机不会影响服务可用性。

在原生分布式数据库系统中，管理节点通常是轻节点，仅需维护数据分布等少量的元数据，通过心跳和租约机制监控集群中其它节点的状态。为了避免管理节点宕机造成的单点故障，原生分布式数据库中会部署多个管理节点，然后采用Paxos协议来自动选举主管理节点。所有服务节点是对等的，通过心跳机制与主管理节点保持通讯，少于数据副本数量的服务节点宕机不会影响服务可用性。通过向主管理节点注册，可以方便地添加新的节点，从而实现良好的扩展性。 在分布式数据库中间件方案中，中间件节点不仅需要维护数据分布等元数据，还需要实现查询解析、查询重写和结果聚合等功能，因此可以看成是包含管理节点和服务节点功能的复合节点。为了保证服务可用性，早期的中间件通常采用HA软件来实现中间件节点的容灾，但在实际使用过程中往往暴露出不够稳定的缺点。近来，也有一些分布式数据库中间件开始将管理功能和服务功能分离成单独的管理节点和中间件节点，然后采用Paxos协议来自动选举主管理节点。底层的数据库节点虽然负责存储数据，但并不能直接对外提供服务，必须和中间件节点配合才能对外提供服务。由于底层数据库节点的容灾是依赖于各自的主备同步机制，因此，任何一个数据库节点的主备库同时宕机都会导致整个系统的服务不可用。

综合来看，影响分布式数据库中间件解决方案服务可用性的因素要比原生分布式数据库更多并且更复杂，需要用户花费更多的精力去配置和管理。

跨节点访问

将数据分片后冗余存储于集群中的各个节点，是分布式数据库实现大规模数据的可靠存储的有效手段。然而，当用户需要在一个事务中同时访问位于不同节点上的数据时，如何保证事务的ACID特性成为所有解决方案的共同难题。有一些分布式数据库中间件产品建议用户对数据进行划分，避免出现跨节点访问数据，从一定程度上来缓解这个难题；在无法避免跨节点访问数据时，通过最终一致性和补偿机制来解决。然而，一方面这种思路大幅度增加了用户使用的难度，另一方面，很多场景下是无法应用最终一致性和补偿机制的。

目前，两阶段提交协议（2PC）是公认的解决这一难题的有效手段。2PC是一种阻塞协议，即当事务处理过程中出现协调者故障时，部分参与者的事务会处于未决状态，影响到所涉及数据的可用性，必须等待协调者恢复后才能解决。分布式数据库系统中2PC实现效率和故障恢复机制是影响跨节点事务性能的主要因素。对于原生分布式数据库系统来说，在协议通讯、日志系统和恢复算法方面是作为一个整体进行规划和实现的，比较容易实现一个高效的2PC机制。也有一些原生分布式数据库产品将基线数据和增量数据分开管理，通过集中进行事务处理，以牺牲单个查询性能的代价，有效地避免了分布式事务。对于分布式数据库中间件来说，底层的节点都是独立的数据库系统，有各自的日志系统和事务处理机制，只能在中间件节点上来实现2PC，其实现的难度相当于重写一个数据库引擎，所实现的效率也难以与原生数据库相媲美。因此，虽然有部分分布式数据库中间件也提供2PC的支持，但通常不建议用户使用或者建议用户自行解决使用过程中的未决事务。

数据快照

分布式系统中的时间同步是一个难以解决的问题。使用NTP协议或原子钟对每个节点的时钟进行同步，能够满足对时效性要求不高的应用需求，但对于毫秒级的交易系统来说，所存在的误差仍然是不可接受的。在分布式数据库系统中，基于各节点的时间来获取一个全局的数据快照是不可行的，存在着数据不一致的风险。通常的解决办法是设置一个全局协调者，来为所有的事务分配全局唯一的事务号，这个事务号可以作为一个逻辑时间来使用。

对于原生分布式数据库系统，全局唯一事务号分配机制是集成在事务处理过程中的，并没有额外的处理开销。而对于分布式数据库中间件来说，底层的每个数据库节点都有自己独立的事务处理机制，如果不设置全局协调者来分配全局唯一的事务号，则在不停机的状态下用户无法获取统一的全局数据快照；如果设置全局协调者来分配事务号，一方面会增加额外申请事务号的开销，另一方面还需要对底层数据库节点的事务处理机制进行改造，使其必须按照事务号顺序执行事务，这都会对极大地影响数据库的性能。

小结

分布式数据库中间件技术是十多年前伴随互联网应用的兴起而发展起来的，帮助很多互联网企业有效地解决了控制成本和应对服务压力等问题，也诞生了很多优秀的中间件产品，但同时也暴露出对应用开发的侵入、功能性能受限和管理运维难度大等问题。究其原因，这类技术是在特定的历史时期利用现有数据库产品来解决问题的一种应用级方案，虽然其中用到了一些数据库实现技术，但本质上并不是一个数据库系统。原生分布式数据库系统从诞生之初便是针对大规模数据存储和高并发数据访问而设计的系统级解决方案，假以时日，它一定会取代中间件成为这一领域的主流技术。