由买买提看人间百态

boards

本页内容为未名空间相应帖子的节选和存档,一周内的贴子最多显示50字,超过一周显示500字 访问原贴
Military版 - 卖火车票的网站真的能有那么难设计吗?
相关主题
买不到火车票[视频]春运和谐号,一女买了3张票躺着,一男站票
一个哥们对刘跨越的评价春运中一女子买3张票睡觉,一站票男子不服
每次买不到火车票得去做长途汽车的时候Kubiak needs to provide convinding evidence. The apology is unacceptable.
有没有大牛谈谈火车票的技术挑战在哪?我X,联邦政府雇员们欠税10个亿! (转载)
铁路售票网问题的关键是每天定时放票Re: 估计Obama会得280-290张票 (转载)
毛泽东的亲戚排队三天买不到火车票博士生买8张票曲线回家 途中转车7次
如果我发明一种中文程序语言,会不会出名? (转载)(ZZ) 8张票7次换乘,在车上的时间省13个小时
方别的不说,抓论文剽窃基本只有漏网的没有抓错的。48天占领广场是不能被任何社会接受的
相关话题的讨论汇总
话题: 服务器话题: 问题话题: 设计话题: 用户
进入Military版参与讨论
1 (共1页)
u****u
发帖数: 229
1
这里很多人都在说这个卖火车票的网站有多难设计,我真的不太相信。这里我就提一个
简单的设计,相信应该能解决所有的问题,大家可以来批评一下会不会出问题:
1。网页上来让用户选择时间和起始车站,一个包送到分服务器上查询是否有空。如果
有,进入到下一个网页输入各种购买信息,完成后一个包送到分服务器上。这时候的提
示是购买要求已受到,但是还不表示购买完成,然后所有的分服务器在后台按照一定顺
序和一个总服务器通讯。分服务器把购买的订单给总服务器,总服务器按照受到的时间
顺序一个个单子处理,的确有空的就完成购买再送回分服务器,没有空的位子就直接退
回无位信息。分服务器收到总服务器的反馈才通知用户。
2。每个分服务器在用户查询是否有车票的时候不需要到总服务器查询,只需要总服务
器定时发送给各个分服务器一个各车站到其他车站是否有票的表就可以了。简单的说,
可能100个分服务器都服务1000个客户某路线的查询,但是票只有500张,这时候完全不
需要精确的预先锁定某500个座位,完全可以告诉这1000个客户有票,然后让他们订购
,总服务器先受到的500个单子自然就能完成购买,后面的500就只能说没票了。反正
1000个人买500张票,你总是要得罪500个人的,谁速度慢就倒霉。
3。分服务器可以根据地理位置或者用户密度安排,保证用户界面响应速度。如果用户
在第一个订单确认前就送出第二个订单,结果就可能两个单子都买了,这种情况下相信
谁也不敢轻易用刷票软件,总服务器也可以很容易的分辨出是否有重复的这种订单然后
简单的拒绝这种单子。
4。总服务器只需要按顺序的从各个分服务器得到当前的待处理订单就可以了。各个分
服务器也不需要严格的统一时间,反正也不可能有谁知道一个北京的晚一分钟的订单抢
到了座位而一个上海的早一分钟的订单反而没枪到座位。对于用户来说,既然大家都知
道票源紧张,自然应该能理解前一秒告诉你有票后一秒你下单的时候就没票了,没有人
会归罪到服务器的排序上。
我觉得订票的互锁问题用这个方式是很容易解决的,查询的问题也很容易解决,不见得
会有多大的难度。当然,最难的是要预计到可能有这些问题,没有预期到可能的问题随
便设计了一个自然就会死的很难看了。
s*****e
发帖数: 16824
2
难不难要看规模,规模一上去了啥都难。就像1+1够简单吧,如果不是整数型,而是要
搞一个无限位数的变量来做,马上难度就上升好几倍,如果同时又要考虑多线程,又上
升几倍,如果还要failsafe,任何异常都可以滚回,又得升几倍,还有分布式计算的
scalable啊,跟银行交易系统交互的瓶颈等等问题。如果这么简单,amazon,ebay这种
专门靠电子交易为生的网站还会被touchpad卡死,岂不是早应该一头撞死了。

