g****t
发帖数: 31659 | 1 假设我是买方，好虫和魏老师作为总工，我选择买谁的?
我不懂软件。但十多年前就做过几千万人民币项目买方主要技术人员。
现在用直觉和经验随便说说。
1.
我第一印象会觉得这二位都至少需要个懂的老印才能把项目做成。
道理很简单，这个火车卖票，我从最一开始几个月前就说了，必须先需求分析，
不然都是瞎整。现在他们总算收敛到需求分析了。一个项目除了技术架构，
还有个管理架构。这两位显然是不合格组织管理项目的部署的。
至少你先找几十个人工卖票的模范工人，问问卖票怎么回事啊，
corner cases啊。不然谈毛的技术啊。卖票可是个技术活啊，这个你们不会不懂吧？
火车买票的需求实际上是非常复杂的。而且有可能买票系统的问题会扩散到
列车调度。具体大家去研究需求，看我说的对不对。
12306这个熊样，我老推荐大家最近回国别做高铁。
上次我一个同事回国出差，我跟他说高铁先别乘。然后1个月后就出事故了。
现在我同样的直觉。大家爱听不听。
2.
从两人的技术表述上来说。老魏是很牛X的。
他把看上去最开始很多人都以为的一个很麻烦的问题，
弄成计数器。这是很牛也很有意思的思路。我想这就是为啥不少人帮他煳后面的
补丁的原因。有意思啊，确实有意思。
赵策说人家不牛，这个属于无聊。人家把抢票简化成计数器。其他部分分割出去
让其他专家作，这个架构显然是有道理的。方法论是有意思的。因为那些其他部分
都是通用的技术，很多人都会做。大规模多路段抢票，是一个不常见的独有的挑战。
你不给人家credit,这个损的是自己的人品。
3.
好虫的方案也不错。优势在于鲁棒性，容易扩展。比如说我找了几个卖票的
老师傅知道了几个新的特殊情况，或者铁道部下了新命令，需求要扩展。
或者桥断路垮，冰雨地震。我相信好虫的方案就可以很容易的
做到扩展。但这就是老魏的方案的缺点。他的方案太specific到抢票这边了。
如果别的需求出现了，很可能他的方案是扩展不出来的。
4.
综合一下。老魏给一个狭窄的需求给出了一个独到的解决。牛。
但如果我是铁道部的，我不会推荐买他这个架构的。我会买好虫的。
一方面是因为好虫的设计四平八稳。另一方面，好虫的方法论很对，
系统性能不太好，咱加延迟啊，不要实时，多加延迟，什么问题不能解决？
你说客户体验不好？ 共产党不就是用来折磨人民的么。
再说了，起码比人工买的等的时间少吧？
另外，第一代产品，安全性，可靠性要放的更高。屁民的体验，不需要太关心。
5.
老魏的方案铁道部肯定不会买。
但我确实看好老魏的想法。而且认为他的想法，在非常确定的狭窄需求
之下，会很有价值。老魏，如果你有有意思的项目需要资金，请给我投条。
我给你投资，咱们看能合伙赚大钱不。
或者你弄个世界最快的挖矿机架构？我买。
挖矿正好是非常确定的狭窄需求。你看能把挖矿弄成内存里面的计数器不。 |
T********i
发帖数: 2416 | 2 我的方案成本降低了一个数量级，铁道部肯买才怪。
如果我要是傻到做铁道部的生意，那是我自己傻逼，怪不得别人。
不过说到可扩展性，我的方案其实更好。在线数据修改/扩展都是微秒级别的。即使暂
时下线升级程序也可以做到秒级，因此结构太简单了。
至于这个好虫，有确凿的证据证明此人OS和Architecture都不及格。这个是难以想象的
。 |
g*****g
发帖数: 34805 | 3 哈哈，单机扩展性更好，人真是不要脸了啥都能说。
【在 T********i 的大作中提到】
: 我的方案成本降低了一个数量级，铁道部肯买才怪。
: 如果我要是傻到做铁道部的生意，那是我自己傻逼，怪不得别人。
: 不过说到可扩展性，我的方案其实更好。在线数据修改/扩展都是微秒级别的。即使暂
: 时下线升级程序也可以做到秒级，因此结构太简单了。
: 至于这个好虫，有确凿的证据证明此人OS和Architecture都不及格。这个是难以想象的
: 。
|
g****t
发帖数: 31659 | 4 不是成本问题。
我说了，你的方案不predictable,太特殊。
如果我有新的需求过来，你可能要重新设计整个东西。
有一种图灵机模型，就是几个箱子挪来挪去。
买票占座位的需求是很可能及其复杂的。说不定是图灵完备的都未可知。
另外还有桥断路垮，首长出巡，冰雨地震，这些情况，在你的那种设计中，
都需要一个个仔细研究。
好虫的方案，估计做起来和填空题类似了。
好虫的方案容易扩展，with respect to 新需求。
而且他懂的折磨屁民提高体系稳定性这个阳光大道。系统不行就加延时。
其实全国分时段订票都可以。
你是把用户当上帝了。这是不对的。
你有你牛的地方。假如你站出来说，给我20万刀，我给你弄个全球最快bitcoin机器，
我会给你。好虫或者赵策等等，我觉得不会作“全球第一”类型的东西。
我的方案成本降低了一个数量级，铁道部肯买才怪。
如果我要是傻到做铁道部的生意，那是我自己傻逼，怪不得别人。
不过说到可扩展性，我的方案其实更好。在线数据修改/扩展都是微秒级别的。即使暂
时下线升级程序也可以做到秒级，因此结构太简单了。
至于这个好虫，有确凿的证据证明此人OS和Architecture都不及格。这个是难以想象的
。
【在 T********i 的大作中提到】
: 我的方案成本降低了一个数量级，铁道部肯买才怪。
: 如果我要是傻到做铁道部的生意，那是我自己傻逼，怪不得别人。
: 不过说到可扩展性，我的方案其实更好。在线数据修改/扩展都是微秒级别的。即使暂
: 时下线升级程序也可以做到秒级，因此结构太简单了。
: 至于这个好虫，有确凿的证据证明此人OS和Architecture都不及格。这个是难以想象的
: 。
|
g****t
发帖数: 31659 | 5 都冷静下，不要PA.
哈哈，单机扩展性更好，人真是不要脸了啥都能说。
【在 g*****g 的大作中提到】
: 哈哈，单机扩展性更好，人真是不要脸了啥都能说。
|
n*****t
发帖数: 22014 | 6 老魏的方案，其实是把记录加锁放到中心节点，一旦你取到了锁，其他操作都可以分布
到任意多台数据库服务器，所以不存在重新设计的问题。关键是瓶颈的效率大大提高了。
这个概念，咳咳，我们 14 年前尝试过，当时的目标是在赛羊上跑企业级的 instant
message，一开始我们用的是 mysql，后来把关键部分移植到 berkeley db。
【在 g****t 的大作中提到】
: 不是成本问题。
: 我说了，你的方案不predictable,太特殊。
: 如果我有新的需求过来，你可能要重新设计整个东西。
: 有一种图灵机模型，就是几个箱子挪来挪去。
: 买票占座位的需求是很可能及其复杂的。说不定是图灵完备的都未可知。
: 另外还有桥断路垮，首长出巡，冰雨地震，这些情况，在你的那种设计中，
: 都需要一个个仔细研究。
: 好虫的方案，估计做起来和填空题类似了。
: 好虫的方案容易扩展，with respect to 新需求。
: 而且他懂的折磨屁民提高体系稳定性这个阳光大道。系统不行就加延时。
|
g*****g
发帖数: 34805 | 7 分布个头，排座位我反例举出来了，你来分一个？还有序列化不用 cpu?
了。
【在 n*****t 的大作中提到】
: 老魏的方案，其实是把记录加锁放到中心节点，一旦你取到了锁，其他操作都可以分布
: 到任意多台数据库服务器，所以不存在重新设计的问题。关键是瓶颈的效率大大提高了。
: 这个概念，咳咳，我们 14 年前尝试过，当时的目标是在赛羊上跑企业级的 instant
: message，一开始我们用的是 mysql，后来把关键部分移植到 berkeley db。
|
l*****9
发帖数: 9501 | 8 你完全不懂技术也就罢了（所以会被一个你不明觉厉的东西大加赞赏），common sense
也欠缺
老魏的real time是通过丢单实现的，屁民用户的体验是网站基本当掉了，偶尔工作一
下，必须不断刷票碰运气；你的所谓有latency的方案，网站一直正常工作，订单交了
10分钟（或更快）出结果。从屁民角度看，哪个是更折磨人的方案？其它，哪个更公平
更正确就不细谈了，反正你根本不懂。
买票最重要的是排队，计数器有个球用
【在 g****t 的大作中提到】
: 假设我是买方，好虫和魏老师作为总工，我选择买谁的?
: 我不懂软件。但十多年前就做过几千万人民币项目买方主要技术人员。
: 现在用直觉和经验随便说说。
: 1.
: 我第一印象会觉得这二位都至少需要个懂的老印才能把项目做成。
: 道理很简单，这个火车卖票，我从最一开始几个月前就说了，必须先需求分析，
: 不然都是瞎整。现在他们总算收敛到需求分析了。一个项目除了技术架构，
: 还有个管理架构。这两位显然是不合格组织管理项目的部署的。
: 至少你先找几十个人工卖票的模范工人，问问卖票怎么回事啊，
: corner cases啊。不然谈毛的技术啊。卖票可是个技术活啊，这个你们不会不懂吧？
|
g****t
发帖数: 31659 | 9 问题是有些需求不见得能简化成记录加锁啊。
这是我的直觉。
你比如说首长突然出巡了。屁民让道，这个怎么解决？
需求这玩意儿说起来没底的。
找些屁民按一定轨则抢座位，说不定就是无法判断最后状态的停机问题。
老魏的方案，其实是把记录加锁放到中心节点，一旦你取到了锁，其他操作都可以分布
到任意多台数据库服务器，所以不存在重新设计的问题。关键是瓶颈的效率大大提高了。
这个概念，咳咳，我们 14 年前尝试过，当时的目标是在赛羊上跑企业级的 instant
message，一开始我们用的是 mysql，后来把关键部分移植到 berkeley db。
【在 n*****t 的大作中提到】
: 老魏的方案，其实是把记录加锁放到中心节点，一旦你取到了锁，其他操作都可以分布
: 到任意多台数据库服务器，所以不存在重新设计的问题。关键是瓶颈的效率大大提高了。
: 这个概念，咳咳，我们 14 年前尝试过，当时的目标是在赛羊上跑企业级的 instant
: message，一开始我们用的是 mysql，后来把关键部分移植到 berkeley db。
|
T********i
发帖数: 2416 | 10 什么叫丢单？
看到今天我发的帖子了么？改成单线程，每秒50M。不会有有票不出的情况了。
sense
【在 l*****9 的大作中提到】
: 你完全不懂技术也就罢了（所以会被一个你不明觉厉的东西大加赞赏），common sense
: 也欠缺
: 老魏的real time是通过丢单实现的，屁民用户的体验是网站基本当掉了，偶尔工作一
: 下，必须不断刷票碰运气；你的所谓有latency的方案，网站一直正常工作，订单交了
: 10分钟（或更快）出结果。从屁民角度看，哪个是更折磨人的方案？其它，哪个更公平
: 更正确就不细谈了，反正你根本不懂。
: 买票最重要的是排队，计数器有个球用
|
|
|
g****t
发帖数: 31659 | 11 你需要研究下前面几个总结。
sense
【在 l*****9 的大作中提到】
: 你完全不懂技术也就罢了（所以会被一个你不明觉厉的东西大加赞赏），common sense
: 也欠缺
: 老魏的real time是通过丢单实现的，屁民用户的体验是网站基本当掉了，偶尔工作一
: 下，必须不断刷票碰运气；你的所谓有latency的方案，网站一直正常工作，订单交了
: 10分钟（或更快）出结果。从屁民角度看，哪个是更折磨人的方案？其它，哪个更公平
: 更正确就不细谈了，反正你根本不懂。
: 买票最重要的是排队，计数器有个球用
|
g*****g
发帖数: 34805 | 12 你序列化了吗？你找座位了吗？实现了再来丢人。
【在 T********i 的大作中提到】
: 什么叫丢单？
: 看到今天我发的帖子了么？改成单线程，每秒50M。不会有有票不出的情况了。
:
: sense
|
T********i
发帖数: 2416 | 13 别不要脸了。你就不能要点脸？
我可以努力一下，让全Nflx都知道你这个人不要脸。随便找两天的帖子给他们看看就好
了。
【在 g*****g 的大作中提到】
: 你序列化了吗？你找座位了吗？实现了再来丢人。
|
l*****9
发帖数: 9501 | 14 用户填好订单，递交，没有反应，网站当了。只要抢票必然丢单。计数器谁不会，
12306在最糟糕的第一季度卖过重复座位吗？
【在 T********i 的大作中提到】
: 什么叫丢单？
: 看到今天我发的帖子了么？改成单线程，每秒50M。不会有有票不出的情况了。
:
: sense
|
g*****g
发帖数: 34805 | 15 操，就一个简单的技术问题，太监了就太监了。骂人有用吗？现在整个论坛一边倒。
【在 T********i 的大作中提到】
: 别不要脸了。你就不能要点脸？
: 我可以努力一下，让全Nflx都知道你这个人不要脸。随便找两天的帖子给他们看看就好
: 了。
|
T********i
发帖数: 2416 | 16 这个智商，和goodbug有一拼了。
还有个共同点，不可能给你说明白了。只能放弃。
【在 l*****9 的大作中提到】
: 用户填好订单，递交，没有反应，网站当了。只要抢票必然丢单。计数器谁不会，
: 12306在最糟糕的第一季度卖过重复座位吗？
|
g****t
发帖数: 31659 | 17 好虫明白了。
1989没花时间看总结。其实前面几个双方的总结都不错。
这个智商，和goodbug有一拼了。
还有个共同点，不可能给你说明白了。只能放弃。
【在 T********i 的大作中提到】
: 这个智商，和goodbug有一拼了。
: 还有个共同点，不可能给你说明白了。只能放弃。
|
n*****t
发帖数: 22014 | 18 所有前端的操作都一样，到最后性能的问题都集中到加锁上。
我的方案跟老魏的大致思路一样，不过有点小区别。老魏是用计数器，性能达到极致，
可以适用 12306 这种特定的抢票。我的性能比较差，用锁，同时给记录加上一些标志
，比如状态、计时器，等等。首长出行、置标志；屁民抢票，用锁隔离；前端某服务器
当机未按协议相应，清计时器，等等等等
了。
【在 g****t 的大作中提到】
: 问题是有些需求不见得能简化成记录加锁啊。
: 这是我的直觉。
: 你比如说首长突然出巡了。屁民让道，这个怎么解决？
: 需求这玩意儿说起来没底的。
: 找些屁民按一定轨则抢座位，说不定就是无法判断最后状态的停机问题。
:
: 老魏的方案，其实是把记录加锁放到中心节点，一旦你取到了锁，其他操作都可以分布
: 到任意多台数据库服务器，所以不存在重新设计的问题。关键是瓶颈的效率大大提高了。
: 这个概念，咳咳，我们 14 年前尝试过，当时的目标是在赛羊上跑企业级的 instant
: message，一开始我们用的是 mysql，后来把关键部分移植到 berkeley db。
|
g*****g
发帖数: 34805 | 19 不管你咋整，单子要序列化，东西不会突然出现在内存里。太监那单线程计数器， 101
作业的难度。一次序列化反序列化就能干100次 计数了。
【在 n*****t 的大作中提到】
: 所有前端的操作都一样，到最后性能的问题都集中到加锁上。
: 我的方案跟老魏的大致思路一样，不过有点小区别。老魏是用计数器，性能达到极致，
: 可以适用 12306 这种特定的抢票。我的性能比较差，用锁，同时给记录加上一些标志
: ，比如状态、计时器，等等。首长出行、置标志；屁民抢票，用锁隔离；前端某服务器
: 当机未按协议相应，清计时器，等等等等
:
: 了。
|
L*****e
发帖数: 8347 | 20 现有系统抢票是瓶颈，还是支付是瓶颈？不解决瓶颈，而让上游决堤，下游洪涝灾害更
严重。。。
虽然支付可以延时，但是大量支付请求排队，那么对一大部分支付可能要等上十几分钟
或者几十分钟，如果因为系统原因支付失败，那么订票一样失败，还得重新抢票。。。
买票过程是一个完整的体验，最不能缩短整个买票时间，提高拿票概率，只是局部发达
，是不可行的，或者说离真正实用还差很远。。。
了。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 n*****t 的大作中提到】
: 老魏的方案，其实是把记录加锁放到中心节点，一旦你取到了锁，其他操作都可以分布
: 到任意多台数据库服务器，所以不存在重新设计的问题。关键是瓶颈的效率大大提高了。
: 这个概念，咳咳，我们 14 年前尝试过，当时的目标是在赛羊上跑企业级的 instant
: message，一开始我们用的是 mysql，后来把关键部分移植到 berkeley db。
|
|
|
g****t
发帖数: 31659 | 21 你说的对的。老魏那个没解决的问题很多。
但鉴于抢票是比较独有的铁路需求。
支付是比较常见的很多系统都有的较通用需求。
我给老魏的计数器鼓掌。
现有系统抢票是瓶颈，还是支付是瓶颈？不解决瓶颈，而让上游决堤，下游洪涝灾害更
严重。。。
虽然支付可以延时，但是大量支付请求排队，那么对一大部分支付可能要等上十几分钟
或者几十分钟，如果因为系统原因支付失败，那么订票一样失败，还得重新抢票。。。
买票过程是一个完整的体验，最不能缩短整个买票时间，提高拿票概率，只是局部发达
，是不可行的，或者说离真正实用还差很远。。。
了。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 L*****e 的大作中提到】
: 现有系统抢票是瓶颈，还是支付是瓶颈？不解决瓶颈，而让上游决堤，下游洪涝灾害更
: 严重。。。
: 虽然支付可以延时，但是大量支付请求排队，那么对一大部分支付可能要等上十几分钟
: 或者几十分钟，如果因为系统原因支付失败，那么订票一样失败，还得重新抢票。。。
: 买票过程是一个完整的体验，最不能缩短整个买票时间，提高拿票概率，只是局部发达
: ，是不可行的，或者说离真正实用还差很远。。。
:
: 了。
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
l*****9
发帖数: 9501 | 22 排好队了，加什么锁呀。你和老魏大战风车很过瘾吧。
【在 n*****t 的大作中提到】
: 所有前端的操作都一样，到最后性能的问题都集中到加锁上。
: 我的方案跟老魏的大致思路一样，不过有点小区别。老魏是用计数器，性能达到极致，
: 可以适用 12306 这种特定的抢票。我的性能比较差，用锁，同时给记录加上一些标志
: ，比如状态、计时器，等等。首长出行、置标志；屁民抢票，用锁隔离；前端某服务器
: 当机未按协议相应，清计时器，等等等等
:
: 了。
|
n*****t
发帖数: 22014 | 23 哎，跟你说话费劲，也不知道你是真不懂还是在死撑，这问题你自己琢磨吧，思路一样
101
【在 g*****g 的大作中提到】
: 不管你咋整，单子要序列化，东西不会突然出现在内存里。太监那单线程计数器， 101
: 作业的难度。一次序列化反序列化就能干100次 计数了。
|
l*****9
发帖数: 9501 | 24 现有系统把排队应用做成了抢票应用，是根本的设计错误
【在 L*****e 的大作中提到】
: 现有系统抢票是瓶颈，还是支付是瓶颈？不解决瓶颈，而让上游决堤，下游洪涝灾害更
: 严重。。。
: 虽然支付可以延时，但是大量支付请求排队，那么对一大部分支付可能要等上十几分钟
: 或者几十分钟，如果因为系统原因支付失败，那么订票一样失败，还得重新抢票。。。
: 买票过程是一个完整的体验，最不能缩短整个买票时间，提高拿票概率，只是局部发达
: ，是不可行的，或者说离真正实用还差很远。。。
:
: 了。
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
g*****g
发帖数: 34805 | 25 操，序列化都视而不见，一个德行。
【在 n*****t 的大作中提到】
: 哎，跟你说话费劲，也不知道你是真不懂还是在死撑，这问题你自己琢磨吧，思路一样
:
: 101
|
n*****t
发帖数: 22014 | 26 支付不是瓶颈，假设有 1000 人买票，分到 1000 台 server 上去总能响应，银行那边
排队是银行的事，超出 12306 的范围了。
所有能分到流水线、加开流水线的，都是渣
【在 L*****e 的大作中提到】
: 现有系统抢票是瓶颈，还是支付是瓶颈？不解决瓶颈，而让上游决堤，下游洪涝灾害更
: 严重。。。
: 虽然支付可以延时，但是大量支付请求排队，那么对一大部分支付可能要等上十几分钟
: 或者几十分钟，如果因为系统原因支付失败，那么订票一样失败，还得重新抢票。。。
: 买票过程是一个完整的体验，最不能缩短整个买票时间，提高拿票概率，只是局部发达
: ，是不可行的，或者说离真正实用还差很远。。。
:
: 了。
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
n*****t
发帖数: 22014 | 27 你定义一下你的序列化，俺蓝翔技校毕业的，这种高大上的词不懂，俺只会使锤子
【在 g*****g 的大作中提到】
: 操，序列化都视而不见，一个德行。
|
g*****g
发帖数: 34805 | 28 单子网络读写序列化，你还能分到其他服务器上，单子天上掉下来的？
【在 n*****t 的大作中提到】
: 支付不是瓶颈，假设有 1000 人买票，分到 1000 台 server 上去总能响应，银行那边
: 排队是银行的事，超出 12306 的范围了。
: 所有能分到流水线、加开流水线的，都是渣
|
g*****g
发帖数: 34805 | 29 就是单子内存跟 io 的转换。 serialization. deserialization。太监计数只能做50
m ，这个必定要了老命。
【在 n*****t 的大作中提到】
: 你定义一下你的序列化，俺蓝翔技校毕业的，这种高大上的词不懂，俺只会使锤子
|
n*****t
发帖数: 22014 | 30 另外，我很早就提过了，12306 应该使用预付费。你想买啥票，放票前把钱交了，这样
看到有票就拿下了，避免很多无效操作。同时也实现一定程度的身份绑定（由银行、支
付宝验证）
当然，这个属于业务逻辑。
【在 L*****e 的大作中提到】
: 现有系统抢票是瓶颈，还是支付是瓶颈？不解决瓶颈，而让上游决堤，下游洪涝灾害更
: 严重。。。
: 虽然支付可以延时，但是大量支付请求排队，那么对一大部分支付可能要等上十几分钟
: 或者几十分钟，如果因为系统原因支付失败，那么订票一样失败，还得重新抢票。。。
: 买票过程是一个完整的体验，最不能缩短整个买票时间，提高拿票概率，只是局部发达
: ，是不可行的，或者说离真正实用还差很远。。。
:
: 了。
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
|
|
b***e
发帖数: 1419 | 31 抢票是resource contention的瓶颈。
【在 L*****e 的大作中提到】
: 现有系统抢票是瓶颈，还是支付是瓶颈？不解决瓶颈，而让上游决堤，下游洪涝灾害更
: 严重。。。
: 虽然支付可以延时，但是大量支付请求排队，那么对一大部分支付可能要等上十几分钟
: 或者几十分钟，如果因为系统原因支付失败，那么订票一样失败，还得重新抢票。。。
: 买票过程是一个完整的体验，最不能缩短整个买票时间，提高拿票概率，只是局部发达
: ，是不可行的，或者说离真正实用还差很远。。。
:
: 了。
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
n*****t
发帖数: 22014 | 32 第一，这个应用不做 IO 不是大问题。首先当机的概率太小，其次当机不是灾难性的，
可以从前端 Cache 鸡那里恢复，而 Cache 鸡由于可分布到多台，性能可以线性提高。
第二、50M 没必要，5M 我没把握，非牛叉硬件条件下，我能做到 SSD 1M/s，也满足应
用要求了吧？咱就不提啥其他牛叉阵列、光纤了，这个老魏比我懂得多了。
50
【在 g*****g 的大作中提到】
: 就是单子内存跟 io 的转换。 serialization. deserialization。太监计数只能做50
: m ，这个必定要了老命。
|
n*****t
发帖数: 22014 | 33 操，你就不能想想扩展到多线程啊？
【在 l*****9 的大作中提到】
: 排好队了，加什么锁呀。你和老魏大战风车很过瘾吧。
|
g*****g
发帖数: 34805 | 34 擦，不做network io你怎么抢票，单子天上掉进内存里？抢票服务器就一台，前端过来
的 io 还能不做。不通信了是吧。
你成天吹你几 byte的编码，编码不用 cpu ? 一次编码跟10次计数哪个慢？
【在 n*****t 的大作中提到】
: 第一，这个应用不做 IO 不是大问题。首先当机的概率太小，其次当机不是灾难性的，
: 可以从前端 Cache 鸡那里恢复，而 Cache 鸡由于可分布到多台，性能可以线性提高。
: 第二、50M 没必要，5M 我没把握，非牛叉硬件条件下，我能做到 SSD 1M/s，也满足应
: 用要求了吧？咱就不提啥其他牛叉阵列、光纤了，这个老魏比我懂得多了。
:
: 50
|
T********i
发帖数: 2416 | 35 发信人: TeacherWei (TW), 信区: Programming
标 题: 再次告诉goodbug，你自己傻逼自己憋着
发信站: BBS 未名空间站 (Wed Feb 5 11:19:52 2014, 美东)
不能拉出来恶心别人。
你自己做不了4G带宽的protocol stack，不代表别人不能做。
上网搜搜，Open Source的方案都一大堆。看不懂是你自己的事请。 |
g*****g
发帖数: 34805 | 36 别人能做的了，你做不了。不服上线实测，太监有用吗？
【在 T********i 的大作中提到】
: 发信人: TeacherWei (TW), 信区: Programming
: 标 题: 再次告诉goodbug，你自己傻逼自己憋着
: 发信站: BBS 未名空间站 (Wed Feb 5 11:19:52 2014, 美东)
: 不能拉出来恶心别人。
: 你自己做不了4G带宽的protocol stack，不代表别人不能做。
: 上网搜搜，Open Source的方案都一大堆。看不懂是你自己的事请。
|
n*****t
发帖数: 22014 | 37 network 的性能你翻翻前面的帖子，编码用 CPU，不过不用 JAVA，如果你觉得这玩意
开销很大，赵策已经计算过平均每单能用多少 CPU CLOCK 了
【在 g*****g 的大作中提到】
: 擦，不做network io你怎么抢票，单子天上掉进内存里？抢票服务器就一台，前端过来
: 的 io 还能不做。不通信了是吧。
: 你成天吹你几 byte的编码，编码不用 cpu ? 一次编码跟10次计数哪个慢？
|
g*****g
发帖数: 34805 | 38 计数是一个指令，编码解码 超过 10个 计数，太监就挂了。你觉得你能，给个合理的
接口你来，就编码解码就好，太监是打死不敢写。我说的就是 cpu都不够用。
【在 n*****t 的大作中提到】
: network 的性能你翻翻前面的帖子，编码用 CPU，不过不用 JAVA，如果你觉得这玩意
: 开销很大，赵策已经计算过平均每单能用多少 CPU CLOCK 了
|
T********i
发帖数: 2416 | 39 上屁线呀？现在大多数人都知道你是傻逼了。除了打你脸，谁还会抬举你？
【在 g*****g 的大作中提到】
: 别人能做的了，你做不了。不服上线实测，太监有用吗？
|
n*****t
发帖数: 22014 | 40 你自己拿个小本子算算，2 x 8 core x 4Ghz，如果要求 5M/s，平均每单是多少指令周
期，算完再说
【在 g*****g 的大作中提到】
: 计数是一个指令，编码解码 超过 10个 计数，太监就挂了。你觉得你能，给个合理的
: 接口你来，就编码解码就好，太监是打死不敢写。我说的就是 cpu都不够用。
|
|
|
g*****g
发帖数: 34805 | 41 你没看见 太监要用单线程，只能做50 m 计数？
【在 n*****t 的大作中提到】
: 你自己拿个小本子算算，2 x 8 core x 4Ghz，如果要求 5M/s，平均每单是多少指令周
: 期，算完再说
|
T********i
发帖数: 2416 | 42 更何况是其他线程解码喂给单线程。
最傻逼的做法，顶多几个单入单出的队列。
再傻逼一点，还有10几个core可用。
最傻逼的，是10几个core不能接近MAX 10G的带宽，要10G网卡有啥用？5年前就能MAX了。
【在 n*****t 的大作中提到】
: 你自己拿个小本子算算，2 x 8 core x 4Ghz，如果要求 5M/s，平均每单是多少指令周
: 期，算完再说
|
T********i
发帖数: 2416 | 43 操你妈的你读不懂12行程序么？
那是50M transaction。每个transaction 20个路段的计数。
【在 g*****g 的大作中提到】
: 你没看见 太监要用单线程，只能做50 m 计数？
|
g*****g
发帖数: 34805 | 44 操，傻逼刚才还单线程，这下又改了？你把序列化加上，大家来实测呀。
了。
【在 T********i 的大作中提到】
: 更何况是其他线程解码喂给单线程。
: 最傻逼的做法，顶多几个单入单出的队列。
: 再傻逼一点，还有10几个core可用。
: 最傻逼的，是10几个core不能接近MAX 10G的带宽，要10G网卡有啥用？5年前就能MAX了。
|
g*****g
发帖数: 34805 | 45 那不就对应 50m 单子的计数器。你倒是加上序列化呀。太监下面就是没有。
【在 T********i 的大作中提到】
: 操你妈的你读不懂12行程序么？
: 那是50M transaction。每个transaction 20个路段的计数。
|
T********i
发帖数: 2416 | 46 你他妈的连线程通信都不会么？
单线程抢票，我还有10几个core不能处理网络编码解码么？
这点基本常识都没有？恭喜你再创新低。
【在 g*****g 的大作中提到】
: 操，傻逼刚才还单线程，这下又改了？你把序列化加上，大家来实测呀。
:
: 了。
|
g*****g
发帖数: 34805 | 47 10几核你就够了？你来呀。
【在 T********i 的大作中提到】
: 你他妈的连线程通信都不会么？
: 单线程抢票，我还有10几个core不能处理网络编码解码么？
: 这点基本常识都没有？恭喜你再创新低。
|
n*****t
发帖数: 22014 | 48 我要是你，就先拿个小本子算算指令周期再出来叫板
【在 g*****g 的大作中提到】
: 10几核你就够了？你来呀。
|
g*****g
发帖数: 34805 | 49 我要是你，就先问问自己见过单机 5m io的吗。
【在 n*****t 的大作中提到】
: 我要是你，就先拿个小本子算算指令周期再出来叫板
|
n*****t
发帖数: 22014 | 50 LOL,你先狗一下吧
【在 g*****g 的大作中提到】
: 我要是你，就先问问自己见过单机 5m io的吗。
|
|
|
z****g
发帖数: 75 | 51 这serializatin/deserialization 就几个指令搞定
这货啥就是懂个皮毛
话越多，就越显示出这13的脑力下限，大学估计班里倒数几名
【在 n*****t 的大作中提到】
: 我要是你，就先拿个小本子算算指令周期再出来叫板
|
m********5
发帖数: 17667 | 52 哈哈,你和goodbug都没看懂老魏的方案?
老魏的方案很有趣, 说道扩展性, 老魏的方案并不差
不过铁道部不会买老魏的方案, 因为外行看起来一点都不fancy
sense
【在 l*****9 的大作中提到】
: 你完全不懂技术也就罢了（所以会被一个你不明觉厉的东西大加赞赏），common sense
: 也欠缺
: 老魏的real time是通过丢单实现的，屁民用户的体验是网站基本当掉了，偶尔工作一
: 下，必须不断刷票碰运气；你的所谓有latency的方案，网站一直正常工作，订单交了
: 10分钟（或更快）出结果。从屁民角度看，哪个是更折磨人的方案？其它，哪个更公平
: 更正确就不细谈了，反正你根本不懂。
: 买票最重要的是排队，计数器有个球用
|
g*****g
发帖数: 34805 | 53 你不服，实现了上线我来测，光说不练是太监。
【在 z****g 的大作中提到】
: 这serializatin/deserialization 就几个指令搞定
: 这货啥就是懂个皮毛
: 话越多，就越显示出这13的脑力下限，大学估计班里倒数几名
|
m********5
发帖数: 17667 | 54 你可以自己算算嘛, 你当是8086啊
【在 g*****g 的大作中提到】
: 10几核你就够了？你来呀。
|
l*****9
发帖数: 9501 | 55 老魏搞的计数器从来就不是问题
【在 m********5 的大作中提到】
: 哈哈,你和goodbug都没看懂老魏的方案?
: 老魏的方案很有趣, 说道扩展性, 老魏的方案并不差
: 不过铁道部不会买老魏的方案, 因为外行看起来一点都不fancy
:
: sense
|
n*****t
发帖数: 22014 | 56 我就说了，好歹拿小本子算一下再叫板，不会算可以狗，哎
【在 m********5 的大作中提到】
: 你可以自己算算嘛, 你当是8086啊
|
g*****g
发帖数: 34805 | 57 这东西还有算出来的？12306是不是算个计数器够了？序列化就是小程序，给个接口我
就要来测试了。光说不练是太监。
【在 m********5 的大作中提到】
: 你可以自己算算嘛, 你当是8086啊
|
z****g
发帖数: 75 | 58 你那破脑子还是别在这里混了，整个一糊涂虫
【在 g*****g 的大作中提到】
: 这东西还有算出来的？12306是不是算个计数器够了？序列化就是小程序，给个接口我
: 就要来测试了。光说不练是太监。
|
c****3
发帖数: 10787 | |
T********i
发帖数: 2416 | 60 早劝过丫的。担心哪天我忍不住把丫那些丑事搞的NFLX人人皆知。
【在 z****g 的大作中提到】
: 你那破脑子还是别在这里混了，整个一糊涂虫
|
|
|
n*****t
发帖数: 22014 | 61 这玩意大把数据在那，你狗一下很难吗？回头我要你证明今天穿没穿内裤，你不拿照片
出来就是太监了？
【在 g*****g 的大作中提到】
: 这东西还有算出来的？12306是不是算个计数器够了？序列化就是小程序，给个接口我
: 就要来测试了。光说不练是太监。
|
T********i
发帖数: 2416 | 62 您千万别，丫极可能PO照片上来。
【在 n*****t 的大作中提到】
: 这玩意大把数据在那，你狗一下很难吗？回头我要你证明今天穿没穿内裤，你不拿照片
: 出来就是太监了？
|
c********l
发帖数: 8138 | 63 看第一段就看不下去了
1，找老印，就算是你所谓的“懂”的老印
他只是把你脑子里面已经清楚的东西用咖喱味的英语反复说，反复说
直到你烦了打断他或者是你自己从清楚变模糊为止。
2，中国高铁是全世界最reliable的。
在那个后面，西班牙、加拿大都出过出轨事故
3，中国企业，不注重网站形象，12306的界面连CSS align都做不好，
这是一个问题。但不代表内在质量差。
中国企业，包括老魏的公司，需要加强presentation
其实花不了什么功夫，用bootstrap就能搞定
【在 g****t 的大作中提到】
: 假设我是买方，好虫和魏老师作为总工，我选择买谁的?
: 我不懂软件。但十多年前就做过几千万人民币项目买方主要技术人员。
: 现在用直觉和经验随便说说。
: 1.
: 我第一印象会觉得这二位都至少需要个懂的老印才能把项目做成。
: 道理很简单，这个火车卖票，我从最一开始几个月前就说了，必须先需求分析，
: 不然都是瞎整。现在他们总算收敛到需求分析了。一个项目除了技术架构，
: 还有个管理架构。这两位显然是不合格组织管理项目的部署的。
: 至少你先找几十个人工卖票的模范工人，问问卖票怎么回事啊，
: corner cases啊。不然谈毛的技术啊。卖票可是个技术活啊，这个你们不会不懂吧？
|
g*****g
发帖数: 34805 | 64 12306能狗出来？
【在 n*****t 的大作中提到】
: 这玩意大把数据在那，你狗一下很难吗？回头我要你证明今天穿没穿内裤，你不拿照片
: 出来就是太监了？
|
n*****t
发帖数: 22014 | 65 Network IO 性能，你要的不是这个吗？
【在 g*****g 的大作中提到】
: 12306能狗出来？
|
g*****g
发帖数: 34805 | 66 不是，要得是能编码能找座位分票还能 5m 的， 不是 helloworld.
【在 n*****t 的大作中提到】
: Network IO 性能，你要的不是这个吗？
|
n*****t
发帖数: 22014 | 67 我的模型里是 Cache 鸡干这些活，当然在中心节点扫一遍也不难。
比如找座位，座席车次先确定，最多 1000 个硬板，假设 20 个站，最坏情况扫
20kbit，你算算 64 bit 需要多少指令
【在 g*****g 的大作中提到】
: 不是，要得是能编码能找座位分票还能 5m 的， 不是 helloworld.
|
N*n
发帖数: 456 | 68 作为一个公司，应该需要有 guvest思路的吧。。有经验的大拿们peer review 一下。
呵呵
【在 g****t 的大作中提到】
: 假设我是买方，好虫和魏老师作为总工，我选择买谁的?
: 我不懂软件。但十多年前就做过几千万人民币项目买方主要技术人员。
: 现在用直觉和经验随便说说。
: 1.
: 我第一印象会觉得这二位都至少需要个懂的老印才能把项目做成。
: 道理很简单，这个火车卖票，我从最一开始几个月前就说了，必须先需求分析，
: 不然都是瞎整。现在他们总算收敛到需求分析了。一个项目除了技术架构，
: 还有个管理架构。这两位显然是不合格组织管理项目的部署的。
: 至少你先找几十个人工卖票的模范工人，问问卖票怎么回事啊，
: corner cases啊。不然谈毛的技术啊。卖票可是个技术活啊，这个你们不会不懂吧？
|
s*******y
发帖数: 851 | 69 上来就找老印也在这儿胡说八道？字里行间显出您的无知。
【在 g****t 的大作中提到】
: 假设我是买方，好虫和魏老师作为总工，我选择买谁的?
: 我不懂软件。但十多年前就做过几千万人民币项目买方主要技术人员。
: 现在用直觉和经验随便说说。
: 1.
: 我第一印象会觉得这二位都至少需要个懂的老印才能把项目做成。
: 道理很简单，这个火车卖票，我从最一开始几个月前就说了，必须先需求分析，
: 不然都是瞎整。现在他们总算收敛到需求分析了。一个项目除了技术架构，
: 还有个管理架构。这两位显然是不合格组织管理项目的部署的。
: 至少你先找几十个人工卖票的模范工人，问问卖票怎么回事啊，
: corner cases啊。不然谈毛的技术啊。卖票可是个技术活啊，这个你们不会不懂吧？
|
d***a
发帖数: 13752 | 70 这个写得不错。
【在 g****t 的大作中提到】
: 假设我是买方，好虫和魏老师作为总工，我选择买谁的?
: 我不懂软件。但十多年前就做过几千万人民币项目买方主要技术人员。
: 现在用直觉和经验随便说说。
: 1.
: 我第一印象会觉得这二位都至少需要个懂的老印才能把项目做成。
: 道理很简单，这个火车卖票，我从最一开始几个月前就说了，必须先需求分析，
: 不然都是瞎整。现在他们总算收敛到需求分析了。一个项目除了技术架构，
: 还有个管理架构。这两位显然是不合格组织管理项目的部署的。
: 至少你先找几十个人工卖票的模范工人，问问卖票怎么回事啊，
: corner cases啊。不然谈毛的技术啊。卖票可是个技术活啊，这个你们不会不懂吧？
|
|
|
z*******3
发帖数: 13709 | 71 我压根没兴趣跟老魏讨论
主要是神经病老pa我
烦死了，那就看看吧
原来如此，不就那么一回事嘛
说了三个月，早说要做计数器，然后其他需求剥离
不就完了么？非要自己装半天，搞得好像12306都能搞定一样
我早就说了，呀的小trick就是把复杂的都交给别人
自己的留到最简，问题在于：计数器我还要你来做干什么？
随便找个人都可以做，而且不会跟我计较网卡和网线
就差没算路由了
【在 g****t 的大作中提到】
: 假设我是买方，好虫和魏老师作为总工，我选择买谁的?
: 我不懂软件。但十多年前就做过几千万人民币项目买方主要技术人员。
: 现在用直觉和经验随便说说。
: 1.
: 我第一印象会觉得这二位都至少需要个懂的老印才能把项目做成。
: 道理很简单，这个火车卖票，我从最一开始几个月前就说了，必须先需求分析，
: 不然都是瞎整。现在他们总算收敛到需求分析了。一个项目除了技术架构，
: 还有个管理架构。这两位显然是不合格组织管理项目的部署的。
: 至少你先找几十个人工卖票的模范工人，问问卖票怎么回事啊，
: corner cases啊。不然谈毛的技术啊。卖票可是个技术活啊，这个你们不会不懂吧？
|
l*********s
发帖数: 5409 | |
z*******3
发帖数: 13709 | 73 老魏应该向后生那个1989学习一下怎么做presentation
人家就说了三个字：计数器
老魏全国一盘棋开始，忽悠了三个月
三个字 vs 三个月
三个月其实更接近啊三的忽悠
总之拼命忽悠，没有point
【在 c********l 的大作中提到】
: 看第一段就看不下去了
: 1，找老印，就算是你所谓的“懂”的老印
: 他只是把你脑子里面已经清楚的东西用咖喱味的英语反复说，反复说
: 直到你烦了打断他或者是你自己从清楚变模糊为止。
: 2，中国高铁是全世界最reliable的。
: 在那个后面，西班牙、加拿大都出过出轨事故
: 3，中国企业，不注重网站形象，12306的界面连CSS align都做不好，
: 这是一个问题。但不代表内在质量差。
: 中国企业，包括老魏的公司，需要加强presentation
: 其实花不了什么功夫，用bootstrap就能搞定
|
e**o
发帖数: 5509 | 74 一个做计数器，一个做排号机。
【在 z*******3 的大作中提到】
: 老魏应该向后生那个1989学习一下怎么做presentation
: 人家就说了三个字：计数器
: 老魏全国一盘棋开始，忽悠了三个月
: 三个字 vs 三个月
: 三个月其实更接近啊三的忽悠
: 总之拼命忽悠，没有point
|
z*******3
发帖数: 13709 | 75 所以排队是这里的关键
学名叫异步
你好好琢磨琢磨
不过还不只异步了
还有云计算爆兵流
【在 e**o 的大作中提到】
: 一个做计数器，一个做排号机。
|
z*******3
发帖数: 13709 | 76 老魏也不是没有排队
关键是他用网卡排队
这个绝对是行为艺术
【在 e**o 的大作中提到】
: 一个做计数器，一个做排号机。
|
z*******3
发帖数: 13709 | 77 二爷在这里扯了三个月异步
【在 e**o 的大作中提到】
: 一个做计数器，一个做排号机。
|
e**o
发帖数: 5509 | 78 嗯。当然都得排队。
老魏做的除了排队还得出票。
goodbug做的就是排号机，都不用改进出票系统了。
放票前一个小时，排号机开始收订单，
然后出票系统在发票前半个小时优先处理排号机的单子。
然后放票的时候在放剩下的票。
你认为铁道部会为这个排号机出多少钱？
【在 z*******3 的大作中提到】
: 老魏也不是没有排队
: 关键是他用网卡排队
: 这个绝对是行为艺术
|
z*******3
发帖数: 13709 | 79 哪出票了
别想当然了
就返回一个t/f的结果
其他啥都不做
他可没少砍需求
【在 e**o 的大作中提到】
: 嗯。当然都得排队。
: 老魏做的除了排队还得出票。
: goodbug做的就是排号机，都不用改进出票系统了。
: 放票前一个小时，排号机开始收订单，
: 然后出票系统在发票前半个小时优先处理排号机的单子。
: 然后放票的时候在放剩下的票。
: 你认为铁道部会为这个排号机出多少钱？
|
e**o
发帖数: 5509 | 80 换个说法，老魏的系统能实时确定订单。和现在铁道部的售票系统一样。
这个就是差距。
【在 z*******3 的大作中提到】
: 哪出票了
: 别想当然了
: 就返回一个t/f的结果
: 其他啥都不做
: 他可没少砍需求
|
|
|
z*******3
发帖数: 13709 | 81 排号机本身只是古德霸需求的一部分
整体系统大着呢
一堆需求点要实现
多少钱，能满足需求，铁道部会出不少钱
这行钱多着呢
【在 e**o 的大作中提到】
: 嗯。当然都得排队。
: 老魏做的除了排队还得出票。
: goodbug做的就是排号机，都不用改进出票系统了。
: 放票前一个小时，排号机开始收订单，
: 然后出票系统在发票前半个小时优先处理排号机的单子。
: 然后放票的时候在放剩下的票。
: 你认为铁道部会为这个排号机出多少钱？
|
z*******3
发帖数: 13709 | 82 已经被证伪了，理论上都是错的
谢谢
铁道部现有系统是sybase做的db
你要跟我打赌更靠近谁的系统么？
【在 e**o 的大作中提到】
: 换个说法，老魏的系统能实时确定订单。和现在铁道部的售票系统一样。
: 这个就是差距。
|
z*******3
发帖数: 13709 | 83 real time老魏压根没实现
他想实现的，但是挂了
现在据说改回单线程了，那这个io撑不了多少
【在 e**o 的大作中提到】
: 换个说法，老魏的系统能实时确定订单。和现在铁道部的售票系统一样。
: 这个就是差距。
|
b*******s
发帖数: 5216 | 84 你就少胡扯了
【在 z*******3 的大作中提到】
: 老魏也不是没有排队
: 关键是他用网卡排队
: 这个绝对是行为艺术
|
z*******3
发帖数: 13709 | 85 那就把网卡换掉
【在 b*******s 的大作中提到】
: 你就少胡扯了
|
w*********l
发帖数: 1337 | 86 你确认你知道“图灵完备”这个词的意思吗？
【在 g****t 的大作中提到】
: 不是成本问题。
: 我说了，你的方案不predictable,太特殊。
: 如果我有新的需求过来，你可能要重新设计整个东西。
: 有一种图灵机模型，就是几个箱子挪来挪去。
: 买票占座位的需求是很可能及其复杂的。说不定是图灵完备的都未可知。
: 另外还有桥断路垮，首长出巡，冰雨地震，这些情况，在你的那种设计中，
: 都需要一个个仔细研究。
: 好虫的方案，估计做起来和填空题类似了。
: 好虫的方案容易扩展，with respect to 新需求。
: 而且他懂的折磨屁民提高体系稳定性这个阳光大道。系统不行就加延时。
|
s***o
发帖数: 6934 | 87 lz是屁都不懂的节奏
【在 g****t 的大作中提到】
: 假设我是买方，好虫和魏老师作为总工，我选择买谁的?
: 我不懂软件。但十多年前就做过几千万人民币项目买方主要技术人员。
: 现在用直觉和经验随便说说。
: 1.
: 我第一印象会觉得这二位都至少需要个懂的老印才能把项目做成。
: 道理很简单，这个火车卖票，我从最一开始几个月前就说了，必须先需求分析，
: 不然都是瞎整。现在他们总算收敛到需求分析了。一个项目除了技术架构，
: 还有个管理架构。这两位显然是不合格组织管理项目的部署的。
: 至少你先找几十个人工卖票的模范工人，问问卖票怎么回事啊，
: corner cases啊。不然谈毛的技术啊。卖票可是个技术活啊，这个你们不会不懂吧？
|
