由买买提看人间百态

topics

全部话题 - 话题: 12306
首页 上页 1 2 3 4 5 6 7 8 9 10 下页 末页 (共10页)
f*********n
发帖数: 148
1
http://www.12306.cn/mormhweb/kyfw/
一次都没成功,有人成功过么?
谢谢!
v*********u
发帖数: 10464
2
美国做个网站那么贵比12306贵多了,码农真幸福
看来美国的码农比大陆的幸福多了,好多钱啊
e*********r
发帖数: 164
3
如果我告诉你,我作为一个硕士生因为回国办事,要出行购买火车票,而且发现我被
自己的无知难住了,买不了车票!你会不会说我就是一弱智啊!卧槽!世界上就有一个
这么奇葩的机构,制造了这么一个牛逼的网站!这真不是玩笑,这是一个很冷的幽默。
冷的你三观尽毁,冷的你无地自容。你不信啊?你上来试试啊!
事情是这样的,公司跟国内几个机构有业务往来,我呢作为一个国内人员,当然被优
先选择派回来,办理相关业务。国内几个机构呢,还不在一个地方,最近的也有几百公
里。最远的3000公里左右。所以选择火车出行是必要的。网络这么发达,所有事坐在办
公室就办了。有人告诉我,上12306购票。
过程其实很简单,就那么几步,跟把大象关进冰箱没啥区别。首先注册个人信息,因
为要实名认证。接下来就是噩梦的开始了!注册完了,重新登录吧,卧槽!眼前跳出来
十多个图片,需要验证码!让你从什么萝卜,白菜,人参,橘子,橙子中,选择正确的
图片。图片的那么大点,渣渣的分辨率。鬼也分不清橘子和柚子,萝卜和人参啊!我是
筋疲力尽了。
换一组又一组,最后终于来了几个明星,莱昂纳多和李琦,郭达跟杰森斯坦森!没有人
性啊!算了吧,我... 阅读全帖
l*****9
发帖数: 9501
4
【 以下文字转载自 Programming 讨论区 】
发信人: falconsniper (Aurora's【X_1835】), 信区: Programming
标 题: Re: 从12306来看,国内IT水平不高
发信站: BBS 未名空间站 (Sun Jan 12 08:42:49 2014, 美东)
h*********n
发帖数: 11319
5
来自主题: Joke版 - 12306网站:
典型文盲喷子
12306那种规模花10亿能搞定就是超高性价比
尼玛当年奥运抢票网站包给IBM做的,也收了快10亿,才几千万并发,结果一放票就挂
了,过一个星期才能出票
O8care网站5亿美元包给Michelle同学的皮包公司,连个屁都没做出来。
d**********x
发帖数: 4083
6
为啥不是拉着一堆人的车?
货物你可以选择自己合适的路线,人就要这一段的票,能一样吗?难不成人家想要某次
直达你给人家三次转车?乘客能和土豆一样运吗?物流,你能运筹,订票是顾客定死的
,你拿什么运?我这里说的复杂度不是分配算法上的复杂度,而是在顾客定了分段票之
后的同步、更新数据库问题。
这可能是个大问题也可能不是,我没有12306的统计数据。但是对于国营企业的开发,
肯定是个没法解决的问题
f*******t
发帖数: 7549
7
其实懂行的人不太骂12306。
比如 http://coolshell.cn/articles/6470.html
P********l
发帖数: 452
8
春运火车票今起开售 开售当日12306网站即崩溃(图)
http://www.wenxuecity.com/news/2013/12/27/2894216.html
元方怎么看?
t*****n
发帖数: 4908
9
来自主题: Programming版 - 12306的方案
魏老师是12306组的马甲?

HP
11
j********x
发帖数: 2330
10
来自主题: Programming版 - 12306的方案
连订票的业务流程都没搞清楚就在scale out。。。能讲讲scale out一个复杂业务流程
和一个简单的key value store的区别么?我很好奇12306的业务逻辑流程啥样的,如果
本身业务流程耦合很严重,除非改善铁路订票的工作流程,怎么可能说scale out就
scale out。。。
n****1
发帖数: 1136
11
来自主题: Programming版 - 12306的方案
>>12306的瓶颈其实是核心节点的CPU、内存性能。但是这个性能的提升不是朝夕的事情
,而是受限于摩尔定律,基本上每两年才能翻一倍多些。
还有这种排队/名额分派算法是cs里很tricky的东西,因为名额是inter-dependent
among services. 极端例子就是md5 checksum, 加机器可以scale out吗?

scale
m**********j
发帖数: 8645
12
对于攻击12306的,虽然对破解人在技术上的能力大家都可以肯定。
但在道德和法律上,必须扼杀。
具体措施就是抓到一个,杀一个,并剥夺其个人和其子女的政治权力终身。
l*****9
发帖数: 9501
13
嗯,其实就是尽量decoupling,服务器可以随便增加,从而得到更好的performance。
12306加服务器没用,说明架构有问题
z****e
发帖数: 54598
14
人家12306才用了17个nodes
你用了50个
3倍了
n****1
发帖数: 1136
15
问题是铁道部所有的窗口都是能卖联程票的, 结果堂堂国有的最牛IT系统, 连卖票窗口
都比不过, 媒体会怎么写? 群众会怎么骂?
铁路出票系统一直以来都是强耦合的, 宕机年年有, 大家习惯了. 但为了技术方便而随
便更改游戏规则是要担政治风险的.
我感觉12306并不是老魏的方案, 而是两者的折中. 其实阿里巴巴也参与设计了, 能做
到现在这个样子, 已经是能平衡各方利益了.
l*****9
发帖数: 9501
16
系统自动出联票,计算量会大很多。查询量,订单量,任何其他系统和12306相比都要
小几个量级
h*d
发帖数: 19309
17
来自主题: Programming版 - 从12306来看,国内IT水平不高
12306找IBM来的,结果IBM说作不了。
amazon AWS问题造成netflix都当了好几次了,facebook/gmail最近也都出过一些问题。
h*d
发帖数: 19309
18
来自主题: Programming版 - 从12306来看,国内IT水平不高
发信人: helloterran (hello), 信区: ITExpress
标 题: 12306毫无疑问是人类历史上最牛鼻的电商网站
发信站: 水木社区 (Thu Jan 24 09:31:06 2013), 站内 [累计积分奖励: 100/0]
2011年美国疯抢touchpad,我也参和了一下
有个找deal 的论坛叫slickdeal,上面有人实时发帖告诉大家哪里还有货
问题是,这个帖子发出来以后两分钟内,该目标网站一定瘫痪。一时间slickdeal变成
了大规模ddos的指挥中心,打哪指哪,横扫了一大批在线零售站点
第一个倒掉的是hp自己的hp store
然后bestbuy
然后newegg
接下来连ebay也down掉十几分钟
等他们恢复访问,那一定是已经OOS了
唯一一个在有货时一直可以访问的是amazon。当然amazon有自己的云服务,对爆发式的
访问没有那么不堪一击。但是事后大家发现,amazon超售了好几倍的量。显然他家的这
次交易是不加锁,没有一致性检查的
最后,这个横扫整个IT界的touchpad,总出货量多少呢?100万出头而已,其中还只有
一半是在... 阅读全帖
h******t
发帖数: 80
19
来自主题: Programming版 - 从12306来看,国内IT水平不高
12306可能水平是不高,不过熬过这段出来的工程师绝对以后是大拿,在美国有几个人
能有这么大流量的工作经验啊。
l*****9
发帖数: 9501
20
来自主题: Programming版 - 从12306来看,国内IT水平不高
obamacare访问量低几个量级,复杂性要高于12306
l*****9
发帖数: 9501
21
来自主题: Programming版 - 从12306来看,国内IT水平不高
IBM给12306开价多少?软件10亿,硬件百亿?其实这个价钱不出格,自己开发肯定低很多
g*****g
发帖数: 34805
22
来自主题: Programming版 - 从12306来看,国内IT水平不高
你说的这些当机,都是应用升级的时候有bug造成的,难以避免。但跟12306高峰来一次
当一次是本质区别。

题。
L******f
发帖数: 5368
23
来自主题: Programming版 - 从12306来看,国内IT水平不高
股票交易,其实要简单得多。
每个股票维持两个queue。
bid queue/ask queue。
全世界有多少股票,就维持
多少queue。每个交易请求
进来,就在bid queue/ask
queue上减少一个bid/ask
tick,然后生成一个trade
tick。
这比12306要简单多了。
这个贴我回,骂街的贴我就不回了。
t********e
发帖数: 931
24
来自主题: Programming版 - 从12306来看,国内IT水平不高
用脚指头想一想就知道,12306复杂程度要比Obama Care高几个数量级
e****e
发帖数: 884
25
来自主题: Programming版 - 从12306来看,国内IT水平不高
不管IBM能不能做,把这种核心服务又交给美国公司,政治责任谁来承担?
中央已经对银行全用DB2和Oracle很头疼了。
感谢12306是自主研发,至少锻炼了队伍,13年底有篇技术文章去读读吧。
s*****e
发帖数: 16824
26
来自主题: Programming版 - 从12306来看,国内IT水平不高
现在就是这样啊,实名制,不能改,可以退有罚金。没用,黄牛乌泱乌泱的,直接用刷
票软件抢票,大大增加了12306的压力。黄牛买了票以后再跟买主联系,买主交钱了以
后黄牛退票再同时用买主的信息把票买回来,至于罚金,那全部都算到买主的票价里了。
x*****n
发帖数: 86
27
来自主题: Programming版 - 从12306来看,国内IT水平不高
黄牛是央企,怎么能搞沒了呢?

现在就是这样啊,实名制,不能改,可以退有罚金。没用,黄牛乌泱乌泱的,直接用刷
票软件抢票,大大增加了12306的压力。黄牛买了票以后再跟买主联系,买主交钱了以
后黄牛退票再同时用买........
e****M
发帖数: 280
28
来自主题: Programming版 - 从12306来看,国内IT水平不高
看淘宝就知道国内的IT水平还是可以的。
12306的问题跟技术水平无关。纯粹是官僚系统的问题。跟healthcare.gov的问题是一
样的。
s****y
发帖数: 38
29
来自主题: Programming版 - 从12306来看,国内IT水平不高
国内没有真正的招标之说,一切国有的网站都不可能做的好,经常连用也用不起来。相
比之下,12306做的已经很上乘了了。
l******l
发帖数: 2651
30
来自主题: Programming版 - 从12306来看,国内IT水平不高
你哪搞的狗屎小道消息?
信谣传谣,被转500次,要被喝茶的。
13年底,淘宝Stanford在搞了招聘会。
CTO王坚当众说了,当时12306是由IBM实现的方案。淘宝作维护。
另外,服务器是IBM的X-系列。
第一次的招标是清华同方作为项目执行方吃下。继承清华90年代把发射小卫星任务外包
到英国的传统,清华同方继续外包。碰巧砸了。
A*****i
发帖数: 3587
31
来自主题: Programming版 - 12306一个比较好的想法是
而且这种公开api的做法还是换汤不换药,最终后台还是要12306自己的服务器来出票
d******e
发帖数: 2265
32
来自主题: Programming版 - 12306一个比较好的想法是
again.12306是tps峰值时会当机。你需要找一个tps or request per second很大的例
子,而不是一个总吞吐量很大的例子。不幸的是,圣诞机票虽然恨难买,但是因为会涨
价所以不会有类似国内的情况出现。
w**z
发帖数: 8232
33
来自主题: Programming版 - 说说12306需要多少台机器
刚看完电影回来,周末还看你这样的帖子,太对不起自己了。 再说,对12306 审美疲
劳了。
z****g
发帖数: 75
34
来自主题: Programming版 - 说说12306需要多少台机器
做这个测试真是浪费钱
就是一个io bound的程序,磁片硬盘,scsi接口,也就是 ~100 IOPS, 测来测去,还
不就是这个数字
换成flash,快10x没问题
如果换OS IO软件,在好的flash disk上能提高100x
至于那个12306,唯一不能简单scale out的是出票,修改数据库。
看他们自己说的卖票峰值数据,也就是100/sec左右的出票速度。
transaction要做persistence,这个是瓶颈。它们换成flash disk,理论出票峰值能至
少快10x

app
L******f
发帖数: 5368
35
来自主题: Programming版 - 说说12306需要多少台机器
没错。哪个所谓的测试,才有
48, 96, 144 and 288 instances
跟小孩过家家似的。确实是浪费钱。
出票其实就是query。每个query时,
数据库必须锁定。query结束,数据库
必须同步更新。不可能scale out。
要应付12306的需求,现有市场上
的商业数据库都不行。
g*****g
发帖数: 34805
36
来自主题: Programming版 - 说说12306需要多少台机器
所有关于12306都说后台数据库不是问题,你纠结啥。前端订票的人多,后端票少。
往高里估,一个火车3000张票,一个车次20段,6万张,一天一千车次,6千万张。
还分时放票,算分10次发,每次就剩下6百万张,一个始发到终点的就能吃掉20张,平
均算一张票5站就好,总共就是120万个transaction. 稍微像样点的数据库服务器每秒
处理5000到1万个交易没问题,2-4分钟就解决了。但凡票卖完了,应用服务器就直接废
掉订单,或者让剩下的waiting list。无需再操作数据库。
我说了多少次,前端订单数量短时要高票数两到三个数量级,这才是问题。只要前后端
不耦合,后台批量读取,离线处理很容易。
L******f
发帖数: 5368
37
来自主题: Programming版 - 说说12306需要多少台机器
这几百个数据库需要同步实时更新吧?
每分钟更新一次,一定会有票卖重了。
因为系统看到的是一分钟前有票,
就卖了。结果发现一分钟内票已经卖
掉了。这在热门线路肯定会发生,
12306要被骂死了。
下单是为了买票吧?
买票就要数据库query吧?
query就需要锁定这几百数据库吧?
买完票后,这几百个数据库就要
实时更新吧?
几百万个这样的请求压上来,
基本上所有的商业数据库都要
崩溃。
g*****g
发帖数: 34805
38
来自主题: Programming版 - 说说12306需要多少台机器
Amazon早就有分段收费了。这个一年就40天春运,春运需要平时100倍机器,说云计算
不划算是不可能的。
自己盖数据中心把剩余计算力租出去,那是amazon, taobao, 12306显然不合适。
g*****g
发帖数: 34805
39
来自主题: Programming版 - 说说12306需要多少台机器
我当然买过,12306我都用过,还好买的票不热门。你说的蜂拥而上跟我说的矛盾是?
g*****g
发帖数: 34805
40
来自主题: Programming版 - 说说12306需要多少台机器
短信,email同时发。不放心还可以到12306刷你的订单状态。我那个网站是有响应的,
不像你的没有。银行设定转账干过吧?到时间帮你转,转了给你发邮件。你不放心移动
可以一直刷银行网站,刷到出来为止。

..
m**********j
发帖数: 8645
41
来自主题: Programming版 - 说说12306需要多少台机器
你这个连弱智科比都不如的怎么就还不明白,那么多人骂12306就是因为他们没买到他
们想要的票。
只要票不够,只要他们想早一点回家的那张车票他们买不到,他们就要骂。
他们就是要买到票,买到他们想要的特快票。
你这个弱智敢把你那句话贴在购票网站,就是个死。
b*******s
发帖数: 5216
42
来自主题: Programming版 - 在讨论12306前
再根据12306的表现猜猜他们自己的一些内部需求
1 防抢票软件
2 和窗口售票有某种分配方法
3 集中放票的模式
4 需要考虑临时增加车次,一般是成对增加
5 有站票出售
6 撑住短时间大量请求
7 待发现

下降
b*******s
发帖数: 5216
43
来自主题: Programming版 - 在讨论12306前
从那篇淘宝的参与12306的文章看,他们好像认为后端是主要问题,cpu不够强
比如我猜测cache更新,需要后端协同的,所以这部分如果用数据库,效率不会高
还真得用魏老师的内存数据结构这个办法,非常轻量
当然你们都坚持一个内存数据结构也是数据库,这个随便你们,不过我写c++代码
不会把数据结构用database这个关键字修饰 :)
l*****9
发帖数: 9501
44
来自主题: Programming版 - 在讨论12306前
这是政治问题,公安部不配合12306的话,估计部长要换人
l******l
发帖数: 2651
45
来自主题: Programming版 - 在讨论12306前
跟维稳比较起来,12306算啥?
z****g
发帖数: 75
46
来自主题: Programming版 - java 真不适合12306一类的网站
Java虽然有些问题,12306还是架构问题,语言没啥关系
用Java也许比用C++得多2~3倍的机子,但是不至于不能做

