由买买提看人间百态

topics

全部话题 - 话题: 12306
首页 上页 1 2 3 4 5 6 7 8 9 10 下页 末页 (共10页)
s*****r
发帖数: 43070
1
俺觉得12306可以独立发展成铁路电商平台,为上市做准备
v****g
发帖数: 11080
2
抢票软件很牛逼,现在国内还有黄牛,帮你刷票,加200。12306的票一放出来,瞬间刷
空!
共匪的电子系统不是很牛吗?怎么还是无能为力?尼玛我认为其中有猫腻!
s***c
发帖数: 1926
3
一个手机app也敢自称12306

发帖数: 1
4
12306难用shi,没听到国内吐槽的声音吗?
哈哈

发帖数: 1
5
如果阿里或者腾讯,任何一家公司做,都能超过现在的12306。
铁路当年找的码工真的是菜得很
p*****b
发帖数: 291
6
铁道部12306往上订票系统可以用境外信用卡吗?
可以用自己的境外信用卡为父母订票吗?
多谢
p*****b
发帖数: 291
7
是指境外卡不能用在12306上?
h*****6
发帖数: 866
8
人在美国,怎样能搞到有银联标志的网上支付卡?比如 在12306.cn 买火车票?
美国的信用卡,借记卡,是不是都不行啊?
p*****y
发帖数: 529
9
来自主题: JobHunting版 - 讨论一下12306的架构?
12306要象你说的这么work,还没上线就得被人砸了。 你当是预订iPhone啊。
而且象你说这样还用人做么? 就一个网页填表单, 然后load balancer后面堆机器就
完了, 原来现在这么狂野的大数据就是这么玩的啊, 长见识。
m********s
发帖数: 55301
10
来自主题: JobHunting版 - 讨论一下12306的架构?
再举个例子,你在此站发帖子跟大家讨论如何改进12306。
你写好你的观点之后点击发送键,弹出的信息是:网站已确认,15分钟之后会通知您的
帖子是否已经贴出或者被取消,感谢合作。
y******u
发帖数: 804
11
来自主题: JobHunting版 - 讨论一下12306的架构?
查询和存数据肯定是分开的。
现实中也是分开的,查询占90%业务,需要准静态数据,大致都是用的阿里云服务
http://companies.caixin.com/2015-01-20/100776355.html
数据层是用的GemFire分布式内存数据库
http://www.csdn.net/article/2013-12-30/2817959-look-at-12306
y******u
发帖数: 804
12
来自主题: JobHunting版 - 讨论一下12306的架构?
查询和存数据肯定是分开的。
现实中也是分开的,查询占90%业务,需要准静态数据,需要不停的push,大部分用的
阿里云服务
http://companies.caixin.com/2015-01-20/100776355.html
数据层是用的GemFire分布式内存数据库
http://www.csdn.net/article/2013-12-30/2817959-look-at-12306

吗?
y******u
发帖数: 804
13
来自主题: JobHunting版 - 讨论一下12306的架构?
用过12306,就会知道,票只显示特定班次的票数,出现conflicts出不了票的情况,只
会在最后一些票。
具体减库存是在进入付款时,还是付款后,是经典的tradeoff。讨论可参考《淘宝产品
十年》相关章节
g*****g
发帖数: 34805
14
来自主题: JobHunting版 - 讨论一下12306的架构?
Baba自己说了,光棍节能撑每秒12万的交易。你再想想春运能撑住吗。
12306现有的内存数据库,就是每秒10万级。一样网站没反应。
y******u
发帖数: 804
15
来自主题: JobHunting版 - 讨论一下12306的架构?
我没说baba能搞定12306,毕竟这个需求已是逼近物理和设计极限。现成解决方案肯定
没有,需要自己“创造条件”上!
我是说nexus那点小九九baba能躺着搞。
a********c
发帖数: 3657
16
来自主题: JobHunting版 - 讨论一下12306的架构?
3年前把12306做好确实牛x,现在国内随便个20人团队就搞定了,现在国内找工的说不会
秒杀的基本不可能吧。。。
a********c
发帖数: 3657
17
来自主题: JobHunting版 - 讨论一下12306的架构?
btw 12306的头在知乎详细说过构架
a********c
发帖数: 3657
18
来自主题: JobHunting版 - 讨论一下12306的架构?