【在 u****u 的大作中提到】
: 这里很多人都在说这个卖火车票的网站有多难设计,我真的不太相信。这里我就提一个
: 简单的设计,相信应该能解决所有的问题,大家可以来批评一下会不会出问题:
: 1。网页上来让用户选择时间和起始车站,一个包送到分服务器上查询是否有空。如果
: 有,进入到下一个网页输入各种购买信息,完成后一个包送到分服务器上。这时候的提
: 示是购买要求已受到,但是还不表示购买完成,然后所有的分服务器在后台按照一定顺
: 序和一个总服务器通讯。分服务器把购买的订单给总服务器,总服务器按照受到的时间
: 顺序一个个单子处理,的确有空的就完成购买再送回分服务器,没有空的位子就直接退
: 回无位信息。分服务器收到总服务器的反馈才通知用户。
: 2。每个分服务器在用户查询是否有车票的时候不需要到总服务器查询,只需要总服务
: 器定时发送给各个分服务器一个各车站到其他车站是否有票的表就可以了。简单的说,

z****0
发帖数: 4413
3
中国网络速度不够快
f*******t
发帖数: 7549
4
楼主还是学生吧。商业化的东西哪有那么简单,你当是学校选课系统随便找些学生来写
就行?
当然花几亿太夸张,还有锁票之类的非技术问题,都不是小小码工能解决的
s******8
发帖数: 4192
5
多加几个CAPTCHA就什么都解决了。
h********3
发帖数: 2075
6
从楼主分析的web服务器是瓶颈就可以看出来楼主还只是个外行人。如果只是web服务器
是瓶颈,那太好解决了,完全可以用机群去解决。之前国内有很多人写文章分析难点,
比如左耳朵兄的博客,所有人都已经明确指出难点在数据库上,楼主自己不够内行,至
少也应该先看一下内行的文章再来说评说吧。

【在 u****u 的大作中提到】
: 这里很多人都在说这个卖火车票的网站有多难设计,我真的不太相信。这里我就提一个
: 简单的设计,相信应该能解决所有的问题,大家可以来批评一下会不会出问题:
: 1。网页上来让用户选择时间和起始车站,一个包送到分服务器上查询是否有空。如果
: 有,进入到下一个网页输入各种购买信息,完成后一个包送到分服务器上。这时候的提
: 示是购买要求已受到,但是还不表示购买完成,然后所有的分服务器在后台按照一定顺
: 序和一个总服务器通讯。分服务器把购买的订单给总服务器,总服务器按照受到的时间
: 顺序一个个单子处理,的确有空的就完成购买再送回分服务器,没有空的位子就直接退
: 回无位信息。分服务器收到总服务器的反馈才通知用户。
: 2。每个分服务器在用户查询是否有车票的时候不需要到总服务器查询,只需要总服务
: 器定时发送给各个分服务器一个各车站到其他车站是否有票的表就可以了。简单的说,

u****u
发帖数: 229
7
的确如此,别人已经有了很多的分析是说在数据库上的问题,而且很明确的指出了服务
中的数据库操作的一些导致性能严重下降的问题。实际上如果大家仔细读一下我写的东
西,一个很关键的地方就是怎样避免数据库的瓶颈,是怎么样从系统结构上信息流上优
化,而不是讨论怎样优化某个sql的操作命令。简单的说,如果一个设计能让每个网页
用户都能得到数据库中的精确的实时信息并且直接锁定座位,这的确是会造成很严重的
设计困难的。而实际上并不需要让每个用户能得到精确路程车票信息,通过异步的操作
完全可以让用户使用并不实时并不精确的信息一样完成订票的操作而不产生可以觉察出
的用户体验的下降。使用非实时非精确的信息能降低系统设计的难度,因为对于一个买
票的人来说,有100张票和有90张票并没有什么本质的区别,反正只要买一张,而且对
于春运这种情况本来就是要限制一个客户同时买很多张票,所以在实际上只有90张票的
时候服务器根据“有100张票”的信息回应客户的要求并没有什么可以觉察的区别。当
然,最后只有一张票的时候,服务器说还有票,然后客户下单,过了些时候被退单说没
票了,这种事是肯定会发生的。这一方面只要提示信息写清楚就能让客户预先知道退单
的可能性,另一方面春运这种艰难的旅程大家已经把舒适和便捷的需要压下去了,还有
总是会有买不到票的倒霉蛋的,大家不见的会多这东西有多敏感。
所以说,很严格的照最理想的情况设计系统往往是会有很多非常难解决的技术问题的,
但是一个好的架构师的作用就在于分析系统系统的应用,适当的合理的再满足系统应用
要求的条件下放宽技术要求,往往是能很大程度上的降低设计的难度的。而且架构师的
的关键是要预测到可能出问题的地方并针对性的设计结构。针对这个应用来说,要让全
国的人都实时的查车票,能准确的锁定座位完成购买,还要在短时间内支持巨大的高峰
,的确是很难的,但是如果设计的时候不用实时的查座位有无,不用锁定一个座位再购
买,其实也能完成买票的功能,但是系统设计的难度就低了很多,可能原先一个要
google/amazon年薪百万的设计明星(比如您)才能搞定的系统现在只用几个中国三本
fresh graduate(比如我)就能搞定了。系统的技术含量可能低了很多,但是一样能用
,还有什么可抱怨的?

