大家经常会听到分布式事务处理，分布式存储等等。但是，在大规模交易系统中，对于核心数据的部分，这些都是狗屎；害死了许多人。前前Paypal的CTO就是被这东东给害了。
由于交易量不断的增大，当时Paypal的核心数据库服务器的Load非常高，超过80%。为了解决问题，决定采用分布式存储，把核心数据的用户信息和Balance数据按用户名来分库存储在不同的地方，采用事务两阶段提交（Two-Phase-Commit）的方式来保证事务的一致性。
当时看来，这个解决方案很好，理论上可以完美的解决核心数据库压力太大的问题。上线前的测试也很好，没有出现任何问题。但是，，，
上线后不久，整个系统就被打死了。为啥？就是因为分布式存储和事务的两阶段提交（Two-Phase-Commit）。线下测试没问题，是因为测试情况下没那么大流量、事务的压力。上线以后就不一样了，一个需要两阶段提交的事务因为某种原因给堵住了，马上产生连锁效应。啪啦啪啦，一大批就给堵死了。整个数据库就给弄死掉了。巨大流量压力下，两阶段提交把数据库间通讯的流量给放大了许多倍。你系统想不死都难。。。但是这个问题，测试环境下你是测不出来的。呵呵。。
Paypal由于这个原因，系统死了几天；影响太大，那时的CTO也只好被迫辞职了。
扯了一些闲话，现在进入主题。那就是核心数据库到底应该有几个？是不是要分布式存储的？。。。答案是只有一个，不是分布式存储的，不能采用两阶段提交的方式解决事务一致性的问题。
有人会问？那你如何解决压力问题。。Paypal的交易量是每天几百万笔，交易量巨大，它的核心数据库就一个。支付宝的交易量也是每天几百万笔，据我所知，核心数据库也是一个（支付宝的和Paypal的有些不同，它系统的交易流和资金流是分开的，所以核心数据实际上是有两类）。。。呵呵，你的交易系统的流量能够有多大？压力能够有多大？。。显然在可以预见的范围内。你的核心数据库只需要一个。
那？如何解决数据库压力问题？。。方法其实很多，比如缓存机制，数据库分区等等。
其中很重要的一个方法就是读写分离。其实数据库读操作占了数据库操作的绝大部分；而且，并不是所有读操作都需要是实时的操作。这些操作完全可以从主数据库中移走，让它们访问镜像数据库或其它由主数据库导出的数据源。
另外一个重要的方法，当然是把不需要实时操作的表从主数据库里移走。这个好像显而易见，但是往往被设计者忽略了。简单有效的东西往往会被忽略。呵呵。
还有，大家不要巨大的交易量给吓住了。。你算算，就算是每天几百万笔的交易，每秒平均才多少笔交易。呵呵，也就100笔。。哈，你核心数据库和主表设计的好的话，1秒100笔的交易，能够有多大的压力？就算是峰值，乘以10倍，也就1000笔每秒。
所以，把不需要实时的表移走，把大部分读操作移走，把你的数据库设计得好一点；一个核心数据库绝对可以支持你超大规模的交易量。别自己把自己吓死，到处找好像很Fancy的东西来解决你的问题。