b*******g
发帖数: 603 | 1 不过八个字，合理分析，小心求证。
需求分析是最基本的，并非所有的需求都是合理，或者都可以满足的。一个好的架构师
，要能够快速地从需求中找出系统的瓶颈，要保证所有不易扩展部分的瓶颈都在常识范
围之下。当做不到的时候就要有所妥协，有些需求可以妥协，有些不能妥协，需要妥协
的部分要跟需求方反复商量重新制定规范。这就是为什么要主动妥协，而不是被动妥协
。一个竞标，你没有这个技术实力，可以不做。但是没用脑子拍胸脯就上了，到时候做
不出来，小则自己被炒，大则公司破产。
具体到12306这个例子上，有新闻说第一分钟的平均订单数达到了27万/秒，基于这个数
据单秒峰值1M/秒其实偏低，但是考虑到用户可以接受一点延迟，还算合理。注意是订
单数，不是票数。12306允许订联程票，允许单个订单最多5张票。这整个是密不可分的
一个事务操作。如果我从广州回长春，只能到北京，我不如不走。如果我走的了，我家
人走不了，不如不走。这些都是常识，数据库101级别的常识。再接下来，老弱病残没
法抗大包换车厢，所以单车次都不换座，这也是基本常识。
所有上面的这些东西，都是没法妥协的。这时候一个有经验的架构师，就会从经验意识
到票子产生竞争，数据库是瓶颈，分票是个复杂处理，没法全部实时处理。所以只有两
种取舍而已。要吗丢
弃一部分订单，要吗放弃实时处理。所幸单子虽然多，但票子有限，只要缓冲订单就行
。如果是无限的供给，无限的需求，那就要分票分库处理。根据数据的特性，制定不同
的策略，恰恰是系统设计的难点。
接下来就是小心求证的部分，这个延迟是否会太大，导致用户体验不佳。从12306分时
放票，加上常规数据库每秒5k-10k的估计，不进一步优化这个延迟大约2-3分钟，各种
不可预知因素留点余量也不过10分钟。个人认为可以接受，但是必须跟甲方再商量。而
且这样的架构，如果峰值不大，比如每秒1万，同样是实时系统没有压力。
魏老师这样的，是真正的半路出家的程序猿。对系统设计完全没有经验，连需求都没想
清楚，就上来就拍胸脯要百万次没压力。对基本的transaction是什么完全没有概念。
decrement/increment不是transaction已经闹了个大笑话。正常人错了好歹理解学习一
下吧，没两天又认为一张票就是一个transaction。就为了满足他那百万次的牛皮，那
是满地里耍赖皮。你要真让他设计了这个系统，12个月工期，10个月好不容易他那宇宙
第一的抢票服务器没有功能性问题了。一上量挂了怎么办？不怎么办，一样就是12306
现在我死给你看的结果。
牛逼哄哄地在这里折腾分座算法也不知道有什么用，分座算法根本不是这个系统的瓶颈
。3个月之前，我用了一分钟，就想清楚分座算法至少是个O(N)的问题，对实时性会有
很大影响。一旦不追求实时，这个问题迎刃而解。因为延迟取决于有效票的总张数，一
次订5张也好，1张也好，不会提高延迟。真要搞算法，jobhunting版那些科班出身的
new grad比魏老师强得不是一点半点。真追求最优，我不会悬赏100万让全社会来竞争
，在这里算破头有用吗？
说到底，人贵有自知之明。外行的东西，胡乱评论就有丢人的风险。拍胸脯要求做违反
常识的东西，就是民科找死的节奏。 |
n*****t
发帖数: 22014 | 2 一大堆的错误亏你能码那么多字，别的不说，哪个老师教你的优化分座是 ON？
★ 发自iPhone App: ChineseWeb 8.6
【在 b*******g 的大作中提到】
: 不过八个字，合理分析，小心求证。
: 需求分析是最基本的，并非所有的需求都是合理，或者都可以满足的。一个好的架构师
: ，要能够快速地从需求中找出系统的瓶颈，要保证所有不易扩展部分的瓶颈都在常识范
: 围之下。当做不到的时候就要有所妥协，有些需求可以妥协，有些不能妥协，需要妥协
: 的部分要跟需求方反复商量重新制定规范。这就是为什么要主动妥协，而不是被动妥协
: 。一个竞标，你没有这个技术实力，可以不做。但是没用脑子拍胸脯就上了，到时候做
: 不出来，小则自己被炒，大则公司破产。
: 具体到12306这个例子上，有新闻说第一分钟的平均订单数达到了27万/秒，基于这个数
: 据单秒峰值1M/秒其实偏低，但是考虑到用户可以接受一点延迟，还算合理。注意是订
: 单数，不是票数。12306允许订联程票，允许单个订单最多5张票。这整个是密不可分的
|
b*******g
发帖数: 603 | 3 单次操作是至少O(N)，常数级的优化存在但O级别的优化在worst case不存在，就是个
常识而已。
一个复杂系统，在一个不是瓶颈的地方低头猛算cpu cycle的，都是最低级的程序猿。
【在 n*****t 的大作中提到】
: 一大堆的错误亏你能码那么多字，别的不说，哪个老师教你的优化分座是 ON？
:
: ★ 发自iPhone App: ChineseWeb 8.6
|
t**********1
发帖数: 550 | 4 亏你码了这么多字。
我的意见。公平不公平，各位网友说了算。
http://www.mitbbs.com/article_t/Programming/31318637.html
【在 b*******g 的大作中提到】
: 不过八个字，合理分析，小心求证。
: 需求分析是最基本的，并非所有的需求都是合理，或者都可以满足的。一个好的架构师
: ，要能够快速地从需求中找出系统的瓶颈，要保证所有不易扩展部分的瓶颈都在常识范
: 围之下。当做不到的时候就要有所妥协，有些需求可以妥协，有些不能妥协，需要妥协
: 的部分要跟需求方反复商量重新制定规范。这就是为什么要主动妥协，而不是被动妥协
: 。一个竞标，你没有这个技术实力，可以不做。但是没用脑子拍胸脯就上了，到时候做
: 不出来，小则自己被炒，大则公司破产。
: 具体到12306这个例子上，有新闻说第一分钟的平均订单数达到了27万/秒，基于这个数
: 据单秒峰值1M/秒其实偏低，但是考虑到用户可以接受一点延迟，还算合理。注意是订
: 单数，不是票数。12306允许订联程票，允许单个订单最多5张票。这整个是密不可分的
|
n*****t
发帖数: 22014 | 5 单次车余票的组合是固定的，完全可以查表，你再想想
【在 b*******g 的大作中提到】
: 单次操作是至少O(N)，常数级的优化存在但O级别的优化在worst case不存在，就是个
: 常识而已。
: 一个复杂系统，在一个不是瓶颈的地方低头猛算cpu cycle的，都是最低级的程序猿。
|
b*******g
发帖数: 603 | 6 实时当然好，但是做不到的时候，你是让老弱病残抗大包，还是等2-3分钟，根本是一
个不需要争的问题。 |
b*******g
发帖数: 603 | 7 我说了，不是瓶颈的地方你使劲优化，根本没用。
【在 n*****t 的大作中提到】
: 单次车余票的组合是固定的，完全可以查表，你再想想
|
n*****t
发帖数: 22014 | 8 抢票不是瓶颈还有什么是瓶颈啊？都不是瓶颈你异步干啥，直接堆机器不就完事了？
【在 b*******g 的大作中提到】
: 我说了，不是瓶颈的地方你使劲优化，根本没用。
|
b*******g
发帖数: 603 | 9 像你这样的单机在IO上就要挂，都没到抢票这一步，信不信由你。反正吹牛逼被打脸的
又不是我。
人贵有自知之明。
【在 n*****t 的大作中提到】
: 抢票不是瓶颈还有什么是瓶颈啊？都不是瓶颈你异步干啥，直接堆机器不就完事了？
|
n*****t
发帖数: 22014 | 10 操，单机 IO 能做到啥样都有数据，你是不是一点概念都没啊？
既然你认定 IO 都无法过，那还要求这个哪个干啥，直接发 5M requests 堆死老魏得
了，还算个屁啊
【在 b*******g 的大作中提到】
: 像你这样的单机在IO上就要挂，都没到抢票这一步，信不信由你。反正吹牛逼被打脸的
: 又不是我。
: 人贵有自知之明。
|
|
|
b*******g
发帖数: 603 | 11 光看spec没用的，你以为是helloworld。都是要做操作的。
【在 n*****t 的大作中提到】
: 操，单机 IO 能做到啥样都有数据，你是不是一点概念都没啊？
: 既然你认定 IO 都无法过，那还要求这个哪个干啥，直接发 5M requests 堆死老魏得
: 了，还算个屁啊
|
t**********1
发帖数: 550 | 12 光说不练不行。
再说练还是我练。
只不过要你要一点脸而已。还是为你好。
【在 b*******g 的大作中提到】
: 光看spec没用的，你以为是helloworld。都是要做操作的。
|
b*******g
发帖数: 603 | 13 我没吹牛，我丢不了脸。您老就不一样了，宇宙第一的算法连基本要求都满足不了。哈
哈。
【在 t**********1 的大作中提到】
: 光说不练不行。
: 再说练还是我练。
: 只不过要你要一点脸而已。还是为你好。
|
n*****t
发帖数: 22014 | 14 你是不是最这些基本信息一点概念没有啊？
【在 b*******g 的大作中提到】
: 光看spec没用的，你以为是helloworld。都是要做操作的。
|
b*******g
发帖数: 603 | 15 我的经验来自于实战，不是硬件的spec或者paper。这就是我们的区别。
【在 n*****t 的大作中提到】
: 你是不是最这些基本信息一点概念没有啊？
|
n*****t
发帖数: 22014 | 16 你有 OS 的实战经验不？没有跑一下别人的测试程序
【在 b*******g 的大作中提到】
: 我的经验来自于实战，不是硬件的spec或者paper。这就是我们的区别。
|
b*******g
发帖数: 603 | 17 我没有，但12306是个网站，你套OS的结果就像魏老师那样。
【在 n*****t 的大作中提到】
: 你有 OS 的实战经验不？没有跑一下别人的测试程序
|
n*****t
发帖数: 22014 | 18 IO 性能是网站？
【在 b*******g 的大作中提到】
: 我没有，但12306是个网站，你套OS的结果就像魏老师那样。
|
b*******g
发帖数: 603 | 19 说的就是网站的瓶颈，一般都在于数据库IO。像你们这样做到CPU bound，实在是不入
流。
【在 n*****t 的大作中提到】
: IO 性能是网站？
|
n*****t
发帖数: 22014 | 20 由 jvm 决定还是 os?
【在 b*******g 的大作中提到】
: 说的就是网站的瓶颈，一般都在于数据库IO。像你们这样做到CPU bound，实在是不入
: 流。
|
|
|
n******1
发帖数: 3756 | 21 我觉得可能大家的理解不同
表面看好像是分票的瓶颈，但实际上，如果只是把票分给用户，那是很简单的过程，再
慢也不会很慢
但是因为分票只要涉及支付等环节，交易需要确认，也有很多的查询，这些查询也要接
近实时，否则用户不满意，所以既不需要实时，也需要实时，还有临时取消的等等操作
，所以才复杂
按我想法，还不如搞一个类似彩票池的东西，在某个特定时间之前，大家都可以登记某
个车次的，不管快慢，售票关闭后统一抽签，不过因为人的自私性，大家可能登记多张
票，到时候拿到最优的就退掉其他的，这里怎么回收退票也是问题，而且交易一旦完成
，还要涉及退款
说来说去，网站其实是用户体验问题
【在 n*****t 的大作中提到】
: 抢票不是瓶颈还有什么是瓶颈啊？都不是瓶颈你异步干啥，直接堆机器不就完事了？
|
b*******g
发帖数: 603 | 22 缓冲池是必需的，至于抽签也好，排队也好，无非是不同策略。
【在 n******1 的大作中提到】
: 我觉得可能大家的理解不同
: 表面看好像是分票的瓶颈，但实际上，如果只是把票分给用户，那是很简单的过程，再
: 慢也不会很慢
: 但是因为分票只要涉及支付等环节，交易需要确认，也有很多的查询，这些查询也要接
: 近实时，否则用户不满意，所以既不需要实时，也需要实时，还有临时取消的等等操作
: ，所以才复杂
: 按我想法，还不如搞一个类似彩票池的东西，在某个特定时间之前，大家都可以登记某
: 个车次的，不管快慢，售票关闭后统一抽签，不过因为人的自私性，大家可能登记多张
: 票，到时候拿到最优的就退掉其他的，这里怎么回收退票也是问题，而且交易一旦完成
: ，还要涉及退款
|
n*****t
发帖数: 22014 | 23 其他不是瓶颈的部分都可以分布，只要堆机器就能增强体验，有些绕不过去的只好攻关
，而不是神马异步批处理这种。
现在争论焦点，是到底实时处理行不行，所以要测关键节点的性能。
【在 n******1 的大作中提到】
: 我觉得可能大家的理解不同
: 表面看好像是分票的瓶颈，但实际上，如果只是把票分给用户，那是很简单的过程，再
: 慢也不会很慢
: 但是因为分票只要涉及支付等环节，交易需要确认，也有很多的查询，这些查询也要接
: 近实时，否则用户不满意，所以既不需要实时，也需要实时，还有临时取消的等等操作
: ，所以才复杂
: 按我想法，还不如搞一个类似彩票池的东西，在某个特定时间之前，大家都可以登记某
: 个车次的，不管快慢，售票关闭后统一抽签，不过因为人的自私性，大家可能登记多张
: 票，到时候拿到最优的就退掉其他的，这里怎么回收退票也是问题，而且交易一旦完成
: ，还要涉及退款
|
z*******3
发帖数: 13709 | 24 实时只要你给钱就能做
这个digua不是给了你正确答案么？
非要这么严苛要求下去，最后成本会很高
做了干嘛？还不如上来就分布式
四平八稳，这正是做server sdie软件需要的素质
老魏那种做client side的，就知道快
就跟国足一样，踢球又不是田径，光快有用么？
又不是只有这一个指标，目标是进球
一样的，server side目标是让尽可能多的人买到票，不出错
而不是多快搞定，这又不是比赛
老中高考一样的思维方式应该改一改
【在 n*****t 的大作中提到】
: 其他不是瓶颈的部分都可以分布，只要堆机器就能增强体验，有些绕不过去的只好攻关
: ，而不是神马异步批处理这种。
: 现在争论焦点，是到底实时处理行不行，所以要测关键节点的性能。
|
n*****t
发帖数: 22014 | 25 几台 16 core 做中心节点狠花钱吗？几千块的网卡很贵吗？铁道部花不起这钱？能不
能少扯淡啊
【在 z*******3 的大作中提到】
: 实时只要你给钱就能做
: 这个digua不是给了你正确答案么？
: 非要这么严苛要求下去，最后成本会很高
: 做了干嘛？还不如上来就分布式
: 四平八稳，这正是做server sdie软件需要的素质
: 老魏那种做client side的，就知道快
: 就跟国足一样，踢球又不是田径，光快有用么？
: 又不是只有这一个指标，目标是进球
: 一样的，server side目标是让尽可能多的人买到票，不出错
: 而不是多快搞定，这又不是比赛
|
