主题：【讨论】回应对12306.cn网站的技术质疑 -- 忘情
咋其他职位够高的人也不知道啊？
前面说的有些道理，后面就，，，，
“其他任何一个网站无法望其项背”恐怕就有点言过其实了。
这里是一个不太完全的排名，按每日访问量排名
1. facebook: 11 billion/day
2. google: 9.2 billion/day
3. youtube: 5.5 billion/day
4. baidu.com: 2.6 billion/day
5. yahoo.com: 2 billion/day
18亿的访问量前5名都排不进去，和第一名的facebook相差一个数量级。
如果说单纯的页面访问不太能说明问题，那么下面的排名是按用户数字。
1. google: 670 million/day
2. facebook: 640 million/day
3. youtube: 450 million/day
4. yahoo: 300 million/day
5. wikipedia: 180 million/day
中国网民数量按照去年的统计是5亿。那么上面排名前2的都能很轻松的支持所有中国网民的在同一天访问这个网站。同时注意一下wilipedia，那是一个非营利机构，所有的运行费用都来自民间捐款，相信从资金上看，比铁道部相差不是一个数量级的。
1.铁路订票系统的定位
铁路订票系统应该公平地将火车票资源按照旅客的请求分发出去。至少应该满足先订先得的要求。包含两层意思：（1）分发票的顺序不能颠倒；（2）订票不会出现失败的情况。也就是说，只要下订单的时候有票，就一定可以得到票。
2.铁路订票系统的模型
下面给出一个满足先订先得要求的铁路订票系统模型。假设旅客订票只关心出发站，出发时间段，到达站，到达时间段。铁路订票系统接收上述四个数据。根据旅客列车时刻表，有算法在近似O(1)的时间内通过上述四个数据取得旅客可以选择的车次的集合。大概思路是，把时间按照一定间隔（譬如2小时）划分为若干段，作为x轴。把所有车次的所有可能停靠站作为y轴，那么某个坐标(x0,y0)可以确定一个车次集合，表示所有在时间段x0经过车站y0的车次。由于列车时刻表是固定的，这个x-y平面中的点与车次集合的对应关系也是固定的，因此可以事先求出，用二维数组的数据结构表示。当旅客给定出发时间段和出发站时，可以在O(1)的时间内读出满足出发要求的车次集合C1。同理，可以在O(1)的时间内读出满足到达要求的车次集合C2。同时满足出发要求和到达要求的车次集合是C1,C2的交集。因为C1,C2的元素个数相对较少，因此求交集可以近似视为在常数时间内完成。由此，我们把旅客提交的出发和到达要求在常数时间内转换成了旅客可以选择的车次集合。
知道可选车次，出发站和到达站，就可以进行订票操作了。这里，基本的数据结构是一个以车次为行，所有可能停靠站为列的二维数组。在二维数组的一个存储单元内，存储某次车在某个停靠站的余票数。如果以n表示旅客提交的出发站与到达站之间的总停靠站数，那么查询余票可以通过n个基本操作完成。道理是这样的，可以出售的车票数等于在出发站与到达站之间的所有停靠站的余票数的最小值。因此对n个站点进行读取就可以得到满足旅客需求的余票数。
旅客的订票需要4*n个基本操作。首先锁定沿途各站的余票数，需要n个基本操作。其次查询余票，需要n个基本操作。如果存在余票，对沿途各站的余票数减1，需要n个基本操作。最后解除锁定，需要n个基本操作。
以上，对于一个旅客的订票活动，需要进行4*n次的存储单元访问。考虑到中国目前有5亿网民，假设在高峰期，有5亿次/秒的订票请求，每个请求中，旅客指定的出发站与到达站之间都有100个停靠站，那么就需要4*100*5亿次/秒，也就是2000亿次/秒的存储单元访问。这可以视为是订票系统的极限性能需求。理论上，如果不考虑网络连接方面的问题，达到该性能的系统可以无压力地满足广大旅客的订票需求。
3.分析及结论
2000亿次/秒的存储单元访问，对于计算机的性能是一个不小的挑战。一个解决方案是，采用分布式计算。如果将不同车次的余票信息分别存储在2000台计算机上，按照车次对旅客提交的订票请求进行分流，那么理想情况下每台计算机的存储单元访问就可以降到1亿次/秒，一般的计算机将可以胜任。
在达不到所需的数据处理性能的情况下，系统将无法实现实时订票，退化为一个异步订票系统。对于一个能处理1亿次/秒存储单元访问的计算机来说，面对5亿次/秒的订票请求，最坏的情况下，最后提交的请求将延迟2000秒，也就是半个多小时才能完成订票。
由上述分析可见，采用高性能的数据库，采用并行计算方案，适当牺牲订票系统的实时性，有助于解决铁路订票系统的问题。
对绝大部分情况都有了解决的方案，只有铁道部是打算一步到位，推出之前完全可以以省为单位进行分批实验的。
送花成功。感谢：作者获得通宝一枚。
作者，声望:1；铢钱:16。你，乐善:1；铢钱:-1。本帖花:1
花了好几亿却舍不得买个Certificate，方便了骗子做钓鱼网站
忘情可以说很多旅客不体谅铁路员工的事理，这没问题，人情层面大家一旦了解了铁路员工的不易，人心皆是肉长的，能理解的地方大家是可以理解的。
问题在于12306是个纯粹技术问题，而且这种技术问题绝不是靠人情理解可以去解决的。网站峰值高，这是一个靠技术解决的问题，恰好说明现有12306网站使用的技术不符合实际需求。却并不能说现阶段没有能够解决问题的技术，事实上很多做这方面开发的人已经给出了至少更好的技术架构。这恰好至少说明了，网站前期预研过于随意。既然不合理，不应该死不承认。不承认问题而强调客观原因。实际是对消费者不负责任。
这篇文章我直接滚动到底了。
上次铁道部也整出片文章说 因为要兼容syabase的旧系统，所以没有scale up的方案，只有scale out方案。当时我还天真的信了
后来某日查车站达到时间，竟然服务器也挂掉了
这出来写文章也是蒙事啊。
车票本身和铁路局之间没有对应关系，一张车票可能跨越了多个铁路局，把票务数据分散到各个铁路局的服务器上，指挥使事情更糟糕。数据一定是统一的，集中管理的，但在内部技术上要分布处理。
按车次分散，一个车次只放在有关的某个路局的同一个服务器上，这与你的“把票务数据按照不同车次、不同时间，分散到不同的表、数据库或服务器中。”没什么区别，只是这么多服务器不在一地而已。各路局服务器如果不用于卖票的话任务肯定是不饱满的。
至于集中管理，只要单个车次集中就行了，没必要全部车次集中。实际上铁道部可以按车次把网上售票任务分到各路局，铁道部总的售票网站上来个链接转移就行了。
你说的和我说的恰恰相反，我说的是大集中，小分散。大集中，就是所有数据集中处理，不再由各路局、各分段维护数据；小分散，是说在集中处理中，为了技术问题，从技术角度上分散数据到不同的数据库、服务器。数据库、服务器可以在物理空间上分部在不同的机房、城市，如果有必要的话！
另外，我很奇怪你为什么一定要把路局扯进来，车票数据从业务逻辑上和路局没有任何关系，服务器的位置也和路局没有任何关系，不知道你从哪个角度认为加进路局会解决问题。把车票数据分配到各个路局，只会加剧责任的扯皮，和数据之间的不一致性和冲突。
起码目前的机制和某个日期的热门票肯定不足现实，决定所有用户的行为都如此。上面列举的网站好像都没有这种问题，即使偶尔有用户量也没法比。
如果确实没有设备能够承受如此多用户的第一时间刷票，那么异步购票的申购抽签模式应该是解决问题的可行出路。
比如所有车次网络票50%，窗口票50%。 一种售罄，只能换另一种方式购票。这个作为过渡时期的业务措施，是合理的，可以降低新系统的风险。
其实铁路这种大型牵涉面极广的重大系统的更新，是需要专门的多层次的风险控制方案，是需要专门的多层次的风险控制队伍，是需要专门的专项的充足的经费和预算，是需要良好严密的风险控制组织体系和质量控制体系，是需要专门的对高层、董事会直接负责的风险控制总/副总经理。
国内软件业对风险控制的意识还很薄弱，真正形成独立的风险控制部门和风险控制组织体系的恐怕还是凤毛麟角。即使是质量控制部门，真正比较强大的也不多。
铁路这个事情，可以起到教育的作用也是不错的。
通过验证码可以解决刷票机的问题。验证码中的字符只有人能辨认，目前机器的识别能力还达不到，所以刷票机在使用验证码的网页上不能发挥作用。