【在 h********3 的大作中提到】
: 从楼主分析的web服务器是瓶颈就可以看出来楼主还只是个外行人。如果只是web服务器
: 是瓶颈,那太好解决了,完全可以用机群去解决。之前国内有很多人写文章分析难点,
: 比如左耳朵兄的博客,所有人都已经明确指出难点在数据库上,楼主自己不够内行,至
: 少也应该先看一下内行的文章再来说评说吧。

l*******s
发帖数: 1258
8
“分服务器把购买的订单给总服务器,总服务器按照受到的时间顺序一个个单子处理”
这么串行处理 单子多了 整个任务队列老长老长 要处理到啥时候?
如果改成总服务器并行处理 那就又回到了数据库查询并行加速上。还是数据库问题。
r***a
发帖数: 2628
9
难不难看是谁来做。
烂不烂也是看谁来做。
u****u
发帖数: 229
10
当然啦,高峰的时候肯定反应是慢的,这个就好比你在amazon买东西,你下了单后并不
表示你已经买到了这个东西,而是要过个几小时甚至几天以后amazon确定能寄出来后才
收钱确认了你的买卖合同。其实就是一个处理模式。总服务器处理的慢点没关系,关键
是用户收到了确认信息后就会去安心等待了,等个一两小时用户还会说订购很神速;而
不是一个网页总在那里loading什么都不出来,即使只需要等几分钟用户还是会说太慢。
服务器的并行处理根本是两回事。让用户从网页上直接连到服务器查询,连接的数量速
度等根本是不可控的,要优化就很困难;你让几台服务器并行工作处理单子,首先服务
器之间的专用连接可以非常快,其次肯定就这几台机器之间通讯,互相之间的协同很容
易优化。所以虽然同样是数据库的问题,解决的难度是天壤之别。

【在 l*******s 的大作中提到】
: “分服务器把购买的订单给总服务器,总服务器按照受到的时间顺序一个个单子处理”
: 这么串行处理 单子多了 整个任务队列老长老长 要处理到啥时候?
: 如果改成总服务器并行处理 那就又回到了数据库查询并行加速上。还是数据库问题。

相关主题
毛泽东的亲戚排队三天买不到火车票[视频]春运和谐号,一女买了3张票躺着,一男站票
如果我发明一种中文程序语言,会不会出名? (转载)春运中一女子买3张票睡觉,一站票男子不服
方别的不说,抓论文剽窃基本只有漏网的没有抓错的。Kubiak needs to provide convinding evidence. The apology is unacceptable.
进入Military版参与讨论
s****a
发帖数: 6521
11
难不难要看利益树有多大
t****d
发帖数: 488
12
这可不是手快有手慢无的问题。如果象你那样,那500个人就不是抱怨而是马娘了。当
然,就目前的系统来看是花了“大”钱做了烂活。而且很多时候即使网站能用,人家也
不一定放票出来。
c***c
发帖数: 21374
13
这是不可以的
必须当时就显示到底有没有买到。否则在国内,尤其是火车票网购这个事情上,是断然
不会被接受的

慢。

