关于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.将所有查询结果缓存化，静态化
首先明确一下查询的步骤，实际上主要查询分两步
第一步是查询符合要求的车次，第二步是查询余票。
缓存也就分两步做，起始地，目标地查询 - 常见查询目标（如北京到成都）全部预制缓存。非常见查询目标，基于第一次查询的结果缓存，这样查询车次基本上无压力。
评论