整理：由12306.cn谈谈网站性能技术

由12306.cn谈谈网站性能技术
├属性
│├http://coolshell.cn/articles/6470.html
│├陈皓
│└2012年1月16日
├内容
│├业务
││├其一，有人可能把这个东西和QQ或是网游相比
│││├网游和QQ在线或是登录时访问的更多的是用户自己的数据
│││└订票系统访问的是中心的票量数据
││├其二，有人说春节期间订火车的这个事好像网站的秒杀活动
│││├火车票这个事，一方面会伴随着大量的查询操作
││││└下单的时候需要对数据库很多的一致性的操作
│││├另一方面，买的人路线、车次、时间选择有很多，会不停地改变下单方式
│││└淘宝的秒杀活动
│││　├本质上是用输验证码并在CDN上把用户直接过滤掉了
│││　└比如：1千万个用户过滤了只剩2万个用户
││├其三，有人拿这个系统和奥运会的票务系统比较
│││├奥运会的票务系统当年也一上线就废了
│││├奥运会用的是抽奖的方式
│││├不存在先来先得的抢的方式
│││├是事后抽奖，事前只需要收信息
│││└事前不需要保证数据一致性，没有锁，很容易水平扩展
││├其四，订票系统应该和电子商务的订单系统很相似
│││└需要有一致性的检查的，也就是在并发时需要对数据加锁的
│││　├1）占住库存
│││　├2）支付（可选）
│││　└3）扣除库存
││├其五，铁路的票务业务很变态
│││├突然放票
│││├票又远远不够大家分
│││└据说12306的高峰访问是10亿PV，集中在早8点到10点，每秒PV在高峰时上千万
││├库存是B2C的恶梦，库存管理相当的复杂
││├对于一个网站来说
│││├浏览网页的高负载很容易搞定
│││├查询的负载有一定的难度去处理
││││└可以通过缓存查询结果来搞定
│││├最难的就是下单的负载
││││└对于下单，基本上是用异步来搞定的
│││└去年（2011？）双11节
│││　├淘宝的每小时的订单数大约在60万左右
│││　├京东一天也才能支持40万
│││　└亚马逊5年前一小时可支持70万订单量
││├淘宝要比B2C的网站要简单得多，因为没有仓库
│││├B2C
││││└有N个仓库对同一商品库存更新和查询的操作
│││└淘宝
│││　├每个商户有自己的库存，库存就是一个数字
│││　└库存分到商户头上了，反而有利于性能扩展
││└数据一致性才是真正的性能瓶颈
│├前端性能优化技术
││├一、前端负载均衡
││├二、减少前端链接数
││├三、减少网页大小增加带宽
││├四、前端页面静态化
││├五、优化查询
││└六、缓存的问题
││　├1）缓存的更新
││　├2）缓存的换页
││　└3）缓存的重建和持久化
│├后端性能优化技术
││├一、数据冗余
││├二、数据镜像
││└三、数据分区
││　├1）把数据把某种逻辑来分类
││　│├可以按各铁路局来分
││　│├可按各种车型分
││　│├可以按始发站分
││　│├可以按目的地分
││　│└这些表就可以存在不同的机器上以达到分担负载的目的
││　├2）把数据按字段分
││　├3）平均分表
││　├4）同一数据分区
││　│└有10000个库存，可以分到10台服务器上，一台上有1000个库存
││　└把火车票的数据分区，并放在各个省市
│├四、后端系统负载均衡
│├五、异步、 throttle 和 批量处理
││├异步在业务上一般来说就是收集请求，然后延时处理
││├throttle 技术其实并不提升性能，主要是防止系统被超过自己不能处理的流量给搞垮了
││└批量处理的技术，是把一堆基本相同的请求批量处理
│├云风同学的这个排队系统
││├机制
│││├收到了你的购票下单请求，但是我还没有真正处理
│││├跟据我自己的处理能力来throttle住这些大量的请求，并一点一点地处理
│││└一旦处理完成，我就可以发邮件或短信告诉用户你来可以真正购票了
││└问题
││　├1）队列的DoS攻击
││　├2）队列的一致性
││　├3）队列的等待时间
││　└4）队列的分布式
│├向网上购物学习
││├在排队（下单）的时候
│││├收集好用户的信息和想要买的票
│││├并允许用户设置购票的优先级
││││├A车次卧铺买 不到就买 B车次的卧铺
││││└如果还买不到就买硬座等等
│││├用户把所需的钱先充值好
│││├系统完全自动地异步处理订单
│││└成功不成功都发短信或邮件通知用户
││└知道这些排队用户的需求
││　├可以优化用户的队列
││　│└把用户分布到不同的队列
││　└像亚马逊的心愿单一样
││　　└通过一些计算就可以让铁道部做车次统筹安排和调整
│└小结
│　├系统一定要能容易地水平扩展
│　│├所有的环节都要能够水平扩展
│　│└当你的系统有性能问题时，“加30倍的服务器”才不会被人讥笑
│　├长期的积累
│　├在各个省市建分站，分开卖票
│　└为了那么一两个星期而搞那么大的系统，而其它时间都在闲着
└评论
　├Jerrygee
　│├业务模式稍微调整下，根本不需要很难的技术。单一技术化解决问题是个死胡同。
　│├a.余票查询：余票查询不需要严格跟实际库同步
　│├b.订票
　││├填写需要的车次
　││├订单进入排队
　││└系统根据现有队列长度估算处理时间反馈
　│├d.支付问题
　││└查客票时已经确定了票价，票款预先存入
　│├e.票锁定问题
　│└4.公平原则的保证
　├yalung
　│├假设12306网站限制为只售卖一个车次的票
　│└在最前端有一个入口，用户首先选择车次，然后就直接路由到了处理该车次的子站（服务器）
　├gcd0318
　│├每列车的数据都存在始发站所在地的数据中心
　│└买过路车，就可能需要连接多个数据中心
　├free
　│├预定业务，不是实时购票业务
　│└如果做成类似于高考填志愿类型的预定业务，则不需要很复杂的技术就可实现售票操作
　└haitao  http://blog.csdn.net/sz_haitao/article/details/7174037
　　├专用客户端 的体验效果更好
　　├购票、查询前先支付，得到凭证用于最后的购票确认
　　├每个班次的数据相对独立，可以分布到不同服务器
　　├给身份证增加有效期
　　│├预先到派出所生成身份证+有效期凭证
　　│└用它才能登录购票
　　├放票时间改为24小时均衡发放
　　└12306没包括票务系统，只是原有票务系统的前置系统，电话、窗口等多种接入的一种而已