关于12306网站和清华某院长的微博言论，我做了一个小回复，说这玩意不难，2个人2周，40台服务器可以搞定。

    下面详细解释一下大概的思路。免费share一下，看看靠谱不靠谱。

    别人看到的是流量，我先看结构，这里的数据结构是相当简单的，主要满足的需求是

    1.车次查询(最常见的是起点站，终点站查询 和车次直接输入查询)+余票显示

    所谓的用户刷页面，绝大部分应该在这里。日均10亿pv(这个数字我先质疑一下，不过么关系，后面再说怎么处理)，估计主要落在这个查询上。

    2.注册，登陆。每天过千万人次是有的

    3.下单，也就是日成交订单量，可能存在下单失败，约几百万次。

    这里基本不涉及复杂的关系操作，不涉及推拉结构，和新浪微博，facebook这样的应用场景相比，在数据关系上简直毫无难度，这也才是我敢说大话的原因。

    因为不涉及复杂的关系操作，不涉及个性展示(不同用户搜索同样的条件，结果一致)，那么缓存化就是最佳途径。

    1.存储key-value化, 推荐redis

    基本上查询都是直线式的，所以key-value就是很好的工具；因为出票可能需要找一下车次，座位，只能一一对应的查询就不好用；弄个redis带个列表结构(dict or zset ，哪个结构更合适？问问新浪架构师杨卫华吧，这事估计对他太简单了)进去就可以了。春节放票总共多少张?又不是一次放出来，每张票对应一个key，一个value，能吃多少内存？后面跟个数据库做同步，这点数据量对于现在的服务器来说根本不是问题。

    注册登陆也可以在 mysql基础上弄个redis挂在前头响应，这种查询速度，biu.

    根据不同车次分几台服务器，响应速度根本不是问题。

    2.将所有查询结果缓存化，静态化

    首先明确一下查询的步骤，实际上主要查询分两步

    第一步是查询符合要求的车次，第二步是查询余票。

    缓存也就分两步做，起始地，目标地查询 - 常见查询目标(如北京到成都)全部预制缓存。非常见查询目标，基于第一次查询的结果缓存，这样查询车次基本上无压力。

    查询有票状态就更简单了，因为票数只有有票，无票两个状态，某日某车次作为一个key-value类型存储(仍用redis即可)。某类车票发生从有到无或从无到有的变化，才通知缓存更新。更新是后台通知的，而非基于用户查询。比如某车次硬卧票售完，通知一次更新，硬座售完，通知一次更新，软座售完，通知一次更新。以此类推，这样的缓存更新次数极少。而且可以给前端返回甚至静态结果(基于查询条件生成静态结果，是个Seoer都会的，后台在票数变化时通知更新，这样结构上就与前端查询无关了，而且一样可以保持实时性)。

    如果你较真说，其实一个车次在不同区间也存在有无票的不同，的确，不过按照同样思路，结构多做一层死不了人的。毕竟这只是概述。但是核心思路不变，缓存的变更次数远少于查询请求次数，这就够了。

    3.前端缓存处理

    很多人被10亿请求数吓到了，其实这里水分很大，最多的是重复刷新和外挂工具，那么如果你做到基于2的查询结果缓存化，这一步就简单了;直接参见这个文章 http://blog.sina.com.cn/s/blog_466c66400100bi2y.html  大量的用户重复刷新根本不是问题。 想知道实际效果，看这里 http://blog.sina.com.cn/s/blog_466c66400100cfrj.html 1小时20亿的刷新都不怕，还怕你一天10亿刷新？

    4.i/o优化

    其实我甚至觉得用了redis都不需要做i/o优化了，如果用户单据需要数据库保存，一天200万单嘛，搜一下 淘宝技术专家余锋分享的qcon讲座文档，顺便读一下他历来新浪微博分享的文字，这个需求简直就是小儿科了。 大不了狠狠心买几块ssd硬盘做raid1/0，对于我这样的穷架构师来说，都属于大手笔了，至于昂贵的fusion-io，我真觉得，这个场景用不着，实在用不着。

    这里关键点，是查询结果的静态化和前段缓存的利用

    查询怎么可能静态化？

    因为

    1：重复查询的频度远远大于数据更新的频度(即便是票数的更新，也是500:1，更不用说是有无的变化)

    2：静态化不代表不动态更新，在订票成功后，如果发生了票数状态的改变(是状态改变，而不是数字改变)，服务端更新或删除该静态结果(下一次查询重新生成静态结果)

    至于为什么说2人2周，别搞花的，别图好看，就把这些结构捋清楚，代码能有多少行？这玩意没什么工作量。

    此外，有人说，你肯定没考虑神马神马神马神马；您说对了，我还真没考虑这么多，毕竟铁道部没给我1000多万，不过真要是给了我1000多万，我用三天时间考虑清楚，肯定比这不到1个小时整理的东西详细，您觉得呢，剩下一周半干活足够完工了。

建议继续学习：

1. 由12306.cn谈谈网站性能技术    (阅读：5058)
2. 用 redis 实现和保护 12306    (阅读：4526)
3. 铁路订票系统的简单设计    (阅读：4169)
4. 关于 12306 网站设计的一点信息收集    (阅读：3966)