由买买提看人间百态

boards

本页内容为未名空间相应帖子的节选和存档,一周内的贴子最多显示50字,超过一周显示500字 访问原贴
Programming版 - 好虫的架构要导致社会动乱
相关主题
如果要做一个铁路售票网站做为一个有买票体验的用户。。。
zz 12306是怎样做成的突然有个想法,区间票能不能实时产生?
老魏的计数器可以一试数据库分票策略
天朝购票的智障系统。。。[合集] 再问一个接受udp数据的问题,急
再举个测试用例。一个比较有趣的面试问题
让老弱残疾扛着打包换车厢还是人吗?一个找电话号码题
再问一个弱问题:为什么程序地址0-0x08000000是不可用的 (转载)本版一天也没有一个帖子,建议改市场定位。
12306,实时系统和非实时系统的用户体验比较今天debug一天
相关话题的讨论汇总
话题: 数据库话题: 10话题: 预售话题: 提前话题: 分钟
进入Programming版参与讨论
1 (共1页)
c******3
发帖数: 296
1
标题党,呵呵。但好虫的设计的问题摆在那。拍砖。
好虫的设计结果:“每天500万成功的单子,数据库每秒1万。”。最多“等10分钟”
如果一次放出当日所有的票的话,只要500秒或不到10分钟就出完了。就算每10分钟卖
500万张票。全天24小时能卖多少?这么卖,整个春运前后30天,全国,全世界的票都
不在话下。而且也就最多等10分钟。可能吗?
春运是上亿人的大迁徙。每张票,十个人抢。500万票后面就有5000万人在抢。你把500
万票拿出来,5000万人从缓存里看到有票,于是提交订票要求。数据库里一下涌进5000
万人。每处理一条要求,后面九条同样要求被数据库事务锁住(row lock)只好排队。
第一个人一秒拿到票,后面的九个人都没买到。最后的第十个人,10秒后得知没买到。
数据库处理完5000万事务,要5000秒,或约一个半小时。这中间有的是买到票的,有的
是没买到的。都要等几秒到一个半小时。也就是说绝大部分人要等10分钟以上才知道是
不是买到票。如果说等个10分钟,就一袋烟的功夫,也就算了。让几千万人等几十分钟
,还不一定买到票,会惹火多少人?这还没算上需要联票事务锁的。
这个问题的根源在于同时并发抢票人太多。你看到有一张票在那儿挂着,其他九个人也
同时看到了。大家都差不多同时去抢。成百上千的抢票软件更是和你同时抢。所以数据
库不是处理一条update,而是十条或更多,更要命的是这些请求都得排成一队一个一个
处理。所以绝不是只等几分钟的。
你会说我还有缓存呢。是的,缓存会挡住一些人,但缓存说有票,也不止就一个人看到
。还是会一张票,多人加无穷多的抢票机同时去数据库抢。
就算是加上数据库有10分钟内处理不了就自动timeout的限制,让用户再重新唰,那用
户会多扫兴?每10分钟就要重新唰,体验不是一般的糟。
惹恼一个老魏就算了。惹恼几千万人可不是闹着玩的。
e**o
发帖数: 5509
2
他那个是预售系统。压根不告诉你有多少张。
就是宣布的时间开始收单。然后慢慢处理。

500
5000

【在 c******3 的大作中提到】
: 标题党,呵呵。但好虫的设计的问题摆在那。拍砖。
: 好虫的设计结果:“每天500万成功的单子,数据库每秒1万。”。最多“等10分钟”
: 如果一次放出当日所有的票的话,只要500秒或不到10分钟就出完了。就算每10分钟卖
: 500万张票。全天24小时能卖多少?这么卖,整个春运前后30天,全国,全世界的票都
: 不在话下。而且也就最多等10分钟。可能吗?
: 春运是上亿人的大迁徙。每张票,十个人抢。500万票后面就有5000万人在抢。你把500
: 万票拿出来,5000万人从缓存里看到有票,于是提交订票要求。数据库里一下涌进5000
: 万人。每处理一条要求,后面九条同样要求被数据库事务锁住(row lock)只好排队。
: 第一个人一秒拿到票,后面的九个人都没买到。最后的第十个人,10秒后得知没买到。
: 数据库处理完5000万事务,要5000秒,或约一个半小时。这中间有的是买到票的,有的

