有人说12306.cn的并发是全世界最大，比Facebook，Google还大，我们姑且相信。但这不能成为操蛋体验的借口，网站崩溃的免死金牌。

并发大并不是第一天才知道，去年春运见识过了。那时候网站刚上线不久，还可以理解。9个月过去了，再来说事只能说明铁道部解决这个问题的无能。

我们作为用户，最容易的就是对这个体验吐槽，所有人都有权利这么做，也应该这么做，你不给他们压力，他们就当你愿意。12306的体验真心很糙。

作为技术产品人员，除了吐槽，对于解决并发问题，也提一些意见。这些意见都是在对铁道数据没有很深理解的前提下瞎聊的，所以可能有纰漏。但只要他们愿意开放数据，我相信很多人愿意给他提提专业意见。

把短时间的并发分散到长时间

并不是所有的技术问题一定要技术手段去解决。12306在节假日买票有高并发，其实完全可以引导用户不要在出行前几天再去买票。在主流节假日前可以考虑允许提早30天买票，越早买折扣越多。比如T-30天可以享受9折，T-X可以享受 9+(30-X)/30折扣。鼓励大家提早买票。把短时间的并发分散到这30天去，让系统瞬时负荷峰值尽可能的下降。我很看好这一点，对价格敏感的群众还能享受实惠。

不同线路使用不同的数据库

12306并发最大的问题可能是对于票务资源的锁定。所以最简单的方法就是打散对票务资源的锁定；让不同的线路使用不同的数据库服务器。如果所有的线路只有一个中央数据库，那你怎么做都是崩溃。

繁忙线路的票务资源分块

简单而言，从上海到北京的线路共1000张票，10000个人同时抢，大家都访问一个数据库，这个数据库很容易崩溃。所以，还是要把这个数据库切分 – 很多不同的做法，多个车厢可以有自己的数据库服务器；或者动态分配部分资源到指定服务器，然后动态引导流量到该服务器；不要锁表，锁行；等等。这点，很多数据库专家可以插插嘴。

读写分开，尽可能的限制写

尤其对于读，完全可以用单独的读数据库，上面可以做memcache，local cache来显示票务信息。对于写，只有在用户选定了一个车次信息，真的决定买的时候，再去访问可写的数据库。

借用云服务

12306的特点是一到节假日，资源耗用特别高，平时要小很多。这种特点不适合自己配备所有的服务器。可以考虑租用其他的云服务器，阿里云，百度云，铁道部出马他们应该会热烈欢迎合作滴。

尽可能的把计算推到用户的浏览器端

考察一下典型的用户使用方式，把查找车次，时间的功能推到用户端。比如，如3而言，如果北京到上海的票务信息，即使是不同的日期，都在一个数据库上； 那可以考虑在查一个日期的时候（记得日期列要加index哦）顺便把左右2天的都给找出来。select … where T=X 和seleect … where T=X or T=X-1 or T=X+1对数据库的资源消耗是没有什么区别的。

最后还是吐槽一点，就算现在用了很低俗的用户排队方法！

排到之后给人发短信通知，不要期待大家盯着屏幕啊！有没有，至少在窗口排队的时候到了我没反应窗口大妈还会吼我滴！

（ @王淮 博客原文 ）

作者新书《打造Facebook——亲历Facebook爆发的五年》正在热卖