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

send_linux

获奖名单已公布，详情请看：http://bbs.chinaunix.net/thread-3718970-1-1.html

话题背景：

2012年年初，全国范围的春运网络购票，使得12306这个网站出现在普通公众的事业之内，春运旅客购买火车票的强力需求，对12306这个新生的电子商务网站带来了大量的并发需求，12306网站在这次高可用高并发的需求面前并没有做到最好。

在此之后，铁道部曾召开研讨会，邀请相关公司如支付宝、淘宝、百度及一些证券公司，研讨下一代网上售票系统。据消息人士透露，该研讨会主要集中于数据安全、便捷支付以及如何应对突发的访问量、保证服务器稳定等问题。另外由于铁道部全国有多个分局，在12306的购票数据实时同步方面，容易出现一些问题，所以铁道部在研讨会上也在考虑做中央主机集中处理的方案。那么12306网站的问题究竟出在哪里？目前哪种流行的服务器架构解决方案能有效解决这些问题？云技术？LAMP集群？还是小型机技术？一时众说纷纭。

今天我们特邀ChinaUnix社区，服务器架构选型方面的嘉宾参与本次在线话题讨论，他们分别是：

AIX版块版主：InfoSVC
集群和高可用版主：kns1024wh
架构设计版版主：yanyangtian4502


讨论话题：

目前12306网站在面向用户服务的过程中主要存在哪些问题，哪些是由服务器架构方面导致的？
大型高并发高性能网站的服务器究竟该如何部署才能保持可用性和安全性？
云计算、自建X86 LAMP服务器集群、Power小型机，多种服务器平台哪一种会更适用于大型高并发高性能网站架构呢？

欢迎大家就以上话题积极发表自己的见解，参与我们的话题讨论！

讨论时间：

2012年3月21日-4月11日

奖项设置：

最佳点评奖：2名，奖励价值200元的礼品一份（CamelBak不锈钢双层保温水壶）

精彩点评奖：5名，奖励价值100元的礼品一份（CamelBak0.75升 驼峰水壶）



参与奖：10名，奖励Power中国用户组社区（ChinaUnix）积分50分

wxxszzz

一点愚见，作为中国的铁道部，现在遇到的问题，不是钱的问题，而是一个思路的问题，一个我们程序员写程序的思路问题。
我们都知道一台电脑，不管是PC，PC服务器，小型机，他都有一个在一定时间内并发连接的极限，

PC一秒内极限可能是1万个连接，PC服务器一秒内处理连接可能是10万，小型机可能是100万个，但这些不能解决问题，因为中国人太多了，都集中在一起去买票了。

我是写程序的，现在写的不多了。我不知道买票的程序是怎样写的，但我想提供一个思路给大家。
想来应该是卖出去一张票添加一条记录到数据库里去，一张票代表数据库里的一个记录。

我想说的是把卖票的记录提前预前写到数据库里去，相当于是预先做车票，

如果全中国在七天长假总共有1亿张票，那么就预先生成1亿张票的记录，按照地区的分类，
在不忙的时候，大概平均的分布到100台数据库服务里去卖票，节假日，分到1000台数据库服务器里去。

至于前端的WEB服务器可以是100台，也可以是1000台，都是一样卖票程序，按照地区的分类，选择数据库卖票。这个就相当于是超市的收银台，客户多嘛就多开点窗口。
当然前面可以加个导购小姐的服务器。减少客户选择时间。

当然如果用PC台数会很多，用小型机可以少点。

当然还有很多细节问题需要考虑，但这是一个可以无限制扩容的方法，因为他不需要一个中央调度。把没卖出去的票预先生成而已。

这个思路应该可以解决铁道部的问题，不就是多买点电脑嘛，小事，现在科技含量高的都在跌价。

唯一需要做的好一点的就是生成车票的记录不要搞错了。要写的好一点。

就象是
车票库1-收银台1
车票库2-收银台2
车票库3-收银台3
车票库4-收银台4
车票库5-收银台5
车票库6-收银台6
无限制的加，总归可以满足我们中国人集中买票的

啊，写到这里，感觉铁道部就是一个巨无霸的网上超市。商品只有一样车票。

其实铁道部的卖票平台，成熟的已经应用的，就是淘宝最接近了。也可以达到铁道部的要求。

如果把淘宝比作铁道部，那么就是节假日，开10000家淘宝店卖票，平时开5000家淘宝店卖票。

OK,不知道大家觉得如何。 先生成车票，再卖票，可以解决很多问题。

wxw2004gl

个人小小看法：
1、在北京建一个票务数据中心，负责订票、查询；在北京，上海，广州，成都建多个订单数据中心，接受订单、付款处理。

2、软件上先按功能垂直切割，再按车次水平切割，各子系统能方便通过增加服务器增加性能，能缓存的数据都缓存起来。

3、设计特殊的文件系统和存储系统；Linux系统要优化、WEB服务软件也要修改。

5、取消用户注册和登录过程，直接订票，根据订单和密码查询。减小这部分的硬件投入和登录开销。全国如果有1亿人注册，登录过程都是不小的开销。

6、订票成功付款时间应该长一些，比如1天，这样大家就不用集中付款了。

7、优化网站，减少数据传输，减少用户查询次数。比如一次传输给用户多趟到目的地最近几天的票务情况。

8、前端交给淘宝等电商去做，可以让他们收取一定的订票费。

9、得找几家NB的软件公司，NB的人来设计、开发，他们自己那帮人估计够呛。

最后还是要打破体制，不要什么都是自己的人来干，应开放（估计在等50年？）。

aindk

回复 24# xly_971223

