讨论一下12306的架构？ - 未名空间MITBBS历史存档

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

Redian新闻

>未名空间

>JobHunting - 待字闺中

讨论一下12306的架构？

讨论一下12306的架构？# JobHunting - 待字闺中

m*02015-11-29 08:11

1 楼

假设面试时系统设计问这个题，这个买票网站面临如下问题，请问如何解决改进？
1. 每趟列车有N个车站，一张车票可以从任意站到任意站，并且有m种座位（硬座、软
座、卧铺、站票。。。）。数据结构如何设计？
2. 查询是否有余票是最频繁的操作。peak时每分钟有上亿次查询。问如何设计系统以
满足这种请求量？
3. 如果需要设置cache，怎么设置比较合理？
抛砖引玉，就当是面试系统设计题吧。。

m*s2015-11-29 08:11

2 楼

2还要加上，一旦某票被查询完成并且有票，就要锁票并且所有与此票经停站有关联的
各票信息都要被更新。
另外，peak时，不是每分钟，是每5秒就会有上亿次的查询。

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

: 假设面试时系统设计问这个题，这个买票网站面临如下问题，请问如何解决改进？
: 1. 每趟列车有N个车站，一张车票可以从任意站到任意站，并且有m种座位（硬座、软
: 座、卧铺、站票。。。）。数据结构如何设计？
: 2. 查询是否有余票是最频繁的操作。peak时每分钟有上亿次查询。问如何设计系统以
: 满足这种请求量？
: 3. 如果需要设置cache，怎么设置比较合理？
: 抛砖引玉，就当是面试系统设计题吧。。

s*r2015-11-29 08:11

3 楼

这个订票系统比哪个订旅馆的二逼牛X太多

h*d2015-11-29 08:11

4 楼

上亿次查询每分钟，相当于150万次QPS。充分静态化应该不难。读取操作可以对数据库
定期扫描，比如没0.2s扫描一次，更新缓存，这点延迟应该无所谓，但大大降低对数据
库的压力（0.2s相当于5QPS对全数据库扫描）。缓存服务器单机应该能搞定上万次请求
，100多台服务器就够了。
买票的时候，写请求可以设置rate limit，用一个环形数组。多数请求直接返回票卖光
，可以扛住很压力，每个后台服务器放进200-300请求做数据库更改。

L*e2015-11-29 08:11

5 楼

这个问题当年在葵花版好虫和魏老师大战了三个月，还有数十站队帮战的网友，有些讨
论还是有些许闪光点的，你去搜搜吧。。。

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

p*y2015-11-29 08:11

6 楼

这个是150万transaction per sec吧。

【在 h********d 的大作中提到】

: 上亿次查询每分钟，相当于150万次QPS。充分静态化应该不难。读取操作可以对数据库
: 定期扫描，比如没0.2s扫描一次，更新缓存，这点延迟应该无所谓，但大大降低对数据
: 库的压力（0.2s相当于5QPS对全数据库扫描）。缓存服务器单机应该能搞定上万次请求
: ，100多台服务器就够了。
: 买票的时候，写请求可以设置rate limit，用一个环形数组。多数请求直接返回票卖光
: ，可以扛住很压力，每个后台服务器放进200-300请求做数据库更改。

g*g2015-11-29 08:11

7 楼

rate limit服务器能撑住但不公平。最简单的就是订单写入Kafka立刻返回，另一边
RDBMS慢慢出票就行了。但凡异步出票所有问题迎刃而解。

【在 h********d 的大作中提到】

l*22015-11-29 08:11

8 楼

最后一边做出来了一个不支持transaction的计数器？

【在 L*****e 的大作中提到】

: 这个问题当年在葵花版好虫和魏老师大战了三个月，还有数十站队帮战的网友，有些讨
: 论还是有些许闪光点的，你去搜搜吧。。。

h*d2015-11-29 08:11

9 楼

不会的，这个应该只是读，你想挣个春运就10亿人次？
好几天时间，一天8万秒，除下来写得压力没那么大。
150万，可以10分钟买掉所有票了。
另外查询时候，页面上然button每次点灰一下，反向代理限制ip的rate，都可以进一步
减轻后面的压力

h*d2015-11-29 08:11

10 楼

有道理，多谢好虫指导

j*r2015-11-29 08:11

11 楼

写了半天说验证码过期，没有保存，再写一遍，哭
整体非常复杂，这里只设计指定车站之间余票和购买问题
假设列车车站数为n, 票种类(软／硬卧，软／硬座，站等)，求第x到y站之间的硬座票
数。
分析：因为某种座位在全程的总票数都固定，所以问题可以转化为求x到y站之间对应票
类最大的售出张数，可以只用最大型线段树模型(max segment tree).
设计: 对每趟车的每种座位生成一个单独的线段树，每个站生成一个叶子节点，记录本
站这种座位已出售票数。内部节点记录子树里面最大的座位售出数。
查询：查询x到y站之间最大售出票数，被总票数减，得到x,y之间票数余额。同时x,y之
间所有max值＋1. 查询复杂度O(lgn+k)
购买：只需处理收款和出票，无需操作线段树和对应数据库
回滚：如果购买失败／超时，回滚x,y之间的max值，复杂度同查询O(lgn+k)
除了单次查询速度有所提升，这样做可以减少锁的数量，传统查询O(n)而且需要锁n条
数据库记录，此设计只需要锁k条记录，在大量查询时可以显著提高并发性能。

j*r2015-11-29 08:11

12 楼

我补充一下，异步处理能很好解决并发问题，但是问题是，你定了票之后不知道是否能
定的上，特别是有很多线路可以选择的情况下，如果不小心选择了紧俏的线路，等异步
处理结果出来再去定差一点的线路结果也没票了，这样也不太合理。
如果界面能设计成一个多选一的订单倒是可以接受
比如有多个选择线路，购票人选择几路，按最希望订到的顺序加入订单，最后选择总订
票数，作为一个订单提交给系统，然后系统根据优先顺序提供总订票数。
这里剩下一个问题就是如果订两张票，本来想一起走，结果分成了两趟走，或者一张订
到一张没订到，不能和女盆友一起走估计很郁闷，还需要增加几个选择all or none，
必须同车次等等。

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

: rate limit服务器能撑住但不公平。最简单的就是订单写入Kafka立刻返回，另一边
: RDBMS慢慢出票就行了。但凡异步出票所有问题迎刃而解。

y*u2015-11-29 08:11

13 楼

现在的配置是GemFire分布式集群内存数据做永久化，阿里的oceanbase做缓存

L*e2015-11-29 08:11

14 楼

最后啥结果不清楚，实在是跟不动了，一边说对方的方案不支持transaction，另一边
指责对方的方案做不到同步出票，再后来一边说对方是太监，另一边说对方是牛二，完
全口水战了。。。

【在 l**********2 的大作中提到】

: 最后一边做出来了一个不支持transaction的计数器？

g*g2015-11-29 08:11

15 楼

备选，联票，这些都可以做。反正瓶颈在后台的RDBMS上，异步了无非是出票再慢一些
而已。一天的票再怎么慢一个小时也处理完了。

【在 j********r 的大作中提到】

: 我补充一下，异步处理能很好解决并发问题，但是问题是，你定了票之后不知道是否能
: 定的上，特别是有很多线路可以选择的情况下，如果不小心选择了紧俏的线路，等异步
: 处理结果出来再去定差一点的线路结果也没票了，这样也不太合理。
: 如果界面能设计成一个多选一的订单倒是可以接受
: 比如有多个选择线路，购票人选择几路，按最希望订到的顺序加入订单，最后选择总订
: 票数，作为一个订单提交给系统，然后系统根据优先顺序提供总订票数。
: 这里剩下一个问题就是如果订两张票，本来想一起走，结果分成了两趟走，或者一张订
: 到一张没订到，不能和女盆友一起走估计很郁闷，还需要增加几个选择all or none，
: 必须同车次等等。

a*s2015-11-29 08:11

16 楼

求链接

【在 L*****e 的大作中提到】

: 这个问题当年在葵花版好虫和魏老师大战了三个月，还有数十站队帮战的网友，有些讨
: 论还是有些许闪光点的，你去搜搜吧。。。

L*e2015-11-29 08:11

17 楼

历时数月的大战，开帖无数，至今余波未了，实在是没有一个统一的链接。。。

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

: 求链接

g*g2015-11-29 08:11

18 楼

这种一边倒的论战，实在没啥意思。就是一堆EE出身，没做过server端应用的人在死撑
，非要单机撑下12306。内行一看就知道不可能。
又要同步又要顶峰不丢单是不可能的。12306现有的方案还是丢单的。哪怕它的关系数
据库比我需要的快10倍。在平民级硬件上用开源框架堆出可伸缩的方案才是我做架构的
初衷。我提到的用云计算来避免不必要的硬件成本，12306去年就开始做了。
由于丢单，在12306上刷一整天，很可能还是下不了单。按我的方案无非是开卖的时候
尽快下一个单子，最后成不成就是一个先来后到的事情。该干嘛干嘛，过一个小时短信
，邮件，push notif通知结果。

【在 L*****e 的大作中提到】

: 最后啥结果不清楚，实在是跟不动了，一边说对方的方案不支持transaction，另一边
: 指责对方的方案做不到同步出票，再后来一边说对方是太监，另一边说对方是牛二，完
: 全口水战了。。。

x*r2015-11-29 08:11

19 楼

恩

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

: 这种一边倒的论战，实在没啥意思。就是一堆EE出身，没做过server端应用的人在死撑
: ，非要单机撑下12306。内行一看就知道不可能。
: 又要同步又要顶峰不丢单是不可能的。12306现有的方案还是丢单的。哪怕它的关系数
: 据库比我需要的快10倍。在平民级硬件上用开源框架堆出可伸缩的方案才是我做架构的
: 初衷。我提到的用云计算来避免不必要的硬件成本，12306去年就开始做了。
: 由于丢单，在12306上刷一整天，很可能还是下不了单。按我的方案无非是开卖的时候
: 尽快下一个单子，最后成不成就是一个先来后到的事情。该干嘛干嘛，过一个小时短信
: ，邮件，push notif通知结果。

h*e2015-11-29 08:11

20 楼

我擦还有人想单机版这也是跪了这种问题不值得跟上一代的人争论吧

m*s2015-11-29 08:11

21 楼

大陆同胞们对于自己订完票后需要"过一个小时短信，邮件，push notif通知结果"这个
处理是最不能忍的。比他们买不到票还要恨。

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

b*52015-11-29 08:11

22 楼

我对这个手机push notification觉得很讨厌。。。什么都要手机上给个密码，然后
要输手机上的密码，烦都烦死了

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

: 大陆同胞们对于自己订完票后需要"过一个小时短信，邮件，push notif通知结果"这个
: 处理是最不能忍的。比他们买不到票还要恨。

p*y2015-11-29 08:11

23 楼

这个过一个小时还不一定能定上，因为“定票”的时候是不锁票的。估计连刷几天能
定上？

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

: 大陆同胞们对于自己订完票后需要"过一个小时短信，邮件，push notif通知结果"这个
: 处理是最不能忍的。比他们买不到票还要恨。

j*r2015-11-29 08:11

24 楼

也是可以解决的，就像你在窗口订票，轮到你，你把你可能需要的车次都问一遍，如果
有就订上，没有的话你也没办法，只能等下一次放票活着别人退票了。
－－－－－－－－－－－－－－－－－－－－－－－－－－
我补充一下，异步处理能很好解决并发问题，但是问题是，你定了票之后不知道是否能
定的上，特别是有很多线路可以选择的情况下，如果不小心选择了紧俏的线路，等异步
处理结果出来再去定差一点的线路结果也没票了，这样也不太合理。
如果界面能设计成一个多选一的订单倒是可以接受
比如有多个选择线路，购票人选择几路，按最希望订到的顺序加入订单，最后选择总订
票数，作为一个订单提交给系统，然后系统根据优先顺序提供总订票数。
这里剩下一个问题就是如果订两张票，本来想一起走，结果分成了两趟走，或者一张订
到一张没订到，不能和女盆友一起走估计很郁闷，还需要增加几个选择all or none，
必须同车次等等。

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

: 这个过一个小时还不一定能定上，因为“定票”的时候是不锁票的。估计连刷几天能
: 定上？

g*g2015-11-29 08:11

25 楼

这有什么不能忍的，刷票刷一整天没刷到的比比皆是。让你五分钟订票，一小时出结果
怎么不行？

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

: 大陆同胞们对于自己订完票后需要"过一个小时短信，邮件，push notif通知结果"这个
: 处理是最不能忍的。比他们买不到票还要恨。

g*g2015-11-29 08:11

26 楼

你把所有备选的车次都放进一个单子里。一次拿不到只能等退票了，不用天天刷。有退
票也可以挨个短信通知，先来先得。

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

: 这个过一个小时还不一定能定上，因为“定票”的时候是不锁票的。估计连刷几天能
: 定上？

c*n2015-11-29 08:11

27 楼

数据结构简单啊
一个座x一个区间（链接的两个站）就是一个 entity.
开车找路的算法就是一截一截的路

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

y*u2015-11-29 08:11

28 楼

再简洁一点
一个座x［各剩余区间（存成bitmap）］
并发：先对inventory做sharding，比如按车厢，在各shards上操作。

【在 c******n 的大作中提到】

: 数据结构简单啊
: 一个座x一个区间（链接的两个站）就是一个 entity.
: 开车找路的算法就是一截一截的路

s*x2015-11-29 08:11

29 楼

Good bug 同志显然不知道什么是real time system.
Your idea might work, apparently real time works better.

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

: 这有什么不能忍的，刷票刷一整天没刷到的比比皆是。让你五分钟订票，一小时出结果
: 怎么不行？

p*y2015-11-29 08:11

30 楼

12306要象你说的这么work，还没上线就得被人砸了。你当是预订iPhone啊。
而且象你说这样还用人做么？就一个网页填表单，然后load balancer后面堆机器就
完了，原来现在这么狂野的大数据就是这么玩的啊，长见识。

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

: 你把所有备选的车次都放进一个单子里。一次拿不到只能等退票了，不用天天刷。有退
: 票也可以挨个短信通知，先来先得。

t*r2015-11-29 08:11

31 楼

终于有人说sharding了

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

: 再简洁一点
: 一个座x［各剩余区间（存成bitmap）］
: 并发：先对inventory做sharding，比如按车厢，在各shards上操作。

s*x2015-11-29 08:11

32 楼

Goodbug 思维还在石器时代。

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

: 12306要象你说的这么work，还没上线就得被人砸了。你当是预订iPhone啊。
: 而且象你说这样还用人做么？就一个网页填表单，然后load balancer后面堆机器就
: 完了，原来现在这么狂野的大数据就是这么玩的啊，长见识。

t*r2015-11-29 08:11

33 楼

股的霸会说你是单机版/单片机／嵌入式。：D

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

:
: Goodbug 思维还在石器时代。

z*32015-11-29 08:11

34 楼

这种问题不值得跟上一代的人争论

【在 t**r 的大作中提到】

: 股的霸会说你是单机版/单片机／嵌入式。：D

L*e2015-11-29 08:11

35 楼

闻到当年葵花版大战的味道了，各位请继续。。。

s*x2015-11-29 08:11

36 楼

