如何设计高并发高流量的12306在线票务系统

gilet

现在登陆好登陆上了，但是查询到票提交订单老是提交不了，提示提交订单的人多

king_819

这个就是一个FB 工程，层层分包

king_819

对于12306网站，最大的压力在后端数据库了，都是实时、动态的数据，数据库优化很重要

gotolinux

wzs993636 发表于 2012-01-20 09:20
我觉得吧，正如前面兄弟所说的，这个系统的核心数据库还是旧的，只是提供相关API给网站使用，所以问题也不能 ...

其实这和数据库的新旧没有关系，旧的不等于不好啊。关键是数据库的架构。

comcn2

刚看到这个讨论，顺手把我发在其他板块的帖子转过来：

第一部分：12306订票网站的真实业务压力分析（假定24小时都可以订票，并且一次放票完毕）：
1、需要订票的人群总数是有限的，一个人订到车票之后，可以认为不会再去访问这个站点。
2、从网上查到全国流动人口总数大约2.6亿。估计其中30%的通过网站订票（上班的时候能上网的群体比例未必有这么高，另外上网族也不是每个人都在网上订票）。也就是4800万，往返计算，就是9600万，按照订票一次需要5个PV计算，总的PV数 就是4.8亿，春运共计40天，每天的PV数也就是1200万。按照订一张票需要1分钟计算，并发连接数8333.4个。这个负载无论是对于web服务器还是数据库都不算很高。也就是说所谓10亿的PV大部分都是无效访问。如果按照铁道部的说法，每天放票一百万张，如果定一张票需要5个PV，那就是只有500万PV。对于互联网企业，这个压力应该不算大了。我们暂且按照1200万的PV数进行计算。
3、每天1200万的PV数的网站，如果访问量始终很平稳，貌似就没有太大的讨论价值了。每天所谓的10亿PV的真实有效PV也就是这1200万，之所以为成为10亿PV，就是因为页面无法打开始终进行刷新页面造成的。
4、由于铁道部放票的逻辑过于恶心，导致并发的PV数很高。可以假设并发访问数达到1200万的访问请求在一个小时内处理完毕，每个用户1分钟，需求就可以简化为：200万并发查询连接、17万并发写入连接，这种情况下，就需要仔细考虑一下系统的架构设计问题了。


第二部分：从技术角度分析：
第一、网络部分，这个环节貌似最简单，增加带宽、使用CDN即可，一般会有啥大的问题，即便有也容易解决
第二、系统前端服务器，提供给用户进行登录、查询、订票、支付的页面。貌似这个环节也比较简单，使用负载均衡设备搭建服务器群集，简单的增加服务器就可以平滑的扩展计算能力，另外对业务系统代码进行优化，这个环节就是一个投入的问题，铁道部这么有钱，估计这个不是问题。
第三、数据库，用来存储车票信息的。作为电商前两个环节都是比较容易解决的，最终所有的压力都会在数据库环节体现出来。根据一般的经验，数据库查询带来的压力会远大于写入的压力。可以考虑采用如下手段：
   1、数据库拆分：根据车票信息进行数据库的拆分。比如每个铁路局所属的车次分别对应一个数据库，需要的话可以进一步的对数据库和表进行拆分，从而实现数据库的负载分担。
   2、采用读写分离，所有的查询都定向到只读数据库，写操作定向到写数据库。
   3、只读服务器采用群集技术，进一步提高负载能力。1200万的访问，其中只有100万是需要进行写操作的，只读服务器采用群集技术有很有必要了。
第四、系统的负载能力必须足够大，最少预留50%的计算余量，才能确定用户一次登录就可以确定是否能够订票，而不是不断的去刷新页面，最终导致整个系统崩溃。   

总结：
1、这个所谓的问题，其实本身不是一个技术问题，1000万的设备应该是足够了，造成这种现象的根本原因是由于非技术因素造成的。

2、要想彻底解决这个问题，订票逻辑必须改变，否则到2.6亿流动人口，每个人都上网订票的时候，无论你增加什么样的设备，都不可能解决这个问题了。想想吧，2.6亿人，每人刷新500次页面，多么恐怖的流量哇。

无风之谷

回复 135# comcn2


    回复很详细啊:wink:

lastfile

层层转包，到最后用来做的钱就少了

rootsecurity

1230**就目前来看是铁路+网宿共同建设的龟速网站，广大互联网朋友们眼看着这个平台确很难买的上票。

架构来说个人意见：
全局cdn在这里是举足轻重的。最好能精确到市。
数据库设计是比较重要的，毕竟承载了那么多次查询，个人感觉RAC集群不错。
网站方面nginx肯定是首选。
日志处理还是用Hadoop吧，这个就现在来说还是效率比较高的。

comcn2

无风之谷 发表于 2012-01-24 23:23
回复 135# comcn2

给发个奖品？

comcn2

comcn2 发表于 2012-01-23 18:26
刚看到这个讨论，顺手把我发在其他板块的帖子转过来：

第一部分：12306订票网站的真实业务压力分析（假定 ...

如果火车票像机票一样可以提前30天以上买票，并且一次就放票完毕，这个看起来很2的网站运行的情况就会很好多。

之所以会出现这样的情况，有几个非常重要的因素可能是我们没有考虑到的：

1、各种特殊票种以及优先级，团体票，学生票，民工票，往返票，儿童票，内部职工票，通勤票，同样的车票价格千差万别，逻辑极其复杂
2、特权票，党政军各级领导、中央各部委、中央媒体都是惹不起的部门，必须要预留大量的车票，最终没卖出去的车票才会放给正规的售票渠道，种种因素叠加，导致业务逻辑混乱不堪，而正是这种混乱不看的逻辑可能最终导致系统设计变得极其复杂、低效，最终投入了大量的经费，却无法实现预期的目标。