在数据库选型中，分布式数据库与集中式数据库之争一直是争论热点。一个系统到底用集中式数据库还是分布式数据库，是数据库用户和DBA最为关注的问题。有些朋友直截了当的说“分布式数据库是个伪需求”，也有人说“分布式数据库太浪费，用集中式数据库就够用了”。我以前也在文章中说过，某些场景其实并不一定需要分布式数据库。

伪需求是一种对于系统运行来说不是必需的需求，而是一种基于偏好的假设。确实在实际的数据库应用中存在这种基于偏好的不必要的选择，不过分布式数据库是不是伪需求这个问题，其实还是十分复杂的。

随着现代硬件的发展，大部分中小型的数据库系统的负载是能够用集中式数据库承载的，并不需要横向扩展。绝大多数独立的系统中的数据库并不存在强烈的横向扩展需求，因此大多数分布式数据库厂商宣扬的横向扩展能力对这样的场景确实不是强需求。

不过搞分布式并不总是为了解决单机处理能力不足的问题，从这个角度上来看，部分使用分布式数据库并不是从单机无法承载负载的角度去考虑的。仅仅从单机能否承载整个负载来判断分布式数据库是不是伪需求有点过于武断了。节约资源也不是集中式数据库的专利，二十多年前和和一个银行用户谈数据库优化，谈到了我们在运营商解决高负载系统，节约硬件投资的案例，不过他一直不为所动。他被我纠缠了多次后他对我实话实说了，他们为了确保银行核心交易的可靠性，核心系统的Oracle数据库负载被设定为不超过15%，也就是说CPU使用率等资源超过15%就必须扩容硬件，从而确保系统的可靠性。在这样的需求场景下，因为他们的运维能力是不足以应对高负载系统的，因此他们选择了多花点钱来换取更重要东西。对于这一点我当时还不大认可，认为他们在浪费资源，几年后我参与了一家证券公司的一次故障分析。为了省钱他们在上海分部没有舍得用小型机而是用了相对便宜的X86服务器来跑一套Oracle 10.2.0.3的RAC，其中一个节点经常莫名其妙重启。有一次节点重启发生在尾盘交易期间，故障节点上的应用切换了7分钟才恢复，导致尾盘交易受到影响，因此他们面临了5000多万元的交易赔偿。如果让他们重新选择，无论此次故障是否和X86服务器有关，他们可能都会毫不犹豫地选择更加稳定不过投资金额有点大的IBM小型机。那次故障的原因最后被我找到了，是因为Linux操作系统的VM默认参数不合理导致的。

数据库应用的场景是十分复杂的，不同的用户，用户不同的技术背景、研发能力、运维能力、投资需求、管理需求等都会影响到企业对数据库产品与技术路线的选择。而我们的认知往往是受到自己的背景的局限的，因此有些时候，你并不一定就能简单的否定别人的选择，或者认定某个需求是伪需求。

前阵子和几个金融行业的客户交流，问他们为什么要上分布式数据库，他们说为了高可用，集中式数据库主备切换的时间比较长，同时故障切换可能会丢失部分数据，影响他们的运行质量，因此他们不能接受。我说如果集中式数据库能够实现数据0丢失，同时也能实现自动切换，同时切换时间压缩到5分钟以内，他们能否接受这样的数据库。其中有几个客户认为，集中式数据库能达到此类效果，他们是可以接受的。

接下来我又问剩下的几个朋友，如果集中式数据库有了类似Oracle RAC的功能，单节点故障可以快速切换，是不是就能够满足你们的需求了。其中有些客户说可以了，他们现在就是用ORACLE RAC，国产数据库能达到RAC FCF的切换效果，就能满足他们的需求了。不过有些用户还不满足，他们说RAC虽然是高可用的，不过他们也遇到过RAC集群故障，这时候双节点都不可用，导致了全行核心交易中断，虽然最后也在半个多小时后恢复了，但是也是业务全中断。而分布式数据库虽然节点故障部分数据要切换主副本，但是不会业务全中断，只会影响部分用户，这在业务考核上算是比较轻微的故障。因此，使用分布式数据库对于他们的运营考核十分关键。