z****e
发帖数: 54598
3
搞没搞错,装啥?
没搞过春运?
以前哪年农民工不是通宵站在售票点排队的?
等个1个小时就要死要活的?
那像去年那样,直接崩溃你是不是要炸大楼啊?
c******3
发帖数: 296
4
设计一个实时的售票系统,要满足那么多人各种不同的要求,是不容易。数据库是不是
也可以分布一下?

【在 z****e 的大作中提到】
: 搞没搞错,装啥?
: 没搞过春运?
: 以前哪年农民工不是通宵站在售票点排队的?
: 等个1个小时就要死要活的?
: 那像去年那样,直接崩溃你是不是要炸大楼啊?

q*c
发帖数: 9453
5
这些人都是矫情。被车管骂的乱跑啥话没有,整夜排队有气不敢发,现在等10 分钟就
要暴乱。。。见过坦克机枪啥样子没?!
根本要不了1小时。 10 分钟已经很保守了,如果预先处理不冲突的路线, 预测进行批
处理,上牛逼多核机器(几万10万级别的普通机器),再提高10倍甚至更多也不是不可
能。

【在 z****e 的大作中提到】
: 搞没搞错,装啥?
: 没搞过春运?
: 以前哪年农民工不是通宵站在售票点排队的?
: 等个1个小时就要死要活的?
: 那像去年那样,直接崩溃你是不是要炸大楼啊?

z****e
发帖数: 54598
6
不是金刚钻别揽瓷器活
real time在这里毫无意义
慢一点不会死人
而且公网本身就不快
数据库可以分库,但是尽量不要太分散
否则分布式事务是很头疼的问题
其实内行没有谁会随便瞧不起12306的
这种事说永远都比做,容易一亿倍

【在 c******3 的大作中提到】
: 设计一个实时的售票系统,要满足那么多人各种不同的要求,是不容易。数据库是不是
: 也可以分布一下?

b*******g
发帖数: 603
7
你犯了一些根本的错误,哪怕5亿人提交要买票,只会进入订单数据库,不会进入余票
数据库。
订单的本身没有冲突,C*之类的数据库可以线性scale out写. 这也是证明了NoSQL的
有用性,传统的数据库做不到scale out write.
余票数目可以每秒更新,并用于数据库外的预处理。这不是精确的,但一旦到0,后面
的订单可以快速并发处理,能支持每秒百万次的写订单,同样每秒百万次写个状态位是
没有压力的。
比如标上失败或者waiting list并且发通知. 所有的这些处理都不需要进余票数据库。
进入余票数据库的,就是500万加上一点最后并发没能锁上的零头而已。同样一旦到0,
手上的订单也足够waiting list了,后面的订单就不收了。
换句话说,成功的订单处理是每秒一万次,车次没票后的处理每秒百万次。两者还是并
发的。

500
5000

【在 c******3 的大作中提到】
: 标题党,呵呵。但好虫的设计的问题摆在那。拍砖。
: 好虫的设计结果:“每天500万成功的单子,数据库每秒1万。”。最多“等10分钟”
: 如果一次放出当日所有的票的话,只要500秒或不到10分钟就出完了。就算每10分钟卖
: 500万张票。全天24小时能卖多少?这么卖,整个春运前后30天,全国,全世界的票都
: 不在话下。而且也就最多等10分钟。可能吗?
: 春运是上亿人的大迁徙。每张票,十个人抢。500万票后面就有5000万人在抢。你把500
: 万票拿出来,5000万人从缓存里看到有票,于是提交订票要求。数据库里一下涌进5000
: 万人。每处理一条要求,后面九条同样要求被数据库事务锁住(row lock)只好排队。
: 第一个人一秒拿到票,后面的九个人都没买到。最后的第十个人,10秒后得知没买到。
: 数据库处理完5000万事务,要5000秒,或约一个半小时。这中间有的是买到票的,有的

b*******g
发帖数: 603
8
12306的现状是碰到这种时候直接瘫痪。别说等10分钟,等1个小时你能成功下个单子都
算运气好。
c******3
发帖数: 296
9
你用一堆C*收订单的话,进入余票数据库前就有个多C*的sort问题,这个还真没数。
即便这不成问题,你的设计是基于只算前500万,后面几亿反正没票就都不用算了。这
不服和实际。每天最多需要卖500万票,那进入订单数据库的几亿可不是都定同一天的
票。春运30天,1。5亿票,很可能春运当天几亿订单就来了。你得连续地算前1。5亿票
,才能踢回乘下的。算完1。5亿票,30个10分钟过去了。

