哈巴狗

12306设计阅读笔记

coolshell的陈皓
原文：http://coolshell.cn/articles/6470.html
一、业务复杂度比对
（1）qq/网游模型：只访问自己的数据；
（2）秒杀：秒杀能够只接受前N个请求，后续请求直接返回；
（3）奥运会售票：注册+抽奖，非先来先抢，可以事后线下处理；
（4）电子商务：c2c只需关注自己的库存；
=>
库存是b2c的噩梦，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）排队的人只要看到自己前面的人公平的在减小，也会安心等待。
曹政
引文：http://sd.csdn.net/a/20120115/310787.html
杨建
引文：http://blog.sina.com.cn/s/blog_466c66400100bi2y.html

===
个人感觉，云风的设计简单可依赖
===