Shading or partitioning is the fundamental for distributed systems.
找到一个可行的 partition 方案是关键。车次，日期，加车厢就差不多。i I doubt
you need go to seat level.

【在 t*********r 的大作中提到】

: 终于有人说sharding了

s*x2015-11-29 08:11

37 楼

没说excel 模式？

【在 t**r 的大作中提到】

: 股的霸会说你是单机版/单片机／嵌入式。：D

t*r2015-11-29 08:11

38 楼

一起围观撕逼大战

【在 L*****e 的大作中提到】

: 闻到当年葵花版大战的味道了，各位请继续。。。

p*y2015-11-29 08:11

39 楼

同搬小板凳

【在 t*********r 的大作中提到】

: 一起围观撕逼大战

m*s2015-11-29 08:11

40 楼

注意区别：
A，你刷票刷一整天没刷到。
B，你订票订完之后一小时才告诉你一小时前动作的结果。
想想你现在已经尿憋裤子了正着急上厕所，赶到一个公厕门口，然后公厕门卫告诉你已
经确认给你排上队了，15分钟后再通知你这个公厕是不是有位子让你可以拉屎撒尿。

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

: 这有什么不能忍的，刷票刷一整天没刷到的比比皆是。让你五分钟订票，一小时出结果
: 怎么不行？

m*s2015-11-29 08:11

41 楼

再举个例子，你在此站发帖子跟大家讨论如何改进12306。
你写好你的观点之后点击发送键，弹出的信息是：网站已确认，15分钟之后会通知您的
帖子是否已经贴出或者被取消，感谢合作。

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

: 这有什么不能忍的，刷票刷一整天没刷到的比比皆是。让你五分钟订票，一小时出结果
: 怎么不行？

s*r2015-11-29 08:11

42 楼

涉及到支付的系统，都是无法异步的。
支付系统的失败率非常高，异步无法让让用户及时知道支付失败，用户不能及时知道订
单失效会导致用户体验差
网上购物时，都是立刻通知订单有没有完成，其实背后就是支付先成功，紧接着是订单
完成，这两个步骤是一个transaction。支付完成，order的status就是payment
complete，否则就是payment fail。只有完成支付的订单才会被继续处理，这以后的步
骤就是异步了，用户不需要实时通知

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

: rate limit服务器能撑住但不公平。最简单的就是订单写入Kafka立刻返回，另一边
: RDBMS慢慢出票就行了。但凡异步出票所有问题迎刃而解。

z*32015-11-29 08:11

43 楼

no
涉及到支付的系统，都是异步的
The entire process from authorization to settlement to funding typically
takes 3 days.
https://en.wikipedia.org/wiki/Payment_gateway

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

: 涉及到支付的系统，都是无法异步的。
: 支付系统的失败率非常高，异步无法让让用户及时知道支付失败，用户不能及时知道订
: 单失效会导致用户体验差
: 网上购物时，都是立刻通知订单有没有完成，其实背后就是支付先成功，紧接着是订单
: 完成，这两个步骤是一个transaction。支付完成，order的status就是payment
: complete，否则就是payment fail。只有完成支付的订单才会被继续处理，这以后的步
: 骤就是异步了，用户不需要实时通知

s*r2015-11-29 08:11

44 楼

因为国内的线上支付系统基本没有fraud protection的能力，所以只能用这种简单粗暴
但很有效的办法，虽然用户体验差，但这个对于不够矫情的国人，没啥大不了的

【在 b**********5 的大作中提到】

: 我对这个手机push notification觉得很讨厌。。。什么都要手机上给个密码，然后
: 要输手机上的密码，烦都烦死了

s*r2015-11-29 08:11

45 楼

capture之前都是同步的，settlement是客户银行和商户银行之间的事情，已经不要求
客户的行为

【在 z*******3 的大作中提到】

:
: no
: 涉及到支付的系统，都是异步的
: The entire process from authorization to settlement to funding typically
: takes 3 days.
: https://en.wikipedia.org/wiki/Payment_gateway

z*32015-11-29 08:11

46 楼

correct
& i think we should stop here

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

: capture之前都是同步的，settlement是客户银行和商户银行之间的事情，已经不要求
: 客户的行为

s*r2015-11-29 08:11

47 楼

数据库瓶颈可以通过sharding来解决，每个订票者的transaction去lock不同的row，减
少之间的conflict和roll back。大多数订票的只会买一两张车票，sharding可以细化
到很小的层次

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

: 备选，联票，这些都可以做。反正瓶颈在后台的RDBMS上，异步了无非是出票再慢一些
: 而已。一天的票再怎么慢一个小时也处理完了。

L*e2015-11-29 08:11

48 楼

sharing解决不了联票的问题，古德坝要求100%不能丢票掉票，只要出现transaction
conflict 或 rollback就不满足他说的要求了。。。

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

: 数据库瓶颈可以通过sharding来解决，每个订票者的transaction去lock不同的row，减
: 少之间的conflict和roll back。大多数订票的只会买一两张车票，sharding可以细化
: 到很小的层次

j*r2015-11-29 08:11

49 楼

sharding其实是显著降低性能的，每个query里面都要根据shard key来查询，否则就是
灾难。

【在 t*********r 的大作中提到】

: 终于有人说sharding了

y*u2015-11-29 08:11

50 楼

中文确实是模糊的语言，这句话居然看不出因果关系。

【在 j********r 的大作中提到】

: sharding其实是显著降低性能的，每个query里面都要根据shard key来查询，否则就是
: 灾难。

j*r2015-11-29 08:11

51 楼

车次开头肯定不行的，那所有查询必须都包含车次。很多人都是查日期和起始站的

doubt

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

:
: 没说excel 模式？

j*r2015-11-29 08:11

52 楼

比如你用车次做shard key, 那查询日期的时候就是全数据库多机查找，不就是灾难吗？

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

: 中文确实是模糊的语言，这句话居然看不出因果关系。

b*52015-11-29 08:11

53 楼

http://coolshell.cn/articles/6470.html

y*u2015-11-29 08:11

54 楼

查询和存数据肯定是分开的。
现实中也是分开的，查询占90%业务，需要准静态数据，大致都是用的阿里云服务
http://companies.caixin.com/2015-01-20/100776355.html
数据层是用的GemFire分布式内存数据库
http://www.csdn.net/article/2013-12-30/2817959-look-at-12306

【在 j********r 的大作中提到】

: 车次开头肯定不行的，那所有查询必须都包含车次。很多人都是查日期和起始站的
:
: doubt

y*u2015-11-29 08:11

55 楼

查询和存数据肯定是分开的。
现实中也是分开的，查询占90%业务，需要准静态数据，需要不停的push，大部分用的
阿里云服务
http://companies.caixin.com/2015-01-20/100776355.html
数据层是用的GemFire分布式内存数据库
http://www.csdn.net/article/2013-12-30/2817959-look-at-12306

吗？

【在 j********r 的大作中提到】

: 比如你用车次做shard key, 那查询日期的时候就是全数据库多机查找，不就是灾难吗？

j*r2015-11-29 08:11

56 楼

读写分离的问题是不consistent, 修改之后，你取到的不是最新数据，这样做
transaction隐患是很多的

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

: 查询和存数据肯定是分开的。
: 现实中也是分开的，查询占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*u2015-11-29 08:11

57 楼

提醒：要战胜铁道研究院信息技术中心，至少要先了解一下同行是怎么做的吧。

y*u2015-11-29 08:11

58 楼

用过12306，就会知道，票只显示特定班次的票数，出现conflicts出不了票的情况，只
会在最后一些票。
具体减库存是在进入付款时，还是付款后，是经典的tradeoff。讨论可参考《淘宝产品
十年》相关章节

【在 j********r 的大作中提到】

: 读写分离的问题是不consistent, 修改之后，你取到的不是最新数据，这样做
: transaction隐患是很多的

L*e2015-11-29 08:11

59 楼

当初讨论这个问题是有个春运前提的，你这个conflict出不了票的情况就会天天发生，
每次车都发生。火车票和淘宝上卖的货还是有区别的，不说时效和限定数，就一个联票
问题就是淘宝卖货所不具有的，你总不是在一家店买只铅笔，然后在另一家店买个橡皮
擦，如果橡皮擦没有了，那么铅笔你也不要了。。。

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

: 用过12306，就会知道，票只显示特定班次的票数，出现conflicts出不了票的情况，只
: 会在最后一些票。
: 具体减库存是在进入付款时，还是付款后，是经典的tradeoff。讨论可参考《淘宝产品
: 十年》相关章节

y*u2015-11-29 08:11

60 楼

上面已说过
数据entry是：
一个座x［各剩余区间（存成bitmap）］
不能简单地存成一个班次的座位数
（暂时）减库存可发生在支付的后面环节，比如redirect去“支付宝”或网银支付

【在 L*****e 的大作中提到】

: 当初讨论这个问题是有个春运前提的，你这个conflict出不了票的情况就会天天发生，
: 每次车都发生。火车票和淘宝上卖的货还是有区别的，不说时效和限定数，就一个联票
: 问题就是淘宝卖货所不具有的，你总不是在一家店买只铅笔，然后在另一家店买个橡皮
: 擦，如果橡皮擦没有了，那么铅笔你也不要了。。。

g*g2015-11-29 08:11

61 楼

别逗了，你狗就是这么运作的。我老曾经去抢 Nexus, 你狗流量太大，直接说回头发邮
件通知抢到没。怎么都比宕机好。

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

g*g2015-11-29 08:11

62 楼

如果我一年只用发一个或几个帖子我不介意。

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

: 再举个例子，你在此站发帖子跟大家讨论如何改进12306。
: 你写好你的观点之后点击发送键，弹出的信息是：网站已确认，15分钟之后会通知您的
: 帖子是否已经贴出或者被取消，感谢合作。

L*e2015-11-29 08:11

63 楼

这个都讨论过的，当初提出bitmap来标注一个座位在某站是否卖出还是我第一个提出来
的，然后有同学还给出了座位优化的算法，还讨论过买起始站票的和买区间票的优先权
问题等等等等。但是一切的一切，你要么不能实时，要么
lock transaction就一定有conflict会发生，再加上联票转车的连锁反应，conflict发
生的机会就大大增加。。。

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

: 上面已说过
: 数据entry是：
: 一个座x［各剩余区间（存成bitmap）］
: 不能简单地存成一个班次的座位数
: （暂时）减库存可发生在支付的后面环节，比如redirect去“支付宝”或网银支付

g*g2015-11-29 08:11

64 楼

不说反正人比票多，再说支付验证是可以抢票之前就注册用户测试的。

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

y*u2015-11-29 08:11

65 楼

狗不是做电商的，交给baba躺着就搞定了

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

: 别逗了，你狗就是这么运作的。我老曾经去抢 Nexus, 你狗流量太大，直接说回头发邮
: 件通知抢到没。怎么都比宕机好。

g*g2015-11-29 08:11

66 楼

Baba自己说了，光棍节能撑每秒12万的交易。你再想想春运能撑住吗。
12306现有的内存数据库，就是每秒10万级。一样网站没反应。

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

: 狗不是做电商的，交给baba躺着就搞定了

g*g2015-11-29 08:11

67 楼

现有的硬件没有一个数据库能撑住这个流量，period.

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

:
: 没说excel 模式？

y*u2015-11-29 08:11

68 楼

我没说baba能搞定12306，毕竟这个需求已是逼近物理和设计极限。现成解决方案肯定
没有，需要自己“创造条件”上！
我是说nexus那点小九九baba能躺着搞。

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

: Baba自己说了，光棍节能撑每秒12万的交易。你再想想春运能撑住吗。
: 12306现有的内存数据库，就是每秒10万级。一样网站没反应。

g*g2015-11-29 08:11

69 楼

没有完美的方法，只能做取舍。我提出的只不过是一种公平，成本低，可靠性高的方案
而已。都不需要高大上的内存数据库，MySQL足以。

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

: 我没说baba能搞定12306，毕竟这个需求已是逼近物理和设计极限。现成解决方案肯定
: 没有，需要自己“创造条件”上！
: 我是说nexus那点小九九baba能躺着搞。

L*e2015-11-29 08:11

70 楼

淘宝店家之间不具备列车车次之间的关联性，淘宝店家数量也远远多于铁道部车次的数
量，所以同样的throughput 造成的conflicts要小得多。天朝大部分人口春运期间指望
车票回家，对时效的要求也不是淘宝淘货所具备的，除非淘宝全部是卖避孕套的还限量
供应，不马上买到会出人命。。。

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

: Baba自己说了，光棍节能撑每秒12万的交易。你再想想春运能撑住吗。
: 12306现有的内存数据库，就是每秒10万级。一样网站没反应。

g*g2015-11-29 08:11

71 楼

刷一条网站打都打不开叫时效，异步等一小时不叫时效？网站第一要务是available,
没有这个屁都没有。

【在 L*****e 的大作中提到】

: 淘宝店家之间不具备列车车次之间的关联性，淘宝店家数量也远远多于铁道部车次的数
: 量，所以同样的throughput 造成的conflicts要小得多。天朝大部分人口春运期间指望
: 车票回家，对时效的要求也不是淘宝淘货所具备的，除非淘宝全部是卖避孕套的还限量
: 供应，不马上买到会出人命。。。

j*r2015-11-29 08:11

72 楼

其实你这个方案就很好，稍微改进一下，平均5分钟出票是完全可能的。
但是政府做，不出问题哪来投资啊？越做的烂越有钱。
美国的健保系统也是一回事。

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

: 没有完美的方法，只能做取舍。我提出的只不过是一种公平，成本低，可靠性高的方案
: 而已。都不需要高大上的内存数据库，MySQL足以。

y*u2015-11-29 08:11

73 楼

知乎上已经有很多改变服务流程的方案，其中一个比较有意思，就是大幅提前预定时间。
比如可以提前一年预订，因为人们可以定下行程的时间在一年的周期里肯定是不同的，
可以大大降低瞬时流量，而是分布到一整年里面。

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

: 没有完美的方法，只能做取舍。我提出的只不过是一种公平，成本低，可靠性高的方案
: 而已。都不需要高大上的内存数据库，MySQL足以。

L*e2015-11-29 08:11

74 楼

所以说讨论前大家先把需求分析统一了，否则你的一个小时出票方案就会被人反驳要耽
误他做决定是不是订其它车次。你说把所有车次请求一起排序提交，他会说会耽误他决
定是否订长途汽车票或者飞机票。然后他说他的方案会有万分之一的丢票可能，然后你
说这违反了公平正义性绝不能容忍，然后就开始鸡同鸭讲，各说个话。。。

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

: 刷一条网站打都打不开叫时效，异步等一小时不叫时效？网站第一要务是available,
: 没有这个屁都没有。

y*u2015-11-29 08:11

75 楼

请教一下你的conflict何时怎么发生？是指丢票吗？

【在 L*****e 的大作中提到】

: 这个都讨论过的，当初提出bitmap来标注一个座位在某站是否卖出还是我第一个提出来
: 的，然后有同学还给出了座位优化的算法，还讨论过买起始站票的和买区间票的优先权
: 问题等等等等。但是一切的一切，你要么不能实时，要么
: lock transaction就一定有conflict会发生，再加上联票转车的连锁反应，conflict发
: 生的机会就大大增加。。。

g*g2015-11-29 08:11

76 楼

怎么都比大量丢单公平。你刷网站刷一天，就能买着飞机票了？