【在 u****u 的大作中提到】
: 当然啦,高峰的时候肯定反应是慢的,这个就好比你在amazon买东西,你下了单后并不
: 表示你已经买到了这个东西,而是要过个几小时甚至几天以后amazon确定能寄出来后才
: 收钱确认了你的买卖合同。其实就是一个处理模式。总服务器处理的慢点没关系,关键
: 是用户收到了确认信息后就会去安心等待了,等个一两小时用户还会说订购很神速;而
: 不是一个网页总在那里loading什么都不出来,即使只需要等几分钟用户还是会说太慢。
: 服务器的并行处理根本是两回事。让用户从网页上直接连到服务器查询,连接的数量速
: 度等根本是不可控的,要优化就很困难;你让几台服务器并行工作处理单子,首先服务
: 器之间的专用连接可以非常快,其次肯定就这几台机器之间通讯,互相之间的协同很容
: 易优化。所以虽然同样是数据库的问题,解决的难度是天壤之别。

u****u
发帖数: 229
14
恐怕这个是正解。搞技术的往往总是从技术层面看问题,其实这个问题估计根本就不是
技术问题。

【在 s****a 的大作中提到】
: 难不难要看利益树有多大
x****u
发帖数: 12955
15

This is absolutely unacceptable in a ticket selling system. If you have to
wait several days, or even just several hours to receive confirmation of
purchase, you would have lost the opportunity to make alternative
arrangements in busy travel season.

【在 u****u 的大作中提到】
: 当然啦,高峰的时候肯定反应是慢的,这个就好比你在amazon买东西,你下了单后并不
: 表示你已经买到了这个东西,而是要过个几小时甚至几天以后amazon确定能寄出来后才
: 收钱确认了你的买卖合同。其实就是一个处理模式。总服务器处理的慢点没关系,关键
: 是用户收到了确认信息后就会去安心等待了,等个一两小时用户还会说订购很神速;而
: 不是一个网页总在那里loading什么都不出来,即使只需要等几分钟用户还是会说太慢。
: 服务器的并行处理根本是两回事。让用户从网页上直接连到服务器查询,连接的数量速
: 度等根本是不可控的,要优化就很困难;你让几台服务器并行工作处理单子,首先服务
: 器之间的专用连接可以非常快,其次肯定就这几台机器之间通讯,互相之间的协同很容
: 易优化。所以虽然同样是数据库的问题,解决的难度是天壤之别。

u****u
发帖数: 229
16
this is unacceptable from individual user perspective, but in a system where
there is more demand than supply, it actually makes sense.
BTW, amazon has been using this model all the time, and it actually did
cause some very unpleasant shopping experience there. But, WTH, ChunYun has
never been pleasant anyway.

to

【在 x****u 的大作中提到】
:
: This is absolutely unacceptable in a ticket selling system. If you have to
: wait several days, or even just several hours to receive confirmation of
: purchase, you would have lost the opportunity to make alternative
: arrangements in busy travel season.

c***c
发帖数: 21374
17
这是绝对不可以的。
靠,买个票要等几个小时几天才知道有没有真买上,耽误我回家,比如说我因此没有买
其他车次的票,你怎么赔我?我砸了你铁道部。

where
has

【在 u****u 的大作中提到】
: this is unacceptable from individual user perspective, but in a system where
: there is more demand than supply, it actually makes sense.
: BTW, amazon has been using this model all the time, and it actually did
: cause some very unpleasant shopping experience there. But, WTH, ChunYun has
: never been pleasant anyway.
:
: to

x****u
发帖数: 12955
18

where
has
A system that's unacceptable from user's point of view has no reason to
exist at all.
Isn't it the reason people are complaining about the current system, that it
has unacceptable performance? Now you propose a system that's unacceptable
even in concept. Simply brilliant.

【在 u****u 的大作中提到】
: this is unacceptable from individual user perspective, but in a system where
: there is more demand than supply, it actually makes sense.
: BTW, amazon has been using this model all the time, and it actually did
: cause some very unpleasant shopping experience there. But, WTH, ChunYun has
: never been pleasant anyway.
:
: to

k*****a
发帖数: 188
19
那100个分服务器都收到500个买票请求呢? 那就是卖5万张票? 然后过一天再告诉
49500个人没有票? 难道要更频繁的定时发送,更趋近真实余票? 多频繁才行?
b***y
发帖数: 14281
20
你发个贴说看不出来有什么难设计的地方,结果却是明知道难在哪里却装疯卖傻。

