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

love2006

分布式集群

lsstarboy

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

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

hjs2020108

个人意见啊。
首先，对于12306，读和写都有很高的并发时，丛大体上，采用读写分离的方法，两库之间做亚秒同步。针对不同库，定制优化
然后，丛全国局域，和列车信息，做纵横切割，功能再切割。来缓解冲击
对于硬件架构，
丛存储架构上，采用集群存储。
丛DB的角度上来说，AIX小型机+Oracle RAC（多节点）+GoldenGate,来应付DB高并发读写
对于中间件层上，采用扩展性强的PC server 集群。或者使用AIX小型机，

Brain1127

同意54楼的

实际上还是库存管理的问题。
接受订单并排进队列，接受日均上亿的PV，都可以通过集群的扩展和提升网络质量来解决。
现在瓶颈在于如何将订单匹配到票的库存。然后管理票的库存。
就算将数据库分布出去，还是会碰到秒级时间要求上的跨地域的库存数据同步问题。

抽象一下数据，发现实际上这个车票库存里
如果用“车次+起始地+目的地+出发时间+座位号” 作为主键来标识的话，每一张车票都是唯一的。
这种库存管理有没有高人能够解决一下？

InfoSVC

个人觉得分布式部署是方向,全国的铁路数据也算多的,加上一列列车经过站点又多且重复性较多,所以应该按照一种方式来进行拆分数据库并进行分布式部署

xcec

大家都坐过列车，但可能都有体会的是列车上的惊人的空或是惊人的挤。我觉得如果能把全国的列车所有的座位信息都同步到各省（或各铁路局）的12306数据中心，各省（或铁路局）数据中心数据保持同步。买车票的人的网络请求根据其选择的目的省（或各铁路局）被转发至相应的目的省（或铁路局）进行处理。

skybird2012

体制问题，技术不是问题。技术就是解决问题的，只要有好的体制，有问题自然会有好的技术来解决。如果全国高薪征集解决方案，相信中国的高手还是很多滴。主要是有发现高手的伯乐和值得高手去做的体制。
云计算机，以前不曾想过的事情，如今也飞入寻常百姓家了。应为互联网这种开放共享共赢的模式能促进技术的进步。

on1forever

1,车票票据应该预生成,减少生成票据的时间和消耗,以空间换时间。
2,从总体逻辑层面来说,应该按时间分库:分为历史库和当前库,每晚12点日结,把当年的车票信息迁移到历史库中。
3,从细节来说,无论是当年库还是历史库,都按地区再细分,减少并发CRUD。
4,对于同一地区的数据库，可以按照票据的哈希，奇偶来分表/库。
5,减少某些不必要的AJAX。
6,剪裁页面大小,重要的是卖票,不是废话和广告。

jli034

才看到这个帖子， 春节后， 我还在想12306 用的是什么服务器， 看了几个帖子， 好像是AIX系统的小型机。

send_linux

jli034 发表于 2012-04-06 20:37
才看到这个帖子， 春节后， 我还在想12306 用的是什么服务器， 看了几个帖子， 好像是AIX系统的小型机。