从这个简单的例子可以看出，相类似的业务场景，因为自身需求的不同、考核标准不同、技术能力不同，就会做出不同的选择，在这些 场景中，选择分布式数据库也并不是伪需求。实际上，从业务的角度出发，选择分布式数据库是因为集中式数据库存在某些对他们业务场景不利的因素，而选择集中式数据库则是因为分布式数据库有他们无法忍受的缺陷。

就上面那个怕业务全中断影响考核的用户场景来说，实际上选择集中式数据库也是可以解决他的问题的。比如他们的系统能够采用分库分表的方式来进行改造，也可以做到某个数据库出故障只影响一部分用户，不会导致业务全中断，邮储银行的核心系统改造就是这么做的。邮储银行的成功也并不能说明选择分布式数据库的用户的选择是不合理的，因为不同的用户，其对应用改造与分库分表系统的运维能力是不同的，不能用一种统一的标准来衡量不同的用户。在我交流过的大多数用户那里，集中式数据库与分布式数据库的选择没有一个是基于单机能否承载业务负载的，他们大多数是基于业务连续性与运营的考核体系的。可能也有朋友对此不服气，认为采用分库分表完全可以解决用户所关心的问题。分库分表的应用之复杂，也不是所有用户都能够承受的，很多用户玩不转，也就 不敢选择这个技术路线了。

在与用户需求的碰撞中，我们还发现了一些分布式数据库的强需求场景。比如上个月我在北京与一个开发商就系统优化的问题进行分析的时候发现，他们目前的应用采用的是微服务架构，整个系统拆得很碎。数据库是四十多个rds mysql实例承载的。不过他们还是有不少准实时的聚合计算需求。目前的微服务限制了他们这方面的需求，因此他们需要搞一个集中库来聚合这些数据。这个场景就很适合与MySQL兼容性较高的分布式数据库了。我给他们推荐了TiDB和OceanBase。

还有一个用户，正在把几百套小系统从Oracle、MySQL数据库迁移到国产数据库上。他们希望选取一个支持多租户的分布式数据库来完成这项工作。当他们完成迁移后，不需要面对数百个运维起来十分复杂的小型国产数据库，希望只是面对一两个大型的分布式数据库集群。这也是分布式数据库应用的十分典型的场景。

我也遇到过一些用户他们现在优先选择集中式数据库，和他们深入沟通后发现，并不是他们不希望使用分布式数据库，而是目前的很多分布式数据库在功能上与他们的需求还有差距。他们需要具有强资源隔离的多租户，需要HTAP能力，需要多机房双活能力，需要比较简单的运维和强大的可观测性。

从对用户的需求上看，分布式数据库的核心挑战是如何在保证数据的一致性和完整性的同时，实现数据的分布式存储和计算。这需要在功能、性能、复杂度、可靠性等方面做出合理的权衡和设计。目前，市场上的分布式数据库产品还不够成熟和完善，往往存在一些缺陷和局限，比如：功能不完善，只能支持简单的CRUD操作，不支持复杂的SQL语法和分析功能，分布式执行计划的质量不高;性能不稳定，由于需要进行多次网络通信和分布式协调，性能相比单机数据库有较大的损失;复杂度高，分布式数据库涉及多个组件和节点，运维管理难度大，故障排查困难;可靠性低，分布式数据库由于引入了更多的失效点，容易出现数据丢失、不一致、脑裂等问题。因此，分布式数据库的发展还有很大的空间和潜力，需要不断地创新和优化，以满足用户的真实需求。

分布式数据库与集中式数据库的选择其实是用户对自身应用场景、技术能力、技术偏好的综合考虑后的结果，没有完美的数据库和数据库架构，因此集中式数据库与分布式数据库都可以找到适合的应用场景与用户。实际上现在集中式数据库也在弥补与分布式数据库在高可用性方面的差距，分布式数据库也希望自己做得像集中式数据库一样普遍适用各种场景并且可以比较简单的运维，这种相互学习是二者发展的重要动力。多练好内功，在用户真实的需求中找到自己产品的发展方向，把用户所需要的功能做出来并且做好，就会获得市场的认可。