最近网上流行转载了一篇文章，用来表达12306系统架构有多复杂的。

里面引用了一些非技术数据用来强调自己的观点。

下面我以技术的角度，一步一步分析12306网站的用户规模与网站业务逻辑的情况，以帮助大家进一步分析12306网站到底架构有多难。

1、首先我们可以分析的是春运火车网的购票人次。

根据我国2013年12月发布的流动人口数据约有2.3亿人口。

详细见：http://www.chinanews.com/gn/2013/12-10/5600343.shtml

假设每天有5%的人访问12306，那么相应的每天的IP应该是2.3 * 0.05 = 0.115亿的独立访问。

假设春运期每天的访问是40%, 那么相应的每天的IP应该是2.3 * 0.4 = 0.92亿的独立访问。

假设人均PV是10, 那么相当于一天9亿的PV。

根据上公布的资料

http://www.zhihu.com/question/20016026

16,941,420 实际只有 2千万就左右的PV。即使峰值是10倍也只有2亿。

那么我们折中一下，将PV换成是峰值5亿好了，谷值是1千万。

对于这样一个系统，最重要的就是如何动态的均衡压力。

忙时可以租用更多的运算服务器，闲时可以释放。

一般来讲分布式架构设计完成后，一定是会有一定的scale能力的。这个通过加机器减少机器就可以解决。这种技术各大网站都已经非常成熟了。

2、订票的业务模型。

由于用户，买票，支付部分跟支付宝、淘宝之类是一样的，我就不多说了。

我们主要分析一下他们的业务逻辑是不是很复杂。

有人提出来火车票的购买是一个动态的过程，我们就按动态的来看。

a) 首先，我们假设有N次火车，每节火车有M个位置,有N个站点，

每次火车可以每天发X趟，那么对于每一个时段发放的车都产生一张表， 分别是M行和N列的。

当用户查询某列车是不是还有票时，只要查询一下对应的位置是不是连续空的就可以了。

b）然后再制作一张车票票价的表供查询，就可以生成了出发地到目的地的一张火车票的票价了。

c)然后当用户完成订票时，将这些经过的站点全部占上。

实际上并没有多少动态性在里面，无非是查询，而这种查询实际上还可以做进一步的优化。即使不优化，他的查询性能也是非常好的。

b)

考虑用户退票，实际上也是一样的。

无非是将那个时间的表上的用户占的站点清空。这样下一个用户就能查到他的位置空了。

对于所有订票网站说订票过程都是动态的，所有的订票业务大同小异，除了铁路站点多点以外，根本没有什么特殊性。

d)再考虑到将不同的车次的订票系统分布到不同的服务器，或者不同的表中，实际上对于一台要处理的服务器，只需要处理几个线路就可以了。

根本不存在什么复杂系统的问题，什么不可拆分的问题。

e)

任何复杂系统都是通过不断的简化模型，来实现低耦合，高内聚的。

这里最多弄个排列与消息系统，来处理用户请求排队的问题。然后通过消息机制来通知用户成功或者失败。

从本身的模型上来讲，不存在什么过于复杂的情况。

3、那么通过我们的分析我们可以看出来：

文章：http://www.zhihu.com/question/22451397

所说的东西很多是虚假的。

拿什么多大的内存，多大的公司出来吓人，并没有真正的合理的技术分析。

有技术分析的地方也是问题很多。

但是从营销的角度，这个文章成功了，我相信12306背后一定使了不少力。

下面我们来看看错误的技术分析：

1、以前12306用的是小型机，发现性能严重不足，遂改用x86系统+linux平台

小型机的情况比PC差？这个是有常识的表现吗？

用X86无非是分布压力，跟什么小型机没有半点关系。

原来以为一台小型机能解决，后来发现小型机一台的运算能力是有限的。我估计只能是这种可能性。

2、通知全站.

任何一个复杂的系统设计的目标就是内聚，小型化，他还叫嚣通知全站，这个全站是谁？

为什么要通知全站，难道我买了一张火车票要上电视通知全国吗？ 如果12306做的事情是将事情复杂化，那么只能表达自己有多弱智，而是不能说明这个业务有多复杂。

作为一个Alexa排名只有77，业务形态非常固定的铁道订票系统的网站，叫嚣自己技术多么复杂，是一件很无聊的事情。

实际上12306网站的演变过程只不过是互联网公司架构升级的过程，没有任何所谓的业务复杂的因素，只能说一开始12306一开始的架构能力是很差的。

仅此而已，但是从系统的发展来说，我不会苛求12306，但是要说12306有多高的技术含量，我只能对写这个文章的人表示“呵呵”