【在 b*******g 的大作中提到】
: 你犯了一些根本的错误,哪怕5亿人提交要买票,只会进入订单数据库,不会进入余票
: 数据库。
: 订单的本身没有冲突,C*之类的数据库可以线性scale out写. 这也是证明了NoSQL的
: 有用性,传统的数据库做不到scale out write.
: 余票数目可以每秒更新,并用于数据库外的预处理。这不是精确的,但一旦到0,后面
: 的订单可以快速并发处理,能支持每秒百万次的写订单,同样每秒百万次写个状态位是
: 没有压力的。
: 比如标上失败或者waiting list并且发通知. 所有的这些处理都不需要进余票数据库。
: 进入余票数据库的,就是500万加上一点最后并发没能锁上的零头而已。同样一旦到0,
: 手上的订单也足够waiting list了,后面的订单就不收了。

f******y
发帖数: 2971
10
之前的争论没怎么看,不过网上买票等10分钟是很长的。而且还大多数人等到的结果是
没买到票。这用户体验是很糟糕的。很多人用的时候心里都会骂这网站做的真SB.
老魏的要等多久?

500
5000

【在 c******3 的大作中提到】
: 标题党,呵呵。但好虫的设计的问题摆在那。拍砖。
: 好虫的设计结果:“每天500万成功的单子,数据库每秒1万。”。最多“等10分钟”
: 如果一次放出当日所有的票的话,只要500秒或不到10分钟就出完了。就算每10分钟卖
: 500万张票。全天24小时能卖多少?这么卖,整个春运前后30天,全国,全世界的票都
: 不在话下。而且也就最多等10分钟。可能吗?
: 春运是上亿人的大迁徙。每张票,十个人抢。500万票后面就有5000万人在抢。你把500
: 万票拿出来,5000万人从缓存里看到有票,于是提交订票要求。数据库里一下涌进5000
: 万人。每处理一条要求,后面九条同样要求被数据库事务锁住(row lock)只好排队。
: 第一个人一秒拿到票,后面的九个人都没买到。最后的第十个人,10秒后得知没买到。
: 数据库处理完5000万事务,要5000秒,或约一个半小时。这中间有的是买到票的,有的

相关主题
让老弱残疾扛着打包换车厢还是人吗?做为一个有买票体验的用户。。。
再问一个弱问题:为什么程序地址0-0x08000000是不可用的 (转载)突然有个想法,区间票能不能实时产生?
12306,实时系统和非实时系统的用户体验比较数据库分票策略
进入Programming版参与讨论
m**********j
发帖数: 8645
11
老魏只管计数器,其它实质的责任完全都推出去了。其做法,完全符合印度方式。

【在 f******y 的大作中提到】
: 之前的争论没怎么看,不过网上买票等10分钟是很长的。而且还大多数人等到的结果是
: 没买到票。这用户体验是很糟糕的。很多人用的时候心里都会骂这网站做的真SB.
: 老魏的要等多久?
:
: 500
: 5000

q*c
发帖数: 9453
12
按时间 sharding, 全部前台分布完成。不需要几秒钟。

【在 c******3 的大作中提到】
: 你用一堆C*收订单的话,进入余票数据库前就有个多C*的sort问题,这个还真没数。
: 即便这不成问题,你的设计是基于只算前500万,后面几亿反正没票就都不用算了。这
: 不服和实际。每天最多需要卖500万票,那进入订单数据库的几亿可不是都定同一天的
: 票。春运30天,1。5亿票,很可能春运当天几亿订单就来了。你得连续地算前1。5亿票
: ,才能踢回乘下的。算完1。5亿票,30个10分钟过去了。

g*****g
发帖数: 34805
13
你先好好想想,春运热门线路预售基本是提前几天一天卖一天,
而不是一天把整个春运的票都预售了。冷门线路票都卖不完,订单比票少,可以忽略不
计。
另外,这个系统只允许一个帐号每天下一个单子,一个单子最多5张票,但可以有很多
备选,重复下单只会让你往后排。所以最多的时候每天恐怕也就几千万单子。
你这个都不符合现在的需求。
另外,分布式排序本来就是C*的强项,只要你不需要实时读,就没有问题。

