主题：【讨论】回应对12306.cn网站的技术质疑 -- 忘情
家园 核心的瓶颈是数据处理过于集中 因为这个网站的业务的原因，所有的操作都是对那么很少量的数据的大量处理从而导致的问题。无论用云计算还是增加更多的服务器，如果不解决这个核心问题，都是白搭。解决数据处理过于集中，我能想到最简单的办法是两条措施，大家看看有没有什么启发：
1、分散数据。
把票务数据按照不同车次、不同时间，分散到不同的表、数据库或服务器中。比如，可以按照某种规则，一张表里只保存几个（比如，5个，具体数值就需要统计以往记录进行分析）车次的几天（比如，2天，那么，预售期10天，就会分散到5个表里。当然，具体几天，还是需要分析以往数据的）的车票数据。这样的话，在数据操作时，影响到的范围将大幅度减小，这将大幅度提高并发度。
2、二级数据管理
可以把数据分布在2个级别上管理，一个级别记录完整数据，在第二级上按某种机制记录部分数据，第二级可以由很多个服务器组成，也就是，1：n的情况。而Web服务器只访问二级数据库，并不访问一级数据库，二级数据库访问一级数据库。
比如，某次车的某天的数据，这个车次的所有票务情况完整保存在第一级数据库中，每个二级数据库需要从一级数据库申请自己可以分销的票的数量，二级数据库的票销售完毕之后，把销售结果同步到一级数据库，并再次申请自己分销的票的数量。这样的话，一级数据库的访问次数将大幅度减少，而同时也保证了数据的一致性，不会出现把票卖超了的情况。
家园 一语中的，我有同样的想法。 一语中的，我有同样的想法。我觉得现在铁道部的数据库可能是一个唯一的数据库，要想提高效率可能不得不搞多个数据库和运算中心来分配载荷，这就牵扯到多个数据库数据同步的问题了，应该是个难点。
家园 还是这样比较靠谱，应该分到各个大的铁路局服务器上。 家园 分到各个铁路局的服务器上只会使事情更糟糕 车票本身和铁路局之间没有对应关系，一张车票可能跨越了多个铁路局，把票务数据分散到各个铁路局的服务器上，指挥使事情更糟糕。数据一定是统一的，集中管理的，但在内部技术上要分布处理。
家园 分散是指大分散小集中， 按车次分散，一个车次只放在有关的某个路局的同一个服务器上，这与你的“把票务数据按照不同车次、不同时间，分散到不同的表、数据库或服务器中。”没什么区别，只是这么多服务器不在一地而已。各路局服务器如果不用于卖票的话任务肯定是不饱满的。
至于集中管理，只要单个车次集中就行了，没必要全部车次集中。实际上铁道部可以按车次把网上售票任务分到各路局，铁道部总的售票网站上来个链接转移就行了。
家园 为什么一定要把路局扯进来？为了政治均衡？ 你说的和我说的恰恰相反，我说的是大集中，小分散。大集中，就是所有数据集中处理，不再由各路局、各分段维护数据；小分散，是说在集中处理中，为了技术问题，从技术角度上分散数据到不同的数据库、服务器。数据库、服务器可以在物理空间上分部在不同的机房、城市，如果有必要的话！
另外，我很奇怪你为什么一定要把路局扯进来，车票数据从业务逻辑上和路局没有任何关系，服务器的位置也和路局没有任何关系，不知道你从哪个角度认为加进路局会解决问题。把车票数据分配到各个路局，只会加剧责任的扯皮，和数据之间的不一致性和冲突。
家园 各路局有现成的服务器，利用上可以减少硬件投资。 从使用上，与铁道部新买大量的服务器放在北京或分散到多个城市没有区别。
从售票上，只要保证某次车本身数据的一致性，甚至只需要保证分配给某个车站的某次车数据的一致性就足够了，不同车次的数据并不需要关联。
08年以前南京车站也曾实行过网络售票，与现在不同的只是不在网上付款，是订好票后给个流水号，在第二天二十四小时内到任一售票处去付款取票。只能订分配给南京站的票，这说明了网络售票并不需要把全国所有票一致在一起。
家园 服务器所有权、管理权的分散，只会增大复杂性 分散的所有权、管理权，必然需要分散的技术支持和运维。而不同路局的技术实力相差很大，运维能力相差也很大，硬件配置差别也不小。看起来是省了一些钱，实际情况估计会华更多的钱和时间。
难道你的意思是，各个路局各自建设、维护自己的网站，再把数据统一到另外一个集中的站点，用户是在各个路局的网站上买票，而不是在统一的12306上买？如果真的是这样的话，你提出了一个异常复杂的技术问题和各路局之间的政治问题。票的分配、剩票的再分配，无论从技术、实时性（用户满意度的关键），还是路局之间的抢票、扯皮，那都是需要神来解决的。当然，这样的话，就可以多几个承包商来做了，有钱大家分了。至于效果，我觉得不会好于现在的情况。
家园 你怎么老想的那么复杂？ 票的分配，路局之间是由铁道部统一分，路局只能管分到自己局的这部分。某次车途经各站可以售的票是预先分配好的，每个车站只能卖分配给自已的票，不存在卖票时各站的抢票问题。
举个例子（具体数字只是打个比方），比如南京到北京的T66，满员一千人，南京站可以卖其中五百张到北京的，蚌埠徐州各两百张，德州100张，同时南京站可以卖200张到蚌埠的，蚌埠到徐州、德州的短程票另分。已经分到其他站的票是抢不来的，对没卖完的票，前面站发车后还没卖出的座号，才可能通知下站卖，没卖出的卧铺由车上卖给已上车的旅客。
同时各车站卖票所得钱款并不是谁卖谁得，都得上交到铁道部结算中心按一定的规则分配，谁卖的票谁提成多，所以车站不会有票不卖的。
即使已经分配到站的票，放哪卖也是预先分好的，留票多少，网上、电话、窗口各卖多少都是分好的，网络、电话没卖完的到最后几天才会放在窗口卖，留票可能放到最后一天上窗口。也不存互相抢的问题。
上面这清楚了，分散服务器的问题也就清楚了。也举T66的例子：所有T66的数据放在上海局（南京归上海局管）的服务器上，12306只管查询和转链接。在于2306上查好车次，选择要买的车次时自动转到上海局后服务器上，以后的操作都在此进行。
不管各局技术能力相差多大，局里的服务器是不能停的。不管路局间怎么扯皮，分票的事是上网前已经扯完了，不存在到卖票时再扯的问题。
家园 我们两个较真的人碰上了 先说票的分配，凭什么分给某个路局这么多票，如果这个路局的票没有卖完是否可以转给其他路局卖，怎么转，什么时候转，是开卖几天之后转，还是开车前几小时确认还有剩票再转？这些是不是都是问题？并且，这样分配的结果，其实还是老的思路，从票务资源的统一、整合，更有效的利用这个角度，是又退了回去。
至于技术方面的运维能力，那可真不是一般的差别，对于某个路局很轻松的问题，对于别的路局可能就是天大问题。如果只是为了利用他们的硬件，完全可以买下来集中管理和运维。
家园 这个凭什么与卖票系统已经无关了。 至于技术问题对哪个路局也不是问题，照理说西部技术能力比较差吧，08年在新疆就可以在区内任一售票点买到全区内任一车站任一车次的车票。
家园 最近被12306.cn折磨得死去活来的人上来说一句 这次改版，在流程设计和用户体验上做得太差。
比如，增加了一个“预约”功能，结果点进去一看：“预约时间已过，预约时间为2012年09月10日，11:00至20:00。”
话说现在都24号了，这个功能若是不能用，为什么不删掉或者置灰？购票时，下了订单，被告知需要等待的时间大于30分钟。这个信息除了引发不满，没有给我任何有益的帮助。我需要不停地刷，或者隔半个小时登录一次。
12306.cn的技术方面，也许存在很多问题。不过对于一年只有两次（国庆、春节）的大流量，是否需要花很多钱从技术上去解决这个问题？我个人觉得可以采用更好的策略而不是简单的下订单后排队这种方法。比如，ETS的Toefl报名，也是瞬间高峰，它的网站采用的方法就是限定每个ip在指定时间内的点击次数，如果超出，就封ip。
从我个人的体验来说，不能进入系统的感觉比下了订单后不知何时支付要好得多。
家园 火车票现阶段的解决方案胡想 1 要解决登陆和查班次的问题，这个可能要用云计算的方法，就是每次长假，春运，铁道部多出点钱去租云计算的量。这种登录的问题和空调类似，总量不够就永远无法满足需求，而且会累计进入恶性循环。租云计算的好处是，平时不用养这么多服务器。这样总的信息投资费用降低，每年的有一些租用的费用，而且随着计算机的技术提高，国家总带宽的提高，租用的费用肯定会逐渐降低。如果实在无法租用，铁道部只有自己想方法满足这么大的页面点击率了，这是一个不小的费用。网民津津乐道新浪，腾讯，百度的天量访问量，也是天量服务器和天量带宽才能完成的。
2 查班次的时候余票量不需要实时票量信息，最起码要有半分钟到一分钟的延迟。对于热门时间的热门班次，其实无论啥技术手段都是无法做到实时数据，你看到的数据和你点击时的数据永远有差异。而冷门票这点延迟其实无所谓。这种延迟信息可以在网页上直接注明，我觉得大家可以接受。
3 增加类似淘宝里的快捷付款的功能，可以预存一部分客户信用卡的信息，这样客户只要输入一个手机确认码就可以完成付款，这样减少票的待确认时间。咱觉得票的待确认时间减少可以减少很多系统的工作量。
家园 这篇文章回应了什么质疑？ 我不知道这篇文章到底回应了什么质疑？难道这个系统从技术上来说是不可能建好的？
作者有点水平，但也不是搞这个业务系统的。性能优化，关键是要找出瓶颈。文章洋洋洒洒，但问题是作者也不知道瓶颈具体在哪里。
铁道部花了这么多时间，结果还是这个样子。要是把系统研发比喻成一场战争的话，如果是这个结果，领头的早就被枪毙了。
通宝推：熊仔,家园 回个贴把这篇文章捞上来 性能优化，关键是要找出瓶颈这一句话就能说明上面那几万字白写了。