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

很多人没有仔细想过可能的业务，或者是基于技术的基础来讨论，没有立足点，怎么展开

1.如果放在内存中可以解决问题，那意味着当年的数据库可以根本考虑不要，nosql的出现，也是因为爬出搜索的需要，但也只是部分借用了内存的作用；
2.所有的讨论，是建立在铁路部门最早是有自己的一套核心的售票系统的，在没有12306之前，代售点就在网上卖票了，只是现在12306把代售点搬到了每个可以联网的PC上；
  因此，考虑票是以什么样方式来发售的，怎么样来保证查询票是有效的，这个实时性还是应该有的，不然让系统去排队，有什么意义；负载不能解决的，加前置机、加排队子系统一样无助于解决问题，只是把问题爆发的时间点往后延长了一点。

老兄说的是对的，因为我们队业务得确不熟悉，所以只能是基于技术的基础来讨论的

那售票点不也是系统中订票嘛。
直接给每个售票点的native系统开个Web，用售票点的入口买票。
可能系统的业务逻辑都不用改多少。

学习移动，将购票系统分配给各个省去做。

我也支持分省或者分车次的划分不同的数据库,不采用集中数据库的概念!!

简单的问题：
瓶颈在数据库么？

是的,目前以我自己的项目失败经验来的判断,大都数问题主要集中在数据库的IO层面导致系统访问缓慢(之前经历的2个全国性系统出现速度缓慢都是此原因造成的),当然了,不否认,和系统架构有关系,可以通过提高数据库的响应速度，而来快速响应用户的请求，二来减少更多的并发，因为只要数据库一慢，就会导致死循环，速度慢，并发越高。

因为目前的web层或者业务层可以通过负载均衡来实现,通过简单的增加应用服务器的数量可以解决此问题.

如有理解不对的地方,请指正.

个人以为问题就在这里，春运增加的服务器和带宽和其他等等设备，到了后期的365天有360天用不上，这些钱怎么办。如果不考虑利润，12306可以做的更好。
数据库的IO导致的负载增加，这个完全可以通过虚拟的内存盘来解决。成本很小

此问题目前无解，只能通过降低设备的成本来减少浪费了，或者租用第三方的云基础设施可以考虑！！！

baidu的一个架构师给出的一个方案。
对于一个理想的在线服务系统，应该包括几方面的能力。1) 单机高性能，也就是所谓的c10k能力。2) 良好的scalability。简单来说，就是加机器可以提升系统性能。3) 稳定输出，特别在极限情况下。4) 良好的自管理自运维能力，在故障、升级或扩容时尽量减少人工介入。

但是，并不是所有的服务都*需要*在以上4个方面做得很好，也不是所有的互联网公司都*有能力*在这4个方面做得很好，甚至很多工程师或架构师都没有*意识*到需要考虑这些方面。

所以，前一篇文章中我的建议是：

a) 可以先不考虑1，因为要提高单机性能难度很大，而效果却并不明显，通过加点机器即可取得同样效果。当然，作为一个old-fashioned engineer，我个人很喜欢做这样的事情。百度的快照库是我到百度后做的第一个系统，单机性能比旧系统提升了10倍以上。

b) 在业务不太复杂的情况下，加机器是最容易提升scalability的方法。我不了解具体的火车票业务模型，不太好讨论，但通常只要能把锁和正常的业务逻辑decouple，问题就不大了。谈到锁，多说两句。用它来保证的同步互斥，是并行系统中最基本的问题。有很多种做法，难度迥异。比如一些lock-free patterns，如果工程师的志向不在于此，不建议尝试。在实际中，按照我的review经验，只要能分解掉那把全局大锁，效果就很好了。

c) 最重要的是sustained throughput。在峰值压力情况下，平滑过渡，可以有效避免雪崩效应，大幅提升用户体验。我提了一些做法，很多朋友说这在通信系统中也是常用的。有兴趣的朋友也可以去研究一下queuing theory，看看latency和throughput是怎样的关系。

d) 在小规模时可以先不考虑自管理自运维能力。随着机群的扩展，故障处理、扩容减容以及服务调度等等逐渐成为最头疼的问题，而这正是分布式系统所要解决的最难的问题。对于大互联网公司来说，应该深有体会。

相对于普通的在线服务，搜索引擎的规模和复杂度要高出一到两个量级，很多考虑问题的出发点也不一样。习惯了这样的思考方式后，我也不太敢直接来设计一个火车票售票系统，over-design就麻烦了，呵呵。所以，以上根据系统的设计原则给出一些建议，希望有用。