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

布老虎在上面提到eventual consistency，我觉得这东西实在不错，看了看wikipedia上的介绍。单就我对wikipedia上BASE条目及其引用文献的理解，这一概念很难用在火车票系统上，至少也不会像布老虎说的这么简单。

首先按照eventual consistency的支撑，CAP theorem的说法，火车票订票系统要保证的是Consistency和Availability，如果要保证这二者，或者哪怕只要严格的Consistency，这样就退回到传统数据库的要求。事实上，所谓证明CAP theorem的这篇文章里面就说：it is impossible to reliably provide atomic,

consistent data when there are partitions in the network。这里的partition，对应我们的问题就是相互独立的后台数据库节点。也就是说，如果后台数据库之间没有同步(如同MapReduce那样)还能保证Consistency和Availability的系统，就和永动机一样，理论上就可以证明是不可能的。这样就退回到Oracle这样的数据库了。

其实BASE系统是不能讲严格的consistency的。布老虎的实现和这篇文章里面的伪代码差不多。为了提高速度，只能保证weak consistency，把几个操作放到message queue里面执行，包括修改不同车次可买的火车票数量和扣用户的钱。这样的系统上线，几乎肯定引发严重的问题。首先是当前查询到的火车票数量是不准确的，任何信息牌上显示的剩余座位信息都是不可靠的。二是当前用户的余额不会立即被扣除，一个恶意用户短时间内可以发起大量购买请求。三是“买到”的票是没有保证的，必须等确认之后才有效，这一点就像是飞机票的超售。飞机票的超售在国内已经引发很多问题了，这个比飞机票的超售还要严重：一是对火车客户而言这是一个全新的概念，以前没有接触过，二是无法确定座位，而火车用户对座位可能看得比飞机上的座次还重。想想春运期间被耍了一把以后还要滞留的客户，不知道会引发多少问题。