铁道部购票网站不是单纯的电子商务

铁道部购票网站不是单纯的电子商务

最近很多人在谈论12306。公司内部论坛也发了个帖子谈论12306的性能问题。不过只有我一个人回帖参与讨论了。看到公司的技术气氛还是不是很火热啊。。。

网上面绝大多数人都将12306和电商巨头淘宝，ebay等等相提并论。

我觉得这是有失偏颇的。

首先，淘宝这样的电商是C2C,没有仓管系统，没有物流系统，数据很容易按照淘宝店铺分区存储。淘宝的核心压力在于订单，同时在线的订单请求能不能够被及时消化掉。

但是单个的商品的查询，其实压力是很容易被分担到各个店铺上去。店铺和店铺之间的数据也没有必然的联系。而12306不同，12306销售的是火车票，铁道部的火车票肯定是由铁道部基干系统根据复杂的业务逻辑和算法出票，相同区域的火车，不同区域的火车，不同时刻的火车，之间的业务关系肯定是有的。

换言之，如果你在淘宝上搜索一个Iphone4，淘宝干的其实是，用内部的搜索引擎，在index cache中傻瓜式的扫描.但是在12306上，我们真正搜索的火车票内部是存在数据关联的。

其次，电商公司一般都是从零开始，历史包袱比较轻。而12306不同，12306其实可以看成是铁道部基干系统的web版业务重排。12306中的所有信息来源，数据仓库肯定都来源于铁道部的既有基干系统，我猜测，一般都是Cobol+小型机+复杂业务逻辑的巨大后台系统。

在这种情况下，不能单纯的要求12306打破铁道部的业务编排，采用过多的新架构新技巧。

其实电商中，抛开负载均衡，session水平扩展等，真正最大的压力其实还是数据的一致性，也就是事务的管理

Ebay的架构指南早就说到，要到处异步，容忍不一致性。

1. Partition Everything
2. Asynchrony Everywhere
3. Automate Everything
4. Remember Everything Fails
5. Embrace Inconsistency

异步就是要用柔性事务打断长事务，比如铁道部完全可以将一部分的下单和支付事务分离开来。

比如，在系统压力很大的时候，可以引导一部分请求来到备份系统，在备份系统中，让客户下预约订单，然后在系统压力变低之后，批量处理这些预约订单，通过短信或者邮件通知客户已经为他保有了该车票，请在几个小时之内付款等等。。。(或者用自动付款？)

在比如容忍数据的不一致性，比如我们横切数据库，切出若干个数据中心，根据各个请求的特性(比如， IP ? 购买火车的线路？) ，将请求引导到不同的数据中心中去。

再者，主要压力最大的车票数据查询相关业务表，我们完全可以抽出来，上内存数据库，上镜像数据库，上读写专用表。

总而言之，12306可以把系统的核心业务和外围业务分离开来，并且容许非核心业务表的一定的冗余和失败

其实，和12306类似的应该是航空公司电子票系统

航空公司电子票系统典型的，引入异步设计，将轻重业务分离，重业务依然保证原子性，轻业务做分布式集群，冗余性设计，在丧失一致性的前提下提高性能。

最后再提一下，我不认为IBM来了就能拯救12306，不信请看苏宁易购。

以上，蒋彪