12306系统架构优化

12306系统架构优化

coolshell陈皓优化方案 原文：http://coolshell.cn/articles/6470.html 一、业务复杂度比对 （1）qq业务模型：只访问自己的数据 （2）秒杀业务模型：秒杀能够只接受前N个请求，后续请求直接返回 （3）奥运会售票业务模型：注册+抽奖，非先来先抢，可以事后线下处理 （4）电子商务业务模型：c2c只需关注自己的库存 结论：库存是b2c的噩梦，12306业务与之类似

二、瓶颈 库存业务的操作模式基本是这样的： 1）占住库存 2）付款 3）扣除库存 这个过程中，是要对数据进行加锁的，高并发下数据的一致性保证非常之难。 并发究竟有多大呢？ 12306的业务特点是，突然放票，大家去抢。几十分钟内，马上几千万的访问量，非常恐怖（据说高峰访问是10亿PV，集中在早上8点到10点）。 结论：高并发下数据一致性是12306的痛点

三、前端优化 （1）负载均衡：DNS+CDN； （2）减少页面链接数：减少浏览器http并发连接，合并js，合并css，合并图标 （3）减少页面大小：带宽有限，压缩，分离图片服务 （4）页面静态化：同一时间查询相同车次的结果页面都是一样的，甚至可将静态化的文件放入/dev/shm下 （5）查询优化：票务结果显示“有/无”，而非具体数字，能大大简化逻辑 （6）前端缓存：直接缓存动态页面

四、后端优化 （1）数据冗余：一个数据可以冗余存在多个表里，代价是一致性 （2）数据镜像：replication，仍然有一致性问题 （3）数据分区：分库，分表，分字段 （4）负载均衡：静态分流，动态分流 （5）异步化、throttle（节流，一般需要排队）、批量处理

五、总结 无论如何，系统一定要能水平扩展，加机器能提高性能。

云风的BLOG优化方案 原文：http://blog.codingnow.com/2012/01/ticket_queue.html 一、核心思想：排队论，餐馆里拿到号的人才能进来吃饭

（1）生成一些签名过的“号”给排队者（“号”不可伪造） （2）一个32G大数组，循环队列，将“号”放入队尾，并hash记录“号”在队列中的index （3）利用一次hash查询，由index和head可知排队者前面有多少人 （4）如果排队者前面没有人了，好吧，给你个签名过的session，进去吃饭吧（“session不可伪造”）

二、注意点 （1）刷“号”也是没用的，不能让你提前 （2）拿到“号”的人心切呀，急于知道他前面排了多少人，便反复查询，反复查询，可以设定阈值，查询频率过高，则“票”作废，这样以降低大家查询的频率 （3）session有有效期，拿到session不去吃饭，重新排队

三、总结 （1）拿到session后才能走正常购票流程，此时性能已经不是瓶颈，大不了多开几个窗口，不正确或者超时的session立马可以断掉 （2）排队由“号”拿session可以精确控制真正进入系统的流量，而排号的系统又是内存的高性能简流程操作 （3）排队的人只要看到自己前面的人公平的在减小，也会安心等待

曹政的和谐blog优化方案 原文：http://hi.baidu.com/ncaoz/item/9bdefa308f1bb7f3e7bb7a84 （ SK注：caoz同学很自信，2人2周，40台服务器搞定，大家一起看下他的方案） 一、业务抽象 （1）车次查询+余票显示，日均10亿PV，这是主要矛盾 （2）注册登录，日均几千万PV （3）下单，日均几百万PV 不涉及复杂的关系操作，不涉及推拉结构、不涉及革新展示。

二、优化方向 （1）存储KV化，例如redis：基本所有查询都是直线式的，可以用redis的集合或者列表搞定 （2）后端查询结果缓存化： 2.1）缓存符合要求的车次 2.2）缓存余票 2.3）缓存有票/无票状态 （3）前端缓存+防刷 （4）IO优化，几百万的订单而已

三、总结 缓存（查询结果静态化）是整个优化方案的核心 这个手段极其适用于符合这两个要求的场景： （1）查询频率远大于更新频率 （2）所有用户在同一时间查询同一条件，返回结果都相同

四、引文 caoz在上文中引用了“杨建”网站Cache加速的文章， 杨建的BLOG-“网站加速-Cache为王”链接如下： 原文：http://blog.sina.com.cn/s/blog_466c66400100bi2y.html