【在 c******3 的大作中提到】
: 你用一堆C*收订单的话,进入余票数据库前就有个多C*的sort问题,这个还真没数。
: 即便这不成问题,你的设计是基于只算前500万,后面几亿反正没票就都不用算了。这
: 不服和实际。每天最多需要卖500万票,那进入订单数据库的几亿可不是都定同一天的
: 票。春运30天,1。5亿票,很可能春运当天几亿订单就来了。你得连续地算前1。5亿票
: ,才能踢回乘下的。算完1。5亿票,30个10分钟过去了。

c******3
发帖数: 296
14
不确定铁道部是不是一上来就能让买春运30天内任何一天的票。因为咱在美国,没用过
12306,算是闭门造车。但按常理,应该不是只放出某一天的票。按你的方案,最长等
待10分钟是基于只能买某个特定一天的票的。一旦是好几天的票都可预订,你的系统最
长等待时间就是Nx10分钟,N是当天允许预订的车票天数。这样下来,体验是很糟的。
“这个系统只允许一个帐号每天下一个单子”,开玩笑吧。你让用户上网,好容易下个
单,10分钟后通知他没票了,明天才能再来买?
总体来说,你靠百台分布式C*收订单,按你说的百万/秒,理论上是可以瞬时间收下亿
次请求
。但你的中心余票数据库实际上完全没有能力实时或在10分钟内处理这么多出票请求。
所以从解决问题的角度说,你这个设计根本是伪分布式,最后还是都汇总到一台中心机
器,仍然没解决12306的出票难题。

【在 g*****g 的大作中提到】
: 你先好好想想,春运热门线路预售基本是提前几天一天卖一天,
: 而不是一天把整个春运的票都预售了。冷门线路票都卖不完,订单比票少,可以忽略不
: 计。
: 另外,这个系统只允许一个帐号每天下一个单子,一个单子最多5张票,但可以有很多
: 备选,重复下单只会让你往后排。所以最多的时候每天恐怕也就几千万单子。
: 你这个都不符合现在的需求。
: 另外,分布式排序本来就是C*的强项,只要你不需要实时读,就没有问题。

n*****t
发帖数: 22014
15
这种排队就是扯淡。
北京到上海一天几十次车,你让农民工兄弟自己选,就算都选,还得排序哪个优先。UX
的骂死你不说,别说农民工了,office lady 都不一定知道 drag n drop ?整了半小
时没弄完,你这边买定收手了。过十分钟告诉人刚才选的都没,接着整吧,又是半小时
,还是没票。
几个小时过去了,北京到上海全卖完了,突然想起来我到南京、苏州也成啊,大不了出
站补票,继续折腾。一狠心,年二十九的头等舱我也要了,少请 2 天价能赚回来点,
结果还是没票,麻痹的。
更复杂的情况还有,上海到昆明我要卧铺,但是我可以从南昌开始买卧铺,之前硬板就
行,或者卧铺到贵阳最后一个半天我站着问题也不大。诸如此类。
对比现行系统,查询北京到上海,刷一下都给你列出了,哪些有硬座哪些有软卧,你点
进去下单就是了。都没有的话,再查一个北京到南京或苏州的,也是一个简单查询。

【在 c******3 的大作中提到】
: 不确定铁道部是不是一上来就能让买春运30天内任何一天的票。因为咱在美国,没用过
: 12306,算是闭门造车。但按常理,应该不是只放出某一天的票。按你的方案,最长等
: 待10分钟是基于只能买某个特定一天的票的。一旦是好几天的票都可预订,你的系统最
: 长等待时间就是Nx10分钟,N是当天允许预订的车票天数。这样下来,体验是很糟的。
: “这个系统只允许一个帐号每天下一个单子”,开玩笑吧。你让用户上网,好容易下个
: 单,10分钟后通知他没票了,明天才能再来买?
: 总体来说,你靠百台分布式C*收订单,按你说的百万/秒,理论上是可以瞬时间收下亿
: 次请求
: 。但你的中心余票数据库实际上完全没有能力实时或在10分钟内处理这么多出票请求。
: 所以从解决问题的角度说,你这个设计根本是伪分布式,最后还是都汇总到一台中心机

g*****g
发帖数: 34805
16
不用脑子好歹也得会 Google吧,预售自然是一天卖一天。到第二天热门的必然不剩。

