主题：【讨论】回应对12306.cn网站的技术质疑 -- 忘情

楼主有不少好建议，类似减少网页静态内容的大小并优化网页结构，利用反向代理来缓存静态内容，采用负载均衡的分布式前端web服务器，分拆数据表等等都是很好的建议，也会很有效。但是有些建议明显不切合火车票卖票业务的实际情况。比如：

1. “我们要在单条数据上进行数据分区，也就是说，把一个畅销商品的库存均分到不同的服务器上，如，一个畅销商品有1万的库存，我们可以设置10台服务器，每台服务器上有1000个库存，这就好像B2C的仓库一样”

这条建议把集中售票的优势抹杀了。原来售票厅售票就是采用沿线每个站事先分配几张票的方式，结果很可能造成一个座位明明空着没有人买，但同一车厢里还卖出了不少站票。而集中售票方式则可以完全避免这样的问题，做到充分利用每个空座。

2. “我觉得完全可以向网上购物学习。在排队（下单）的时候，收集好用户的信息和想要买的票，并允许用户设置购票的优先级，比如，A车次卧铺买 不到就买 B车次的卧铺，如果还买不到就买硬座等等，然后用户把所需的钱先充值好，接下来就是系统完全自动地异步处理订单。成功不成功都发短信或邮件通知用户”

这种方式也不够现实。

a.首先购票是突发业务，在几天的时间内几乎24小时的每一秒都有海量的订票交易，而系统必须在相对短的时间内给出交易是否成功的回复，这就使得异步处理的优势完全体现不出来；

b.其次，现场购票如果买不到火车票可以立刻去买机票长途汽车票，如果异步处理等候时间稍长，比如隔夜才有结果的话，等系统通知我买不到票的时候，很可能也错失了买机票汽车票的机会了，这样更容易引发不满。

c.不知道这次网络售票是不是与售票厅联网，还是单独拿出一批票来卖。如果单独还好说，如果是与售票厅联网，那么就不可能异步处理，因为售票厅是“同步处理”当场卖票的。

如果让我来给建议的话，除了楼主说过的优化前端和数据库表结构的很多建议外，我会建议业务细分。比如查询车次余票用一组前端应用服务器，购票用另一组，结帐再用一组，分配座号（如果需要这个功能的话）又是一组。当然，购票和余票的数据库可能只能用同一组，否则任意区段的余票数目很难得到及时更新，座号可以单独按铁路局分成几组数据库，用户信息又是一组数据库。同组数据库只能采用集群技术分担负载，否则数据一致性就是大麻烦。

技术构架方面，前端服务器和负载均衡代理可以分布在不同的网段（电信联通移动教育网等等）和不同的地理位置以保证网页响应速度，后端数据库也可以在每个网段都放置节点，但前端服务器与数据库节点，数据库节点与数据库节点相互之间必须保证至少10Gbps的连接以提供足够快的网络响应速度。另外，读写数据库要分离。

这样的架构应该可以保证网民打开网页的实时性，同时，由于采用多数据源，以及数据库间交叉查询，也可以保证后台查询的速度和准确性并及时返回查询结果。