我认为12306 可以改进的地方

January 7, 2014

几条社会数据:

2013年春运期间卖出2.4亿张火车票,折半的话单趟就是1.2亿。 这1.2亿张火车票 网络售票数量不到4成 流动人口总数是2.2亿(不包括市辖区内人户分离)。 12306日每天2000万人访问点击量 高达14亿 最高日售票460万张

以上数据可以得出以下结论: 1.火车的运载量是不太够的。 2.实际网络买票人数员远大于12306售票数的总数。 3.12306卖出的票还是少了点。

下面是我认为12306可以改进的地方。

网页前端可以改进的地方:

我这几天也经历过几次买票,在高峰期进入网站后基本上是一个卡住不动的状态了。经过仔细观察12306的前端我发现改进的余地还是非常大的。

尽量静态化:

这么高访问量的网站必须要尽可能的减少客户端请求,网页前端能静态就静态。少设置一点图片,js与css可以参考rails的AssetsPipline 把所有的资源打包成一个文件,去掉不必要图片。这里可以参考奥巴马的选举网站

页面功能单一化

访问量这么高,完全可以把网站所有不同功能的页面分开。订票与查询完全可以分开成两个页面,订票页面就不要再有其他的资源链接或者其它功能。

订票过程尽量简单

现在用户订票需要选择日期后再查询,然后服务器再返回好几趟车的数据。我认为这一步实在是很多余,买票的人这么多,大家都会事先查好需要买哪趟车,不会等到出票时间去查询再买。面对这种情况,最好是让用户直接再事前输入准确的车次,起终点站就可以了。这样就能减少服务器与客户端之间的数据传输次数与数据量。

可增加的功能(没错,我认为应该增加一些功能。)

现在的订票助手已经做到了离线化订票,既然这样12306为什么不直接把这件事给干了呢?12306拿到用户的订票信息,可根据偏远程度与火车的运载量在后台进行订票的优先级排序。甚至可以在某辆车运载量不够的情况下为用户自动安排最优化的换乘方案与对应的车票。

增加电话订票的可用度

不得不说电话订票实在太难用了,中间经历的过程非常烦琐。能用电话订到票的基本上需要一部带有机械键盘的座机与职业游戏玩家的反应与手速才能做到。简化电话订票中间的流程,多开通几个订票号码,这样能分流一部分订票压力。

后台改进

从春运的卖出的2.4亿张火车票的数量上来看,这真的是实实在在的大数据处理。甚至被称为世界级难题我认为都是可以的。因为后台跟12306前端所面对的问题完全是不再一个层面上的。因为后台需要将电话,售票点,代售点,网络售票,退票这几个点的火车票全部进行管理。也就是需要为这2.4亿张火车票做一个中心数据库系统。而且这个系统需要满足: 高并发:几百万人在一个时间点同时买票。 高可用性:不能done机 高响应:读写的时间不能太长 恐怖的一致性:是的,这个一致性很恐怖。因为所有的订票请求,都需要在一个地方去拿,不能出现两个人订到了同一张票的情况。虽然电话,售票点,代售点,退票这几个点可以提前分配好资源。网络售票在一个时间点保持几百万个资源的一致性是非常恐怖的操作。

改进方案:

陈皓在去年提出了几点解决方案:数据镜像 ,数据分区 ,后端系统负载均衡
他的大致思路是一个数据负载均衡的思路。就是尽量不让用户去大量的访问一个点。实际上铁道部已经在去年开始就使用了分时间段买票的方法。这一方法就是一个负载均衡的思路。效果是有了,但是实际上只是消化了一部分数据,但还是有海量的数据存在。我倒是比较赞同他的另外一个思路,就是收集用户的订单,然后到了一定的时间与数量再提交到中数据库中。

我的思路:

既然要批量提交,为什么不把剩余票源提前从数据库里面挖出来做一个缓存,然后读写这块缓存,到最后在提交这块缓存到中心数据库。每个节点服务一批用户,缓存的节点不能太少,缓存应该在从中心数据里挖出来的那时候起就要保证将来数据库里一致性的问题。但难度在于如何将用户分配到适合的票源缓存点去?这就要按车次与席别还有乘车日期类型的不同来分配车票的类型。这个计算过程是独立,完全可以很轻松的做到并行计算。

小结

春运火车票这个问题基本上无解,因为需要买票的人数大于票的总数。火车的载量是有限的,技术能解决的问题只能是让尽可能多人的人更顺利的买的票,不能产生更多的票。所以我想无论是叫阿里还是其他市场化的公司来做这个系统,没有买到票的人该骂的还是照样会骂。当然,上面的提出的一些方式也是比较理想化的。并没有过多的去考虑太多的细节问题。