简单讨论火车票系统后面的架构设计 推荐

简单讨论火车票系统后面的架构设计

[有点晚了，简单写写，找时间再polish。另外，我们只谈技术。]

简单说，在线服务scalability有两种方式，scale-up和scale-out。Scale-up追求单机性能，如高级硬件、异步架构等，而scale-out则用加机器的方法。Scale-out也是最简单的方法，在规模不是非常大时很好用，也很容易解决问题，普通工程师就足以胜任。有很多现成的方法或模块可以使用。

也就是说，很多时候通过加机器就能解决大多数问题。只要规模在一定量级下（通常的在线系统规模都不会特别大），我们可以先不考虑硬件故障以及自动运维。

但为什么很多时候系统还是崩溃呢？罪魁祸首就是请求的尖峰，10倍于平常的压力是很正常的。普通模型到达性能瓶颈后，开始堆积请求（可能在web server，也可能在请求队列，不过通常不会在CDN），吞吐急剧下降，延迟急剧上升，而随着堆积请求越多，情况越糟，引起雪崩效应。而这样的压力通常不会持续很久，如果性能不急剧下降的话，一段时间后其实也就能把请求都响应了。

为10倍压力而准备机器是不合适的，我们需要有办法能扛住瞬间压力。这时候架构设计主要考虑的问题，也就是我上个weibo所说的，如何保证极限情况下的稳定吞吐。有很多种办法，分级队列、请求调度、延迟截断、主动拒绝等等，这些都有助于帮系统度过艰难时刻。具体的做法，就不在这里讨论了。

当然，我也并不是说这个系统是非常难做的，因为可以有很多种做法，如普通文艺、高级文艺等，:)。如何用软件架构的方法来实现scale-up就很困难，做得好与不好可能性能差异能达几倍到一个量级。但对于普通公司来说，直接scale-out是最合适的，规模不大时多一些机器也不会对成本产生太大影响。但关键的是，要注意如何处理峰值压力，提供极限情况下的稳定输出。也就是说对于普通在线系统，即那些transaction-based systems，规模不太大，只是可能有海量的用户请求。只要在设计时注意极限情况下的稳定输出就可以了，实现的工艺水平高不高，差别只是机器多少而已，通常看不出来。

对于大数据量的系统，无论在线或离线（其典型代表就是搜索引擎），则又是另外的故事了。

继续阅读：《再谈谈火车票系统》

【本文首发于：林仕鼎新浪轻微博】http://qing.weibo.com/2244218960/85c41050330009xm.html

【关注百度技术沙龙】