【转】12306系统架构优化

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

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

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

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

5、总结
不管如何，系统必定要能水平扩展，加机器能提升性能。

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

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

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

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

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

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

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

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

SK我的感受，云风的“排队论”优化简单可信。