【在 L*****e 的大作中提到】

: 所以说讨论前大家先把需求分析统一了，否则你的一个小时出票方案就会被人反驳要耽
: 误他做决定是不是订其它车次。你说把所有车次请求一起排序提交，他会说会耽误他决
: 定是否订长途汽车票或者飞机票。然后他说他的方案会有万分之一的丢票可能，然后你
: 说这违反了公平正义性绝不能容忍，然后就开始鸡同鸭讲，各说个话。。。
:
:

g*g2015-11-29 08:11

77 楼

不丢单也就没人去刷网站，这本身就减少了10倍以上的流量。另外加一点简单的 IP
throttling. 票贩子就会被淹没在人民群众的汪洋大海里。

L*e2015-11-29 08:11

78 楼

如果客户甲需要订A次车然后转B次车，A次车还剩一张票，被锁住。这个时候客户乙需
要定A次车转C次车，结果显示A次车没票。
结果甲客户的B次车没票了，所以他A次车的票rollback，但这张票乙用户拿不到了，被
后面的丙用户拿到了。这就是丢票。
如果你不锁住A次车票，交易没有完全完成你不更新这个座位的状态，那么乙用户和甲
用户就出现conflict。。。
如果甲客户交易没完成你让所有需要订A次车的客户等待，那么无法应付大并发量。。。

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

: 请教一下你的conflict何时怎么发生？是指丢票吗？

y*u2015-11-29 08:11

79 楼

那就锁啊，乙先拿不到，丙后拿到，对于数亿用户来说，这点不一致性有什么问题吗？
何时减库存本来就是各有利弊（《淘宝产品十年》相关章节有讨论），而且这只会发生
在最后一些票。

【在 L*****e 的大作中提到】

: 如果客户甲需要订A次车然后转B次车，A次车还剩一张票，被锁住。这个时候客户乙需
: 要定A次车转C次车，结果显示A次车没票。
: 结果甲客户的B次车没票了，所以他A次车的票rollback，但这张票乙用户拿不到了，被
: 后面的丙用户拿到了。这就是丢票。
: 如果你不锁住A次车票，交易没有完全完成你不更新这个座位的状态，那么乙用户和甲
: 用户就出现conflict。。。
: 如果甲客户交易没完成你让所有需要订A次车的客户等待，那么无法应付大并发量。。。

m*s2015-11-29 08:11

80 楼

你春运不在乎买不买火车票的话，确实不介意。

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

: 如果我一年只用发一个或几个帖子我不介意。

L*e2015-11-29 08:11

81 楼

所以这就是需求分歧啊，你觉得丢单牺牲个别人的利益对于几亿人来说不算什么，有人
认为哪怕几亿人都多等点时间，但是程序公平。。。
这讨论下去就要扯出著名的道德悖论问题了，比如说杀一个无辜人，可以救一万个人的
命，该不该杀他？

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

:
: 那就锁啊，乙先拿不到，丙后拿到，对于数亿用户来说，这点不一致性有什么问题吗？
: 何时减库存本来就是各有利弊（《淘宝产品十年》相关章节有讨论），而且这只会发生
: 在最后一些票。

g*g2015-11-29 08:11

82 楼

事实上是票贩子拿走了很多票。我给的方案，票贩子拿不了多少。
至于买不买得着，人多票少，问题解决不了。我只能保证先来后到。

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

: 你春运不在乎买不买火车票的话，确实不介意。

y*u2015-11-29 08:11

83 楼

每人都有“失而复得”的可能，就是公平啊，这跟有人退票产生新票也一个意思吧。

【在 L*****e 的大作中提到】

: 所以这就是需求分歧啊，你觉得丢单牺牲个别人的利益对于几亿人来说不算什么，有人
: 认为哪怕几亿人都多等点时间，但是程序公平。。。
: 这讨论下去就要扯出著名的道德悖论问题了，比如说杀一个无辜人，可以救一万个人的
: 命，该不该杀他？

a*c2015-11-29 08:11

84 楼

3年前把12306做好确实牛x，现在国内随便个20人团队就搞定了，现在国内找工的说不会
秒杀的基本不可能吧。。。

a*c2015-11-29 08:11

85 楼

btw 12306的头在知乎详细说过构架

m*s2015-11-29 08:11

86 楼

票贩子是另一个大话题，快快的说一句，15亿同胞就是票贩子的土壤。
对15亿同胞来说，他们不能认可的先来后到，就不算是先来后到。
你想想我之前说的你着急上厕所的例子。你可以接受你看到厕所目前拥挤你进不去、你
可以接受你看到厕所门外不让你现在进去，但你不能接受厕所门外通知你15分钟之后再
告诉你能进不能进。

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

: 事实上是票贩子拿走了很多票。我给的方案，票贩子拿不了多少。
: 至于买不买得着，人多票少，问题解决不了。我只能保证先来后到。

y*u2015-11-29 08:11

87 楼

有链接吗？谢谢

【在 a********c 的大作中提到】

: btw 12306的头在知乎详细说过构架

a*c2015-11-29 08:11

88 楼

狗秒杀+12306+构架

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

: 有链接吗？谢谢

g*g2015-11-29 08:11

89 楼

那么多人都要上厕所，你敢说排队不合理吗？莫非你没见过排队上厕所？你这个纯粹扯
蛋。

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

: 票贩子是另一个大话题，快快的说一句，15亿同胞就是票贩子的土壤。
: 对15亿同胞来说，他们不能认可的先来后到，就不算是先来后到。
: 你想想我之前说的你着急上厕所的例子。你可以接受你看到厕所目前拥挤你进不去、你
: 可以接受你看到厕所门外不让你现在进去，但你不能接受厕所门外通知你15分钟之后再
: 告诉你能进不能进。

x*k2015-11-29 08:11

90 楼

这种货物必定售完的就该跟h1b一样抽签预售。指定时间内预付款锁定一个抽签名额,大
家都别刷网站。不满意也没办法运力有限跟it系统无关。

a*c2015-11-29 08:11

91 楼

世面上的秒杀基本都是rate limit在做，只是limit的方式不一样而已，说简单了就是
不同的方法怎样保证1秒放几个人，fifo才是不公平的。。。

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

: rate limit服务器能撑住但不公平。最简单的就是订单写入Kafka立刻返回，另一边
: RDBMS慢慢出票就行了。但凡异步出票所有问题迎刃而解。

g*g2015-11-29 08:11

92 楼

为啥 fifo不公平，没排过队吗？

【在 a********c 的大作中提到】

:
: 世面上的秒杀基本都是rate limit在做，只是limit的方式不一样而已，说简单了就是
: 不同的方法怎样保证1秒放几个人，fifo才是不公平的。。。

L*e2015-11-29 08:11

93 楼

你这就是强词夺理了，那么这个世界上根本不存在不公平，因为每个人都有可能被不公
平对待这就是公平。
你这个把transaction rollback解释为退票这以前也讨论过，乙客户在被告知没票时他
也有权利进入waiting list等退票吧？而不应该是退票出来给丙。。。

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

: 每人都有“失而复得”的可能，就是公平啊，这跟有人退票产生新票也一个意思吧。

a*c2015-11-29 08:11

94 楼

说个简单的，网速有差别啊，地理有差别啊，etc
我现在就专门做秒杀，懒得跟你这种人挣

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

: 为啥 fifo不公平，没排过队吗？

t*r2015-11-29 08:11

95 楼

你这IP throttling在国内现有的infra根本行不通
美帝这头家家户户都有个external IP，我听所国内有的学校里几个宿舍楼都共享一个

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

: 不丢单也就没人去刷网站，这本身就减少了10倍以上的流量。另外加一点简单的 IP
: throttling. 票贩子就会被淹没在人民群众的汪洋大海里。

j*r2015-11-29 08:11

96 楼

这完全没问题，加网卡id, session id, 付款方式，用户身份信息，能把绝大多数票贩
子抓出来。
amazon已经很成熟的算法了

【在 t*********r 的大作中提到】

: 你这IP throttling在国内现有的infra根本行不通
: 美帝这头家家户户都有个external IP，我听所国内有的学校里几个宿舍楼都共享一个

L*e2015-11-29 08:11

97 楼

嗯，还有好多是在公司订票的，一个公司也是共享一个IP。。。

【在 t*********r 的大作中提到】

: 你这IP throttling在国内现有的infra根本行不通
: 美帝这头家家户户都有个external IP，我听所国内有的学校里几个宿舍楼都共享一个

y*u2015-11-29 08:11

98 楼

没票的时候确实“没票”，有票的时候确实“有票”，这就是公平。
anyway 我觉得是pm的活儿，就是个tradeoff。
实际工作中，这种类似的问题我是不会去吵的，作为码农业务上能理解能执行就行，pm
要征求意见就说一说。

【在 L*****e 的大作中提到】

: 你这就是强词夺理了，那么这个世界上根本不存在不公平，因为每个人都有可能被不公
: 平对待这就是公平。
: 你这个把transaction rollback解释为退票这以前也讨论过，乙客户在被告知没票时他
: 也有权利进入waiting list等退票吧？而不应该是退票出来给丙。。。

t*r2015-11-29 08:11

99 楼

车票单子应该远远小于买东西的单子吧，应该都不是一个数量级的

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

: Baba自己说了，光棍节能撑每秒12万的交易。你再想想春运能撑住吗。
: 12306现有的内存数据库，就是每秒10万级。一样网站没反应。

j*r2015-11-29 08:11

100 楼

大家其实不用争了，12306这个网站就是业余水平搞的
https://kyfw.12306.cn/otn/
搞了个ssl，但是是自己认证的，浏览器都会警告你这是病毒网站。
就这水平，我看大家没必要浪费时间给他们出主意了，他们估计优化一下界面都能比现
在强10倍。

pm

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

: 没票的时候确实“没票”，有票的时候确实“有票”，这就是公平。
: anyway 我觉得是pm的活儿，就是个tradeoff。
: 实际工作中，这种类似的问题我是不会去吵的，作为码农业务上能理解能执行就行，pm
: 要征求意见就说一说。

L*e2015-11-29 08:11

101 楼

那“没票”的时候，排队的所有人按既有顺序等“退票”，你不能告诉排前面的没票了
让他走人，然后转眼把“退票”卖给排后面的人。。。
系统设计本来大部分工作就是在需求分析和架构设计上，pm也就是这些年搞出来的新角
色，以前architect自己就是pm。。。

pm

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

z*32015-11-29 08:11

102 楼

i thought pm is just a label not a title

【在 L*****e 的大作中提到】

: 那“没票”的时候，排队的所有人按既有顺序等“退票”，你不能告诉排前面的没票了
: 让他走人，然后转眼把“退票”卖给排后面的人。。。
: 系统设计本来大部分工作就是在需求分析和架构设计上，pm也就是这些年搞出来的新角
: 色，以前architect自己就是pm。。。
:
: pm

t*r2015-11-29 08:11

103 楼

问题是版上讨论了半天其实也没有特别好的解决，尤其是一个能够支持查询还有没有票
的系统出来

【在 j********r 的大作中提到】

: 大家其实不用争了，12306这个网站就是业余水平搞的
: https://kyfw.12306.cn/otn/
: 搞了个ssl，但是是自己认证的，浏览器都会警告你这是病毒网站。
: 就这水平，我看大家没必要浪费时间给他们出主意了，他们估计优化一下界面都能比现
: 在强10倍。
:
: pm

L*e2015-11-29 08:11

104 楼

我也不懂pm到底算什么，亚麻的TPM角色我觉得很接近architect。。。

【在 z*******3 的大作中提到】

:
: i thought pm is just a label not a title

y*u2015-11-29 08:11

105 楼

查询和写库彻底分开
查询就是出发点、目的地、日期为key的key－value缓存嘛，定时＋写数据库push

【在 t*********r 的大作中提到】

: 问题是版上讨论了半天其实也没有特别好的解决，尤其是一个能够支持查询还有没有票
: 的系统出来

g*g2015-11-29 08:11

106 楼

这没错呀，hedge fund租 exchange的 floor，为的就是微妙级的网络优势。你听说过
股票 match不是先来后到的吗？

【在 a********c 的大作中提到】

:
: 说个简单的，网速有差别啊，地理有差别啊，etc
: 我现在就专门做秒杀，懒得跟你这种人挣

t*r2015-11-29 08:11

107 楼

你这个定时怎么定？
定长对用户没用处
定短了不准

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

: 查询和写库彻底分开
: 查询就是出发点、目的地、日期为key的key－value缓存嘛，定时＋写数据库push

y*u2015-11-29 08:11

108 楼

tradeoff！tradeoff！tradeoff！
玩过实时系统就知道了：算法一定要是完备的吗？该抛异常就优雅地抛异常，掌握好尺
度就行。

【在 t*********r 的大作中提到】

: 你这个定时怎么定？
: 定长对用户没用处
: 定短了不准

t*r2015-11-29 08:11

109 楼

tradeoff也要有个额度
两个选线都没用你再怎么选都没用，这个例子下你再怎么tradeoff用户看到的回馈都是
错的
并且是影响到体验的错

行。

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

: tradeoff！tradeoff！tradeoff！
: 玩过实时系统就知道了：算法一定要是完备的吗？该抛异常就优雅地抛异常，掌握好尺
: 度就行。

y*u2015-11-29 08:11

110 楼

具体说一下什么回馈是错的，怎么影响体验？

【在 t*********r 的大作中提到】

: tradeoff也要有个额度
: 两个选线都没用你再怎么选都没用，这个例子下你再怎么tradeoff用户看到的回馈都是
: 错的
: 并且是影响到体验的错
:
: 行。

g*g2015-11-29 08:11

111 楼

你懂得 false negative和 false positive的区别吗？不考虑退票，这个系统说有票不
一定有，说没票一定没了。而看到有票多半就是几分钟。等大家噼里啪啦下个单子，后
面的人本来就没戏。再过不到一个小时连下单都不让了。一个系统的体验，跟错误信号
的频率和长短关系是很大的。

【在 t*********r 的大作中提到】

: tradeoff也要有个额度
: 两个选线都没用你再怎么选都没用，这个例子下你再怎么tradeoff用户看到的回馈都是
: 错的
: 并且是影响到体验的错
:
: 行。

x*k2015-11-29 08:11

112 楼

查询和写分开带来的不一致是系统复杂的根源。所以不仅不该分开,还得合并。业务逻
辑变成你需要预付费买一个token,查询时如果有票就会instance帮你买到这个票. 没有
票就退款，买到了不要就自己退承担相应损失.这样的队列很好处理公平性，一个时间
戳搞定。顾客还想着查询？对于这种抢票的情节就不该提供查询.非热门时间车次才能
查询。

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

: 查询和写库彻底分开
: 查询就是出发点、目的地、日期为key的key－value缓存嘛，定时＋写数据库push

t*r2015-11-29 08:11

113 楼

春运加车厢加车次经常有
站里/网上买卖票经常有分配和挪动
现在没票的说不定等几个小时又有几车箱子的票子
所以你这个假设不成立
false positive和false negative都会有影响
即使只有false positive
按照你那套东西，我要等一个小时才能知道我买到票了没
我是该抢火车票还是抢飞机票？有好几个能用的行程要不要都去抢一下？都抢到了又要
去退？
太二了吧

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

