12306 妙杀 - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>JobHunting - 待字闺中

12306 妙杀

12306 妙杀# JobHunting - 待字闺中

s*x2015-12-02 08:12

1 楼

昨晚又想到一个trick, 直接秒杀这种high concurrency but tiny data set 系统。
就是合理的分流加aggregation.
分流可以按车次，前台 10000 web server, 后台 10000台server 自带任何一种数据库
就好了，一台server 负责几个车次。
Each web server aggregate all the requests to the same 车次 in one second,
后台能处理 10000 QPS 就行了。
貌似连多级cache，mem only db 之类的都是杀鸡用牛刀。
联票web server 并行锁票。
支付额外sever 异步处理。
Fault tolerance 多种方案。
Simple, easy and fast, 系统QPS 100m.
估计三个普通码工三个月轻松写完。

y*u2015-12-02 08:12

2 楼

进一步优化：针对火车票这种巨大需求，一个车次的所有区间票都是可以提前计划好或
是每隔一段时间重分配。也就是，一个车次包含各种区间票的商品，每个商品有库存数
。写数据时，不同的票之间就解耦了。
细思极恐～“魏老师的计数器的灵魂在飘荡....”

【在 s**x 的大作中提到】

: 昨晚又想到一个trick, 直接秒杀这种high concurrency but tiny data set 系统。
: 就是合理的分流加aggregation.
: 分流可以按车次，前台 10000 web server, 后台 10000台server 自带任何一种数据库
: 就好了，一台server 负责几个车次。
: Each web server aggregate all the requests to the same 车次 in one second,
: 后台能处理 10000 QPS 就行了。
: 貌似连多级cache，mem only db 之类的都是杀鸡用牛刀。
: 联票web server 并行锁票。
: 支付额外sever 异步处理。
: Fault tolerance 多种方案。

s*x2015-12-02 08:12

3 楼

那些都是细节，我发现因为可以aggregate 这个问题就变得非常简单了，魏老师的计数
器成了牛刀杀鸡了。
为什么aggregate? 因为数据量太小了，一个车次的车票，更新一个跟更新一万个一次
大部分时间都在disk io 上，没有区别。

【在 y******u 的大作中提到】

: 进一步优化：针对火车票这种巨大需求，一个车次的所有区间票都是可以提前计划好或
: 是每隔一段时间重分配。也就是，一个车次包含各种区间票的商品，每个商品有库存数
: 。写数据时，不同的票之间就解耦了。
: 细思极恐～“魏老师的计数器的灵魂在飘荡....”

y*u2015-12-02 08:12

4 楼

sharding规模以上公司都在做，不是黑科技

【在 s**x 的大作中提到】

:
: 那些都是细节，我发现因为可以aggregate 这个问题就变得非常简单了，魏老师的计数
: 器成了牛刀杀鸡了。
: 为什么aggregate? 因为数据量太小了，一个车次的车票，更新一个跟更新一万个一次
: 大部分时间都在disk io 上，没有区别。

m*s2015-12-02 08:12

5 楼

楼主不如建议每一天的每一个车次都有一个单独的有100台服务器的网站来处理。
就没事儿了。
比如北京至上海的G101在2016年1月17日的车票请去： http://G101-2016-01-17.com.cn购买。

s*x2015-12-02 08:12

6 楼

我靠，你不会认为Google.com facebook.com 就一台服务器吧？

【在 m********s 的大作中提到】

: 楼主不如建议每一天的每一个车次都有一个单独的有100台服务器的网站来处理。
: 就没事儿了。
: 比如北京至上海的G101在2016年1月17日的车票请去： http://G101-2016-01-17.com.cn购买。

s*x2015-12-02 08:12

7 楼

这个当然，我的建议里sharding 就是按车次。

【在 y******u 的大作中提到】

: sharding规模以上公司都在做，不是黑科技

m*s2015-12-02 08:12

8 楼

我就是顺着你的思路去说的。
每一个单独独立的网站只负责某一天的某个车次的订票、售票服务，就不容易被大流量
把全部车次都搞瘫痪了。
比如，你要订北京北去往八达岭的火车，这是趟无论什么时候都坐不满的车次。你却不
得不跟几千万订热门车次的旅客在同一个网站买票，很不科学。

【在 s**x 的大作中提到】

:
: 这个当然，我的建议里sharding 就是按车次。

g*g2015-12-02 08:12

9 楼

因为有联程票呗，没联程票是很简单。这种把需求阉割了意淫解决方案都是没有意义的
。

s*x2015-12-02 08:12

10 楼

也是一种方法，不过你这个需要二级分流。app 总是要先talk to tier 1 servers,
then talks to the servers you mentioned.

【在 m********s 的大作中提到】

: 我就是顺着你的思路去说的。
: 每一个单独独立的网站只负责某一天的某个车次的订票、售票服务，就不容易被大流量
: 把全部车次都搞瘫痪了。
: 比如，你要订北京北去往八达岭的火车，这是趟无论什么时候都坐不满的车次。你却不
: 得不跟几千万订热门车次的旅客在同一个网站买票，很不科学。

s*x2015-12-02 08:12

11 楼

一个人买n张联票，n个人买同样的n张票，there is no real difference.
The only difference is that you want the first case all or none.
No advantage for 联票，no disadvantage as well. 并行锁票就可以了。

【在 g*****g 的大作中提到】

: 因为有联程票呗，没联程票是很简单。这种把需求阉割了意淫解决方案都是没有意义的
: 。

t*n2015-12-02 08:12

12 楼

“并行锁票就可以了”？你还真是一点clue都没有啊！大学都没上过就能“解决”哥
德巴赫猜想的大概就张你这样吧？

【在 s**x 的大作中提到】

:
: 一个人买n张联票，n个人买同样的n张票，there is no real difference.
: The only difference is that you want the first case all or none.
: No advantage for 联票，no disadvantage as well. 并行锁票就可以了。

f*s2015-12-02 08:12

13 楼

这有一篇blog文章
http://www.habadog.com/2014/12/16/make-12306-better-again/

g*g2015-12-02 08:12

14 楼

I服了U，又一个连transaction的概念都没有就要做12306的。

【在 s**x 的大作中提到】

s*x2015-12-02 08:12

15 楼

看了五分钟，看到
”我并非信口开河，根据铁道部专家的说明：这几天，平均一天下单100万，所以，处
理1000万的用户需要十天。这个计算可能有点简单了，我只是想说，在这样低负载的系
统下用排队可能都不能解决业务问题）"
又看到，"40 台机器搞定”
我靠，这水平彻底跪了。

【在 f*******s 的大作中提到】

: 这有一篇blog文章
: http://www.habadog.com/2014/12/16/make-12306-better-again/

s*x2015-12-02 08:12

16 楼

Transaction 是什么东东? Say say 看。你定义的transaction 是必须全国人民大排
队？

【在 g*****g 的大作中提到】

: I服了U，又一个连transaction的概念都没有就要做12306的。

g*g2015-12-02 08:12

17 楼

我老不是来做TA的，对数据库基本概念都没有的我老不奉陪了。

【在 s**x 的大作中提到】

:
: Transaction 是什么东东? Say say 看。你定义的transaction 是必须全国人民大排
: 队？

s*x2015-12-02 08:12

18 楼

多谢！建议你还是先复习一下什么叫数据库吧，搞了一辈子数据库的人还真不一定给出
个正确的定义来。

【在 g*****g 的大作中提到】