【在 c******3 的大作中提到】
: 不确定铁道部是不是一上来就能让买春运30天内任何一天的票。因为咱在美国,没用过
: 12306,算是闭门造车。但按常理,应该不是只放出某一天的票。按你的方案,最长等
: 待10分钟是基于只能买某个特定一天的票的。一旦是好几天的票都可预订,你的系统最
: 长等待时间就是Nx10分钟,N是当天允许预订的车票天数。这样下来,体验是很糟的。
: “这个系统只允许一个帐号每天下一个单子”,开玩笑吧。你让用户上网,好容易下个
: 单,10分钟后通知他没票了,明天才能再来买?
: 总体来说,你靠百台分布式C*收订单,按你说的百万/秒,理论上是可以瞬时间收下亿
: 次请求
: 。但你的中心余票数据库实际上完全没有能力实时或在10分钟内处理这么多出票请求。
: 所以从解决问题的角度说,你这个设计根本是伪分布式,最后还是都汇总到一台中心机

g*****g
发帖数: 34805
17
得了吧,现在是看得到,提交没反应。一刷几个小时没票了。

UX

【在 n*****t 的大作中提到】
: 这种排队就是扯淡。
: 北京到上海一天几十次车,你让农民工兄弟自己选,就算都选,还得排序哪个优先。UX
: 的骂死你不说,别说农民工了,office lady 都不一定知道 drag n drop ?整了半小
: 时没弄完,你这边买定收手了。过十分钟告诉人刚才选的都没,接着整吧,又是半小时
: ,还是没票。
: 几个小时过去了,北京到上海全卖完了,突然想起来我到南京、苏州也成啊,大不了出
: 站补票,继续折腾。一狠心,年二十九的头等舱我也要了,少请 2 天价能赚回来点,
: 结果还是没票,麻痹的。
: 更复杂的情况还有,上海到昆明我要卧铺,但是我可以从南昌开始买卧铺,之前硬板就
: 行,或者卧铺到贵阳最后一个半天我站着问题也不大。诸如此类。

c******3
发帖数: 296
18
这个还真没google到。
”1月9日,当日开始出售1月28日的火车票,是今年的售票高峰日。这一天,12306网页
点击量高达144亿次,相当于全中国每人至少在12306网站点击了10次。这一天的网页浏
览量高达88亿次,相当于全中国每人都浏览了12306网站6次页面。“
即便有这样的预售政策,也够脑残的:通知-今天本网站只预售明天的票,想买后天的
,等明儿吧。
咱码工没本事搞不定,看来只好抱官府大腿了。最好再加上几条预售规则:身份证最后
一位是奇数的,不能在偶数日预定车票,反之亦然。流量力马下降一半。去年抢到过预售
票的,今年不许参加预售,把公平留给其他人。流量又力马下降一半。呵呵,都是冠冕
堂皇的理由呀。这样几条预售规则下来,张三李四设计的系统都可搞定12306了。

【在 g*****g 的大作中提到】
: 不用脑子好歹也得会 Google吧,预售自然是一天卖一天。到第二天热门的必然不剩。
g*****g
发帖数: 34805
19
那说明你连google都不会用。用点脑子都明白怎么回事。先弄明白需求再做设计。你这
纯粹屁股决定脑袋。
关于2014年春运售票的公告
[2013-12-07]
为了做好2014年春运车票发售工作,现将有关事项公告如下:
一、车票预售期
图定旅客列车互联网、电话订票预售期为20天,即2013年12月28日发售2014年1月
16日(春运第一天)车票;车站窗口、代售点、自动售票机预售期为18天,即2013年12
月30日发售2014年1月16日(春运第一天)车票。
2014年春运期间临时加开的旅客列车(以下简称“临客”)车票预售期提前,互联
网、电话订票预售期为25天,即2013年12月23日发售2014年1月16日(春运第一天)车
票;车站窗口、代售点、自动售票机预售期为23天,即2013年12月25日发售2014年1月
16日(春运第一天)车票。

