近年来，分布式数据库已经成为了行业中默认的主流技术方向，仿佛只要一款数据库不是分布式架构，即丧失了其技术先进性，无法承载未来业务的发展。这种观点对于“大数据”时代的海量数据需求完全正确，但是，在“账务类”的业务场景下，是否就必须使用分布式架构呢？对于这个问题，业界充斥着截然相反的声音。

一方的观点认为，在大数据时代，“账务类”和其他系统一样，其所需要处理的数据量都有可能会被无限制地放大，因此需要通过一个通用的分布式数据库，满足未来“可能”存在的海量数据强交易场景是非常有必要的。就算是分布式架构下性能与集中式数据库相比存在短板，我们也可以使用分布式的弹性扩张特性，将整体性能无上限地进行提升。

而另一方的观点则认为，在商业化的环境中单纯探讨理论是无意义的，实际上在“账务类”场景中针对海量数据的强交易需求几乎是不存在的。同时，由于硬件条件所限，分布式架构是否能够真正避免网络性能瓶颈也是个问题。一般来说，在目前行业中的大部分“账务类”场景中，Oracle等传统集中式数据库处理能力绰绰有余，因此分布式数据库技术在“账务类”场景中并不存在刚需。

分布式数据库处理“账务类”场景在技术上是否合适？

可以看到，正反方的观点包含讨论技术实现及业务需求的不同方向。从产品发展的角度看，实际上，Google Spanner并不是第一个实现分布式交易数据库的架构。早在上世纪九十年代，IBM DB2 DPF即基于二段提交机制实现了跨节点事务的一致性，将分布式数据库的交易能力进行了商业化实现；2003年Greenplum也提供了可以保证分布式事务下的数据一致性能力（包括：增、删、改、查）。但这两个数据库都没有进一步在强交易的“账务类”场景上发力，迄今为止他们主要业务场景依然围绕着数据仓库展开，并没有过多涉足“账务类”交易场景。

从技术角度来看，分布式交易数据库的处理性能与集中式数据库Oracle相比存在较大差距。这个性能差距存在的前提是：数据量。在几十亿数据量的级别下，集中式数据库通过服务器内存与数据压缩机制，完全能够将这些数据存在一台服务器的内存中。这种情况下，分布式交易所需要执行的代码指令数量以及网络开销，与在单台服务器内部通过内存总线进行数据交换的开销是完全无法相比的。

譬如说，仅仅在事务号分配这个领域，集中式架构只需要简单使用一个原子变量即可生成进程唯一的事务号；而分布式架构要么通过网络从一个集中式GTM生成事务号，要么通过Google Spanner类似的机制使用原子钟生成一个时间范围作为事务顺序号，之后提交时还必须等待一个毫秒级的误差延时才能完成事务提交。

除此以外，无论是二段提交还是优化后的Percolator机制，都会对事务提交造成极大的延时。而由分布式技术所带来的并行执行效率的提升，在“账务类”场景下的点状记录修改需要的是瞬时的交易处理性能，分布式算法所带来的并发带宽扩展能力引入了更多的开销，因此并无用武之地。

因此，从技术以及算法的角度来看，在数据量完全能够使用一台服务器存放的场景中，集中式交易性能一定高于分布式交易性能。一般来说，在DB2、Oracle等成熟的传统交易型数据库中，这个数字可以达到亿级记录的数据量。如同Google这样的互联网巨头，确实会由于更大的海量数据，对分布式交易能力有着较大的需求。因此在Google内部Spanner发挥了重要的作用。但我们从Google Trends的数据中可以发现，在海外，实际的Spanner应用并不活跃，这到底又是什么原因呢？

到这里，我们就必须要讨论在“账务类”场景下，分布式数据库产品的市场契合度的问题。到底哪些行业及客户的“账务类”低延迟强交易场景，有着海量的数据，必须通过分布式数据库来解决？我们知道大部分会产生海量数据的业务系统，例如互联网、物联网等，几乎不存在如同“银行分户账”一样，需要多数据之间信息大量强事务交换的要求。而在其他对数据一致性要求最为明显的金融、电信、政企、交通等领域往往为纯交易场景。企业可以通过微服务及各类架构，控制数据量在十亿行以下，因此集中式数据库在容量上足以支撑，实时处理性能方面也远高于分布式架构。这也许就是如同Spanner、CockroachDB这样的数据库，在海外的实际应用都并不活跃的原因。

分布式数据库与“账务类”场景的市场契合度如何？

可以看到，分布式数据库在“账务类”场景是否具有商用价值，这并非一个纯技术问题，而是一个产品市场契合度（Product Market Fit）的综合问题。

