如何设计高并发高流量的12306在线票务系统
获奖名单已公布，详情请看：http://bbs.chinaunix.net/thread-3675185-1-1.html
“当前访问用户过多，请稍候重试！”“系统忙！”……类似的提示，在旅客登录12306时屡见不鲜。12306的“不堪重负”，一方面是由于巨大的购票需求所致。铁路部门的统计显示，从1月5日起，12306的日均点击量曾连续超过10亿次，访问量环比上月激增10余倍。在我这里我们可以以10亿次/日来稍为计算下12306的并发值，10亿/3600/24=0.00011570亿，大约11000并发值，这个值是非常大的，对数据库、程序、Web应用都是非常有要求的；另外，由于牵涉到票务系统的身份认证，所以安全方面也不容忽视。因此，希望我们能在这里一起来讨论下如何设计高并发高流量的12306在线票务系统的相关话题：
讨论话题：
1.针对目前12306网站的瓶颈进行分析（可以是从我们自身可以获取到的信息进行分析）。
2.如何设计和部署高并发高流量安全的在线票务系统。
3.现在有哪些比较成熟的系统或者方案。（因为12306拒绝了IBM等的成熟方案，选择自己开发）
邀请嘉宾：
老男孩 （老男孩linux培训）老男孩Linux实战运维培训中心总裁
崔晓辉（ coralzd ） 大众网高级系统管理员
刘晗昭（wenzizone）昆仑万维高级架构师
胡安伟（king_819） 金游数据运维主管
刘鑫 （gray1982） 宜搜科技 高级系统运维工程师
汪洋（yanyangtian4520） HP高级.net系统架构师
余洪春（yuhongchun） 易瑞特系统架构师、《构建高可用Linux服务器》作者
活动时间：2012.1.17-2012.2.17
活动要求：
1，针对本次话题可以提出疑问，答疑解惑。
2，分享此在线票务系统的架构经验，案例，解决方案。
讨论有奖：
活动结束后，我们会评选出三位积极参与话题讨论的网友奖励威刚 USB3.0 16GBU盘一个，对其他积极参与讨论的网友（回帖有参考价值）我们将奖励积分30分。
这个话题发的有意义，参与！ 如此之大的并发量和PV流量，建议采用开源架构,web应用服务器采用Nginx，数据库采用oracle RAC集群+IBM AIX 小机。 其实 这么大的流量，需要从前端，到后台 全部都要有优化，因为任何一点小的问题*上亿的PV，问题会被立刻放大 前端的负载可以考虑硬件
静态可以考虑CDN
后台的数据库非常的频繁，如果不考虑DB2，Oracle，只能选择Mysql的读写分离
而且，数据库前端的缓存不知道memcache集群会不会更好一些 本帖最后由 gotolinux 于 2012-01-17 16:32 编辑
虽然不知道这个系统开发了多长时间，但是从应用情况来看，总体感觉还是比较仓促。
做过政府项目的都知道，这是一个十分典型的政府网站。
网站上有大量图片，所以图片、CSS、JS等页面元素做好缓存是必须的。
网站上有大量的嵌套CSS，这个完全可以与页面框架分离，缓解网站前端访问压力。
这些页面元素可以根据不同城市的访问量而使用CDN，使用CDN有个好处，部署快，稳定，可靠性高。
现阶段……诶……我今天都没刷到票。 说实在的，我之前没有使用过12306，最近也是看到很多朋友放映12306不给力，我就看了下！
首先不说别的，页面本身就没有优化，请看下图
初略一看，就知道有问题：把样式嵌入在页面中
有朋友，或许认为这不是个问题，当是这其实就加大了页面的大小，消耗了带宽
我们把问题在深入一点点：如果每个页面大小70k，其中 这样的css嵌入 假设是1k。因为每次访问，浏览器需要下载页面，那么每次都要去下载这多余的1k的css样式，试想：上千万的pv去访问的时候，那么产生的流量就是1k*100，000，000,
也就说明：要多消耗服务器的这么多网络带宽！很要命，一点点的问题，就立刻被放大！
还不说别的 定票的那几天，一直登录不进12306，真是悲哀，系统忙得有票都买不到。直到1.13号才登录进去，买了2张票，不容易啊。 瓶颈应该在前端过多的、无效的查询上面。
Web服务器按区域部署
车次信息缓存，不直接从数据库查询，定时刷新余票信息。
订票请求排队，后台按订单次序批处理后返回结果给Web端缓存