- 发帖可能变空内容，邪门暂不知所以然
- 『稷下学宫』新认证方式，24年网站打算和努力目标
主题：【原创】好吧，给一个铁道部订票系统的正确答案 -- 布老虎
家园 【原创】好吧，给一个铁道部订票系统的正确答案 达到适当长度，那么就另起新楼。
为了避免铁道部把这个系统再次搞成世界级的笑话，那我就免费给他们大概地，简单地设计一个每秒千万级响应的系统吧。
首先，实际的做法是eventual consistency,而不是immediate consistency。全世界最大的电商Amazon,就是eventual consistency的老祖宗。有的同学提出async processing,算是摸着点儿边了。IBM之流肯定会忽悠你去搞一个实时交易系统，然后通过系统硬件升级狠宰你一刀。注意，这就一个人民群众买车票的系统，我草，别把自己当NYSE了。
其次，绝对不能和其他系统互联。高峰时间的流量未必能crash铁道部的这套系统，但是一定会搞死工农中建的交易支付系统。简单的解决方法就是全国人民用身份证号登陆，事先在铁道部的系统里存钱。
最后，所有的数据库必须offline，绝对不能让实时的流量冲击数据库，不管是NoSQL还是SQL，这帮数据库都不行。Oracle肯定一定绝对会忽悠铁道部升级到“高级”数据库。铁道部的“专家们”，请一定要大叫呀咩跌。
好了，下面就是系统描述：
查询车次：请求被负载均衡到任意一台前端服务器，前端服务器直接按车次/时间把做好的html从一个hashmap里取出来，扔回去给用户。全部响应时间应该在毫秒级。
有勤于思考的同学就要迷惑地问，这个车次之类的东西，难道不更新吗？我摸摸这个同学的脑袋，慈祥地说，“this is a good question.”。每个前端服务器都定时（每5秒吧，要不每3秒？每2秒？）从后端的cache里取出更新数据。No, no, 先不要问这个cache的问题，叔叔马上告诉你。
下订单：请求被负载均衡到任意一台前端服务器，前端服务器知道这哥们要下订单了，二话不说把订单扔到一个message queue（叫做fund checking queue吧， 瞧，我连变量名字都替铁道部起好了），然后返回一个响应给用户，订单已经提交，请查email或短信。全部响应时间应该在毫秒级。
后端服务器先检查这哥们的钱够不够。因为这钱已经存进铁道部的系统， 这就直接在铁道部的数据库里（就叫存款数据库吧）查询就行了，用不着到工农中建的服务器上去做啥web service。钱够了，直接扣就行。简单的按身份证号sharding数据库table就行了，200个MySql serve, 每个32G内存，够全国人民用的吧？全部响应在毫秒级。
如果这哥们钱不够，把请求扔到一个message queueu（就叫insufficient funds queue吧), 然后email 短信啥的就不多说了。
如果这哥们钱够了，先扣钱，然后把请求扔到一个message queue（就叫 seat checking queue 吧），这个queue主要就是占座位了。如果座位被占了，那么就回到存款数据库里把钱退回去。如果座位还有，那么就占座，然后发送两个message, 一个message到另外一个message queue (就叫做cache update queue吧），这个queue的任务是更新第一步里面的cache（看，叔叔没有骗你吧？)。另一个message当然就是发短信确认订座了。 这一步的响应也应该在毫秒级。
当然肯定存在这样的二百五，事先没往铁道部的系统里存钱，要订座了才开始存钱。也有的无聊人士定完座之后不愿意等，不停地刷个人账户的网页看看有没有更新。存款的过程会比较慢，因为要和其他银行系统互联。个人账户/订票历史网页倒可以飞快，把前面的系统照抄一遍就可以了。
7. 当然中国电信/移动/网通之类的必须在春运期间保证铁道部的带宽，如有差错，那就必须不得不把这几个老总们与数名女性发生或保持不正当性关系了。
至于https reverse proxy之类的load balancer问题，就留给小的们办吧。
那么大概盘算一下开销，前端服务器/cache/数据库/message quque，每样来个300台吧，那就1200台，每台大概$1000，一两百万美刀左右吧。加上开发费用，5个mil美刀应该搞定了。报价个2000万美刀不过分吧？
其实像这样的系统实在太初级，世界上现有的highly scalable (Amazon EC2 可以随时调用数百上千个instance救急），高频系统(NYSE的高频交易系统让Knight Capital在一个半小时内损失4.4亿美元），那处理的交易流量不知道比铁道部水平高到哪里去了，人家还不是谈笑风生就搞定了？
你们呀，还是图森破，奶一捂。
通宝推：bjinjin,远航,史文恭,镐梓,牛栏山二锅头,奥森,铁手,家园 嘿嘿，原来铁道部的就这水平 2012年的，但是完全可以看出来，一帮子初学者嘛，居然用Spring+Hibernate+Struts来处理大流量。
这帮人平时都没在搞技术，忙着闲聊啥悖论了吧？
http://www.csdn.net/article/2012-09-27/2810439
家园 WTF，铁道部居然用的GemFire cache 这帮傻逼到底懂不懂技术？
Java能做cache吗？你用屁股想一想就不可能。GemFire用的最多的地方就是花街，TMD给我们找了多少麻烦？现在要坚决换掉。
一群猪啊，一群猪，居然还发了片报道来炫耀。http://www.ctocio.com.cn/cloud/120/12820120.shtml。
一群菜鸟，自作孽不可活。
通宝推：parishg,家园 俺认为12306订票系统的问题不仅仅是技术，更重要的是设 这两天加入抢票大军了，1张票也没抢到
第1天的问题在系统设置，12306需要3道设置：证书、信任站点、弹出窗许可，网上付款设置不算在内。不懂点电脑技术的人，估计要抓狂。
第2天，根本刷不到。
需要理清的问题：
理念：12306的目的是什么？卖票。怎么卖：公平地把票卖出去。
问题：客多票少，永远绝对公平不了。对于网络售票，不公平的因素：电脑网络技术、网络速度、恶意抢票软件。
解决方法：
简单的卖票程序--打开一个压缩包，安全通道、买票信息设置全搞定，就可以刷票了。
网络速度和恶意抢票软件可以一起解决：面对疯狂的抢票，12306的优势是什么？带宽和速度？不是。软件技术？不是。唯一的就是：票！票在我手里，我可以控制票源、放票速度。可以在开始放票后，隔一定时间，比如5秒钟，锁定一个请求，放1张票。为了防止软件嗅探出间隔，可以用一个随机数。这样，网络抢票软件在速度上就没用了，慢的请求也有机会买到票。当然，发送的请求多，被接受的可能性就会大一些，但总比现在的JAVA终端方式好。
这样，12306可以公开售票软件的借口参数，提供购票软件，同时也容许任何第三方购票软件。
家园 贴个链接,供大家批判学习一下 http://www.guancha.cn/Science/2014_01_09_198628.shtml
具体技术我完全不懂,贴一个链接,供大家批判学习一下.
家园 最省事的 取消即时处理，每个人每次就是提交一个request
1 身份证
2 账号
3 手动填写五个车次 第一志愿到第五志愿（时刻表？请订票的童鞋们自力更生。）
提交request的时候系统再加一个timestamp。
后台每次处理一批requests。按timestamp sort。首先根据志愿找车次。车次定了去账号提钱。中间只要有一个错误，就回个failure+error code，然后处理下一个request。
家园 实际上还有一个问题 订票网站上的票来源不是固定的，而是从售票车间的后台转出来的。也就是说订票网站和售票车间共用一个票库，而且车间的优先级比网站要高。这样的话如果在网站上做cache,很有可能这张票已经从车间卖出去了。
而且事前存钱，如果买不到票退钱的话，压力照样会集中在某一个具体的逻辑上，而且客户的相应处理可能也会头疼的。
家园 业务上就可以避免
家园 支持布老虎的技术方案 按我理解，布老虎同学的方案其实要点有这么几个：
1. 事先存钱减少外部依赖。
2. 查询车次、有无票的请求绝对不能直接压数据库，解决方案是把相关数据分离到一个定时刷新的副本。这里问题在于查票时看到的情况和最终数据库里的未必一致 —— 但考虑到所有人同时上来查票买票的情况，这本来就无法避免。
3. 所有实际买票的请求，先进队列，方便削峰填谷，避免数据库超载。
4. 所有车票数据，分散到若干各自独立的数据库里（术语叫 sharding），这样互不干涉的买票操作可以并行完成。
在我看来，布老虎的方案直击要点，一把抓住了单台数据库服务器负载能力有限这个瓶颈。由此判断，布老虎应该确实有处理高并发的经验。
事实上，这个总体方案一定，最后具体机器上数据库是选 MySQL 还是 Oracle，其实已经无关大局了。纠缠开源软件不可靠的说法，我感觉根本没有明白问题的核心在哪里。谈什么政治责任的，更是莫名其妙：买了 IBM/Oracle 还出问题，拍板人员就不用负责任了？如果铁道部上上下下真是这么想的，那我还真觉得有追究一下“政治责任”的必要了！
不过也要劝布老虎一句，说话语气太冲不是好事，技术人员也要讲究沟通方法的。否则被毛也不懂的外行忽悠去了话语权，最后也是双输的局面。
家园 好久没来，嗯，那些苍蝇都不见了 前段时间太忙，实在没有功夫上网。那个啥红黑客的马甲太多，一看就是专门来搅混水的，明摆着胡说八道。
忙了一年，CTMD bonus就那么点，遥望Hudson river点点渔火，不禁有“问苍茫大地，谁主沉浮”的感想。当年老毛也是因为compensation问题上的井冈山吧？
家园 买oracle的确不用负责任 这个都不知道，说明你的确是不懂
家园 我的确不懂“买 Oracle 就不用负责任”这种见鬼逻辑 老实说我没在铁道部工作过，也没有在其他纯粹国有大企业工作的经历。但是这种“买 Oracle 就不用负责任”、“买 IBM 出了事就不是你的问题”的论调，确实在很多场合听到过。于是我就弄不懂了，铁道部花钱培养起来的技术部门、高薪聘请的技术决策人员，到头来只要决定付钱给 IBM、Oracle、EMC 买他们的解决方案，接着不管出什么技术问题就都不用负责任了？
如果这是真的，那这日子还真是简单而滋润啊，中学生都能胜任了。另外我还想问一句：到时候如果还是出了问题，IOE 会双倍退还项目金额不？
家园 官僚体制下如果资金足够，或者说钱不是问题 那么会选择看起来风险最小的，或者是领导看起来风险最小的。举个实际的例子，如果你用mysql，服务和支持怎么办，有什么有名的大公司支持？就是这类实际的问题。官僚体制下思维方式就是这样的。实际上和是不是国企问题不太大。
换另外一种思路，就是这软件能免费嘛？？？？我们预算很少，只能给工钱。
家园 这用户体验可就很差了 下订单：请求被负载均衡到任意一台前端服务器，前端服务器知道这哥们要下订单了，二话不说把订单扔到一个message queue（叫做fund checking queue吧， 瞧，我连变量名字都替铁道部起好了），然后返回一个响应给用户，订单已经提交，请查email或短信。全部响应时间应该在毫秒级。后端服务器先检查这哥们的钱够不够。因为这钱已经存进铁道部的系统， 这就直接在铁道部的数据库里（就叫存款数据库吧）查询就行了，用不着到工农中建的服务器上去做啥web service。钱够了，直接扣就行。简单的按身份证号sharding数据库table就行了，200个MySql serve, 每个32G内存，够全国人民用的吧？全部响应在毫秒级。
如果这哥们钱不够，把请求扔到一个message queueu（就叫insufficient funds queue吧), 然后email 短信啥的就不多说了。
如果这哥们钱够了，先扣钱，然后把请求扔到一个message queue（就叫 seat checking queue 吧），这个queue主要就是占座位了。如果座位被占了，那么就回到存款数据库里把钱退回去。如果座位还有，那么就占座，然后发送两个message, 一个message到另外一个message queue (就叫做cache update queue吧），这个queue的任务是更新第一步里面的cache（看，叔叔没有骗你吧？)。另一个message当然就是发短信确认订座了。 这一步的响应也应该在毫秒级。
您说的这个系统肯定是能实现的。但用户体验也是将是很差的。
买票作为一个流程，对乘客来说在网上买票其实和到车站售票处买票都是买票。对于乘客来说，最重要的是我交了钱就要拿到票。
到车站售票处买票，售票处不能跟顾客说，你先把钱交了，然后我短信通知你有没有票，拿不拿得到票。都是一手交钱一手交票。
同样的，网上售票也不能用这种先交钱，过一阵再出票的形式。这么搞的话，只要有一两次人家交了钱却订不到票或者要重新订票，人家就不会再信任这个系统了。
网上售票和网上售货一样，卖的归根到底也是一种货物。大型的网上售货网站在顾客下订单收钱之前就要查库存。如果库存不足就要立刻通知顾客没货了。
所以流程应当是乘客查询订票-》系统查询库存-》锁定库存-》受理客户支付-》确定客户有钱-》出票。
家园 花之，讲到问题核心了 不过我还是要支持下布老虎的，因为布老虎的方案肯定会带来铁道部购票网2.0版的升级。。
客户做的烂才有饭吃啦。