主题：【原创】好吧，给一个铁道部订票系统的正确答案 -- 布老虎
家园 这个想法的核心麻烦在这里 每个省只卖自己出发的车票，意味着订购处理可以放在省一级，每个省自己处理完请求后再统一汇总到中心去铁路上一个重要的特点是：“从河南郑州到江苏徐州的票有可能是从北京出发终点站在上海”。如果这张票数据放到河南服务器，那么，从北京到郑州的座位就查不到，被浪费了；如果放到北京，那么从河南中心查的话，是查不到这张票的。如果想要避免这两种情况，就必须线路上每一站都放上资源，这又涉及到数据同步问题。如果不想数据同步，就只能所有经停河南的省的服务器都查询一遍，这与数据集中放置到一台服务器的差别不大。上面分析的是读操作部分，在缓存足够大的情况下，这几种方案读效率差不多。现代数据库写是不会阻塞读的（参考数据库的MVCC方案，很多数据库用的都是这个）。
关键问题是写，当多个写操作并发的锁定同一行数据时，只要一个事务被提交，其他的就要全部重来（读已提交）或者回滚（可串行化），大量相互竞争的写操作不断重来回滚，就会耗尽数据库连接资源，最终读的连接也进不去了。最终看似是读失败，实质是写操作阻塞造成的连接失败。
解决这种问题的核心思路就是人为设计一个并发事务串行化队列。无论供应商吹嘘的多么复杂，本质上就是这个。淘宝用开源数据库，某些高并发的地方就是这么干的。
中国不少行业的数据规模都是全球最大最复杂的，比如电信（以至于要分省运营）、铁路（世界负载最高，调度最困难、最乱、最复杂）、证券（金融创新虽不及美国，但小账户、小合约太多，又是世界上最钟爱短线的市场，散户化特征明显）。东部某发达省某银行曾经从印度引进过据称是使用Java先进技术开发的银行业务系统，结果每到高峰时段就会出现10分钟以上的延迟和停摆，断断续续解决了两年没有解决，最后忍无可忍换掉了供应商。印度公司从来没有想到，中国东部一个县的交易量就已经能赶上别人一个国家。
家园 关于证券交易，美国那边比我们频繁的多 因为程序化交易的发展，有些交易已经是在毫秒甚至更小级别上竞争了。
家园 菜鸟一堆。 “东部某发达省某银行曾经从印度引进过据称是使用Java先进技术开发的银行业务系统，结果每到高峰时段就会出现10分钟以上的延迟和停摆，断断续续解决了两年没有解决，最后忍无可忍换掉了供应商。”
Java先进技术，这尼玛哪里来的词？老子怎么从来没听说过？
我老一句话解决问题：典型的Java GC，没有控制好流量。JVM只适用小流量。
这尼玛还要两年？老子服务器down机，trading floor顶多给你5分钟。
家园 我这个考虑过了，可能他们没有做那么复杂 你想现在线上都是标明起始终点站的
也能计座位数的
说明后台里并不是动态分段，而是人工分段分好了输入。
比如我买上海到南京200张，那后台就是上海到南京200张
而不是上海到北京200张然后你可以选终点站是南京还是济南的那种。
不知道说明白了没有。
家园 这个是正确答案 铁道部自己内部有票控计划部门，每一列车次在各站的可售票都是预先订好的，不会允许你随便买哪一段的票。比如北京到广州的车次，每站可以卖多少票都是预先计划好。如果不事先计划好，那么有人恶作剧把武汉到长沙段的票全部买断，北京到广州，郑州到广州的票也用不着卖了。
这尼玛是基本常识stree smart，不知道这帮人回滚啊锁死啊之类的吵什么。听着很像大三的学生，刚刚上完数据库原理，学了一肚子的consistency之类的东西，用了用MySQL和Postgresql，看了我老的雄文，觉得白学了，不忿，上来乱吵，神秘兮兮地乱夸了Oracle和Java一通（这两现在一家了），显得很有内涵，据说开源软件没一样有用，最终还得用Postgresql和Java,因为他俩是闭源软件的典范，秒杀任何开源软件。
我老这苦口婆心不辞辛劳地给广大群众在技术上把关，实在应该收费了。
家园 【商榷】不知道他们有没有用分表这样的很普遍的方法 "不同的事务锁定不同的数据行"做不到，但将票按线路分表，每个表一个事务，这样对“写”操作应该可以并行不少了。更进一步的话，由于用户每次预订操作都是针对一个日期的一条线路来的，按日期和线路两者进行分表，这样并行化也可以更进一步了。到这样的粒度的话，并发量应该就能降一个数量级了。假设高峰时每秒有1000万人同时订票，平均分布的线路有100条，订票时间分布在5天，那并发量也就是2W，貌似大部分订票操作是可以做到秒响应的。
我没试过春节高峰时订票，不知道高峰时到底响应怎么样，不过我怀疑铁路系统已经是这么做或是用类似的办法了。
家园 表分区（分表）的主要目的是为了降低查询负载 尤其是可以有效降低全表扫描的查询负载。在有索引的条件下，这个查询负载降低不明显。
写操作的问题是，竞争+并发，一个事务提交会导致其它事务重做或者回滚。用一个粗略的方法计算，假设有10个事务竞争一行数据，假设他们全部能成功提交，那么，并行事务（假设到所有事务在最终提交前发生回滚）最终耗费的运算资源是10+9+8+7+6+5+4+3+2+1=45；如果这10个事务是串行提交的话，那么耗费资源是1+1+1+1+1+1+1+1+1+1=10。
由于大量的数据库连接资源被浪费到回滚上。数据库连接池会被迅速耗尽。最终导致读数据连接也无法接入。
春运的时候竞争只会比这个强。
无论分多少个表，对于同一行的竞争是无法规避的。现代数据库对资源的锁定都是按照行来的（行锁），并且写不会阻塞读。分表（分区）对于写竞争改善不大。
如果写操作对资源的锁定是按照表来的话，那么你的想法非常有意义。不过现代数据库大多不是这样。
核心问题是解决写操作竞争。可以搜索"MVCC"参考一下数据库的并发控制原理。
家园 麻烦的应该是查验身份证 这至少会增加一倍的时间，他们大概是估计不足了。
家园 2000千万报价是少了点，奥巴马care的网站都近5个亿 的花销，现在上线了人一多就死翘翘，这两天全国开骂呢。 healthcare.org
家园 healthcare.gov的问题不只是流量限制 作为外行，看了一下slate的相关报道，貌似问题还是更深层次的，层层转包，外行领导内行。55个承包商，没有懂行的总负责人。
有很多例子是难以想象的。
1.用户名要包含数字，但是做网页的不知道这个要求，所以用户注册时不知道，结果出了错误，返回的错误信息也不明确。
2.当流量太大时，错误信息根本不是平常人懂的语言。其实网页源码里面都有，诸如“请打某某电话注册”之类的话，但不知道被谁注释掉了。对了，有好事者发现，那个电话很好记，1-800-F1UCKYO。我还纳闷呢，美国人喜欢用这种方法记电话，为什么不弄个好记的。
还有人说要改5百万行代码，好消息是这只占整个代码的百分之一。据说windows vista也只有五千万行代码。这是什么高科技网站啊。当然了，代码的数量并不一定说明什么问题。
家园 我这是第一次看到用政府部门做的网站 做标准。
能不能解释一下为什么Obamacare的网站，可以作为benchmark?
家园 铁道部也是政府部门 可以作为反面教材的benchmark。
家园 又尼玛来个回帖不看帖的 你如果不是数据库供应商的sales，就是被那些卖big ass服务器的ppt忽悠瘸了。
我老在雄文的第三自然段，就已经预料到了会有数据库供应商不忿，跳出来：
“首先，实际的做法是eventual consistency,而不是immediate consistency。全世界最大的电商Amazon,就是eventual consistency的老祖宗。有的同学提出async processing,算是摸着点儿边了。IBM之流肯定会忽悠你去搞一个实时交易系统，然后通过系统硬件升级狠宰你一刀。注意，这就一个人民群众买车票的系统，我草，别把自己当NYSE了。”
然后再具体看看你的PPT错在哪里：
“但由于订票业务是涉及到金钱与资源抢占的业务，因而一致性是不能放弃的，所以采用NoSQL是绝对不行的。”
这不胡说八道吗？用户从看到页面显示，到下订单，中间间隔几秒？至少几分钟吧？等你敲完键盘下完了单，至少几分钟过去了吧？在那么多人抢票的情况下，你看的页面有票没票的信息早过时了，下的订单只能算意向订单，根本没法保证实时，也没有办法保证你一定能拿到票，所以在我老的设计里，也只是给客户一个回复订单已经提交，至于是否成交，你得查询另一个页面。
你的意思retail客户需要实时数据，几毫秒内实时下单，几毫秒内实时成交？所以你的立论就是错的，往好里说，那是没有把客户需求调查清楚，往坏里说，那就是恐吓铁道部。你自己挑一个罪名吧。