12306毫无疑问是人类历史上最牛鼻的电商网站 zz

梦宫有香 发表于 2013-1-25 06:29

2011年美国疯抢touchpad，我也参和了一下

有个找deal 的论坛叫slickdeal，上面有人实时发帖告诉大家哪里还有货

问题是，这个帖子发出来以后两分钟内，该目标网站一定瘫痪。一时间slickdeal变成了大规模ddos的指挥中心，打哪指哪，横扫了一大批在线零售站点

第一个倒掉的是hp自己的hp store

然后bestbuy

然后newegg

接下来连ebay也down掉十几分钟

等他们恢复访问，那一定是已经OOS了

唯一一个在有货时一直可以访问的是amazon。当然amazon有自己的云服务，对爆发式的访问没有那么不堪一击。但是事后大家发现，amazon超售了好几倍的量。显然他家的这次交易是不加锁，没有一致性检查的

最后，这个横扫整个IT界的touchpad，总出货量多少呢？100万出头而已，其中还只有一半是在线出售的。

给大家一个参考

保安发表于 2013-1-25 06:36

别的不说，UI实在土得掉渣

lollxxox 发表于 2013-1-25 06:39

我在想为什么12306不做成一个可以较容易扩展的服务器，平时淡季的时候用自己的机群啊网络啊，长假的时候和各种云签个协议租用一个月几天啥的来快速扩容，我觉得这免费广告sina啊阿里啊各种云不会不给铁老大点面子吧，顺便做压测了。

不是搞IT的，但是这么做技术上应该没有问题吧......

Gato_shin 发表于 2013-1-25 06:53

某次安全論壇上，數字表示他們有中國最好的分佈式DDoS對抗集群

給大家一個參考

tumuyan 发表于 2013-1-25 08:10

玻色子 发表于 2013-1-25 08:48

thq 发表于 2013-1-25 09:35

一致性检查导致这个玩意不好扩展吧……尤其对火车票这种一件商品可以拆成几件卖，还要求必须不能超售的商品而言，一致性检查的复杂度和重要性就更高了。

螺纹发表于 2013-1-25 09:43

要求给更多API的接口问题，估计光是流程就要好几个月，各种吃饭请客各种审批
反正和国企或部门打交道，形式上的程序走过场把事情效率变低下了

秀光发表于 2013-1-25 09:43

不能超售这一点决定了再怎么扩展，数据库的压力都非常大……所以单纯跟电商对比毫无意义吧，难道买火车票可以先下单，过半小时再告诉你对不起，票已经没了？

何边杨 发表于 2013-1-25 09:51

回 8楼(秀光) 的帖子

去年还真是这样的啊
今年倒是有改善了

258921 发表于 2013-1-25 12:18

引用第8楼秀光于2013-01-25 09:43发表的:
不能超售这一点决定了再怎么扩展，数据库的压力都非常大……所以单纯跟电商对比毫无意义吧，难道买火车票可以先下单，过半小时再告诉你对不起，票已经没了？ images/back.gif

12306曾经还真的就这么干过啊，要买票是吧，统统显示有票，你买就告诉你排队30分钟之后告诉你买没买到。
当时恶心死了……

lollxxox 发表于 2013-1-25 14:18

2047 发表于 2013-1-25 14:21

我能先问一下LS的职业是什么吗？

一般市民 发表于 2013-1-25 14:35

界面一股上世纪90年代风就不说了这安全证书不可信是咋回事？

lollxxox 发表于 2013-1-25 14:52

回 12楼(2047) 的帖子

咦？职业很关键嘛，我只是在一家咨询公司做一些风控和相应的数据分析的工作而已......对象是工程公司和跨国事业吧，目前

ov_efly 发表于 2013-1-25 14:55

刷票不停地刷
你分3个云都难看
何况国内的云还在起步阶段
和亚马逊比嫩着呢

thq 发表于 2013-1-25 15:05

引用第11楼lollxxox于2013-01-25 14:18发表的:

安全方面完全不懂，不过再怎样也肯定不是明文吧，是这个意思吗？

如果把一个服务器扩展到其他云很难的话，那就划分区域好了！平时12306一个服务器带所有的负荷，到了节假日让sinaapp挂东三省发车的，让百度云挂珠三角发车的，让阿里挂长三角发车的。这种分类可以以始发站啊所属铁路局啊，城市abcde的顺序啊来排列都可以啊，这样不就是把压力分摊了吗？因为是各卖各的也不会出现超卖现象。实现的方法我觉得先进点的话可以统一前段然后后台接入各自的服务器，也可以根据IP预分配用户到各自始发站服务器，当然可以让人选择换服务器来给其他人买票啦！最笨的方法还有做一个landing page，自己选始发站，然后接入相应服务器和数据库。也许我科幻小说看多了吧....但是我觉得这应该不难实现的。
....... images/back.gif

