哈巴狗

再读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

SK个人感觉，云风的“排队论”优化简单可信。