12306设计阅读笔记

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

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

评论关闭。