写在开头的话：技术总是在不断质疑中进步（改编自：质疑是科学研究不断前进的动力）
原文地址：
1、http://blog.itpub.net/69923331/viewspace-2662964/
2、https://zhuanlan.zhihu.com/p/91934639
LVS+Nginx 这套架构是普遍流行的，成熟的架构，变种有：F5+Nginx， 个人觉得F5+Nginx比LVS+Nginx好，因为硬件分流比软件更稳定，性能更高。其实LVS+Nginx是我们这种小成本网站用的。
订单流程的核心是数据库的性能，12306用的是内存数据库，性能应该已经提升到了极致。
架构图中前置了MQ消息队列，这应该是削峰作用，防止数据库崩溃的手段，日常应该没有太多作用；MQ是异步的，会产生数据库的事务问题，因此架构里面着重要解释如何解决一致性的问题。
文中解释MQ属于业务定制的缓存，也就是MQ会汇总请求，统一进行订单处理，只把结果写入数据库中。因此MQ属于一个超级业务缓存，只把结果存入数据库中，这样就解决了一致性的问题。同时文中还进行了延申说明，MQ是可以并行部署的，没有性能问题。
现在看起来这个架构是一套高性能的成熟的架构，除了一些微小的无关痛痒的瑕疵。
文中并没有对查票业务进行说明，我个人认为查票业务应该比这个部分重要，理由有两点：1、大部分用户会反复查票，查票的性能要求更高，更能给用户好的体验；2、中介机构的刷票业务才是影响性能的重点，也是常常造成崩溃的原因。
查票里面的难点是需要进行路线计算，这个过程可以分为两个步骤：首先查询出路线，其次需要和座位数量匹配，筛选出有效的路线。从目前使用看来，这个部分性能还不够，应该是业务的分离程度不够的原因。
最后总结：这个架构里面不清晰的两个地方，MQ和查票两个模块，大部分业务都在这里，应该着重设计细化的地方。个人觉得查票是非常影响用户体验的，官方应该继续努力把这个模块优化好。
查票业务有一个核心就是状态传递是单向的，不需要设计锁来实现状态的更新，因此查票业务是可以做到性能极高，再配合IP反刷票机制，系统不会崩溃。
