从12306说起 建设高可用高并发网站何种服务器架构更合适？（获奖名单已公布）

xdsnet

我们解决问题一般要找到问题的根源，12306作为一个售票系统为什么同时有那么多链接？为什么没有12306时同样多的票也能在很短时间卖出去？
其实我们比较一下窗口（电话）买票和网站买票有什么差异可给我们提供一些解决的思路。
1. 窗口（电话）买票（下面就称为窗口买票）都是专人一进一出依次处理，很多个窗口可以同时处理（有限但还是很大的一个量，并发应该还是100W级），即并发有上限。也表明数据库查询实际上是能支持一个比较高的量的。
2. 窗口买票时用户提前知道几个车次备选，即有预查询，一些临时车次信息根据起至点可以快速查询（查询人员是专业人员）。如果查询和订票进行一定程度的分离还是可以实施的。
3. 窗口可以很快确定是否购买成功，及时出票。（付费途径便捷2分钟内左右完成，预订锁定——解锁确认完成，身份信息输入专人也很快）
4. 其他相关（飞机实现的是电子客票+登机换登机牌）
其实我认为影响网上购票比较麻烦的是购买环节中个人信息输入和付费两个步骤因为用户不熟悉和本身的繁琐造成效率低下，进而引发锁定时间过长（一定程度的阻塞）的雪崩效应，整体降低网站效率。

改进思路：
1. 分离查询与订票，查询可以分布并发，其实所有的数据购票瞬时信息完全可以做到内存数据库中读（拟静态的），支持很高的并发；
2. 订票流程排队限定链接数量（预排编号），一进一出；
3. 个人信息预先输入（订票前）；
4. 改进付费流程（实行预扣制），在查询时依据车次等级等预先完成，订票完成后根据实际情况扣除（这个其实不光是12306问题，还需要和网络支付等进行协调解决，而且是很大一个问题，也是解决关键）
5. 出票是否可能类似飞机的电子客票+换登车票（现场专门窗口处理，一种程度的分布处理）

InfoSVC

aindk 发表于 2012-03-21 22:53
个人认为
像开分店得思路估计无法解决，实时票务的问题，因为 开分店可以用来分摊高并发请求的需求，但是及 ...

    首先赞同目前的业务架构已经不是oralce或者db2这种关系型数据库单一可以解决的问题了,想想过年期间的哪个并发量,也绝不是单纯的堆叠服务器可以解决的.

    更多的要从软件架构本身来解决这些问题,oracle,服务器之类的只是实现这个架构的工具,但是这些工具本身都有他的局限性,所以在设计时应该要考虑这些问题.

    我本身不做系统架构设计,没有太多发言权了.

liuyxhello

wxxszzz 发表于 2012-03-21 22:08
一点愚见，作为中国的铁道部，现在遇到的问题，不是钱的问题，而是一个思路的问题，一个我们程序员写程序的 ...

预先生成车票不太可取。因为火车不是只有出发站和终点站的，一列从深圳到武汉的火车，有的人可能从深圳做到长沙就下了，有的人从长沙到武汉，这票你怎么生成？
按车次负载才是硬道理，因为不管怎么的，到买票那一步，车次是都是定了的。一点愚见。

spark8103

多开几家店，最简单了！将票放在不同的篮子里，热点地区，可以预先领号方式，阻止太多人临时抢入！

synchalt

参考百度？

renxiao2003

云？我看12306（铁道部）才真的要晕了。
花费好几亿，就搞出个这么个东西，出了错还要用户自己认倒霉（付了钱却出不了票），就这样的花费，这样的态度，不亏损就怪了。

InfoSVC

哈哈,我觉得这个帖子不再是说tdb的这个系统如何不给力,而且讨论一下改进的办法以及未来这种模式下设备的选择,架构的设定等等

send_linux

aindk 发表于 2012-03-21 22:53
个人认为
像开分店得思路估计无法解决，实时票务的问题，因为 开分店可以用来分摊高并发请求的需求，但是及 ...

那这个和硬件的关系不大么？比如是过去那种小型机的积极方案靠谱呢，还是现在的流量的x86集群靠谱呢？

wang290

marxn 发表于 2012-03-21 18:25
回复 3# wang290

是的，我想既然是全国范围的车票系统，分开每个局端是不可行的，还是需要中央集中处理，这样的架构设计是业务决定的，没有办法挑战了

taffy5366

在淘宝上开家店，省事方便