对于网上购票系统12306，如果你是架构师，你会怎么办？

隔壁帖子的老兄说，我们都不了解铁道部订票网站的业务多复杂，就别在给他们出方案了，他们一律表示不屑！

不是给他们提的，·引以为戒，怎么在自己的系统不犯这种错误。

数据存储两份，一份在数据库，一份到nosql中，如redis，一次写两份。查询和锁票先在nosql中做，成功了在进入数据库后续操作。把无效操作从数据库弄出去，降低锁消耗；同时把大量查询和抢票操作在nosql中完成，nosql效率高的一塌糊涂。。。

真正拿到票的人没多少，一天不就那么多票嘛，数据库分拆下慢慢服务就ok了。

楼主同志，你说的这些在网上随便一搜一大堆的方案啊。这些没有用，起不了关键作用。你要先了解铁路订票的业务以后才有资格说话。
订票这套业务肯定比你我想的都要复杂的多。

"订票这套业务肯定比你我想的都要复杂的多"多么冠冕堂皇的理由啊，有了这个理由，你说啥都没用！

一句话，你们地球人的智商是做不了这个系统的！

我觉得应该这样做：让铁道部写需求文档，各位大神集思广益免费给铁道部设计个系统，以服务社会。

售票有什么复杂的？查询车次可以分开，甚至用varnish直接代理缓存了是不是？

每个车票，余量等实时数据，可以根据车次完美的分拆，是不是？基本固定的东西，用redis，用memcached都可以做的很不错，是不是？

对于没有完美事务的nosql和缓存，差几个人进入后续订票，数据库二次校验下提示他失败就行了。

车次可以分散开，票可以提前分配好，事务可以完美的分解成每张票的行锁，互不干涉。

唯一的业务复杂就是中间有很多站，要分区卖。这其实也很容易解决，好比这样：

1. 数据库预存储1张票 北京->上海

2. 用户A锁定此票，但选择是 济南->南京

3. OK， 把这张票的行程记录为 济南->南京，出票给他。

4. 系统自动在插入2张新票可用：北京->济南 ， 南京 >上海

5. 等待其他用户购买。

看，每张票都是完美的行锁，并发什么的有什么影响。程序只要发现有锁，不用等待，直接告诉用户票已经卖掉，或者继续寻找下一个没有加锁的票。

支持“你们地球人的智商是做不了这个系统的！”

我要是负责人，那我干脆把车票架在淘宝上买！费力不讨好，花了几千万！
铁道部的人可以找淘宝的团队，真不知道他们怎么想的！

你说得对啊，但是作为行业从业人员，可以探讨下，