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个人感觉，云风的“排队论”优化简单可信。

12306系统架构优化相关推荐

Entity Framework 数据并发访问错误原因分析与系统架构优化
本文主要记录近两天针对项目发生的数据访问问题的分析研究过程与系统架构优化,我喜欢说通俗的白话,高手轻拍 1. 发现问题系统新模块上线后,使用频率较高,故在实际使用和后期的问题重现测试中,产生了一下系 ...
阿里云存储表格存储TableStore-高并发IM系统架构优化实践
文章地址:https://yq.aliyun.com/articles/66461?utm_campaign=66461&utm_medium=images&utm_source=os ...
秒杀系统架构优化思路
本文曾在"架构师之路"上发布过,近期支援Qcon-AS大会,在微信群里分享了该话题,故对原文进行重新整理与发布. 架构师之路16年精选50篇一.秒杀业务为什么难做 1)im系统, ...
阿里秒杀系统架构优化思路
秒杀业务为什么难做 im系统,例如qq或者微博,每个人都读自己的数据(好友列表.群列表.个人信息) 微博系统,每个人读你关注的人的数据,一个人读多个人的数据秒杀系统,库存只有一份,所有人会在集中的时 ...
12306系统架构，凭什么支撑每天如洪水般的各种抢票插件？
点击上方"码农突围",马上关注这里是码农充电第一站,回复"666",获取一份专属大礼包真爱,请设置"星标"或点个"在看&quo ...
(转载)秒杀系统架构优化思路
转载自: https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959391&idx=1&sn=fb28fd5e ...
Node.js 多进程/线程 —— 日志系统架构优化实践
1. 背景在日常的项目中,常常需要在用户侧记录一些关键的行为,以日志的形式存储在用户本地,对日志进行定期上报.这样能够在用户反馈问题时,准确及时的对问题进行定位. 为了保证日志信息传输的安全.缩小日 ...
高并发IM系统架构优化实践
互联网+时代,消息量级的大幅上升,消息形式的多元化,给即时通讯云服务平台带来了非常大的挑战.高并发的IM系统背后究竟有着什么样的架构和特性? 以上内容由网易云信首席架构师内部分享材料整理而成相关阅读 ...
关于秒杀的系统架构优化思路
一.问题的提出秒杀或抢购活动一般会经过预约,下单,支付 ,扛不住的地方在于下单,一般会带来2个问题: 1.高并发比较火热的秒杀在线人数都是10w起的,如此之高的在线人数对于网站架构从前到后都是一 ...

12306系统架构优化

12306系统架构优化相关推荐

最新文章

热门文章