网购到火车票浅析淘宝和12306网站架构.docVIP

网购到火车票 浅析淘宝和12306网站架构 2012年11月22日09:32 12306火车票购票系统，逢假日必瘫痪，引发了强烈反响。国庆前后，“问诊12306”的时候，铁道系统的答复是，购票人数太多，数据量过大。但是，在前不久淘宝双11大促活动中，淘宝双十一总交易金额191亿，订单1亿零580万笔，其中无线支付近900万笔，支付宝核心数据库集群处理了41亿个事务，执行285亿次SQL，生成15TB日志，访问1931亿次内存数据块，13亿个物理读，核心MySQL集群一天支持了20亿个事务。12306火车票系统和其相比，真是天上地下。12306为何如此烂? 　　1. 淘宝技术被人称赞 　　在刚刚过去的淘宝双11大促活动中，淘宝的技术支撑受到了网民的追捧。据来自支付宝DBA@dbatools的透露：淘宝双十一总交易金额191亿，订单1亿零580万笔，其中无线支付近900万笔，支付宝核心数据库集群处理了41亿个事务，执行285亿次SQL，生成15TB日志，访问1931亿次内存数据块，13亿个物理读，核心MySQL集群一天支持了20亿个事务。 　　淘宝的技术人员以实际行动让网民折服，虽然在淘宝双十一活动刚开始的10分钟内的访问高峰期内，购物车和支付宝都出现了打不开的情况，但订单可以生成，而且白天的系统运行比较正常。双十一期间，淘宝除了技术上的保障，还有大量的运维策略的支持，比如在峰值期间下订单优先级最高，支付可以晚点儿，大额度的订单优先处理等等。 　　淘宝网采用什么技术架构来实现网站高负载的呢?据淘宝技术人员分享，淘宝的整体架构使用了如下措施来应对：一应用无状态(淘宝session框架);二有效使用缓存(Tair);三应用拆分(HSF);四数据库拆分(TDDL);五异步通信(Notify);六非结构化数据存储(TFS,NOSQL);七监控、预警系统;八配置统一管理。 　　2. 12306网站被人诟病 　　淘宝强大的技术实力，很容易让人们联想到让人“一票难求”的订票网站-12306。12306网站购票难的问题几乎成了所有人的共识。来自前支付宝架构师冯大辉(@Fenng )的这条微博翻出12306这笔账，别有一番滋味。 　　以冯大辉的计算方法，支付宝11月11日一天就处理了1亿零580万条交易请求量，而12306一天处理的交易(出票量)仅仅166万条，这还主要是集中在8点钟开始放票之后的5分钟时间里。从结果来看，12306弱爆了，处理的交易量比支付宝“低了两个数量级”还那么弱不禁风。 　　冯大辉的微博马上得到了@caoz的转发响应，后者在9月底对12306的骂战中一战成名，由于观点相似，caoz和Fenng可以称为统一战线——当然，众多对12306充满怨恨的普通购票者也与他们在感情上统一战线。 　　简单分析一下12306的购票系统，为避免“黄牛”买票，购票系统有一个业务逻辑：一个有效身份证件同一乘车日期同一车次限购一张车票。因此购买一张车票可以简化为包含四个操作： 　　1) 判断同一乘车日期同一车次是否有未预订的空余座位 　　2) 判断这个有效身份证是否已购买过同一乘车日期同一车次的车票 　　3) 车票上标注的座位标记为已预订 　　4) 如果没有购买过，则该身份证预订一张车票 　　人们在12306网站上购买一张票的流程如下： 　　1)用户通过浏览器访问系统URL 　　2)界面集群F5将请求转发至某一节点，通过比较用户数据库的内容进行身份鉴权。 　　3)鉴权成功后进入订票，提交订票订单(查询流程暂不讨论)界面显示请等待 　　4)订票消息被发送至总线部件(接口可用webService、RMI、甚至自定义协议都可以) 　　5)总线收到订票消息、去Cache集群查询相关车次 　　6)Cache根据自身维护的车次余票表，返回查询结果，如果有余票，转7)。如果无票了，则总线返回界面集群“没票了”，界面提示用户明天再试。 　　7)若有余票，则总线返回界面集群“正在出票，请等待”，并将订票请求压入队列。且发消息至Cache，告诉CACHE将订票请求加入队列。 　　8)Cache收到总线队列增加1个的消息，将自身维护的对应车次余票数减1个。 　　9)总线另一线程负责从队列中取消息，并发送至出票部件。 　　10)出票部件产生订票结果，并修改数据库，发送“订票成功”消息回总线。 　　11)总线将订票成功消息直接回传至界面集群。 　　12)用户看到订票结果。 　　3. 跟淘宝相比，12306网站的有独特的技术难度 　　1) 火车票属于竞争性资源。淘宝的交易是相对离散的，分散在成千上万的卖家当中，同时对同一商家同一商品的并发购买并不是特别高。因此在数据访问上不会有太大的锁同一数据的瓶颈，买火车票在这方面压力会更大，最主要的原因还是僧多粥少的。火