举个简单的例子，京广线，从北京到广州方向，有多少个车站？跨越多少个省？这些车站能组合出多少种火车票组合？比如一张从北京到广州的车票被售出以后，减少的不仅仅是北京到广州一张票，而是从北京到广州上方向所有车站的票。
所以火车票的一致性校验比一般的商品要复杂多了。

tf小红帽 发表于 2013-1-25 15:16

引用第11楼lollxxox于2013-01-25 14:18发表的:

安全方面完全不懂，不过再怎样也肯定不是明文吧，是这个意思吗？

如果把一个服务器扩展到其他云很难的话，那就划分区域好了！平时12306一个服务器带所有的负荷，到了节假日让sinaapp挂东三省发车的，让百度云挂珠三角发车的，让阿里挂长三角发车的。这种分类可以以始发站啊所属铁路局啊，城市abcde的顺序啊来排列都可以啊，这样不就是把压力分摊了吗？因为是各卖各的也不会出现超卖现象。实现的方法我觉得先进点的话可以统一前段然后后台接入各自的服务器，也可以根据IP预分配用户到各自始发站服务器，当然可以让人选择换服务器来给其他人买票啦！最笨的方法还有做一个landing page，自己选始发站，然后接入相应服务器和数据库。也许我科幻小说看多了吧....但是我觉得这应该不难实现的。
....... images/back.gif

按出发点分无意义，最后都要汇总到核心服务器生成车票

yuxiao 发表于 2013-1-25 15:26

回 2楼(lollxxox) 的帖子

数据库数据一致性问题，如何把数据快速扩散到新租用的存储设备内的问题，个人信息安全性问题，软件使用许可问题，以及其它非技术问题

kawa11 发表于 2013-1-25 15:41

笨，一开始就做的最好或是做的很好，以后怎么要预算提高

hplovecraft 发表于 2013-1-25 17:11

就没人喷铁道部不允许其他第三方电商代购火车票么……要是允许的话服务器压力根本不会那么大

bubuyu 发表于 2013-1-25 17:23

我觉得12306需要的是一个强大的公关公司而不是更多的服务器

董卓发表于 2013-1-25 17:24

代购...那就得不单单是跨集群的一致性了
还得跨平台啊

秀光发表于 2013-1-25 17:33

代购，是预先分配一部分车票，还是一个数据库多个接口？前者不过是多几个被挤垮的地方和更多的骂声——绝大部分人肯定同时刷几个网站——后者的话，只会比现在压力更大。

heliosu 发表于 2013-1-25 17:43

引用第2楼lollxxox于2013-01-25 06:39发表的:
我在想为什么12306不做成一个可以较容易扩展的服务器，平时淡季的时候用自己的机群啊网络啊，长假的时候和各种云签个协议租用一个月几天啥的来快速扩容，我觉得这免费广告sina啊阿里啊各种云不会不给铁老大点面子吧，顺便做压测了。

不是搞IT的，但是这么做技术上应该没有问题吧...... images/back.gif

锁……

heliosu 发表于 2013-1-25 17:45

引用第20楼hplovecraft于2013-01-25 17:11发表的:
就没人喷铁道部不允许其他第三方电商代购火车票么……要是允许的话服务器压力根本不会那么大 images/back.gif

没用最终决定性能的是铁道部的数据库
自行百度读者写者问题

Realplayer 发表于 2013-1-25 17:46

接続の安全性を確認できません

无动于衷 发表于 2013-1-25 17:59

我就想知道铁路网上售票要是外包给淘宝会是个什么结果

heliosu 发表于 2013-1-25 18:01

引用第27楼无动于衷于2013-01-25 17:59发表的:
我就想知道铁路网上售票要是外包给淘宝会是个什么结果 images/back.gif

出了问题铁道部和淘宝互相踢球
淘宝预先截留一部分车票暗中出售

白左发表于 2013-1-25 18:09

未定名 发表于 2013-1-25 18:25

引用第27楼无动于衷于2013-01-25 17:59发表的:
我就想知道铁路网上售票要是外包给淘宝会是个什么结果

如果淘宝敢承诺1111这样的情况绝对不超卖的话。火车票超卖是必然被骂死的。

----发送自 STAGE1 App for Android.

yuxiao 发表于 2013-1-25 18:55

再补充一点，云环境不适合在线交易系统，不可控因素太多了

