satan 通过 Google 阅读器发送给您的内容：
缘起
这两天同事都在讨论12306的订票机制，据说要排队了。我不买火车票，所以只是大概听同事讲解了一下机制。如果不正确，希望大家告知我。我听到的机制大概是这样的。
首先，是每个人进去，正常购票。当碰到热门线路，在提交时进入不定时的排队。等排队结束，成功与否给与提示。铁道部称，这是为了能够减轻并发压力。
问题
如同老板说的那样，这个机制P都没解决。问题的关键在于系统的每秒负载能力，即每秒能够完成多少个transaction。只要来的人比能完成的transaction多。那只有几个结局：
- 刷爆网站，这是原来的结局。
- 堆在队列上，有人买不到票。
如果铁道部宣称的目的是真的的话，那他们一定用错了机制。
原因
铁道部这个系统的核心想法，是将并发的业务改为串行业务。即，前置一个订单系统，减轻核心的交易数据库的压力。实话说，这一定是没在互联网上混过的领导想出来的馊主意。
在通常业务系统里面，如果我们说一个核心交易组件有压力，那么最常用的办法就是排队。然而在互联网上却不能这么干，尤其是很多"非买不可"的系统里面，更不能让用户玩"排队"。因为对于互联网上的人，"分身"是再容易不过的事情了。使用多个浏览器，甚至开多虚拟机，普通人可以轻易的做到4-5个不同的会话。就算普通人做不到，看网络教程学是可以学出来的。每个会话订不同班次的火车。多开会话的结果，就是让队列的长度比原本会长上很多。这是一种级联效应。由于购票组件的处理速度有限，所以压力向前堆积，最终前面的排队系统也会被汹涌的客户（比原来大N倍）玩死。
机制
对此其实我很难想明白，为什么铁道部的核心交易系统有这么差的效率。有网友曾经说，系统要检查很多东西，要上锁——这都是假的。作为铁道部的核心交易系统，和铁道部内部的资讯检查有什么关系？他唯一要做的事情，就是检查是否真的有票，座位多少，有的话锁定一张（这个过程要排他）。
也许你会觉得，既然要排他，那么就需要用事务型数据库。目前数据库平均性能都是1k/s（我们就按照我们在普通台式机上的数据计算好了），而全国每秒成交的数量远大于这个值。这里出的问题？
这是不可能的。傻想也知道，每趟车和另一趟车没有耦合关系。按照车次做哈希，分布在多台服务器上交易就行了。这是典型的可并行系统，效率可以直接用单台机器性能乘以服务器数。在交换机允许的范围内，根本不会有交易性能压力。我们仔细审查铁路系统的结构，会发现，这东西天生就是分布交易的好材料。
- 部署一组服务器，每一台都部署同一套东西，接口按照REST开放。
- 将车次哈希后映射到具体的服务器上，所有的余票查询/订购，都向这台机器做请求。而核心服务器只要返回静态页面和车次信息就好。
- 单个服务器上的每秒transaction要求就不可能太高。
阴谋论
也许有些人会想，这个系统莫非是铁道部给内部留票做的？这又错了。要做内部留票，最简单的方法就是开打内部提前售票限制。只要这个限制一开，他们想留多少留多少，你一点脾气都没有。
结论
我只能归因于国有垄断企业在解决这类问题上的扯淡了，和私有企业没法比阿。建议对铁道部实行拆分。
可从此处完成的操作：
- 使用 Google 阅读器订阅shell's home
- 开始使用 Google 阅读器，轻松地与您喜爱的所有网站保持同步更新
没有评论:
发表评论