where
has

【在 u****u 的大作中提到】
: this is unacceptable from individual user perspective, but in a system where
: there is more demand than supply, it actually makes sense.
: BTW, amazon has been using this model all the time, and it actually did
: cause some very unpleasant shopping experience there. But, WTH, ChunYun has
: never been pleasant anyway.
:
: to

相关主题
我X,联邦政府雇员们欠税10个亿! (转载)(ZZ) 8张票7次换乘,在车上的时间省13个小时
Re: 估计Obama会得280-290张票 (转载)48天占领广场是不能被任何社会接受的
博士生买8张票曲线回家 途中转车7次刚才去ABC主页链接到contact us 留了言
进入Military版参与讨论
h*******k
发帖数: 55
21
用镜像服务器可以么。

【在 u****u 的大作中提到】
: 这里很多人都在说这个卖火车票的网站有多难设计,我真的不太相信。这里我就提一个
: 简单的设计,相信应该能解决所有的问题,大家可以来批评一下会不会出问题:
: 1。网页上来让用户选择时间和起始车站,一个包送到分服务器上查询是否有空。如果
: 有,进入到下一个网页输入各种购买信息,完成后一个包送到分服务器上。这时候的提
: 示是购买要求已受到,但是还不表示购买完成,然后所有的分服务器在后台按照一定顺
: 序和一个总服务器通讯。分服务器把购买的订单给总服务器,总服务器按照受到的时间
: 顺序一个个单子处理,的确有空的就完成购买再送回分服务器,没有空的位子就直接退
: 回无位信息。分服务器收到总服务器的反馈才通知用户。
: 2。每个分服务器在用户查询是否有车票的时候不需要到总服务器查询,只需要总服务
: 器定时发送给各个分服务器一个各车站到其他车站是否有票的表就可以了。简单的说,

h*********n
发帖数: 11319
22
不懂技术的人常常有个误区,以为什么技术都是水到渠成, 只要有问题归根到底一定
不是技术问题。
这种人因为没有第一线技术工作的切身体会,不知道其实有很多东西从基本原理上就不
可能实现。
抢touchpad的时候,以slickdeal为指挥中心,几十万用户就横扫了包括bestbuy,
newegg,ebay,amazon在内的所有美国电商网站。touchpad网上总出货量还不到100万台
12306要面对的问题规模比抢touchpad大百倍。

【在 u****u 的大作中提到】
: 恐怕这个是正解。搞技术的往往总是从技术层面看问题,其实这个问题估计根本就不是
: 技术问题。

l*******s
发帖数: 1258
23
NO.
amazon买东西等半天,那是后面有相关人工在处理单子,涉及到库存供应链啥的。跟这
个买票请求等半天是两码事!

慢。

【在 u****u 的大作中提到】
: 当然啦,高峰的时候肯定反应是慢的,这个就好比你在amazon买东西,你下了单后并不
: 表示你已经买到了这个东西,而是要过个几小时甚至几天以后amazon确定能寄出来后才
: 收钱确认了你的买卖合同。其实就是一个处理模式。总服务器处理的慢点没关系,关键
: 是用户收到了确认信息后就会去安心等待了,等个一两小时用户还会说订购很神速;而
: 不是一个网页总在那里loading什么都不出来,即使只需要等几分钟用户还是会说太慢。
: 服务器的并行处理根本是两回事。让用户从网页上直接连到服务器查询,连接的数量速
: 度等根本是不可控的,要优化就很困难;你让几台服务器并行工作处理单子,首先服务
: 器之间的专用连接可以非常快,其次肯定就这几台机器之间通讯,互相之间的协同很容
: 易优化。所以虽然同样是数据库的问题,解决的难度是天壤之别。

o********s
发帖数: 971
24
lz恐怕连上千用户同时进行复杂操作的系统都没有做过才能说出这样的外行话。
真的很难。
租用多少服务器?
用什么样的load balancer?
用什么级别的cache?
用什么级别的bandwidth?
n******1
发帖数: 3756
25
其实卖火车票还是比较简单的,只要分区分域就可以分流,当然用户数据库本身要共享
,其他应该没什么了
O**o
发帖数: 2071
26
这能有多大volume啊。金融交易,black friday, IRS 4月15日,VS fashion
show,这礼拜的super bowl,交易量都比卖火车票只大不小。
你说的这些都是最基本的online transaction要求。天朝的IT水平绝对能做。
做不出来还是说明头儿们不愿意做。上网买票就过程全透明了,没油水了。

