12306.cn铁路网购系统十宗罪
- 无法支持大规模并发！！
- 从去年上线到现在一直无法支持大规模并发！！！
（这9个多月在干嘛！）
最最重要的sharding，caching，compressing，clustering，cdn等等都做了吗？
- 界面极操，完全不懂得应用ajax来时间局部页面更新
no longer valid - 只支持IE （据网友说可以用chrome，safari了，我四个月前mac chrome不行）
- 不能直接打印车票
- 不能选座位
- 使用的安全证书竟然不是有效的
- 竟然不是https
- 票丢失补办后竟然要先购买一张。。。不能直接作废之前那张吗？？？
- 开发费用极高；怀疑是用火星人的工资请了朝鲜人来写的程序
给12306.cn改善并发的7点建议
有人说12306.cn的并发是全世界最大，比Facebook，Google还大，我们姑且相信。但这不能成为操蛋体验的借口，网站崩溃的免死金牌。
并发大并不是第一天才知道，去年春运见识过了。那时候网站刚上线不久，还可以理解。9个月过去了，再来说事只能说明铁道部解决这个问题的无能。
我们作为用户，最容易的就是对这个体验吐槽，所有人都有权利这么做，也应该这么做，你不给他们压力，他们就当你愿意。12306的体验真心很糙。
作为技术产品人员，除了吐槽，对于解决并发问题，也提一些意见。这些意见都是在对铁道数据没有很深理解的前提下瞎聊的，所以可能有纰漏。但只要他们愿意开放数据，我相信很多人愿意给他提提专业意见。
1- 把短时间的并发分散到长时间
并不是所有的技术问题一定要技术手段去解决。12306在节假日买票有高并发，其实完全可以引导用户不要在出行前几天再去买票。在主流节假日前可以考虑允许提早30天买票，越早买折扣越多。比如T-30天可以享受9折，T-X可以享受 9+(30-X)/30折扣。鼓励大家提早买票。把短时间的并发分散到这30天去，让系统瞬时负荷峰值尽可能的下降。我很看好这一点，对价格敏感的群众还能享受实惠。
2- 不同线路使用不同的数据库
12306并发最大的问题可能是对于票务资源的锁定。所以最简单的方法就是打散对票务资源的锁定；让不同的线路使用不同的数据库服务器。如果所有的线路只有一个中央数据库，那你怎么做都是崩溃。
3- 繁忙线路的票务资源分块
简单而言，从上海到北京的线路共1000张票，10000个人同时抢，大家都访问一个数据库，这个数据库很容易崩溃。所以，还是要把这个数据库切分 - 很多不同的做法，多个车厢可以有自己的数据库服务器；或者动态分配部分资源到指定服务器，然后动态引导流量到该服务器；不要锁表，锁行；等等。这点，很多数据库专家可以插插嘴。
4- 读写分开，尽可能的限制写
尤其对于读，完全可以用单独的读数据库，上面可以做memcache，local cache来显示票务信息。对于写，只有在用户选定了一个车次信息，真的决定买的时候，再去访问可写的数据库。
5- 借用云服务
12306的特点是一到节假日，资源耗用特别高，平时要小很多。这种特点不适合自己配备所有的服务器。可以考虑租用其他的云服务器，阿里云，百度云，铁道部出马他们应该会热烈欢迎合作滴。
6- 尽可能的把计算推到用户的浏览器端
考察一下典型的用户使用方式，把查找车次，时间的功能推到用户端。比如，如3而言，如果北京到上海的票务信息，即使是不同的日期，都在一个数据库上； 那可以考虑在查一个日期的时候（记得日期列要加index哦）顺便把左右2天的都给找出来。select … where T=X 和seleect … where T=X or T=X-1 or T=X+1对数据库的资源消耗是没有什么区别的。
7- 最后还是吐槽一点，就算现在用了很低俗的用户排队方法！排到之后给人发短信通知，不要期待大家盯着屏幕啊！有没有，至少在窗口排队的时候到了我没反应窗口大妈还会吼我滴！