: 你懂得 false negative和 false positive的区别吗？不考虑退票，这个系统说有票不
: 一定有，说没票一定没了。而看到有票多半就是几分钟。等大家噼里啪啦下个单子，后
: 面的人本来就没戏。再过不到一个小时连下单都不让了。一个系统的体验，跟错误信号
: 的频率和长短关系是很大的。

t*r2015-11-29 08:11

114 楼

你给我说没票其实有票
你给我说有票下单又出错说没票
其实我觉得选一个短的定时应该是个不错的选择
毕竟人多下单顾客反映不过来不是一个系统能解决的问题
但越短对系统的压力越大
不过一趟车就那么多座位，所以write的数目是有一定上限的

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

: 具体说一下什么回馈是错的，怎么影响体验？

b*s2015-11-29 08:11

115 楼

车票的难点是耦合性，比如上海到南京，有人先买了苏州到常州的票，这个座位后面的
销售情况就有变化
或者两个人联程，一个北京经上海到杭州，一个武汉经上海到杭州，分段出票，一个人
可能影响另一个人的出票
一旦交易间产生耦合，这问题的复杂性就上去了

【在 t*********r 的大作中提到】

: 车票单子应该远远小于买东西的单子吧，应该都不是一个数量级的

b*s2015-11-29 08:11

116 楼

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

【在 L*****e 的大作中提到】

: sharing解决不了联票的问题，古德坝要求100%不能丢票掉票，只要出现transaction
: conflict 或 rollback就不满足他说的要求了。。。

z*e2015-11-29 08:11

117 楼

别逗了，最不可接受的就是错误，尤其是涉及到钱的时候
所有人都精得跟什么一样，迟那么几分钟几个小时都不算什么
做金钱交易的服务器端，错一次就准备卷铺盖滚蛋吧
运气不好还会被告，如果被发现是有意的错误，比如往自己账户转账那种
就属于金融犯罪，准备进监狱吧，这里还有各级政府的稽核盯着
定期来查你几次，公司大的话，自己公司都有审核部门

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

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

b*s2015-11-29 08:11

118 楼

一个比较简单的设计，基本是把撮合和payment transcation剥离开
并且把查询和matching也剥离开
这样性能敏感部分可以快，支付可以有稳健
http://postimg.org/image/ams8fn2iz/
初始的从持久数据库里面load到matching system，这个是一个高计算能力的撮合机器
，类似交易所的撮合机器，撮合机器发送指令更新cache，然后等待撮合
这个是before mkt open的，按时做完就行，其实没多少数据，比如一百万张票，也不
牵涉复杂的锁操作，应该数据库不会慢到无法短时间搞定
然后用户能看到的是cache里面的票情况，cache在一定时间内，比如一秒内，可以看成
是静止的，用户可根据查询结果下单，cache是一组机器
下单直接经过下单服务器群到达撮合机器，撮合机器给成功以及失败，撮合机器就是老
魏类似那种思路，可以处理大量的orders，因为不牵涉到transcation，所以不会被数
据库拖慢，就是内存里直接裸的数据结构的操作。如果失败，返回nak给order sender
，如果成功，返回ack给payment机器的集群，这个集群挂数据库，有transcation，因
为实际支付的票数是不多的，这个冲击不是很大的。
如果支付失败,payment给matching box cancellation notice，成功则写数据库
matching box定期更新caches，cache和撮合机实际状况不一致在用户那里就是得到nak，
没有更严重后果了

b*s2015-11-29 08:11

119 楼

中间任意部分掉电，重启全系统即可，甚至部分重启都行，或者做failover也很容易
期间也不会出错
这样用户体验基本几秒内就拿到成功与否的反馈了，支付也是有安全保证的
肯定有考虑不周之处，欢迎挑刺

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

: 一个比较简单的设计，基本是把撮合和payment transcation剥离开
: 并且把查询和matching也剥离开
: 这样性能敏感部分可以快，支付可以有稳健
: http://postimg.org/image/ams8fn2iz/
: 初始的从持久数据库里面load到matching system，这个是一个高计算能力的撮合机器
: ，类似交易所的撮合机器，撮合机器发送指令更新cache，然后等待撮合
: 这个是before mkt open的，按时做完就行，其实没多少数据，比如一百万张票，也不
: 牵涉复杂的锁操作，应该数据库不会慢到无法短时间搞定
: 然后用户能看到的是cache里面的票情况，cache在一定时间内，比如一秒内，可以看成
: 是静止的，用户可根据查询结果下单，cache是一组机器

b*s2015-11-29 08:11

120 楼

我把拿票和付钱分开处理，付钱用transaction,你review一下吧

【在 z****e 的大作中提到】

: 别逗了，最不可接受的就是错误，尤其是涉及到钱的时候
: 所有人都精得跟什么一样，迟那么几分钟几个小时都不算什么
: 做金钱交易的服务器端，错一次就准备卷铺盖滚蛋吧
: 运气不好还会被告，如果被发现是有意的错误，比如往自己账户转账那种
: 就属于金融犯罪，准备进监狱吧，这里还有各级政府的稽核盯着
: 定期来查你几次，公司大的话，自己公司都有审核部门

b*s2015-11-29 08:11

121 楼

至于matching box如何实现，如何减少更新cache的数据搬移的冲击，想到了好办法了
，懒得打字了

z*e2015-11-29 08:11

122 楼

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

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

: 我把拿票和付钱分开处理，付钱用transaction,你review一下吧

b*s2015-11-29 08:11

123 楼

计数器就是让抢票的人马上看到结果，可以更改选择，用户体验好一点
其实付钱的也就是抢票的访问量的几千分之一甚至更少
不让这些慢速的阻碍抢票就好了
其实计数器我不是最喜欢，我有我的设计

【在 z****e 的大作中提到】

:
: txn肯定不在12306内部完成
: 肯定要发给银行
: 而且要经过公网
: 而且银行的接口协议是iso8583，不是丢一个json过去就可以了的
: 中间要经过gateway翻译，从发送req到最后接收到resp
: 最快最快2-3s内可以完成，这假设的是中间几乎没有任何的网络延迟
: 以及只经过一个gateway比如paypal
: 如果是多个gateway的话，会慢很多，比如apple pay发给paypal
: 再发给银行，然后银行处理后返回，这中间2-3s是最少的

z*e2015-11-29 08:11

124 楼

看到结果没用啊，划账没有完成，光看结果其本质就是一个异步
跟古德霸的异步效果没大差别，不过你这么做也不是没有道理
可以用这种方式增强体验

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

: 计数器就是让抢票的人马上看到结果，可以更改选择，用户体验好一点
: 其实付钱的也就是抢票的访问量的几千分之一甚至更少
: 不让这些慢速的阻碍抢票就好了
: 其实计数器我不是最喜欢，我有我的设计

b*s2015-11-29 08:11

125 楼

嗯，这个我觉得应该还是一个可行的改进
毕竟现在用户主要还是对响应不满

【在 z****e 的大作中提到】

:
: 看到结果没用啊，划账没有完成，光看结果其本质就是一个异步
: 跟古德霸的异步效果没大差别，不过你这么做也不是没有道理
: 可以用这种方式增强体验

b*s2015-11-29 08:11

126 楼

这个在用户体验上就是
没抢到的，卧槽，秒回没抢到，继续抢，这个焦虑是得到安抚的，比一小时没结果肯定
要舒服，你也知道国内人没什么耐心的
抢到的，慢慢支付，这个慢是可以接受的，定心了

【在 z****e 的大作中提到】

s*r2015-11-29 08:11

127 楼

not sure，第一年很烂，由铁道部信息中心独自完成
后来阿里提供了技术支持，就好多了
ssl证书是中国自己的机构签的，国内的浏览器能认，国外的不认，并不影响国内人民
使用

【在 j********r 的大作中提到】

m*s2015-11-29 08:11

128 楼

这个回复还是比较准确的。

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

: 这个在用户体验上就是
: 没抢到的，卧槽，秒回没抢到，继续抢，这个焦虑是得到安抚的，比一小时没结果肯定
: 要舒服，你也知道国内人没什么耐心的
: 抢到的，慢慢支付，这个慢是可以接受的，定心了

m*s2015-11-29 08:11

129 楼

你先冷静一下。
你所谓的排队上厕所，是指排队的都知道只要排到自己了自己就能进去上厕所脱裤子。
而不是自己花了10几分钟排队排到了却告诉你你可以上厕所脱裤子，还是你不可以上厕
所脱裤子得去别的厕所再碰运气。
不要混淆。

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

: 那么多人都要上厕所，你敢说排队不合理吗？莫非你没见过排队上厕所？你这个纯粹扯
: 蛋。

L*e2015-11-29 08:11

130 楼

呵呵，无脑兄也过来了。嗯，你说的这个就是咱们当年讨论后的折衷方案，或者说是个
将古德坝和魏老实方案的合并案，将排队，分配座位，和支付分开进行，不同阶段都给
出响应及更新。。。

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

m*s2015-11-29 08:11

131 楼

对于着急上厕所的你来说。
a, 当前厕所有空位，你直接进去上。
b, 当前厕所没空位，你选择排队或者直接在街上大小便。当然，绝大部分人这时候绝
不会选择自己直接大小便。
对于b，还分，你根据前面排队人的多少和队伍前进速度的快慢来判断你是否还等的起
，或排队人太多前进速度太慢你等不起而转身去别的厕所碰运气。这里面你排队的前提
也是假设当你排到的时候是保证你能上厕所而不是当你终于排到时只得到一个你可不可
以上厕所的通知。因为你不能确定如果你花了十几分钟排队后得到通知是不能上的话，
你是否能憋到找下一个公厕而不至于当街大小便。而且你找到下一个公厕根据你的系统
还是需要再排队十几分钟等通知告诉你能不能上而不是排到了就一定可以上。

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

: 那么多人都要上厕所，你敢说排队不合理吗？莫非你没见过排队上厕所？你这个纯粹扯
: 蛋。

s*r2015-11-29 08:11

132 楼

网上支付系统非常复杂，有几百个原因会导致支付失败。最常见的原因就是支付信息失
效，比如信用卡过期。先期验证无法保证后面的支付就一定会成功，失败的可能性很大

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

: 不说反正人比票多，再说支付验证是可以抢票之前就注册用户测试的。

P*X2015-11-29 08:11

133 楼

无聊爬了半天楼发现吵来吵去其实是因为定义的需求不一样。然后因为别人用的技术在
自己定义的需求下不够好而大叫大跳，互相看不起。其实各位大牛都没啥marketing训
练，都是自我感觉良好而已。你们看不起business/marketing训练是一回事，自己真的
能分析市场需求是另一回事。

m*s2015-11-29 08:11

134 楼

说的不错。
呵呵

【在 P******X 的大作中提到】

: 无聊爬了半天楼发现吵来吵去其实是因为定义的需求不一样。然后因为别人用的技术在
: 自己定义的需求下不够好而大叫大跳，互相看不起。其实各位大牛都没啥marketing训
: 练，都是自我感觉良好而已。你们看不起business/marketing训练是一回事，自己真的
: 能分析市场需求是另一回事。

g*g2015-11-29 08:11

135 楼

一刷刷一天都没票，比等一小时体验好？抢票的时候攒了一个大 waiting list, 加车
顺序通知就行了，非只有刷票一条路？一个单子有备用车次，也不会有买多的情况。

【在 t*********r 的大作中提到】

: 春运加车厢加车次经常有
: 站里/网上买卖票经常有分配和挪动
: 现在没票的说不定等几个小时又有几车箱子的票子
: 所以你这个假设不成立
: false positive和false negative都会有影响
: 即使只有false positive
: 按照你那套东西，我要等一个小时才能知道我买到票了没
: 我是该抢火车票还是抢飞机票？有好几个能用的行程要不要都去抢一下？都抢到了又要
: 去退？
: 太二了吧

g*g2015-11-29 08:11

136 楼

没有系统能撑住峰值的交易量需求，所以只有各种取舍。我老认为排队出票比暴力丢单
合理而已。

【在 t*********r 的大作中提到】

: 问题是版上讨论了半天其实也没有特别好的解决，尤其是一个能够支持查询还有没有票
: 的系统出来

s*x2015-11-29 08:11

137 楼

你老设计不出那样的系统，并不意味着别人也设计不出来。
说实在的，这个系统算是非常典型的高并发实时分布系统。

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

: 没有系统能撑住峰值的交易量需求，所以只有各种取舍。我老认为排队出票比暴力丢单
: 合理而已。

g*g2015-11-29 08:11

138 楼

我看是你不冷静，厕所是无限资源，车票是有限的，你要觉得不合适也是你的例子举得
不好。你觉得这个办法不好，非的一群人往厕所里挤，谁挤进去谁上？
电子系统无非是现实生活解决方案的虚拟化。排队排了没买着票是常有的事，不排队靠
挤要挨板砖的，你连这最低门槛都没过。

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

: 你先冷静一下。
: 你所谓的排队上厕所，是指排队的都知道只要排到自己了自己就能进去上厕所脱裤子。
: 而不是自己花了10几分钟排队排到了却告诉你你可以上厕所脱裤子，还是你不可以上厕
: 所脱裤子得去别的厕所再碰运气。
: 不要混淆。

g*g2015-11-29 08:11

139 楼

别逗了，世界上不存在这么快的交易系统。baba号称世界最快，也就每秒12万。
做系统设计不能好高骛远，可靠，有余量才是根本。

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

:
: 你老设计不出那样的系统，并不意味着别人也设计不出来。
: 说实在的，这个系统算是非常典型的高并发实时分布系统。

g*g2015-11-29 08:11

140 楼

没有错呀，预注册只不过提高交易成功的概率，没说必然成功。

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

: 网上支付系统非常复杂，有几百个原因会导致支付失败。最常见的原因就是支付信息失
: 效，比如信用卡过期。先期验证无法保证后面的支付就一定会成功，失败的可能性很大

s*x2015-11-29 08:11

141 楼

Sigh. 不教你了。

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

: 别逗了，世界上不存在这么快的交易系统。baba号称世界最快，也就每秒12万。
: 做系统设计不能好高骛远，可靠，有余量才是根本。

g*g2015-11-29 08:11

142 楼

你是没啥可教我的。现实最大。

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

:
: Sigh. 不教你了。

g*g2015-11-29 08:11

143 楼

别逗了，有联票之类的限制。高并发下，不用数据库，他们几个连个可靠的余票计数都
做不出来。这个已经证明过无数次了。

【在 z****e 的大作中提到】

t*r2015-11-29 08:11

144 楼

刷不到票子好歹客户知道没有票能去想别的办法，现在老百姓又不是火车一棵树吊死
你waiting list更扯淡了，一个小时后你给我发邮件说没抢到
好，我下单买飞机票
然后三个小时后突然发邮件又说我中了waiting list
太蛋疼了吧
按照天朝的国情这个waiting list应该也不小
假设你不发邮件就更扯了，车走之前你都不知道有票没
你把人搞的不知道有票没这个太玄乎了

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

: 一刷刷一天都没票，比等一小时体验好？抢票的时候攒了一个大 waiting list, 加车
: 顺序通知就行了，非只有刷票一条路？一个单子有备用车次，也不会有买多的情况。

m*s2015-11-29 08:11

145 楼

