主题：【原创】好吧，给一个铁道部订票系统的正确答案 -- 布老虎

搞的我都不好意思了，本来想坑掉都不行了。

========================================

简单说下我以前参与的那个系统：一个商品秒杀系统，每次来访问的用户人数都比较多，带宽与服务器的压力都很巨大。这个系统虽然设计实现的比较堍，但却管用。

当然我们的系统与铁道部订票的系统没法比，因为我们为了抗访问压力，将前面的业务逻辑尽量简化。

总结起来，对这类系统就是这么几点：

1. 不能追求完全的精确。任何一个抢购系统都会有些全局的资源，比如车票、座位、商品。要控制抢购的数量，不能超卖，这是起码的要求，但这个要求不能僵硬的执行。要做到实时数字的完全准确，就会对性能造成极大的影响，甚至会造成整个系统瘫痪。

2. 第一层抗访问压力的逻辑要简单再简单。用户来了，访问一个哈希表（我们用的Redis），看看这个用户有没有已经买过，if买过了就返回跳走，else没买过，就看下商品资源是否有货的标志，if没有货就返回卖光了的标志给客户，else恭喜成功记一条syslog出去。ok了，前面一层只有这点逻辑。

3. 尽量异步化。上面说了，前面记条日志就返回了，每个请求没有什么阻塞的时间。后台有个程序会把这些日志汇总到一个中心服务器里，那个中心的服务器会记录总数，并把信息写入到Redis的主库里。这样，整个抢购过程中，只有一个连接在写Reids，剩下的都是简单的读取。

总之，举重若轻，越是看上去困难复杂的问题，越要用简单的方法解决。当然，像美国医保网站那样复杂的系统搞5亿行代码，也是必须的。