主题：【原创】无责任推测12306网站遇到的麻烦 -- 代码ABC
家园 网上、电话、窗口都是分配的不同票额，互不相干。 网上不会把窗口的票也卖掉的。
但反过来，网上的票额到最后几天卖不掉会转到窗口去。
家园 晕，我没看错吧 几十万的小项目@#￥%&*（
生意是不大，一天一百多万笔交易……，不大，不大不大……？？？
可是有多少人在上面反复的查啊查啊查啊
“12306”网站在1月9日的日点击量达到14亿次
- 复 晕，我没看错吧
家园 这个次数的来历，应当是反复都进不去，进不去就不断刷新 这个次数的来历，应当是反复都进不去，进不去就不断刷新，每刷次一次就计算一次点击，按我自己的习惯，在十秒钟以后页面还不能读出，就会刷新重来。估计还有很多人的可忍受时间也相差不大。
- 复 晕，我没看错吧
家园 当然不大 交易量的话，你可以查一下淘宝在光棍节的交易量。
查询量大的情况有很多种解决办法，我用过的一个简易方法是主数据库定时归总和生成报表，之后的交易留在浅层数据服务器中的数据库和内存中，生成查询结果就在内存中完成，不动硬盘。用这种方法只要带宽和DNS跟得上，系统本身应付大流量查询不怎么吃力。
客票系统的查询有两个很大的优势，它不需要应付语义查询，没有定制路线的跨车次查询的任务。
家园 数据库部分甚为同意。 每台数据库服务器专门负责一组车次的数据，相互独立。每台机器各自备份查询报告可做成服务接口，供管理服务器调用即可。数据库部分做成这样，其负载是很小的，可控的。比如一台入门级服务器专门负责某天发车的某一车次，其数据量是很小的。可根据使用情况调节，比如某一车次所有未来N日内车票，或者几个车次的票。这样的小负载，就是普通入门级服务器+MYSQL数据库都很够用了。
数据部分解决后，就是商务逻辑服务器和WEB服务器集群的事了，也没有大的难题。DNS负载均衡服务器+多地点（分散带宽要求）的多个WEB服务器集群把流量分散到多个商务逻辑服务器集群，即可基本实现。
家园 素质！就不能注意一下素质？！ 抢抢抢。。。什么都是抢，不会排队啊，
能不能注意一下素质？铁道部网上售票，那就压根不是个需要高并发的东西，非得往这个方向考虑，是不是嫌回扣拿得少啊。
就弄个排队机，登录了就发个号，预估一下多长时间轮得上你买票，齐活
。再具体点，铁道部不差钱，东西南北方向分忙闲每个方向弄几个服务器，先选方向选票，然后扔到对应服务器上领号排队拉倒。
都琢磨着上网买东西，就得立等可取，这都谁惯出来的毛病，什么山唱什么歌，下个魔兽副本都得排队，买票回家这么大事儿还算啥啊，登录之后中间等待这段随你去干嘛，风不吹雨不打的，凡是有意见的大厅、代售点的干活
。家园 我的购票经历 本人在今天23点50分登录12306，10分钟内完成注册与订票业务，当然了定的是三十晚上的卧铺，没堵塞的体验，不知道其他人都什么时间段体验的。
家园 写了这么多就没提到cache，，，，， 家园 如果加点底层调优的料来更有美感。。。 不知道河里有大侠 经历过当年大陆“最强DBA团队” IBM EMC SUN/HDC的调优大战不
一举奠定了EMC在国内存储界的江湖地位 也给最牛DBA团队加了传说谈资哇
家园 没资料支持 Cache规划需要更多的假定，我手头没有任何资料帮我做这些假定。所以只是从最基本的东西推测。
另外，直觉上Cache对12306没什么帮助。
- 复 没资料支持
家园 想必阁下是男性，所以你的直觉很惨啊！ 除此之外我还可以确认，你没有网站架构/开发经验。
最近面试人的时候，我都会问一下怎么优化12306这样的网站，那些就一两年工作经验的人都知道要做好cache，虽然未必知道怎么优化，，，，
据说现在不少公司面试都会问类似问题
家园 应该说我很保守 一般只用直觉来规划验证问题的优先级。所以习惯使然让我只从最基本的层面——数据量，开始分析。实际上做优化的第一个步骤并不是考虑使用什么技术手段，而是首先收集数据，有了性能评估数据之后。也不是先考虑Cache之类的手段。而是确定系统瓶颈和产生的原因，所以我在没有任何这些资料的情况下写这篇东西的时候特意标明是“无责任推测”。
既然讲到了Cache，假设我主贴的分析是靠谱的话，我们来看看Cache能解决什么。在我的分析中，我隐约提到实际上瓶颈在于查询量过大，并且和订票查询在操作上有冲突。这种冲突最终导致对同一个车次的查询和订票实际不是并发操作。缓解这个冲突概率就可以提升整个系统的性能。所以12306通过放弃实时余票查询而构建一个汇总库专用于查询应该就是基于这个考虑，但不知为何还是没有解决问题。当然使用Cache技术缓存查询结构，同样能减少这种冲突。
既然12306的方法不能解决问题，那么应该还有我们尚未掌握的因素，排除他们的开发人员太傻这个因素，其他因素展开就太虚了。所以Cache不能解决问题的直觉来源于此。
我个人对Cache使用相对保守。其实Cache无处不在，操作系统有文件Cache，数据库有自己的Cache，Web服务器也有自己内部的Cache机制。我的第一选择一般是考虑如何利用好这些已有的Cache。
另外Cache也是有开销的。当数据时一成不变的话，比如车次数据我会考虑一次性读入内存的一个结构中。而那些有读写需求的数据则需谨慎考虑，因为实际上我们把冲突问题从数据库层面转移到内存里的数据结构上了，比如订票操作会修改查询结果，也就是使Cache下来的结果失效。如何通知结果失效呢？这里我们再次碰到冲突问题，还是要锁。那么我们就必须确认这个通知的开销要小于数据库访问的开销（事实上设计不好的Cache这个开销比企业级的数据库要大）。另外还有Cache的淘汰机制，Hash函数的冲突问题——如果使用Hash表的话，都是影响Cache选择的关键因素，没有背景数据支持，一般我不发表意见。
使用Cache的一个前提是从Cache中获取结果的速度远大于从数据库直接查询的速度。但是，在我经手的不多的几个大型系统中，我发现在数据量很大的时候，这点未必是真实的，因为数据库本身也是一个通用高效的cache。