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

一般只用直觉来规划验证问题的优先级。所以习惯使然让我只从最基本的层面——数据量，开始分析。实际上做优化的第一个步骤并不是考虑使用什么技术手段，而是首先收集数据，有了性能评估数据之后。也不是先考虑Cache之类的手段。而是确定系统瓶颈和产生的原因，所以我在没有任何这些资料的情况下写这篇东西的时候特意标明是“无责任推测”。

既然讲到了Cache，假设我主贴的分析是靠谱的话，我们来看看Cache能解决什么。在我的分析中，我隐约提到实际上瓶颈在于查询量过大，并且和订票查询在操作上有冲突。这种冲突最终导致对同一个车次的查询和订票实际不是并发操作。缓解这个冲突概率就可以提升整个系统的性能。所以12306通过放弃实时余票查询而构建一个汇总库专用于查询应该就是基于这个考虑，但不知为何还是没有解决问题。当然使用Cache技术缓存查询结构，同样能减少这种冲突。

既然12306的方法不能解决问题，那么应该还有我们尚未掌握的因素，排除他们的开发人员太傻这个因素，其他因素展开就太虚了。所以Cache不能解决问题的直觉来源于此。

我个人对Cache使用相对保守。其实Cache无处不在，操作系统有文件Cache，数据库有自己的Cache，Web服务器也有自己内部的Cache机制。我的第一选择一般是考虑如何利用好这些已有的Cache。

另外Cache也是有开销的。当数据时一成不变的话，比如车次数据我会考虑一次性读入内存的一个结构中。而那些有读写需求的数据则需谨慎考虑，因为实际上我们把冲突问题从数据库层面转移到内存里的数据结构上了，比如订票操作会修改查询结果，也就是使Cache下来的结果失效。如何通知结果失效呢？这里我们再次碰到冲突问题，还是要锁。那么我们就必须确认这个通知的开销要小于数据库访问的开销（事实上设计不好的Cache这个开销比企业级的数据库要大）。另外还有Cache的淘汰机制，Hash函数的冲突问题——如果使用Hash表的话，都是影响Cache选择的关键因素，没有背景数据支持，一般我不发表意见。

使用Cache的一个前提是从Cache中获取结果的速度远大于从数据库直接查询的速度。但是，在我经手的不多的几个大型系统中，我发现在数据量很大的时候，这点未必是真实的，因为数据库本身也是一个通用高效的cache。