【在 c******3 的大作中提到】
: 这个还真没google到。
: ”1月9日,当日开始出售1月28日的火车票,是今年的售票高峰日。这一天,12306网页
: 点击量高达144亿次,相当于全中国每人至少在12306网站点击了10次。这一天的网页浏
: 览量高达88亿次,相当于全中国每人都浏览了12306网站6次页面。“
: 即便有这样的预售政策,也够脑残的:通知-今天本网站只预售明天的票,想买后天的
: ,等明儿吧。
: 咱码工没本事搞不定,看来只好抱官府大腿了。最好再加上几条预售规则:身份证最后
: 一位是奇数的,不能在偶数日预定车票,反之亦然。流量力马下降一半。去年抢到过预售
: 票的,今年不许参加预售,把公平留给其他人。流量又力马下降一半。呵呵,都是冠冕
: 堂皇的理由呀。这样几条预售规则下来,张三李四设计的系统都可搞定12306了。

c******3
发帖数: 296
20
大爷,最基本的需求是实时呀。这点都做不到,也就只能发表在这了。

【在 g*****g 的大作中提到】
: 那说明你连google都不会用。用点脑子都明白怎么回事。先弄明白需求再做设计。你这
: 纯粹屁股决定脑袋。
: 关于2014年春运售票的公告
: [2013-12-07]
: 为了做好2014年春运车票发售工作,现将有关事项公告如下:
: 一、车票预售期
: 图定旅客列车互联网、电话订票预售期为20天,即2013年12月28日发售2014年1月
: 16日(春运第一天)车票;车站窗口、代售点、自动售票机预售期为18天,即2013年12
: 月30日发售2014年1月16日(春运第一天)车票。
: 2014年春运期间临时加开的旅客列车(以下简称“临客”)车票预售期提前,互联

相关主题
[合集] 再问一个接受udp数据的问题,急本版一天也没有一个帖子,建议改市场定位。
一个比较有趣的面试问题今天debug一天
一个找电话号码题骆驼祥子与硅工 (转载)
进入Programming版参与讨论
g*****g
发帖数: 34805
21
你丫就是屁股决定脑袋,最基本的要求是网站有响应,现在都没响应有个屁实时。
宁可刷几个小时单子交不上去,非要跟我别扭等不了10分钟。