【在 s*****e 的大作中提到】
: 难不难要看规模,规模一上去了啥都难。就像1+1够简单吧,如果不是整数型,而是要
: 搞一个无限位数的变量来做,马上难度就上升好几倍,如果同时又要考虑多线程,又上
: 升几倍,如果还要failsafe,任何异常都可以滚回,又得升几倍,还有分布式计算的
: scalable啊,跟银行交易系统交互的瓶颈等等问题。如果这么简单,amazon,ebay这种
: 专门靠电子交易为生的网站还会被touchpad卡死,岂不是早应该一头撞死了。

n******1
发帖数: 3756
27
只大不小,你吹吧,看了峰值数据再说

【在 O**o 的大作中提到】
: 这能有多大volume啊。金融交易,black friday, IRS 4月15日,VS fashion
: show,这礼拜的super bowl,交易量都比卖火车票只大不小。
: 你说的这些都是最基本的online transaction要求。天朝的IT水平绝对能做。
: 做不出来还是说明头儿们不愿意做。上网买票就过程全透明了,没油水了。

O**o
发帖数: 2071
28
瞎掰。online transaction已经是很成熟的技术了。
我做过一个project,IRS e-file. go live那年的4月15日交易量是创历史纪录的。
那已经是N年前的事了。之后无论stream video还是financial transaction, 技术都在
不断成熟完善。
online volume问题都是钱的问题。钱到位了什么都能做。
天朝现在一个小小的卖票网站绝对能做。即不缺钱也不缺技术。问题还是当头儿的不愿意
启动这种project.

万台

【在 h*********n 的大作中提到】
: 不懂技术的人常常有个误区,以为什么技术都是水到渠成, 只要有问题归根到底一定
: 不是技术问题。
: 这种人因为没有第一线技术工作的切身体会,不知道其实有很多东西从基本原理上就不
: 可能实现。
: 抢touchpad的时候,以slickdeal为指挥中心,几十万用户就横扫了包括bestbuy,
: newegg,ebay,amazon在内的所有美国电商网站。touchpad网上总出货量还不到100万台
: 12306要面对的问题规模比抢touchpad大百倍。

k******a
发帖数: 2436
29
不难。如果是private sector不论多难都能作出来。

【在 u****u 的大作中提到】
: 这里很多人都在说这个卖火车票的网站有多难设计,我真的不太相信。这里我就提一个
: 简单的设计,相信应该能解决所有的问题,大家可以来批评一下会不会出问题:
: 1。网页上来让用户选择时间和起始车站,一个包送到分服务器上查询是否有空。如果
: 有,进入到下一个网页输入各种购买信息,完成后一个包送到分服务器上。这时候的提
: 示是购买要求已受到,但是还不表示购买完成,然后所有的分服务器在后台按照一定顺
: 序和一个总服务器通讯。分服务器把购买的订单给总服务器,总服务器按照受到的时间
: 顺序一个个单子处理,的确有空的就完成购买再送回分服务器,没有空的位子就直接退
: 回无位信息。分服务器收到总服务器的反馈才通知用户。
: 2。每个分服务器在用户查询是否有车票的时候不需要到总服务器查询,只需要总服务
: 器定时发送给各个分服务器一个各车站到其他车站是否有票的表就可以了。简单的说,

h*********n
发帖数: 11319
30
我只看示例
京奥售票网站也花了上亿,IBM做的。07年11月放票的时候全国人民包括我自己在内一整
天都连不上的窘样我还记得
京奥总门票数不到200万张,仍然只有火车票的1%.
美国的任何基础设施拿去应付中国的人口都是笑话。
什么IRS的历史纪录,不过是接受信息而已。相当于每个人已经预先分派了一件商品。不
同的transaction之间需要锁么?不同服务器有一致性协议么?
泛泛而谈online transaction就更搞笑了。每张火车票每个站点都是独一无二的商品,
你买2月5号10号车厢64号座从北京到驻马店的硬座票,和你去网上抢尿布抢到多少是多
少,怎么可能类比得起来?
说了半天又回到“技术和资金哪个是根本问题”了
我只是告诉你,以前人类历史上从没有过这种容量的电商网站,现在有了,叫12306.cn


