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

yifangyou

1.针对目前12306网站的瓶颈进行分析（可以是从我们自身可以获取到的信息进行分析）。
答：12306的瓶颈有：
     1）没有一个OAUTH系统，还是采取直接查询数据库进行认证这种方式，这个不利于安全，也不利于扩展
     2) 把所有车次的数据库都放在一个数据库里，导致查询出现锁的问题，查询需要排队
    3）网页代码没有经过优化，很多页面样式和js都写在页面上，没有统一写在css和js文件中，这样不利于CDN加速。
   4）订单支付没有使用第三方经过压力测试的支付例如支付宝之类。
   5）网站没有做分布式，而是都集中在铁通里。
2.如何设计和部署高并发高流量安全的在线票务系统。
答：1）首先需要一个OAUTH系统，不要和在线票务系统放在一起，这样保证了安全性，其次可以把登录认证的流量转移到认证系统上，再次可以横向扩展，把在线售票系统做到一个省一个。
      2）系统必须是分布，例如买北京始发的票应该到bj.1230**去买，买广州的票应该到gz.1230**去买，这样每秒1100万的流量就会被分流到各个子售票系统上，每个子域名只售该站始发的票。
      3)对于css和js之类的文件应该全部做CDN，这样可以大大减少对主站的带宽压力。
      4）选择有能够支持强大压力的支付工具（支付宝）

3.现在有哪些比较成熟的系统或者方案。（因为12306拒绝了IBM等的成熟方案，选择自己开发）
答：淘宝有一套OceanBase数据库就能支持天大约有6000万用户登录以及20亿PV量

gotolinux

有朋友说到外包问题，这个是难以解决的问题，特别是层层外包，凸显出的问题更为严重。

说些不是题外话的题外话：

首先，大家应该注意这个一个外包系统，简单来说，至少是应用和运维外包。当然，期间肯定有更加细度的外包，这里就不深究。应用和运维的外包照成了一个很大的问题，就是运维不知道这个应用的“轻”“重”，应用开发不知道后端的承载能力。前面，也有朋友提出了，应用开发方面的诸多问题，比如：垃圾回收、线程的合理应用、浮点运算的处理等问题。对于开发人员来说，首要任务是功能的实现，功能的完整和稳定高于一切，至于后端的运维，那是另外一个公司的事。

其次，还是外包问题。我也接触过政府的相关应用外包，基本都有指定的公司、企业具有投标权。而这些公司原本就有一套甚至几套模块化的系统，中标后，基本上都是根据合同要求进行相应的修改。对于12306是怎么一种情况，这里我们不讨论，也不猜测。对于12306这种亿级PV的应用，肯定需要对其进行完整的定制开发。

第三，也是我最先说的，12306上线非常匆忙。撇开应用不说，单从运维的角度看，前期没有做流量分析，服务器的负载设计不合理。最终，也是在服务器崩溃以后才匆忙添加设备，做CDN。另外，这套系统在上线前也没有做大量的压力测试，只是经过了高铁、动车的小规模线上测试。所以，回到应用架构上，没有充足的测试就发现不了内在的问题，你想要程序员一开始就写出完美的程序来，那是不可能的。

最后，总结下，应用架构有问题，一时半会也改不过来，而我们在这里也很难分析出架构哪里有问题。而我们只能从运维的角度去分析，同样，运维的架构我们也不知晓，只能通过猜测。至于它崩溃的原因，我们也不清楚，是前端服务器的问题，还是后端数据库的问题等等等等？

comcn2

看了大家的讨论，很多人都说铁道部的网站趴掉了，实际上铁道部的网站并没有趴掉，只是做了并发用户数量限制。另外所谓的每日10亿PV纯粹就是瞎扯，根本不可能的事情，除以500才是有效的PV数。这个网站的设计也不可能根据每天10亿PV来进行设计，否则就纯属浪费了

wfcjz

yahoon 发表于 2012-01-17 17:46
此业务的地域特征(北上广,加上几个大的中转站), 高峰时间段(每年也就那么几个节日), 实时要求特征明显

个 ...

1. 此业务的地域特征(北上广,加上几个大的中转站), 高峰时间段(每年也就那么几个节日), 实时要求特征明显
   
2. 
   
3. 个人觉得没必要在一个机房,一组服务器来承担全国的量
   
4. 让每个铁路局负责自己站点的票? 用户数据都是从统一的数据源的一份拷贝
   
5. 
   
6. 就比如运营商各个地方都有分站,办理业务只用上对应的分站,而不是一个portal
   
7. 
   
8. 而且数据查询还是可以优化的,并不是每次点击查询都要去数据库
   
9. 现在最突出的是查到了有票,但是提交不进去,因为全国的写操作都对一个库在操作
   
10. 可想而知了

复制代码

这个是可以的

gotolinux

铁道部12306项目被曝未经招投标仓促上线
http://tech.sina.com.cn/i/2012-01-29/15336665259.shtml

platinum

yanyangtian4502 发表于 2012-01-17 16:06
说实在的，我之前没有使用过12306，最近也是看到很多朋友放映12306不给力，我就看了下！
首先不说别的，页 ...

这是硬伤，别的周边优化做得再好，恐怕也无济于事
好比有 1000W 数据，查找很慢，即使上了再多的集群，但使用的是线性单链表查找，呃……

gotolinux

我认为设计之初就非常必要有个通知系统、首页公告之类，告诉用户到哪有余票，到哪没余票。
当然了，也不是完整的全部站点都通知，可以根据查询量来做，对用户查询进行一个简单的分析，然后给出相应的功能，比如：对于无票的站点给予拒绝查询、提供临近站点的票务情况、近期的临客信息等等。

这样可以避免无必要的大量查询，而且用户对于当前票务也有个大致的把握。

gaoxintian

分布式是必须的
这样一些前端的流量就不需要进入服务器

Gray1982

rootsecurity 发表于 2012-01-25 17:14
1230**就目前来看是铁路+网宿共同建设的龟速网站，广大互联网朋友们眼看着这个平台确很难买的上票。

架构 ...

如果日志还用hadoop的话，不知道对硬件，软件二次开发，系统设置有无优化
二次开发就不多说了
硬件的IO 内存 CPU是否可以，尤其是内存，mapreduce需要的还是很多的
hadoop整体的处理方式，压缩否，IO模式本地化否，几个XML文件优化的怎么样，一想到这玩意就要改N多
系统的挂载设置，系统内核缓存大小，最大连接数，最起码sysctl.conf你得有一套自己的代码吧

这些都是要根据不同的需要来处理，不知道现用的系统怎么样的一样设置

无牙

先要改体制，最后才是改系统。