|
精华帖 (1) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-01-13
jiaoronggui 写道 诺亚之舟 写道 用mysql 替代 oracle，我不赞同。这个老兄能说下原因吗？？
因为从我自身的多个全国性系统的经验来看，中心数据库在突然的大并发访问的时候，IO绝对是最后的一个也是最大的一个问题，对于ORalce这样的，如果采用3-rac或者4rac的话，阵列的成本太高了，动不动就上百万的。 对于国家支撑的项目来说，设计的时候完全可以不考虑成本问题，只求最贵！不求最好！ |
| 返回顶楼 | |
|
发表时间：2012-01-13
说了这么多,呵呵,要我说就一句话,改成电话订票不就完了吗,呵呵!!
|
| 返回顶楼 | |
|
发表时间：2012-01-13
linliangyi2007
给的是比较折中的设计思路，在不考虑使用大集群、大高速缓存设计等时，安全性和用户体验比较好的方案了，支持一下！ 应该是秒杀系统的升级版了！ |
| 返回顶楼 | |
|
发表时间：2012-01-13
hueng512 写道 linliangyi2007 写道 wangda.cn 写道 楼主同志，你说的这些在网上随便一搜一大堆的方案啊。这些没有用，起不了关键作用。你要先了解铁路订票的业务以后才有资格说话。
订票这套业务肯定比你我想的都要复杂的多。 "订票这套业务肯定比你我想的都要复杂的多"多么冠冕堂皇的理由啊，有了这个理由，你说啥都没用！ 一句话，你们地球人的智商是做不了这个系统的！ 顶老林~！ 系统肯定是很复杂的，不仅仅是买票，它的很多数据接口都要和其他部门结合，比如公安、税务等，其他的系统做的就很烂，有的时候你必须去适应那些烂的，所以国家部门的系统真的是恶性循环，不统一，互相影响，没有最烂，只有更烂！ |
| 返回顶楼 | |
|
发表时间：2012-01-13
yue19870813 写道 hueng512 写道 linliangyi2007 写道 wangda.cn 写道 楼主同志，你说的这些在网上随便一搜一大堆的方案啊。这些没有用，起不了关键作用。你要先了解铁路订票的业务以后才有资格说话。
订票这套业务肯定比你我想的都要复杂的多。 "订票这套业务肯定比你我想的都要复杂的多"多么冠冕堂皇的理由啊，有了这个理由，你说啥都没用！ 一句话，你们地球人的智商是做不了这个系统的！ 顶老林~！ 系统肯定是很复杂的，不仅仅是买票，它的很多数据接口都要和其他部门结合，比如公安、税务等，其他的系统做的就很烂，有的时候你必须去适应那些烂的，所以国家部门的系统真的是恶性循环，不统一，互相影响，没有最烂，只有更烂！ +1 |
| 返回顶楼 | |
|
发表时间：2012-01-13
aa00aa00 写道 说了这么多,呵呵,要我说就一句话,改成电话订票不就完了吗,呵呵!!
哈哈，那就不再咱们的讨论范畴内了。。 |
| 返回顶楼 | |
|
发表时间：2012-01-13
1、可以采用activeMq来排队。。
2、采用读写缓存分离，采用memcached，复杂一点就memcache集群，设置主从缓存以及缓存服务器优先级，类似sina的sea。 3、配置多台备用缓存服务器，在春运的情况下加入备用缓存服务器到memcached集群中。 |
| 返回顶楼 | |
|
发表时间：2012-01-13
qq123zhz 写道 1、可以采用activeMq来排队。。
2、采用读写缓存分离，采用memcached，复杂一点就memcache集群，设置主从缓存以及缓存服务器优先级，类似sina的sea。 3、配置多台备用缓存服务器，在春运的情况下加入备用缓存服务器到memcached集群中。 你了解铁道部系统流程吗,就给下定论了,呵呵,我是不敢下定论啊!! 
|
| 返回顶楼 | |
|
发表时间：2012-01-13
jiaoronggui 写道 aa00aa00 写道 说了这么多,呵呵,要我说就一句话,改成电话订票不就完了吗,呵呵!!
哈哈，那就不再咱们的讨论范畴内了。。 电话订票成功率也很低的... 亲身经历,苦不堪言 |
| 返回顶楼 | |
|
发表时间：2012-01-13
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.可以短信提示注册号 增高 机器人刷票.成本 |
| 返回顶楼 | |