愿意
一定
就不
100

【在 O**o 的大作中提到】
: 瞎掰。online transaction已经是很成熟的技术了。
: 我做过一个project,IRS e-file. go live那年的4月15日交易量是创历史纪录的。
: 那已经是N年前的事了。之后无论stream video还是financial transaction, 技术都在
: 不断成熟完善。
: online volume问题都是钱的问题。钱到位了什么都能做。
: 天朝现在一个小小的卖票网站绝对能做。即不缺钱也不缺技术。问题还是当头儿的不愿意
: 启动这种project.
:
: 万台

相关主题
Disney/ABC News: 快去抢占舆论高地!一个哥们对刘跨越的评价
Why Kimmel's Apology is Unacceptable (转载)每次买不到火车票得去做长途汽车的时候
买不到火车票有没有大牛谈谈火车票的技术挑战在哪?
进入Military版参与讨论
s********r
发帖数: 394
31
ni

★ 发自iPhone App: ChineseWeb 7.8

【在 O**o 的大作中提到】
: 瞎掰。online transaction已经是很成熟的技术了。
: 我做过一个project,IRS e-file. go live那年的4月15日交易量是创历史纪录的。
: 那已经是N年前的事了。之后无论stream video还是financial transaction, 技术都在
: 不断成熟完善。
: online volume问题都是钱的问题。钱到位了什么都能做。
: 天朝现在一个小小的卖票网站绝对能做。即不缺钱也不缺技术。问题还是当头儿的不愿意
: 启动这种project.
:
: 万台

k******a
发帖数: 2436
32
你见过比12306.cn作的更次的网站?

一整
。不

【在 h*********n 的大作中提到】
: 我只看示例
: 京奥售票网站也花了上亿,IBM做的。07年11月放票的时候全国人民包括我自己在内一整
: 天都连不上的窘样我还记得
: 京奥总门票数不到200万张,仍然只有火车票的1%.
: 美国的任何基础设施拿去应付中国的人口都是笑话。
: 什么IRS的历史纪录,不过是接受信息而已。相当于每个人已经预先分派了一件商品。不
: 同的transaction之间需要锁么?不同服务器有一致性协议么?
: 泛泛而谈online transaction就更搞笑了。每张火车票每个站点都是独一无二的商品,
: 你买2月5号10号车厢64号座从北京到驻马店的硬座票,和你去网上抢尿布抢到多少是多
: 少,怎么可能类比得起来?

t*****g
发帖数: 7455
33
分析个屁啊,分析来分析去都触及不到问题的本质:搞开发的是一群低端开发者,钱大
部分都被贪走了
找个大公司,ibm这样的来做,花钱估计只有几分之一,现在的问题都不存在
l******t
发帖数: 55733
34

那得花10倍,功能还只有10分之一

【在 t*****g 的大作中提到】
: 分析个屁啊,分析来分析去都触及不到问题的本质:搞开发的是一群低端开发者,钱大
: 部分都被贪走了
: 找个大公司,ibm这样的来做,花钱估计只有几分之一,现在的问题都不存在

u****u
发帖数: 229
35
其实真的不是技术问题.关键是票少人多,巧妇难为无米之炊,前面人说了,买不到票的
人就是要骂娘,你技术再好设计的再巧妙也没有用,总有人买不到票,人家买不到就是
要骂你.而且你的网站设计的越快,抢票的人就越集中,这是一个正循环,最后总归是要
超过设计的能力,无解。

万台

【在 h*********n 的大作中提到】
: 不懂技术的人常常有个误区,以为什么技术都是水到渠成, 只要有问题归根到底一定
: 不是技术问题。
: 这种人因为没有第一线技术工作的切身体会,不知道其实有很多东西从基本原理上就不
: 可能实现。
: 抢touchpad的时候,以slickdeal为指挥中心,几十万用户就横扫了包括bestbuy,
: newegg,ebay,amazon在内的所有美国电商网站。touchpad网上总出货量还不到100万台
: 12306要面对的问题规模比抢touchpad大百倍。