【在 c******3 的大作中提到】
: 大爷,最基本的需求是实时呀。这点都做不到,也就只能发表在这了。
e**o
发帖数: 5509
22
转载:火车票详细的放票时间揭秘
来源: 丁雷的日志
一 关于放票时间
我们可能只知道“提前10天售火车票”这个信息,也就是说,火车票只在开车前10天放
一次票。事实上远非如此。我把目前观察到的放票时间在这里列给大家:
1.提前20天晚上19:00,放20天后的动车组车票和Z字头车票。这个时间,一般不会有
什么人抢动车组车票(毕竟动车组不会很抢手)。但一些重点线路(客流量大,车少,
车次时间合适)的Z车车票在这个时间已经会被包走相当可观的数量。比如Z37,Z77
,这两次车是发往武昌、汉口的直达车,夕发朝至,并且挂许多节硬卧车厢,湖北客流
量一向较大,所以这两次车的硬卧提前20天就会被包走三分之一(在单位和票贩子手里
)。剩余的留在网上,当出行高峰来临时(比如暑运),在开车前15天左右就会被全部
卖光(这也就是为什么提前“很多”天依然买不到Z车硬卧票的原因)。
2.提前18天早晨8:00,放18天后的动车异地票以及一小部分Z车异地票。但多是跨局列
车票,比如沈阳北-太原D191的动车票[跨沈京两局];管内[一个铁路局之内]的动车票
不一定这个时候放,比如济南-青岛的D6001,提前18天有时能在北京买到,有时就买不
到。至于具体什么时候放,要看车次所在铁路局的政策。
3.提前12天早晨8:00,放12天后的D[管内部分]、Z车异地票。因为铁路是计划运输,
每列车几乎都会给出一些全国范围的“共享票额”,也就是这些票额只供始发站之外的
全国各站用,始发站不可以用。这样,比如提前12天的时候,在天津买不到Z41到上海
的票,可是这时候在北京(甚至在某些边远的站,如西宁),还是可以调用全国共享票
额打出来票。返程票也是同样道理。比如提前12天就可以买12天后的南昌-北京西Z68,
但得到的多是上铺。
4.提前10天晚上19:00,放10天后的T、K和普通列车始发票。这是极其重要的放票黄金
时间!! 基本上除了T17、T47、T69、T41这样的极紧张车次之外,绝大多数车都可以
在这个时间打出票来。我们所谓的“提前10天排队买票去”,说的就是在这个时间去窗
口趴票。不过晚七点一到,马上前几手票都必定是票贩子的。运气好的排在前面的乘客
,可能会在19:15分左右(当然是在票贩子和熟人的票基本搞定之后)抢到几张剩余的
自己需要的票(往往是硬卧上铺等残羹冷炙……)。
5.提前10天晚上19:20~20:00,这是“捡票”时间。有那些七点时被别人抢走,挂上
了,但最终没出票,又放回票池的那些票,这个时候还有希望被重新抢回来。不要以为
这个时候来算是来晚了,尤其是要买那些相对偏僻地区车次的旅客,这个时候很有可能
再捡回几张“漏儿”。比如我曾亲自在19:35分的时候捡到两张2189到乌兰浩特的硬卧
(京通线和白阿线的时间合适的始发空调车,卧铺相当难买)。为什么会捡到?因为去
这些地方虽然票紧,但毕竟去的人不是很多,所以票贩子很有可能抢到手之后再把票放
回来(毕竟他们的行动是取决于购票人需求的)。
6.提前9天早晨8:00,放9天后的T、K和普通列车异地票。这个时候可以随意打全国任
意车次的票,而且不用抢,因为买异地票的旅客现在还不算多。加上早晨代售点不忙,
因此这个时候是买异地票的最佳时机。不过不一定每辆车每种席位都有给全国公用的预
留票额,比如我曾在第一时间看到T197郑州-乌鲁木齐的车只给异地留硬卧和软卧,想
买硬座是买不到的。
7.提前3天晚上20:00,这是第二个黄金时间。这时车站会把给各大旅行社和各部委的
预留票没有卖出去的部分放出来。一般而言,每趟始发车这时候都会有机会抢到票,但
往往只放出来15张左右,而且还建立在这样一个前提之上——预留票没有被公家买走用
掉。如果那次车恰好被公家包走,那么这时候抢也是白抢,就比如T41这类车,内部已
经都把预留票买走了,因为不剩,所以就不放出来。
8.提前1天中午12:00,这是第三个黄金时间。这时候车站会把给铁路系统内部预留的
票(给路局以及相关部门)没有用的剩余部分放出来。和提前3天抢票类似,如果没能
有剩余的,那么也就不会放出来。一般而言,这个时候抢票抢到的几率相对大些(当然
只是相对的,和提前10天第一时间抢票抢到的份额显然不是一个数量级),因为铁路内
部并没有那么多人要出去。
9.提前1天下午17:00,放某些特定车次的加挂车厢。铁路部门会统计和分析每天各线
路的客流情况,在一些线路的重点列车上加挂1-2节硬座或硬卧车厢。比较容易放加挂
的车是湘鄂赣桂等地区,比如T5、T189、Z37等车,如果加挂了,那么就意味着有100多
张票放出来,这个时候抢票会抢到大份额。但问题是放不放加挂,哪辆车放加挂,哪天
放记挂,这是没有固定规律的,如果能够探听到铁路部门的内部消息当然最好,如果完
全不知道,就只能靠经验推断(比如 T5 Z59 T189等都是放过加挂的车,尤其T5是经常
放加挂的车),这时候到了五点死蹲这些车次,就能弄出来票。
10.提前1天下午18:00,放车站“窗口票”“抽屉票”。车站有时会把自己提前打出来
的票之中的剩余部分在这个时候放到网上去,还有就是把窗口的退票(平时没有时间放
到网上去或是故意留着给内部认识人)统一放回去。再有就是12:00没有放完的
部分(有时领导中午决定不了第二天走不走,如果这时候决定了不走,就会把预留票放
出来)。但总之这个时候抢到票的概率比较小。
11.提前1天凌晨0:00。这个时间是最绝的,往往在高峰期才会在这个时候放“死票”
(又叫“机动预留票”,这种票在网上能查到有多少张,但就是打不出来,是车站不给
。和前文所述“预留票”不同,预留票究竟有多少完全是暗箱操作,售票网上根本
查不出来)(也就是没有被任何人订走,但被车站提前锁定的那些‘机动票’,比如
Z29等车常常被锁住的硬卧票[上中下各30张左右])。这些票的具体用途,车站也说不
很清楚,只是希望票别都散出去买的那么快,万一内部或是机关部门有个什么临时安排
需要出行,而内部预留票又不够的时候,再动用这些票。如果这些票在开车前一天晚上
还是没有人要,那么就在零点放出去。
12.开车前24小时,打破“区段限售”,也称“松绑”。比如T7在预售期内给石家庄、
郑州各预留20张座位(这些座位只卖给去石家庄、郑州的乘客,去郑州以远的乘客不能
买),但这些预留座位如果没有卖光,那么在开车前24小时的时候这些票就会变成不限
售的公用票(也就是说这些座票也可以卖给去成都等地的乘客了)。松绑相当于一次放
票。
13.开车前4个半小时,每辆车各放出最后六张“底牌”。这些“底牌”往往是站长手里
攥着的特批票,如果没有用,就会在开车前4个半小时放到网上去。这也就是为什么有
时临走前直接去车站买票还会很幸运地买到十天前都抢不到的票的原因。

