s*****r 发帖数: 43070 | 1 俺觉得12306可以独立发展成铁路电商平台,为上市做准备 |
|
v****g 发帖数: 11080 | 2 抢票软件很牛逼,现在国内还有黄牛,帮你刷票,加200。12306的票一放出来,瞬间刷
空!
共匪的电子系统不是很牛吗?怎么还是无能为力?尼玛我认为其中有猫腻! |
|
|
发帖数: 1 | 4 12306难用shi,没听到国内吐槽的声音吗?
哈哈 |
|
发帖数: 1 | 5 如果阿里或者腾讯,任何一家公司做,都能超过现在的12306。
铁路当年找的码工真的是菜得很 |
|
p*****b 发帖数: 291 | 6 铁道部12306往上订票系统可以用境外信用卡吗?
可以用自己的境外信用卡为父母订票吗?
多谢 |
|
|
h*****6 发帖数: 866 | 8 人在美国,怎样能搞到有银联标志的网上支付卡?比如 在12306.cn 买火车票?
美国的信用卡,借记卡,是不是都不行啊? |
|
p*****y 发帖数: 529 | 9 12306要象你说的这么work,还没上线就得被人砸了。 你当是预订iPhone啊。
而且象你说这样还用人做么? 就一个网页填表单, 然后load balancer后面堆机器就
完了, 原来现在这么狂野的大数据就是这么玩的啊, 长见识。 |
|
m********s 发帖数: 55301 | 10 再举个例子,你在此站发帖子跟大家讨论如何改进12306。
你写好你的观点之后点击发送键,弹出的信息是:网站已确认,15分钟之后会通知您的
帖子是否已经贴出或者被取消,感谢合作。 |
|
|
|
y******u 发帖数: 804 | 13 用过12306,就会知道,票只显示特定班次的票数,出现conflicts出不了票的情况,只
会在最后一些票。
具体减库存是在进入付款时,还是付款后,是经典的tradeoff。讨论可参考《淘宝产品
十年》相关章节 |
|
g*****g 发帖数: 34805 | 14 Baba自己说了,光棍节能撑每秒12万的交易。你再想想春运能撑住吗。
12306现有的内存数据库,就是每秒10万级。一样网站没反应。 |
|
y******u 发帖数: 804 | 15 我没说baba能搞定12306,毕竟这个需求已是逼近物理和设计极限。现成解决方案肯定
没有,需要自己“创造条件”上!
我是说nexus那点小九九baba能躺着搞。 |
|
a********c 发帖数: 3657 | 16 3年前把12306做好确实牛x,现在国内随便个20人团队就搞定了,现在国内找工的说不会
秒杀的基本不可能吧。。。 |
|
|
|
b*******s 发帖数: 5216 | 19 100%不掉票绝对是吹毛求疵,卖一亿张票错个百把张不是什么大问题
他说的transaction其实也是思路局限在数据库技术上了。数据库的transcation也无非
是建立在数据结构上的一系列操作而已,如果数据库本身形成严重性能瓶颈还要死抱着
不放,这个是比较不合格的架构设计,不过考虑到国内做12306的人水平问题,尽量用
现成东西搭也算情有可原,只要不是为了面子主动引入低效因素就行 |
|
z****e 发帖数: 54598 | 20
txn肯定不在12306内部完成
肯定要发给银行
而且要经过公网
而且银行的接口协议是iso8583,不是丢一个json过去就可以了的
中间要经过gateway翻译,从发送req到最后接收到resp
最快最快2-3s内可以完成,这假设的是中间几乎没有任何的网络延迟
以及只经过一个gateway比如paypal
如果是多个gateway的话,会慢很多,比如apple pay发给paypal
再发给银行,然后银行处理后返回,这中间2-3s是最少的
慢的话,20m+都有,在这个数量级下,老魏那个计数器的多少ns是没有什么意义的
而且前面swjtuer也说了,这里必须同步,否则就是古德霸的做法
如果同步的话,你就要等txn返回,如果要等的话,一次交易周期至少是2-3s
崩了
老魏后来还上了什么udp,这都是胡闹,金钱交易是非常慎重的
基本上前台都是https少部分用tcp/tls,后台都是iso8583 |
|
g*****g 发帖数: 34805 | 21 很多人以为刷一次没有就是没票,用过12306吗?刷票没刷上意味着你的单子在到达数
据库之前丢了,或者数据库太忙,等待太久timeout了。这些才是大头,数据库处理了
没锁上票的是极小部分,这部分才是真没票的。一旦没票系统就不让你下单了,这部分
都是过渡的几秒钟。
这就是为什么刷一次没有,再刷一次可能有。看着还很多就是买不着,甚至不热门的车
次也躺枪。数据库处理不了这样的峰值,前面弄个queue缓冲异步处理,本来就是个常
见办法而已。一堆人脑子就是转不过来。 |
|
i****k 发帖数: 668 | 22 我反对这种说法。
对于计算机来说当然没有必要方法都是公平等价的,但是对人来说不一样。你玩命的刷
15分钟,刷到一张票,那种喜悦和15分钟后告诉你拿到票了是不可同日而语的,然后就
忘了去骂12306了。
你们学计算机的就是喜欢把人看成是没感情的计算机,图样图森破啊! |
|
g*****g 发帖数: 34805 | 23 世界上已知最快的系统只能每秒处理12万个交易,耦合度还比12306低。等硬件能比现
在快10倍,问题可以自动解决,但在此之前,没有任何同步系统能够不丢订单,这个很
难理解吗?我只不过给出一种异步的方案而已。 |
|
g*****g 发帖数: 34805 | 24 你才嘴硬。12306数据库能每秒处理10万单子,你每秒来20万,其中10万单子随机扔掉
,那不叫挤?这就是10万人挤进去了,另外十万被挤破脑袋,后面一秒20万又来了,这
十万连优先权都没有。
让你挤厕所你能确定15分钟后能挤进去?15分钟后你能确定啥时候能挤进去?你觉得我
的结果不好,你的结果更差。
如果所有的票排队要一个小时才能处理完,挤还是得至少一个小时。事实上因为反复刷
,外部负荷更大,内部job大量timeout。只会更慢。一个系统的处理速度是由瓶颈决定
的,不是由排不排队这样的非瓶颈部分决定的。我看你缺乏common sense。 |
|
s**x 发帖数: 7506 | 25
那只能说明12306现在的设计不行,不能证明你的想法不是狗屎。
实时是must to have, not even nice to have.
If you think you can not do it, just be quiet. |
|
g*****g 发帖数: 34805 | 26 别装了行不,baba自己说光棍节能处理12万/秒的交易量,世界上最大。12306内部人出
来说峰值订单超过每秒20万。
这东西说到底就是CAP theorem的限制,我设计不了永动机,也没有人可以。如何取舍
是一个架构设计的精髓所在,世界不是非黑既白。 |
|
g*****g 发帖数: 34805 | 27 12306出票不用写数据库?那个太监计数器你不是又要拿出来让大家嘲笑一次吧? |
|
g*****g 发帖数: 34805 | 28 支付才是瓶颈没错,但光数据库就撑不住这样的transaction,12306可是内存数据库都
上了。 |
|
|
g*****g 发帖数: 34805 | 30 别扯蛋了,12306允许你一个单子买多票,联程票。你买的也不是座位,而是日期车次
起始站,你想分割就分割?你从北京到广东某个小站,广州到小站的买到了,北京到广
州的没有,钱交了走不了。脑子一团浆糊还出来瞎指点。 |
|
s**x 发帖数: 7506 | 31
Lol 你能把个实时系统整成一两个小时,确实水平不一般。中国人民很庆幸12306 不是
由你设计的。 |
|
g*****g 发帖数: 34805 | 32 打这嘴炮没用,两趟车一旦耦合,基本所有车次都可以直接或者间接耦合。连这个都想
不到的不配跟我谈什么架构。
丢单的系统也不叫实时系统。实时系统意味着对所有订单可以响应,而且有票必须出。
现有的12306不是什么实时系统。
都不是实时系统,至少我的设计公平,不用刷网站。 |
|
g*****g 发帖数: 34805 | 33 12306之所以分时放票,就因为数据库处理不了这样的负荷。
让你等一小时再刷愿意,等一小时直接出排队结果就不行?都是一帮装逼的。 |
|
j******o 发帖数: 4219 | 34 在车票有限的情况下,再NB的硬件和马工也解决不了问题,总有人买不到票。12306就
算用天顶星技术,能够实现不丢票,即时完成交易,不出错,最后还是没什么卵用。这
个订票的事就跟马工没多大关系,是一个如何平民愤的问题。
现在基本能考虑的是:
1.如何减少黄牛票。
2.如何通知让定不上票的人更改路线,越快越好。
3.怎么安抚啥也没买到的人。 |
|
s*****r 发帖数: 43070 | 35 这是铁路的窗口售票系统,不是这里讨论的12306 |
|
z****e 发帖数: 54598 | 36
this is exactly what i said in previous post
i didnt say it is 12306
i was asking where the tickets come from? |
|
z****e 发帖数: 54598 | 37
12306当时问过ibm的意见,ibm给了一个报价,铁道部吓坏了
决定自己摸索,这个档次的项目,也就是ibm能做了
几个大型的项目基本上都是ibm在做
amadeus之类的,其实cloud用在这里不太合适
这种级别的项目,不用省硬件那点钱,国家有的是钱造数据中心
包括nosql什么其实也都不合适,容易出错
memorydb做点cache还勉强 |
|
g*****g 发帖数: 34805 | 38 别逗了,你口口声声帮太监做外围,不认可他的设计,做个蛋外围。没做过 高并发应
用要拿12306练手不是找丢人吗? |
|
t**r 发帖数: 3428 | 39 12306最基本的一个问题,用什么数据結構存票? |
|
z****e 发帖数: 54598 | 40
一个最基本的问题
对现有系统了解多少?
铁道部有自己的it系统,这个显然吧?不会有人认为现在铁道部还在用手工和纸张作业
吧?
其次政府部门,比如存身份证的,也有自己的一套系统
最后银行也有自己的一套系统,中国400多家银行
每一家都有自己的it系统,12306的流程基本上是横跨了这几个全国性的系统
这是非常麻烦的一件事,怎么总有人认为简单呢?
而且纷纷提出自己的方案,还是先把需求定了再说吧
现有数据如何拿到都是一个大问题
单机最搞笑,上来就是内存,怎么可能嘛
数据显然是存在db里面的,要先全部读入内存?
疯了差不多 |
|
L*****e 发帖数: 8347 | 41 也不是非要自己有机会去做的才能感兴趣一下啊。
12306春运是系统设计的一个极限挑战,既有高并发,又有限时响应,又有高耦合数据
,把这个案例的前前后后各方面弄清楚,明白各种trade off的利弊,足以秒杀99%的系
统设计面试题。。。 |
|
g*****g 发帖数: 34805 | 42 LOL, 联票是 12306现有的 feature,你丫说 nice to have, 老板同意了吗? |
|
y******u 发帖数: 804 | 43 i'm with sdlx on this.
不要忘了支付跟银行或支付宝打一个来回,也是秒级的。再高并发,你也得cope with
这个事实。各位,请去12306买一张票再喷吧 |
|
g*****g 发帖数: 34805 | 44 实时系统,请求必须处理。每秒进来20万请求,数据库只能处理10万,另外10万扔掉,
不叫实时系统。12306现在就是这么做的。
都没响应还要死撑叫实时。 |
|
g*****g 发帖数: 34805 | 45 俩菜鸟还死撑。我说得一个小时就是个上限,撑死这么久票也卖光了。12306为啥要分
时抢票呀,不就是为了把票数下一个数量级。本来最多一个小时处理完,立马变成5分
钟,再弄个高大上的内存数据库,你要的实时出来了。
我老人家不喜欢这个设计。早上起来下个单子,出门的时候就知道买没买着多省事。你
还让我跟钟摆似的每个小时去刷一次。但内部异步队列,前后分离还是一样的,这些都
看不出来也别出来丢人现眼了。 |
|
s**x 发帖数: 7506 | 46 一个车次,从北京到上海,有一万个座位,全北京两千万人同时订票到上海,怎么设计?
主要问题:几台机器?数据存哪?
这个题解决了,12306 的基本架构就有了。 |
|
|
g*****g 发帖数: 34805 | 48 I服了U,又一个连transaction的概念都没有就要做12306的。 |
|
|
M*******g 发帖数: 224 | 50 父母12月27号飞回北京, 然后准备坐动车回山东. 想在网上把火车票给他们买了. 有没
有在www.12306.cn买过车票的朋友? 这个网站可靠吗? 不知道我们这边的信用卡他们收
不收? 这个网站也没有联系电话可以打. 多谢了. |
|