王宗锐阿里云数据库交付架构师9年互联网行业数据库行业经验，历任DBA、售前架构师、交付架构师等职位，在分布式数据库技术方面，经验丰富数据库运维自动化领域尤为丰富。目前的工作方向是信创领域的国内数据库改造和分布式改造。笔者初入该行业是一名MySQLDBA。从事分布式数据库运维和自动化开发5年，积累了大型数据库集群的管理经验。后来担任云数据库售前方案和交付方案的架构师在客户研发和DBA交流合作的过程中，发现很多同学被市面上五花八门的数据库看得眼花缭乱，尤其是分布式数据库，陷入了选择的困境。在这里把自己在分布式数据库领域的实际运维、架构和实现经验分享给大家，希望能引起大家的共鸣。主要从四个方面给大家介绍一下：一、数据库从集中式到分布式的演进1、传统单机数据库狭义上的“数据库”是OLTP场景下的关系型单机数据库，比如老式的Oracle，DB2和其他商业数据库，以及开源产品MySQL和PostgreSQL，主要解决两个业务问题：在线数据库的实时高效访问和交易保障。传统单机数据库除了基本能力外，还支持很多经典的数据库特性，如视图、触发器、外键约束、存储过程等，以满足特定的业务场景。坦率地说，传统单机数据库的容量和性能足以满足大多数中小型客户的需求；商业数据库依托特定的软硬件条件，甚至可以满足一些大客户的数据库使用需求。但随着互联网时代的到来，业务数据呈爆发式增长，单机数据库在存储容量、计算量、吞吐量等方面遇到了瓶颈。数据量的膨胀不仅增加了存储成本，也增加了数据库运维难度和数据安全风险；高并发业务场景，尤其是高并发更新场景，需要足够的数据库计算资源和磁盘IO资源，单机数据库捉襟见肘。虽然可以将业务数据合理拆分到多个数据库实例中，延缓单机资源的高峰时间，但需要不断付出高昂的架构改造成本。2、分布式数据库在这种情况下，分布式数据库应运而生。其基本思想是将多台物理机的资源组织起来，以数据库的形式为应用程序提供服务。理想情况下，高并发场景下的计算、存储io、网络io压力在物理机之间均衡。同时要求具备资源横向扩展能力（scaleout），充分满足业务未来增长需求。一般认为，目前的分布式数据库可以细分为分布式数据库中间件和原生分布式数据库两种，各大数据库厂商也不例外。分布式数据库中间件，自底向上架构，即结合单机数据库实例作为底层存储节点，作为代理层屏蔽应用海量数据分库分表逻辑（理想情况下），在实践中，应用程序完全不知道分布式逻辑，很难实现SQL优化设计）底层存储资源的扩展也让应用程序不知道，典型的ShareNothing架构。原来的分布式数据库，也就是前几年流行的NewSQL数据库，都是一体化的架构。计算层和存储层紧密耦合。计算层OLTP数据库是SMP架构。分布式可以实现负载均衡和高可用。OLAP数据库的多位MPP架构使用并行处理来加速复杂查询；存储层常采用ShareNothing架构隔离IO资源，多副本之间采用分布式共识算法平衡数据可用性和一致性。由于计算层和存储层的一体化设计，往往更容易兼容传统单机数据库更多的产品特性。3、云原生数据库这是近几年流行的一种数据库分类。它常与分布式数据库混淆，但两者有天然的区别。云原生本质上是一种充分利用云计算基础设施的高性能、高可靠、高弹性的特点，在云端开发产品的方式。专门基于云计算资源开发的数据库就是云原生数据库，比如AWS的极光，阿里云的PolarDB。)快速弹性缩放的能力。虽然资源是分布式的，但是数据库架构的本质还是scaleup。与云基础设施的强耦合是云原生数据库区别于分布式数据库的最大特点。4.不同场景下的分布式数据库选择在一些业务场景中，往往不需要采用分布式数据库方案，避繁就简，有更多的轻量级方案：一些新闻、资源类应用往往是写的少，读的多。建议通过部署querycache和单机数据库读写分离来应对。不建议升级分布式数据库。一些电子商务应用具有高并发更新的特点。推荐采用业务模块垂直拆分的方式，以低成本解决业务负载高的问题。未来根据业务增长，分布式数据库将针对高并发模块单独升级。一些国家级在线服务存储海量实时数据，同时处理高并发吞吐量。这是使用分布式数据库的典型场景。由于历史原因，以MySQL数据库为代表的一些应用，单表积累了数亿条数据，单表数据文件达到GB级别，性能明显下降。在此场景下，建议先与业务协商，减少线上数据保留时间，推出数据归档方案；同时要检查指标是否不完善，是否有优化空间；分布式数据库是底线解决方案。针对OLAP场景，在不升级数据库架构的前提下，优先引入成本相对较低的流计算、预计算等大数据处理方案和产品；如果不能满足业务需求，则引入专门的OLAP数据库。如今，国产数据库改造是我国各行业IT改造的重要方向。对于之前使用传统商业数据库的客户，他们最需要的是一个高度兼容的数据库，以控制改造和迁移的成本；而是否选择分布式，需要考察客户的业务场景是否满足以上。提到的适应症。在数据库容灾、异地多活等场景下，原生分布式数据库具有天然的优势，可以根据基础资源、业务一致性需求和可用性需求，采用不同的部署架构来满足，只需要关注应用容灾和多主动研发。2、分布式数据库的分类从应用场景来看，市场上的分布式数据库可以分为三类：OLTP、OLAP、非机构专有领域的NOSQL。这也是大部分云厂商的数据库产品页面上常见的分类。.1、OLTP数据库Mycat与PlarDB-X（原DRDS）同源。原来是淘宝的数据库中间件TDDL。一个是开源的，另一个是商业产品。TiDB是一个非常成功的开源分布式数据库，拥有非常活跃的生态系统和众多合作伙伴。OceanBase是蚂蚁集团最早开发的分布式数据库。主要支撑支付宝的全业务。金融行业有很多客户的成功案例，拥抱了开源生态。2、OLAP数据库OLAP数据库往往要处理海量数据的复杂分析，采用MPP架构，自然需要分布式架构、数据分片、并行计算加速。3.在非制度化专有NoSQL缓存领域，Codis类似于TP数据库中间件解决方案。宽列数据库（bigtable）常用于存储海量非结构化数据，需要高写入吞吐量，自然需要分布式架构。在时序数据库和图数据库领域，并不是所有的产品都是分布式的，但是如果这两个场景涉及的数据量快速增长，分布式架构是一个加分项。三、关系型分布式数据库最佳实践1、分布式数据库中间件1）场景1使用分布式数据库中间件的前提是数据已经充分合理的垂直拆分。最佳实践是业务和数据具有天然的横向拆分特性，比如个人网盘，天然适合拆分用户ID，电商买家数据库，天然适合拆分买家ID，电子社保卡天然适合用于拆分卡号和高并发更新的大数据表。适用于水平拆分。与其关联的小表应该作为广播表使用，不允许拆分的单表不要拆分。2）场景2平滑的扩展能力是分布式中间件的核心技术竞争力。业务不敏感是最高级别，但扩容时很难真正做到可操作的数据粒度。这是一把双刃剑。业务灵活性和运维便利性无法同时实现。拆分键级别的数据迁移和扩容是解决数据库热点问题的良药。最高级别的扩容Realm是底层数据节点和中间件计算层的自适应弹性伸缩。目前看来，与云原生数据库的结合才是解决方案。3）场景三该方案主要是测试分布式数据库中间件的路由灵活性在访问效率和频率允许的情况下，归档库或归档存储甚至可以是冷设备，可以自动开机加载必要的。档案库的OLAP访问可以配置专属MPP架构的中间件代理层，不仅可以实现并行计算加速，还可以与OLTP业务实现资源隔离，避免争用。2.原生分布式数据库1）场景1在自动资源管理上有很大的优势。当有新的机器加入到资源池中时，会在启用datarebalance和balance的情况下自动迁移，这也是资源弹性伸缩的基础。基于这种架构，上层理论上可以兼容各种数据库接口，提供流畅的数据库迁移体验。2）场景2：从单机房机架级容灾到2.3中心机房级容灾，如果采用传统数据库的主从复制架构进行同步，会遇到一致性和可用性的两难选择，需要数据审计、数据修复等多重保险机制，这将带来复杂的应用和数据库开发难度原生分布式数据库通过集群存储的分布式一致性算法保证强一致性和写入效率。同时，只要少数节点出现故障，也能保证数据库服务的可用性。多活架构不仅对数据库有要求，对多层应用的流量纠错也有严格的要求。数据库本身也需要有防止写错的能力，需要一个整体的设计方案。往往是本地化数据库相对于传统单机数据库的优势弯道超车。如果选择国产单机数据库，就会陷入田忌赛马的被动局面。表面采集和回放技术是其中的关键部分，是迁移后数据库功能特性和性能不退化的有力保证。分布式表一定是分布式表》4.关系型分布式数据库总结与展望一句话总结：技术没有银弹，没有最好的数据库产品，没有一劳永逸的分布式数据库架构解决方案，只针对特定的业务场景，最适合的解决方案是分布式数据库中间件，特别适合数据有天然分片特性，但有SQL开发需求的场景，避免非分键查询和分布式事务，否则吞吐量会很大贫穷的。原生分布式数据库适用于对资源弹性伸缩、可用性、强一致性要求高的场景。与传统数据库有很好的兼容性，但架构往往不典型，运维难度略高。分布式执行计划的优化也很难，需要技巧。值得一提的是，现在分布式中间件产品通过自适应分区表、数据一致性哈希、统一binlog服务等新特性的开发，越来越类似于原生的分布式数据库；同样，原生分布式数据库也无法完全摆脱实现数据透明水平拆分的中间件方案。相信未来两者的界限会逐渐模糊。运维原生分布式数据库的架构与传统数据库有很大不同，需要相关人才的积累和经验的沉淀与分享。这也是其拥抱开源社区，努力发展技术生态的重要原因。>>>>Q&AQ1：分布式最终数据一致性的通用实践和最佳实践有哪些？A1：这个问题我举个分布式中间件的例子。一个我比较熟悉的分布式中间件，最早以灵活事务的方式实现了分布式事务的解决。本质上，这个方法是在中间件自己每次执行一个事务时，记录每条SQL的undolog和redolog。一旦发现问题，根据情况决定是重试还是回滚。在这个过程中，存在数据的中间状态。在这个过程中查询的时候，查询会发现数据不一致。但是通过它的undolog和redolog机制，可以保证每个事务的数据最终状态是一致的。同时他们也发现，这种灵活的事务虽然在查询延迟和SQL吞吐量上表现非常好，也能保证最终的一致性，但是对很多客户有严格的数据一致性要求，比如金融中的一些事务业和电商行业。场景不太满意。所以这个方案是分布式事务的替代方案，他们也实现了XA事务作为分布式事务的补充方案，并进一步向全局逻辑时钟事务方案靠拢，最终做到了。所以综上所述，最终的数据一致性只能满足部分业务场景的需求！一般来说，一个理想的分布式事务方案应该是强一致的。Q2：中间件的分布式数据库，业务的一些复杂的多条件查询，有没有经验分享一下？A2：这个问题其实在文章中有提到。一些优秀的中间件分布式数据库产品已经具备了全局二级索引的能力。也就是说，它只能支持有限的多维查询。比如我的主数据是按照orderid拆分的，现在想装sellerid或者buyerid来查询，怎么办？我可以这样实现：创建sellerid或buyerid的二级索引，并使用二级索引保存buyerid或sellerid与订单id的映射关系。同时，为了进一步提高性能，我也可以在我的全局二级索引中覆盖更多的字段，避免二级索引查询的一些要求的回表。这样就解决了多维查询的问题。Q3：你在分布式数据库中遇到过网络分区问题吗？A1：这个问题应该是关于原生分布式数据库的。如果使用原生分布式数据库所谓的半同步和强同步的方式，或者在基于zookeeper的容错的情况下做一致性分区，其实会遇到一些脑裂等问题。但是目前原生的分布式数据库基本上都是采用基于类Poxos分布式共识协议的方案。该方案最大的特点是，只要多数节点发生故障，少数节点发生故障后，多数节点自然会选举master，快速恢复对外服务，保证数据一致性。而一旦少数人发现网络分区，知道自己是少数人，不能举行选举，自然会停止对外服务。这样就避免了网络分区和脑裂的问题。