在一个开发人员的眼中，交易系统可以说是包罗万象。以银行金融业务为例，从银行的分户账核心，到支付平台，到渠道系统，都可以归纳为交易系统。而实际上，真正涉及到转账的“账务类”业务系统往往十分聚焦，在金融体系中除了分户账这类真正存储着每个账户金额的数据表，在交易的那一刹那需要强交易能力以外，大部分产生海量数据的业务系统都可以归纳为“非账务类”业务（如各类：报文、业务流水、历史记录等）。

在笔者看来，大部分人对“大数据”存在一个理解的误区，即分布式及大数据可以解决一切问题。宏观条件下，企业数字化转型的过程中会以“非账务类”为主要场景产生海量数据，单台数据库无法处理，分布式数据库是这类需求的绝佳选择。这类业务，往往数据量以数亿甚至达到万亿级别，同时服务的终端业务众多，需要更强的弹性并发能力，且同样需要保障ACID，只是在交易延迟上可以有一定放宽。

而细分到如同分户账核心这类“账务类”场景时，其需求是极限的交易延迟，这一点并不是分布式数据库的优势所在。尤其是在微服务应用架构大行其道的今天，大部分这类交易的场景都会被拆分到多个微服务中，通过各种幂等性原则及补偿策略，完成应用整体的端到端交易能力，降低对底层数据库强交易能力的依赖。

因此，我们可以看到，“非账务类”场景产生了海量数据，分布式数据库十分契合这一场景的业务需求。同时，“非账务类”场景虽然同样需要联机处理的事务一致性能力，但相对于“账务类”强交易能力的需求，相对可以容忍更长的网络延迟。

而对强交易存在刚需的“账务类”场景，其核心需求则是总线级别的交易延迟，同时通过微服务架构细分控制单体数据量，可以更切实地满足业务对各个子系统性能的诉求。在信创的背景下，基于长期成本及供应链的考虑，传统商业化集中式数据库有较强的迁移诉求。对于这类迁移的需求，虽然说95%的“账务类”系统通过集中式MySQL或PostgreSQL架构已经可以承载，但剩下5%数据量较大的系统又应该如何处理呢？综合现实条件的约束，笔者认为通过类似MyCat分库分表中间件方案承载“账务类”系统，依然值得我们探讨。当然，我们也期待未来我国自研的企业级产品，可以给我们提供MyCat这类分库分表中间件方案以外的更多选项。

总体来说，从市场契合度的方面来看，无论从数据量以及应用开发架构趋势，集中式数据库更契合“账务类”场景，对分布式数据库并不存在强烈的市场刚需；而分布式数据库更契合于海量数据需求下的“非账务类”场景。

新一代集中式数据库特性

除了Oracle、MySQL、SQL Server等上一代传统交易型数据库以外，当前业界新一代集中式交易型数据库包括AWS Aurora、以及阿里云PolarDB等。这类新一代交易型数据库通过一写多读的能力，构建基于云平台提供的分布式存储之上。因此，其事务处理依然集中在单台服务的总线之上，并不涉及分布式事务处理架构。

一般来说，这类基于云计算的集中式数据库往往在部署当中采用读写分离的主从架构，用于加速其数据的读取性能，也能够尽可能提升读多写少场景下的性能扩展性。其核心思路参考了十多年前就在Oracle DataGuard以及IBM DB2 HADR等产品中的读写分离架构，同时在数据库缓存及存储方面进行了优化，使得同一份数据可以被多个节点同时读取，减少数据冗余。

因此，类似AWS Aurora或阿里云PolarDB等产品,在数据库引擎的缓存机制上甚至会使用如同Intel Optane“持久内存（Persistent Memory）”等特殊硬件，加以深度优化，使得其运行在分布式的云存储时，还能够保证数据库实例足够低的读写延迟。

这类新一代的集中式数据库，有效基于云平台简化管理模型，同时基于读写分离扩展了查询的能力，减轻写入节点的处理压力，或许可以成为“账务类”场景下有力的数据库竞争者。

架构的选型应该遵循业务的实际需求

通过以上的分析我们不难看出，任何技术的选型都离不开业务需求，产品市场契合度（Product Market Fit）是所有新型产品是否能够在正确的场景获得广泛应用的核心基础。

“账务类”场景在数据量可控的情况下，集中式数据库可以带来更低的延迟，从而获得更高的业务处理性能。而部分超大型企业的系统中，即使是“账务类”系统也可能超出集中式数据库的处理能力，因此引入基于分库分表数据库方案，结合业务处理改造可以更合理地解决现实的业务需求。“非账务类”场景主要面向海量数据，及弹性的高并发联机业务，通过分布式数据库基于多服务器横向扩展能力，可以获得更有效的数据底座支撑能力。但无论是哪一类的系统，对于数据库的ACID一致性能力都同样有着明确的要求。

因此，企业IT架构决策团队在进行技术产品选型时，应该充分论证目标业务的真实述求，以企业的长期发展需求为导向，为不同的业务选型不同的基础技术架构。