h*9
2 楼
谢谢
s*8
3 楼
2006年底来美,今年应该算是RESIDENT了.现在用CPT工作.
问题如下:
1,请问第六项Additional amount, if any, you want withheld from each paycheck,后
面要填一个金额,请问这个是如何算的,还是自己按照工资的15%预估一个呢?
2,CPT用交SOCIAL SECURITY TAX和 MEDICARE TAX吗?
如果是OPT的话,用交吗?
谢谢回复
问题如下:
1,请问第六项Additional amount, if any, you want withheld from each paycheck,后
面要填一个金额,请问这个是如何算的,还是自己按照工资的15%预估一个呢?
2,CPT用交SOCIAL SECURITY TAX和 MEDICARE TAX吗?
如果是OPT的话,用交吗?
谢谢回复
n*e
4 楼
【 以下文字转载自 Detective 讨论区 】
发信人: nile (nile), 信区: Detective
标 题: 杀人分尸与活人喂狼
发信站: BBS 未名空间站 (Sun Oct 28 00:49:35 2018, 美东)
杀人分尸，把活人送去让狼吃掉。这些人类社会令人发指的罪行。现在却在以国家的名
义公然上演。
沙特记者卡舒吉在土耳其沙特领事馆被流氓特工杀死分尸，无非就是因为他对沙特政府
激烈的批评态度。卡舒吉是勇敢的，他明知沙特政府对他已经恨之入骨，还敢孤身闯入
沙特领土。而手握国家重器的沙特政府是胆小鬼。他们不敢听到反对的声音，甚至不敢
在别人的领土上扼杀反对者的声音。而是用飞机把十五名屠夫悄悄运进土耳其国土上自
己的领地。
他们不仅懦弱而且愚蠢。他们以为杀了卡舒吉就可以堵住反对者的声音，以为在自己的
领事馆动手，就不会被抓住屠杀的证据。这些愚蠢的懦夫现在该后悔了。报应来的是如
此迅速，根本不需要等他们下地狱的日子。
像自以为强大的沙特屠夫们一样，还有瑞典法西斯警察。这些法西斯就因为看见一个戴
着斗笠的人在他们的历史建筑物外面拉屎就认定这是中国人干的。从此决定把捣乱的中
国游客送到森林里去喂狼。可惜这些当年就对德国法西斯怕的要死的瑞典警察现在又怕
人死在他们自己的警车上罪行败露。只好半途而返终止行动。那些等着看活人被狼吃掉
的法西斯走狗们失望了，他们一直满心期盼着分一块狼吃剩的人骨头。
这些人真正的愚蠢不在于他们不小心泄露了邪恶的秘密。而是不懂得老子所云反者道之
动的道理。被分尸的卡舒吉有福了。肉身的毁灭，只会使真理的声音更加清越。而死亡
不过是脱去灵魂的一件已经穿旧的外衣。这件破碎流血的外衣却腐烂发臭，为屠夫们的
灵魂打上罪恶的印记，生生世世无法洗脱。
发信人: nile (nile), 信区: Detective
标 题: 杀人分尸与活人喂狼
发信站: BBS 未名空间站 (Sun Oct 28 00:49:35 2018, 美东)
杀人分尸，把活人送去让狼吃掉。这些人类社会令人发指的罪行。现在却在以国家的名
义公然上演。
沙特记者卡舒吉在土耳其沙特领事馆被流氓特工杀死分尸，无非就是因为他对沙特政府
激烈的批评态度。卡舒吉是勇敢的，他明知沙特政府对他已经恨之入骨，还敢孤身闯入
沙特领土。而手握国家重器的沙特政府是胆小鬼。他们不敢听到反对的声音，甚至不敢
在别人的领土上扼杀反对者的声音。而是用飞机把十五名屠夫悄悄运进土耳其国土上自
己的领地。
他们不仅懦弱而且愚蠢。他们以为杀了卡舒吉就可以堵住反对者的声音，以为在自己的
领事馆动手，就不会被抓住屠杀的证据。这些愚蠢的懦夫现在该后悔了。报应来的是如
此迅速，根本不需要等他们下地狱的日子。
像自以为强大的沙特屠夫们一样，还有瑞典法西斯警察。这些法西斯就因为看见一个戴
着斗笠的人在他们的历史建筑物外面拉屎就认定这是中国人干的。从此决定把捣乱的中
国游客送到森林里去喂狼。可惜这些当年就对德国法西斯怕的要死的瑞典警察现在又怕
人死在他们自己的警车上罪行败露。只好半途而返终止行动。那些等着看活人被狼吃掉
的法西斯走狗们失望了，他们一直满心期盼着分一块狼吃剩的人骨头。
这些人真正的愚蠢不在于他们不小心泄露了邪恶的秘密。而是不懂得老子所云反者道之
动的道理。被分尸的卡舒吉有福了。肉身的毁灭，只会使真理的声音更加清越。而死亡
不过是脱去灵魂的一件已经穿旧的外衣。这件破碎流血的外衣却腐烂发臭，为屠夫们的
灵魂打上罪恶的印记，生生世世无法洗脱。
b*y
5 楼
【 以下文字转载自 Stock 讨论区 】
发信人: badcompany (哥玩的不是股票，是心跳！), 信区: Stock
标 题: IPad 第一印象
发信站: BBS 未名空间站 (Sat Apr 3 18:03:33 2010, 美东)
还挺沉，挺大挺厚实的一玩意儿
速度很快。
华尔街日报一周要3.99,靠，简直是抢钱！我还花钱订了他的iphone application呢。
不理他了。
纽约日报界面很精美，不过要全看好像也要付钱。另外有免费的us today, ap news可
以下载，都不错。
ibookstore 还没啥书，界面不错。
kindle是最大的惊喜，用它看书比原来的kindle机器感觉舒服多了，简直是windows和
dos的区别，这个功能能让我满意，买ipad的主要目的就达到了。
pdf功能也很好，买了一个 pdfreader hd, 屏幕足够大可以看扫描的中文书。
电池确实很耐用。
总之感觉不错，可以打个85分。最需要改进的还是应该做得更轻薄些。
发信人: badcompany (哥玩的不是股票，是心跳！), 信区: Stock
标 题: IPad 第一印象
发信站: BBS 未名空间站 (Sat Apr 3 18:03:33 2010, 美东)
还挺沉，挺大挺厚实的一玩意儿
速度很快。
华尔街日报一周要3.99,靠，简直是抢钱！我还花钱订了他的iphone application呢。
不理他了。
纽约日报界面很精美，不过要全看好像也要付钱。另外有免费的us today, ap news可
以下载，都不错。
ibookstore 还没啥书，界面不错。
kindle是最大的惊喜，用它看书比原来的kindle机器感觉舒服多了，简直是windows和
dos的区别，这个功能能让我满意，买ipad的主要目的就达到了。
pdf功能也很好，买了一个 pdfreader hd, 屏幕足够大可以看扫描的中文书。
电池确实很耐用。
总之感觉不错，可以打个85分。最需要改进的还是应该做得更轻薄些。
T*i
6 楼
你忽略的是什么？
你根本没搞清楚春运系统的难点：
1. 全国一盘棋。任意两点任意方向都有需求
2. 读写要同时优化，写数据可能只有那么几亿条。读请求会多几十上百倍。很多人一
直刷屏。
3. 瞬时负载。要做好在几十分钟内每秒几十万上百万请求的准备。
4. 动态规划，要兼顾用户优化和全局优化。比如某路段最抢手，但是还要考虑经过这
个路段的其他长途旅客。
你的那个数据库怎么应付瞬时激增的请求？
我的设计，就是我的核心取代你的数据库和cache，以及transaction manager。
主要针对上述1，2，3点。因为第四点能够分布。
我的核心输入很简单：
1. 查询:
输入： Route List + Constraint filter (时间段， 座位等级 etc)
输出： 没票：
或者有票： 每节点班次和剩余座位数
2. 订票：
输入： 上次查询结果
输出： 是否成功？（其他人可能抢先）
3. 退票： 或者几分钟后银行确认失败取消
输入： 班次座位列表
输出： 永远成功
就是这个server，这个是核心，我的方案比你的处理能力高两个数量级。
这个是Hard Realtime System，系统内部，每个请求的处理时间都guarantee是微秒级
别的。
剩下的，都是外围。用户账号管理。用户界面。支付系统。都可以是现成的。也容易分
布处理。
但是这个核心。我能够证明是最优的。而且是实现最简单的。
再说一遍，我的核心取代你的数据库和cache，以及transaction manager。
下面是你的原文。
---------------------------------------------------------------------
架构本身倒没什么难得。读写分离，数据库要有cluster，readonly node。读有cache
，所有的数据库读都是cache发起的。用户读只hit cache。
接下来按线路分表，再按发车日期分表。每线路每天不过几千张票而已。用户本身可以
无限
分表，不是问题。如果这个还不够，终极杀器就是离线订单。所有发来的请求以(线路&
日期)发到不同的queue上以commit log的性质写，这个没有锁，极快。然后处理这个
queue就完了。一个好的数据库服务器处理每秒1万的transaction不是问题。一整个
queue一秒钟就处理完了，票卖完了后面直接通知买不到。
这个架构底下，所有线路所有天的票一秒钟就处理了，所以可以往回放，比如不用分日
期，不用分
线路等等。当
然事实上是没这么理想的，还要等外部支付系统确认交易成功等等，但撑住是没问题的
。
你根本没搞清楚春运系统的难点：
1. 全国一盘棋。任意两点任意方向都有需求
2. 读写要同时优化，写数据可能只有那么几亿条。读请求会多几十上百倍。很多人一
直刷屏。
3. 瞬时负载。要做好在几十分钟内每秒几十万上百万请求的准备。
4. 动态规划，要兼顾用户优化和全局优化。比如某路段最抢手，但是还要考虑经过这
个路段的其他长途旅客。
你的那个数据库怎么应付瞬时激增的请求？
我的设计，就是我的核心取代你的数据库和cache，以及transaction manager。
主要针对上述1，2，3点。因为第四点能够分布。
我的核心输入很简单：
1. 查询:
输入： Route List + Constraint filter (时间段， 座位等级 etc)
输出： 没票：
或者有票： 每节点班次和剩余座位数
2. 订票：
输入： 上次查询结果
输出： 是否成功？（其他人可能抢先）
3. 退票： 或者几分钟后银行确认失败取消
输入： 班次座位列表
输出： 永远成功
就是这个server，这个是核心，我的方案比你的处理能力高两个数量级。
这个是Hard Realtime System，系统内部，每个请求的处理时间都guarantee是微秒级
别的。
剩下的，都是外围。用户账号管理。用户界面。支付系统。都可以是现成的。也容易分
布处理。
但是这个核心。我能够证明是最优的。而且是实现最简单的。
再说一遍，我的核心取代你的数据库和cache，以及transaction manager。
下面是你的原文。
---------------------------------------------------------------------
架构本身倒没什么难得。读写分离，数据库要有cluster，readonly node。读有cache
，所有的数据库读都是cache发起的。用户读只hit cache。
接下来按线路分表，再按发车日期分表。每线路每天不过几千张票而已。用户本身可以
无限
分表，不是问题。如果这个还不够，终极杀器就是离线订单。所有发来的请求以(线路&
日期)发到不同的queue上以commit log的性质写，这个没有锁，极快。然后处理这个
queue就完了。一个好的数据库服务器处理每秒1万的transaction不是问题。一整个
queue一秒钟就处理完了，票卖完了后面直接通知买不到。
这个架构底下，所有线路所有天的票一秒钟就处理了，所以可以往回放，比如不用分日
期，不用分
线路等等。当
然事实上是没这么理想的，还要等外部支付系统确认交易成功等等，但撑住是没问题的
。
s*u
7 楼
OK
S*I
8 楼
1. Whatever amount you think is appropriate
2. yes & yes
paycheck,后
【在 s*******8 的大作中提到】
: 2006年底来美,今年应该算是RESIDENT了.现在用CPT工作.
: 问题如下:
: 1,请问第六项Additional amount, if any, you want withheld from each paycheck,后
: 面要填一个金额,请问这个是如何算的,还是自己按照工资的15%预估一个呢?
: 2,CPT用交SOCIAL SECURITY TAX和 MEDICARE TAX吗?
: 如果是OPT的话,用交吗?
: 谢谢回复
2. yes & yes
paycheck,后
【在 s*******8 的大作中提到】
: 2006年底来美,今年应该算是RESIDENT了.现在用CPT工作.
: 问题如下:
: 1,请问第六项Additional amount, if any, you want withheld from each paycheck,后
: 面要填一个金额,请问这个是如何算的,还是自己按照工资的15%预估一个呢?
: 2,CPT用交SOCIAL SECURITY TAX和 MEDICARE TAX吗?
: 如果是OPT的话,用交吗?
: 谢谢回复
d*m
9 楼
这么惊悚的标题，需不需要啊
s*8
10 楼
看样子我应该买一个。
P*l
11 楼
魏老师可能没搞过这种数据库．
１．火车票不是股票，没必要实时到毫秒级．非订单查询结果是五分钟之前的就足够了．
２．理想情况下全世界都是一盘棋．请问你的服务器（世界级的）放在哪个城市？刮风
不？下雨不？
３．全国人民不都住在那个服务器的隔壁．服务器的吞吐量是20G．这20G是如何到达用
户终端的？
４．订票．这种情况下服务器怎么可能是stateful的？负载这么大，client随时都有断
掉的可能．你准备为多少用户保存状态多久？
【在 T********i 的大作中提到】
: 你忽略的是什么？
: 你根本没搞清楚春运系统的难点：
: 1. 全国一盘棋。任意两点任意方向都有需求
: 2. 读写要同时优化，写数据可能只有那么几亿条。读请求会多几十上百倍。很多人一
: 直刷屏。
: 3. 瞬时负载。要做好在几十分钟内每秒几十万上百万请求的准备。
: 4. 动态规划，要兼顾用户优化和全局优化。比如某路段最抢手，但是还要考虑经过这
: 个路段的其他长途旅客。
: 你的那个数据库怎么应付瞬时激增的请求？
: 我的设计，就是我的核心取代你的数据库和cache，以及transaction manager。
１．火车票不是股票，没必要实时到毫秒级．非订单查询结果是五分钟之前的就足够了．
２．理想情况下全世界都是一盘棋．请问你的服务器（世界级的）放在哪个城市？刮风
不？下雨不？
３．全国人民不都住在那个服务器的隔壁．服务器的吞吐量是20G．这20G是如何到达用
户终端的？
４．订票．这种情况下服务器怎么可能是stateful的？负载这么大，client随时都有断
掉的可能．你准备为多少用户保存状态多久？
【在 T********i 的大作中提到】
: 你忽略的是什么？
: 你根本没搞清楚春运系统的难点：
: 1. 全国一盘棋。任意两点任意方向都有需求
: 2. 读写要同时优化，写数据可能只有那么几亿条。读请求会多几十上百倍。很多人一
: 直刷屏。
: 3. 瞬时负载。要做好在几十分钟内每秒几十万上百万请求的准备。
: 4. 动态规划，要兼顾用户优化和全局优化。比如某路段最抢手，但是还要考虑经过这
: 个路段的其他长途旅客。
: 你的那个数据库怎么应付瞬时激增的请求？
: 我的设计，就是我的核心取代你的数据库和cache，以及transaction manager。
n*j
12 楼
什么offer letter？老板的support letter行不？
【在 s**u 的大作中提到】
: OK
【在 s**u 的大作中提到】
: OK
z*l
13 楼
paycheck,后
only if you want to IRS to withhold more
yes, yes
【在 s*******8 的大作中提到】
: 2006年底来美,今年应该算是RESIDENT了.现在用CPT工作.
: 问题如下:
: 1,请问第六项Additional amount, if any, you want withheld from each paycheck,后
: 面要填一个金额,请问这个是如何算的,还是自己按照工资的15%预估一个呢?
: 2,CPT用交SOCIAL SECURITY TAX和 MEDICARE TAX吗?
: 如果是OPT的话,用交吗?
: 谢谢回复
d*m
14 楼
来个轻松点的话题思考下呗
d*d
15 楼
长时间看书的话e-ink应该还是更舒服吧
【在 b********y 的大作中提到】
: 【 以下文字转载自 Stock 讨论区 】
: 发信人: badcompany (哥玩的不是股票，是心跳！), 信区: Stock
: 标 题: IPad 第一印象
: 发信站: BBS 未名空间站 (Sat Apr 3 18:03:33 2010, 美东)
: 还挺沉，挺大挺厚实的一玩意儿
: 速度很快。
: 华尔街日报一周要3.99,靠，简直是抢钱！我还花钱订了他的iphone application呢。
: 不理他了。
: 纽约日报界面很精美，不过要全看好像也要付钱。另外有免费的us today, ap news可
: 以下载，都不错。
【在 b********y 的大作中提到】
: 【 以下文字转载自 Stock 讨论区 】
: 发信人: badcompany (哥玩的不是股票，是心跳！), 信区: Stock
: 标 题: IPad 第一印象
: 发信站: BBS 未名空间站 (Sat Apr 3 18:03:33 2010, 美东)
: 还挺沉，挺大挺厚实的一玩意儿
: 速度很快。
: 华尔街日报一周要3.99,靠，简直是抢钱！我还花钱订了他的iphone application呢。
: 不理他了。
: 纽约日报界面很精美，不过要全看好像也要付钱。另外有免费的us today, ap news可
: 以下载，都不错。
P*l
16 楼
＾＾＾
指你说的那个核心
指你说的那个核心
h*9
17 楼
提供了offer letter 有效期还有半年的复印件，还需要提供老板的support letter 吗
？
？
d*m
18 楼
比如活人分尸与杀人喂狼如何？
b*y
19 楼
呵呵，我是长时间看过kindle的，我可以很坦率地说，e-ink很不舒服
e-ink的底色是灰的，看久了眼睛很累
另外一个缺陷是翻页太慢。
【在 d****d 的大作中提到】
: 长时间看书的话e-ink应该还是更舒服吧
e-ink的底色是灰的，看久了眼睛很累
另外一个缺陷是翻页太慢。
【在 d****d 的大作中提到】
: 长时间看书的话e-ink应该还是更舒服吧
T*i
20 楼
了．
五分钟之前不够，因为随时有人买票退票。而且数据依赖性非常严重。
如果没有直达的就要找最好的reroute。这些必须实时处理。
determinism很重要。一旦你不能保持确定性，永远都不能保持确定性。
和这样类似的系统都是一样的架构。也不是我发明的。你问问任何正交所match engine
是不是集中在一个地方？
选一个中心是必然的。
local front server都是分布的。可以通过DNS partition来分布负载。这些都可以是
stateless。注意分布的前端服务器和中心是专线。
你的2和3都是commodity，堆机器就能实现。有点钱就能买到。
其他的都可以是stateless。就是票源管理是我的一台服务器解决瓶颈。
【在 P********l 的大作中提到】
: 魏老师可能没搞过这种数据库．
: １．火车票不是股票，没必要实时到毫秒级．非订单查询结果是五分钟之前的就足够了．
: ２．理想情况下全世界都是一盘棋．请问你的服务器（世界级的）放在哪个城市？刮风
: 不？下雨不？
: ３．全国人民不都住在那个服务器的隔壁．服务器的吞吐量是20G．这20G是如何到达用
: 户终端的？
: ４．订票．这种情况下服务器怎么可能是stateful的？负载这么大，client随时都有断
: 掉的可能．你准备为多少用户保存状态多久？
s*u
21 楼
Need.
【在 h**********9 的大作中提到】
: 提供了offer letter 有效期还有半年的复印件，还需要提供老板的support letter 吗
: ？
【在 h**********9 的大作中提到】
: 提供了offer letter 有效期还有半年的复印件，还需要提供老板的support letter 吗
: ？
a*y
22 楼
NPR app is very good try that.
T*i
23 楼
我的核心只管票，不管用户。订票退票查询都是分布式外围服务器送来的。
一个64位transaction ID足够了。
【在 P********l 的大作中提到】
: ＾＾＾
: 指你说的那个核心
一个64位transaction ID足够了。
【在 P********l 的大作中提到】
: ＾＾＾
: 指你说的那个核心
w*s
24 楼
kindle on ipad is good.
ipad ibook has too few books..
ipad ibook has too few books..
P*l
25 楼
８／２２／２０１３：
Nasdaq market paralyzed by three hour shutdown
http://www.reuters.com/article/2013/08/22/us-nasdaq-halt-tapec-
(Reuters) - Trading in thousands of U.S. stocks ground to a halt for much of
Thursday after an unexplained technological problem shut down trading in
Nasdaq securities, the latest prominent disruption to the operations of U.S.
markets.
Nasdaq market paralyzed by three hour shutdown
http://www.reuters.com/article/2013/08/22/us-nasdaq-halt-tapec-
(Reuters) - Trading in thousands of U.S. stocks ground to a halt for much of
Thursday after an unexplained technological problem shut down trading in
Nasdaq securities, the latest prominent disruption to the operations of U.S.
markets.
r*y
26 楼
pdfreader hd怎样把书传到ipad？最大能打开多大的pdf？比如几百M的如何？
翻页和渲染速度如何？
【在 b********y 的大作中提到】
: 【 以下文字转载自 Stock 讨论区 】
: 发信人: badcompany (哥玩的不是股票，是心跳！), 信区: Stock
: 标 题: IPad 第一印象
: 发信站: BBS 未名空间站 (Sat Apr 3 18:03:33 2010, 美东)
: 还挺沉，挺大挺厚实的一玩意儿
: 速度很快。
: 华尔街日报一周要3.99,靠，简直是抢钱！我还花钱订了他的iphone application呢。
: 不理他了。
: 纽约日报界面很精美，不过要全看好像也要付钱。另外有免费的us today, ap news可
: 以下载，都不错。
翻页和渲染速度如何？
【在 b********y 的大作中提到】
: 【 以下文字转载自 Stock 讨论区 】
: 发信人: badcompany (哥玩的不是股票，是心跳！), 信区: Stock
: 标 题: IPad 第一印象
: 发信站: BBS 未名空间站 (Sat Apr 3 18:03:33 2010, 美东)
: 还挺沉，挺大挺厚实的一玩意儿
: 速度很快。
: 华尔街日报一周要3.99,靠，简直是抢钱！我还花钱订了他的iphone application呢。
: 不理他了。
: 纽约日报界面很精美，不过要全看好像也要付钱。另外有免费的us today, ap news可
: 以下载，都不错。
T*i
27 楼
他们做的谈不上完美。但是绝对不是你想象的那么糟糕。
人家的系统运行了这么多年，经历了flash crash的大流量的挑战。
我一个单子送到NASDAQ，一般大约50微秒后ACK就到了。
注意是50微秒，不是毫秒。微秒是毫秒的1/1000。这是一个round trip，包括两次
message encoding和两次message decoding，两次send和两次recv。还有match engine
记账完成。报价送到book上，同时市场数据的更新也已经发送出去了。
这种系统不是本版某些人能想象的。用他们手头的技术，绝对做不出来。
人家的系统运行了这么多年，经历了flash crash的大流量的挑战。
我一个单子送到NASDAQ，一般大约50微秒后ACK就到了。
注意是50微秒，不是毫秒。微秒是毫秒的1/1000。这是一个round trip，包括两次
message encoding和两次message decoding，两次send和两次recv。还有match engine
记账完成。报价送到book上，同时市场数据的更新也已经发送出去了。
这种系统不是本版某些人能想象的。用他们手头的技术，绝对做不出来。
b*y
28 楼
可以map network folder， 你打开这个application后可以看到一个地址，map就行了。
几百兆的没问题，翻页速度还行。
不过你用goodreader应该也差不多，便宜一点。
【在 r****y 的大作中提到】
: pdfreader hd怎样把书传到ipad？最大能打开多大的pdf？比如几百M的如何？
: 翻页和渲染速度如何？
几百兆的没问题，翻页速度还行。
不过你用goodreader应该也差不多，便宜一点。
【在 r****y 的大作中提到】
: pdfreader hd怎样把书传到ipad？最大能打开多大的pdf？比如几百M的如何？
: 翻页和渲染速度如何？
f*4
29 楼
五分钟之前的？goodbug还指望看到了就能定到呢
了．
【在 P********l 的大作中提到】
: 魏老师可能没搞过这种数据库．
: １．火车票不是股票，没必要实时到毫秒级．非订单查询结果是五分钟之前的就足够了．
: ２．理想情况下全世界都是一盘棋．请问你的服务器（世界级的）放在哪个城市？刮风
: 不？下雨不？
: ３．全国人民不都住在那个服务器的隔壁．服务器的吞吐量是20G．这20G是如何到达用
: 户终端的？
: ４．订票．这种情况下服务器怎么可能是stateful的？负载这么大，client随时都有断
: 掉的可能．你准备为多少用户保存状态多久？
了．
【在 P********l 的大作中提到】
: 魏老师可能没搞过这种数据库．
: １．火车票不是股票，没必要实时到毫秒级．非订单查询结果是五分钟之前的就足够了．
: ２．理想情况下全世界都是一盘棋．请问你的服务器（世界级的）放在哪个城市？刮风
: 不？下雨不？
: ３．全国人民不都住在那个服务器的隔壁．服务器的吞吐量是20G．这20G是如何到达用
: 户终端的？
: ４．订票．这种情况下服务器怎么可能是stateful的？负载这么大，client随时都有断
: 掉的可能．你准备为多少用户保存状态多久？
d*u
30 楼
一个例子什么也说明不了呀，上面的提问也是不着边际。好像大家都没太看懂人家在说
什么，还停留在搭网站这种低能力的思维上。魏老师有个系统在运营，而且貌似运营地
还不错，说明他的设计是可行的。
这个讨论还是不错的，我个人学到一些东西。好虫再发表些见解吧。
of
S.
【在 P********l 的大作中提到】
: ８／２２／２０１３：
: Nasdaq market paralyzed by three hour shutdown
: http://www.reuters.com/article/2013/08/22/us-nasdaq-halt-tapec-
: (Reuters) - Trading in thousands of U.S. stocks ground to a halt for much of
: Thursday after an unexplained technological problem shut down trading in
: Nasdaq securities, the latest prominent disruption to the operations of U.S.
: markets.
什么，还停留在搭网站这种低能力的思维上。魏老师有个系统在运营，而且貌似运营地
还不错，说明他的设计是可行的。
这个讨论还是不错的，我个人学到一些东西。好虫再发表些见解吧。
of
S.
【在 P********l 的大作中提到】
: ８／２２／２０１３：
: Nasdaq market paralyzed by three hour shutdown
: http://www.reuters.com/article/2013/08/22/us-nasdaq-halt-tapec-
: (Reuters) - Trading in thousands of U.S. stocks ground to a halt for much of
: Thursday after an unexplained technological problem shut down trading in
: Nasdaq securities, the latest prominent disruption to the operations of U.S.
: markets.
P*l
31 楼
distance between shanghai and beijing / speed of light
= 769.7 mi / 299792458 m/s = 4.1 ms.
And 50us * speed of light = 1.5km. That means your server is in Manhattan.
Anyway, have to get back to work.
engine
【在 T********i 的大作中提到】
: 他们做的谈不上完美。但是绝对不是你想象的那么糟糕。
: 人家的系统运行了这么多年，经历了flash crash的大流量的挑战。
: 我一个单子送到NASDAQ，一般大约50微秒后ACK就到了。
: 注意是50微秒，不是毫秒。微秒是毫秒的1/1000。这是一个round trip，包括两次
: message encoding和两次message decoding，两次send和两次recv。还有match engine
: 记账完成。报价送到book上，同时市场数据的更新也已经发送出去了。
: 这种系统不是本版某些人能想象的。用他们手头的技术，绝对做不出来。
= 769.7 mi / 299792458 m/s = 4.1 ms.
And 50us * speed of light = 1.5km. That means your server is in Manhattan.
Anyway, have to get back to work.
engine
【在 T********i 的大作中提到】
: 他们做的谈不上完美。但是绝对不是你想象的那么糟糕。
: 人家的系统运行了这么多年，经历了flash crash的大流量的挑战。
: 我一个单子送到NASDAQ，一般大约50微秒后ACK就到了。
: 注意是50微秒，不是毫秒。微秒是毫秒的1/1000。这是一个round trip，包括两次
: message encoding和两次message decoding，两次send和两次recv。还有match engine
: 记账完成。报价送到book上，同时市场数据的更新也已经发送出去了。
: 这种系统不是本版某些人能想象的。用他们手头的技术，绝对做不出来。
T*i
32 楼
你这个计算很不靠谱。
首先，光在光纤中不走直线。走的是全反射bounce along。要乘一个折射系数。
其次，我的一堆server和NASDAQ的服务器在一个building里面。地点是CARTRET NJ。你
不能假定我的系统和NASDAQ系统的处理延迟是0。
实际上我的系统的处理延迟大约5-10us。
但是和latency和throughput优势两个概念。latency高，throughput同样可以做很大。
【在 P********l 的大作中提到】
: distance between shanghai and beijing / speed of light
: = 769.7 mi / 299792458 m/s = 4.1 ms.
: And 50us * speed of light = 1.5km. That means your server is in Manhattan.
: Anyway, have to get back to work.
:
: engine
首先，光在光纤中不走直线。走的是全反射bounce along。要乘一个折射系数。
其次，我的一堆server和NASDAQ的服务器在一个building里面。地点是CARTRET NJ。你
不能假定我的系统和NASDAQ系统的处理延迟是0。
实际上我的系统的处理延迟大约5-10us。
但是和latency和throughput优势两个概念。latency高，throughput同样可以做很大。
【在 P********l 的大作中提到】
: distance between shanghai and beijing / speed of light
: = 769.7 mi / 299792458 m/s = 4.1 ms.
: And 50us * speed of light = 1.5km. That means your server is in Manhattan.
: Anyway, have to get back to work.
:
: engine
P*l
33 楼
goodbug?
f*4
34 楼
不是没看懂，而是不愿意看人家怎么说的吧？
其实对这样不同行业的讨论讨论，比起讨论语言有意义多了。
用硬实时的multicast log的ack来检测硬件错误，这个之前没用过。
【在 d********u 的大作中提到】
: 一个例子什么也说明不了呀，上面的提问也是不着边际。好像大家都没太看懂人家在说
: 什么，还停留在搭网站这种低能力的思维上。魏老师有个系统在运营，而且貌似运营地
: 还不错，说明他的设计是可行的。
: 这个讨论还是不错的，我个人学到一些东西。好虫再发表些见解吧。
:
: of
: S.
其实对这样不同行业的讨论讨论，比起讨论语言有意义多了。
用硬实时的multicast log的ack来检测硬件错误，这个之前没用过。
【在 d********u 的大作中提到】
: 一个例子什么也说明不了呀，上面的提问也是不着边际。好像大家都没太看懂人家在说
: 什么，还停留在搭网站这种低能力的思维上。魏老师有个系统在运营，而且貌似运营地
: 还不错，说明他的设计是可行的。
: 这个讨论还是不错的，我个人学到一些东西。好虫再发表些见解吧。
:
: of
: S.
f*4
35 楼
从网上购物的角度讲，你的这个设计就是决定：下单的时候，能不能把东西放到
shopping cart里面。车票放到购物车之后，同一张票就不能再给别人放购物车了。
网页上显示有票不代表你能放到购物车里面。checkout这个过程才是和银行，出票相关
的。只要在给定时间之内不能checkout成功，票就回滚回去了。
就算票回滚回去了，从这张票进入购物车到出购物车的时间段，这张票是不能再卖给别
人的。
因为你的主机是高throughput的，所以所有抢票的动作都在这上面实现。不会出现分布
式的数据同步问题，也就不会出现一票多卖的现象。
放到购物车和checkout分开之后，checkout这块就可以用分布式的，堆机器实现。当然
了，整个网站的访问，还是需要堆机器来支持的。
【在 T********i 的大作中提到】
: 你忽略的是什么？
: 你根本没搞清楚春运系统的难点：
: 1. 全国一盘棋。任意两点任意方向都有需求
: 2. 读写要同时优化，写数据可能只有那么几亿条。读请求会多几十上百倍。很多人一
: 直刷屏。
: 3. 瞬时负载。要做好在几十分钟内每秒几十万上百万请求的准备。
: 4. 动态规划，要兼顾用户优化和全局优化。比如某路段最抢手，但是还要考虑经过这
: 个路段的其他长途旅客。
: 你的那个数据库怎么应付瞬时激增的请求？
: 我的设计，就是我的核心取代你的数据库和cache，以及transaction manager。
shopping cart里面。车票放到购物车之后，同一张票就不能再给别人放购物车了。
网页上显示有票不代表你能放到购物车里面。checkout这个过程才是和银行，出票相关
的。只要在给定时间之内不能checkout成功，票就回滚回去了。
就算票回滚回去了，从这张票进入购物车到出购物车的时间段，这张票是不能再卖给别
人的。
因为你的主机是高throughput的，所以所有抢票的动作都在这上面实现。不会出现分布
式的数据同步问题，也就不会出现一票多卖的现象。
放到购物车和checkout分开之后，checkout这块就可以用分布式的，堆机器实现。当然
了，整个网站的访问，还是需要堆机器来支持的。
【在 T********i 的大作中提到】
: 你忽略的是什么？
: 你根本没搞清楚春运系统的难点：
: 1. 全国一盘棋。任意两点任意方向都有需求
: 2. 读写要同时优化，写数据可能只有那么几亿条。读请求会多几十上百倍。很多人一
: 直刷屏。
: 3. 瞬时负载。要做好在几十分钟内每秒几十万上百万请求的准备。
: 4. 动态规划，要兼顾用户优化和全局优化。比如某路段最抢手，但是还要考虑经过这
: 个路段的其他长途旅客。
: 你的那个数据库怎么应付瞬时激增的请求？
: 我的设计，就是我的核心取代你的数据库和cache，以及transaction manager。
T*i
36 楼
其实是checkout的时候才请求transaction的。只剩一张票，也可以给10000个人放到购
物车里。谁先checkout是谁的。
设计思路是能分布的尽量分布。这个购物车甚至可以在browser端用javascript实现。
根本不走服务器端。
股市里的股票交易也一样。你能看到的价格不见得你能买到。你可以随便下单。
我的优势是DB做成了hard realtime的。你下一个单子，我的服务器规定时间内（比如1
-2ms）保证响应。当然了，终极约束是我的DB带宽。比如我限定在50G。带宽不够你的
单子到不了我的DB服务器。
这就是我第一帖说的，神马都是浮云，只有Gb/s的throughput才是实实在在的。
【在 f****4 的大作中提到】
: 从网上购物的角度讲，你的这个设计就是决定：下单的时候，能不能把东西放到
: shopping cart里面。车票放到购物车之后，同一张票就不能再给别人放购物车了。
: 网页上显示有票不代表你能放到购物车里面。checkout这个过程才是和银行，出票相关
: 的。只要在给定时间之内不能checkout成功，票就回滚回去了。
: 就算票回滚回去了，从这张票进入购物车到出购物车的时间段，这张票是不能再卖给别
: 人的。
: 因为你的主机是高throughput的，所以所有抢票的动作都在这上面实现。不会出现分布
: 式的数据同步问题，也就不会出现一票多卖的现象。
: 放到购物车和checkout分开之后，checkout这块就可以用分布式的，堆机器实现。当然
: 了，整个网站的访问，还是需要堆机器来支持的。
物车里。谁先checkout是谁的。
设计思路是能分布的尽量分布。这个购物车甚至可以在browser端用javascript实现。
根本不走服务器端。
股市里的股票交易也一样。你能看到的价格不见得你能买到。你可以随便下单。
我的优势是DB做成了hard realtime的。你下一个单子，我的服务器规定时间内（比如1
-2ms）保证响应。当然了，终极约束是我的DB带宽。比如我限定在50G。带宽不够你的
单子到不了我的DB服务器。
这就是我第一帖说的，神马都是浮云，只有Gb/s的throughput才是实实在在的。
【在 f****4 的大作中提到】
: 从网上购物的角度讲，你的这个设计就是决定：下单的时候，能不能把东西放到
: shopping cart里面。车票放到购物车之后，同一张票就不能再给别人放购物车了。
: 网页上显示有票不代表你能放到购物车里面。checkout这个过程才是和银行，出票相关
: 的。只要在给定时间之内不能checkout成功，票就回滚回去了。
: 就算票回滚回去了，从这张票进入购物车到出购物车的时间段，这张票是不能再卖给别
: 人的。
: 因为你的主机是高throughput的，所以所有抢票的动作都在这上面实现。不会出现分布
: 式的数据同步问题，也就不会出现一票多卖的现象。
: 放到购物车和checkout分开之后，checkout这块就可以用分布式的，堆机器实现。当然
: 了，整个网站的访问，还是需要堆机器来支持的。
N*K
37 楼
有一腚道理
如1
【在 T********i 的大作中提到】
: 其实是checkout的时候才请求transaction的。只剩一张票，也可以给10000个人放到购
: 物车里。谁先checkout是谁的。
: 设计思路是能分布的尽量分布。这个购物车甚至可以在browser端用javascript实现。
: 根本不走服务器端。
: 股市里的股票交易也一样。你能看到的价格不见得你能买到。你可以随便下单。
: 我的优势是DB做成了hard realtime的。你下一个单子，我的服务器规定时间内（比如1
: -2ms）保证响应。当然了，终极约束是我的DB带宽。比如我限定在50G。带宽不够你的
: 单子到不了我的DB服务器。
: 这就是我第一帖说的，神马都是浮云，只有Gb/s的throughput才是实实在在的。
如1
【在 T********i 的大作中提到】
: 其实是checkout的时候才请求transaction的。只剩一张票，也可以给10000个人放到购
: 物车里。谁先checkout是谁的。
: 设计思路是能分布的尽量分布。这个购物车甚至可以在browser端用javascript实现。
: 根本不走服务器端。
: 股市里的股票交易也一样。你能看到的价格不见得你能买到。你可以随便下单。
: 我的优势是DB做成了hard realtime的。你下一个单子，我的服务器规定时间内（比如1
: -2ms）保证响应。当然了，终极约束是我的DB带宽。比如我限定在50G。带宽不够你的
: 单子到不了我的DB服务器。
: 这就是我第一帖说的，神马都是浮云，只有Gb/s的throughput才是实实在在的。
f*4
38 楼
也是。我的方法反而搞复杂了。
如1
【在 T********i 的大作中提到】
: 其实是checkout的时候才请求transaction的。只剩一张票，也可以给10000个人放到购
: 物车里。谁先checkout是谁的。
: 设计思路是能分布的尽量分布。这个购物车甚至可以在browser端用javascript实现。
: 根本不走服务器端。
: 股市里的股票交易也一样。你能看到的价格不见得你能买到。你可以随便下单。
: 我的优势是DB做成了hard realtime的。你下一个单子，我的服务器规定时间内（比如1
: -2ms）保证响应。当然了，终极约束是我的DB带宽。比如我限定在50G。带宽不够你的
: 单子到不了我的DB服务器。
: 这就是我第一帖说的，神马都是浮云，只有Gb/s的throughput才是实实在在的。
如1
【在 T********i 的大作中提到】
: 其实是checkout的时候才请求transaction的。只剩一张票，也可以给10000个人放到购
: 物车里。谁先checkout是谁的。
: 设计思路是能分布的尽量分布。这个购物车甚至可以在browser端用javascript实现。
: 根本不走服务器端。
: 股市里的股票交易也一样。你能看到的价格不见得你能买到。你可以随便下单。
: 我的优势是DB做成了hard realtime的。你下一个单子，我的服务器规定时间内（比如1
: -2ms）保证响应。当然了，终极约束是我的DB带宽。比如我限定在50G。带宽不够你的
: 单子到不了我的DB服务器。
: 这就是我第一帖说的，神马都是浮云，只有Gb/s的throughput才是实实在在的。
a*e
39 楼
你这个思路应该是不错的，但是首先，你要确定 DB 已经成为了瓶颈，才需要更高吞吐
量的方案。
When you have a hammer, everything else looks like a nail.
如1
【在 T********i 的大作中提到】
: 其实是checkout的时候才请求transaction的。只剩一张票，也可以给10000个人放到购
: 物车里。谁先checkout是谁的。
: 设计思路是能分布的尽量分布。这个购物车甚至可以在browser端用javascript实现。
: 根本不走服务器端。
: 股市里的股票交易也一样。你能看到的价格不见得你能买到。你可以随便下单。
: 我的优势是DB做成了hard realtime的。你下一个单子，我的服务器规定时间内（比如1
: -2ms）保证响应。当然了，终极约束是我的DB带宽。比如我限定在50G。带宽不够你的
: 单子到不了我的DB服务器。
: 这就是我第一帖说的，神马都是浮云，只有Gb/s的throughput才是实实在在的。
量的方案。
When you have a hammer, everything else looks like a nail.
如1
【在 T********i 的大作中提到】
: 其实是checkout的时候才请求transaction的。只剩一张票，也可以给10000个人放到购
: 物车里。谁先checkout是谁的。
: 设计思路是能分布的尽量分布。这个购物车甚至可以在browser端用javascript实现。
: 根本不走服务器端。
: 股市里的股票交易也一样。你能看到的价格不见得你能买到。你可以随便下单。
: 我的优势是DB做成了hard realtime的。你下一个单子，我的服务器规定时间内（比如1
: -2ms）保证响应。当然了，终极约束是我的DB带宽。比如我限定在50G。带宽不够你的
: 单子到不了我的DB服务器。
: 这就是我第一帖说的，神马都是浮云，只有Gb/s的throughput才是实实在在的。
T*i
40 楼
我定义的这个DB是这个系统唯一的瓶颈。除了这个系统就没瓶颈了。
做方案就是要不作任何假设。你确信技术已经做到头了才能放心。如果系统再慢你知道
是运营商的事情。买带宽堆机器就好了。
做东西就是要做到这个程度才是可接受的。比如我用的Arista 10G switch，系统都有
log的，500ns延迟一个Ip包，如果一台服务器丢一个UDP包，可以到switch去查，是
switch丢的还是系统慢自己丢的。其实switch是不会丢包的。
【在 a*****e 的大作中提到】
: 你这个思路应该是不错的，但是首先，你要确定 DB 已经成为了瓶颈，才需要更高吞吐
: 量的方案。
: When you have a hammer, everything else looks like a nail.
:
: 如1
做方案就是要不作任何假设。你确信技术已经做到头了才能放心。如果系统再慢你知道
是运营商的事情。买带宽堆机器就好了。
做东西就是要做到这个程度才是可接受的。比如我用的Arista 10G switch，系统都有
log的，500ns延迟一个Ip包，如果一台服务器丢一个UDP包，可以到switch去查，是
switch丢的还是系统慢自己丢的。其实switch是不会丢包的。
【在 a*****e 的大作中提到】
: 你这个思路应该是不错的，但是首先，你要确定 DB 已经成为了瓶颈，才需要更高吞吐
: 量的方案。
: When you have a hammer, everything else looks like a nail.
:
: 如1
g*g
41 楼
早上带娃去检查身体，刚回来，慢慢回。你对这类互联网应用没有概念。
总的来说，互联网应用追求的不是stock exchange的low latency，而是high
availability和high scalability。追求完全scale out的架构，可以用commodity的硬
件线性跟随用户增长。就throughput而言，淘宝，ebay, amazon峰值要远远大于stock
exchange，单机数据库是完全挺不住的。而你的设计跟这些要求相去甚远。
【在 T********i 的大作中提到】
: 你忽略的是什么？
: 你根本没搞清楚春运系统的难点：
: 1. 全国一盘棋。任意两点任意方向都有需求
: 2. 读写要同时优化，写数据可能只有那么几亿条。读请求会多几十上百倍。很多人一
: 直刷屏。
: 3. 瞬时负载。要做好在几十分钟内每秒几十万上百万请求的准备。
: 4. 动态规划，要兼顾用户优化和全局优化。比如某路段最抢手，但是还要考虑经过这
: 个路段的其他长途旅客。
: 你的那个数据库怎么应付瞬时激增的请求？
: 我的设计，就是我的核心取代你的数据库和cache，以及transaction manager。
总的来说，互联网应用追求的不是stock exchange的low latency，而是high
availability和high scalability。追求完全scale out的架构，可以用commodity的硬
件线性跟随用户增长。就throughput而言，淘宝，ebay, amazon峰值要远远大于stock
exchange，单机数据库是完全挺不住的。而你的设计跟这些要求相去甚远。
【在 T********i 的大作中提到】
: 你忽略的是什么？
: 你根本没搞清楚春运系统的难点：
: 1. 全国一盘棋。任意两点任意方向都有需求
: 2. 读写要同时优化，写数据可能只有那么几亿条。读请求会多几十上百倍。很多人一
: 直刷屏。
: 3. 瞬时负载。要做好在几十分钟内每秒几十万上百万请求的准备。
: 4. 动态规划，要兼顾用户优化和全局优化。比如某路段最抢手，但是还要考虑经过这
: 个路段的其他长途旅客。
: 你的那个数据库怎么应付瞬时激增的请求？
: 我的设计，就是我的核心取代你的数据库和cache，以及transaction manager。
f*4
42 楼
你又离题了。
魏老师这对卖春运车票给了个针对性的方案，不是普通意义上的互联网应用。
你给的只是个互联网应用的通用方案，但完全没有根据春运车票的特性进行优化。
就因为车票实际上是有限的（和股票一样）才能这么干。淘宝，amz完全不适用。
stock
【在 g*****g 的大作中提到】
: 早上带娃去检查身体，刚回来，慢慢回。你对这类互联网应用没有概念。
: 总的来说，互联网应用追求的不是stock exchange的low latency，而是high
: availability和high scalability。追求完全scale out的架构，可以用commodity的硬
: 件线性跟随用户增长。就throughput而言，淘宝，ebay, amazon峰值要远远大于stock
: exchange，单机数据库是完全挺不住的。而你的设计跟这些要求相去甚远。
魏老师这对卖春运车票给了个针对性的方案，不是普通意义上的互联网应用。
你给的只是个互联网应用的通用方案，但完全没有根据春运车票的特性进行优化。
就因为车票实际上是有限的（和股票一样）才能这么干。淘宝，amz完全不适用。
stock
【在 g*****g 的大作中提到】
: 早上带娃去检查身体，刚回来，慢慢回。你对这类互联网应用没有概念。
: 总的来说，互联网应用追求的不是stock exchange的low latency，而是high
: availability和high scalability。追求完全scale out的架构，可以用commodity的硬
: 件线性跟随用户增长。就throughput而言，淘宝，ebay, amazon峰值要远远大于stock
: exchange，单机数据库是完全挺不住的。而你的设计跟这些要求相去甚远。
g*g
43 楼
先说说你的所谓难点。说之前我先澄清一个概念。大部分互联网购物网站，是用户下单
，商品计数更新，连到银行收钱，返回成功这个整个做成一个transaction的。不相信
的可以试试无效的信用卡号，大部分网站不是跟你说下单成功，然后回头发邮件说钱刷
不出来，而是当场就返回错误跟你说支付失败让你改。这种做法可以获得最好的体验。
但对数据库压力比较大，这是我所谓的在线订单。而异步验证的，下单不能当场给你确
定结果的，是所谓的离线订单。
关于分库我提到了几点，一个是按线路分，线路本身就是单向的，来回有车次之分一个
是单数一个是偶数，另一个是按始发日期分。对于不同线路不同日期，从service
layer到数据库，都是完全分离的。互相之间没有瓶颈。而搜索是前端发起的请求，比
如你要查询北京到上海的所有线路，这些都是可以静态索引好的。加上是离线订单，交
易并不需要跨越数据库来做。如何做我后面会讲到，但很明显我的架构完全满足任何两
点任何方向的需求。
这个是关键，但关键不是像你放在一个数据库里。而是读写分离加分库。经过我上面的
分库，一个库其实就只有一个线路一天几千个座位，一条线路算20个段，撑死10万张票
，全天最多几万次的写请求，后台处理订单的时候产生。表里就是20个计数器而已，
MySQL, Oracle之类的常规RDMBS都可以，简单的DB transaction就可以了，完全没有什
么复杂的算法问题。一天几万次，又是异步对latency要求很低，commodity硬件都可以
轻松完成。
上面说了写，这里说读。我提到两点，数据库读只来自cache (当然还有那个近乎单线
程的后台订单处理进程)，用户请求只hit cache。这样只需要一个或者几个服务，从数
据库读，然后刷新cache就可以了，如常见的memcache, redis。cache server可以很多
，需要的话几千上万都可以，结点很多的话还可以分层做push update。这个push
update频率每秒一次是完全没有压力的。或者说，每秒仅仅产生一次数据库读而已。用
户看到的余票数据可以保证是一秒以内的。当没票新的订单就不让下了。
这个优化当然是要的，前面我先假设按线路和天数分，分到最后每个数据库只剩每天几
万次的写，加上每秒一次的读。实在太轻松，太浪费了。所以事实上可以回退而按历史
流量整合，可以所有天放在一起，可以某些线路放在一起，以综合达到一定的数据库硬
件使用率，不浪费硬件。
然而最最重要的，就是这个设计对核心维护余票的数据库，每天最高的读写数量都是固
定的(几万次写+每秒一次读)，外部即使100倍的瞬时冲击也没有影响。
【在 T********i 的大作中提到】
: 你忽略的是什么？
: 你根本没搞清楚春运系统的难点：
: 1. 全国一盘棋。任意两点任意方向都有需求
: 2. 读写要同时优化，写数据可能只有那么几亿条。读请求会多几十上百倍。很多人一
: 直刷屏。
: 3. 瞬时负载。要做好在几十分钟内每秒几十万上百万请求的准备。
: 4. 动态规划，要兼顾用户优化和全局优化。比如某路段最抢手，但是还要考虑经过这
: 个路段的其他长途旅客。
: 你的那个数据库怎么应付瞬时激增的请求？
: 我的设计，就是我的核心取代你的数据库和cache，以及transaction manager。
，商品计数更新，连到银行收钱，返回成功这个整个做成一个transaction的。不相信
的可以试试无效的信用卡号，大部分网站不是跟你说下单成功，然后回头发邮件说钱刷
不出来，而是当场就返回错误跟你说支付失败让你改。这种做法可以获得最好的体验。
但对数据库压力比较大，这是我所谓的在线订单。而异步验证的，下单不能当场给你确
定结果的，是所谓的离线订单。
关于分库我提到了几点，一个是按线路分，线路本身就是单向的，来回有车次之分一个
是单数一个是偶数，另一个是按始发日期分。对于不同线路不同日期，从service
layer到数据库，都是完全分离的。互相之间没有瓶颈。而搜索是前端发起的请求，比
如你要查询北京到上海的所有线路，这些都是可以静态索引好的。加上是离线订单，交
易并不需要跨越数据库来做。如何做我后面会讲到，但很明显我的架构完全满足任何两
点任何方向的需求。
这个是关键，但关键不是像你放在一个数据库里。而是读写分离加分库。经过我上面的
分库，一个库其实就只有一个线路一天几千个座位，一条线路算20个段，撑死10万张票
，全天最多几万次的写请求，后台处理订单的时候产生。表里就是20个计数器而已，
MySQL, Oracle之类的常规RDMBS都可以，简单的DB transaction就可以了，完全没有什
么复杂的算法问题。一天几万次，又是异步对latency要求很低，commodity硬件都可以
轻松完成。
上面说了写，这里说读。我提到两点，数据库读只来自cache (当然还有那个近乎单线
程的后台订单处理进程)，用户请求只hit cache。这样只需要一个或者几个服务，从数
据库读，然后刷新cache就可以了，如常见的memcache, redis。cache server可以很多
，需要的话几千上万都可以，结点很多的话还可以分层做push update。这个push
update频率每秒一次是完全没有压力的。或者说，每秒仅仅产生一次数据库读而已。用
户看到的余票数据可以保证是一秒以内的。当没票新的订单就不让下了。
这个优化当然是要的，前面我先假设按线路和天数分，分到最后每个数据库只剩每天几
万次的写，加上每秒一次的读。实在太轻松，太浪费了。所以事实上可以回退而按历史
流量整合，可以所有天放在一起，可以某些线路放在一起，以综合达到一定的数据库硬
件使用率，不浪费硬件。
然而最最重要的，就是这个设计对核心维护余票的数据库，每天最高的读写数量都是固
定的(几万次写+每秒一次读)，外部即使100倍的瞬时冲击也没有影响。
【在 T********i 的大作中提到】
: 你忽略的是什么？
: 你根本没搞清楚春运系统的难点：
: 1. 全国一盘棋。任意两点任意方向都有需求
: 2. 读写要同时优化，写数据可能只有那么几亿条。读请求会多几十上百倍。很多人一
: 直刷屏。
: 3. 瞬时负载。要做好在几十分钟内每秒几十万上百万请求的准备。
: 4. 动态规划，要兼顾用户优化和全局优化。比如某路段最抢手，但是还要考虑经过这
: 个路段的其他长途旅客。
: 你的那个数据库怎么应付瞬时激增的请求？
: 我的设计，就是我的核心取代你的数据库和cache，以及transaction manager。
g*g
44 楼
我没离题，他的方案不好，不提别的，就算scalability够了。availability也很差，
我后面
可以详细说。
【在 f****4 的大作中提到】
: 你又离题了。
: 魏老师这对卖春运车票给了个针对性的方案，不是普通意义上的互联网应用。
: 你给的只是个互联网应用的通用方案，但完全没有根据春运车票的特性进行优化。
: 就因为车票实际上是有限的（和股票一样）才能这么干。淘宝，amz完全不适用。
:
: stock
我后面
可以详细说。
【在 f****4 的大作中提到】
: 你又离题了。
: 魏老师这对卖春运车票给了个针对性的方案，不是普通意义上的互联网应用。
: 你给的只是个互联网应用的通用方案，但完全没有根据春运车票的特性进行优化。
: 就因为车票实际上是有限的（和股票一样）才能这么干。淘宝，amz完全不适用。
:
: stock
g*g
45 楼
前面说完了维护余票的数据库，以及后台处理订单的模块。这里再说说订单系统。
我一开始就说commit log + 离线订单。订单产生之后怎么处理我说完了，
现在说产生订单的部分。我提到订单系统就是个基于commit log的message queue，
同样是可以根据车次和天划分的。
我之所以提commit log，是因为有很多现成的实现。commit log这块就是魏老师嘴里所谓
的高throughput单机DB。但他对诸多现成的NoSQL实现完全没有概念。而且我很肯定他的
谈到的系统在throughput上远逊于Cassandra。他的DB有瓶颈，我的设计没有，是完全
scale out的。懂得Cassandra的都知道原理，就是根据hash在集群上找到对应的结点写
。魏老师写的是1个结点，Cassandra写的可以是几百个个结点的集群。为了提高可靠性
和availablity，可以用常见的replication factor 3和quorum写。也就是每个数据有
三份拷贝，两份写即时确认，一份后台复制。维护同一数据的三台机器里，一台机器坏
了不影响读写。
不仅如此，Cassandra支持多数据中心。我们的大多数数据库就是三个region, 每个
region三个zone。想象一下就是北京整三个房子，每个房子有独立网络和供电，房子之
间光纤连接。上海和广州也照样一份。这样的好处，就是不只是停电，就算北京地震整
个废掉了。整个系统仍然能够正常工作。魏老师的系统，就是一个局域网上一个主力一
个standby数据库，停电了，网络故障了就玩完。
我提到的多数据中心，是同样可以用到前面的余票RDBMS数据库上的。MySQL就提供这样
的支持，虽然transaction和异地数据库sync都比较慢。但别忘了我把读写压到了写几
万+读每秒一次，支持还是太容易了。
我一开始就说commit log + 离线订单。订单产生之后怎么处理我说完了，
现在说产生订单的部分。我提到订单系统就是个基于commit log的message queue，
同样是可以根据车次和天划分的。
我之所以提commit log，是因为有很多现成的实现。commit log这块就是魏老师嘴里所谓
的高throughput单机DB。但他对诸多现成的NoSQL实现完全没有概念。而且我很肯定他的
谈到的系统在throughput上远逊于Cassandra。他的DB有瓶颈，我的设计没有，是完全
scale out的。懂得Cassandra的都知道原理，就是根据hash在集群上找到对应的结点写
。魏老师写的是1个结点，Cassandra写的可以是几百个个结点的集群。为了提高可靠性
和availablity，可以用常见的replication factor 3和quorum写。也就是每个数据有
三份拷贝，两份写即时确认，一份后台复制。维护同一数据的三台机器里，一台机器坏
了不影响读写。
不仅如此，Cassandra支持多数据中心。我们的大多数数据库就是三个region, 每个
region三个zone。想象一下就是北京整三个房子，每个房子有独立网络和供电，房子之
间光纤连接。上海和广州也照样一份。这样的好处，就是不只是停电，就算北京地震整
个废掉了。整个系统仍然能够正常工作。魏老师的系统，就是一个局域网上一个主力一
个standby数据库，停电了，网络故障了就玩完。
我提到的多数据中心，是同样可以用到前面的余票RDBMS数据库上的。MySQL就提供这样
的支持，虽然transaction和异地数据库sync都比较慢。但别忘了我把读写压到了写几
万+读每秒一次，支持还是太容易了。
z*e
46 楼
说了半天其实就是用单机来替换分布式
这个最理想的结果就是主机
罗嗦半天不着重点
这个最理想的结果就是主机
罗嗦半天不着重点
f*4
47 楼
有个地方值得商榷一下，“大部分互联网购物网站，是用户下单，商品计数更新”
如果是这样的话，淘宝就不会出现卖货卖爆的情况了。
还有，为啥非说他这是离线订单？
抢到票了，log出去，然后银行收钱，出票，用户返回成功。
抢到票了，log出去，银行收钱失败，rollback，用户返回失败。
用户体验是一样的。
【在 g*****g 的大作中提到】
: 先说说你的所谓难点。说之前我先澄清一个概念。大部分互联网购物网站，是用户下单
: ，商品计数更新，连到银行收钱，返回成功这个整个做成一个transaction的。不相信
: 的可以试试无效的信用卡号，大部分网站不是跟你说下单成功，然后回头发邮件说钱刷
: 不出来，而是当场就返回错误跟你说支付失败让你改。这种做法可以获得最好的体验。
: 但对数据库压力比较大，这是我所谓的在线订单。而异步验证的，下单不能当场给你确
: 定结果的，是所谓的离线订单。
:
: 关于分库我提到了几点，一个是按线路分，线路本身就是单向的，来回有车次之分一个
: 是单数一个是偶数，另一个是按始发日期分。对于不同线路不同日期，从service
: layer到数据库，都是完全分离的。互相之间没有瓶颈。而搜索是前端发起的请求，比
如果是这样的话，淘宝就不会出现卖货卖爆的情况了。
还有，为啥非说他这是离线订单？
抢到票了，log出去，然后银行收钱，出票，用户返回成功。
抢到票了，log出去，银行收钱失败，rollback，用户返回失败。
用户体验是一样的。
【在 g*****g 的大作中提到】
: 先说说你的所谓难点。说之前我先澄清一个概念。大部分互联网购物网站，是用户下单
: ，商品计数更新，连到银行收钱，返回成功这个整个做成一个transaction的。不相信
: 的可以试试无效的信用卡号，大部分网站不是跟你说下单成功，然后回头发邮件说钱刷
: 不出来，而是当场就返回错误跟你说支付失败让你改。这种做法可以获得最好的体验。
: 但对数据库压力比较大，这是我所谓的在线订单。而异步验证的，下单不能当场给你确
: 定结果的，是所谓的离线订单。
:
: 关于分库我提到了几点，一个是按线路分，线路本身就是单向的，来回有车次之分一个
: 是单数一个是偶数，另一个是按始发日期分。对于不同线路不同日期，从service
: layer到数据库，都是完全分离的。互相之间没有瓶颈。而搜索是前端发起的请求，比
T*i
48 楼
回错了，当私信回帖了。
说说重点。
1. 很难保证数据库划分完全去除数据依赖性。我在美国订机票，从纽约到芝加哥，就
有道达拉斯转机的。而且特别便宜。
2. 如果数据有依赖性。是distributed transaction，性能不可能好。
3. 即使数据没有依赖性，几十台服务器，性能也没有我一两台服务器好。而且实现更
复杂。复杂不光是实现代码。还包括deployment script和维护等等。
4. 我优化的是数据库。没有管支付。支付是在线还是离线我无所谓。美国这边是在线
简单验证，离线再详细验证。我就有后来收到邮件信用卡不能支付的情况。因为卡被盗
用拿了一个新卡，而系统内是旧卡。竟然能通过实时验证。
5. aviliability没问题。都是多机hot standby。别人能做的，我也都有。
【在 g*****g 的大作中提到】
: 先说说你的所谓难点。说之前我先澄清一个概念。大部分互联网购物网站，是用户下单
: ，商品计数更新，连到银行收钱，返回成功这个整个做成一个transaction的。不相信
: 的可以试试无效的信用卡号，大部分网站不是跟你说下单成功，然后回头发邮件说钱刷
: 不出来，而是当场就返回错误跟你说支付失败让你改。这种做法可以获得最好的体验。
: 但对数据库压力比较大，这是我所谓的在线订单。而异步验证的，下单不能当场给你确
: 定结果的，是所谓的离线订单。
:
: 关于分库我提到了几点，一个是按线路分，线路本身就是单向的，来回有车次之分一个
: 是单数一个是偶数，另一个是按始发日期分。对于不同线路不同日期，从service
: layer到数据库，都是完全分离的。互相之间没有瓶颈。而搜索是前端发起的请求，比
说说重点。
1. 很难保证数据库划分完全去除数据依赖性。我在美国订机票，从纽约到芝加哥，就
有道达拉斯转机的。而且特别便宜。
2. 如果数据有依赖性。是distributed transaction，性能不可能好。
3. 即使数据没有依赖性，几十台服务器，性能也没有我一两台服务器好。而且实现更
复杂。复杂不光是实现代码。还包括deployment script和维护等等。
4. 我优化的是数据库。没有管支付。支付是在线还是离线我无所谓。美国这边是在线
简单验证，离线再详细验证。我就有后来收到邮件信用卡不能支付的情况。因为卡被盗
用拿了一个新卡，而系统内是旧卡。竟然能通过实时验证。
5. aviliability没问题。都是多机hot standby。别人能做的，我也都有。
【在 g*****g 的大作中提到】
: 先说说你的所谓难点。说之前我先澄清一个概念。大部分互联网购物网站，是用户下单
: ，商品计数更新，连到银行收钱，返回成功这个整个做成一个transaction的。不相信
: 的可以试试无效的信用卡号，大部分网站不是跟你说下单成功，然后回头发邮件说钱刷
: 不出来，而是当场就返回错误跟你说支付失败让你改。这种做法可以获得最好的体验。
: 但对数据库压力比较大，这是我所谓的在线订单。而异步验证的，下单不能当场给你确
: 定结果的，是所谓的离线订单。
:
: 关于分库我提到了几点，一个是按线路分，线路本身就是单向的，来回有车次之分一个
: 是单数一个是偶数，另一个是按始发日期分。对于不同线路不同日期，从service
: layer到数据库，都是完全分离的。互相之间没有瓶颈。而搜索是前端发起的请求，比
z*e
49 楼
车票肯定不是那么简单的数据格式
车票涉及到线路和座位
而线路就有客运和货运两种
都用同一个线路，这里面有调度的问题
operation research一个经典问题就是搞火车线路的调度
【在 f****4 的大作中提到】
: 你又离题了。
: 魏老师这对卖春运车票给了个针对性的方案，不是普通意义上的互联网应用。
: 你给的只是个互联网应用的通用方案，但完全没有根据春运车票的特性进行优化。
: 就因为车票实际上是有限的（和股票一样）才能这么干。淘宝，amz完全不适用。
:
: stock
车票涉及到线路和座位
而线路就有客运和货运两种
都用同一个线路，这里面有调度的问题
operation research一个经典问题就是搞火车线路的调度
【在 f****4 的大作中提到】
: 你又离题了。
: 魏老师这对卖春运车票给了个针对性的方案，不是普通意义上的互联网应用。
: 你给的只是个互联网应用的通用方案，但完全没有根据春运车票的特性进行优化。
: 就因为车票实际上是有限的（和股票一样）才能这么干。淘宝，amz完全不适用。
:
: stock
z*e
50 楼
again
log需要反馈的
这里面还要精确到ms
你见过哪个网络哪怕是内网的网络
能保证在1－2ms内反馈的？
你这不是搞笑嘛
【在 f****4 的大作中提到】
: 有个地方值得商榷一下，“大部分互联网购物网站，是用户下单，商品计数更新”
: 如果是这样的话，淘宝就不会出现卖货卖爆的情况了。
: 还有，为啥非说他这是离线订单？
: 抢到票了，log出去，然后银行收钱，出票，用户返回成功。
: 抢到票了，log出去，银行收钱失败，rollback，用户返回失败。
: 用户体验是一样的。
log需要反馈的
这里面还要精确到ms
你见过哪个网络哪怕是内网的网络
能保证在1－2ms内反馈的？
你这不是搞笑嘛
【在 f****4 的大作中提到】
: 有个地方值得商榷一下，“大部分互联网购物网站，是用户下单，商品计数更新”
: 如果是这样的话，淘宝就不会出现卖货卖爆的情况了。
: 还有，为啥非说他这是离线订单？
: 抢到票了，log出去，然后银行收钱，出票，用户返回成功。
: 抢到票了，log出去，银行收钱失败，rollback，用户返回失败。
: 用户体验是一样的。
z*e
51 楼
客户金钱的数据肯定是放在网银里面
然后通过跟网银的某一个接口来处理
不会有人认为钱的数据是放在铁道部吧？
然后通过跟网银的某一个接口来处理
不会有人认为钱的数据是放在铁道部吧？
g*g
52 楼
综上所述，我提出的系统在high availability上比魏老师的强得太多。是多zone, 多
region的冗余系统。另一方面，完全的多region还可以使得流量区域化，从而减少
latency。
另外，我提出的全套方案是没有瓶颈的，不像魏老师的系统DB要是撑不住了，就没辙了。
还有一个巨大的好处，就是不需要牛逼大机器，只要云上就能跑。从而可以利用云上动
态分配的特点，根据压力分配机器，从而极大节省成本。火车票系统，一年就是春运和
几个长假压力特别大，其余时间流量很低。
region的冗余系统。另一方面，完全的多region还可以使得流量区域化，从而减少
latency。
另外，我提出的全套方案是没有瓶颈的，不像魏老师的系统DB要是撑不住了，就没辙了。
还有一个巨大的好处，就是不需要牛逼大机器，只要云上就能跑。从而可以利用云上动
态分配的特点，根据压力分配机器，从而极大节省成本。火车票系统，一年就是春运和
几个长假压力特别大，其余时间流量很低。
z*e
53 楼
楼主的前提就是假设单机能处理全国的数据
还不是用硬盘，是直接上内存搞定，这是一
其次不用考虑legacy system/data
最后还不用考虑网络以及不同系统之间的通信的问题
如果1－2ms内不反馈，那就是硬件故障
综上所述，楼主认为，一个小server能搞定天朝的春运问题
还不是用硬盘，是直接上内存搞定，这是一
其次不用考虑legacy system/data
最后还不用考虑网络以及不同系统之间的通信的问题
如果1－2ms内不反馈，那就是硬件故障
综上所述，楼主认为，一个小server能搞定天朝的春运问题
f*4
54 楼
好虫，你到底有没有好好看看人家的设计？不要想当然好不好。
他的单机高throughput只是一个有票没票的自动机。commit log只是为了支持rollback
而已。
他的外围机器用来做这些scale的事情，系统的极限就是网络io。如果用来卖地球上的
沙子，单机放不下；但是火车票和股票就能处理。
所谓
他的
【在 g*****g 的大作中提到】
: 前面说完了维护余票的数据库，以及后台处理订单的模块。这里再说说订单系统。
: 我一开始就说commit log + 离线订单。订单产生之后怎么处理我说完了，
: 现在说产生订单的部分。我提到订单系统就是个基于commit log的message queue，
: 同样是可以根据车次和天划分的。
: 我之所以提commit log，是因为有很多现成的实现。commit log这块就是魏老师嘴里所谓
: 的高throughput单机DB。但他对诸多现成的NoSQL实现完全没有概念。而且我很肯定他的
: 谈到的系统在throughput上远逊于Cassandra。他的DB有瓶颈，我的设计没有，是完全
: scale out的。懂得Cassandra的都知道原理，就是根据hash在集群上找到对应的结点写
: 。魏老师写的是1个结点，Cassandra写的可以是几百个个结点的集群。为了提高可靠性
: 和availablity，可以用常见的replication factor 3和quorum写。也就是每个数据有
他的单机高throughput只是一个有票没票的自动机。commit log只是为了支持rollback
而已。
他的外围机器用来做这些scale的事情，系统的极限就是网络io。如果用来卖地球上的
沙子，单机放不下；但是火车票和股票就能处理。
所谓
他的
【在 g*****g 的大作中提到】
: 前面说完了维护余票的数据库，以及后台处理订单的模块。这里再说说订单系统。
: 我一开始就说commit log + 离线订单。订单产生之后怎么处理我说完了，
: 现在说产生订单的部分。我提到订单系统就是个基于commit log的message queue，
: 同样是可以根据车次和天划分的。
: 我之所以提commit log，是因为有很多现成的实现。commit log这块就是魏老师嘴里所谓
: 的高throughput单机DB。但他对诸多现成的NoSQL实现完全没有概念。而且我很肯定他的
: 谈到的系统在throughput上远逊于Cassandra。他的DB有瓶颈，我的设计没有，是完全
: scale out的。懂得Cassandra的都知道原理，就是根据hash在集群上找到对应的结点写
: 。魏老师写的是1个结点，Cassandra写的可以是几百个个结点的集群。为了提高可靠性
: 和availablity，可以用常见的replication factor 3和quorum写。也就是每个数据有
g*g
55 楼
先说最重点的，availability你不能做。因为你是单机系统，负荷有上限，而我提出的
系统是没有上限的。另外hot standby，不能避免switch的时候交易丢失，你都在一个
机器上，数目很高，哪怕毫秒都要丢很多。再有，你这种单datacenter的做法，不能避免
网络出问题的availablity。LSE和nasdaq都出过类似的问题，导致系统关闭。而我提出
的系统，没有这个问题。
再说一下数据库划分依赖的问题，我做了最彻底的划分，系统有极大的余量，一天才几
万次写，
多100遍都不多。必要的话，当然可以把一些相关度高的线路放在一起。
最后再说一遍，你的一两台服务器，峰值要要负荷平时100倍以上的流量。而我的系统，
用的全是云上的VM，你买那两台机器的钱，就够我运营10年了。
【在 T********i 的大作中提到】
: 回错了，当私信回帖了。
: 说说重点。
: 1. 很难保证数据库划分完全去除数据依赖性。我在美国订机票，从纽约到芝加哥，就
: 有道达拉斯转机的。而且特别便宜。
: 2. 如果数据有依赖性。是distributed transaction，性能不可能好。
: 3. 即使数据没有依赖性，几十台服务器，性能也没有我一两台服务器好。而且实现更
: 复杂。复杂不光是实现代码。还包括deployment script和维护等等。
: 4. 我优化的是数据库。没有管支付。支付是在线还是离线我无所谓。美国这边是在线
: 简单验证，离线再详细验证。我就有后来收到邮件信用卡不能支付的情况。因为卡被盗
: 用拿了一个新卡，而系统内是旧卡。竟然能通过实时验证。
系统是没有上限的。另外hot standby，不能避免switch的时候交易丢失，你都在一个
机器上，数目很高，哪怕毫秒都要丢很多。再有，你这种单datacenter的做法，不能避免
网络出问题的availablity。LSE和nasdaq都出过类似的问题，导致系统关闭。而我提出
的系统，没有这个问题。
再说一下数据库划分依赖的问题，我做了最彻底的划分，系统有极大的余量，一天才几
万次写，
多100遍都不多。必要的话，当然可以把一些相关度高的线路放在一起。
最后再说一遍，你的一两台服务器，峰值要要负荷平时100倍以上的流量。而我的系统，
用的全是云上的VM，你买那两台机器的钱，就够我运营10年了。
【在 T********i 的大作中提到】
: 回错了，当私信回帖了。
: 说说重点。
: 1. 很难保证数据库划分完全去除数据依赖性。我在美国订机票，从纽约到芝加哥，就
: 有道达拉斯转机的。而且特别便宜。
: 2. 如果数据有依赖性。是distributed transaction，性能不可能好。
: 3. 即使数据没有依赖性，几十台服务器，性能也没有我一两台服务器好。而且实现更
: 复杂。复杂不光是实现代码。还包括deployment script和维护等等。
: 4. 我优化的是数据库。没有管支付。支付是在线还是离线我无所谓。美国这边是在线
: 简单验证，离线再详细验证。我就有后来收到邮件信用卡不能支付的情况。因为卡被盗
: 用拿了一个新卡，而系统内是旧卡。竟然能通过实时验证。
T*i
56 楼
说了这么多你还是没抓住重点。
我的系统也是NoSQL。Cassandra那点玩意儿做一个比他快1-2个数量级的也没问题。
我说的是一个不能分布的应用。只比单机性能。
现实中有很多这样的例子，春运算一个，股票和金融交易算一个，还有很多。将来甚至
淘宝之类的很多商品也有可能有这样的特性。
换句话说，分布到最小的granularity也就这样了。这种情况下衡量性能就是一个Gb/s。
再换句话说，你那些东西我的系统都能做，scalability和availability。你用那个
Cassandra做个NASDAQ交易系统给我看看？
所谓
他的
【在 g*****g 的大作中提到】
: 前面说完了维护余票的数据库，以及后台处理订单的模块。这里再说说订单系统。
: 我一开始就说commit log + 离线订单。订单产生之后怎么处理我说完了，
: 现在说产生订单的部分。我提到订单系统就是个基于commit log的message queue，
: 同样是可以根据车次和天划分的。
: 我之所以提commit log，是因为有很多现成的实现。commit log这块就是魏老师嘴里所谓
: 的高throughput单机DB。但他对诸多现成的NoSQL实现完全没有概念。而且我很肯定他的
: 谈到的系统在throughput上远逊于Cassandra。他的DB有瓶颈，我的设计没有，是完全
: scale out的。懂得Cassandra的都知道原理，就是根据hash在集群上找到对应的结点写
: 。魏老师写的是1个结点，Cassandra写的可以是几百个个结点的集群。为了提高可靠性
: 和availablity，可以用常见的replication factor 3和quorum写。也就是每个数据有
我的系统也是NoSQL。Cassandra那点玩意儿做一个比他快1-2个数量级的也没问题。
我说的是一个不能分布的应用。只比单机性能。
现实中有很多这样的例子，春运算一个，股票和金融交易算一个，还有很多。将来甚至
淘宝之类的很多商品也有可能有这样的特性。
换句话说，分布到最小的granularity也就这样了。这种情况下衡量性能就是一个Gb/s。
再换句话说，你那些东西我的系统都能做，scalability和availability。你用那个
Cassandra做个NASDAQ交易系统给我看看？
所谓
他的
【在 g*****g 的大作中提到】
: 前面说完了维护余票的数据库，以及后台处理订单的模块。这里再说说订单系统。
: 我一开始就说commit log + 离线订单。订单产生之后怎么处理我说完了，
: 现在说产生订单的部分。我提到订单系统就是个基于commit log的message queue，
: 同样是可以根据车次和天划分的。
: 我之所以提commit log，是因为有很多现成的实现。commit log这块就是魏老师嘴里所谓
: 的高throughput单机DB。但他对诸多现成的NoSQL实现完全没有概念。而且我很肯定他的
: 谈到的系统在throughput上远逊于Cassandra。他的DB有瓶颈，我的设计没有，是完全
: scale out的。懂得Cassandra的都知道原理，就是根据hash在集群上找到对应的结点写
: 。魏老师写的是1个结点，Cassandra写的可以是几百个个结点的集群。为了提高可靠性
: 和availablity，可以用常见的replication factor 3和quorum写。也就是每个数据有
z*e
57 楼
分布式的瓶颈在io上难道不是很正常的事？
它搞成单机不就是想回避io上的瓶颈？
但是最后还是要求银行给反馈
还单机什么哟
rollback
【在 f****4 的大作中提到】
: 好虫，你到底有没有好好看看人家的设计？不要想当然好不好。
: 他的单机高throughput只是一个有票没票的自动机。commit log只是为了支持rollback
: 而已。
: 他的外围机器用来做这些scale的事情，系统的极限就是网络io。如果用来卖地球上的
: 沙子，单机放不下；但是火车票和股票就能处理。
:
: 所谓
: 他的
它搞成单机不就是想回避io上的瓶颈？
但是最后还是要求银行给反馈
还单机什么哟
rollback
【在 f****4 的大作中提到】
: 好虫，你到底有没有好好看看人家的设计？不要想当然好不好。
: 他的单机高throughput只是一个有票没票的自动机。commit log只是为了支持rollback
: 而已。
: 他的外围机器用来做这些scale的事情，系统的极限就是网络io。如果用来卖地球上的
: 沙子，单机放不下；但是火车票和股票就能处理。
:
: 所谓
: 他的
z*e
58 楼
淘宝不是分布式？
主机能比分布式做更多的事难道不是旧闻？
问题在于主机贵得半死，你有几个人买得起？
你是这不考虑那不考虑，最后计算天朝多少人次客运
然后自己设计一个数据结构，而且简单得不能再简单
最后告诉所有人，这个可以解决所有问题
s。
【在 T********i 的大作中提到】
: 说了这么多你还是没抓住重点。
: 我的系统也是NoSQL。Cassandra那点玩意儿做一个比他快1-2个数量级的也没问题。
: 我说的是一个不能分布的应用。只比单机性能。
: 现实中有很多这样的例子，春运算一个，股票和金融交易算一个，还有很多。将来甚至
: 淘宝之类的很多商品也有可能有这样的特性。
: 换句话说，分布到最小的granularity也就这样了。这种情况下衡量性能就是一个Gb/s。
: 再换句话说，你那些东西我的系统都能做，scalability和availability。你用那个
: Cassandra做个NASDAQ交易系统给我看看？
:
: 所谓
主机能比分布式做更多的事难道不是旧闻？
问题在于主机贵得半死，你有几个人买得起？
你是这不考虑那不考虑，最后计算天朝多少人次客运
然后自己设计一个数据结构，而且简单得不能再简单
最后告诉所有人，这个可以解决所有问题
s。
【在 T********i 的大作中提到】
: 说了这么多你还是没抓住重点。
: 我的系统也是NoSQL。Cassandra那点玩意儿做一个比他快1-2个数量级的也没问题。
: 我说的是一个不能分布的应用。只比单机性能。
: 现实中有很多这样的例子，春运算一个，股票和金融交易算一个，还有很多。将来甚至
: 淘宝之类的很多商品也有可能有这样的特性。
: 换句话说，分布到最小的granularity也就这样了。这种情况下衡量性能就是一个Gb/s。
: 再换句话说，你那些东西我的系统都能做，scalability和availability。你用那个
: Cassandra做个NASDAQ交易系统给我看看？
:
: 所谓
f*4
59 楼
你是说搞个卖车票的方案还要管调度？
是不是顺带着得搞个3个代表啥的？
是先确定了车次调度，再让卖票的，次序别弄错了
【在 z****e 的大作中提到】
: 车票肯定不是那么简单的数据格式
: 车票涉及到线路和座位
: 而线路就有客运和货运两种
: 都用同一个线路，这里面有调度的问题
: operation research一个经典问题就是搞火车线路的调度
是不是顺带着得搞个3个代表啥的？
是先确定了车次调度，再让卖票的，次序别弄错了
【在 z****e 的大作中提到】
: 车票肯定不是那么简单的数据格式
: 车票涉及到线路和座位
: 而线路就有客运和货运两种
: 都用同一个线路，这里面有调度的问题
: operation research一个经典问题就是搞火车线路的调度
g*g
60 楼
把错误坚持到底有意义吗？stock exchange追求的是low latency，微妙级的latency。
卖票追求的就是high availability，linear scalability，线路再多不怕，人再多不
怕，断电了不怕。你连数据类型都没明白。
至于你能写得比cassandra好，那纯粹意淫了。写一个大家瞅瞅，人mongodb弄了5个亿
，别发财机会不要。
还我那些东西你的系统都能做，我提的系统，用户多100倍，我多扔100倍的硬件上去就
完了，你的行吗？
s。
【在 T********i 的大作中提到】
: 说了这么多你还是没抓住重点。
: 我的系统也是NoSQL。Cassandra那点玩意儿做一个比他快1-2个数量级的也没问题。
: 我说的是一个不能分布的应用。只比单机性能。
: 现实中有很多这样的例子，春运算一个，股票和金融交易算一个，还有很多。将来甚至
: 淘宝之类的很多商品也有可能有这样的特性。
: 换句话说，分布到最小的granularity也就这样了。这种情况下衡量性能就是一个Gb/s。
: 再换句话说，你那些东西我的系统都能做，scalability和availability。你用那个
: Cassandra做个NASDAQ交易系统给我看看？
:
: 所谓
卖票追求的就是high availability，linear scalability，线路再多不怕，人再多不
怕，断电了不怕。你连数据类型都没明白。
至于你能写得比cassandra好，那纯粹意淫了。写一个大家瞅瞅，人mongodb弄了5个亿
，别发财机会不要。
还我那些东西你的系统都能做，我提的系统，用户多100倍，我多扔100倍的硬件上去就
完了，你的行吗？
s。
【在 T********i 的大作中提到】
: 说了这么多你还是没抓住重点。
: 我的系统也是NoSQL。Cassandra那点玩意儿做一个比他快1-2个数量级的也没问题。
: 我说的是一个不能分布的应用。只比单机性能。
: 现实中有很多这样的例子，春运算一个，股票和金融交易算一个，还有很多。将来甚至
: 淘宝之类的很多商品也有可能有这样的特性。
: 换句话说，分布到最小的granularity也就这样了。这种情况下衡量性能就是一个Gb/s。
: 再换句话说，你那些东西我的系统都能做，scalability和availability。你用那个
: Cassandra做个NASDAQ交易系统给我看看？
:
: 所谓
z*e
61 楼
你这也不管，那也不管，你的系统如何及时反馈出其它系统上的变化呢？
你搞分布式见过不需要在乎其它系统的分布式么？
【在 f****4 的大作中提到】
: 你是说搞个卖车票的方案还要管调度？
: 是不是顺带着得搞个3个代表啥的？
: 是先确定了车次调度，再让卖票的，次序别弄错了
你搞分布式见过不需要在乎其它系统的分布式么？
【在 f****4 的大作中提到】
: 你是说搞个卖车票的方案还要管调度？
: 是不是顺带着得搞个3个代表啥的？
: 是先确定了车次调度，再让卖票的，次序别弄错了
T*i
62 楼
很多高数据依赖的只能单机，因为分布只能造成IO指数增长。这种情况下技术的极限就
是单机性能。
【在 z****e 的大作中提到】
: 分布式的瓶颈在io上难道不是很正常的事？
: 它搞成单机不就是想回避io上的瓶颈？
: 但是最后还是要求银行给反馈
: 还单机什么哟
:
: rollback
是单机性能。
【在 z****e 的大作中提到】
: 分布式的瓶颈在io上难道不是很正常的事？
: 它搞成单机不就是想回避io上的瓶颈？
: 但是最后还是要求银行给反馈
: 还单机什么哟
:
: rollback
f*4
63 楼
你是说用户点着秒级延迟的UI，不能忍受ms级别的log ack延迟？
你就是ping一下都有20ms+的延迟啊
【在 z****e 的大作中提到】
: again
: log需要反馈的
: 这里面还要精确到ms
: 你见过哪个网络哪怕是内网的网络
: 能保证在1－2ms内反馈的？
: 你这不是搞笑嘛
你就是ping一下都有20ms+的延迟啊
【在 z****e 的大作中提到】
: again
: log需要反馈的
: 这里面还要精确到ms
: 你见过哪个网络哪怕是内网的网络
: 能保证在1－2ms内反馈的？
: 你这不是搞笑嘛
z*e
64 楼
随便一台主机都比你买的破server强一万倍
【在 T********i 的大作中提到】
: 很多高数据依赖的只能单机，因为分布只能造成IO指数增长。这种情况下技术的极限就
: 是单机性能。
【在 T********i 的大作中提到】
: 很多高数据依赖的只能单机，因为分布只能造成IO指数增长。这种情况下技术的极限就
: 是单机性能。
z*e
65 楼
1－2ms内反馈是楼主说的
你这不是公然挑战楼主的设计嘛？
【在 f****4 的大作中提到】
: 你是说用户点着秒级延迟的UI，不能忍受ms级别的log ack延迟？
: 你就是ping一下都有20ms+的延迟啊
你这不是公然挑战楼主的设计嘛？
【在 f****4 的大作中提到】
: 你是说用户点着秒级延迟的UI，不能忍受ms级别的log ack延迟？
: 你就是ping一下都有20ms+的延迟啊
f*4
66 楼
不会有人认为做这么个系统，顺带还要把银行接口重新设计一下吧？
堆机器来和网银接口处理。网银接口处理不了那也是它的事情。
【在 z****e 的大作中提到】
: 客户金钱的数据肯定是放在网银里面
: 然后通过跟网银的某一个接口来处理
: 不会有人认为钱的数据是放在铁道部吧？
堆机器来和网银接口处理。网银接口处理不了那也是它的事情。
【在 z****e 的大作中提到】
: 客户金钱的数据肯定是放在网银里面
: 然后通过跟网银的某一个接口来处理
: 不会有人认为钱的数据是放在铁道部吧？
T*i
67 楼
这就是你的问题。
【在 z****e 的大作中提到】
: again
: log需要反馈的
: 这里面还要精确到ms
: 你见过哪个网络哪怕是内网的网络
: 能保证在1－2ms内反馈的？
: 你这不是搞笑嘛
【在 z****e 的大作中提到】
: again
: log需要反馈的
: 这里面还要精确到ms
: 你见过哪个网络哪怕是内网的网络
: 能保证在1－2ms内反馈的？
: 你这不是搞笑嘛
g*g
68 楼
淘宝是淘宝，淘宝不是一般的购物网站。大多数网站到不了这个流量，没有这个必要。
异步写起来更麻烦，体验更差。纯粹对数据库压力小而已。
银行收钱这个，是外部系统。latency本身就大，SLA也不见得很高，比如说每秒支持你
100个交易。
你高峰每秒进来10万个，你怎么办，最少也得等1000秒。你让用户等1000秒还叫什么在
线订单。
【在 f****4 的大作中提到】
: 有个地方值得商榷一下，“大部分互联网购物网站，是用户下单，商品计数更新”
: 如果是这样的话，淘宝就不会出现卖货卖爆的情况了。
: 还有，为啥非说他这是离线订单？
: 抢到票了，log出去，然后银行收钱，出票，用户返回成功。
: 抢到票了，log出去，银行收钱失败，rollback，用户返回失败。
: 用户体验是一样的。
异步写起来更麻烦，体验更差。纯粹对数据库压力小而已。
银行收钱这个，是外部系统。latency本身就大，SLA也不见得很高，比如说每秒支持你
100个交易。
你高峰每秒进来10万个，你怎么办，最少也得等1000秒。你让用户等1000秒还叫什么在
线订单。
【在 f****4 的大作中提到】
: 有个地方值得商榷一下，“大部分互联网购物网站，是用户下单，商品计数更新”
: 如果是这样的话，淘宝就不会出现卖货卖爆的情况了。
: 还有，为啥非说他这是离线订单？
: 抢到票了，log出去，然后银行收钱，出票，用户返回成功。
: 抢到票了，log出去，银行收钱失败，rollback，用户返回失败。
: 用户体验是一样的。
z*e
69 楼
做一个哪怕最简单的分布式
你什么时候不用考虑其它系统了？
如何跟其它系统集成是分布式最常见的问题
连之一我都不用加
【在 f****4 的大作中提到】
: 不会有人认为做这么个系统，顺带还要把银行接口重新设计一下吧？
: 堆机器来和网银接口处理。网银接口处理不了那也是它的事情。
你什么时候不用考虑其它系统了？
如何跟其它系统集成是分布式最常见的问题
连之一我都不用加
【在 f****4 的大作中提到】
: 不会有人认为做这么个系统，顺带还要把银行接口重新设计一下吧？
: 堆机器来和网银接口处理。网银接口处理不了那也是它的事情。
z*e
70 楼
所以你永远都不需要考虑问题
有问题都是别人的问题对吧？
【在 T********i 的大作中提到】
: 这就是你的问题。
有问题都是别人的问题对吧？
【在 T********i 的大作中提到】
: 这就是你的问题。
T*i
71 楼
你这不是扯淡么？
stock exchange没有high availability，linear scalability？
stock exchange能够支持持续的每秒上百万的transaction。这种流量你这辈子都没机
会做。
你还是先证明你的分布式春运数据库性能比我的单机的好再说吧。
【在 g*****g 的大作中提到】
: 把错误坚持到底有意义吗？stock exchange追求的是low latency，微妙级的latency。
: 卖票追求的就是high availability，linear scalability，线路再多不怕，人再多不
: 怕，断电了不怕。你连数据类型都没明白。
: 至于你能写得比cassandra好，那纯粹意淫了。写一个大家瞅瞅，人mongodb弄了5个亿
: ，别发财机会不要。
: 还我那些东西你的系统都能做，我提的系统，用户多100倍，我多扔100倍的硬件上去就
: 完了，你的行吗？
:
: s。
stock exchange没有high availability，linear scalability？
stock exchange能够支持持续的每秒上百万的transaction。这种流量你这辈子都没机
会做。
你还是先证明你的分布式春运数据库性能比我的单机的好再说吧。
【在 g*****g 的大作中提到】
: 把错误坚持到底有意义吗？stock exchange追求的是low latency，微妙级的latency。
: 卖票追求的就是high availability，linear scalability，线路再多不怕，人再多不
: 怕，断电了不怕。你连数据类型都没明白。
: 至于你能写得比cassandra好，那纯粹意淫了。写一个大家瞅瞅，人mongodb弄了5个亿
: ，别发财机会不要。
: 还我那些东西你的系统都能做，我提的系统，用户多100倍，我多扔100倍的硬件上去就
: 完了，你的行吗？
:
: s。
z*e
72 楼
银行要反馈给你transaction的结果你才能写log
要不然你写什么？搞定了，结果待定，然后直接commit？
农民工欢天喜地拿到票了回家了，整理衣物去了
下一步银行反馈，挂了，请回滚，你怎么办？
再去退钱？退钱一堆麻烦事要做，就算成功退钱了吧
农民工上车时候验票，突然发现，票没有订到？
你觉得农民工会怎么办？
【在 f****4 的大作中提到】
: 不会有人认为做这么个系统，顺带还要把银行接口重新设计一下吧？
: 堆机器来和网银接口处理。网银接口处理不了那也是它的事情。
要不然你写什么？搞定了，结果待定，然后直接commit？
农民工欢天喜地拿到票了回家了，整理衣物去了
下一步银行反馈，挂了，请回滚，你怎么办？
再去退钱？退钱一堆麻烦事要做，就算成功退钱了吧
农民工上车时候验票，突然发现，票没有订到？
你觉得农民工会怎么办？
【在 f****4 的大作中提到】
: 不会有人认为做这么个系统，顺带还要把银行接口重新设计一下吧？
: 堆机器来和网银接口处理。网银接口处理不了那也是它的事情。
g*g
73 楼
stock exchange当然在scalability和availablity差多了。纽约大地震了
NYSE就要shutdown。我提的系统北京废了都还能继续跑，比个头呀。
我做架构的系统，最多的时候每天request过了1B。等你啥时候有机会做这种架构
再跟我吹吧。
【在 T********i 的大作中提到】
: 你这不是扯淡么？
: stock exchange没有high availability，linear scalability？
: stock exchange能够支持持续的每秒上百万的transaction。这种流量你这辈子都没机
: 会做。
: 你还是先证明你的分布式春运数据库性能比我的单机的好再说吧。
NYSE就要shutdown。我提的系统北京废了都还能继续跑，比个头呀。
我做架构的系统，最多的时候每天request过了1B。等你啥时候有机会做这种架构
再跟我吹吧。
【在 T********i 的大作中提到】
: 你这不是扯淡么？
: stock exchange没有high availability，linear scalability？
: stock exchange能够支持持续的每秒上百万的transaction。这种流量你这辈子都没机
: 会做。
: 你还是先证明你的分布式春运数据库性能比我的单机的好再说吧。
T*i
74 楼
Hard Realtime System本来执行就是能精确定时的。
假定IO bound，给定throughput，两边的ping-pong分布很小。
我的系统context switch都没有了。整个kernel都bypass了。当然可以有一个确定的
timeout。
不见得是1-2ms，但是绝对是毫秒级。如果这个你理解不了。就没有讨论的必要了。
【在 z****e 的大作中提到】
: 1－2ms内反馈是楼主说的
: 你这不是公然挑战楼主的设计嘛？
假定IO bound，给定throughput，两边的ping-pong分布很小。
我的系统context switch都没有了。整个kernel都bypass了。当然可以有一个确定的
timeout。
不见得是1-2ms，但是绝对是毫秒级。如果这个你理解不了。就没有讨论的必要了。
【在 z****e 的大作中提到】
: 1－2ms内反馈是楼主说的
: 你这不是公然挑战楼主的设计嘛？
z*e
75 楼
我相信可以，但是你这种系统里面实现不了
当然也不是实现不了，可以实现，但是成本在那边
bypass个头啊，说的是message发送出去之后ack的反馈
你说说这里面是不是涉及到网络了
现在ping一下都要20ms,你怎么保证1－2ms内能够反馈？
【在 T********i 的大作中提到】
: Hard Realtime System本来执行就是能精确定时的。
: 假定IO bound，给定throughput，两边的ping-pong分布很小。
: 我的系统context switch都没有了。整个kernel都bypass了。当然可以有一个确定的
: timeout。
: 不见得是1-2ms，但是绝对是毫秒级。如果这个你理解不了。就没有讨论的必要了。
当然也不是实现不了，可以实现，但是成本在那边
bypass个头啊，说的是message发送出去之后ack的反馈
你说说这里面是不是涉及到网络了
现在ping一下都要20ms,你怎么保证1－2ms内能够反馈？
【在 T********i 的大作中提到】
: Hard Realtime System本来执行就是能精确定时的。
: 假定IO bound，给定throughput，两边的ping-pong分布很小。
: 我的系统context switch都没有了。整个kernel都bypass了。当然可以有一个确定的
: timeout。
: 不见得是1-2ms，但是绝对是毫秒级。如果这个你理解不了。就没有讨论的必要了。
g*g
76 楼
单机的系统跟完全scale out的分布式系统比availability和scalability，我老也没啥
好说了。
单机都能解决，还要NoSQL干啥。
魏老师到头来就剩我就是比你牛逼这一句。
好说了。
单机都能解决，还要NoSQL干啥。
魏老师到头来就剩我就是比你牛逼这一句。
T*i
77 楼
request不是transaction。porn网站每天request过1b的多得是。
【在 g*****g 的大作中提到】
: stock exchange当然在scalability和availablity差多了。纽约大地震了
: NYSE就要shutdown。我提的系统北京废了都还能继续跑，比个头呀。
: 我做架构的系统，最多的时候每天request过了1B。等你啥时候有机会做这种架构
: 再跟我吹吧。
【在 g*****g 的大作中提到】
: stock exchange当然在scalability和availablity差多了。纽约大地震了
: NYSE就要shutdown。我提的系统北京废了都还能继续跑，比个头呀。
: 我做架构的系统，最多的时候每天request过了1B。等你啥时候有机会做这种架构
: 再跟我吹吧。
f*4
78 楼
需求分析是让你了解用户需求不是让你给用户创造需求
你以为国内卖个车票，调度说加量车就能加的？国内没和政府打过交道吧？
车次定了才能卖票的。春运的车次不定年初就做好了，每个铁路局藏点运力起来，到时
候成临时增开的客列。就是临时增开的客列，调度都是提前做好预案的。
你卖票的，只要在开卖之前，把票的信息读到系统里面就好了。
要是运气不好，买了票，到车站，车坏了，算你倒霉，退票在买票。和机票一个道理。
【在 z****e 的大作中提到】
: 你这也不管，那也不管，你的系统如何及时反馈出其它系统上的变化呢？
: 你搞分布式见过不需要在乎其它系统的分布式么？
你以为国内卖个车票，调度说加量车就能加的？国内没和政府打过交道吧？
车次定了才能卖票的。春运的车次不定年初就做好了，每个铁路局藏点运力起来，到时
候成临时增开的客列。就是临时增开的客列，调度都是提前做好预案的。
你卖票的，只要在开卖之前，把票的信息读到系统里面就好了。
要是运气不好，买了票，到车站，车坏了，算你倒霉，退票在买票。和机票一个道理。
【在 z****e 的大作中提到】
: 你这也不管，那也不管，你的系统如何及时反馈出其它系统上的变化呢？
: 你搞分布式见过不需要在乎其它系统的分布式么？
T*i
79 楼
别吹牛。给定一个具体任务，大家比一比Gb/s。
【在 z****e 的大作中提到】
: 随便一台主机都比你买的破server强一万倍
【在 z****e 的大作中提到】
: 随便一台主机都比你买的破server强一万倍
z*e
80 楼
需求分析最常见的几个问题
第一，客户不知道他们需要什么
第二，客户有不切实际的schedule
第三，客户的需求总是在变化
所以需求工程就跟战场一样
战场上发生的一切，都不是按照你原先计划好的去发展
往往有各种异常错误发生，那么如何把这些错误和异常控制起来
这才是需求工程的核心价值和目的所在
请不要假设这一切都不存在，实际上这一切都存在
【在 f****4 的大作中提到】
: 需求分析是让你了解用户需求不是让你给用户创造需求
: 你以为国内卖个车票，调度说加量车就能加的？国内没和政府打过交道吧？
: 车次定了才能卖票的。春运的车次不定年初就做好了，每个铁路局藏点运力起来，到时
: 候成临时增开的客列。就是临时增开的客列，调度都是提前做好预案的。
: 你卖票的，只要在开卖之前，把票的信息读到系统里面就好了。
: 要是运气不好，买了票，到车站，车坏了，算你倒霉，退票在买票。和机票一个道理。
第一，客户不知道他们需要什么
第二，客户有不切实际的schedule
第三，客户的需求总是在变化
所以需求工程就跟战场一样
战场上发生的一切，都不是按照你原先计划好的去发展
往往有各种异常错误发生，那么如何把这些错误和异常控制起来
这才是需求工程的核心价值和目的所在
请不要假设这一切都不存在，实际上这一切都存在
【在 f****4 的大作中提到】
: 需求分析是让你了解用户需求不是让你给用户创造需求
: 你以为国内卖个车票，调度说加量车就能加的？国内没和政府打过交道吧？
: 车次定了才能卖票的。春运的车次不定年初就做好了，每个铁路局藏点运力起来，到时
: 候成临时增开的客列。就是临时增开的客列，调度都是提前做好预案的。
: 你卖票的，只要在开卖之前，把票的信息读到系统里面就好了。
: 要是运气不好，买了票，到车站，车坏了，算你倒霉，退票在买票。和机票一个道理。
f*4
81 楼
那你就麻烦再解释一件事情，你的抢票是怎么实现的。
能不能避免一票多卖的情况？老魏的可以！
了。
【在 g*****g 的大作中提到】
: 综上所述，我提出的系统在high availability上比魏老师的强得太多。是多zone, 多
: region的冗余系统。另一方面，完全的多region还可以使得流量区域化，从而减少
: latency。
: 另外，我提出的全套方案是没有瓶颈的，不像魏老师的系统DB要是撑不住了，就没辙了。
: 还有一个巨大的好处，就是不需要牛逼大机器，只要云上就能跑。从而可以利用云上动
: 态分配的特点，根据压力分配机器，从而极大节省成本。火车票系统，一年就是春运和
: 几个长假压力特别大，其余时间流量很低。
能不能避免一票多卖的情况？老魏的可以！
了。
【在 g*****g 的大作中提到】
: 综上所述，我提出的系统在high availability上比魏老师的强得太多。是多zone, 多
: region的冗余系统。另一方面，完全的多region还可以使得流量区域化，从而减少
: latency。
: 另外，我提出的全套方案是没有瓶颈的，不像魏老师的系统DB要是撑不住了，就没辙了。
: 还有一个巨大的好处，就是不需要牛逼大机器，只要云上就能跑。从而可以利用云上动
: 态分配的特点，根据压力分配机器，从而极大节省成本。火车票系统，一年就是春运和
: 几个长假压力特别大，其余时间流量很低。
g*g
82 楼
我做的是message系统，每天处理的message过了1B，那是1B的写。
【在 T********i 的大作中提到】
: request不是transaction。porn网站每天request过1b的多得是。
【在 T********i 的大作中提到】
: request不是transaction。porn网站每天request过1b的多得是。
T*i
83 楼
我说的我的master和hot standby的通信。环境可控。
你根本不懂实时系统。多说无益。
【在 z****e 的大作中提到】
: 我相信可以，但是你这种系统里面实现不了
: 当然也不是实现不了，可以实现，但是成本在那边
: bypass个头啊，说的是message发送出去之后ack的反馈
: 你说说这里面是不是涉及到网络了
: 现在ping一下都要20ms,你怎么保证1－2ms内能够反馈？
你根本不懂实时系统。多说无益。
【在 z****e 的大作中提到】
: 我相信可以，但是你这种系统里面实现不了
: 当然也不是实现不了，可以实现，但是成本在那边
: bypass个头啊，说的是message发送出去之后ack的反馈
: 你说说这里面是不是涉及到网络了
: 现在ping一下都要20ms,你怎么保证1－2ms内能够反馈？
z*e
84 楼
我不吹牛，你去找台主机去比去
要是你接触不到主机，我没办法
【在 T********i 的大作中提到】
: 别吹牛。给定一个具体任务，大家比一比Gb/s。
要是你接触不到主机，我没办法
【在 T********i 的大作中提到】
: 别吹牛。给定一个具体任务，大家比一比Gb/s。
z*e
85 楼
你为什么要假设环境可控呢？
你做了无数的不切实际的假设
什么叫做现实复杂性？
你对分布式整个一狗屁不通
【在 T********i 的大作中提到】
: 我说的我的master和hot standby的通信。环境可控。
: 你根本不懂实时系统。多说无益。
你做了无数的不切实际的假设
什么叫做现实复杂性？
你对分布式整个一狗屁不通
【在 T********i 的大作中提到】
: 我说的我的master和hot standby的通信。环境可控。
: 你根本不懂实时系统。多说无益。
z*e
86 楼
最简单的一个例子
你这里假设
调度都是提前做好预案的
你信不信到时候一定会变？
【在 f****4 的大作中提到】
: 需求分析是让你了解用户需求不是让你给用户创造需求
: 你以为国内卖个车票，调度说加量车就能加的？国内没和政府打过交道吧？
: 车次定了才能卖票的。春运的车次不定年初就做好了，每个铁路局藏点运力起来，到时
: 候成临时增开的客列。就是临时增开的客列，调度都是提前做好预案的。
: 你卖票的，只要在开卖之前，把票的信息读到系统里面就好了。
: 要是运气不好，买了票，到车站，车坏了，算你倒霉，退票在买票。和机票一个道理。
你这里假设
调度都是提前做好预案的
你信不信到时候一定会变？
【在 f****4 的大作中提到】
: 需求分析是让你了解用户需求不是让你给用户创造需求
: 你以为国内卖个车票，调度说加量车就能加的？国内没和政府打过交道吧？
: 车次定了才能卖票的。春运的车次不定年初就做好了，每个铁路局藏点运力起来，到时
: 候成临时增开的客列。就是临时增开的客列，调度都是提前做好预案的。
: 你卖票的，只要在开卖之前，把票的信息读到系统里面就好了。
: 要是运气不好，买了票，到车站，车坏了，算你倒霉，退票在买票。和机票一个道理。
T*i
87 楼
还行，快要赶上我在NASDAQ CO-LO的6台机器一天的总消息数了。
【在 g*****g 的大作中提到】
: 我做的是message系统，每天处理的message过了1B，那是1B的写。
【在 g*****g 的大作中提到】
: 我做的是message系统，每天处理的message过了1B，那是1B的写。
g*g
88 楼
我没一票多卖呀，我就是让随便你下单，回头给你发邮件告诉你成功没。
后台数据库锁到了，银行钱也刷到了，你就买着了，否则没买着。
这个延迟纯粹取决于银行，银行一秒处理了，你立刻就知道了。
量大，1秒出100万个订单，银行处理要几个小时，你就得等几个小时。
魏老师的那点比这个强？下单立刻跟你说买着了，你欢天喜地的，过
几个小时银行那边处理，发现你账号错了，再把你cancel了。那还不如
我刚开始不跟你说成功没。
【在 f****4 的大作中提到】
: 那你就麻烦再解释一件事情，你的抢票是怎么实现的。
: 能不能避免一票多卖的情况？老魏的可以！
:
: 了。
后台数据库锁到了，银行钱也刷到了，你就买着了，否则没买着。
这个延迟纯粹取决于银行，银行一秒处理了，你立刻就知道了。
量大，1秒出100万个订单，银行处理要几个小时，你就得等几个小时。
魏老师的那点比这个强？下单立刻跟你说买着了，你欢天喜地的，过
几个小时银行那边处理，发现你账号错了，再把你cancel了。那还不如
我刚开始不跟你说成功没。
【在 f****4 的大作中提到】
: 那你就麻烦再解释一件事情，你的抢票是怎么实现的。
: 能不能避免一票多卖的情况？老魏的可以！
:
: 了。
T*i
89 楼
我的两台机器在我自己的数据中心。同一个局域网。这就是环境可控。
hot standby主要解决availability的问题。
至于为什么能保证在timeout时间内ACK，你需要重新学习实时系统，我没有义务教你，
【在 z****e 的大作中提到】
: 你为什么要假设环境可控呢？
: 你做了无数的不切实际的假设
: 什么叫做现实复杂性？
: 你对分布式整个一狗屁不通
hot standby主要解决availability的问题。
至于为什么能保证在timeout时间内ACK，你需要重新学习实时系统，我没有义务教你，
【在 z****e 的大作中提到】
: 你为什么要假设环境可控呢？
: 你做了无数的不切实际的假设
: 什么叫做现实复杂性？
: 你对分布式整个一狗屁不通
z*e
90 楼
网络还real time个球啊
你告诉我说经过网络的数据要保证1－2ms内反馈
你自己信么？你自己试一下也知道行不行啊
吹什么牛啊
【在 T********i 的大作中提到】
: 我的两台机器在我自己的数据中心。同一个局域网。这就是环境可控。
: hot standby主要解决availability的问题。
: 至于为什么能保证在timeout时间内ACK，你需要重新学习实时系统，我没有义务教你，
你告诉我说经过网络的数据要保证1－2ms内反馈
你自己信么？你自己试一下也知道行不行啊
吹什么牛啊
【在 T********i 的大作中提到】
: 我的两台机器在我自己的数据中心。同一个局域网。这就是环境可控。
: hot standby主要解决availability的问题。
: 至于为什么能保证在timeout时间内ACK，你需要重新学习实时系统，我没有义务教你，
g*g
91 楼
LOL。断个电，断个网，玩完了。你懂啥分布式设计。
【在 T********i 的大作中提到】
: 我的两台机器在我自己的数据中心。同一个局域网。这就是环境可控。
: hot standby主要解决availability的问题。
: 至于为什么能保证在timeout时间内ACK，你需要重新学习实时系统，我没有义务教你，
【在 T********i 的大作中提到】
: 我的两台机器在我自己的数据中心。同一个局域网。这就是环境可控。
: hot standby主要解决availability的问题。
: 至于为什么能保证在timeout时间内ACK，你需要重新学习实时系统，我没有义务教你，
f*4
92 楼
别来忽悠我。
需求分析的本质就是帮用户搞清楚他们到底要什么，顺带教育一下他们，他们的哪些要
求现阶段是不切实际的。然后你的系统出来皆大欢喜。
在天朝给政府做需求分析，从高的讲光一个行政规定，你就改变不了。从底的讲，一个
领导审批，你再好主意都靠边站。
【在 z****e 的大作中提到】
: 需求分析最常见的几个问题
: 第一，客户不知道他们需要什么
: 第二，客户有不切实际的schedule
: 第三，客户的需求总是在变化
: 所以需求工程就跟战场一样
: 战场上发生的一切，都不是按照你原先计划好的去发展
: 往往有各种异常错误发生，那么如何把这些错误和异常控制起来
: 这才是需求工程的核心价值和目的所在
: 请不要假设这一切都不存在，实际上这一切都存在
需求分析的本质就是帮用户搞清楚他们到底要什么，顺带教育一下他们，他们的哪些要
求现阶段是不切实际的。然后你的系统出来皆大欢喜。
在天朝给政府做需求分析，从高的讲光一个行政规定，你就改变不了。从底的讲，一个
领导审批，你再好主意都靠边站。
【在 z****e 的大作中提到】
: 需求分析最常见的几个问题
: 第一，客户不知道他们需要什么
: 第二，客户有不切实际的schedule
: 第三，客户的需求总是在变化
: 所以需求工程就跟战场一样
: 战场上发生的一切，都不是按照你原先计划好的去发展
: 往往有各种异常错误发生，那么如何把这些错误和异常控制起来
: 这才是需求工程的核心价值和目的所在
: 请不要假设这一切都不存在，实际上这一切都存在
z*e
93 楼
“然后你的系统出来皆大欢喜。”
这种事情曾经发生过么？
你以为给他们做网站的时候没有计划过？没有教育过？没有让他们搞清楚过？
你在想什么？
【在 f****4 的大作中提到】
: 别来忽悠我。
: 需求分析的本质就是帮用户搞清楚他们到底要什么，顺带教育一下他们，他们的哪些要
: 求现阶段是不切实际的。然后你的系统出来皆大欢喜。
: 在天朝给政府做需求分析，从高的讲光一个行政规定，你就改变不了。从底的讲，一个
: 领导审批，你再好主意都靠边站。
这种事情曾经发生过么？
你以为给他们做网站的时候没有计划过？没有教育过？没有让他们搞清楚过？
你在想什么？
【在 f****4 的大作中提到】
: 别来忽悠我。
: 需求分析的本质就是帮用户搞清楚他们到底要什么，顺带教育一下他们，他们的哪些要
: 求现阶段是不切实际的。然后你的系统出来皆大欢喜。
: 在天朝给政府做需求分析，从高的讲光一个行政规定，你就改变不了。从底的讲，一个
: 领导审批，你再好主意都靠边站。
f*4
94 楼
你就回帖，不看贴的吧？
农民工欢天喜地拿到票了，就说明银行划钱成功了。
交钱失败，农民工只能继续排队买票。
你还是正面解释一下，分布式的情况下，怎么避免1票多卖吧。
春运，一群农民工上车了发现是一个座，这不得打起来？？？
【在 z****e 的大作中提到】
: 银行要反馈给你transaction的结果你才能写log
: 要不然你写什么？搞定了，结果待定，然后直接commit？
: 农民工欢天喜地拿到票了回家了，整理衣物去了
: 下一步银行反馈，挂了，请回滚，你怎么办？
: 再去退钱？退钱一堆麻烦事要做，就算成功退钱了吧
: 农民工上车时候验票，突然发现，票没有订到？
: 你觉得农民工会怎么办？
农民工欢天喜地拿到票了，就说明银行划钱成功了。
交钱失败，农民工只能继续排队买票。
你还是正面解释一下，分布式的情况下，怎么避免1票多卖吧。
春运，一群农民工上车了发现是一个座，这不得打起来？？？
【在 z****e 的大作中提到】
: 银行要反馈给你transaction的结果你才能写log
: 要不然你写什么？搞定了，结果待定，然后直接commit？
: 农民工欢天喜地拿到票了回家了，整理衣物去了
: 下一步银行反馈，挂了，请回滚，你怎么办？
: 再去退钱？退钱一堆麻烦事要做，就算成功退钱了吧
: 农民工上车时候验票，突然发现，票没有订到？
: 你觉得农民工会怎么办？
f*4
95 楼
前提是在说卖火车票。。。
【在 g*****g 的大作中提到】
: 单机的系统跟完全scale out的分布式系统比availability和scalability，我老也没啥
: 好说了。
: 单机都能解决，还要NoSQL干啥。
: 魏老师到头来就剩我就是比你牛逼这一句。
【在 g*****g 的大作中提到】
: 单机的系统跟完全scale out的分布式系统比availability和scalability，我老也没啥
: 好说了。
: 单机都能解决，还要NoSQL干啥。
: 魏老师到头来就剩我就是比你牛逼这一句。
z*e
96 楼
你忘记了这是queue了吧？
你每一个交易都等银行划账成功之后再commit，后面怎么办？
排队等哦，银行的这个交易很磨蹭的
分布式怎么锁，看你内存怎么锁
分布式就怎么锁，一个道理
【在 f****4 的大作中提到】
: 你就回帖，不看贴的吧？
: 农民工欢天喜地拿到票了，就说明银行划钱成功了。
: 交钱失败，农民工只能继续排队买票。
: 你还是正面解释一下，分布式的情况下，怎么避免1票多卖吧。
: 春运，一群农民工上车了发现是一个座，这不得打起来？？？
你每一个交易都等银行划账成功之后再commit，后面怎么办？
排队等哦，银行的这个交易很磨蹭的
分布式怎么锁，看你内存怎么锁
分布式就怎么锁，一个道理
【在 f****4 的大作中提到】
: 你就回帖，不看贴的吧？
: 农民工欢天喜地拿到票了，就说明银行划钱成功了。
: 交钱失败，农民工只能继续排队买票。
: 你还是正面解释一下，分布式的情况下，怎么避免1票多卖吧。
: 春运，一群农民工上车了发现是一个座，这不得打起来？？？
f*4
97 楼
温州高铁之后，要是还有那个局长敢签字改变调度，我很佩服。
【在 z****e 的大作中提到】
: 最简单的一个例子
: 你这里假设
: 调度都是提前做好预案的
: 你信不信到时候一定会变？
【在 z****e 的大作中提到】
: 最简单的一个例子
: 你这里假设
: 调度都是提前做好预案的
: 你信不信到时候一定会变？
z*e
98 楼
调度每天都在改，尤其是春运期间
至少临时增开客运不要太常见
【在 f****4 的大作中提到】
: 温州高铁之后，要是还有那个局长敢签字改变调度，我很佩服。
至少临时增开客运不要太常见
【在 f****4 的大作中提到】
: 温州高铁之后，要是还有那个局长敢签字改变调度，我很佩服。
g*g
99 楼
分布式的只是web portal，前面的订单queue。到最后transaction是单机数据库处理的，
只不过单机数据库只处理一条线路一天，这就是我前面强调的分表。这个每天几万个写
，每秒一次的读，完全没压力不是。
我可没鼓吹过单机throughput，恰恰相反，我说的就是云上的VM就搞定了。
【在 f****4 的大作中提到】
: 你就回帖，不看贴的吧？
: 农民工欢天喜地拿到票了，就说明银行划钱成功了。
: 交钱失败，农民工只能继续排队买票。
: 你还是正面解释一下，分布式的情况下，怎么避免1票多卖吧。
: 春运，一群农民工上车了发现是一个座，这不得打起来？？？
只不过单机数据库只处理一条线路一天，这就是我前面强调的分表。这个每天几万个写
，每秒一次的读，完全没压力不是。
我可没鼓吹过单机throughput，恰恰相反，我说的就是云上的VM就搞定了。
【在 f****4 的大作中提到】
: 你就回帖，不看贴的吧？
: 农民工欢天喜地拿到票了，就说明银行划钱成功了。
: 交钱失败，农民工只能继续排队买票。
: 你还是正面解释一下，分布式的情况下，怎么避免1票多卖吧。
: 春运，一群农民工上车了发现是一个座，这不得打起来？？？
f*4
100 楼
你不是一直说你的是在线实时么？分布式的 -_-
我就想知道分布式的scale上去之后，数据同步能不能回避1票多卖。淘宝双11能把货卖
爆掉，就说明它没解决这个问题。
我相信你们几个做分布式的一定能解决这个问题。
【在 g*****g 的大作中提到】
: 我没一票多卖呀，我就是让随便你下单，回头给你发邮件告诉你成功没。
: 后台数据库锁到了，银行钱也刷到了，你就买着了，否则没买着。
: 这个延迟纯粹取决于银行，银行一秒处理了，你立刻就知道了。
: 量大，1秒出100万个订单，银行处理要几个小时，你就得等几个小时。
: 魏老师的那点比这个强？下单立刻跟你说买着了，你欢天喜地的，过
: 几个小时银行那边处理，发现你账号错了，再把你cancel了。那还不如
: 我刚开始不跟你说成功没。
我就想知道分布式的scale上去之后，数据同步能不能回避1票多卖。淘宝双11能把货卖
爆掉，就说明它没解决这个问题。
我相信你们几个做分布式的一定能解决这个问题。
【在 g*****g 的大作中提到】
: 我没一票多卖呀，我就是让随便你下单，回头给你发邮件告诉你成功没。
: 后台数据库锁到了，银行钱也刷到了，你就买着了，否则没买着。
: 这个延迟纯粹取决于银行，银行一秒处理了，你立刻就知道了。
: 量大，1秒出100万个订单，银行处理要几个小时，你就得等几个小时。
: 魏老师的那点比这个强？下单立刻跟你说买着了，你欢天喜地的，过
: 几个小时银行那边处理，发现你账号错了，再把你cancel了。那还不如
: 我刚开始不跟你说成功没。
f*4
101 楼
你自己都说了3zone 2region failover的方案了。。。
这个已经有了好多年
【在 g*****g 的大作中提到】
: LOL。断个电，断个网，玩完了。你懂啥分布式设计。
这个已经有了好多年
【在 g*****g 的大作中提到】
: LOL。断个电，断个网，玩完了。你懂啥分布式设计。
z*e
102 楼
分布式很难保证real time
只能说不让某些node挂掉，保证有node能响应
这就是real time了，跟单机上精确到ms的real time完全不是一回事
分布式目前还有很多问题不能解决
所以主机一直都没有被淘汰，但是要说一个随随便便的破server就能替换掉主机
这个也太扯淡了，如果能这么做，那主机就没有人用了
而实际上主机在很多大型机构里面还是有其生存的空间
【在 f****4 的大作中提到】
: 你不是一直说你的是在线实时么？分布式的 -_-
: 我就想知道分布式的scale上去之后，数据同步能不能回避1票多卖。淘宝双11能把货卖
: 爆掉，就说明它没解决这个问题。
: 我相信你们几个做分布式的一定能解决这个问题。
只能说不让某些node挂掉，保证有node能响应
这就是real time了，跟单机上精确到ms的real time完全不是一回事
分布式目前还有很多问题不能解决
所以主机一直都没有被淘汰，但是要说一个随随便便的破server就能替换掉主机
这个也太扯淡了，如果能这么做，那主机就没有人用了
而实际上主机在很多大型机构里面还是有其生存的空间
【在 f****4 的大作中提到】
: 你不是一直说你的是在线实时么？分布式的 -_-
: 我就想知道分布式的scale上去之后，数据同步能不能回避1票多卖。淘宝双11能把货卖
: 爆掉，就说明它没解决这个问题。
: 我相信你们几个做分布式的一定能解决这个问题。
f*4
103 楼
发生过，我给魔都的公安总局，教育局做的几个系统，他们满意了，公司收到尾款了，
我给小弟们额外放了几天假（和公司说在客户现场）。
【在 z****e 的大作中提到】
: “然后你的系统出来皆大欢喜。”
: 这种事情曾经发生过么？
: 你以为给他们做网站的时候没有计划过？没有教育过？没有让他们搞清楚过？
: 你在想什么？
我给小弟们额外放了几天假（和公司说在客户现场）。
【在 z****e 的大作中提到】
: “然后你的系统出来皆大欢喜。”
: 这种事情曾经发生过么？
: 你以为给他们做网站的时候没有计划过？没有教育过？没有让他们搞清楚过？
: 你在想什么？
g*g
104 楼
淘宝比较困难，因为商品多，数量大，数据也比较难划分。你不能说我一单买了电脑就
不能
买尿布。
火车票相当于几千张种商品，数目又比较有限，一个车次一天最多几千个。不是首尾相
连的还可以
让你分单下，所以可以做到。
【在 f****4 的大作中提到】
: 你不是一直说你的是在线实时么？分布式的 -_-
: 我就想知道分布式的scale上去之后，数据同步能不能回避1票多卖。淘宝双11能把货卖
: 爆掉，就说明它没解决这个问题。
: 我相信你们几个做分布式的一定能解决这个问题。
不能
买尿布。
火车票相当于几千张种商品，数目又比较有限，一个车次一天最多几千个。不是首尾相
连的还可以
让你分单下，所以可以做到。
【在 f****4 的大作中提到】
: 你不是一直说你的是在线实时么？分布式的 -_-
: 我就想知道分布式的scale上去之后，数据同步能不能回避1票多卖。淘宝双11能把货卖
: 爆掉，就说明它没解决这个问题。
: 我相信你们几个做分布式的一定能解决这个问题。
f*4
105 楼
你不看贴的习惯真不好，我都回过几次了，后面来的请求是抢不到这张票的！！！
要等啥啊？要锁啥锁啊？
【在 z****e 的大作中提到】
: 你忘记了这是queue了吧？
: 你每一个交易都等银行划账成功之后再commit，后面怎么办？
: 排队等哦，银行的这个交易很磨蹭的
: 分布式怎么锁，看你内存怎么锁
: 分布式就怎么锁，一个道理
要等啥啊？要锁啥锁啊？
【在 z****e 的大作中提到】
: 你忘记了这是queue了吧？
: 你每一个交易都等银行划账成功之后再commit，后面怎么办？
: 排队等哦，银行的这个交易很磨蹭的
: 分布式怎么锁，看你内存怎么锁
: 分布式就怎么锁，一个道理
f*4
106 楼
我已经给你解释了临时增开的客运是怎么来的了，请看贴。
【在 z****e 的大作中提到】
: 调度每天都在改，尤其是春运期间
: 至少临时增开客运不要太常见
【在 z****e 的大作中提到】
: 调度每天都在改，尤其是春运期间
: 至少临时增开客运不要太常见
T*i
107 楼
主机本来就是给人傻钱多的准备的。
【在 z****e 的大作中提到】
: 分布式很难保证real time
: 只能说不让某些node挂掉，保证有node能响应
: 这就是real time了，跟单机上精确到ms的real time完全不是一回事
: 分布式目前还有很多问题不能解决
: 所以主机一直都没有被淘汰，但是要说一个随随便便的破server就能替换掉主机
: 这个也太扯淡了，如果能这么做，那主机就没有人用了
: 而实际上主机在很多大型机构里面还是有其生存的空间
【在 z****e 的大作中提到】
: 分布式很难保证real time
: 只能说不让某些node挂掉，保证有node能响应
: 这就是real time了，跟单机上精确到ms的real time完全不是一回事
: 分布式目前还有很多问题不能解决
: 所以主机一直都没有被淘汰，但是要说一个随随便便的破server就能替换掉主机
: 这个也太扯淡了，如果能这么做，那主机就没有人用了
: 而实际上主机在很多大型机构里面还是有其生存的空间
z*e
108 楼
你这个局管的范围大过一个市没有？
【在 f****4 的大作中提到】
: 发生过，我给魔都的公安总局，教育局做的几个系统，他们满意了，公司收到尾款了，
: 我给小弟们额外放了几天假（和公司说在客户现场）。
【在 f****4 的大作中提到】
: 发生过，我给魔都的公安总局，教育局做的几个系统，他们满意了，公司收到尾款了，
: 我给小弟们额外放了几天假（和公司说在客户现场）。
z*e
109 楼
你不锁，人家凭什么不能抢？
这个票还没有划账成功，是否成功售出未知
【在 f****4 的大作中提到】
: 你不看贴的习惯真不好，我都回过几次了，后面来的请求是抢不到这张票的！！！
: 要等啥啊？要锁啥锁啊？
这个票还没有划账成功，是否成功售出未知
【在 f****4 的大作中提到】
: 你不看贴的习惯真不好，我都回过几次了，后面来的请求是抢不到这张票的！！！
: 要等啥啊？要锁啥锁啊？
g*g
110 楼
屁呀，我那个是要transaction的部分一天就几万个写，所以异地sync能做到。
他都4网卡，80GB吞吐，出了局域网没有光纤能撑住这个速度。有你也付不起这个
专线的钱。
【在 f****4 的大作中提到】
: 你自己都说了3zone 2region failover的方案了。。。
: 这个已经有了好多年
他都4网卡，80GB吞吐，出了局域网没有光纤能撑住这个速度。有你也付不起这个
专线的钱。
【在 f****4 的大作中提到】
: 你自己都说了3zone 2region failover的方案了。。。
: 这个已经有了好多年
z*e
111 楼
主机比你reliable
【在 T********i 的大作中提到】
: 主机本来就是给人傻钱多的准备的。
【在 T********i 的大作中提到】
: 主机本来就是给人傻钱多的准备的。
f*4
112 楼
老魏的方案就是你这分表的替代方案，然后代码比你的简单，需要的硬件比你的少多了。
你的方案是个通用方案，老魏的只是在卖火车票，股票的时候可以这么干。但可以这么
干的时候，比你的通用方案性能好。
的，
【在 g*****g 的大作中提到】
: 分布式的只是web portal，前面的订单queue。到最后transaction是单机数据库处理的，
: 只不过单机数据库只处理一条线路一天，这就是我前面强调的分表。这个每天几万个写
: ，每秒一次的读，完全没压力不是。
: 我可没鼓吹过单机throughput，恰恰相反，我说的就是云上的VM就搞定了。
你的方案是个通用方案，老魏的只是在卖火车票，股票的时候可以这么干。但可以这么
干的时候，比你的通用方案性能好。
的，
【在 g*****g 的大作中提到】
: 分布式的只是web portal，前面的订单queue。到最后transaction是单机数据库处理的，
: 只不过单机数据库只处理一条线路一天，这就是我前面强调的分表。这个每天几万个写
: ，每秒一次的读，完全没压力不是。
: 我可没鼓吹过单机throughput，恰恰相反，我说的就是云上的VM就搞定了。
z*e
113 楼
你就说说这个会不会发生吧
绝对不可能发生？
如果发生了你怎么办？
当没看到
【在 f****4 的大作中提到】
: 我已经给你解释了临时增开的客运是怎么来的了，请看贴。
绝对不可能发生？
如果发生了你怎么办？
当没看到
【在 f****4 的大作中提到】
: 我已经给你解释了临时增开的客运是怎么来的了，请看贴。
g*g
114 楼
对，就是订单排队。挨个处理。订单是亿万人下的，要分布式要不顶不住。处理总共就
几千张票，
单机就处理了。
【在 z****e 的大作中提到】
: 你不锁，人家凭什么不能抢？
: 这个票还没有划账成功，是否成功售出未知
几千张票，
单机就处理了。
【在 z****e 的大作中提到】
: 你不锁，人家凭什么不能抢？
: 这个票还没有划账成功，是否成功售出未知
T*i
115 楼
都是那么一坨。我的多机hot standby。凭什么上下牙一碰就说他更可靠？
【在 z****e 的大作中提到】
: 主机比你reliable
【在 z****e 的大作中提到】
: 主机比你reliable
f*4
116 楼
没错，但原方案也说了，别的地方该堆机器的堆机器，该分workload的分workload
他只是强调，卖票的情况下，单机来做高throughput，比分布式的简单。
【在 z****e 的大作中提到】
: 分布式很难保证real time
: 只能说不让某些node挂掉，保证有node能响应
: 这就是real time了，跟单机上精确到ms的real time完全不是一回事
: 分布式目前还有很多问题不能解决
: 所以主机一直都没有被淘汰，但是要说一个随随便便的破server就能替换掉主机
: 这个也太扯淡了，如果能这么做，那主机就没有人用了
: 而实际上主机在很多大型机构里面还是有其生存的空间
他只是强调，卖票的情况下，单机来做高throughput，比分布式的简单。
【在 z****e 的大作中提到】
: 分布式很难保证real time
: 只能说不让某些node挂掉，保证有node能响应
: 这就是real time了，跟单机上精确到ms的real time完全不是一回事
: 分布式目前还有很多问题不能解决
: 所以主机一直都没有被淘汰，但是要说一个随随便便的破server就能替换掉主机
: 这个也太扯淡了，如果能这么做，那主机就没有人用了
: 而实际上主机在很多大型机构里面还是有其生存的空间
g*g
117 楼
代码是比我的简单，可是断个电就玩完了。成本也比我高。他需要的这种硬件，一台就是
几百万美金。我在EC2上跑几十台机器，高峰起几千台，比他的运营成本可便宜多了。
还有，他的单机能不能承受每秒百万次的写，我很怀疑。到千万必崩无疑，所以不是
scalable的方案。
了。
【在 f****4 的大作中提到】
: 老魏的方案就是你这分表的替代方案，然后代码比你的简单，需要的硬件比你的少多了。
: 你的方案是个通用方案，老魏的只是在卖火车票，股票的时候可以这么干。但可以这么
: 干的时候，比你的通用方案性能好。
:
: 的，
几百万美金。我在EC2上跑几十台机器，高峰起几千台，比他的运营成本可便宜多了。
还有，他的单机能不能承受每秒百万次的写，我很怀疑。到千万必崩无疑，所以不是
scalable的方案。
了。
【在 f****4 的大作中提到】
: 老魏的方案就是你这分表的替代方案，然后代码比你的简单，需要的硬件比你的少多了。
: 你的方案是个通用方案，老魏的只是在卖火车票，股票的时候可以这么干。但可以这么
: 干的时候，比你的通用方案性能好。
:
: 的，
z*e
118 楼
不早就告诉过你了，十年前ejb当时就解决了
还要你来干p？
【在 T********i 的大作中提到】
: 都是那么一坨。我的多机hot standby。凭什么上下牙一碰就说他更可靠？
还要你来干p？
【在 T********i 的大作中提到】
: 都是那么一坨。我的多机hot standby。凭什么上下牙一碰就说他更可靠？
z*e
119 楼
你这个单机也不是绝对的单机
一旦涉及到其它部分，就是分布式
所以可以说是分布式里面的一个环节的单机处理
这有bird用
这就好比你告诉我说ejb容器用一到两个机器处理
so？
【在 f****4 的大作中提到】
: 没错，但原方案也说了，别的地方该堆机器的堆机器，该分workload的分workload
: 他只是强调，卖票的情况下，单机来做高throughput，比分布式的简单。
一旦涉及到其它部分，就是分布式
所以可以说是分布式里面的一个环节的单机处理
这有bird用
这就好比你告诉我说ejb容器用一到两个机器处理
so？
【在 f****4 的大作中提到】
: 没错，但原方案也说了，别的地方该堆机器的堆机器，该分workload的分workload
: 他只是强调，卖票的情况下，单机来做高throughput，比分布式的简单。
g*g
120 楼
说到系统是不是scalable，就问一个问题就行，这个系统多100倍流量还能撑得住吗？
老魏的单机数据库瞬间从百万次写上升到亿次写，必崩无疑。我说的系统，扔100倍硬
件上去
就可以了，连代码都不用改。
老魏的单机数据库瞬间从百万次写上升到亿次写，必崩无疑。我说的系统，扔100倍硬
件上去
就可以了，连代码都不用改。
f*4
121 楼
你回避了一个问题，你再分表，分单，热门的路线workload还是很大。
比如说回南方的民工买票怎么都要经过沪宁线一样。难道这样，你分表之后的db
server处理不了，还要分到座位么？？？
你这样一来，再碰上zhaoc坚持的，能动态增加车次，你这系统别上线了。。。
【在 g*****g 的大作中提到】
: 淘宝比较困难，因为商品多，数量大，数据也比较难划分。你不能说我一单买了电脑就
: 不能
: 买尿布。
: 火车票相当于几千张种商品，数目又比较有限，一个车次一天最多几千个。不是首尾相
: 连的还可以
: 让你分单下，所以可以做到。
比如说回南方的民工买票怎么都要经过沪宁线一样。难道这样，你分表之后的db
server处理不了，还要分到座位么？？？
你这样一来，再碰上zhaoc坚持的，能动态增加车次，你这系统别上线了。。。
【在 g*****g 的大作中提到】
: 淘宝比较困难，因为商品多，数量大，数据也比较难划分。你不能说我一单买了电脑就
: 不能
: 买尿布。
: 火车票相当于几千张种商品，数目又比较有限，一个车次一天最多几千个。不是首尾相
: 连的还可以
: 让你分单下，所以可以做到。
z*e
122 楼
人家主机可是登陆，验证，交易，存储一条龙服务
银行员工直接登陆主机操作
你搞个破处理环节都需要两台机器，还保证这个保证那个
真不是一般滴难伺候
顺便说一下，ejb还能passive时候持久化，不怕断电
不比你这个破烂一断电就挂了强一万倍？
银行员工直接登陆主机操作
你搞个破处理环节都需要两台机器，还保证这个保证那个
真不是一般滴难伺候
顺便说一下，ejb还能passive时候持久化，不怕断电
不比你这个破烂一断电就挂了强一万倍？
f*4
123 楼
如果你不知道到局和总局的区别，我也教不了你。。。
只能打个比方，总局就像pm，局就是se
【在 z****e 的大作中提到】
: 你这个局管的范围大过一个市没有？
只能打个比方，总局就像pm，局就是se
【在 z****e 的大作中提到】
: 你这个局管的范围大过一个市没有？
T*i
124 楼
我说过了，1万多美金一台。你凭啥给我涨价100倍？
就是
【在 g*****g 的大作中提到】
: 代码是比我的简单，可是断个电就玩完了。成本也比我高。他需要的这种硬件，一台就是
: 几百万美金。我在EC2上跑几十台机器，高峰起几千台，比他的运营成本可便宜多了。
: 还有，他的单机能不能承受每秒百万次的写，我很怀疑。到千万必崩无疑，所以不是
: scalable的方案。
:
: 了。
就是
【在 g*****g 的大作中提到】
: 代码是比我的简单，可是断个电就玩完了。成本也比我高。他需要的这种硬件，一台就是
: 几百万美金。我在EC2上跑几十台机器，高峰起几千台，比他的运营成本可便宜多了。
: 还有，他的单机能不能承受每秒百万次的写，我很怀疑。到千万必崩无疑，所以不是
: scalable的方案。
:
: 了。
z*e
125 楼
不好意思，我做过总局的系统，比你举例的强一万倍
【在 f****4 的大作中提到】
: 如果你不知道到局和总局的区别，我也教不了你。。。
: 只能打个比方，总局就像pm，局就是se
【在 f****4 的大作中提到】
: 如果你不知道到局和总局的区别，我也教不了你。。。
: 只能打个比方，总局就像pm，局就是se
f*4
126 楼
哪怕后面划钱失败，后面对进来的这个人来说，这张票是卖出去的！！！
你抢什么东西？
一直要回滚之后，这张票才能再让人抢到。
【在 z****e 的大作中提到】
: 你不锁，人家凭什么不能抢？
: 这个票还没有划账成功，是否成功售出未知
你抢什么东西？
一直要回滚之后，这张票才能再让人抢到。
【在 z****e 的大作中提到】
: 你不锁，人家凭什么不能抢？
: 这个票还没有划账成功，是否成功售出未知
z*e
127 楼
就是queue嘛，你能不能把话说得精确点
queue有一个顺序问题，你凭什么让后面的人去等？
上千万人的等待将会是怎样一番光景？
【在 f****4 的大作中提到】
: 哪怕后面划钱失败，后面对进来的这个人来说，这张票是卖出去的！！！
: 你抢什么东西？
: 一直要回滚之后，这张票才能再让人抢到。
queue有一个顺序问题，你凭什么让后面的人去等？
上千万人的等待将会是怎样一番光景？
【在 f****4 的大作中提到】
: 哪怕后面划钱失败，后面对进来的这个人来说，这张票是卖出去的！！！
: 你抢什么东西？
: 一直要回滚之后，这张票才能再让人抢到。
g*g
128 楼
你到底都没读我前面怎么说的？分到车次和天之后，就剩最多10万张票。
我整个单机数据库只需要处理10万次写和每秒一次的读。每天10万次写是处理订单的
单个进程产生的。每秒一次写是cache push update产生的。跟终端用户数目无关。
就算全世界人民都来抢，读只读cache。写只写Cassandra based MQ。这两个是完全
scale
out的。我不需要去动后台这个需要transaction的数据库。
【在 f****4 的大作中提到】
: 你回避了一个问题，你再分表，分单，热门的路线workload还是很大。
: 比如说回南方的民工买票怎么都要经过沪宁线一样。难道这样，你分表之后的db
: server处理不了，还要分到座位么？？？
: 你这样一来，再碰上zhaoc坚持的，能动态增加车次，你这系统别上线了。。。
我整个单机数据库只需要处理10万次写和每秒一次的读。每天10万次写是处理订单的
单个进程产生的。每秒一次写是cache push update产生的。跟终端用户数目无关。
就算全世界人民都来抢，读只读cache。写只写Cassandra based MQ。这两个是完全
scale
out的。我不需要去动后台这个需要transaction的数据库。
【在 f****4 的大作中提到】
: 你回避了一个问题，你再分表，分单，热门的路线workload还是很大。
: 比如说回南方的民工买票怎么都要经过沪宁线一样。难道这样，你分表之后的db
: server处理不了，还要分到座位么？？？
: 你这样一来，再碰上zhaoc坚持的，能动态增加车次，你这系统别上线了。。。
f*4
129 楼
80GB吞吐怎么异地，我没做过。
我只做过1GB的异地，并且后来换地方了，也不知道原来方案是不是修改过了。。。
【在 g*****g 的大作中提到】
: 屁呀，我那个是要transaction的部分一天就几万个写，所以异地sync能做到。
: 他都4网卡，80GB吞吐，出了局域网没有光纤能撑住这个速度。有你也付不起这个
: 专线的钱。
我只做过1GB的异地，并且后来换地方了，也不知道原来方案是不是修改过了。。。
【在 g*****g 的大作中提到】
: 屁呀，我那个是要transaction的部分一天就几万个写，所以异地sync能做到。
: 他都4网卡，80GB吞吐，出了局域网没有光纤能撑住这个速度。有你也付不起这个
: 专线的钱。
g*g
130 楼
就没有这么做的，流量多一倍，还得再扩容一次。想想都不可能。
【在 f****4 的大作中提到】
: 80GB吞吐怎么异地，我没做过。
: 我只做过1GB的异地，并且后来换地方了，也不知道原来方案是不是修改过了。。。
【在 f****4 的大作中提到】
: 80GB吞吐怎么异地，我没做过。
: 我只做过1GB的异地，并且后来换地方了，也不知道原来方案是不是修改过了。。。
f*4
131 楼
你先解释一下发生了，goodbug的分表数据库怎么处理吧。
你这是要弄死他方案的节奏啊。
【在 z****e 的大作中提到】
: 你就说说这个会不会发生吧
: 绝对不可能发生？
: 如果发生了你怎么办？
: 当没看到
你这是要弄死他方案的节奏啊。
【在 z****e 的大作中提到】
: 你就说说这个会不会发生吧
: 绝对不可能发生？
: 如果发生了你怎么办？
: 当没看到
g*g
132 楼
那就是吹牛不上税了。就跟你说写个NoSQL还能秒Cassandra一样。
【在 T********i 的大作中提到】
: 我说过了，1万多美金一台。你凭啥给我涨价100倍？
:
: 就是
【在 T********i 的大作中提到】
: 我说过了，1万多美金一台。你凭啥给我涨价100倍？
:
: 就是
z*e
133 楼
我说的是魏老师的单机系统，跟古德霸有什么关系？
我压根没有认真看古德霸的设计
【在 f****4 的大作中提到】
: 你先解释一下发生了，goodbug的分表数据库怎么处理吧。
: 你这是要弄死他方案的节奏啊。
我压根没有认真看古德霸的设计
【在 f****4 的大作中提到】
: 你先解释一下发生了，goodbug的分表数据库怎么处理吧。
: 你这是要弄死他方案的节奏啊。
T*i
134 楼
他还要增加100倍，就是8000G的吞吐，号称他的方案能scale up。
这个人东拉西扯。
【在 f****4 的大作中提到】
: 80GB吞吐怎么异地，我没做过。
: 我只做过1GB的异地，并且后来换地方了，也不知道原来方案是不是修改过了。。。
这个人东拉西扯。
【在 f****4 的大作中提到】
: 80GB吞吐怎么异地，我没做过。
: 我只做过1GB的异地，并且后来换地方了，也不知道原来方案是不是修改过了。。。
z*e
135 楼
比你这种号称单机最后却不得不搞成分布式的强一万倍
好歹人家上来就说是分布式
【在 T********i 的大作中提到】
: 他还要增加100倍，就是8000G的吞吐，号称他的方案能scale up。
: 这个人东拉西扯。
好歹人家上来就说是分布式
【在 T********i 的大作中提到】
: 他还要增加100倍，就是8000G的吞吐，号称他的方案能scale up。
: 这个人东拉西扯。
z*e
136 楼
ejb有接口很容易实现持久化服务
断电后数据可以找回来
比你这个强一万倍
【在 T********i 的大作中提到】
: 他还要增加100倍，就是8000G的吞吐，号称他的方案能scale up。
: 这个人东拉西扯。
断电后数据可以找回来
比你这个强一万倍
【在 T********i 的大作中提到】
: 他还要增加100倍，就是8000G的吞吐，号称他的方案能scale up。
: 这个人东拉西扯。
g*g
137 楼
你没弄明白为啥你的系统不公平吗？这个火车1000张票，1万个人来抢。
假定头1000个人里100个银行账户有问题。你1000张票出去了，后面9000个
都直接说没票。过了1个小时银行处理完了，这100张票才出来。能买着的
是出来之后才排队的。
我提出的系统，则保证前1100个人里账户没问题的都买着了票。这就是差距！！
【在 f****4 的大作中提到】
: 哪怕后面划钱失败，后面对进来的这个人来说，这张票是卖出去的！！！
: 你抢什么东西？
: 一直要回滚之后，这张票才能再让人抢到。
假定头1000个人里100个银行账户有问题。你1000张票出去了，后面9000个
都直接说没票。过了1个小时银行处理完了，这100张票才出来。能买着的
是出来之后才排队的。
我提出的系统，则保证前1100个人里账户没问题的都买着了票。这就是差距！！
【在 f****4 的大作中提到】
: 哪怕后面划钱失败，后面对进来的这个人来说，这张票是卖出去的！！！
: 你抢什么东西？
: 一直要回滚之后，这张票才能再让人抢到。
f*4
138 楼
你真做过high available的系统？你不知道有东西叫发电机，ups？
别笑，google也有这套东西。有公司专门提供解决方案的。
硬件，4个10G卡和相关支持我不知道价格，但5万美金能买到的90+cpu,36G服务器已经
超出他的假设很多了。。。
就是
【在 g*****g 的大作中提到】
: 代码是比我的简单，可是断个电就玩完了。成本也比我高。他需要的这种硬件，一台就是
: 几百万美金。我在EC2上跑几十台机器，高峰起几千台，比他的运营成本可便宜多了。
: 还有，他的单机能不能承受每秒百万次的写，我很怀疑。到千万必崩无疑，所以不是
: scalable的方案。
:
: 了。
别笑，google也有这套东西。有公司专门提供解决方案的。
硬件，4个10G卡和相关支持我不知道价格，但5万美金能买到的90+cpu,36G服务器已经
超出他的假设很多了。。。
就是
【在 g*****g 的大作中提到】
: 代码是比我的简单，可是断个电就玩完了。成本也比我高。他需要的这种硬件，一台就是
: 几百万美金。我在EC2上跑几十台机器，高峰起几千台，比他的运营成本可便宜多了。
: 还有，他的单机能不能承受每秒百万次的写，我很怀疑。到千万必崩无疑，所以不是
: scalable的方案。
:
: 了。
f*4
139 楼
你这个说的有点道理，hot standby 的failover的确不能算真正的单机
【在 z****e 的大作中提到】
: 你这个单机也不是绝对的单机
: 一旦涉及到其它部分，就是分布式
: 所以可以说是分布式里面的一个环节的单机处理
: 这有bird用
: 这就好比你告诉我说ejb容器用一到两个机器处理
: so？
【在 z****e 的大作中提到】
: 你这个单机也不是绝对的单机
: 一旦涉及到其它部分，就是分布式
: 所以可以说是分布式里面的一个环节的单机处理
: 这有bird用
: 这就好比你告诉我说ejb容器用一到两个机器处理
: so？
g*g
140 楼
是呀，分布式设计本来不就是这样。我设计的系统，用户读只读cache，写只写mq，多
100倍
也不怕。你的DB一下子就挂了。
【在 T********i 的大作中提到】
: 他还要增加100倍，就是8000G的吞吐，号称他的方案能scale up。
: 这个人东拉西扯。
100倍
也不怕。你的DB一下子就挂了。
【在 T********i 的大作中提到】
: 他还要增加100倍，就是8000G的吞吐，号称他的方案能scale up。
: 这个人东拉西扯。
f*4
141 楼
这是卖火车票。。。
【在 g*****g 的大作中提到】
: 说到系统是不是scalable，就问一个问题就行，这个系统多100倍流量还能撑得住吗？
: 老魏的单机数据库瞬间从百万次写上升到亿次写，必崩无疑。我说的系统，扔100倍硬
: 件上去
: 就可以了，连代码都不用改。
【在 g*****g 的大作中提到】
: 说到系统是不是scalable，就问一个问题就行，这个系统多100倍流量还能撑得住吗？
: 老魏的单机数据库瞬间从百万次写上升到亿次写，必崩无疑。我说的系统，扔100倍硬
: 件上去
: 就可以了，连代码都不用改。
f*4
142 楼
可能把，不过看起来你的客户对你可能不大满意
【在 z****e 的大作中提到】
: 不好意思，我做过总局的系统，比你举例的强一万倍
【在 z****e 的大作中提到】
: 不好意思，我做过总局的系统，比你举例的强一万倍
f*4
143 楼
是你们的方案在让后面的人等好不好
【在 z****e 的大作中提到】
: 就是queue嘛，你能不能把话说得精确点
: queue有一个顺序问题，你凭什么让后面的人去等？
: 上千万人的等待将会是怎样一番光景？
【在 z****e 的大作中提到】
: 就是queue嘛，你能不能把话说得精确点
: queue有一个顺序问题，你凭什么让后面的人去等？
: 上千万人的等待将会是怎样一番光景？
g*g
144 楼
LOL，着火的时候发电机ups有用？网络出问题的时候有用？硬件只是一部分，
数据库软件，应用服务器，都是按cpu算license fee的。我用的方案，都是开源软件。
DC要超过30%的使用的时候，才能比cloud便宜。他这东西按峰值设计，
年平均远远没有30%的使用率，自然比我的方案贵多了。
【在 f****4 的大作中提到】
: 你真做过high available的系统？你不知道有东西叫发电机，ups？
: 别笑，google也有这套东西。有公司专门提供解决方案的。
: 硬件，4个10G卡和相关支持我不知道价格，但5万美金能买到的90+cpu,36G服务器已经
: 超出他的假设很多了。。。
:
: 就是
数据库软件，应用服务器，都是按cpu算license fee的。我用的方案，都是开源软件。
DC要超过30%的使用的时候，才能比cloud便宜。他这东西按峰值设计，
年平均远远没有30%的使用率，自然比我的方案贵多了。
【在 f****4 的大作中提到】
: 你真做过high available的系统？你不知道有东西叫发电机，ups？
: 别笑，google也有这套东西。有公司专门提供解决方案的。
: 硬件，4个10G卡和相关支持我不知道价格，但5万美金能买到的90+cpu,36G服务器已经
: 超出他的假设很多了。。。
:
: 就是
f*4
145 楼
是啊，全世界人都来抢票，你就不需要对这个server再做个分布，分一下流？
就算你也是80G的网络IO一台机器也是处理不了的啊
【在 g*****g 的大作中提到】
: 你到底都没读我前面怎么说的？分到车次和天之后，就剩最多10万张票。
: 我整个单机数据库只需要处理10万次写和每秒一次的读。每天10万次写是处理订单的
: 单个进程产生的。每秒一次写是cache push update产生的。跟终端用户数目无关。
: 就算全世界人民都来抢，读只读cache。写只写Cassandra based MQ。这两个是完全
: scale
: out的。我不需要去动后台这个需要transaction的数据库。
就算你也是80G的网络IO一台机器也是处理不了的啊
【在 g*****g 的大作中提到】
: 你到底都没读我前面怎么说的？分到车次和天之后，就剩最多10万张票。
: 我整个单机数据库只需要处理10万次写和每秒一次的读。每天10万次写是处理订单的
: 单个进程产生的。每秒一次写是cache push update产生的。跟终端用户数目无关。
: 就算全世界人民都来抢，读只读cache。写只写Cassandra based MQ。这两个是完全
: scale
: out的。我不需要去动后台这个需要transaction的数据库。
g*g
146 楼
你的方案连公平都保证不了，还后面人等？
就我说的，1000个里100交易失败，你是应该拿下100排队的去交易。而不是
看谁运气好交易失败票出来的时候刚好上网。
【在 f****4 的大作中提到】
: 是你们的方案在让后面的人等好不好
就我说的，1000个里100交易失败，你是应该拿下100排队的去交易。而不是
看谁运气好交易失败票出来的时候刚好上网。
【在 f****4 的大作中提到】
: 是你们的方案在让后面的人等好不好
f*4
147 楼
-_- 我们的客户卫星已经在轨道飞了，如果做不到的话，一天要陪40万美金。
恩原来公司还没倒闭。。。
【在 g*****g 的大作中提到】
: 就没有这么做的，流量多一倍，还得再扩容一次。想想都不可能。
恩原来公司还没倒闭。。。
【在 g*****g 的大作中提到】
: 就没有这么做的，流量多一倍，还得再扩容一次。想想都不可能。
f*4
148 楼
你抢deal的时候，就没碰到过交易超时重新排队么？？？
【在 g*****g 的大作中提到】
: 你没弄明白为啥你的系统不公平吗？这个火车1000张票，1万个人来抢。
: 假定头1000个人里100个银行账户有问题。你1000张票出去了，后面9000个
: 都直接说没票。过了1个小时银行处理完了，这100张票才出来。能买着的
: 是出来之后才排队的。
: 我提出的系统，则保证前1100个人里账户没问题的都买着了票。这就是差距！！
【在 g*****g 的大作中提到】
: 你没弄明白为啥你的系统不公平吗？这个火车1000张票，1万个人来抢。
: 假定头1000个人里100个银行账户有问题。你1000张票出去了，后面9000个
: 都直接说没票。过了1个小时银行处理完了，这100张票才出来。能买着的
: 是出来之后才排队的。
: 我提出的系统，则保证前1100个人里账户没问题的都买着了票。这就是差距！！
g*g
149 楼
你们那公司做到了80GB的光纤专线，敢问成本如何？5万块还Hold住吗？
【在 f****4 的大作中提到】
: -_- 我们的客户卫星已经在轨道飞了，如果做不到的话，一天要陪40万美金。
: 恩原来公司还没倒闭。。。
【在 f****4 的大作中提到】
: -_- 我们的客户卫星已经在轨道飞了，如果做不到的话，一天要陪40万美金。
: 恩原来公司还没倒闭。。。
g*g
150 楼
我设计的这个系统，不需要。这就是它强的地方。
【在 f****4 的大作中提到】
: 你抢deal的时候，就没碰到过交易超时重新排队么？？？
【在 f****4 的大作中提到】
: 你抢deal的时候，就没碰到过交易超时重新排队么？？？
f*4
151 楼
看贴，同学，我们的要求是支持1GB
看贴啊，同学
【在 g*****g 的大作中提到】
: 你们那公司做到了80GB的光纤专线，敢问成本如何？5万块还Hold住吗？
看贴啊，同学
【在 g*****g 的大作中提到】
: 你们那公司做到了80GB的光纤专线，敢问成本如何？5万块还Hold住吗？
f*4
152 楼
LOL
淘宝amz应该都是分布式的，你看看他们做到了没
【在 g*****g 的大作中提到】
: 我设计的这个系统，不需要。这就是它强的地方。
淘宝amz应该都是分布式的，你看看他们做到了没
【在 g*****g 的大作中提到】
: 我设计的这个系统，不需要。这就是它强的地方。
f*4
153 楼
下班回家，各位，周末愉快～
g*g
154 楼
难道不是一开始就是多region的分布式的吗？我们公司的系统都是美东，美西，欧洲三
个region的跑，美东的三个zone都废了我们可以一个脚本把流量全部转移到美西。因为
我们只在美洲和欧洲有业务。假定其他大陆都有DC。多100倍也就多加点机器就可以了。
【在 f****4 的大作中提到】
: 是啊，全世界人都来抢票，你就不需要对这个server再做个分布，分一下流？
: 就算你也是80G的网络IO一台机器也是处理不了的啊
个region的跑，美东的三个zone都废了我们可以一个脚本把流量全部转移到美西。因为
我们只在美洲和欧洲有业务。假定其他大陆都有DC。多100倍也就多加点机器就可以了。
【在 f****4 的大作中提到】
: 是啊，全世界人都来抢票，你就不需要对这个server再做个分布，分一下流？
: 就算你也是80G的网络IO一台机器也是处理不了的啊
g*g
155 楼
你1GB魏老师不够用呀，他需要80GB的。再说你那1GB的专用光纤，一年使用成本要多少
钱？
【在 f****4 的大作中提到】
: 看贴，同学，我们的要求是支持1GB
: 看贴啊，同学
钱？
【在 f****4 的大作中提到】
: 看贴，同学，我们的要求是支持1GB
: 看贴啊，同学
g*g
156 楼
我前面说到淘宝东西多，数量多，不好分库。火车票总共预售几十天，总共几千种，每
种几千张。这差了至少两个数量级了。
你全世界人民来抢票，也只是订单增多，票没增多吧，所以不影响后台处理系统。做架
构最最重要的就是要懂得
分析数据呀。像魏老师那样把订票系统往stock exchange上套，我是没法说。
【在 f****4 的大作中提到】
: LOL
: 淘宝amz应该都是分布式的，你看看他们做到了没
种几千张。这差了至少两个数量级了。
你全世界人民来抢票，也只是订单增多，票没增多吧，所以不影响后台处理系统。做架
构最最重要的就是要懂得
分析数据呀。像魏老师那样把订票系统往stock exchange上套，我是没法说。
【在 f****4 的大作中提到】
: LOL
: 淘宝amz应该都是分布式的，你看看他们做到了没
z*e
157 楼
我当年就是总局的人
可不是什么客户
【在 f****4 的大作中提到】
: 可能把，不过看起来你的客户对你可能不大满意
可不是什么客户
【在 f****4 的大作中提到】
: 可能把，不过看起来你的客户对你可能不大满意
z*e
158 楼
那你还想先commit后退票吗？
你知道这里面会卷入多少不必要的麻烦么？
甚至连基建都会跟不上
【在 f****4 的大作中提到】
: 是你们的方案在让后面的人等好不好
你知道这里面会卷入多少不必要的麻烦么？
甚至连基建都会跟不上
【在 f****4 的大作中提到】
: 是你们的方案在让后面的人等好不好
z*e
159 楼
数据源本身就是分散的
怎么可能做到单机一条龙服务？
钱肯定在银行的，票肯定在铁道部的
这两个一定不会变成一个单机系统
这里面怎么优化都会有这样那样的问题
要正视这些问题，这些都是系统的一部分，都会让系统挂掉
而实际上那次出事让系统挂掉的就是web，而不是什么app server
app server又没事，优化什么？为什么要换楼主来做？
app server很少出事，我就没遇到过有app server撑不住的时候
除了静态页面web server，就数app server最健壮了，除非搞科学计算
否则不需要单独处理app server，机票没有什么太过于复杂的科学计算
而且一般太复杂的科学计算也不会放在app server上做，放到hpc上去算的概率更大
一般都是web或者persistence出事
动态页面server以及db都是常出事的地方
当然这对于楼主来说，那都是别人的事
【在 f****4 的大作中提到】
: 你这个说的有点道理，hot standby 的failover的确不能算真正的单机
怎么可能做到单机一条龙服务？
钱肯定在银行的，票肯定在铁道部的
这两个一定不会变成一个单机系统
这里面怎么优化都会有这样那样的问题
要正视这些问题，这些都是系统的一部分，都会让系统挂掉
而实际上那次出事让系统挂掉的就是web，而不是什么app server
app server又没事，优化什么？为什么要换楼主来做？
app server很少出事，我就没遇到过有app server撑不住的时候
除了静态页面web server，就数app server最健壮了，除非搞科学计算
否则不需要单独处理app server，机票没有什么太过于复杂的科学计算
而且一般太复杂的科学计算也不会放在app server上做，放到hpc上去算的概率更大
一般都是web或者persistence出事
动态页面server以及db都是常出事的地方
当然这对于楼主来说，那都是别人的事
【在 f****4 的大作中提到】
: 你这个说的有点道理，hot standby 的failover的确不能算真正的单机
h*a
160 楼
基本同意你说的。其实魏老师的设计还是不错的。不过这里是考虑到了春运火车这个具
体的case下系统的throughput是有一定的上限的。对于大部分的互联网应用，在设计的
时候往往是为了处理无穷大的scale（呵呵）所以出发点可能会有不同。
另外从availability的角度，互联网的应用往往考虑用commodity hardware，假设硬件
随时会fail。魏老师的设计对核心机器的availability和性能的要求很高，这也是一个
比较大的区别。
我也觉得学到了一些东西。是不错的讨论。
【在 f****4 的大作中提到】
: 你又离题了。
: 魏老师这对卖春运车票给了个针对性的方案，不是普通意义上的互联网应用。
: 你给的只是个互联网应用的通用方案，但完全没有根据春运车票的特性进行优化。
: 就因为车票实际上是有限的（和股票一样）才能这么干。淘宝，amz完全不适用。
:
: stock
体的case下系统的throughput是有一定的上限的。对于大部分的互联网应用，在设计的
时候往往是为了处理无穷大的scale（呵呵）所以出发点可能会有不同。
另外从availability的角度，互联网的应用往往考虑用commodity hardware，假设硬件
随时会fail。魏老师的设计对核心机器的availability和性能的要求很高，这也是一个
比较大的区别。
我也觉得学到了一些东西。是不错的讨论。
【在 f****4 的大作中提到】
: 你又离题了。
: 魏老师这对卖春运车票给了个针对性的方案，不是普通意义上的互联网应用。
: 你给的只是个互联网应用的通用方案，但完全没有根据春运车票的特性进行优化。
: 就因为车票实际上是有限的（和股票一样）才能这么干。淘宝，amz完全不适用。
:
: stock
h*a
161 楼
不错，availability确实是他的设计中的一个缺陷。一个地震或者恐怖袭击估计就不能
卖票了。否则多数据中心的主机进行同步也是一个难解的问题。
所谓
他的
【在 g*****g 的大作中提到】
: 前面说完了维护余票的数据库，以及后台处理订单的模块。这里再说说订单系统。
: 我一开始就说commit log + 离线订单。订单产生之后怎么处理我说完了，
: 现在说产生订单的部分。我提到订单系统就是个基于commit log的message queue，
: 同样是可以根据车次和天划分的。
: 我之所以提commit log，是因为有很多现成的实现。commit log这块就是魏老师嘴里所谓
: 的高throughput单机DB。但他对诸多现成的NoSQL实现完全没有概念。而且我很肯定他的
: 谈到的系统在throughput上远逊于Cassandra。他的DB有瓶颈，我的设计没有，是完全
: scale out的。懂得Cassandra的都知道原理，就是根据hash在集群上找到对应的结点写
: 。魏老师写的是1个结点，Cassandra写的可以是几百个个结点的集群。为了提高可靠性
: 和availablity，可以用常见的replication factor 3和quorum写。也就是每个数据有
卖票了。否则多数据中心的主机进行同步也是一个难解的问题。
所谓
他的
【在 g*****g 的大作中提到】
: 前面说完了维护余票的数据库，以及后台处理订单的模块。这里再说说订单系统。
: 我一开始就说commit log + 离线订单。订单产生之后怎么处理我说完了，
: 现在说产生订单的部分。我提到订单系统就是个基于commit log的message queue，
: 同样是可以根据车次和天划分的。
: 我之所以提commit log，是因为有很多现成的实现。commit log这块就是魏老师嘴里所谓
: 的高throughput单机DB。但他对诸多现成的NoSQL实现完全没有概念。而且我很肯定他的
: 谈到的系统在throughput上远逊于Cassandra。他的DB有瓶颈，我的设计没有，是完全
: scale out的。懂得Cassandra的都知道原理，就是根据hash在集群上找到对应的结点写
: 。魏老师写的是1个结点，Cassandra写的可以是几百个个结点的集群。为了提高可靠性
: 和availablity，可以用常见的replication factor 3和quorum写。也就是每个数据有
h*a
162 楼
我觉得关键对于火车票这个具体的问题，他假设系统的最大处理峰值可以有一定的上限
，在这个前提下这个设计是有意义的。对于淘宝和很多互联网应用来说，这种设计的缺
陷也比较明显。
【在 g*****g 的大作中提到】
: 单机的系统跟完全scale out的分布式系统比availability和scalability，我老也没啥
: 好说了。
: 单机都能解决，还要NoSQL干啥。
: 魏老师到头来就剩我就是比你牛逼这一句。
，在这个前提下这个设计是有意义的。对于淘宝和很多互联网应用来说，这种设计的缺
陷也比较明显。
【在 g*****g 的大作中提到】
: 单机的系统跟完全scale out的分布式系统比availability和scalability，我老也没啥
: 好说了。
: 单机都能解决，还要NoSQL干啥。
: 魏老师到头来就剩我就是比你牛逼这一句。
t*t
163 楼
真不容易, 这么多天总算有个有意义的讨论, 虽然中间夹杂了一些谩骂, 不过总算不是
清水
【在 h*****a 的大作中提到】
: 基本同意你说的。其实魏老师的设计还是不错的。不过这里是考虑到了春运火车这个具
: 体的case下系统的throughput是有一定的上限的。对于大部分的互联网应用，在设计的
: 时候往往是为了处理无穷大的scale（呵呵）所以出发点可能会有不同。
: 另外从availability的角度，互联网的应用往往考虑用commodity hardware，假设硬件
: 随时会fail。魏老师的设计对核心机器的availability和性能的要求很高，这也是一个
: 比较大的区别。
: 我也觉得学到了一些东西。是不错的讨论。
清水
【在 h*****a 的大作中提到】
: 基本同意你说的。其实魏老师的设计还是不错的。不过这里是考虑到了春运火车这个具
: 体的case下系统的throughput是有一定的上限的。对于大部分的互联网应用，在设计的
: 时候往往是为了处理无穷大的scale（呵呵）所以出发点可能会有不同。
: 另外从availability的角度，互联网的应用往往考虑用commodity hardware，假设硬件
: 随时会fail。魏老师的设计对核心机器的availability和性能的要求很高，这也是一个
: 比较大的区别。
: 我也觉得学到了一些东西。是不错的讨论。
k*e
164 楼
小白看了1小时以后，表示：完全没有看懂。大帽子满天飞，看得心惊胆战，觉得自己
真是弱毙了。。。。
真是弱毙了。。。。
z*e
165 楼
就是某人跳出来说，我一台server可以搞定核心问题
然后这台server没有做到的东西，都是民工做的事，交给其他民工去处理
我这台server解决了最核心最关键的问题
结果p都没解决，因为出问题的压根不是这块，所以很多人上来第一个回帖就是
做这个干什么？这个又没有问题，但是某人死活不承认这块没有问题
算了半天，死咬这块就是有问题，系统其他出问题的地方一律不予讨论
于是小菊花就问：一碗泡面倒下去，就挂了，于是某人赶紧说
要hot standby，尼玛，这还是单机么？
于是又改口说，其实不是单机，但是可以实现1－2ms内响应
于是别人又问，那如果实现不了呢？要保证能实现
然后继续问，那怎么跟金钱交易挂上钩？
金钱交易怎么可能跟票本身的处理在同一台机器上？
魏老师大怒，你的水平太差了，我没有义务教育你
【在 k********e 的大作中提到】
: 小白看了1小时以后，表示：完全没有看懂。大帽子满天飞，看得心惊胆战，觉得自己
: 真是弱毙了。。。。
然后这台server没有做到的东西，都是民工做的事，交给其他民工去处理
我这台server解决了最核心最关键的问题
结果p都没解决，因为出问题的压根不是这块，所以很多人上来第一个回帖就是
做这个干什么？这个又没有问题，但是某人死活不承认这块没有问题
算了半天，死咬这块就是有问题，系统其他出问题的地方一律不予讨论
于是小菊花就问：一碗泡面倒下去，就挂了，于是某人赶紧说
要hot standby，尼玛，这还是单机么？
于是又改口说，其实不是单机，但是可以实现1－2ms内响应
于是别人又问，那如果实现不了呢？要保证能实现
然后继续问，那怎么跟金钱交易挂上钩？
金钱交易怎么可能跟票本身的处理在同一台机器上？
魏老师大怒，你的水平太差了，我没有义务教育你
【在 k********e 的大作中提到】
: 小白看了1小时以后，表示：完全没有看懂。大帽子满天飞，看得心惊胆战，觉得自己
: 真是弱毙了。。。。
n*w
166 楼
cqrs,
database replicated to many read-only servers, caching,
database replicated to many read-only servers, caching,
g*g
167 楼
魏老师说写个比 Cassandra强的数据库没社么难度。考虑到 mongo 风投5亿。魏老师想
退休是分分钟的事。
【在 z****e 的大作中提到】
: 就是某人跳出来说，我一台server可以搞定核心问题
: 然后这台server没有做到的东西，都是民工做的事，交给其他民工去处理
: 我这台server解决了最核心最关键的问题
: 结果p都没解决，因为出问题的压根不是这块，所以很多人上来第一个回帖就是
: 做这个干什么？这个又没有问题，但是某人死活不承认这块没有问题
: 算了半天，死咬这块就是有问题，系统其他出问题的地方一律不予讨论
: 于是小菊花就问：一碗泡面倒下去，就挂了，于是某人赶紧说
: 要hot standby，尼玛，这还是单机么？
: 于是又改口说，其实不是单机，但是可以实现1－2ms内响应
: 于是别人又问，那如果实现不了呢？要保证能实现
退休是分分钟的事。
【在 z****e 的大作中提到】
: 就是某人跳出来说，我一台server可以搞定核心问题
: 然后这台server没有做到的东西，都是民工做的事，交给其他民工去处理
: 我这台server解决了最核心最关键的问题
: 结果p都没解决，因为出问题的压根不是这块，所以很多人上来第一个回帖就是
: 做这个干什么？这个又没有问题，但是某人死活不承认这块没有问题
: 算了半天，死咬这块就是有问题，系统其他出问题的地方一律不予讨论
: 于是小菊花就问：一碗泡面倒下去，就挂了，于是某人赶紧说
: 要hot standby，尼玛，这还是单机么？
: 于是又改口说，其实不是单机，但是可以实现1－2ms内响应
: 于是别人又问，那如果实现不了呢？要保证能实现
k*i
168 楼
老魏的春运设计思路，切中刚需，化繁为简，高效低耗，是工程师解决实际问题的典范。
Goodbug的通用方案，更强调elastically scale out和location high availability。
Goodbug的通用方案，更强调elastically scale out和location high availability。
z*e
169 楼
我觉得这里的人背景不一样
很多人是完全没有相关行业的从业经验，就瞎说
就像楼主总是把这种系统比作股票交易一样
两个完全不同的行业，数据格式要求精度以及来源什么都不一样
如果死搬经验就是邯郸学步
而我总是把火车票的买卖跟飞机票的买卖做比较
因为我相信，飞机票跟火车票的买卖是类似的
股票的交易还有web公司平台，都不是一回事
因为数据格式不一样，要求也不一样，差别很大
所以最好的办法就是参考飞机票的买卖，而不是淘宝等web公司
也不是股票交易市场的系统
如果真想做这个系统，最先应该做的是了解一下现有火车票的数据格式是什么样子的
而不是假设这个数据格式应该是某一种格式
就这么大的系统而言，在短时间内
往往是连最简单的数据格式的转换都几乎是个不可能完成的任务
更不要说重新构建一个有向图，再读到内存中去了
【在 h*****a 的大作中提到】
: 我觉得关键对于火车票这个具体的问题，他假设系统的最大处理峰值可以有一定的上限
: ，在这个前提下这个设计是有意义的。对于淘宝和很多互联网应用来说，这种设计的缺
: 陷也比较明显。
很多人是完全没有相关行业的从业经验，就瞎说
就像楼主总是把这种系统比作股票交易一样
两个完全不同的行业，数据格式要求精度以及来源什么都不一样
如果死搬经验就是邯郸学步
而我总是把火车票的买卖跟飞机票的买卖做比较
因为我相信，飞机票跟火车票的买卖是类似的
股票的交易还有web公司平台，都不是一回事
因为数据格式不一样，要求也不一样，差别很大
所以最好的办法就是参考飞机票的买卖，而不是淘宝等web公司
也不是股票交易市场的系统
如果真想做这个系统，最先应该做的是了解一下现有火车票的数据格式是什么样子的
而不是假设这个数据格式应该是某一种格式
就这么大的系统而言，在短时间内
往往是连最简单的数据格式的转换都几乎是个不可能完成的任务
更不要说重新构建一个有向图，再读到内存中去了
【在 h*****a 的大作中提到】
: 我觉得关键对于火车票这个具体的问题，他假设系统的最大处理峰值可以有一定的上限
: ，在这个前提下这个设计是有意义的。对于淘宝和很多互联网应用来说，这种设计的缺
: 陷也比较明显。
z*e
170 楼
一般做过大系统的人，对于现实复杂度怀有一种畏惧之心
因为知道现实生活中，往往一个很简单的东西
经过历史的演变之后，会变得很复杂，各种关联关系，看都看不懂
哪怕是你有能力，动手去改，都会引发很多莫名其妙的，你想都想不到的
触发一个五年十年甚至二十年以前埋下的逻辑炸弹
导致生产事故，最后导致某些人卷铺盖滚蛋
所以什么不测试就下放生产，一个人搞定这么大系统
这种一听就是搞笑的，直接转学术版没有任何问题
因为知道现实生活中，往往一个很简单的东西
经过历史的演变之后，会变得很复杂，各种关联关系，看都看不懂
哪怕是你有能力，动手去改，都会引发很多莫名其妙的，你想都想不到的
触发一个五年十年甚至二十年以前埋下的逻辑炸弹
导致生产事故，最后导致某些人卷铺盖滚蛋
所以什么不测试就下放生产，一个人搞定这么大系统
这种一听就是搞笑的，直接转学术版没有任何问题
P*l
171 楼
fzz妥协了, 又改成了一张票随便卖. 谁先付完钱就给谁. 如果这样实现, 对于热门线
路来讲, >80%的银行交易都得失败. 适当的超卖是不错的, 比如120%, 以防有些用户动
作太慢影响整体的效率. 但是不能太离谱. 比如说, 一张票最多最多可以放到两个购物
车里, 那个先check out的就先拿到票. 那个因为checkout晚没有那到票的, 就需要事
先讲好几种解决方式: 1)拿另外同车次的票, 2)roll back, 重新排队. 如果和银行有
特殊接口,就有更多选择.
【在 f****4 的大作中提到】
: 从网上购物的角度讲，你的这个设计就是决定：下单的时候，能不能把东西放到
: shopping cart里面。车票放到购物车之后，同一张票就不能再给别人放购物车了。
: 网页上显示有票不代表你能放到购物车里面。checkout这个过程才是和银行，出票相关
: 的。只要在给定时间之内不能checkout成功，票就回滚回去了。
: 就算票回滚回去了，从这张票进入购物车到出购物车的时间段，这张票是不能再卖给别
: 人的。
: 因为你的主机是高throughput的，所以所有抢票的动作都在这上面实现。不会出现分布
: 式的数据同步问题，也就不会出现一票多卖的现象。
: 放到购物车和checkout分开之后，checkout这块就可以用分布式的，堆机器实现。当然
: 了，整个网站的访问，还是需要堆机器来支持的。
路来讲, >80%的银行交易都得失败. 适当的超卖是不错的, 比如120%, 以防有些用户动
作太慢影响整体的效率. 但是不能太离谱. 比如说, 一张票最多最多可以放到两个购物
车里, 那个先check out的就先拿到票. 那个因为checkout晚没有那到票的, 就需要事
先讲好几种解决方式: 1)拿另外同车次的票, 2)roll back, 重新排队. 如果和银行有
特殊接口,就有更多选择.
【在 f****4 的大作中提到】
: 从网上购物的角度讲，你的这个设计就是决定：下单的时候，能不能把东西放到
: shopping cart里面。车票放到购物车之后，同一张票就不能再给别人放购物车了。
: 网页上显示有票不代表你能放到购物车里面。checkout这个过程才是和银行，出票相关
: 的。只要在给定时间之内不能checkout成功，票就回滚回去了。
: 就算票回滚回去了，从这张票进入购物车到出购物车的时间段，这张票是不能再卖给别
: 人的。
: 因为你的主机是高throughput的，所以所有抢票的动作都在这上面实现。不会出现分布
: 式的数据同步问题，也就不会出现一票多卖的现象。
: 放到购物车和checkout分开之后，checkout这块就可以用分布式的，堆机器实现。当然
: 了，整个网站的访问，还是需要堆机器来支持的。
P*l
172 楼
魏老师说的数据依赖性是存在的,并且还不小. 比如, 我买一张票, 出发和到达都不是
起始站和终点站. 那这张票就要涉及更多的结点参与计算.
所有的结点这时候都很忙. 这时候划分得太细就成了缺点, 产生了不必要的流量和
transaction.
魏老师的方案的牛逼支出在于充分挖掘硬件的潜力. 他说用UDP协议, 本身效率就很好.
如果每个请求只占几百个字节, 一个包还可以放好几个请求. 加上单机存储所有的票
的状态, 效率是非常高的.
两个方案需要综合一下.
了。
【在 g*****g 的大作中提到】
: 综上所述，我提出的系统在high availability上比魏老师的强得太多。是多zone, 多
: region的冗余系统。另一方面，完全的多region还可以使得流量区域化，从而减少
: latency。
: 另外，我提出的全套方案是没有瓶颈的，不像魏老师的系统DB要是撑不住了，就没辙了。
: 还有一个巨大的好处，就是不需要牛逼大机器，只要云上就能跑。从而可以利用云上动
: 态分配的特点，根据压力分配机器，从而极大节省成本。火车票系统，一年就是春运和
: 几个长假压力特别大，其余时间流量很低。
起始站和终点站. 那这张票就要涉及更多的结点参与计算.
所有的结点这时候都很忙. 这时候划分得太细就成了缺点, 产生了不必要的流量和
transaction.
魏老师的方案的牛逼支出在于充分挖掘硬件的潜力. 他说用UDP协议, 本身效率就很好.
如果每个请求只占几百个字节, 一个包还可以放好几个请求. 加上单机存储所有的票
的状态, 效率是非常高的.
两个方案需要综合一下.
了。
【在 g*****g 的大作中提到】
: 综上所述，我提出的系统在high availability上比魏老师的强得太多。是多zone, 多
: region的冗余系统。另一方面，完全的多region还可以使得流量区域化，从而减少
: latency。
: 另外，我提出的全套方案是没有瓶颈的，不像魏老师的系统DB要是撑不住了，就没辙了。
: 还有一个巨大的好处，就是不需要牛逼大机器，只要云上就能跑。从而可以利用云上动
: 态分配的特点，根据压力分配机器，从而极大节省成本。火车票系统，一年就是春运和
: 几个长假压力特别大，其余时间流量很低。
P*l
173 楼
Cassandra那点玩意儿做一个比他快1-2个数量级的也没问题。
^^^ 吹牛不上税. 你当别人都是傻子.
单机当然没有availability的保证. 如果这个都不承认就没有讨论的基础了.
scalability也有问题. 就事说事,火车票行的通,不代表这种方式就解决了scalability
的问题.
换更牛逼的大机器(单机)不算.
s。
【在 T********i 的大作中提到】
: 说了这么多你还是没抓住重点。
: 我的系统也是NoSQL。Cassandra那点玩意儿做一个比他快1-2个数量级的也没问题。
: 我说的是一个不能分布的应用。只比单机性能。
: 现实中有很多这样的例子，春运算一个，股票和金融交易算一个，还有很多。将来甚至
: 淘宝之类的很多商品也有可能有这样的特性。
: 换句话说，分布到最小的granularity也就这样了。这种情况下衡量性能就是一个Gb/s。
: 再换句话说，你那些东西我的系统都能做，scalability和availability。你用那个
: Cassandra做个NASDAQ交易系统给我看看？
:
: 所谓
^^^ 吹牛不上税. 你当别人都是傻子.
单机当然没有availability的保证. 如果这个都不承认就没有讨论的基础了.
scalability也有问题. 就事说事,火车票行的通,不代表这种方式就解决了scalability
的问题.
换更牛逼的大机器(单机)不算.
s。
【在 T********i 的大作中提到】
: 说了这么多你还是没抓住重点。
: 我的系统也是NoSQL。Cassandra那点玩意儿做一个比他快1-2个数量级的也没问题。
: 我说的是一个不能分布的应用。只比单机性能。
: 现实中有很多这样的例子，春运算一个，股票和金融交易算一个，还有很多。将来甚至
: 淘宝之类的很多商品也有可能有这样的特性。
: 换句话说，分布到最小的granularity也就这样了。这种情况下衡量性能就是一个Gb/s。
: 再换句话说，你那些东西我的系统都能做，scalability和availability。你用那个
: Cassandra做个NASDAQ交易系统给我看看？
:
: 所谓
P*l
174 楼
mark.
【在 T********i 的大作中提到】
: 这就是你的问题。
【在 T********i 的大作中提到】
: 这就是你的问题。
P*l
175 楼
系统的价钱不一样.
如果你这样设计, 根本没人买. 岂不可惜?
证券交易所为什么不卖火车票?
【在 T********i 的大作中提到】
: 你这不是扯淡么？
: stock exchange没有high availability，linear scalability？
: stock exchange能够支持持续的每秒上百万的transaction。这种流量你这辈子都没机
: 会做。
: 你还是先证明你的分布式春运数据库性能比我的单机的好再说吧。
如果你这样设计, 根本没人买. 岂不可惜?
证券交易所为什么不卖火车票?
【在 T********i 的大作中提到】
: 你这不是扯淡么？
: stock exchange没有high availability，linear scalability？
: stock exchange能够支持持续的每秒上百万的transaction。这种流量你这辈子都没机
: 会做。
: 你还是先证明你的分布式春运数据库性能比我的单机的好再说吧。
P*l
176 楼
每张票都唯一对应/找到一个锁.
【在 f****4 的大作中提到】
: 那你就麻烦再解释一件事情，你的抢票是怎么实现的。
: 能不能避免一票多卖的情况？老魏的可以！
:
: 了。
【在 f****4 的大作中提到】
: 那你就麻烦再解释一件事情，你的抢票是怎么实现的。
: 能不能避免一票多卖的情况？老魏的可以！
:
: 了。
m*l
177 楼
支持你
好虫是根据自己经验做的,不是针对春运做的,
其他人都是打酱油的. 没有啥货
【在 T********i 的大作中提到】
: 你忽略的是什么？
: 你根本没搞清楚春运系统的难点：
: 1. 全国一盘棋。任意两点任意方向都有需求
: 2. 读写要同时优化，写数据可能只有那么几亿条。读请求会多几十上百倍。很多人一
: 直刷屏。
: 3. 瞬时负载。要做好在几十分钟内每秒几十万上百万请求的准备。
: 4. 动态规划，要兼顾用户优化和全局优化。比如某路段最抢手，但是还要考虑经过这
: 个路段的其他长途旅客。
: 你的那个数据库怎么应付瞬时激增的请求？
: 我的设计，就是我的核心取代你的数据库和cache，以及transaction manager。
好虫是根据自己经验做的,不是针对春运做的,
其他人都是打酱油的. 没有啥货
【在 T********i 的大作中提到】
: 你忽略的是什么？
: 你根本没搞清楚春运系统的难点：
: 1. 全国一盘棋。任意两点任意方向都有需求
: 2. 读写要同时优化，写数据可能只有那么几亿条。读请求会多几十上百倍。很多人一
: 直刷屏。
: 3. 瞬时负载。要做好在几十分钟内每秒几十万上百万请求的准备。
: 4. 动态规划，要兼顾用户优化和全局优化。比如某路段最抢手，但是还要考虑经过这
: 个路段的其他长途旅客。
: 你的那个数据库怎么应付瞬时激增的请求？
: 我的设计，就是我的核心取代你的数据库和cache，以及transaction manager。
z*e
178 楼
我叉，都没想到丫居然还用了无状态的网络协议
牛逼到死，丢个包怎么办？
再完美的网络都会存在丢包现象
这家伙居然用了udp，我服了
看来都是把涉及到金钱的交易当网游来做了
好.
【在 P********l 的大作中提到】
: 魏老师说的数据依赖性是存在的,并且还不小. 比如, 我买一张票, 出发和到达都不是
: 起始站和终点站. 那这张票就要涉及更多的结点参与计算.
: 所有的结点这时候都很忙. 这时候划分得太细就成了缺点, 产生了不必要的流量和
: transaction.
: 魏老师的方案的牛逼支出在于充分挖掘硬件的潜力. 他说用UDP协议, 本身效率就很好.
: 如果每个请求只占几百个字节, 一个包还可以放好几个请求. 加上单机存储所有的票
: 的状态, 效率是非常高的.
: 两个方案需要综合一下.
:
: 了。
牛逼到死，丢个包怎么办？
再完美的网络都会存在丢包现象
这家伙居然用了udp，我服了
看来都是把涉及到金钱的交易当网游来做了
好.
【在 P********l 的大作中提到】
: 魏老师说的数据依赖性是存在的,并且还不小. 比如, 我买一张票, 出发和到达都不是
: 起始站和终点站. 那这张票就要涉及更多的结点参与计算.
: 所有的结点这时候都很忙. 这时候划分得太细就成了缺点, 产生了不必要的流量和
: transaction.
: 魏老师的方案的牛逼支出在于充分挖掘硬件的潜力. 他说用UDP协议, 本身效率就很好.
: 如果每个请求只占几百个字节, 一个包还可以放好几个请求. 加上单机存储所有的票
: 的状态, 效率是非常高的.
: 两个方案需要综合一下.
:
: 了。
s*o
179 楼
scale-up vs scale-out?
好虫跟魏老师合作一把整合一下也许能做出一个很好的系统来。赚钱了别忘了回来给看
热闹的发包子
好虫跟魏老师合作一把整合一下也许能做出一个很好的系统来。赚钱了别忘了回来给看
热闹的发包子
z*e
180 楼
scale up最合理的做法就是主机
魏老师没有想过主机，也没有想过分布式
他只想到如何省钱，而实际上他省不了钱
因为容灾系统太烂，很容易让他赔得倾家荡产
完全不是一个做稳定系统的人，更适合搞赌博系统
去抢单，抢不到拉倒，比如做一个山寨的插件
去抢铁道部的票，这种合适，也很接近他自己说的，给nasdaq送单
但是反过来，做票务数据的提供商，不适合
他也没有做过nasdaq股票平台的经验
【在 s***o 的大作中提到】
: scale-up vs scale-out?
: 好虫跟魏老师合作一把整合一下也许能做出一个很好的系统来。赚钱了别忘了回来给看
: 热闹的发包子
魏老师没有想过主机，也没有想过分布式
他只想到如何省钱，而实际上他省不了钱
因为容灾系统太烂，很容易让他赔得倾家荡产
完全不是一个做稳定系统的人，更适合搞赌博系统
去抢单，抢不到拉倒，比如做一个山寨的插件
去抢铁道部的票，这种合适，也很接近他自己说的，给nasdaq送单
但是反过来，做票务数据的提供商，不适合
他也没有做过nasdaq股票平台的经验
【在 s***o 的大作中提到】
: scale-up vs scale-out?
: 好虫跟魏老师合作一把整合一下也许能做出一个很好的系统来。赚钱了别忘了回来给看
: 热闹的发包子
P*l
181 楼
udp是无连接,不是无状态.
如果控制请求的字节长度. tcp的功能与udp相比就成了累赘. 剩下的丢包和重复可以在
application里解决.
魏老师对现有的系统效率不高很愤怒.
你对别人不遵守你的知识很愤怒.
【在 z****e 的大作中提到】
: 我叉，都没想到丫居然还用了无状态的网络协议
: 牛逼到死，丢个包怎么办？
: 再完美的网络都会存在丢包现象
: 这家伙居然用了udp，我服了
: 看来都是把涉及到金钱的交易当网游来做了
:
: 好.
如果控制请求的字节长度. tcp的功能与udp相比就成了累赘. 剩下的丢包和重复可以在
application里解决.
魏老师对现有的系统效率不高很愤怒.
你对别人不遵守你的知识很愤怒.
【在 z****e 的大作中提到】
: 我叉，都没想到丫居然还用了无状态的网络协议
: 牛逼到死，丢个包怎么办？
: 再完美的网络都会存在丢包现象
: 这家伙居然用了udp，我服了
: 看来都是把涉及到金钱的交易当网游来做了
:
: 好.
g*g
182 楼
我说的这个是通用设计，基本上任何卖东西的网站到了最大规模都这么做。
淘宝那套系统稍微改改卖火车票是绝对没问题的。光棍节流量比春运订票可是大多了。
我设计的架构好处是灵活性好。我把数据分到了每天每车次，最后每个后台余票数据库
只需要
处理每天几万次的写。经验上说，多一千倍也能撑得住。所以所有车次按天分可能已经
够了。
只不过在性能测试确保能撑得住之前，我不会那么做而已。
我说的分布式架构做个Prototype, 测试，发现性能远远超过需求，再简化架构容易。
像他那样单机系统，要拼命优化
才有可能撑得住要求的流量。临近上马，需求改了，导致流量增加100%，项目立马挂了。
我老做架构，从来追求scale out，这个会有最大的灵活性，流量比预想得小，无非就
是少弄点硬件得事。
不能scale out, 就只有走买大机器一条路，硬件价格指数上升，而且是有上限的。
淘宝是买了最大的机器跑oracle还撑不住，还被迫走分布式这一套。好歹人的流量是几
年慢慢上来的，
有时间改系统。春运系统这东西，一上来如果撑不住，今年算了等明年？
【在 m*******l 的大作中提到】
: 支持你
: 好虫是根据自己经验做的,不是针对春运做的,
: 其他人都是打酱油的. 没有啥货
淘宝那套系统稍微改改卖火车票是绝对没问题的。光棍节流量比春运订票可是大多了。
我设计的架构好处是灵活性好。我把数据分到了每天每车次，最后每个后台余票数据库
只需要
处理每天几万次的写。经验上说，多一千倍也能撑得住。所以所有车次按天分可能已经
够了。
只不过在性能测试确保能撑得住之前，我不会那么做而已。
我说的分布式架构做个Prototype, 测试，发现性能远远超过需求，再简化架构容易。
像他那样单机系统，要拼命优化
才有可能撑得住要求的流量。临近上马，需求改了，导致流量增加100%，项目立马挂了。
我老做架构，从来追求scale out，这个会有最大的灵活性，流量比预想得小，无非就
是少弄点硬件得事。
不能scale out, 就只有走买大机器一条路，硬件价格指数上升，而且是有上限的。
淘宝是买了最大的机器跑oracle还撑不住，还被迫走分布式这一套。好歹人的流量是几
年慢慢上来的，
有时间改系统。春运系统这东西，一上来如果撑不住，今年算了等明年？
【在 m*******l 的大作中提到】
: 支持你
: 好虫是根据自己经验做的,不是针对春运做的,
: 其他人都是打酱油的. 没有啥货
g*g
183 楼
利用udp可以做到可靠， 但这是靠aplication layer ack来做到的。
现成的实现有jgroups之类。可惜魏老师就知道吹，号称整个系统一两万行。光
他说的这udp可靠传输，一两万行就出去了。
【在 P********l 的大作中提到】
: udp是无连接,不是无状态.
: 如果控制请求的字节长度. tcp的功能与udp相比就成了累赘. 剩下的丢包和重复可以在
: application里解决.
: 魏老师对现有的系统效率不高很愤怒.
: 你对别人不遵守你的知识很愤怒.
现成的实现有jgroups之类。可惜魏老师就知道吹，号称整个系统一两万行。光
他说的这udp可靠传输，一两万行就出去了。
【在 P********l 的大作中提到】
: udp是无连接,不是无状态.
: 如果控制请求的字节长度. tcp的功能与udp相比就成了累赘. 剩下的丢包和重复可以在
: application里解决.
: 魏老师对现有的系统效率不高很愤怒.
: 你对别人不遵守你的知识很愤怒.
P*l
184 楼
re.
魏老师的设计里, 如果哪一项指标刚好到极限, 项目交付时候发现超过了设计, 登时就
SB了. 不是大大增加了预算就是healthcare.gov了.
了。
【在 g*****g 的大作中提到】
: 我说的这个是通用设计，基本上任何卖东西的网站到了最大规模都这么做。
: 淘宝那套系统稍微改改卖火车票是绝对没问题的。光棍节流量比春运订票可是大多了。
: 我设计的架构好处是灵活性好。我把数据分到了每天每车次，最后每个后台余票数据库
: 只需要
: 处理每天几万次的写。经验上说，多一千倍也能撑得住。所以所有车次按天分可能已经
: 够了。
: 只不过在性能测试确保能撑得住之前，我不会那么做而已。
: 我说的分布式架构做个Prototype, 测试，发现性能远远超过需求，再简化架构容易。
: 像他那样单机系统，要拼命优化
: 才有可能撑得住要求的流量。临近上马，需求改了，导致流量增加100%，项目立马挂了。
魏老师的设计里, 如果哪一项指标刚好到极限, 项目交付时候发现超过了设计, 登时就
SB了. 不是大大增加了预算就是healthcare.gov了.
了。
【在 g*****g 的大作中提到】
: 我说的这个是通用设计，基本上任何卖东西的网站到了最大规模都这么做。
: 淘宝那套系统稍微改改卖火车票是绝对没问题的。光棍节流量比春运订票可是大多了。
: 我设计的架构好处是灵活性好。我把数据分到了每天每车次，最后每个后台余票数据库
: 只需要
: 处理每天几万次的写。经验上说，多一千倍也能撑得住。所以所有车次按天分可能已经
: 够了。
: 只不过在性能测试确保能撑得住之前，我不会那么做而已。
: 我说的分布式架构做个Prototype, 测试，发现性能远远超过需求，再简化架构容易。
: 像他那样单机系统，要拼命优化
: 才有可能撑得住要求的流量。临近上马，需求改了，导致流量增加100%，项目立马挂了。
N*n
185 楼
你那套系统是生搬硬套, SCALE OUT设计是想当然，分库设计只有当每个人只
需买一个车次时才有用，但实际需并非如此。一个东北民工从南方回家，一
张通票下去京广、京哈的车次都要买。把京广、京哈的车次分库有啥用？一
个TRANSACTION下来俩库还得JOINT处理。SCALE OUT就告吹了。这样分库这会
变成DISTRIBUTED TRANSACTION，效率比单机还差。分库变成搬石头砸自己脚。
需求从一开始就告诉你了，“全国一盘棋。任意两点任意方向都有需求”，
全国不是任意两点之间都有直通车，通票转车不可避免，怎么分库？铁路之
所以叫网就是串在一起的，哪有那么容易随便划几块就分了。
【在 g*****g 的大作中提到】
: 我说的这个是通用设计，基本上任何卖东西的网站到了最大规模都这么做。
: 淘宝那套系统稍微改改卖火车票是绝对没问题的。光棍节流量比春运订票可是大多了。
: 我设计的架构好处是灵活性好。我把数据分到了每天每车次，最后每个后台余票数据库
: 只需要
: 处理每天几万次的写。经验上说，多一千倍也能撑得住。所以所有车次按天分可能已经
: 够了。
: 只不过在性能测试确保能撑得住之前，我不会那么做而已。
: 我说的分布式架构做个Prototype, 测试，发现性能远远超过需求，再简化架构容易。
: 像他那样单机系统，要拼命优化
: 才有可能撑得住要求的流量。临近上马，需求改了，导致流量增加100%，项目立马挂了。
g*g
186 楼
这个问题我当然考虑了，我说的是一个极端分库的情况。具体怎么分，当然要看商业逻
辑。
比如北京到上海，和西安到新疆的线路，肯定不用在一个库里。另外，我设计的系统余量
很大，一天才几万个写，多一千倍也能处理。自然是可以把一些线路放一块的。
只要你限制联程的长度，就能限制distribution transaction的比例。一个合理的分库
并不需要
完全杜绝distributed transaction, 只要保证比例低，不会造成瓶颈就行了。需要
distributed transaction
的这个地方是后台处理票务的，也没什么low latency的要求。
具体怎么分，一个常见的做法就是把历史数据拿出来，做聚合就是了。比如说分成几十
个库，
跨库的交易不超过10%，足以。其他的做法还有诸如分票，90%预留给直达，10%预留给
转车，
直达部分还是可以完美分。转车的库把所有车次放在一起。一边用完了再重新分配。
总之分库本身是很有学问的。没有具体数据我只能给一些常见的做法，但无论怎么做总比
无脑断定不能分强多了。
【在 N********n 的大作中提到】
:
: 你那套系统是生搬硬套, SCALE OUT设计是想当然，分库设计只有当每个人只
: 需买一个车次时才有用，但实际需并非如此。一个东北民工从南方回家，一
: 张通票下去京广、京哈的车次都要买。把京广、京哈的车次分库有啥用？一
: 个TRANSACTION下来俩库还得JOINT处理。SCALE OUT就告吹了。这样分库这会
: 变成DISTRIBUTED TRANSACTION，效率比单机还差。分库变成搬石头砸自己脚。
: 需求从一开始就告诉你了，“全国一盘棋。任意两点任意方向都有需求”，
: 全国不是任意两点之间都有直通车，通票转车不可避免，怎么分库？铁路之
: 所以叫网就是串在一起的，哪有那么容易随便划几块就分了。
辑。
比如北京到上海，和西安到新疆的线路，肯定不用在一个库里。另外，我设计的系统余量
很大，一天才几万个写，多一千倍也能处理。自然是可以把一些线路放一块的。
只要你限制联程的长度，就能限制distribution transaction的比例。一个合理的分库
并不需要
完全杜绝distributed transaction, 只要保证比例低，不会造成瓶颈就行了。需要
distributed transaction
的这个地方是后台处理票务的，也没什么low latency的要求。
具体怎么分，一个常见的做法就是把历史数据拿出来，做聚合就是了。比如说分成几十
个库，
跨库的交易不超过10%，足以。其他的做法还有诸如分票，90%预留给直达，10%预留给
转车，
直达部分还是可以完美分。转车的库把所有车次放在一起。一边用完了再重新分配。
总之分库本身是很有学问的。没有具体数据我只能给一些常见的做法，但无论怎么做总比
无脑断定不能分强多了。
【在 N********n 的大作中提到】
:
: 你那套系统是生搬硬套, SCALE OUT设计是想当然，分库设计只有当每个人只
: 需买一个车次时才有用，但实际需并非如此。一个东北民工从南方回家，一
: 张通票下去京广、京哈的车次都要买。把京广、京哈的车次分库有啥用？一
: 个TRANSACTION下来俩库还得JOINT处理。SCALE OUT就告吹了。这样分库这会
: 变成DISTRIBUTED TRANSACTION，效率比单机还差。分库变成搬石头砸自己脚。
: 需求从一开始就告诉你了，“全国一盘棋。任意两点任意方向都有需求”，
: 全国不是任意两点之间都有直通车，通票转车不可避免，怎么分库？铁路之
: 所以叫网就是串在一起的，哪有那么容易随便划几块就分了。
z*e
187 楼
如果你什么都要自己去实现的话，来得及么？
春运可不能推迟哦，为什么不直接上tcp泥？会差多少？
现有系统效率不高没有什么奇怪的
现实是不完美的
again，什么问题都是别人的问题
【在 P********l 的大作中提到】
: udp是无连接,不是无状态.
: 如果控制请求的字节长度. tcp的功能与udp相比就成了累赘. 剩下的丢包和重复可以在
: application里解决.
: 魏老师对现有的系统效率不高很愤怒.
: 你对别人不遵守你的知识很愤怒.
春运可不能推迟哦，为什么不直接上tcp泥？会差多少？
现有系统效率不高没有什么奇怪的
现实是不完美的
again，什么问题都是别人的问题
【在 P********l 的大作中提到】
: udp是无连接,不是无状态.
: 如果控制请求的字节长度. tcp的功能与udp相比就成了累赘. 剩下的丢包和重复可以在
: application里解决.
: 魏老师对现有的系统效率不高很愤怒.
: 你对别人不遵守你的知识很愤怒.
g*g
188 楼
魏老师不就是这样吗？他吹了半天的所谓核心log db系统，cassandra已经实现了，还
带cluster 支持。
他用c++写一个，latency可能能低一些，throughput肯定是被cassandra cluster秒的
。我要他那个东西干啥。
所以到头来没办法了，就只好拍胸脯我写一个能秒cassandra, 反正吹牛不上税。
【在 z****e 的大作中提到】
: 如果你什么都要自己去实现的话，来得及么？
: 春运可不能推迟哦，为什么不直接上tcp泥？会差多少？
: 现有系统效率不高没有什么奇怪的
: 现实是不完美的
: again，什么问题都是别人的问题
带cluster 支持。
他用c++写一个，latency可能能低一些，throughput肯定是被cassandra cluster秒的
。我要他那个东西干啥。
所以到头来没办法了，就只好拍胸脯我写一个能秒cassandra, 反正吹牛不上税。
【在 z****e 的大作中提到】
: 如果你什么都要自己去实现的话，来得及么？
: 春运可不能推迟哦，为什么不直接上tcp泥？会差多少？
: 现有系统效率不高没有什么奇怪的
: 现实是不完美的
: again，什么问题都是别人的问题
P*l
189 楼
打岔.
你说呢? 你不是搞游戏的吗?
搞错. 如果什么都不在乎,那你还讨论什么劲?
这才叫哭了半天不知到谁死了.
不是我说的.
【在 z****e 的大作中提到】
: 如果你什么都要自己去实现的话，来得及么？
: 春运可不能推迟哦，为什么不直接上tcp泥？会差多少？
: 现有系统效率不高没有什么奇怪的
: 现实是不完美的
: again，什么问题都是别人的问题
b*s
190 楼
我觉得做多了系统集成严重损害一个软工自己造轮子的能力
思路已经坏死了
【在 f****4 的大作中提到】
: 不是没看懂，而是不愿意看人家怎么说的吧？
: 其实对这样不同行业的讨论讨论，比起讨论语言有意义多了。
: 用硬实时的multicast log的ack来检测硬件错误，这个之前没用过。
思路已经坏死了
【在 f****4 的大作中提到】
: 不是没看懂，而是不愿意看人家怎么说的吧？
: 其实对这样不同行业的讨论讨论，比起讨论语言有意义多了。
: 用硬实时的multicast log的ack来检测硬件错误，这个之前没用过。
z*e
191 楼
我觉得直接上tcp就好了
我不是搞游戏的，我是搞网络的
游戏是我自己搞来玩的
所以这些协议反而是我的主业
我认为不上tcp基本上属于自找麻烦
那点节省么有必要
udp替换tcp理论上可以节省latency，而不是提高throughput
但是差错率会增加，要额外处理，没有必要
就像古德霸说的，人家魏老师只打算写2万行代码
不够的
【在 P********l 的大作中提到】
:
: 打岔.
: 你说呢? 你不是搞游戏的吗?
: 搞错. 如果什么都不在乎,那你还讨论什么劲?
: 这才叫哭了半天不知到谁死了.
: 不是我说的.
我不是搞游戏的，我是搞网络的
游戏是我自己搞来玩的
所以这些协议反而是我的主业
我认为不上tcp基本上属于自找麻烦
那点节省么有必要
udp替换tcp理论上可以节省latency，而不是提高throughput
但是差错率会增加，要额外处理，没有必要
就像古德霸说的，人家魏老师只打算写2万行代码
不够的
【在 P********l 的大作中提到】
:
: 打岔.
: 你说呢? 你不是搞游戏的吗?
: 搞错. 如果什么都不在乎,那你还讨论什么劲?
: 这才叫哭了半天不知到谁死了.
: 不是我说的.
z*e
192 楼
可以自己做，问题在于别人为什么要相信你做的会比别人做的要好呢？
【在 b*******s 的大作中提到】
: 我觉得做多了系统集成严重损害一个软工自己造轮子的能力
: 思路已经坏死了
【在 b*******s 的大作中提到】
: 我觉得做多了系统集成严重损害一个软工自己造轮子的能力
: 思路已经坏死了
P*l
193 楼
假设点环境: 北京有个单机,存全国的票的状态. 状态包括(票,状态,更新时间). 上海,
郑州,广州有其他三个单机, 和北京每分钟都要同步一次 (incremental, broadcast).
四个城市都可以卖票, 但是只有北京可以最终更新票的状态. (三个只读,一个写)
北京和其他三个城市的数据量很大. 这个io应该是瓶颈(?). 这时候如何有效利用带宽
就有意义了.
如果用tcp的话,协议里有三次握手: 这个没有必要,比较浪费. 还有流量控制: 这个应
该在application里实现. 比如,上海说:(票1,定),北京本来就要回一个(票1,好),上海
再给一个确认. 这时候流量也可以由北京通过application协议控制. 差错控制: 本来
只有一个包, 没有顺序的问题. 所以在这个特定的环境下, 也许udp要好一点. 肯定有
情况没考虑到, 但是效率应该要好一点 (20%?).
【在 z****e 的大作中提到】
: 我觉得直接上tcp就好了
: 我不是搞游戏的，我是搞网络的
: 游戏是我自己搞来玩的
: 所以这些协议反而是我的主业
: 我认为不上tcp基本上属于自找麻烦
: 那点节省么有必要
: udp替换tcp理论上可以节省latency，而不是提高throughput
: 但是差错率会增加，要额外处理，没有必要
: 就像古德霸说的，人家魏老师只打算写2万行代码
: 不够的
郑州,广州有其他三个单机, 和北京每分钟都要同步一次 (incremental, broadcast).
四个城市都可以卖票, 但是只有北京可以最终更新票的状态. (三个只读,一个写)
北京和其他三个城市的数据量很大. 这个io应该是瓶颈(?). 这时候如何有效利用带宽
就有意义了.
如果用tcp的话,协议里有三次握手: 这个没有必要,比较浪费. 还有流量控制: 这个应
该在application里实现. 比如,上海说:(票1,定),北京本来就要回一个(票1,好),上海
再给一个确认. 这时候流量也可以由北京通过application协议控制. 差错控制: 本来
只有一个包, 没有顺序的问题. 所以在这个特定的环境下, 也许udp要好一点. 肯定有
情况没考虑到, 但是效率应该要好一点 (20%?).
【在 z****e 的大作中提到】
: 我觉得直接上tcp就好了
: 我不是搞游戏的，我是搞网络的
: 游戏是我自己搞来玩的
: 所以这些协议反而是我的主业
: 我认为不上tcp基本上属于自找麻烦
: 那点节省么有必要
: udp替换tcp理论上可以节省latency，而不是提高throughput
: 但是差错率会增加，要额外处理，没有必要
: 就像古德霸说的，人家魏老师只打算写2万行代码
: 不够的
z*e
194 楼
安了，铁道部机房肯定能搞定带宽的啦
这个小意思，遇到这种大事，电信部门肯定不敢跟铁道部对抗的
省这个就没有必要了，民航售票的机房都是电信专线接入
带宽本身肯定没有问题，出问题的是web server
web server撑不住，基本上每一个请求到能到达web server
但是web server处理不过来，apache静态页面上限一般是4000个并发访问
而且用的还是动态页面，所以挂了
海,
.
【在 P********l 的大作中提到】
: 假设点环境: 北京有个单机,存全国的票的状态. 状态包括(票,状态,更新时间). 上海,
: 郑州,广州有其他三个单机, 和北京每分钟都要同步一次 (incremental, broadcast).
: 四个城市都可以卖票, 但是只有北京可以最终更新票的状态. (三个只读,一个写)
: 北京和其他三个城市的数据量很大. 这个io应该是瓶颈(?). 这时候如何有效利用带宽
: 就有意义了.
: 如果用tcp的话,协议里有三次握手: 这个没有必要,比较浪费. 还有流量控制: 这个应
: 该在application里实现. 比如,上海说:(票1,定),北京本来就要回一个(票1,好),上海
: 再给一个确认. 这时候流量也可以由北京通过application协议控制. 差错控制: 本来
: 只有一个包, 没有顺序的问题. 所以在这个特定的环境下, 也许udp要好一点. 肯定有
: 情况没考虑到, 但是效率应该要好一点 (20%?).
这个小意思，遇到这种大事，电信部门肯定不敢跟铁道部对抗的
省这个就没有必要了，民航售票的机房都是电信专线接入
带宽本身肯定没有问题，出问题的是web server
web server撑不住，基本上每一个请求到能到达web server
但是web server处理不过来，apache静态页面上限一般是4000个并发访问
而且用的还是动态页面，所以挂了
海,
.
【在 P********l 的大作中提到】
: 假设点环境: 北京有个单机,存全国的票的状态. 状态包括(票,状态,更新时间). 上海,
: 郑州,广州有其他三个单机, 和北京每分钟都要同步一次 (incremental, broadcast).
: 四个城市都可以卖票, 但是只有北京可以最终更新票的状态. (三个只读,一个写)
: 北京和其他三个城市的数据量很大. 这个io应该是瓶颈(?). 这时候如何有效利用带宽
: 就有意义了.
: 如果用tcp的话,协议里有三次握手: 这个没有必要,比较浪费. 还有流量控制: 这个应
: 该在application里实现. 比如,上海说:(票1,定),北京本来就要回一个(票1,好),上海
: 再给一个确认. 这时候流量也可以由北京通过application协议控制. 差错控制: 本来
: 只有一个包, 没有顺序的问题. 所以在这个特定的环境下, 也许udp要好一点. 肯定有
: 情况没考虑到, 但是效率应该要好一点 (20%?).
g*g
195 楼
没有足够好的轮子的时候可以造轮子。有足够好的轮子了，那不是吃饱了撑的吗？
【在 b*******s 的大作中提到】
: 我觉得做多了系统集成严重损害一个软工自己造轮子的能力
: 思路已经坏死了
【在 b*******s 的大作中提到】
: 我觉得做多了系统集成严重损害一个软工自己造轮子的能力
: 思路已经坏死了
k*i
196 楼
replication factor 3和quorum写，写了两个replicas然后return write failure了怎
么办？Retry和write-ahead log有什么问题？改为写所有replicas原理上和魏老师的有
什么区别？
所谓
他的
【在 g*****g 的大作中提到】
: 前面说完了维护余票的数据库，以及后台处理订单的模块。这里再说说订单系统。
: 我一开始就说commit log + 离线订单。订单产生之后怎么处理我说完了，
: 现在说产生订单的部分。我提到订单系统就是个基于commit log的message queue，
: 同样是可以根据车次和天划分的。
: 我之所以提commit log，是因为有很多现成的实现。commit log这块就是魏老师嘴里所谓
: 的高throughput单机DB。但他对诸多现成的NoSQL实现完全没有概念。而且我很肯定他的
: 谈到的系统在throughput上远逊于Cassandra。他的DB有瓶颈，我的设计没有，是完全
: scale out的。懂得Cassandra的都知道原理，就是根据hash在集群上找到对应的结点写
: 。魏老师写的是1个结点，Cassandra写的可以是几百个个结点的集群。为了提高可靠性
: 和availablity，可以用常见的replication factor 3和quorum写。也就是每个数据有
么办？Retry和write-ahead log有什么问题？改为写所有replicas原理上和魏老师的有
什么区别？
所谓
他的
【在 g*****g 的大作中提到】
: 前面说完了维护余票的数据库，以及后台处理订单的模块。这里再说说订单系统。
: 我一开始就说commit log + 离线订单。订单产生之后怎么处理我说完了，
: 现在说产生订单的部分。我提到订单系统就是个基于commit log的message queue，
: 同样是可以根据车次和天划分的。
: 我之所以提commit log，是因为有很多现成的实现。commit log这块就是魏老师嘴里所谓
: 的高throughput单机DB。但他对诸多现成的NoSQL实现完全没有概念。而且我很肯定他的
: 谈到的系统在throughput上远逊于Cassandra。他的DB有瓶颈，我的设计没有，是完全
: scale out的。懂得Cassandra的都知道原理，就是根据hash在集群上找到对应的结点写
: 。魏老师写的是1个结点，Cassandra写的可以是几百个个结点的集群。为了提高可靠性
: 和availablity，可以用常见的replication factor 3和quorum写。也就是每个数据有
g*g
197 楼
如果你不熟悉Cassandra的话，最大的区别是这是在一个很大的cluster上挑两个结点写
，这样不同的写请求可以写到不同的机器上。比如一个10个结点的cluster，跟他一单
机+standby，就可以达到5倍的throughput。因为瓶颈在磁盘IO上。
【在 k****i 的大作中提到】
: replication factor 3和quorum写，写了两个replicas然后return write failure了怎
: 么办？Retry和write-ahead log有什么问题？改为写所有replicas原理上和魏老师的有
: 什么区别？
:
: 所谓
: 他的
，这样不同的写请求可以写到不同的机器上。比如一个10个结点的cluster，跟他一单
机+standby，就可以达到5倍的throughput。因为瓶颈在磁盘IO上。
【在 k****i 的大作中提到】
: replication factor 3和quorum写，写了两个replicas然后return write failure了怎
: 么办？Retry和write-ahead log有什么问题？改为写所有replicas原理上和魏老师的有
: 什么区别？
:
: 所谓
: 他的
h*e
198 楼
why do u need encoding/decoding? OUCH is binary protocol.
besides, the 50 microseconds will be dominated by network traffic time, only
small protion is ur stack. any kernel by-pass system can do this.
engine
【在 T********i 的大作中提到】
: 他们做的谈不上完美。但是绝对不是你想象的那么糟糕。
: 人家的系统运行了这么多年，经历了flash crash的大流量的挑战。
: 我一个单子送到NASDAQ，一般大约50微秒后ACK就到了。
: 注意是50微秒，不是毫秒。微秒是毫秒的1/1000。这是一个round trip，包括两次
: message encoding和两次message decoding，两次send和两次recv。还有match engine
: 记账完成。报价送到book上，同时市场数据的更新也已经发送出去了。
: 这种系统不是本版某些人能想象的。用他们手头的技术，绝对做不出来。
besides, the 50 microseconds will be dominated by network traffic time, only
small protion is ur stack. any kernel by-pass system can do this.
engine
【在 T********i 的大作中提到】
: 他们做的谈不上完美。但是绝对不是你想象的那么糟糕。
: 人家的系统运行了这么多年，经历了flash crash的大流量的挑战。
: 我一个单子送到NASDAQ，一般大约50微秒后ACK就到了。
: 注意是50微秒，不是毫秒。微秒是毫秒的1/1000。这是一个round trip，包括两次
: message encoding和两次message decoding，两次send和两次recv。还有match engine
: 记账完成。报价送到book上，同时市场数据的更新也已经发送出去了。
: 这种系统不是本版某些人能想象的。用他们手头的技术，绝对做不出来。
k*i
199 楼
你知道挑两个节点写有可能成功写进一个节点然后返回错误，但写入的数据最终被复制
到各个节点吧？
对这种需要ACID的系统，我认为Nosql并不是最好的选择。实际上是把问题推到了
application层实现如consistency, referential integrity等。
Devil is in the detail. 很多人张嘴就说这些都不是问题但真要做起来这些才是难点。
【在 g*****g 的大作中提到】
: 如果你不熟悉Cassandra的话，最大的区别是这是在一个很大的cluster上挑两个结点写
: ，这样不同的写请求可以写到不同的机器上。比如一个10个结点的cluster，跟他一单
: 机+standby，就可以达到5倍的throughput。因为瓶颈在磁盘IO上。
到各个节点吧？
对这种需要ACID的系统，我认为Nosql并不是最好的选择。实际上是把问题推到了
application层实现如consistency, referential integrity等。
Devil is in the detail. 很多人张嘴就说这些都不是问题但真要做起来这些才是难点。
【在 g*****g 的大作中提到】
: 如果你不熟悉Cassandra的话，最大的区别是这是在一个很大的cluster上挑两个结点写
: ，这样不同的写请求可以写到不同的机器上。比如一个10个结点的cluster，跟他一单
: 机+standby，就可以达到5倍的throughput。因为瓶颈在磁盘IO上。
z*e
200 楼
对，魏老师就是缺这个常识
【在 k****i 的大作中提到】
: 你知道挑两个节点写有可能成功写进一个节点然后返回错误，但写入的数据最终被复制
: 到各个节点吧？
: 对这种需要ACID的系统，我认为Nosql并不是最好的选择。实际上是把问题推到了
: application层实现如consistency, referential integrity等。
: Devil is in the detail. 很多人张嘴就说这些都不是问题但真要做起来这些才是难点。
【在 k****i 的大作中提到】
: 你知道挑两个节点写有可能成功写进一个节点然后返回错误，但写入的数据最终被复制
: 到各个节点吧？
: 对这种需要ACID的系统，我认为Nosql并不是最好的选择。实际上是把问题推到了
: application层实现如consistency, referential integrity等。
: Devil is in the detail. 很多人张嘴就说这些都不是问题但真要做起来这些才是难点。
g*g
201 楼
你说的不对，出问题是写两个结点都成功了，在ack之前网络出错了。client以为没写
，数据库写进去了。这个是可能的，但你要考虑个概率问题。不同结点在不同的zone里
，独立的网络。3个网络你要坏掉俩(app server到db server连接)，才会出错。这个在
server出现概率基本可以忽略不计。一个春运出现个位数false negative到头了。
再看出这种错的impact，就是你以为没买上，过20分钟通知你买上了。或者你买重了，
又不是不让你退票。当这种错出得极少，根本不是个问题。换句话说，你不希望几十几
百万订单出错，但整个春运几个订单出错，屁大的事。
啥是影响大的部分，刷了两次钱，卖了一次票。那个不行，就算出一两次影响也很不好。
所以出票的部分是传统数据库控制的。
点。
【在 k****i 的大作中提到】
: 你知道挑两个节点写有可能成功写进一个节点然后返回错误，但写入的数据最终被复制
: 到各个节点吧？
: 对这种需要ACID的系统，我认为Nosql并不是最好的选择。实际上是把问题推到了
: application层实现如consistency, referential integrity等。
: Devil is in the detail. 很多人张嘴就说这些都不是问题但真要做起来这些才是难点。
，数据库写进去了。这个是可能的，但你要考虑个概率问题。不同结点在不同的zone里
，独立的网络。3个网络你要坏掉俩(app server到db server连接)，才会出错。这个在
server出现概率基本可以忽略不计。一个春运出现个位数false negative到头了。
再看出这种错的impact，就是你以为没买上，过20分钟通知你买上了。或者你买重了，
又不是不让你退票。当这种错出得极少，根本不是个问题。换句话说，你不希望几十几
百万订单出错，但整个春运几个订单出错，屁大的事。
啥是影响大的部分，刷了两次钱，卖了一次票。那个不行，就算出一两次影响也很不好。
所以出票的部分是传统数据库控制的。
点。
【在 k****i 的大作中提到】
: 你知道挑两个节点写有可能成功写进一个节点然后返回错误，但写入的数据最终被复制
: 到各个节点吧？
: 对这种需要ACID的系统，我认为Nosql并不是最好的选择。实际上是把问题推到了
: application层实现如consistency, referential integrity等。
: Devil is in the detail. 很多人张嘴就说这些都不是问题但真要做起来这些才是难点。
w*z
202 楼
Also Cassandra writes are sequential writes (it's like commit log), very
fast.
【在 g*****g 的大作中提到】
: 如果你不熟悉Cassandra的话，最大的区别是这是在一个很大的cluster上挑两个结点写
: ，这样不同的写请求可以写到不同的机器上。比如一个10个结点的cluster，跟他一单
: 机+standby，就可以达到5倍的throughput。因为瓶颈在磁盘IO上。
fast.
【在 g*****g 的大作中提到】
: 如果你不熟悉Cassandra的话，最大的区别是这是在一个很大的cluster上挑两个结点写
: ，这样不同的写请求可以写到不同的机器上。比如一个10个结点的cluster，跟他一单
: 机+standby，就可以达到5倍的throughput。因为瓶颈在磁盘IO上。
w*z
203 楼
C* returns true to client if you are able to write 2 replicates. In case the
last one fail, C* will handle that for you. It will resolve it at read time
, given the fact you are reading also quorum. It will also do the read
repair, and you run node repair to make the data "eventual consistent"
So read quorum + write quorum give you the strong consistency.
【在 k****i 的大作中提到】
: replication factor 3和quorum写，写了两个replicas然后return write failure了怎
: 么办？Retry和write-ahead log有什么问题？改为写所有replicas原理上和魏老师的有
: 什么区别？
:
: 所谓
: 他的
last one fail, C* will handle that for you. It will resolve it at read time
, given the fact you are reading also quorum. It will also do the read
repair, and you run node repair to make the data "eventual consistent"
So read quorum + write quorum give you the strong consistency.
【在 k****i 的大作中提到】
: replication factor 3和quorum写，写了两个replicas然后return write failure了怎
: 么办？Retry和write-ahead log有什么问题？改为写所有replicas原理上和魏老师的有
: 什么区别？
:
: 所谓
: 他的
g*g
204 楼
False negative can happen when you write 2 nodes successfully, and network
between app server and db server is down before ack. But we all know how
unlikely that can be, particularly when I design it with 3 zones failover,
each zone has independent network.
the
time
【在 w**z 的大作中提到】
: C* returns true to client if you are able to write 2 replicates. In case the
: last one fail, C* will handle that for you. It will resolve it at read time
: , given the fact you are reading also quorum. It will also do the read
: repair, and you run node repair to make the data "eventual consistent"
: So read quorum + write quorum give you the strong consistency.
between app server and db server is down before ack. But we all know how
unlikely that can be, particularly when I design it with 3 zones failover,
each zone has independent network.
the
time
【在 w**z 的大作中提到】
: C* returns true to client if you are able to write 2 replicates. In case the
: last one fail, C* will handle that for you. It will resolve it at read time
: , given the fact you are reading also quorum. It will also do the read
: repair, and you run node repair to make the data "eventual consistent"
: So read quorum + write quorum give you the strong consistency.
w*z
205 楼
In this case, client has to retry.
点。
【在 k****i 的大作中提到】
: 你知道挑两个节点写有可能成功写进一个节点然后返回错误，但写入的数据最终被复制
: 到各个节点吧？
: 对这种需要ACID的系统，我认为Nosql并不是最好的选择。实际上是把问题推到了
: application层实现如consistency, referential integrity等。
: Devil is in the detail. 很多人张嘴就说这些都不是问题但真要做起来这些才是难点。
点。
【在 k****i 的大作中提到】
: 你知道挑两个节点写有可能成功写进一个节点然后返回错误，但写入的数据最终被复制
: 到各个节点吧？
: 对这种需要ACID的系统，我认为Nosql并不是最好的选择。实际上是把问题推到了
: application层实现如consistency, referential integrity等。
: Devil is in the detail. 很多人张嘴就说这些都不是问题但真要做起来这些才是难点。
g*g
206 楼
Also my design didn't need to update counter. That's one subtle difference
but it will result in 10+ times performance difference.
but it will result in 10+ times performance difference.
w*z
207 楼
that is certainly possible. Almost all high level C* clients do retry when
it fails.
【在 g*****g 的大作中提到】
: False negative can happen when you write 2 nodes successfully, and network
: between app server and db server is down before ack. But we all know how
: unlikely that can be, particularly when I design it with 3 zones failover,
: each zone has independent network.
:
: the
: time
it fails.
【在 g*****g 的大作中提到】
: False negative can happen when you write 2 nodes successfully, and network
: between app server and db server is down before ack. But we all know how
: unlikely that can be, particularly when I design it with 3 zones failover,
: each zone has independent network.
:
: the
: time
g*g
208 楼
Thank you for reminding me that. Since the primary key is from client, retry
will actually correct the problem. It's only when all retries also fail, it
becomes a false negative. With a setting of 3 retries, you can also ensure
the network is really down between app and DB, and we are talking about 2
out of 3 zones happen at the same time.
Simply put, the application is designed for failure in one zone, not in 2
zones. Coz it's really unlikely to happen.
【在 w**z 的大作中提到】
: that is certainly possible. Almost all high level C* clients do retry when
: it fails.
will actually correct the problem. It's only when all retries also fail, it
becomes a false negative. With a setting of 3 retries, you can also ensure
the network is really down between app and DB, and we are talking about 2
out of 3 zones happen at the same time.
Simply put, the application is designed for failure in one zone, not in 2
zones. Coz it's really unlikely to happen.
【在 w**z 的大作中提到】
: that is certainly possible. Almost all high level C* clients do retry when
: it fails.
相关阅读
app单干没啥前途吧？Scala还值得学吗？ (转载)FP和OOP就是英语和汉语的区别吧web问题就两个现在082KAFKA支持produce数组吗湾区码工的职称赵海平加入阿里巴巴各个语言在paradigms上的对比haskell怎么样 未来有机会在公司大展身手么给王垠同学的一点看法 (转载)从并行计算谈谈前戏的重要性 (转载)完全靠刷题和GPA拿到offer，进公司能赶上吗 (转载)码工如果只认准一种语言， 要想一辈子有工作保障是不可能好东西周报 2015-03-22What is the simple plain text editor in iMAC ?既然美国这么缺码工，为何不大力 外包到印度？J2EE 的面试 越来越变态 (转载)码工詹皇 (转载)haskell写起来真爽。可惜没有spark这种牛库带动这个语言C 语言，2进制转16进制，输入问题