分库一时爽，维护火葬场，有些数据库最终走向了合并

从前单机承载高并发

以前做公安系统每秒写入几百上千。几千个终端的写入。然后大量数据检索以及数据分析、挖掘、下钻。那时候没有HTAP。但是我确实在一个数据库上实现了所有。这期间没有用到Redis这样的缓存也没有用到消息队列的缓冲峰值。因为足以应付用不到啊！

也没有用到解耦。不需要解耦。这上面十几个schema有些就是需要相互调用的。

后来微服务和中台来了

开始时候不知道什么是微服务。其实到现在我也不是非常清晰中台能做什么。据说马老师自己听下属汇报也就是觉得达到他意念中的三分之一。所以这种玄学我不了解也正常。

我见到的很多就是一个Oracle拆了一堆MySQL。或者一个MySQL拆了一堆MySQL。要么就是一个Oracle拆成了一堆Oracle。

拆之前都说每个要独立。最后一看，独立的数据基本走不下去。必须和其他数据通过接口或者服务的互动才能走下去。既然如此为何要拆开？见过太多的案例是为了拆而拆。

这种分库好吗？

一时分库一时爽，一直分库一直爽。然后就开始收到漫长的分库带来的反噬。

首先如果要查询的数据在不同的数据库上，这下就无法关联查询了。于是出现了几种解决方案：

1）将这些数据再汇聚到一个地方。可能是一个集中的数据库也可能是hadoop。当通过CDC的技术汇聚到一个数据库的时候，难道不觉得无奈吗？这是何苦呢？

2）通过接口同步一些数据到本地。比如一个系统需要用户的信息，每次调会员的接口。不是慢就是各式各样的问题。于是聪明的开发人员就是调接口后自己也存一下。下次自己有的用自己的，没有再去找。然后就留下了一个坑，数据存储多处。是不是一致？哪里还管得了那么多。

每个服务都有自己的数据库

结果就是自己理解的划分，或者说是抄别人的。合同、订单、发票。诸如此类一个属性一个数据库。结果是新增合同的同时需要新增订单和发票。同时修改其中一个的时候也要修改其他两个。

这个时候如果是要求数据一致的。（好像我说了一句废话，这个怎么允许不一致？）那么又出现了几种方案：

1）分布式事务，一个个去做，做好了再返回。实际上步骤没这么少，不会只涉及到3个库，3个表。真实的世界不是我们可以想象的。一路走来周期有点长。甚至在走的过程中走丢了。一部分成功了，一部分失败。由于不在一个数据库上，原子性没有保障。分布式事务也控制不了N个数据库，其中还是异构数据库的，全体回退。就导致后续数据补偿的压力很大。

2）异步解耦。这就使得系统架构继续增加环节。上面的同步都没解决一致性问题。这个消息队列就更加解决不了。

以前有个故事，三个和尚因为喝水问题。结果导致成立更多的部门，招聘更多的管理者，提拔更多的干部，设立更多的管理岗位，设置更多的考核、激励机制……

终于原本的小寺庙成了个大寺庙，自然大寺庙就需要大寺庙的配套模式：开会、文件、沟通、协调、打分、评比……数据化、信息化、经营分析会、研究部、战略部、决策部……

大家看看这和分了一堆数据库是不是一个道理？没解决本质问题。

这个现象现在正在改观

不知道和我一直潜移默化主张有没有关系。今日有人在网上问我，他们打算把他们两个数据库进行合并。我看了这个两个数据库属性，我就问是不是这两个就是紧密的？开发答道是的。我又问是不是你们自己觉得放在一起更加好？开发答道是的。我再追问，是不是这些合并后，相关的数据再也不会不一致了？开发答道是的。最终还是ACID和CAP获胜了。