gc
m*m
发帖数: 47
47
来自主题: Programming版 - java 真不适合12306一类的网站
其实java gc的问题在于不确定性。你不可能知道它什么时候开始, 什么时候结束。不
确定性在设计大系统上是很忌讳的。
比方说, 有几百台机器同时运行java 程序( hadoop, cassandra, jetty, 等等),
存在一种可能就是这几百个jvm在某一时间同时进行gc. 当这种情况发生后, 会连带一
堆反应,进而导致服务中断。 如果这几百个机器是线下系统, 做batch 
processing, 那没人会留意这几秒或几十秒。但如果是线上系统, 那用户越多, 中
断越严重。
java系统对12306一类的网站来说,是先天不足的。
m*m
发帖数: 47
48
来自主题: Programming版 - java 真不适合12306一类的网站
嗯, 不过如果你仔细读了 CMS 和G1, 你会发现在这些GC都没说他们能够完全消除
pause time, 只是最大限度减少而已。
对于enterprise application 来说, 内存够大, 用户群够小, G1/CMS已经够好了,
用户们完全可能觉擦不到gc在运行。
但当面对12306的用户群时,巨大的访问量会给jvm带来很大的压力,我估计memory
fragmentation 会迫使jvm放弃G1/CMS, 转而运行STW GC来回收heap. 恶性循环就
此开始。
那些jvm运用(amazon, ebay, taobao)没有太多的背景信息,不好评价。 如果是线下程
序(batching processing, map reduce 等等), 那完全可能, 因为gc对他们的影响
很小, 没人会在意。
首页 上页 1 2 3 4 5 6 7 8 9 10 下页 末页 (共10页)