你错了，在你急着要上厕所时，厕所不是无限资源。你只有有非常有限的时间来控制你
自己马上不尿出来拉出来。只能是那些在你有限时间内可以达到的距离以内的厕所才是
理论上你可以去的。而你需要在短短且有限的时间内决定你去那个厕所否则你就拉裤子
了。
而你判断你去哪个厕所最优的依据就是你当前最近的这个厕所会让你花多长时间进去，
而不是你当前最近的厕所会让你花多长时间知道你能进去还是不能进去。
你着急上厕所，你会选择去那个你可以忍住而达到的附近的能让你解决你大小便的厕所
，虽然这个厕所不一定是最近的甚至不是比较近的。
回到前面说过的。你作为一个着急上厕所的，你需要能判断的是这个当前的厕所是否能
让你在你忍住的时间内进去上，而不是在你忍住的时间里高诉你一个能上不能上的通知。

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

: 我看是你不冷静，厕所是无限资源，车票是有限的，你要觉得不合适也是你的例子举得
: 不好。你觉得这个办法不好，非的一群人往厕所里挤，谁挤进去谁上？
: 电子系统无非是现实生活解决方案的虚拟化。排队排了没买着票是常有的事，不排队靠
: 挤要挨板砖的，你连这最低门槛都没过。

m*s2015-11-29 08:11

146 楼

本来我是打算用你申请绿卡排期这个作为例子的，
你绿卡排期虽然时间长，7、8年。但你知道只要过了8年排到了你了，就是处理你的绿
卡了。
而不是7、8年过去后，告诉你，你的申请可不可以被递交。
不过，用你着急上厕所时如何选择上附近的哪个厕所，厕所如何处理你的排队，是让你
花15分钟就能上还是让你花15分钟等一个消息，更合适。

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

g*g2015-11-29 08:11

147 楼

我不明白你想表达什么，你等得起就等，等不起就取消订单买机票去。比起你刷网站买
不着，体验哪点不强？

知。

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

: 你错了，在你急着要上厕所时，厕所不是无限资源。你只有有非常有限的时间来控制你
: 自己马上不尿出来拉出来。只能是那些在你有限时间内可以达到的距离以内的厕所才是
: 理论上你可以去的。而你需要在短短且有限的时间内决定你去那个厕所否则你就拉裤子
: 了。
: 而你判断你去哪个厕所最优的依据就是你当前最近的这个厕所会让你花多长时间进去，
: 而不是你当前最近的厕所会让你花多长时间知道你能进去还是不能进去。
: 你着急上厕所，你会选择去那个你可以忍住而达到的附近的能让你解决你大小便的厕所
: ，虽然这个厕所不一定是最近的甚至不是比较近的。
: 回到前面说过的。你作为一个着急上厕所的，你需要能判断的是这个当前的厕所是否能
: 让你在你忍住的时间内进去上，而不是在你忍住的时间里高诉你一个能上不能上的通知。

m*s2015-11-29 08:11

148 楼

而且为了保证自己能有多一点机会得到票，很可能在十几个车次上都排队。等最满意的
票到手后再把不需要的票都退了。

【在 t*********r 的大作中提到】

: 刷不到票子好歹客户知道没有票能去想别的办法，现在老百姓又不是火车一棵树吊死
: 你waiting list更扯淡了，一个小时后你给我发邮件说没抢到
: 好，我下单买飞机票
: 然后三个小时后突然发邮件又说我中了waiting list
: 太蛋疼了吧
: 按照天朝的国情这个waiting list应该也不小
: 假设你不发邮件就更扯了，车走之前你都不知道有票没
: 你把人搞的不知道有票没这个太玄乎了

g*g2015-11-29 08:11

149 楼

谁让你吊死了，等不及你可以取消订单呀。waiting list同样是给你一段时间愿意买就
买，不愿意下一个。有点常识行不？

【在 t*********r 的大作中提到】

m*s2015-11-29 08:11

150 楼

你着急上厕所大小便时在厕所前排队的等，是等什么？
你是等排15分钟队排到你后由厕所管理员告诉你，你是能进去上厕所，还是不能进去上
厕所吗？

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

: 我不明白你想表达什么，你等得起就等，等不起就取消订单买机票去。比起你刷网站买
: 不着，体验哪点不强？
:
: 知。

g*g2015-11-29 08:11

151 楼

按你的办法，上厕所靠挤，你就知道多久你能挤进去了？
我说得很明白，你要是只能等15分钟，那就15分钟后取消订单买机票，结果是一样的，
但是不需要刷15分钟的网站。还是比你的强。

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

: 而且为了保证自己能有多一点机会得到票，很可能在十几个车次上都排队。等最满意的
: 票到手后再把不需要的票都退了。

g*g2015-11-29 08:11

152 楼

你着急大小便的时候前面很长，你根本就不知道要等多久。你自己设个时间，顶不住了
就换地方。没见过大家往里挤，谁挤进去谁尿的，谁能保证你15分钟能挤进去？要找例
子也要找个对自己有利的。
你要着急大小便在厕所门上发力挤15分钟估计就不是大小便的问题了。

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

: 你着急上厕所大小便时在厕所前排队的等，是等什么？
: 你是等排15分钟队排到你后由厕所管理员告诉你，你是能进去上厕所，还是不能进去上
: 厕所吗？

m*s2015-11-29 08:11

153 楼

好虫。
排队等，有两种。
a. 排队15分钟，你知道只要你排到了，你就能拉屎撒尿。
b. 排队15分钟，你知道的只是你排到了，告诉你你是不是可以进去拉屎撒尿。
你的方法是第二种。

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

: 你着急大小便的时候前面很长，你根本就不知道要等多久。你自己设个时间，顶不住了
: 就换地方。没见过大家往里挤，谁挤进去谁尿的，谁能保证你15分钟能挤进去？要找例
: 子也要找个对自己有利的。
: 你要着急大小便在厕所门上发力挤15分钟估计就不是大小便的问题了。

g*g2015-11-29 08:11

154 楼

都比你挤8个小时不一定能挤进去强。另外，我可以提供现在有多少余票，有多少人排
在你前面，处理速度的大致信息，甚至算个概率出来。愿不愿意等是你的事情。
本质上我可以跟你说等下去有多大概率能上厕所，要等多久可以100%确定能不能上。根
据历史数据110%订单出来之后后面订单不让下等等。总之有响应是网站第一要务，其他
体验改进办法多得是。没响应啥都做不了。文明社会厕所还是靠排队的，不是靠挤。

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

: 好虫。
: 排队等，有两种。
: a. 排队15分钟，你知道只要你排到了，你就能拉屎撒尿。
: b. 排队15分钟，你知道的只是你排到了，告诉你你是不是可以进去拉屎撒尿。
: 你的方法是第二种。

t*r2015-11-29 08:11

155 楼

太扯了
老百姓又不知道你后台要处理多久，该不该多下几个单去抢，铁道部要像你这样打嘴炮
早被老百姓骂死了

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

: 谁让你吊死了，等不及你可以取消订单呀。waiting list同样是给你一段时间愿意买就
: 买，不愿意下一个。有点常识行不？

g*g2015-11-29 08:11

156 楼

网站刷一天都刷了，一样不知道多久能刷到，该干嘛干嘛等一个小时等不了？你让那些
售票大厅等几天的民工弟
兄情何以堪。别死撑了。

【在 t*********r 的大作中提到】

: 太扯了
: 老百姓又不知道你后台要处理多久，该不该多下几个单去抢，铁道部要像你这样打嘴炮
: 早被老百姓骂死了

t*r2015-11-29 08:11

157 楼

你加个estimate那个帖子我觉得靠点谱
但你说这一点我觉得不靠谱
刷不到票好歹是个准信
你这个的问题在于创造了太多的不确定性
人家该不该多排几个对?

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

: 网站刷一天都刷了，一样不知道多久能刷到，该干嘛干嘛等一个小时等不了？你让那些
: 售票大厅等几天的民工弟
: 兄情何以堪。别死撑了。

g*g2015-11-29 08:11

158 楼

没啥区别，你排在前面的话，迅速就处理了有准信。后面的话就是要等。靠挤的也好，
靠排队的也好，后台处理速度是一样的，都是满负荷。
等15分钟没买到跟刷15分钟没买到没啥本质区别，都可以改买机票去。都不是准信，都
有可能30分钟就买到了。宏观上谁能买到无非是排队和撞大运的分配不同。
至于你能排几个队系统同样可以限制。

【在 t*********r 的大作中提到】

: 你加个estimate那个帖子我觉得靠点谱
: 但你说这一点我觉得不靠谱
: 刷不到票好歹是个准信
: 你这个的问题在于创造了太多的不确定性
: 人家该不该多排几个对?

m*s2015-11-29 08:11

159 楼

好虫。
首先，我本楼所有论述都没有提及过"挤"这个字眼或概念。你不要自擅自修改我的论述。
你和我本楼的讨论中最主要区别就是在于对"等(排队)"的定义。
排队了，排了15分钟或者30分钟终于排到了，你希望得到的结果是你可以进去拉屎撒尿
，还是告诉你也许你可以进去拉屎撒尿。

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

: 都比你挤8个小时不一定能挤进去强。另外，我可以提供现在有多少余票，有多少人排
: 在你前面，处理速度的大致信息，甚至算个概率出来。愿不愿意等是你的事情。
: 本质上我可以跟你说等下去有多大概率能上厕所，要等多久可以100%确定能不能上。根
: 据历史数据110%订单出来之后后面订单不让下等等。总之有响应是网站第一要务，其他
: 体验改进办法多得是。没响应啥都做不了。文明社会厕所还是靠排队的，不是靠挤。

g*g2015-11-29 08:11

160 楼

刷网站就是挤厕所，没有什么不同。15分钟挤不进去有可能30分钟就挤进去了，就跟排
队15分钟没排到有可能30分钟能排到，没有本质区别。除了一个可以坐着等，一个要去
挤。有人第一分钟就挤进去了，就跟有人排队早，第一分钟就放进去了也一样。
诸位都是学计算机的，一个threadpool是带个queue还是大家都synchronize lock比运
气，本来就没有争的必要。

述。

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

: 好虫。
: 首先，我本楼所有论述都没有提及过"挤"这个字眼或概念。你不要自擅自修改我的论述。
: 你和我本楼的讨论中最主要区别就是在于对"等(排队)"的定义。
: 排队了，排了15分钟或者30分钟终于排到了，你希望得到的结果是你可以进去拉屎撒尿
: ，还是告诉你也许你可以进去拉屎撒尿。

t*r2015-11-29 08:11

161 楼

区别在于
我刷一次立马悲剧vs下个单一个小时候悲剧
后果的确一样，但是还是有时间成本的
你加个estimate的确减少了这个成本

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

: 没啥区别，你排在前面的话，迅速就处理了有准信。后面的话就是要等。靠挤的也好，
: 靠排队的也好，后台处理速度是一样的，都是满负荷。
: 等15分钟没买到跟刷15分钟没买到没啥本质区别，都可以改买机票去。都不是准信，都
: 有可能30分钟就买到了。宏观上谁能买到无非是排队和撞大运的分配不同。
: 至于你能排几个队系统同样可以限制。

g*g2015-11-29 08:11

162 楼

没有时间成本，如果你刷一次需要1分钟，你刷15次放弃，你等15分钟。排队你排15分
钟放弃，没啥区别。这个时候都还有票，继续刷和继续等都有可能拿到票，都不叫准信
。同样这15分钟内，你有可能刷到，也有可能排到。
一个小时只不过是票卖光了，确认买不着而已。

【在 t*********r 的大作中提到】

: 区别在于
: 我刷一次立马悲剧vs下个单一个小时候悲剧
: 后果的确一样，但是还是有时间成本的
: 你加个estimate的确减少了这个成本

t*r2015-11-29 08:11

163 楼

我刷一次没有说明下次放票之前都没票了，其实没必要继续刷
但要等一小时才知道就浪费了这一小时

信。

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

: 没有时间成本，如果你刷一次需要1分钟，你刷15次放弃，你等15分钟。排队你排15分
: 钟放弃，没啥区别。这个时候都还有票，继续刷和继续等都有可能拿到票，都不叫准信
: 。同样这15分钟内，你有可能刷到，也有可能排到。
: 一个小时只不过是票卖光了，确认买不着而已。

g*g2015-11-29 08:11

164 楼

别扯了，后台处理只有排队批处理更快，不会刷票快。排队会比刷票更早把票卖完。没
卖完之前一样都是有票状态。区别在于排队是可控的，还能给个概率。刷票纯粹撞大运。

【在 t*********r 的大作中提到】

: 我刷一次没有说明下次放票之前都没票了，其实没必要继续刷
: 但要等一小时才知道就浪费了这一小时
:
: 信。

L*e2015-11-29 08:11

165 楼

这个主要要看你的方案会产生多少conflicts或者transaction rollback。前面有同学
说了把这种rollback当作是“退票”，那么这种“退票”也就是下次放票的时间是无法
预期的，所有用户就会不停地刷以求好运能刷到“退票”，因为不停地重新刷实际上是
增加了throughput，虽然不完全等同于“挤”，实际效果确实和“挤”差不多，就是拼
网速，拼重刷频率，所以才有刷票软件的市场。。。

【在 t*********r 的大作中提到】

: 我刷一次没有说明下次放票之前都没票了，其实没必要继续刷
: 但要等一小时才知道就浪费了这一小时
:
: 信。

t*r2015-11-29 08:11

166 楼

票卖完了加waitlist排队我不反对啊，商家卖东西也是这么做的

【在 L*****e 的大作中提到】

: 这个主要要看你的方案会产生多少conflicts或者transaction rollback。前面有同学
: 说了把这种rollback当作是“退票”，那么这种“退票”也就是下次放票的时间是无法
: 预期的，所有用户就会不停地刷以求好运能刷到“退票”，因为不停地重新刷实际上是
: 增加了throughput，虽然不完全等同于“挤”，实际效果确实和“挤”差不多，就是拼
: 网速，拼重刷频率，所以才有刷票软件的市场。。。

g*g2015-11-29 08:11

167 楼

很多人以为刷一次没有就是没票，用过12306吗？刷票没刷上意味着你的单子在到达数
据库之前丢了，或者数据库太忙，等待太久timeout了。这些才是大头，数据库处理了
没锁上票的是极小部分，这部分才是真没票的。一旦没票系统就不让你下单了，这部分
都是过渡的几秒钟。
这就是为什么刷一次没有，再刷一次可能有。看着还很多就是买不着，甚至不热门的车
次也躺枪。数据库处理不了这样的峰值，前面弄个queue缓冲异步处理，本来就是个常
见办法而已。一堆人脑子就是转不过来。

m*s2015-11-29 08:11

168 楼

看到这里，只说一句题外话。我再一次理解为什么你只能当高级程序员了(此话没有任
何贬意或褒义)。好虫，原来我一直觉得你不出去自己单干是屈才了，其实是我之前想
错了。
我前面用你急需上厕所需要根据厕所排队人多人少决定你自己下一步去哪里上厕所的例
子，你确实是看不明白了，也许是你自己不想让你自己看明白了的。
享受科比的最后一个赛季吧。

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

: 很多人以为刷一次没有就是没票，用过12306吗？刷票没刷上意味着你的单子在到达数
: 据库之前丢了，或者数据库太忙，等待太久timeout了。这些才是大头，数据库处理了
: 没锁上票的是极小部分，这部分才是真没票的。一旦没票系统就不让你下单了，这部分
: 都是过渡的几秒钟。
: 这就是为什么刷一次没有，再刷一次可能有。看着还很多就是买不着，甚至不热门的车
: 次也躺枪。数据库处理不了这样的峰值，前面弄个queue缓冲异步处理，本来就是个常
: 见办法而已。一堆人脑子就是转不过来。