狗 秒杀+12306+构架
b*******s
发帖数: 5216
19
来自主题: JobHunting版 - 讨论一下12306的架构?
100%不掉票绝对是吹毛求疵,卖一亿张票错个百把张不是什么大问题
他说的transaction其实也是思路局限在数据库技术上了。数据库的transcation也无非
是建立在数据结构上的一系列操作而已,如果数据库本身形成严重性能瓶颈还要死抱着
不放,这个是比较不合格的架构设计,不过考虑到国内做12306的人水平问题,尽量用
现成东西搭也算情有可原,只要不是为了面子主动引入低效因素就行
z****e
发帖数: 54598
20
来自主题: JobHunting版 - 讨论一下12306的架构?

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
来自主题: JobHunting版 - 讨论一下12306的架构?
很多人以为刷一次没有就是没票,用过12306吗?刷票没刷上意味着你的单子在到达数
据库之前丢了,或者数据库太忙,等待太久timeout了。这些才是大头,数据库处理了
没锁上票的是极小部分,这部分才是真没票的。一旦没票系统就不让你下单了,这部分
都是过渡的几秒钟。
这就是为什么刷一次没有,再刷一次可能有。看着还很多就是买不着,甚至不热门的车
次也躺枪。数据库处理不了这样的峰值,前面弄个queue缓冲异步处理,本来就是个常
见办法而已。一堆人脑子就是转不过来。
i****k
发帖数: 668
22
来自主题: JobHunting版 - 讨论一下12306的架构?
我反对这种说法。
对于计算机来说当然没有必要方法都是公平等价的,但是对人来说不一样。你玩命的刷
15分钟,刷到一张票,那种喜悦和15分钟后告诉你拿到票了是不可同日而语的,然后就
忘了去骂12306了。
你们学计算机的就是喜欢把人看成是没感情的计算机,图样图森破啊!
g*****g
发帖数: 34805
23
来自主题: JobHunting版 - 讨论一下12306的架构?
世界上已知最快的系统只能每秒处理12万个交易,耦合度还比12306低。等硬件能比现
在快10倍,问题可以自动解决,但在此之前,没有任何同步系统能够不丢订单,这个很
难理解吗?我只不过给出一种异步的方案而已。
g*****g
发帖数: 34805
24
来自主题: JobHunting版 - 讨论一下12306的架构?
你才嘴硬。12306数据库能每秒处理10万单子,你每秒来20万,其中10万单子随机扔掉
,那不叫挤?这就是10万人挤进去了,另外十万被挤破脑袋,后面一秒20万又来了,这
十万连优先权都没有。
让你挤厕所你能确定15分钟后能挤进去?15分钟后你能确定啥时候能挤进去?你觉得我
的结果不好,你的结果更差。
如果所有的票排队要一个小时才能处理完,挤还是得至少一个小时。事实上因为反复刷
,外部负荷更大,内部job大量timeout。只会更慢。一个系统的处理速度是由瓶颈决定
的,不是由排不排队这样的非瓶颈部分决定的。我看你缺乏common sense。
s**x
发帖数: 7506
25
来自主题: JobHunting版 - 讨论一下12306的架构?

那只能说明12306现在的设计不行,不能证明你的想法不是狗屎。
实时是must to have, not even nice to have.
If you think you can not do it, just be quiet.
g*****g
发帖数: 34805
26
来自主题: JobHunting版 - 讨论一下12306的架构?
别装了行不,baba自己说光棍节能处理12万/秒的交易量,世界上最大。12306内部人出
来说峰值订单超过每秒20万。
这东西说到底就是CAP theorem的限制,我设计不了永动机,也没有人可以。如何取舍
是一个架构设计的精髓所在,世界不是非黑既白。
g*****g
发帖数: 34805
27
来自主题: JobHunting版 - 讨论一下12306的架构?
12306出票不用写数据库?那个太监计数器你不是又要拿出来让大家嘲笑一次吧?
g*****g
发帖数: 34805
28
来自主题: JobHunting版 - 讨论一下12306的架构?
支付才是瓶颈没错,但光数据库就撑不住这样的transaction,12306可是内存数据库都
上了。
y******u
发帖数: 804
29
来自主题: JobHunting版 - 讨论一下12306的架构?
前文再发
提醒:要战胜铁道研究院信息技术中心,至少要先了解一下同行是怎么做的吧。
查询和存数据肯定是分开的。
现实中也是分开的,查询占90%业务,需要准静态数据,需要定时push,2015年后大部
分用的阿里云服务
查询的缓存也简单,就是出发站+到达站+日期为key 查询结果为value 的key-value对
http://companies.caixin.com/2015-01-20/100776355.html
数据层是用的GemFire分布式内存数据库
http://www.csdn.net/article/2013-12-30/2817959-look-at-12306
g*****g
发帖数: 34805
30
来自主题: JobHunting版 - 讨论一下12306的架构?
别扯蛋了,12306允许你一个单子买多票,联程票。你买的也不是座位,而是日期车次
起始站,你想分割就分割?你从北京到广东某个小站,广州到小站的买到了,北京到广
州的没有,钱交了走不了。脑子一团浆糊还出来瞎指点。
s**x
发帖数: 7506
31
来自主题: JobHunting版 - 讨论一下12306的架构?

