|
精华帖 (1) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-01-13
画了个图，如下
|
| 返回顶楼 | |
|
发表时间：2012-01-13
情已逝 写道 alan0509 写道 估计都是没有坐过火车的，试问。。 你从广州到北京， 到了长沙 ，你旁边的靓妹下了，这个座位你还要留着给从长沙上来的人吗？？？ 如果这样，站票还一个价，难道那靓妹的钱比你的钱大？ 以前一个座位只卖一次票。 现在确实是中途下车了可以再卖票的，至于公平不公平就不知道了。 铁路本来就是按里程收费的，所以才会导致业务的复杂性。老实说没有见过千万级数据处理的人，设计出来的方案肯定是臆想，很难满足实际需要的。 |
| 返回顶楼 | |
|
发表时间：2012-01-13
ieanwfg201 写道 linliangyi2007 写道 楼上的大谈NoSQL+RDB是辛苦了，换我也会采用类似方案。但是 那帮子搞这套系统的人说不定连啥子redis都不知道呢。 不是哥小看人，而是体制内的事情就是这么荒唐！ 我们整天谈事物完整性，这个几乎是做IT数据库的基础知识和基本要求，当我看到CCAV 的新闻说，钱扣了，票没出，真是让哥大跌眼镜！这他x连最基本的东西都没了，还奢谈个屁的性能，高并发！ 钱扣和出票有半毛钱关系呀，不扣钱还不是照样可以出票，两个完全是调用的外部系统，敢问如何做到一个事物中？求解。要知道就算是航空业务系统将订票和查票分开这样子，也是又无法出票的情况的。 你以为事务的概念就是那么狭义的单数据库或者单系统？！典型是没做过跨系统集成的人才会有这样的想法。 |
| 返回顶楼 | |
|
发表时间：2012-01-13
诺亚之舟 写道 情已逝 写道 alan0509 写道 估计都是没有坐过火车的，试问。。 你从广州到北京， 到了长沙 ，你旁边的靓妹下了，这个座位你还要留着给从长沙上来的人吗？？？ 如果这样，站票还一个价，难道那靓妹的钱比你的钱大？ 以前一个座位只卖一次票。 现在确实是中途下车了可以再卖票的，至于公平不公平就不知道了。 铁路本来就是按里程收费的，所以才会导致业务的复杂性。老实说没有见过千万级数据处理的人，设计出来的方案肯定是臆想，很难满足实际需要的。 我提的方案 http://www.iteye.com/topic/1119804 就考虑到了中途下车的情况，也没见复杂的没法做。 |
| 返回顶楼 | |
|
发表时间：2012-01-13
linliangyi2007 写道 抛出异常的爱 写道 linliangyi2007 写道 jiaoronggui 写道 情已逝 写道 看了这多回复，各位都是网商的应用做多了吧。。
有没有从铁路售票的业务去考虑架构， 这个系统需要支持超大并发像秒杀一样一秒钟就把票卖完吗？ 我觉得就在原来的系统上在做个叫号系统就行了，限制进入购票中心系统的用户。轮到号了才允许进入买票。 体验方面，提示用户前面排队的人数，按照实际系统每秒出票数量计算出需要等待的时间并告诉用户。 说白了就是用户体验做做好就行了。 这哥们思路新颖啊。。。支持 关于排队的思路，我昨天在隔壁帖子中就给出了基本的思路了 引用 1.排队等待子系统
如此大的并发量不是简单的群集能承受的，因此，系统需要一个缓冲区，就好比在窗口面前排队一样，在进入订票流程前，应该有个排队处理系统，简单的页面，让电脑面前的用户知道自己的请求已经提交，系统慢，大概还需要几分钟才能受理你的订票请求。 如果大家玩过wow，下过魔兽的副本，就知道有个副本排队系统了，这样也一样。 此系统需要大量的HTTP前端服务器，接受用户请求，但不需要很复杂的业务逻辑。 2.订票流程处理子系统 进入该子系统的用户开始正式的订票流程，如，填写各种表单。该子系统关键在于需要一张表，用来记录用户已经订出的票，扣除系统剩余票数，这样不至于用户交钱了票没了。只有用户取消订票时，将票退回系统。 同时，该系统应该记录用户在订票流程的日志。 3.订票确认与分发子系统 用户完成所有信息填写后，进入该子系统，该系统负责最终登记用户的订票信息，并正式的将票据出售，同时从用户的资金账户中扣除钱款，并在系统中锁定票号。 用户将从这个系统中，最终确认自己的购买的票据时间，票据，出发到达等信息，即提供最终票务状态的查询。 剩下的具体设计，如，数据库集群设计，负载均衡设计，动态服务扩展设计，高可用性设计，高速缓存设计，这些议题大家平时都在讨论，这里就不多说了。 大方向设计出来了，小细节的可选方案就灵活了。我就不信这样的设计会出现钱扣了，票没出的情况... 1.如果秒杀在设计方案上是个伪命题...... 2.显示方式以域名区分. bj_sh.12306.com\2012\1\20_21_22,返回北京到上海的20号到22号之间的可用车次最多七天. sh_bj.12306.com\page\1返回上海到北京的可用车次可案星期翻页 这样可以水平集群.不同压力使用不同服务器与策略. 3.用户一般不需要注册用户.所以只需要有身份证号,姓名,手机号,在前台用一个隐藏域保存不用存数据库就可以减少集群的压力 4.先行使用支付宝支付.如果有票那么就可以支付.并等待(1小时一次公布) 5.使用撮合算法.撮合最大可能性.并去掉已购票的身份证号,手机号 6.用户查寻放票榜,不成交的号进入下次池中 7.支付宝将支付后的定单完成.不点击完成的号成为不成交号进入下次池中, 8.如果一直没有买中的票则从支付宝退款. 9.可以短信提示注册号 增高 机器人刷票.成本 牛人驾到，直接辗压那些“系统超复杂”论调！ 蓝山，这个绝对牛，极其有可行性，分析的相当透彻，学习，拜读了。 |
| 返回顶楼 | |
|
发表时间：2012-01-13
linliangyi2007 写道 wangda.cn 写道 楼主同志，你说的这些在网上随便一搜一大堆的方案啊。这些没有用，起不了关键作用。你要先了解铁路订票的业务以后才有资格说话。
订票这套业务肯定比你我想的都要复杂的多。 "订票这套业务肯定比你我想的都要复杂的多"多么冠冕堂皇的理由啊，有了这个理由，你说啥都没用！ 一句话，你们地球人的智商是做不了这个系统的！ 体制推卸责任就两招： 1: 神秘主义，这事我搞砸了是客观条件太复杂了，你们P民不懂的。但是从来没有解释复杂在哪的。常用句式：你不懂的，别废话。 2: 二元论，只给你“不做”和“做差”两个选项，绝口不提“做好”这个选项。常用句式：你们p民真难伺候，做也挨骂，不做也挨骂。 |
| 返回顶楼 | |
|
发表时间：2012-01-13
ieanwfg201 写道 linliangyi2007 写道 楼上的大谈NoSQL+RDB是辛苦了，换我也会采用类似方案。但是 那帮子搞这套系统的人说不定连啥子redis都不知道呢。 不是哥小看人，而是体制内的事情就是这么荒唐！ 我们整天谈事物完整性，这个几乎是做IT数据库的基础知识和基本要求，当我看到CCAV 的新闻说，钱扣了，票没出，真是让哥大跌眼镜！这他x连最基本的东西都没了，还奢谈个屁的性能，高并发！ 钱扣和出票有半毛钱关系呀，不扣钱还不是照样可以出票，两个完全是调用的外部系统，敢问如何做到一个事物中？求解。要知道就算是航空业务系统将订票和查票分开这样子，也是又无法出票的情况的。 这个基本上是找喷的，跨系统来操作的例子太多了，如果是央行的系统，不好意思又提出来央行了，做不到这一点，就差不多一切可以妄谈了。 |
| 返回顶楼 | |
|
发表时间：2012-01-13
alan0509 写道 jiaoronggui 写道 情已逝 写道 看了这多回复，各位都是网商的应用做多了吧。。
有没有从铁路售票的业务去考虑架构， 这个系统需要支持超大并发像秒杀一样一秒钟就把票卖完吗？ 我觉得就在原来的系统上在做个叫号系统就行了，限制进入购票中心系统的用户。轮到号了才允许进入买票。 体验方面，提示用户前面排队的人数，按照实际系统每秒出票数量计算出需要等待的时间并告诉用户。 说白了就是用户体验做做好就行了。 这哥们思路新颖啊。。。支持 动不动就排队，几十W人请问你怎么排， 同时1W人刷新网页？请问你又怎么排。。。 很明显走排队的思路就是错误的。 排队都做不了的话，你还来接铁道部的这个单子啊 |
| 返回顶楼 | |
|
发表时间：2012-01-13
linliangyi2007 写道 ieanwfg201 写道 linliangyi2007 写道 楼上的大谈NoSQL+RDB是辛苦了，换我也会采用类似方案。但是 那帮子搞这套系统的人说不定连啥子redis都不知道呢。 不是哥小看人，而是体制内的事情就是这么荒唐！ 我们整天谈事物完整性，这个几乎是做IT数据库的基础知识和基本要求，当我看到CCAV 的新闻说，钱扣了，票没出，真是让哥大跌眼镜！这他x连最基本的东西都没了，还奢谈个屁的性能，高并发！ 钱扣和出票有半毛钱关系呀，不扣钱还不是照样可以出票，两个完全是调用的外部系统，敢问如何做到一个事物中？求解。要知道就算是航空业务系统将订票和查票分开这样子，也是又无法出票的情况的。 你以为事务的概念就是那么狭义的单数据库或者单系统？！典型是没做过跨系统集成的人才会有这样的想法。 +1 严重支持，我一直找不到比较合适的话来喷。 |
| 返回顶楼 | |
|
发表时间：2012-01-13
最后修改：2012-01-13
情已逝 写道 alan0509 写道 jiaoronggui 写道 情已逝 写道 看了这多回复，各位都是网商的应用做多了吧。。
有没有从铁路售票的业务去考虑架构， 这个系统需要支持超大并发像秒杀一样一秒钟就把票卖完吗？ 我觉得就在原来的系统上在做个叫号系统就行了，限制进入购票中心系统的用户。轮到号了才允许进入买票。 体验方面，提示用户前面排队的人数，按照实际系统每秒出票数量计算出需要等待的时间并告诉用户。 说白了就是用户体验做做好就行了。 这哥们思路新颖啊。。。支持 动不动就排队，几十W人请问你怎么排， 同时1W人刷新网页？请问你又怎么排。。。 很明显走排队的思路就是错误的。 排队都做不了的话，你还来接铁道部的这个单子啊 我作过的最大的孽, 西直门13号线换乘铁排队. 那个排队是为了防止自动售票机最大流量. 每天至少要花半个小时排队 第一次看到铁笼子的时候 . 想到的是塔防..... 再之后是天才的龙泽铁壁 再后来是回龙观迷宫II 铁路部门最会排队了 |
| 返回顶楼 | |
