12306.cn 的产品技术设计缺陷

【原创】转发请注明出处：http://xuezhongfeicn.blog.163.com/blog/static/224601412012012104845827/

2012年春运又如期而至，针对于广大回乡的人们又要进行一次煎熬，购票是首先需要面对的难题，铁路n次提速，也解决不了春运“一票难求”的局面，原因多方面的，在此不做累述。12306.cn网站横空出世，元旦后平均10亿PV的点击量，aluxe排名59位，一下子让这个出生不久的孩子顶在风口浪尖上，“被成为”一线的互联网电商网站。

用户体验：系统极不稳定， 用户体验差， 频繁大量无效点击操作。
技术解决方案（广大技术网友）： 提升技术架构，扩大硬件容量，异步技术，数据库扩展技术......
点评：技术为了应用/业务服务的，业务为了商业模式服务。 “上兵伐谋，其下攻城”，如果能够在业务层面优化解决问题，就没有必要通过技术改造，系统扩容来解决问题。一本万利。

业务模式思考。12306.cn网站是想变成taobao.com的秒杀呢？ 还是希望成为一种“先来先得”的有序机制呢？ 这个是管理层需要去思考的问题。如果是一般的电商网站，喜欢采取“秒杀”的机制，营造“拼人品”的氛围，大家踊跃点击购买，有很大的随机因素在里面。如果采用排号机制，比如有100张票，只能排在前100位客户可以获得票，后面的人基本就没机会，除非是前面的人不想要（退票需要退票费，防止恶意攻击）。采取后一种业务模式，整个购票是很温和的，基本没有随机因素，先来先得。

购票流程思考。之前的购票流程是，登陆--》车票查询---》订单提交 ----》锁票 -----》支付 -----》出票 -----》线下取票。压力最大的是订单提交，12306.cn的订单和普通网站的订单不同，其他电商网站的单品之间是没有任何联系的，而12306.cn的单品之间是有关联的，每个单品的日期，车次，起点，终点都有关联，而且这些单品是动态生成，因为每个客户的起点和终点都事先不确定。如果是采用数据库来存放车次，座位信息，这将会对数据库造成极大的压力。而且还需要判断客户是否是多次购票（防止黄牛倒票），可想而知，几百万用户同时在线，同事提交订单，导致系统应付不过来也是可想而知的。


产品设计易用性。对于电商网站都是鼓励用户登录的，但12306.cn限制用户登录，taobao.com几百万用户同时在线，也不存在无法登录的问题。无法登录就不能查询订单，不能在线支付，这导致锁定的票号也会被自动放弃。这和设计者的解决问题的思路有问题，为了减轻同时提交订单的压力，我就限制用户登录数。这是一种简单粗暴的方式。一般查询余票下部操作基本是购票，所以查询余票 和 购票没必要放在两个tab下。


解决问题方案和思路

业务模式。由于12306.cn网站的商品火车票是刚需，而且网站本身是事业性质，目的不是为了积蓄人气流量，不需要采用秒杀的购物模式。可以采取温和的“先来先得”模式，将购票客户排队，降低随机性，营造有序的网络购票氛围。只要用户提交订单就默认返回成功，订单状态为“等待出票”。订单任务在队列中排队，系统有条不紊的顺序进行，只要有票，优先给前面的任务。优点：客户不需要频繁点击提交任务，降低系统的无效负载，用户只需要耐心等待到就可以（成功可以短信息通知）。当然系统需要解决重复提交订单的问题（比较简单）。

购票流程。由于采用了”先到先得“的秩序模式，所以可以预先充值，通过网银，第三方支付等，提前将钱款打到12306.cn账户上，解决了农民工兄弟不会玩网银的问题。也就是说，大家把准备工作做足（注册，钱款准备等），只等温和的提交订单，短信或者邮件通知即可。改造后的流程：登陆 --》提交订单 ----》自动支付----》短信通知 ---》线下取票。简略为：登陆--》提交订单--》短信通知结果。鉴于会出现”车票售罄“的结果，根据实际情况，可以让某个身份证购买同一起始站的多张车票（第1首选，第2选择），一旦第一选择购得车车票，其余的自动取消。为了减轻系统复杂性，也可以采取在10分钟（可以配置）之内告知购票结果，如果售罄，可以再选择其他座次或者席位等级。方法论的思路：减少客户的操作，尽量让系统自动执行，并主动告知售票结果（实时性要保证）。降低客户的无效点击，采用此种思路，流量和PV会减轻1-2个数量级，节约巨量的经费。

用户体验：不需要限制用登陆，静态数据查询和动态交易提请区别对待，采用”分级泄洪“模式。 用户可以不受限制的登陆，可以查询车次时刻表和订单情况，账户余额等情况。如果用户需要购票，根据实际情况，限制用户同时提交订单数（比如10万，这个可以动态配置），这样用户虽然不能提交订单，但可以到自己的my 12306中做一些信息查询，用户体验大大增加。其他的一些tab的优化组合也需要跟进，尽量少的页面中完成订票。 方法论：分级泄洪。

技术架构：应用需要拆分，例如：查询中心，订票中心，账户中心，支付中心，等等。应用的拆分，有利于针对性的水平扩展，并且对于核心应用，可以分级提高可用性。多采用异步消息机制，将长事务拆解成短事务.....


12306.cn首先需要在方法论上做调整，先做业务流程的梳理重构，再做技术的优化，多采用分级泄洪的思想，切忌一步封死，善于疏导，而不是填堵。技术解决永远是最后一个环节，产品业务设计优化是”性价比最高“的解决思路。

【原创】转发请注明出处：http://xuezhongfeicn.blog.163.com/blog/static/224601412012012104845827/