一些业务场景下，往往不需要采用分布式数据库方案，避繁就简，有更轻量级的解决方法：

• 一些新闻、资源应用常有写少读多的特点，建议通过部署查询缓存和单机数据库读写分离的方式来应对，不建议升级分布式数据库。
• 一些电商应用会有高并发更新的特点，优先建议采用业务模块垂直拆分的方法，低成本解决业务负载高的问题。后续根据业务增长情况，针对高并发的模块单独升级分布式数据库。
• 一些全国级别的在线服务，就是会存储海量实时数据，同时应对高并发吞吐，这是采用分布式数据库的典型场景。
• 有些应用因为历史原因，以MySQL数据库为代表，单表内积累了上亿的数据量，单表数据文件达到GB级别，性能出现显著退化。此场景优先建议与业务协商，减小在线数据保留时间，上线数据归档方案；同时要考察是否索引不够完善，是否存在优化空间；分布式数据库是兜底方案。
• 对于OLAP场景，在不升级数据库架构的前提下，优先引入流计算、预计算等大数据处理方案和产品，成本较低；如还不能满足业务需求，则引入专门的OLAP数据库。
• 如今国产数据库改造是国内各行业IT转型的重要方向，对于之前选用传统商业数据库的客户，最需要的是高兼容数据库来控制改造迁移成本；而是否选用分布式，要考察客户业务场景是否符合上面提到的指征。
• 数据库容灾、异地多活的场景，原生分布式数据库具有天然优势，可根据基础资源、业务一致性要求和可用性要求，采用不同的部署架构满足，只需将精力集中在应用容灾和多活的研发上。

从应用场景角度看，市面上的分布式数据库可分为OLTP、OLAP和、非机构@amp;专有领域NOSQL三个大类，这也是大多数云厂商数据库产品页面的常用分类。

1、OLTP数据库

Mycat和PlarDB-X（之前的DRDS）系出同源，最早都是淘宝的数据库中间件TDDL，一个开源，一个是商业产品。

• TiDB是非常成功的开源分布式数据库，生态非常活跃，有很多合作伙伴。
• OceanBase是最早蚂蚁集团研发的分布式数据库，主要支撑了支付宝全业务，在金融行业有较多客户成功案例，进来已拥抱开源生态。

2、OLAP数据库

OLAP数据库往往要处理海量数据的复杂分析，采用MPP架构，天然需要分布式架构，数据分片，进行并行计算加速。

3、非机构化@amp;专有领域NoSQL

缓存领域，Codis类似TP数据库中间件的方案。

宽列数据库（bigtable）往往用于存储海量非机构化数据，需要高写入吞吐，天然需要分布式架构应对。

在时序数据库和图数据库领域，并非全部产品都是分布式的，但这两种场景涉及的数据量如果增长较快，分布式架构是其加分项。

1）场景一

分布式数据库中间件使用的前提是，数据已经进行过充分合理的垂直拆分

最佳实践是，业务、数据具有天然水平拆分特点，如个人网盘，天然适合用户id拆分，电商买家库，天然适合买家id拆分，电子社保卡，天然适合卡号拆分

有高并发更新的大数据表，适合水平拆分，与他关联的小表做广播表，不许关联的单表不要拆分

2）场景二

平滑扩容能力，是分布式中间件的核心技术竞争力，业务无感是最高境界，但很难真正做到

扩容时可操作的数据粒度是把双刃剑，业务灵活性和运维便利度，不可兼得

拆分键级别的数据迁移与扩容，是解决数据库热点问题的良药

扩容的最高境界，是底层数据节点和中间件计算层的自适应弹性伸缩，目前看来，与云原生数据库相结合是解决之道

3）场景三

此方案主要是对分布式数据库中间件路由灵活性的考验

访问实效性和频率允许条件下，归档库或归档存储甚至可以是冷设备，需要时可自动加电加载

可以为归档库的OLAP访问，配置专属MPP架构的中间件proxy层，既达到并行计算加速效果，又实现了资源与OLTP业务隔离，避免争抢

1）场景一