不同意您得观点
taobao的需求和铁道部购票的只是相似，而内在是不同得两个极端，
如，一个客户两点直接并不是直达车次，所以设计到专车换成，难道他需要进行两次购物吗？换乘问题，旅客高峰期 临客问题，然后，列车无座票,


10亿次请求，并不是真正得有效请求，而且从将来扩展的角度来说，票务的大集中是必须的，所以目前解决的问题应该是海量得高并发请求




   

hritian

12306的问题和神马 网络半点扯不上边 ，吞吐能力 、网卡、流量都不是问题。这么小的流量都能有问题，某些人直接面向小金门跳海去算了。

12306的问题本质上就是一张小表（数据库的容量不需要太大，所以IO也不会有太大问题，不行多用些内存+SSD就完了） 碰上了高集中度的访问。关键是要解决可扩展性的问题和同步（锁）开销的问题，保证大系统的性能 能够随着后台机器上呈现O（n）的增长。

lsstarboy

　　我觉得集中在北京的想法有点脑残！原因：数据库放北京了，方便了定票系统，但是各地方车站还要卖票，这些信息也需要同步，对数据库也是有影响的。还不如北京的票就在北京查询，南京的票就到南京查询，需要转车的时候多查几个地方站，这样对数据库的压力轻松一些。北京的主网站只做调试员的角色就可以了，支付也应该这样，分散进行才是好的。
　　就像网游的设计：用户认证的时候集中，具体游戏的时候分散在不同的区进行。
　　一楼说的“另外由于铁道部全国有多个分局，在12306的购票数据实时同步方面，容易出现一些问题”，可以采取一些折中手段还避免这些问题，比如分车厢，或把某一些号预留给网站，先对票进行简单分配，在数据量小的时候再进行同步和调配。
　　分布式还有一个好处：一个地方垮了，不影响其他地方。主网站只最多只做个远程查询或重定向，减轻不少负担。

　　其实这跟社会制度差不多，如果所有的事情都由皇帝处理，那么精力再旺盛，保养的再好也不会高寿。就某个单位而言，主要领导的任务就是协调，而不是去做具体的业务。

marxn

对于12306这种变态级别的应用需求只能采取高度专用定制的方案。神马通用组件架构优化都是扯淡。

wang290

marxn 发表于 2012-03-21 17:57
对于12306这种变态级别的应用需求只能采取高度专用定制的方案。神马通用组件架构优化都是扯淡。

很犀利，求详解

记得之前看过别人说过，前端还是lamp集群，后台还是小机加oracle数据库靠谱些，这样的解决方案，前后端都有厂商可以供货的，出了问题可以concall

marxn

回复 3# wang290


    12306的问题不在钱上，现在的问题是现有的任何已知的通用架构都无法满足瞬时的并发需求。12306的问题不是堆机器买服务就能解决的。我认为唯一可行的方案就是由一个专业的软件开发团队从底层到应用层进行高度整合。耦合程度高一点没关系，这种变态的应用就得用变态的架构。后期维护费用高点也没关系，这个钱值得出。

Purple_Grape

12306 其实牵涉到很大一盘棋，你懂的！

网站做的再牛，也只是头痛医头，脚痛医脚，还做了花钱的冤大头。

开分店的做法我觉得还可以，

把异地购票独立出来，解决同步问题。

kisswen

按省分布式？

aindk

个人认为
像开分店得思路估计无法解决，实时票务的问题，因为 开分店可以用来分摊高并发请求的需求，但是及时的联机票务处理估计将会是另一个瓶颈问题，

而数据的存储这必须是海量高并发的，所以像oracle  DB2那种与之类似的关系型数据库，估计解决不了问题

所以估计得考虑非关系型数据库，然后采用缓存优化的办法，将那些客流比较大得站点缓存起来，对于部分一致性比较高的数据还得用到关系型数据库，

然后一些需要事务控制得需要一些中间件

最后还是需求，如何处理这种集中型高并发，其实也可以用参考 HIS 行业的 预约挂号+叫号会诊得思路模式，这样需求进一般粒化

可以将采用一个轮转的排队产生一个有生存期的排队号然后进行订票 订票完后生成一个有期限得订单号，然后分开付款，
并且可以使用分店模式来分摊压力，后台票务大集中处理模式。
中间可以加入短信或语音验证得方式防止恶意竞号，然后，后台是不连续的瀑布式推进，前台任务式操作，这样在将需求粒化，

估计可以一步步逼近最优解决方案，应该是可行的，


一句话来说就是不停的快速重复构建现实模型，来找出最终解决方案，通用行业系统估计无法解决这个问题。

lanck

这个网站很公平，啥时候都能登上又成了黄牛的天下了

cycj2000

12306这个问题本身从应用层面来说问题不大，更主要的是不管是什么操作系统，他本身对socktet的连接数就有限制。
如果不从操作系统本身入手，应用层面做的再好，也不可能从根本上解决问题。毕竟中国的人口基数太大，可以采用获取登录时候的ip地址归属地去，几个省市归集到一个服务器，部署多服务器集群，尤其是北京、上海、广州、深圳几个一线城市，人口密度大。
逢年过节的时候，大家都要回家，可以把一个去的ip地址归属到一个服务器集群去，环境操作系统层面的压力，举例这样来说：北京人口密集度大的几个去，朝阳、海淀、东城西城可以分别建立对应的服务器集群，其他人口密度小的可以建立一个服务器集群，其它人口密度小的城市几个省归集到1个服务器集群。
后天需要对数据库的所有操作，包括索引、使用的sql语句全部进行优化，有可能才能解决此问题