i*k2015-11-29 08:11

169 楼

我反对这种说法。
对于计算机来说当然没有必要方法都是公平等价的，但是对人来说不一样。你玩命的刷
15分钟，刷到一张票，那种喜悦和15分钟后告诉你拿到票了是不可同日而语的，然后就
忘了去骂12306了。
你们学计算机的就是喜欢把人看成是没感情的计算机，图样图森破啊！

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

: 刷网站就是挤厕所，没有什么不同。15分钟挤不进去有可能30分钟就挤进去了，就跟排
: 队15分钟没排到有可能30分钟能排到，没有本质区别。除了一个可以坐着等，一个要去
: 挤。有人第一分钟就挤进去了，就跟有人排队早，第一分钟就放进去了也一样。
: 诸位都是学计算机的，一个threadpool是带个queue还是大家都synchronize lock比运
: 气，本来就没有争的必要。
:
: 述。

t*r2015-11-29 08:11

170 楼

他说的ESTIMATE倒是解决的你说的问题

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

: 看到这里，只说一句题外话。我再一次理解为什么你只能当高级程序员了(此话没有任
: 何贬意或褒义)。好虫，原来我一直觉得你不出去自己单干是屈才了，其实是我之前想
: 错了。
: 我前面用你急需上厕所需要根据厕所排队人多人少决定你自己下一步去哪里上厕所的例
: 子，你确实是看不明白了，也许是你自己不想让你自己看明白了的。
: 享受科比的最后一个赛季吧。

t*r2015-11-29 08:11

171 楼

LZ问的本身是如何设计这套东西，不是叫你在现有的设计和实现上挑刺
一套轮子用的不对出瓶颈并不能说明别的轮子会有同样的瓶颈

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

g*g2015-11-29 08:11

172 楼

分明是你想错了，你去挤厕所，挤不进去可以走，排队，等不了也可以走。排队还可以
跟你说有多少人在你前面，有多少余票，多高概率能拿到，等多久能确定。挤根本就是
撞大运的事情。
文明社会，本来就没有挤厕所的。你非要钻牛角尖不出来就不关我的事了。我也从来不
在乎别人如何看我。

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

g*g2015-11-29 08:11

173 楼

世界上已知最快的系统只能每秒处理12万个交易，耦合度还比12306低。等硬件能比现
在快10倍，问题可以自动解决，但在此之前，没有任何同步系统能够不丢订单，这个很
难理解吗？我只不过给出一种异步的方案而已。

【在 t*********r 的大作中提到】

: LZ问的本身是如何设计这套东西，不是叫你在现有的设计和实现上挑刺
: 一套轮子用的不对出瓶颈并不能说明别的轮子会有同样的瓶颈

m*s2015-11-29 08:11

174 楼

你还嘴硬。
我本楼那里提过挤了？
我一直说的是，你的排队过15分钟等通知就类似于急着上厕所的你却只能排15分钟厕所
队但得到的结果是厕所管理员在你排了15分钟队之后告诉你可不可以进，而不是你排到
之后就马上进厕所拉屎撒尿。

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

: 分明是你想错了，你去挤厕所，挤不进去可以走，排队，等不了也可以走。排队还可以
: 跟你说有多少人在你前面，有多少余票，多高概率能拿到，等多久能确定。挤根本就是
: 撞大运的事情。
: 文明社会，本来就没有挤厕所的。你非要钻牛角尖不出来就不关我的事了。我也从来不
: 在乎别人如何看我。

g*g2015-11-29 08:11

175 楼

你才嘴硬。12306数据库能每秒处理10万单子，你每秒来20万，其中10万单子随机扔掉
，那不叫挤？这就是10万人挤进去了，另外十万被挤破脑袋，后面一秒20万又来了，这
十万连优先权都没有。
让你挤厕所你能确定15分钟后能挤进去？15分钟后你能确定啥时候能挤进去？你觉得我
的结果不好，你的结果更差。
如果所有的票排队要一个小时才能处理完，挤还是得至少一个小时。事实上因为反复刷
，外部负荷更大，内部job大量timeout。只会更慢。一个系统的处理速度是由瓶颈决定
的，不是由排不排队这样的非瓶颈部分决定的。我看你缺乏common sense。

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

: 你还嘴硬。
: 我本楼那里提过挤了？
: 我一直说的是，你的排队过15分钟等通知就类似于急着上厕所的你却只能排15分钟厕所
: 队但得到的结果是厕所管理员在你排了15分钟队之后告诉你可不可以进，而不是你排到
: 之后就马上进厕所拉屎撒尿。

s*x2015-11-29 08:11

176 楼

那只能说明12306现在的设计不行，不能证明你的想法不是狗屎。
实时是must to have, not even nice to have.
If you think you can not do it, just be quiet.

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

: 你才嘴硬。12306数据库能每秒处理10万单子，你每秒来20万，其中10万单子随机扔掉
: ，那不叫挤？这就是10万人挤进去了，另外十万被挤破脑袋，后面一秒20万又来了，这
: 十万连优先权都没有。
: 让你挤厕所你能确定15分钟后能挤进去？15分钟后你能确定啥时候能挤进去？你觉得我
: 的结果不好，你的结果更差。
: 如果所有的票排队要一个小时才能处理完，挤还是得至少一个小时。事实上因为反复刷
: ，外部负荷更大，内部job大量timeout。只会更慢。一个系统的处理速度是由瓶颈决定
: 的，不是由排不排队这样的非瓶颈部分决定的。我看你缺乏common sense。

g*g2015-11-29 08:11

177 楼

别装了行不，baba自己说光棍节能处理12万/秒的交易量，世界上最大。12306内部人出
来说峰值订单超过每秒20万。
这东西说到底就是CAP theorem的限制，我设计不了永动机，也没有人可以。如何取舍
是一个架构设计的精髓所在，世界不是非黑既白。

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

:
: 那只能说明12306现在的设计不行，不能证明你的想法不是狗屎。
: 实时是must to have, not even nice to have.
: If you think you can not do it, just be quiet.

s*x2015-11-29 08:11

178 楼

人类没法突破每秒20万了？Nasdaq 不行？你太naive 了。停在石器时代。

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

: 别装了行不，baba自己说光棍节能处理12万/秒的交易量，世界上最大。12306内部人出
: 来说峰值订单超过每秒20万。
: 这东西说到底就是CAP theorem的限制，我设计不了永动机，也没有人可以。如何取舍
: 是一个架构设计的精髓所在，世界不是非黑既白。

b*s2015-11-29 08:11

179 楼

左眼兄好，这方案其实没古德霸什么事，核心还是老魏的，至于古德霸说一秒十二万交
易是他知道的上限，这也没错，如果把支付完成看成交易完成，那还真是用不了这个交
易量

【在 L*****e 的大作中提到】

: 呵呵，无脑兄也过来了。嗯，你说的这个就是咱们当年讨论后的折衷方案，或者说是个
: 将古德坝和魏老实方案的合并案，将排队，分配座位，和支付分开进行，不同阶段都给
: 出响应及更新。。。

t*r2015-11-29 08:11

180 楼

你这就是抬杠耍无赖了

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

:
: 人类没法突破每秒20万了？Nasdaq 不行？你太naive 了。停在石器时代。

g*g2015-11-29 08:11

181 楼

你太幼稚了，12年的数据，Nasdaq peak orders也不过每秒58万，还是几千个symbol。
Nasdaq可没有联程票一说，你可以下一个单子，苹果和谷歌 all or nothing吗？
人类硬件提高可以突破20万，那之前就不要卖票了是吧？你这种狗屎想法做啥架构呀。

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

:
: 人类没法突破每秒20万了？Nasdaq 不行？你太naive 了。停在石器时代。

g*g2015-11-29 08:11

182 楼

LOL，你跟太监合起来都做不出一个没缺陷的计数器，现在要重写历史？

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

: 左眼兄好，这方案其实没古德霸什么事，核心还是老魏的，至于古德霸说一秒十二万交
: 易是他知道的上限，这也没错，如果把支付完成看成交易完成，那还真是用不了这个交
: 易量

t*r2015-11-29 08:11

183 楼

用户本身不太在乎你总THROUGHPUT高低
他只在乎他自己单子有没有下
你如果嫌内部TIMEOUT太多可以像IMGUR／网游刚上线登陆一样让人在系统外面挤／排队
同步下单如果能做到要比异步好这一点你不否定吧？
即使你要排队，在系统外面排队然后下单也要比无脑下单然后被告知没抢到体验要好

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

b*s2015-11-29 08:11

184 楼

好好讨论，别讲什么幼稚不幼稚的

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

: 你太幼稚了，12年的数据，Nasdaq peak orders也不过每秒58万，还是几千个symbol。
: Nasdaq可没有联程票一说，你可以下一个单子，苹果和谷歌 all or nothing吗？
: 人类硬件提高可以突破20万，那之前就不要卖票了是吧？你这种狗屎想法做啥架构呀。

g*g2015-11-29 08:11

185 楼

废话，谁不知道同步下单比异步强。同步下单还简单。问题是做不到呗。能做到还有啥
好设计的。但凡丢单，不叫做同步下单。

【在 t*********r 的大作中提到】

: 用户本身不太在乎你总THROUGHPUT高低
: 他只在乎他自己单子有没有下
: 你如果嫌内部TIMEOUT太多可以像IMGUR／网游刚上线登陆一样让人在系统外面挤／排队
: 同步下单如果能做到要比异步好这一点你不否定吧？
: 即使你要排队，在系统外面排队然后下单也要比无脑下单然后被告知没抢到体验要好

b*s2015-11-29 08:11

186 楼

其实古德霸一直在混淆概念，
比如nasdaq每秒五十八万峰值，
其实是写数据库的，数据库带来的I/O延迟才是性能瓶颈，如果把抢票和数据库绑定，
那是肯定要慢的，而买票这个事情，其实每秒支付的十万都够了
这点都不明白，果然是java + db日子好过

g*g2015-11-29 08:11

187 楼

你没发现摆事实讲道理的是我老，拍脑袋你的想法就是狗屎的是另一位吗？

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

: 好好讨论，别讲什么幼稚不幼稚的

g*g2015-11-29 08:11

188 楼

12306出票不用写数据库？那个太监计数器你不是又要拿出来让大家嘲笑一次吧？

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

: 其实古德霸一直在混淆概念，
: 比如nasdaq每秒五十八万峰值，
: 其实是写数据库的，数据库带来的I/O延迟才是性能瓶颈，如果把抢票和数据库绑定，
: 那是肯定要慢的，而买票这个事情，其实每秒支付的十万都够了
: 这点都不明白，果然是java + db日子好过

b*s2015-11-29 08:11

189 楼

我能说的都说了，就这样吧

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

: 12306出票不用写数据库？那个太监计数器你不是又要拿出来让大家嘲笑一次吧？

g*g2015-11-29 08:11

190 楼

是没啥好说的，当年你们几个能想出来的办法都被扁过了。嘴上还是不服，qxc把机器
拿出来，最后结果就是尿遁。

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

: 我能说的都说了，就这样吧

s*r2015-11-29 08:11

191 楼

支付才是瓶颈吧，比写数据库慢多了，国内还有手机验证的步骤，应该无法做到支付同
步，导致抢票的情况更加复杂

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

g*g2015-11-29 08:11

192 楼

支付才是瓶颈没错，但光数据库就撑不住这样的transaction，12306可是内存数据库都
上了。

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

: 支付才是瓶颈吧，比写数据库慢多了，国内还有手机验证的步骤，应该无法做到支付同
: 步，导致抢票的情况更加复杂

z*e2015-11-29 08:11

193 楼

有一个问题，你怎么知道票务信息都在内存里？
用常识猜测，都在db里面放着的可能性比较大
启动时候把所有票务信息读入内存，这会是多么麻烦的一件事
也就是硬盘上的数据结构从一开始就可能很复杂
不是说你想怎么定义就可以怎么定义的
估计有一堆fk,pk这些约束

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

: 嗯，这个我觉得应该还是一个可行的改进
: 毕竟现在用户主要还是对响应不满

z*e2015-11-29 08:11

194 楼

关键就在txn这一步
抢票如果涉及db一样要txn
而票的信息在db里面的可能性是极大的
几乎可以肯定在db里面
当时我找出了新闻，铁道部用的是sybase的db

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

T*92015-11-29 08:11

195 楼

这个还是要用event processing

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

s*x2015-11-29 08:11

196 楼

瞎扯，支付这种单用户交割的分布式小学生都会做。 fb 支持十几亿活跃用户，全中国
十亿人同抢一个座位的概率有多大？
Wechat 的读写也不知比这个系统复杂多少倍。了

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

: 支付才是瓶颈没错，但光数据库就撑不住这样的transaction，12306可是内存数据库都
: 上了。

y*u2015-11-29 08:11

197 楼

前文再发
提醒：要战胜铁道研究院信息技术中心，至少要先了解一下同行是怎么做的吧。
查询和存数据肯定是分开的。
现实中也是分开的，查询占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

【在 z****e 的大作中提到】

: 有一个问题，你怎么知道票务信息都在内存里？
: 用常识猜测，都在db里面放着的可能性比较大
: 启动时候把所有票务信息读入内存，这会是多么麻烦的一件事
: 也就是硬盘上的数据结构从一开始就可能很复杂
: 不是说你想怎么定义就可以怎么定义的
: 估计有一堆fk,pk这些约束

g*g2015-11-29 08:11

198 楼

别扯蛋了，12306允许你一个单子买多票，联程票。你买的也不是座位，而是日期车次
起始站，你想分割就分割？你从北京到广东某个小站，广州到小站的买到了，北京到广
州的没有，钱交了走不了。脑子一团浆糊还出来瞎指点。

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

:
: 瞎扯，支付这种单用户交割的分布式小学生都会做。 fb 支持十几亿活跃用户，全中国
: 十亿人同抢一个座位的概率有多大？
: Wechat 的读写也不知比这个系统复杂多少倍。了

s*x2015-11-29 08:11

199 楼

老兄，你还是先想想假若没有联票能不能做成实时响应的再想联票怎么弄好不好？
有了实时响应系统，怎么联都不是问题。没有实时，根本不会有人用你的系统。

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

: 别扯蛋了，12306允许你一个单子买多票，联程票。你买的也不是座位，而是日期车次
: 起始站，你想分割就分割？你从北京到广东某个小站，广州到小站的买到了，北京到广
: 州的没有，钱交了走不了。脑子一团浆糊还出来瞎指点。

s*x2015-11-29 08:11

200 楼

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

g*g2015-11-29 08:11

201 楼

你根本就是本末倒置，就是因为联票所以难。要不然一个车次一天几千张票，十几段，
每个车次
一个数据库几秒钟就弄完了，怎么都实时。我拜托你能不能一次把这些都想清楚了，质
疑了一整天，连最基本的问题都没想明白。牛逼哄哄拿个nasdaq来类比，到头来才发现
不是那么回事。

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

s*x2015-11-29 08:11

202 楼

你一车能实时，来回两个车就要一个小时？你脑子进水？

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

