主题：【原创】好吧，给一个铁道部订票系统的正确答案 -- 布老虎
家园 我觉得eventual consistency问题多多 布老虎在上面提到eventual consistency，我觉得这东西实在不错，看了看wikipedia上的介绍。单就我对wikipedia上BASE条目及其引用文献的理解，这一概念很难用在火车票系统上，至少也不会像布老虎说的这么简单。
首先按照eventual consistency的支撑，CAP theorem的说法，火车票订票系统要保证的是Consistency和Availability，如果要保证这二者，或者哪怕只要严格的Consistency，这样就退回到传统数据库的要求。事实上，所谓证明CAP theorem的这篇文章里面就说：it is impossible to reliably provide atomic,
consistent data when there are partitions in the network。这里的partition，对应我们的问题就是相互独立的后台数据库节点。也就是说，如果后台数据库之间没有同步(如同MapReduce那样)还能保证Consistency和Availability的系统，就和永动机一样，理论上就可以证明是不可能的。这样就退回到Oracle这样的数据库了。
其实BASE系统是不能讲严格的consistency的。布老虎的实现和这篇文章里面的伪代码差不多。为了提高速度，只能保证weak consistency，把几个操作放到message queue里面执行，包括修改不同车次可买的火车票数量和扣用户的钱。这样的系统上线，几乎肯定引发严重的问题。首先是当前查询到的火车票数量是不准确的，任何信息牌上显示的剩余座位信息都是不可靠的。二是当前用户的余额不会立即被扣除，一个恶意用户短时间内可以发起大量购买请求。三是“买到”的票是没有保证的，必须等确认之后才有效，这一点就像是飞机票的超售。飞机票的超售在国内已经引发很多问题了，这个比飞机票的超售还要严重：一是对火车客户而言这是一个全新的概念，以前没有接触过，二是无法确定座位，而火车用户对座位可能看得比飞机上的座次还重。想想春运期间被耍了一把以后还要滞留的客户，不知道会引发多少问题。
家园 铁路自己有历年售票数据，每个站点的售票量加个上限不就结了
家园 搞技术不是捣浆糊 你们好像从来没有遇到过必须保质保量完成的项目。
很多帖子一提到搞技术就张口结舌，结结巴巴，含糊其辞，一提到背后勾兑捣浆糊就兴奋异常，甚至说整个项目的成败决定于undertable deal，技术无关。
国内的这些误解和恶习，全是从外包过来的吧。真正做过软件开发，特别是公司内部开发的，哪有什么勾兑，哪有什么甲方乙方？必须完成，不折不扣，拖延一点也许有关系，看竞争对手网站的情况。如果竞争对手网站上了这个featue,你这边还在唧唧歪歪，那就死定了。
你们当真以为技术没有差别？真是黑老子一跳。技术水平的差别直接导致整个项目完蛋的，远的有铁道部，近的有obamacare。
Oracle没有在大数据上任何有意义的产品。目前的大数据产品都是基于Hadoop/Storm，全部开源。
- 复 搞技术不是捣浆糊
家园 应该说在这个问题上讨论技术没什么大意思 其实讨论已经隐隐约约提到了，这个问题根本在于业务模式的问题。你1200台服务器就算能解决问题吧，考虑冗余了么，考虑运营成本了么，你只解决了高峰时候的瓶颈问题，但是春运以外的316天呢，不要说1200台，100台都太多了吧。一个软件的生命一般在5年，你的方案考虑到5年后的客流量了么。。
最后，你考虑过你的方案里客户付出多少，回报多少么？？你想想客户本来就可以卖出去那么多票，你花了那么多钱只是能帮助他们更快的卖出去，本来卖1天的，花了那么多钱，只需要5分钟就可以卖完了。。。客户要疯了呵呵。从这个角度来说，就是不可能成功忽悠到客户钱滴。。
所以这个问题里技术只是很小一部分，很不起眼一部分。先想想你客户的IOE在哪里。。
家园 这中间有很多大智慧，先收藏有空再读 家园 我来和稀泥 不到之处，请指点，毕竟脱离这行也快5年了，唉。。。。
从本质上来说，布老虎与红黑客的基本观点应该是一致的。
布老虎：
，二话不说把订单扔到一个message queue红黑客：
，都是放弃的并发性。将并发请求通过一级缓冲转化为串行请求。简单来说，都是一回事，太多用户一起涌过来是不行的，大伙乖乖地排队吧。
两位关键的不同在哪里呢？左看右看，就是数据库的选择。
布老虎的选择：
200个MySql serve, 每个32G内存，够全国人民用的吧？全部响应在毫秒级。红黑客的没有说明选择，但是：
，能够解决一致性问题的，非企业级数据库不可，使用MySQL和NoSQL的方案绝对会被决策层乱棍打出估计他会选择Oracle，再不济也得用Sql Server吧？
这稀泥应该怎么和呢？
这不是跟和面查不多吗？面粉多了，加水，水多了加面粉！
简单来说，就是看菜下饭。钱多的主，就用红黑客的方案，钱少的主，就用布老虎的方案，这不就和好了吗？
通宝推：铁手,- 复 我来和稀泥
家园 呵呵 Oracle 铁道部售票系统别想了 因为电子售票系统当年选择的数据库是SybaseASE, 而且已经积累了这么多年了，被粘住脱不了身了。
当年车票由小纸板车票换成目前使用纸质车票， 那可是费了牛劲，阻力很大。地方路局和铁道部之间的利益纠葛，那就是天子和诸侯的关系， 单单靠权力自上向下压是行不通的。
举个小例子， 目前使用的粉红色车票其中有一块钱的软件费（貌似是这个名字，记不清楚了）， 这一块钱是分给各个地方路局用在做软件硬件升级用的。你如果更换系统更换的早的话， 就能更早拿到这笔钱。这么多年鬼知道这笔钱是不是升级了硬件软件。
改革改革，就是利益再次分配。分不好得罪人，就像商鞅被五马分尸啦。哪个领导敢拍板， 把那个后台数据库换了？
家园 Sybase也很不错 据说华尔街那边有不少公司都在用。
如果用了多年，要脱身确实不容易。
再加上他们的技术能力，再考虑到利益纠葛，只能哈哈了。。。。
- 复 我来和稀泥
家园 从技术上来说我觉得内存数据库可能是一个比较简单的办法 搜索了一下，2012年春节日均售票700万。
由此想到虽然这个业务的特点是高并发高实时但是数据量是很低的。
（请不要争论到底是很低还是低还是中，反正我觉得很大众吧）
而且这700万还不是在时间上平均分布的，而且网站还允许每日停机维护。
所以我就那么一搜索内存数据库了。
这里不提sqlite，没文档。
有个叫extreamdb的，8并发每秒写70万条数据，4并发每秒删40万条数据。可以满足高实时了吧。
而基于内存和磁盘的solid db8线程每秒也可以插入5万多数据。
测试规模在1000万条数据。
所以我觉得可以解决这个问题了。其实我顺带搜了一下当时的抱怨，其实很多纯粹是可以无难度避免的。他们的主要问题还是缺乏设计这种系统的经验。
最后我不得不说，客户既有系统做的烂我们才不断有订单。大家懂吧。
家园 小伙子勤于思考，不错，但是 re-invent the wheel了。
In memory db早就有了，你说的是cache还是有persistent capability的db? 简单举个例子，你说的是memcache还是CouchDB?
In memory db要有条件，很苛刻。首先你不能crash,或者有live-live the failover. 道理很简单，你如果crash了，重新启动，要多长时间来reload memoery？
MongoDB/Cassandra之类的key-value store, 首要条件就是所有的数据能够fit into memory，那么就有了很多sharding, failover，read/write separation的设计，来scale out。
家园 你这些都是些很基础的问题，可以略过不讲滴 略过不讲估计你又要跳起来了，那搜索下产品说明书吧，不要再发明轮子啦。
你们的根本问题在于不懂铁道业务。不要追求最完美的，要追求最适合的。好好想想我说的对不对。
- 复 我来和稀泥
家园 你这个稀泥和的清楚 我觉得用mysql的可能性不大，虽然从实际情况来看，mysql的潜力也不小。facebook就把mysql的潜力挖出很多。问题是在于facebook很可能是一开始用上了php和mysql，更换系统的风险太大，所以就这么抗下去了，另外也有资源去补丁。还有个风险是在于mysql被oracle收购了，谁都得对它的将来要保持点疑心。
- 复 我来和稀泥
家园 免费方案中，红黑客会选开源中最好的PostgreSQL 很奇怪大家都自动无视了红黑客提到的PostgreSQL数据库。选开源的数据库时，推荐PostgreSQL而不是MySQL，给我的感觉更像高手，呵呵。
我没有仔细看大家给出的方案，但是仅凭常识来讲，觉得红黑客比布老虎要正确。就算不涉及政治，就算不涉及态度，光是技术方面，布老虎就有几个地方明显说错了。
选PostgreSQL也可以做集群，不一定是“单机版”
选PostgreSQL也可以NoSQL，这个估计他也不知道。
家园 问题是他还说了SPOOL 这玩意儿一看就是单机的，不管怎么把它网络化。
- 复 我来和稀泥
家园 从我以前看，一般的客户都不会在这个问题上有任何的犹豫。 他们必须选择Oracle，因为这个是收费的，收费的就意味着有人要承担责任。免费软件很多时候在国内是要受到限制的。