主题：【原创】好吧，给一个铁道部订票系统的正确答案 -- 布老虎

铁路上一个重要的特点是：“从河南郑州到江苏徐州的票有可能是从北京出发终点站在上海”。如果这张票数据放到河南服务器，那么，从北京到郑州的座位就查不到，被浪费了；如果放到北京，那么从河南中心查的话，是查不到这张票的。如果想要避免这两种情况，就必须线路上每一站都放上资源，这又涉及到数据同步问题。如果不想数据同步，就只能所有经停河南的省的服务器都查询一遍，这与数据集中放置到一台服务器的差别不大。上面分析的是读操作部分，在缓存足够大的情况下，这几种方案读效率差不多。现代数据库写是不会阻塞读的（参考数据库的MVCC方案，很多数据库用的都是这个）。

关键问题是写，当多个写操作并发的锁定同一行数据时，只要一个事务被提交，其他的就要全部重来（读已提交）或者回滚（可串行化），大量相互竞争的写操作不断重来回滚，就会耗尽数据库连接资源，最终读的连接也进不去了。最终看似是读失败，实质是写操作阻塞造成的连接失败。

解决这种问题的核心思路就是人为设计一个并发事务串行化队列。无论供应商吹嘘的多么复杂，本质上就是这个。淘宝用开源数据库，某些高并发的地方就是这么干的。

中国不少行业的数据规模都是全球最大最复杂的，比如电信（以至于要分省运营）、铁路（世界负载最高，调度最困难、最乱、最复杂）、证券（金融创新虽不及美国，但小账户、小合约太多，又是世界上最钟爱短线的市场，散户化特征明显）。东部某发达省某银行曾经从印度引进过据称是使用Java先进技术开发的银行业务系统，结果每到高峰时段就会出现10分钟以上的延迟和停摆，断断续续解决了两年没有解决，最后忍无可忍换掉了供应商。印度公司从来没有想到，中国东部一个县的交易量就已经能赶上别人一个国家。