: 你根本就是本末倒置，就是因为联票所以难。要不然一个车次一天几千张票，十几段，
: 每个车次
: 一个数据库几秒钟就弄完了，怎么都实时。我拜托你能不能一次把这些都想清楚了，质
: 疑了一整天，连最基本的问题都没想明白。牛逼哄哄拿个nasdaq来类比，到头来才发现
: 不是那么回事。

g*g2015-11-29 08:11

203 楼

你脑子才进水，我只不过把订单放进queue里，异步能不能实时纯粹看你多久能响应。
一耦合就不是一车两车的问题。你这水平实在太低，不说话没人当你是哑巴。

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

:
: 你一车能实时，来回两个车就要一个小时？你脑子进水？

s*x2015-11-29 08:11

204 楼

Lol 你能把个实时系统整成一两个小时，确实水平不一般。中国人民很庆幸12306 不是
由你设计的。

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

: 你脑子才进水，我只不过把订单放进queue里，异步能不能实时纯粹看你多久能响应。
: 一耦合就不是一车两车的问题。你这水平实在太低，不说话没人当你是哑巴。

g*g2015-11-29 08:11

205 楼

打这嘴炮没用，两趟车一旦耦合，基本所有车次都可以直接或者间接耦合。连这个都想
不到的不配跟我谈什么架构。
丢单的系统也不叫实时系统。实时系统意味着对所有订单可以响应，而且有票必须出。
现有的12306不是什么实时系统。
都不是实时系统，至少我的设计公平，不用刷网站。

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

:
: Lol 你能把个实时系统整成一两个小时，确实水平不一般。中国人民很庆幸12306 不是
: 由你设计的。

s*x2015-11-29 08:11

206 楼

你水平高，应该用在正确方向上，一个不是实时的系统等于狗屎。你的queue是用火车
车厢做的吧，一个小时处理一个？

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

: 打这嘴炮没用，两趟车一旦耦合，基本所有车次都可以直接或者间接耦合。连这个都想
: 不到的不配跟我谈什么架构。
: 丢单的系统也不叫实时系统。实时系统意味着对所有订单可以响应，而且有票必须出。
: 现有的12306不是什么实时系统。
: 都不是实时系统，至少我的设计公平，不用刷网站。

g*g2015-11-29 08:11

207 楼

你战风车有用吗？throughput大于系统承受能力就是个现实问题，大坝是为了雨季蓄水
，别把下游冲了。如果没那么多水自然可以进多少出多少。我设计的系统，因为没有反
复刷单，处理比现有系统还快。能处理多少处理多少剩下扔掉不叫座实
时。实时的系统要吗有，要吗没有，不需要反复刷网站。
你连定义都弄不明白出来丢人能改变啥？

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

:
: 你水平高，应该用在正确方向上，一个不是实时的系统等于狗屎。你的queue是用火车
: 车厢做的吧，一个小时处理一个？

j*o2015-11-29 08:11

208 楼

你这个不用刷网站和高考填志愿没什么区别。考生把第一第二第三志愿填完了，等放榜
日看自己有没有被录取，没录取就复读。
这个和技术没什么太大关系了，只是用户心理上能不能接受的问题。目前来看多数人是
接受不了的。

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

g*g2015-11-29 08:11

209 楼

售票大厅也是排队，不是闹哄哄挤到售票口，谁抢到归谁。排了队买不到也是正常的。
不能接受的不是需要买票的
，是这里有些人的脸皮。

【在 j******o 的大作中提到】

: 你这个不用刷网站和高考填志愿没什么区别。考生把第一第二第三志愿填完了，等放榜
: 日看自己有没有被录取，没录取就复读。
: 这个和技术没什么太大关系了，只是用户心理上能不能接受的问题。目前来看多数人是
: 接受不了的。

m*s2015-11-29 08:11

210 楼

你排队排到了窗口，得到的是售票员脸对脸告诉你：好虫你走吧，等你的短信通知，别
急，如果不出意外，你会在15分钟到30分钟之后得到短信通知，告诉你你刚才的排队是
否买到了票还是你询问的车次目前已经没有票了。
呵呵。

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

: 售票大厅也是排队，不是闹哄哄挤到售票口，谁抢到归谁。排了队买不到也是正常的。
: 不能接受的不是需要买票的
: ，是这里有些人的脸皮。

s*x2015-11-29 08:11

211 楼

用户不是不刷，是会隔一小时再刷。所以不是脑残的人很难会想到这么妙的idea.

【在 j******o 的大作中提到】

g*g2015-11-29 08:11

212 楼

随便挤你多半15分钟都没挤到窗口，指示牌还写着有票。窗口下挤死一堆人都是自找的
。文明社会之所以发明了排队，不是没有原因的。

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

: 你排队排到了窗口，得到的是售票员脸对脸告诉你：好虫你走吧，等你的短信通知，别
: 急，如果不出意外，你会在15分钟到30分钟之后得到短信通知，告诉你你刚才的排队是
: 否买到了票还是你询问的车次目前已经没有票了。
: 呵呵。

g*g2015-11-29 08:11

213 楼

12306之所以分时放票，就因为数据库处理不了这样的负荷。
让你等一小时再刷愿意，等一小时直接出排队结果就不行？都是一帮装逼的。

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

:
: 用户不是不刷，是会隔一小时再刷。所以不是脑残的人很难会想到这么妙的idea.

j*o2015-11-29 08:11

214 楼

在车票有限的情况下，再NB的硬件和马工也解决不了问题，总有人买不到票。12306就
算用天顶星技术，能够实现不丢票，即时完成交易，不出错，最后还是没什么卵用。这
个订票的事就跟马工没多大关系，是一个如何平民愤的问题。
现在基本能考虑的是：
1.如何减少黄牛票。
2.如何通知让定不上票的人更改路线，越快越好。
3.怎么安抚啥也没买到的人。

g*g2015-11-29 08:11

215 楼

着火了，可以大家挤着跑出去，踩死的都活该。也可以排队走出去。
感情楼上都是鼓励踩死活该的。

j*o2015-11-29 08:11

216 楼

你刷一个小时票，最后有可能第1分钟就刷到了，也有可能没刷到。
和你过一个小时告诉他有没有被录取。人本能都会选第一个。更别说那等待的一个小时
猫腻太多。

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

: 12306之所以分时放票，就因为数据库处理不了这样的负荷。
: 让你等一小时再刷愿意，等一小时直接出排队结果就不行？都是一帮装逼的。

g*g2015-11-29 08:11

217 楼

分时放票，对黄牛有利。一天只能抢一次，订单不丢，黄牛就淹没在人民群众大海中。

【在 j******o 的大作中提到】

: 在车票有限的情况下，再NB的硬件和马工也解决不了问题，总有人买不到票。12306就
: 算用天顶星技术，能够实现不丢票，即时完成交易，不出错，最后还是没什么卵用。这
: 个订票的事就跟马工没多大关系，是一个如何平民愤的问题。
: 现在基本能考虑的是：
: 1.如何减少黄牛票。
: 2.如何通知让定不上票的人更改路线，越快越好。
: 3.怎么安抚啥也没买到的人。

g*g2015-11-29 08:11

218 楼

你排队，也有可能第一分钟就排到，没有任何区别。一分钟后台能出的票就那么多。
本来就是个排队和乐透的区别。

【在 j******o 的大作中提到】

: 你刷一个小时票，最后有可能第1分钟就刷到了，也有可能没刷到。
: 和你过一个小时告诉他有没有被录取。人本能都会选第一个。更别说那等待的一个小时
: 猫腻太多。

j*o2015-11-29 08:11

219 楼

你不会天真地以为黄牛都和大家一样坐在电脑前等着放票吧？

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

: 分时放票，对黄牛有利。一天只能抢一次，订单不丢，黄牛就淹没在人民群众大海中。

g*g2015-11-29 08:11

220 楼

很多黄牛就是这样，弄个刷票软件，企业级光纤，比你快而已。

【在 j******o 的大作中提到】

: 你不会天真地以为黄牛都和大家一样坐在电脑前等着放票吧？

j*o2015-11-29 08:11

221 楼

等级不一样。你没中乐透大不了损失2块钱，没买到nexus6大不了旧手机继续用。要是
没买到票回不了家，那可是天大的事情。
你的设想不就是想把排队变成乐透吗？

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

: 你排队，也有可能第一分钟就排到，没有任何区别。一分钟后台能出的票就那么多。
: 本来就是个排队和乐透的区别。

g*g2015-11-29 08:11

222 楼

错了，刷票就是挤窗口，乐透。异步才是排队。
我老认为排队比乐透公平。你们不服也没有。生活中是靠排队，不是靠挤来解决问题的

【在 j******o 的大作中提到】

: 等级不一样。你没中乐透大不了损失2块钱，没买到nexus6大不了旧手机继续用。要是
: 没买到票回不了家，那可是天大的事情。
: 你的设想不就是想把排队变成乐透吗？

j*o2015-11-29 08:11

223 楼

我不觉得你这个和乐透有什么区别，什么是排队？排队就是先来后到。你这里的先来后
到体现在哪里？

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

: 错了，刷票就是挤窗口，乐透。异步才是排队。
: 我老认为排队比乐透公平。你们不服也没有。生活中是靠排队，不是靠挤来解决问题的

g*g2015-11-29 08:11

224 楼

我靠，没明白我系统怎么设计的就来喷了？谁单子先提交到服务器，谁就排在前面。怎
么不是排队。

【在 j******o 的大作中提到】

: 我不觉得你这个和乐透有什么区别，什么是排队？排队就是先来后到。你这里的先来后
: 到体现在哪里？

j*o2015-11-29 08:11

225 楼

那你处理完返回就完了，让用户等个3，5分钟，和现在的系统一模一样，等15分钟统一
通知不就是脱裤子放屁。
你的系统唯一的用户就是本来刷一天票的，现在需要刷3天。你连铁道部为啥需要一个
网上订票系统的原因都搞不清楚。

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

: 我靠，没明白我系统怎么设计的就来喷了？谁单子先提交到服务器，谁就排在前面。怎
: 么不是排队。

m*s2015-11-29 08:11

226 楼

哈哈哈，好虫已经不能自拔了。

【在 j******o 的大作中提到】

: 那你处理完返回就完了，让用户等个3，5分钟，和现在的系统一模一样，等15分钟统一
: 通知不就是脱裤子放屁。
: 你的系统唯一的用户就是本来刷一天票的，现在需要刷3天。你连铁道部为啥需要一个
: 网上订票系统的原因都搞不清楚。

g*g2015-11-29 08:11

227 楼

如果排在前面的自然是处理到就通知了。统一通知的是票卖完了。
后端的处理能力是一样的。当然是我的系统处理的快。没有浪费资源在刷票上。成功出
票单位时间我的系统只会多，不会少。

【在 j******o 的大作中提到】

m*s2015-11-29 08:11

228 楼

一天只能抢一次？
你的系统靠什么识别并限制你好虫只能一天抢一次？

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

: 分时放票，对黄牛有利。一天只能抢一次，订单不丢，黄牛就淹没在人民群众大海中。

g*g2015-11-29 08:11

229 楼

操，你不是这么弱智吧。用户跟身份证是绑定的，现在连手机验证码都上了。假如黄牛
有100个身份证，100个手机。发一次票刷100张，分10次就刷1000张。多简单的道理。

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

: 一天只能抢一次？
: 你的系统靠什么识别并限制你好虫只能一天抢一次？

z*e2015-11-29 08:11

230 楼

http://database.51cto.com/art/201101/243802.htm

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

: 前文再发
: 提醒：要战胜铁道研究院信息技术中心，至少要先了解一下同行是怎么做的吧。
: 查询和存数据肯定是分开的。
: 现实中也是分开的，查询占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

s*r2015-11-29 08:11

231 楼

这是铁路的窗口售票系统，不是这里讨论的12306

【在 z****e 的大作中提到】

: http://database.51cto.com/art/201101/243802.htm

z*e2015-11-29 08:11

232 楼

this is exactly what i said in previous post
i didnt say it is 12306
i was asking where the tickets come from?

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

: 这是铁路的窗口售票系统，不是这里讨论的12306

d*r2015-11-29 08:11

233 楼

其实这也是一个办法，搞一个假实时系统，client 端弄个JavaScript 转啊转或者弄个
long polling, sever端再高效一点，用户等个二三四分钟应该有个结果，用户感受还
可以接受。
我们还不如算算5分钟理论最高throughput.
其实现在single thread web server就是这玩意，sever端在排队，用户端觉得实时。

【在 j******o 的大作中提到】

L*e2015-11-29 08:11

234 楼

嗯，两百多层了。。。我老在35楼对此楼做了准确的预言。。。

b*s2015-11-29 08:11

235 楼

the impact is on caches
not a big issue

【在 L*****e 的大作中提到】

m*s2015-11-29 08:11

236 楼

好虫，你不会那么弱智到居然还认为身份证是能够识别好虫你身份的ID吧？

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

: 操，你不是这么弱智吧。用户跟身份证是绑定的，现在连手机验证码都上了。假如黄牛
: 有100个身份证，100个手机。发一次票刷100张，分10次就刷1000张。多简单的道理。

m*s2015-11-29 08:11

237 楼

你不如预言一下，你什么时候能建立公司并使得你公司正式员工数突破50人。

【在 L*****e 的大作中提到】

: 嗯，两百多层了。。。我老在35楼对此楼做了准确的预言。。。

g*g2015-11-29 08:11

238 楼

我老没有要识别黄牛的身份，我老只不过让他们只能跟人民群众一样只能下一个单而已
。现在黄牛猖獗的很大原因是大量订单无响应。大家都拼命刷，黄牛就占了便宜。
你不服也不行。反正我老去厕所人多了排队，不像你到门口挤。

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

: 好虫，你不会那么弱智到居然还认为身份证是能够识别好虫你身份的ID吧？

m*s2015-11-29 08:11

239 楼

黄牛怎么搞到的票跟你想的差远了。
回到厕所这个话题，你正着急拉屎撒尿，你赶紧去了离你最近的厕所排队，你排了15分
钟终于排到你了，厕所管理员面对面告诉你：好虫，很抱歉，厕所没位置了，要不您去
别的厕所再去排队看是不是还有空位。

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

: 我老没有要识别黄牛的身份，我老只不过让他们只能跟人民群众一样只能下一个单而已
: 。现在黄牛猖獗的很大原因是大量订单无响应。大家都拼命刷，黄牛就占了便宜。
: 你不服也不行。反正我老去厕所人多了排队，不像你到门口挤。

g*g2015-11-29 08:11

240 楼

你错了，我排队就是直接去拿了个号。然后我就知道了厕所大约15分钟后关门，厕所关
门之前我能上厕所的概率有多大，我觉得没戏我就走了。
你呢，在厕所门口使劲挤，挤得鼻青脸肿，挤了15分钟，发现厕所也关门了。

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

: 黄牛怎么搞到的票跟你想的差远了。
: 回到厕所这个话题，你正着急拉屎撒尿，你赶紧去了离你最近的厕所排队，你排了15分
: 钟终于排到你了，厕所管理员面对面告诉你：好虫，很抱歉，厕所没位置了，要不您去
: 别的厕所再去排队看是不是还有空位。

b*s2015-11-29 08:11

241 楼

"我老只不过让他们只能跟人民群众一样只能下一个单而已"
don't think you can make this

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

g*g2015-11-29 08:11