预售

【在 c******3 的大作中提到】
: 这个还真没google到。
: ”1月9日,当日开始出售1月28日的火车票,是今年的售票高峰日。这一天,12306网页
: 点击量高达144亿次,相当于全中国每人至少在12306网站点击了10次。这一天的网页浏
: 览量高达88亿次,相当于全中国每人都浏览了12306网站6次页面。“
: 即便有这样的预售政策,也够脑残的:通知-今天本网站只预售明天的票,想买后天的
: ,等明儿吧。
: 咱码工没本事搞不定,看来只好抱官府大腿了。最好再加上几条预售规则:身份证最后
: 一位是奇数的,不能在偶数日预定车票,反之亦然。流量力马下降一半。去年抢到过预售
: 票的,今年不许参加预售,把公平留给其他人。流量又力马下降一半。呵呵,都是冠冕
: 堂皇的理由呀。这样几条预售规则下来,张三李四设计的系统都可搞定12306了。

c******3
发帖数: 296
23
一旦政策变得亲民些,容许预售多天的票,这个设计就更不灵了。
做了这么多分析,结论就是以后别人向你忽悠分布式多牛,cloud多强大,千万别轻信
。那都是有前提的。在别人那里好用的,在你这里未必适用。当然这也适于任何热门技
术。

【在 e**o 的大作中提到】
: 转载:火车票详细的放票时间揭秘
: 来源: 丁雷的日志
: 一 关于放票时间
: 我们可能只知道“提前10天售火车票”这个信息,也就是说,火车票只在开车前10天放
: 一次票。事实上远非如此。我把目前观察到的放票时间在这里列给大家:
: 1.提前20天晚上19:00,放20天后的动车组车票和Z字头车票。这个时间,一般不会有
: 什么人抢动车组车票(毕竟动车组不会很抢手)。但一些重点线路(客流量大,车少,
: 车次时间合适)的Z车车票在这个时间已经会被包走相当可观的数量。比如Z37,Z77
: ,这两次车是发往武昌、汉口的直达车,夕发朝至,并且挂许多节硬卧车厢,湖北客流
: 量一向较大,所以这两次车的硬卧提前20天就会被包走三分之一(在单位和票贩子手里

g*****g
发帖数: 34805
24
一旦政策更灵活,我这里延迟是变大。太监那里就是死十次跟死一百次的区别。叫板总
是容易的,能找出可行的妥协才是困难的。认为丢单比延迟实时的都是屁股决定脑袋。

【在 c******3 的大作中提到】
: 一旦政策变得亲民些,容许预售多天的票,这个设计就更不灵了。
: 做了这么多分析,结论就是以后别人向你忽悠分布式多牛,cloud多强大,千万别轻信
: 。那都是有前提的。在别人那里好用的,在你这里未必适用。当然这也适于任何热门技
: 术。

1 (共1页)
进入Programming版参与讨论
相关主题
今天debug一天再举个测试用例。
骆驼祥子与硅工 (转载)让老弱残疾扛着打包换车厢还是人吗?
有一天python会不会像perl一样悄悄的消亡了 (转载)再问一个弱问题:为什么程序地址0-0x08000000是不可用的 (转载)
随着规模增加,消耗资源跟着增加的玩意都没啥前景可言12306,实时系统和非实时系统的用户体验比较
如果要做一个铁路售票网站做为一个有买票体验的用户。。。
zz 12306是怎样做成的突然有个想法,区间票能不能实时产生?
老魏的计数器可以一试数据库分票策略
天朝购票的智障系统。。。[合集] 再问一个接受udp数据的问题,急
相关话题的讨论汇总
话题: 数据库话题: 10话题: 预售话题: 提前话题: 分钟