再谈谈火车票系统
昨天那篇weibo发后，收到很多反馈。有很多朋友给了正面评价，非常感谢。也有些亲给了差评，这本无可厚非，只是其中有些人我感觉都没仔细看文章，时有露怯。也有人怀疑我只会说，没写过程序。我不想自吹，在十几年的程序和研究生涯里，几乎所有名字中含system字样的系统我都亲手做过。到百度做了几个实际系统后，负责了更多事情，这才转为设计规划，不再事必躬亲。
令人反感的是，有人说我拿了黑钱，这纯属无稽之谈。
还有些朋友给了一些非技术层面的建议，也非常感谢。我也知道这些问题所在，也考虑过用产品设计的方法来避免。之所以还来讨论，只不过是想借这个系统谈谈架构设计的一些看法。本人一向喜欢风花雪月，不想凑热闹不好为人师。只是恰好碰上自己的专业领域，这才斗胆来碰这么热门的事件。
我再阐述一下我的观点。这个系统的复杂度在于海量的并发请求，并发性可以通过scale-out（简单来说，就是堆机器）加以解决，但最难的却是保证系统的稳定吞吐。我想说明的是，在线系统应以保证极限情况下的稳定输出（sustained throughput）为首要设计目标，而这是不容易实现的。至于如何切分数据，如何scale-out，这和具体业务特点关系密切，在不知道火车售票具体业务模型的情况下，不好进行讨论。
对于一个理想的在线服务系统，应该包括几方面的能力。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就麻烦了，呵呵。所以，以上根据系统的设计原则给出一些建议，希望有用。
【本文首发于：林仕鼎新浪轻微博】http://qing.weibo.com/2244218960/85c4105033000a3v.html
【
关注百度技术沙龙】
本文转自百度技术51CTO博客，原文链接：http://blog.51cto.com/baidutech/763031
，如需转载请自行联系原作者