242 楼

我能让每个用户每天最多下一个单，每个用户绑定了一个身份证号和手机号，每个IP在
一定时间内只能下有限的单子。至于黄牛能拿到多少身份证和多少手机就不是我能控制
得了。

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

: "我老只不过让他们只能跟人民群众一样只能下一个单而已"
: don't think you can make this

m*s2015-11-29 08:11

243 楼

我没要挤啊。我从没说过挤啊。
我前面叙述得很清楚，你好虫排队，好虫看到排队上厕所队伍的长度和速度是在你好虫
能忍住屎尿的时间范围内，就排着直到排到你后你进入厕所解决问题。好虫你一看这个
厕所的排队队伍太长或者前进速度太慢就会马上换去另外一个稍远的厕所看看那个厕所
外面的队伍是不是短些或速度快些，如果还不行就马上去第三个，以此类推。
你那个排队拿号，然后等15分钟之后再得到通知说你待会能入厕的概率多大，你着急拉
屎撒尿，你有多少个15分钟可以让你等？

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

: 你错了，我排队就是直接去拿了个号。然后我就知道了厕所大约15分钟后关门，厕所关
: 门之前我能上厕所的概率有多大，我觉得没戏我就走了。
: 你呢，在厕所门口使劲挤，挤得鼻青脸肿，挤了15分钟，发现厕所也关门了。

g*g2015-11-29 08:11

244 楼

你实在是脑子太差。我说最后一遍。通过历史数据，我可以知道交易成功率，排在我前
面的人数，余票数目。我能买到票的概率是下单的时候就知道的，不需要等15分钟。举
个简单例子，如果只剩1张票，前面有三个人，交易成功率90%，三个人都没买成的概率
是0.1%，我老人家是不会等下去的。15分钟是所有票都卖掉，确定没票的时间，不是出
概率需要那么久。
刷票就是挤，刷出来了就是挤进去。刷不出来就是做了分母，厕所没关门之前就有挤进
去的可能。你不承认是没用的。我老人家是不会憋着尿去跟人挤的，你貌似乐此不彼。

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

: 我没要挤啊。我从没说过挤啊。
: 我前面叙述得很清楚，你好虫排队，好虫看到排队上厕所队伍的长度和速度是在你好虫
: 能忍住屎尿的时间范围内，就排着直到排到你后你进入厕所解决问题。好虫你一看这个
: 厕所的排队队伍太长或者前进速度太慢就会马上换去另外一个稍远的厕所看看那个厕所
: 外面的队伍是不是短些或速度快些，如果还不行就马上去第三个，以此类推。
: 你那个排队拿号，然后等15分钟之后再得到通知说你待会能入厕的概率多大，你着急拉
: 屎撒尿，你有多少个15分钟可以让你等？

m*s2015-11-29 08:11

245 楼

大部分人的选择不是唯一的。但有顺序高低。
他们需要的是尽早知道第一选择是否有票，
否则就试第二选择，
否则就试第三选择......

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

: 你实在是脑子太差。我说最后一遍。通过历史数据，我可以知道交易成功率，排在我前
: 面的人数，余票数目。我能买到票的概率是下单的时候就知道的，不需要等15分钟。举
: 个简单例子，如果只剩1张票，前面有三个人，交易成功率90%，三个人都没买成的概率
: 是0.1%，我老人家是不会等下去的。15分钟是所有票都卖掉，确定没票的时间，不是出
: 概率需要那么久。
: 刷票就是挤，刷出来了就是挤进去。刷不出来就是做了分母，厕所没关门之前就有挤进
: 去的可能。你不承认是没用的。我老人家是不会憋着尿去跟人挤的，你貌似乐此不彼。

b*s2015-11-29 08:11

246 楼

of course it does not work. they can borrow id
and ip throttle is not effective, someone has told you

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

: 我能让每个用户每天最多下一个单，每个用户绑定了一个身份证号和手机号，每个IP在
: 一定时间内只能下有限的单子。至于黄牛能拿到多少身份证和多少手机就不是我能控制
: 得了。

g*g2015-11-29 08:11

247 楼

这就是为啥一个单子就可以把所有选择都放进去。如果全国人民排队进一个售票口，一
样是这么问的。我只不过把它自动化了而已。我甚至能在下单的时候就跟你说每个选择
的概率有多高。

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

: 大部分人的选择不是唯一的。但有顺序高低。
: 他们需要的是尽早知道第一选择是否有票，
: 否则就试第二选择，
: 否则就试第三选择......

b*s2015-11-29 08:11

248 楼

interesting. people to learn probability to get a ticket. they must have an
average IQ over 110

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

g*g2015-11-29 08:11

249 楼

黄牛成功的最大原因是订单大概率丢失。这时候自动刷就大大提高了概率，你是跟机器
在战斗。当一个系统限制每个用户每天只能下一个单子，让你网络再快软件再牛逼一个
用户还只能下一个单子。

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

: of course it does not work. they can borrow id
: and ip throttle is not effective, someone has told you

b*s2015-11-29 08:11

250 楼

all methods you use could be applied to my solution
think it over

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

: 黄牛成功的最大原因是订单大概率丢失。这时候自动刷就大大提高了概率，你是跟机器
: 在战斗。当一个系统限制每个用户每天只能下一个单子，让你网络再快软件再牛逼一个
: 用户还只能下一个单子。

g*g2015-11-29 08:11

251 楼

Easily if people like you are excluded in the conversation.

an

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

: interesting. people to learn probability to get a ticket. they must have an
: average IQ over 110

g*g2015-11-29 08:11

252 楼

You have no solution. You can't even make 2 counters atomic. Shut up.

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

: all methods you use could be applied to my solution
: think it over

b*s2015-11-29 08:11

253 楼

no surprise, it is you

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

: Easily if people like you are excluded in the conversation.
:
: an

i*w2015-11-29 08:11

254 楼

联程不仅仅是round trip，还有stop over，后者才是难点

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

:
: 用户不是不刷，是会隔一小时再刷。所以不是脑残的人很难会想到这么妙的idea.

w*62015-11-29 08:11

255 楼

GemFire 不是数据库好吗？
[在 yiyeguhu (Dartmouse) 的大作中提到：]
：查询和存数据肯定是分开的。
：
：...........

i*w2015-11-29 08:11

256 楼

这个应该可以过滤掉不少做“高频交易”的黄牛

s*x2015-11-29 08:11

257 楼

难个屁。你能联100个？1秒一个车次，100个也不会超过两分钟。

【在 i**w 的大作中提到】

: 联程不仅仅是round trip，还有stop over，后者才是难点

y*u2015-11-29 08:11

258 楼

http://pivotal.io/big-data/datasheet/pivotal-gemfire

【在 w*******6 的大作中提到】

: GemFire 不是数据库好吗？
: [在 yiyeguhu (Dartmouse) 的大作中提到：]
: ：查询和存数据肯定是分开的。
: ：
: ：...........

z*e2015-11-29 08:11

259 楼

god
this is NOT the persistence db we r talking about
this is a memorydb which pretty much like a cache

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

: http://pivotal.io/big-data/datasheet/pivotal-gemfire

y*u2015-11-29 08:11

260 楼

memorydb就一定是当cache的命～你高兴就好！

【在 z****e 的大作中提到】

:
: god
: this is NOT the persistence db we r talking about
: this is a memorydb which pretty much like a cache

m*p2015-11-29 08:11

261 楼

看了半天，我觉得brainless和yiyeguhu的设计差不多啊，比异步queue好。

z*e2015-11-29 08:11

262 楼

你do知道有一个东西叫做legacy system吧？

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

: memorydb就一定是当cache的命～你高兴就好！

b*s2015-11-29 08:11

263 楼

这个设计其实很老了，那时魏老师出来给了一个撮合系统的设计
但是魏老师没有给周边系统的设计，我就帮他补完了一个，和这个差别不大
然后其余人进来讨论，基本没有按这个设计来的，我也就没跟
也许按左眼兄的说法，最后回到这个设计了也未可知，老帖子我也懒得翻了，谁有兴趣
可以去挖坟
魏老师做的是计数器方案，和我的设计也不一样，但总体思路差不多
魏老师还是比较厉害的
如果不考虑用户体验，当然异步queue也是可以的，设计也很简单

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

: 看了半天，我觉得brainless和yiyeguhu的设计差不多啊，比异步queue好。

z*e2015-11-29 08:11

264 楼

现在的票在数据库里面
全部读入内存？
老魏那个单机后来连udp都来了
安全彻底不管了吧？
这种系统it审计这一关直接枪毙

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

: 这个设计其实很老了，那时魏老师出来给了一个撮合系统的设计
: 但是魏老师没有给周边系统的设计，我就帮他补完了一个，和这个差别不大
: 然后其余人进来讨论，基本没有按这个设计来的，我也就没跟
: 也许按左眼兄的说法，最后回到这个设计了也未可知，老帖子我也懒得翻了，谁有兴趣
: 可以去挖坟
: 魏老师做的是计数器方案，和我的设计也不一样，但总体思路差不多
: 魏老师还是比较厉害的
: 如果不考虑用户体验，当然异步queue也是可以的，设计也很简单

z*e2015-11-29 08:11

265 楼

yiyeguhu还是先把memorydb在做什么搞明白吧
当时就说过了，老魏的那个计数器，其实redis就能做

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

: 看了半天，我觉得brainless和yiyeguhu的设计差不多啊，比异步queue好。

z*e2015-11-29 08:11

266 楼

另外就是，异步queue和memorydb其实没有啥本质区别
如果你只是想返回的话，异步的目的就是让你尽早返回
现在问题是，票的信息在db硬盘上，你什么时候返回有什么意义？
这里就有了一层io好吧？当你读票的时候，就有了争抢，锁等问题了
这里就有了一个transaction在等着你了，因为是db
难道这个都不考虑了？

g*g2015-11-29 08:11

267 楼

别设计了。连个联票支持transaction都做不了。太监计数器有蛋用。打完脸死撑就是
行就是行，qxc给机器来个实测直接尿遁。就这德行还有脸出来说。

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

b*s2015-11-29 08:11

268 楼

你和老魏聊吧，后半段我都没看你们在吵什么

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

: 别设计了。连个联票支持transaction都做不了。太监计数器有蛋用。打完脸死撑就是
: 行就是行，qxc给机器来个实测直接尿遁。就这德行还有脸出来说。

b*s2015-11-29 08:11

269 楼

你异步返回的是入队列状态，我这个返回的是有没有抢到

【在 z****e 的大作中提到】

: 另外就是，异步queue和memorydb其实没有啥本质区别
: 如果你只是想返回的话，异步的目的就是让你尽早返回
: 现在问题是，票的信息在db硬盘上，你什么时候返回有什么意义？
: 这里就有了一层io好吧？当你读票的时候，就有了争抢，锁等问题了
: 这里就有了一个transaction在等着你了，因为是db
: 难道这个都不考虑了？

z*e2015-11-29 08:11

270 楼

12306当时问过ibm的意见，ibm给了一个报价，铁道部吓坏了
决定自己摸索，这个档次的项目，也就是ibm能做了
几个大型的项目基本上都是ibm在做
amadeus之类的，其实cloud用在这里不太合适
这种级别的项目，不用省硬件那点钱，国家有的是钱造数据中心
包括nosql什么其实也都不合适，容易出错
memorydb做点cache还勉强

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

: 别设计了。连个联票支持transaction都做不了。太监计数器有蛋用。打完脸死撑就是
: 行就是行，qxc给机器来个实测直接尿遁。就这德行还有脸出来说。

z*e2015-11-29 08:11

271 楼

你先需要把票的数据读入内存
否则抢什么？内存里空无一物

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

: 你异步返回的是入队列状态，我这个返回的是有没有抢到

g*g2015-11-29 08:11

272 楼

别去，就太监那个计数器。我质疑不支持transaction，然后出去看了个电影。前后也
就4个小时，居然盖了个200层的大楼，几十位牛鬼蛇神一起出来嘲笑我基础不行。结果
我不得不又举了个最简单的例子，把所有外行通通打脸，做鸟兽散。你就在内。
两个独立atomic 的计数器并不能保证一起atomic，就这么简单一个常识，就把一群人
都暴
露了。

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

: 你和老魏聊吧，后半段我都没看你们在吵什么

z*e2015-11-29 08:11

273 楼

顺便说一下，国内就是即时交易的股票平台
比如a股之类的，也是异步处理，集合竞价听说过吧？
看看是不是古德霸说的那种方式，也没见谁砸柜台
买不到就买不到呗

b*s2015-11-29 08:11

274 楼

你去找找吧，找到我就认，不再和你争了，行不？

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

: 别去，就太监那个计数器。我质疑不支持transaction，然后出去看了个电影。前后也
: 就4个小时，居然盖了个200层的大楼，几十位牛鬼蛇神一起出来嘲笑我基础不行。结果
: 我不得不又举了个最简单的例子，把所有外行通通打脸，做鸟兽散。你就在内。
: 两个独立atomic 的计数器并不能保证一起atomic，就这么简单一个常识，就把一群人
: 都暴
: 露了。

b*s2015-11-29 08:11

275 楼

赵老师，您在说啥呀

【在 z****e 的大作中提到】

: 顺便说一下，国内就是即时交易的股票平台
: 比如a股之类的，也是异步处理，集合竞价听说过吧？
: 看看是不是古德霸说的那种方式，也没见谁砸柜台
: 买不到就买不到呗

g*g2015-11-29 08:11

276 楼

我老人家没那个功夫，反正太监那个计数器连transaction都不行，支持他的都一起打
脸。他自己知道丢人躲了一年。

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

: 你去找找吧，找到我就认，不再和你争了，行不？

z*e2015-11-29 08:11

277 楼

就是我说的意思啊，你别把我问的跟古德霸说的混起来
我问的是，现在的票存在db上，你该如何读入内存？
因为如果你按照老魏那种计数器的方式的话
你需要把票的信息在系统启动的时候全部读入内存
否则怎么处理？数据不在内存里面就在硬盘（db）上
你总要有个地方吧？如果是在硬盘（db）上的话
那就是txn啊

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

: 赵老师，您在说啥呀

b*s2015-11-29 08:11

278 楼

我那个设计不是计数器啊，大哥，你找找去吧

【在 z****e 的大作中提到】

:
: 就是我说的意思啊，你别把我问的跟古德霸说的混起来
: 我问的是，现在的票存在db上，你该如何读入内存？
: 因为如果你按照老魏那种计数器的方式的话
: 你需要把票的信息在系统启动的时候全部读入内存
: 否则怎么处理？数据不在内存里面就在硬盘（db）上
: 你总要有个地方吧？如果是在硬盘（db）上的话
: 那就是txn啊

z*e2015-11-29 08:11

279 楼

不找了，先睡了
说的人太多，容易混

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

: 我那个设计不是计数器啊，大哥，你找找去吧

b*s2015-11-29 08:11

280 楼

我那方案不是计数器，你们拿着老魏的来打我的，赢了有意思吗

【在 z****e 的大作中提到】

:
: 不找了，先睡了
: 说的人太多，容易混

z*e2015-11-29 08:11

281 楼

你自己老说老魏的计数器，那谁分得清楚
那么高楼，没力气爬了
这个你跟古德霸好好讨论讨论，我先睡了

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

: 我那方案不是计数器，你们拿着老魏的来打我的，赢了有意思吗