|
锁定老帖子 主题：为12306说几句好话
该帖已经被评为隐藏帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-01-13
最后修改：2012-01-13
风云的方案很靠谱，再加上个排队的时候可以直接输入买票的信息，边排队边查询余票，10秒一次压力应该不大吧，如果没票了让用户可以选择继续排还是退出，排队轮到他之后如果有票直接根据填好的信息进买票页面减少操作时间，票没了就进查票页面该干嘛干嘛去
总之就是快速失败，减少用户真正与服务器交互的时间，大家一起来秒杀... |
| 返回顶楼 | |
|
发表时间：2012-01-13
他妹的,花了纳税人五千万,却整了个怪胎给纳税人,我日,居然还有那么多人还叫好了
|
| 返回顶楼 | |
|
发表时间：2012-01-13
最后修改：2012-01-13
sanshizi 写道 我虽然也喷一次12306, 其是因为填了几个小时的验证码, 有点火,
但是心里还是佩服的, 至少如此高的pv量 , ip量, 网站然后还流畅的运行, 已经很不错了, (即使是说用户过多, 那只是后面系统处理不过来的原因) “网站然后还流畅的运行” 好一个“流畅的运行”，真是睁眼说瞎话！ |
| 返回顶楼 | |
|
发表时间：2012-01-13
我怎么觉得楼主说的全是忽悠人的？
1、配置神马的都是浮云，铁道部会没钱吗？这是必须付出的。 2、连个压力测试都没有的系统，什么高并发，试问，现在这个系统是用什么来处理高并发的？有什么技术含量没有？ 3、这个系统的功能：查票、下单、支付、改签、退票。也就这么几点，有神马特别复杂的？ |
| 返回顶楼 | |
|
发表时间：2012-01-13
zhangjunbao 写道 诺亚之舟 写道 说的不错，不清楚铁道部的主机是什么，不过在一些没有足够的经验的公司面前，这样的系统的确是大问题，拿我们公司来说，我们有自己的框架，在热部署，并行负载等方面的功能（不是说他们的web server不行，而是不如我们实现的好），bea，ibm都羡慕，但是这是我们公司近10年的项目经验的结晶。为什么会这样？因为我们给电信运营商做系统，我们有足够的机会试验我们的技术，在生产系统上逐渐改进，而他们只能在测试环境模拟，怎么可能比得上呢？比如内存数据库，oracle 的都比不上我们公司的，但是这是从800w用户到5000w用户每日详单账单压力测试10年的结果，oracle 的投入再大，可能这样做吗？他们没有这样的机会，导致了他们的不如我们的，并不是我们的工程师就比人家的聪明。
请问是哪家公司的内存数据库？有产品化么？ 如果做的好？为什么不产品化卖给其他公司？ 公司就不说了，不过我们是自己产品内部使用的，没有产品化，也没有销售。 至于为什么不产品化？我不清楚，但是我知道早几年从公司离职的人，现在挂靠在宝蓝德公司做内存数据库产品。性能比我们差20%。资源占用比我们多50%。 |
| 返回顶楼 | |
|
发表时间：2012-01-13
zui4yi1 写道 我怎么觉得楼主说的全是忽悠人的？
1、配置神马的都是浮云，铁道部会没钱吗？这是必须付出的。 2、连个压力测试都没有的系统，什么高并发，试问，现在这个系统是用什么来处理高并发的？有什么技术含量没有？ 3、这个系统的功能：查票、下单、支付、改签、退票。也就这么几点，有神马特别复杂的？ 您想的真简单。 1、给铁道部供应系统的集成商，开始并没有做过类似系统，所以所有的规划都是臆想的。 2、没有合理规划，合理设计的压力测试根本无法替代实际的应用。 3、一个查票，不是淘宝的类静态数据，是全动态的库从计算及组合。比如转车等情况，不是一个select就可以搞定的，还需要站站锁定资源，这些都是要计算的。 |
| 返回顶楼 | |
|
发表时间：2012-01-13
zui4yi1 写道 我怎么觉得楼主说的全是忽悠人的？
1、配置神马的都是浮云，铁道部会没钱吗？这是必须付出的。 2、连个压力测试都没有的系统，什么高并发，试问，现在这个系统是用什么来处理高并发的？有什么技术含量没有？ 3、这个系统的功能：查票、下单、支付、改签、退票。也就这么几点，有神马特别复杂的？ 其实并不是每天都是春运的。 压力测试，高并发---可能他们跟本没做全国上亿人次的并发。 也没必要。不可能为了春运去达到这个需求吧。 票少人多这才是跟本原因。都息事宁人好的 
|
| 返回顶楼 | |
|
发表时间：2012-01-13
sanshizi 写道 我虽然也喷一次12306, 其是因为填了几个小时的验证码, 有点火,
但是心里还是佩服的, 至少如此高的pv量 , ip量, 网站然后还流畅的运行, 已经很不错了, (即使是说用户过多, 那只是后面系统处理不过来的原因) 因为人太多, 拼命加硬件也可以解决,前面查询与后面支付问题, 但是只是每年春节才用一次, 不值当的, 所以我有一个小小的想法来解决这个问题, 我说的这个问题特指: 目前网站前台接待工作做的很好, 但是把你带到后堂, 就没有人招呼了, 就跟我大学的时候, 吃饭的时间大家都拿水瓶去打水, 结果茶房挤破头, 但是呢最终都有水打, 只是要耗太多的时间在那等, 我就想大家都茶壶放在那, 然后有一个人专门来打水 , 大家都估计(根据送来水壶的时间)水打好了, 就直接到拿走就ok了, 节省时间 所以我想到的方法是: 采用预订机制, (归根结底是因为没有排队) 1. 先查询出我要订哪些票(票的价格都有), 此时直接可以支付(注册时已经认证过身份证信息), 支付好了以后, 大家就该干嘛干嘛, 2. 系统根据预订队列, 按照系统所能使出最大能力, 生成车票, 如果可能可以短信提醒或邮件提醒订票成功与否, (如果有客户选择的时间范围,自动滚动到下一批的队列) 3. 最终还是没有票, 执行退款动作 我想这样做的好处, 大家不用无谓的去查询多张, 再订啊订啊, 增加无谓的服务器和带宽负担, 这样就可以把前台接客的资源(甚至支付资源)节省一大部分, 用与支付环节 不知道是否可行 你的方案不可行，同一条线路，有多种选择，比如有高铁，有动车，有普快，有空调特快，有中转，你一次性将所有都选择呢？还是选部分，还是如果没有，自动调剂差的车或者中转呢？如果今天没有，明天你接受吗？后天呢？情况选择太多了，所有不可行的。 |
| 返回顶楼 | |
|
发表时间：2012-01-13
不管怎么说
你花了5KW 做了这么个网站 就是不对。 |
| 返回顶楼 | |
|
发表时间：2012-01-13
不是百度的运维，国内能做铁道部这个系统的公司其实很有限，比如百度、淘宝、盛大、腾讯、网易、sohu、新浪、亚联、神码等
但是这些公司的IT系统都是从小到大一点一点做的。 另外，5000w看起来很多吗，其实一点都不多。以我们目前给运营商做的项目而言，超过450人参与，持续10个月，大家想一下，按一个程序员一年50w成本算。这是多少？ 我们公司是可以2000年的时候提供千万级的邮件系统，国内60%的电信市场都是我们的，运营商的短信网关（你见过基站忙，见过短信丢失吗？）和手机邮箱大部分是我们的，那是多少年的经验啊，这家公司显然没有这个经验的，靠臆测来做系统，能做好才见鬼了。 kimmking 写道 诺亚之舟 写道 说的不错，不清楚铁道部的主机是什么，不过在一些没有足够的经验的公司面前，这样的系统的确是大问题，拿我们公司来说，我们有自己的框架，在热部署，并行负载等方面的功能（不是说他们的web server不行，而是不如我们实现的好），bea，ibm都羡慕，但是这是我们公司近10年的项目经验的结晶。为什么会这样？因为我们给电信运营商做系统，我们有足够的机会试验我们的技术，在生产系统上逐渐改进，而他们只能在测试环境模拟，怎么可能比得上呢？比如内存数据库，oracle 的都比不上我们公司的，但是这是从800w用户到5000w用户每日详单账单压力测试10年的结果，oracle 的投入再大，可能这样做吗？他们没有这样的机会，导致了他们的不如我们的，并不是我们的工程师就比人家的聪明。
lz难道我们是同事？ 楼上的，baidu运维？ 基本同意lz， 但是 1、5000w做这个东西太扯了。如果不算硬件和数据库、操作系统这些硬性的采购。 2、开不开源的技术不重要，成本到底多少其实也不重要，重要的是让用的人都能进得去网站，进得去的都能看到数据，看到数据的都能点预订，订预订的，都能提交订单。 就成了。 否则，就直接挂个抢票活动，直接告诉人家，你有1%的机会中奖拿到票。 |
| 返回顶楼 | |