a***n
发帖数: 3633
36
楼主的办法其实可行。楼主的思路基本上把售票变成了博彩。
先交押金,如果抽到票了,就给票。如果没有抽到
就退钱,返回信息说没有票了。但是应该告诉旅客,你交的钱购买的
是博彩资格,不是车票。每十分钟揭晓一次。
当然这么搞会不会被人骂死,那是社会问题。从技术上讲,楼主的方案
可以用于建立一个低成本博彩系统。

一整
。不

【在 h*********n 的大作中提到】
: 我只看示例
: 京奥售票网站也花了上亿,IBM做的。07年11月放票的时候全国人民包括我自己在内一整
: 天都连不上的窘样我还记得
: 京奥总门票数不到200万张,仍然只有火车票的1%.
: 美国的任何基础设施拿去应付中国的人口都是笑话。
: 什么IRS的历史纪录,不过是接受信息而已。相当于每个人已经预先分派了一件商品。不
: 同的transaction之间需要锁么?不同服务器有一致性协议么?
: 泛泛而谈online transaction就更搞笑了。每张火车票每个站点都是独一无二的商品,
: 你买2月5号10号车厢64号座从北京到驻马店的硬座票,和你去网上抢尿布抢到多少是多
: 少,怎么可能类比得起来?

g*******g
发帖数: 9753
37
由于春运时大部分人买不到票,也就是按这个方案大部分人需要交了钱再退钱,这样别
说要被购票人骂死,就是银行也要骂死你啊!

【在 a***n 的大作中提到】
: 楼主的办法其实可行。楼主的思路基本上把售票变成了博彩。
: 先交押金,如果抽到票了,就给票。如果没有抽到
: 就退钱,返回信息说没有票了。但是应该告诉旅客,你交的钱购买的
: 是博彩资格,不是车票。每十分钟揭晓一次。
: 当然这么搞会不会被人骂死,那是社会问题。从技术上讲,楼主的方案
: 可以用于建立一个低成本博彩系统。
:
: 一整
: 。不

a***n
发帖数: 3633
38
也就是说,由于中国目前的社会形态,导致铁路网上售票无法采用
楼主提出的低成本方案。这本质上不是技术问题,而是体制问题。
把体制造成的问题推给技术人员,是不公平的。

【在 g*******g 的大作中提到】
: 由于春运时大部分人买不到票,也就是按这个方案大部分人需要交了钱再退钱,这样别
: 说要被购票人骂死,就是银行也要骂死你啊!

s*****r
发帖数: 43070
39
IBM来了一样抓瞎,根本没有处理每秒20万次复杂交易的能力

【在 t*****g 的大作中提到】
: 分析个屁啊,分析来分析去都触及不到问题的本质:搞开发的是一群低端开发者,钱大
: 部分都被贪走了
: 找个大公司,ibm这样的来做,花钱估计只有几分之一,现在的问题都不存在

h*********n
发帖数: 11319
40
自恨到一定程度了
奥运抢票系统就是IBM做的。那才叫狗屎一坨

【在 t*****g 的大作中提到】
: 分析个屁啊,分析来分析去都触及不到问题的本质:搞开发的是一群低端开发者,钱大
: 部分都被贪走了
: 找个大公司,ibm这样的来做,花钱估计只有几分之一,现在的问题都不存在

1 (共1页)
进入Military版参与讨论
相关主题
48天占领广场是不能被任何社会接受的铁路售票网问题的关键是每天定时放票
刚才去ABC主页链接到contact us 留了言毛泽东的亲戚排队三天买不到火车票
Disney/ABC News: 快去抢占舆论高地!如果我发明一种中文程序语言,会不会出名? (转载)
Why Kimmel's Apology is Unacceptable (转载)方别的不说,抓论文剽窃基本只有漏网的没有抓错的。
买不到火车票[视频]春运和谐号,一女买了3张票躺着,一男站票
一个哥们对刘跨越的评价春运中一女子买3张票睡觉,一站票男子不服
每次买不到火车票得去做长途汽车的时候Kubiak needs to provide convinding evidence. The apology is unacceptable.
有没有大牛谈谈火车票的技术挑战在哪?我X,联邦政府雇员们欠税10个亿! (转载)
相关话题的讨论汇总
话题: 服务器话题: 问题话题: 设计话题: 用户