主题：【原创】无责任推测12306网站遇到的麻烦 -- 代码ABC

目前库里有多少是多少， select 的条件从句可以简单很多很多。

当天售票/余额汇总以后如果计划部门重新分配长短途票额的话，那还是今天没有就是没有，明天有的是新的。

不用搞动态资源分配，算法/架构可以数量级的简单

貌似原贴估计大了不止一个量级。这些天总共才通过网络卖出300万张票。这个系统设计还真是个.......怎么说呢，太不中用了。

另外，注册用户1000万，出300万的票。这不是白找700万人来骂自己吗？还是我又搞错了新闻来源。

Cache规划需要更多的假定，我手头没有任何资料帮我做这些假定。所以只是从最基本的东西推测。

另外，直觉上Cache对12306没什么帮助。

根本原因是铁路内网只给12306放了300万张票吧

春运这个情况，查询量不知会翻多少倍.

你看河里有多少人说“刷”票

我主贴里也是把查询作为主要负担来考虑的。我是觉得这个票额不合理加大了系统的负担。如果能大致满足注册用户的购票需求，其实系统负担至少可以下降一半。大部分人买完票之后就不会再刷页面了，这类无谓增加的流量估计占去一半以上（可能远远不止）。

所以其实这里可能存在一个优化系统的方案，其效果远远超过技术改造。

本人在今天23点50分登录12306，10分钟内完成注册与订票业务，当然了定的是三十晚上的卧铺，没堵塞的体验，不知道其他人都什么时间段体验的。

以目前的情况来看，这是不可能的。没那么多票给你。

所以目前系统必须承受不成比例地高的查询量

抢抢抢。。。什么都是抢，不会排队啊，能不能注意一下素质？

铁道部网上售票，那就压根不是个需要高并发的东西，非得往这个方向考虑，是不是嫌回扣拿得少啊。

就弄个排队机，登录了就发个号，预估一下多长时间轮得上你买票，齐活。

再具体点，铁道部不差钱，东西南北方向分忙闲每个方向弄几个服务器，先选方向选票，然后扔到对应服务器上领号排队拉倒。

都琢磨着上网买东西，就得立等可取，这都谁惯出来的毛病，什么山唱什么歌，下个魔兽副本都得排队，买票回家这么大事儿还算啥啊，登录之后中间等待这段随你去干嘛，风不吹雨不打的，凡是有意见的大厅、代售点的干活。

春运售票系统的商务逻辑是很简单的：买卖行为统一；库存可预设；退货量小...... 需要解决的不过就是访问量大而已。

当然你非要先做一个淘宝出来，再拿它来卖春运票那也随你----估计铁道部的猪头们就是这么指挥的，而且指不定实现的时候还把数据生成文本自己写代码根据磁轨访问。

像这样只卖一样货的系统我见过印度人是怎么干的，他们的做法符合KISS规则，干净利落：

1.每天夜里留出半个小时做数据库维护和报表生成。

2.绝不做multiple middle layer servers × multiple synchronized databases 的蠢事。大访问量用多个商务逻辑服务器解决，数据库那边最小数据单元为某一次车次在两个相邻车站间的某一座位，即车票为数据单元的组合。纵向拆分数据，每台数据库服务器专门负责一组车次的数据，相互独立。每台机器各自备份，各自生成查询报告。

3.退票、划票、屏蔽/新增/调拨车次的数据用独立的数据库服务器完成，相关逻辑在中间层hardcode。

这么做应该是一个几十万元的小项目。

另外我觉得网上订春运票虽有利于维稳，却有损于社会公平。能够轻松在网上搞定这件事的人看着那些在寒风冷雨中排队的苦哈哈们，多少会带着轻视的目光，而后者心中则难免委屈或恨意。

不知道河里有大侠 经历过当年大陆“最强DBA团队” IBM EMC SUN/HDC的调优大战不

一举奠定了EMC在国内存储界的江湖地位 也给最牛DBA团队加了传说谈资哇

除此之外我还可以确认，你没有网站架构/开发经验。

最近面试人的时候，我都会问一下怎么优化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。

你提出系统瓶颈是查询量太大，这点是基本正确的，但是你的解决方法完全是拍脑袋的，南辕北辙，没有经过实践检验的。

其实业界对于这种问题是有成熟解决方案的，河里的西电鲁丁就发了不少大型网站的架构分析，你可以参考一下。

ipad输入不方便，回头我再说说为什么用cache能降低数据库负荷，以及怎么用。

从06年或更早，阿里集团就考虑。去年现在有了实际的进展，具体就不说了，哈哈！