Lol 你能把个实时系统整成一两个小时,确实水平不一般。中国人民很庆幸12306 不是
由你设计的。
g*****g
发帖数: 34805
32
来自主题: JobHunting版 - 讨论一下12306的架构?
打这嘴炮没用,两趟车一旦耦合,基本所有车次都可以直接或者间接耦合。连这个都想
不到的不配跟我谈什么架构。
丢单的系统也不叫实时系统。实时系统意味着对所有订单可以响应,而且有票必须出。
现有的12306不是什么实时系统。
都不是实时系统,至少我的设计公平,不用刷网站。
g*****g
发帖数: 34805
33
来自主题: JobHunting版 - 讨论一下12306的架构?
12306之所以分时放票,就因为数据库处理不了这样的负荷。
让你等一小时再刷愿意,等一小时直接出排队结果就不行?都是一帮装逼的。
j******o
发帖数: 4219
34
来自主题: JobHunting版 - 讨论一下12306的架构?
在车票有限的情况下,再NB的硬件和马工也解决不了问题,总有人买不到票。12306就
算用天顶星技术,能够实现不丢票,即时完成交易,不出错,最后还是没什么卵用。这
个订票的事就跟马工没多大关系,是一个如何平民愤的问题。
现在基本能考虑的是:
1.如何减少黄牛票。
2.如何通知让定不上票的人更改路线,越快越好。
3.怎么安抚啥也没买到的人。
s*****r
发帖数: 43070
35
来自主题: JobHunting版 - 讨论一下12306的架构?
这是铁路的窗口售票系统,不是这里讨论的12306
z****e
发帖数: 54598
36
来自主题: JobHunting版 - 讨论一下12306的架构?

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
来自主题: JobHunting版 - 讨论一下12306的架构?

12306当时问过ibm的意见,ibm给了一个报价,铁道部吓坏了
决定自己摸索,这个档次的项目,也就是ibm能做了
几个大型的项目基本上都是ibm在做
amadeus之类的,其实cloud用在这里不太合适
这种级别的项目,不用省硬件那点钱,国家有的是钱造数据中心
包括nosql什么其实也都不合适,容易出错
memorydb做点cache还勉强
g*****g
发帖数: 34805
38
来自主题: JobHunting版 - 讨论一下12306的架构?
别逗了,你口口声声帮太监做外围,不认可他的设计,做个蛋外围。没做过 高并发应
用要拿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
来自主题: JobHunting版 - 锁票是12306 的重要组成部分
LOL, 联票是 12306现有的 feature,你丫说 nice to have, 老板同意了吗?
y******u
发帖数: 804
43
来自主题: JobHunting版 - 锁票是12306 的重要组成部分
i'm with sdlx on this.
不要忘了支付跟银行或支付宝打一个来回,也是秒级的。再高并发,你也得cope with
这个事实。各位,请去12306买一张票再喷吧
g*****g
发帖数: 34805
44
来自主题: JobHunting版 - 锁票是12306 的重要组成部分
实时系统,请求必须处理。每秒进来20万请求,数据库只能处理10万,另外10万扔掉,
不叫实时系统。12306现在就是这么做的。
都没响应还要死撑叫实时。
g*****g
发帖数: 34805
45
来自主题: JobHunting版 - 锁票是12306 的重要组成部分
俩菜鸟还死撑。我说得一个小时就是个上限,撑死这么久票也卖光了。12306为啥要分
时抢票呀,不就是为了把票数下一个数量级。本来最多一个小时处理完,立马变成5分
钟,再弄个高大上的内存数据库,你要的实时出来了。
我老人家不喜欢这个设计。早上起来下个单子,出门的时候就知道买没买着多省事。你
还让我跟钟摆似的每个小时去刷一次。但内部异步队列,前后分离还是一样的,这些都
看不出来也别出来丢人现眼了。
s**x
发帖数: 7506
46
来自主题: JobHunting版 - 12306 的简化版
一个车次,从北京到上海,有一万个座位,全北京两千万人同时订票到上海,怎么设计?
主要问题:几台机器?数据存哪?
这个题解决了,12306 的基本架构就有了。
f*******s
发帖数: 182
47
来自主题: JobHunting版 - 12306 妙杀
这有一篇blog文章
http://www.habadog.com/2014/12/16/make-12306-better-again/
g*****g
发帖数: 34805
48
来自主题: JobHunting版 - 12306 妙杀
I服了U,又一个连transaction的概念都没有就要做12306的。
t****t
发帖数: 2269
49
在12306 app里直接买,最后选微信支付
M*******g
发帖数: 224
50
父母12月27号飞回北京, 然后准备坐动车回山东. 想在网上把火车票给他们买了. 有没
有在www.12306.cn买过车票的朋友? 这个网站可靠吗? 不知道我们这边的信用卡他们收
不收? 这个网站也没有联系电话可以打. 多谢了.
首页 上页 1 2 3 4 5 6 7 8 9 10 下页 末页 (共10页)