12306系统架构优化

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

本文分享自微信公众号 - 架构师之路(road5858)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2014-12-16

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT技术精选文摘

微信支付商户系统架构背后的故事

PostgreSQL-XC在事务管理系统方案本身有一个明显的缺点,那就是事务管理机制会成为系统的瓶颈,GTM(Global Transaction Manage...

20210
来自专栏FreeBuf

挖洞经验 | 如何参加众测项目发现美国国防部网站各类高危漏洞

美国国防部(DoD)于2016年11月21日首次与HackerOne合作,开展了“Hack the Pentagon”的漏洞众测项目,这将允许安全研究人员通过背...

34260
来自专栏musazhang的专栏

【 腾讯云的1001种玩法 】腾讯云数据库优化最佳实战:以 TXSQL 为例

TXSQL-Tencent MySQL 自从2016年5月份正式立项,在近一年的时间里对 MySQL 的读写性能、强同步、大并发量访问和稳定性等方面做了大量工作...

70330
来自专栏芋道源码1024

Dubbo 源码解析 —— Zookeeper 创建节点

前言 在之前dubbo源码解析-本地暴露中的前言部分提到了两道高频的面试题,其中一道 dubbo中zookeeper做注册中心,如果注册中心集群都挂掉,那发布者...

44860
来自专栏Android 开发学习

2016年干货小结

16320
来自专栏编程一生

简单的业务更考验技术--化腐朽为神奇

12420
来自专栏FreeBuf

挖洞经验 | 看我如何利用上传漏洞在PayPal服务器上实现RCE执行

当你看到这篇文章标题时,是不是很吃惊,PayPal服务器的RCE漏洞?Dafaq?WTF?真的吗?这当然是真的,很幸运,我通过枚举和域名查找方法发现了该漏洞。 ...

41950
来自专栏腾讯Bugly的专栏

《iOS APP 性能检测》

| 导语 最近组里在做性能优化,既然要优化,就首先要有指标来描述性能水平,并且可以检测到这些指标,通过指标值的变化来看优化效果,于是笔者调研了iOS APP性能...

2K50
来自专栏Java进阶架构师

dubbo专题-深入分析zookeeper创建节点过程(高清大图无水印版)

在之前dubbo源码解析-本地暴露中的前言部分提到了两道高频的面试题,其中一道dubbo中zookeeper做注册中心,如果注册中心集群都挂掉,那发布者和订阅者...

28520
来自专栏程序人生

思考,快与慢

吐槽:GitBook editor 有个二B的设计-当它莫名检测出文件被外星人修改后,会弹个无法取消的对话框-检测出外部修改,ignore? discard? ...

32270

扫码关注云+社区

领取腾讯云代金券