• 一大优势是资源自动化管理，将新机器加入资源池，在开启数据rebalance条件下，会自动进行迁移和均衡，这也是资源弹性伸缩能力的基础

• 以此架构为基础，上层理论上可以兼容各种数据库的接口，提供平滑的数据库迁移体验

2）场景二

• 从单机房的机架位级别容灾，到两点三中心的机房级别容灾，如采用传统数据库的主从复制架构来做同步，都会遭遇一致性和可用性的两难问题，需要数据稽核、数据修复等多重保险机制，带来复杂的应用和数据库开发难度

• 原生分布式数据库通过集群化存储的分布式一致性算法，确保了强一致性和写入效率的同时，只要是少数派节点故障，也可确保数据库服务的可用性

• 多活架构不仅对数据库有要求，对应用多个分层也有流量纠错的严格要求，还需要数据库自身具备防写错能力，需要整体设计方案

3）场景三

• 国产化数据库改造，不是必须选择分布式方案，但分布式往往是国产化数据库相对传统单机数据库弯道超车的优势所在，如果选用国产单机数据库，会陷入田忌赛马的被动局面

• 采集回放技术是这其中的关键一环，是迁移后数据库功能特性和性能不退化的有力保证

• 使用分布式数据库改造后，需要拆分的表，才进行分区表设计，不要“因为用了分布式，就都要分布式表”

Q1：分布式最终数据一致性的常用做法和最佳实践有哪些？

A1：这个问题我举一个分布式中间件的例子吧。我熟悉的一个分布式中间件，它最早实现决分布式事务采用的是柔性事务的方式。这个方式本质上是由这个中间件自身来在每次执行事务时候，记录每条SQL的undo日志、redo日志。一旦发现问题之后，它自己根据情况，决策重试还是回滚，在这个过程中就存在数据中间状态.在这过程中查询，就会查询到数据是不一致的。但通过它的undo日志和redo日志的机制，能够保证每笔事务的数据最终状态是一致的。同时他们也发现，这个柔性事务虽然在查询延迟、SQL吞吐上表现非常好，也能保证最终一致性，但对很多客户的较苛刻的数据一致性要求，比如金融行业、电商行业交易的一些场景是不能很好满足的。所以这个方案他们是作为分布式事务一种备选项，同时他们也实现了XA事务作为分布式事务的补充方案，并进一步向全局逻辑时钟事务时的方案靠拢，最后是这么做的。所以总结来说，最终数据一致性仅能满足一部分也业务场景的的需求！通用的，理想的分布式事务方案应该是强一致性的。

Q2：中间件的分布式数据库，针对业务的一些复杂多条件查询，有一些经验可以分享一下吗？

A2：这个问题在文章中其实有所涉及，中间件的分布式数据库目前的一些优秀产品已经具备了全局二级索引的能力。也就是说它可以支持有限的多维度查询。例如，我的主数据是基于订单id进行拆分的，但现在我想安装卖家id或买家id来进行查询怎么办？我可以通过这种方式来进行：去创建卖家id或买家id的二级索引，由二级索引来保存买家id或卖家id和订单id之间的映射关系。同时为了进一步改善性能，我还可以在我的全局二级索引里覆盖更多字段，根据二级索引查询时的一些要求来避免回表。通过这样的方式来解决多维度查询的问题。

Q3:在分布式数据库中网络分区问题遇到过吗？

A1：这个问题应该是关于原生分布式数据库的。原生分布式数据库如果你采用之前所谓的半同步、强同步等一些方式，或者在基于zookeeper做一致性的分区的容错的情况下，其实会遇到脑裂等一些问题。但基本上现在的原生分布式数据库采用的都是基于Poxos类的分布式一致性的协议来做的方案，这种方案最大的特点在于：只要不是多数派的节点出现故障，少数派的节点出现故障之后，多数派的节点就会自然而然地选主出来，快速地对外恢复服务，并且保证数据的一致性。而少数派一旦发现网络分区，知道自己是少数派没办法进行选举之后，就会自然地对外停止服务。通过这样的方式来避免网络分区和脑裂的问题。