2047 发表于 2013-1-25 19:03

引用第14楼lollxxox于2013-01-25 14:52发表的
咦？职业很关键嘛，我只是在一家咨询公司做一些风控和相应的数据分析的工作而已......对象是工程公司和跨国事业吧，目前 images/back.gif

没搞过分布式的半吊子码农简单说一下，说错请轻拍

一般来说以现在的服务器硬件性能，只要不是代码写得太烂，多数企业级web应用的性能瓶颈主要在两块地方 1、网络带宽 2、数据库读写

因为离家近的原因，我从来没上12306买票也不知道他们是怎么处理的，虽然也听说过12306爆出过一些很低级的漏洞，不过这里不谈这个

你想的都是分担服务器压力的方法，前面也有人指出问题来了。这样做业务上到底能不能实现，12306服务器处理能力能不能抗住也先不用去管它，你只要知道春运买票这种高并发量+业务复杂需要反复读写数据库的情况下，最容易拖慢速度的九成九是数据库这一块

更麻烦的是高并发量下如何保证数据一致性，比如怎么保证一张票不能卖给两个人等等问题是很要人命的，相比之下淘宝上的秒杀处理起来就简单太多了

非洗地，太极开发地好不好我不知道也不关心，我只是想说春运买票这种情况想完美解决太难了

Netheril 发表于 2013-1-25 19:37

引用第32楼2047于2013-01-25 19:03发表的:

没搞过分布式的半吊子码农简单说一下，说错请轻拍

一般来说以现在的服务器硬件性能，只要不是代码写得太烂，多数企业级web应用的性能瓶颈主要在两块地方 1、网络带宽 2、数据库读写

....... images/back.gif

访问量在 12306 这个级别的在线交易系统做起来的确有难度，不过也没有真的难到上天入地。拍一个亿给淘宝，拉出精干队伍来做，妥妥地轻松搞定。就算是我这样的废柴，真要带一票人搭一个能扛住这个级别流量的后台数据库系统，自忖呲牙咧嘴也能对付下来。毕竟春运高峰也就是一天售票 100 万张的样子，折算过来 tps 都不见得过 50 啊 —— 当然了，据说 12306 渣到余票查询都去压数据库，这个真心是没药救的。

秀光发表于 2013-1-25 19:51

不到50是直接把每天总量平均的么……照这样做出的系统在出票那几分钟必爆无疑……另外余票查询不访问数据库的话，如何让用户实时确认有没有票？难道也是半小时刷新一次……

Netheril 发表于 2013-1-25 21:05

引用第34楼秀光于2013-01-25 19:51发表的:
不到50是直接把每天总量平均的么……照这样做出的系统在出票那几分钟必爆无疑……另外余票查询不访问数据库的话，如何让用户实时确认有没有票？难道也是半小时刷新一次…… images/back.gif

直接总量平均的话，一天 86400 秒平摊下来不到 12 呢，50 是习惯性乘以 4 的结果。余票查询显然不能直接压数据库啊，建一个旁路的索引，每个交易提交数据库事务的时候并行地更新一下索引，然后以一定的时间间隔从数据库分段重建以消除可能存在的偏差。

iray 发表于 2013-1-25 21:41

我这个外行想到一个办法，不知道可不可不行

既然即时购票访问量太大，那么改成非即时呢
每天白天用户提交订单，夜间关闭提交，统一处理订单，车票在所有提交的订单内抽签分配，第二天公布。
这样的话，至少服务器是没有压力了吧，问题是抽签的方案又会引来争议吧。

明日の香 发表于 2013-1-25 23:28

引用第36楼iray于2013-01-25 21:41发表的:
我这个外行想到一个办法，不知道可不可不行

既然即时购票访问量太大，那么改成非即时呢
每天白天用户提交订单，夜间关闭提交，统一处理订单，车票在所有提交的订单内抽签分配，第二天公布。
这样的话，至少服务器是没有压力了吧，问题是抽签的方案又会引来争议吧。 images/back.gif

你这个比排队三十分钟还可悲

thq 发表于 2013-1-26 10:33

引用第35楼Netheril于2013-01-25 21:05发表的:

直接总量平均的话，一天 86400 秒平摊下来不到 12 呢，50 是习惯性乘以 4 的结果。余票查询显然不能直接压数据库啊，建一个旁路的索引，每个交易提交数据库事务的时候并行地更新一下索引，然后以一定的时间间隔从数据库分段重建以消除可能存在的偏差。
....... images/back.gif

这样下单不就可能出现超售了么？

梦宫有香 发表于 2013-1-26 10:45

页: [1] 2

Stage1st's Archiver