N*n
发帖数: 456 | 1 参考老魏在回oop2帖子里提到的架构
如果 web 请求真那么大，TW得用 100 web serve（甲） + 几个
核心server（乙） + 付账server（丙）来实现了。
你用什么不一样的架构可以更好？
像网友问goodbug G家的那个面试题似的。。最简单，最可靠当然就是
counter 单机实现。 老魏无非是说其中核心多机平行难弄的抢票部分
用特制高性能单机串组足够搞定。 |
|
z****e
发帖数: 54598 | 2 100个够吗？
还有这个就是补丁
app server是老魏一开始的重点
后来陡然发现，哦，原来web server才是重点
所以又开始转向了
所以我一开始就跟他说，app server没问题
有问题的是web server
而且老魏还不承认，说什么理论上app server是唯一的瓶颈 |
|
z****e
发帖数: 54598 | 3 抢票部分你只要用单线程处理
就像老魏那样，你用什么写
其实都无非那么一回事
而且老魏还没有考虑灾难处理
也是别人给打的补丁 |
|
z****e
发帖数: 54598 | 4 少来了，老魏是买买提玩这套的鼻祖
你是不是没看老魏十年前是怎么搞人的
look都快跟丫对薄公堂了
还不知道公共论坛有多险恶 |
|
w*******r
发帖数: 34 | 5 的确，老魏给的法子为啥会有这么大的争议，我觉得最主要原因就是在扩展性和稳定性
的实现上，跟大多数人的认识不一致。
goodbug那个法子是大多数人的都会选择的路，架构分层，数据分区，单机不够就依靠
软件的支持搞分布式，再不行就上云平台，反正大家都这么做，尤其是做网站的，简直
是固定的路子，好不好？挺好的，省心可靠，麻烦都丢给第三方软件商了。
但老魏的法子更有意思，而且看得出他给的思路很多都是已经实现出来的，只是板上众
多平时没机会接触他那类应用，所以显得有点另类，真心觉得他讲了个事实，再上分布
式之前，单机的性能有没有榨取干净？ |
|
w*******r
发帖数: 34 | 6 我明白你意思，追着一台机器搞有点纯属没事找事，对不？早早上的云里，大家都省事
， 哈哈。
要实际动手做，你之前的那些回复都靠铺，说法也没错。但有个问题，不是什么应用都
能往云里搁的，没走到云那一步之前怎么办？咱不是在走项目，早早交付了收款了事，
这不是在说纯技术实现么？
再退一步讲，不卖火车票了，搁到其他应用上，老魏的路子是有很大借鉴意义的。你要
是nasa搞火星车的那帮人，难不成还背个云上火星么？再或者要在google做东西，也能
跟大老板说咱不行就放aws上去跑吧。呵呵，真到这种时候了，老魏的路子就是正路了
，万事靠自己，没有第三方。 |
|
z****e
发帖数: 54598 | 7 总之天下开源是一家
除了c++和.net，其它都会慢慢照顾到
互通有无是必然的
python的东西java以后也能用
tornado什么，用来替换jms不错
还有比起老魏那个自己吭哧吭哧写半天的message server要强一万倍
至少文档比较多，fb还帮忙维护社区
老魏那个也就他自己能看得懂 |
|
z****e
发帖数: 54598 | 8 老魏我跟你的区别在于
我不懂的不会去装懂，你不懂的你会装懂
要不你说说你懂不懂怎么搞website？
我就明说了，你不懂怎么做website，你服气不服气？
你说的恰好就是怎么做website，我告诉你的是
你那一套是不行的，不适合做website
想起当年的一个笑话，老大问，你们上班堵车不堵车啊？
都说很堵，我说，那可以早一点来
老大说，你要是四点来，肯定不会堵
老魏你就是属于那种为了避开堵车，四点就跑来上班的家伙
凡事，过犹不及 |
|
z****e
发帖数: 54598 | 9 老魏压根没有用cluster
是后面吹牛被喷后加上去的
单机是老魏说的，后来做成cluster还是主机，这个是别人给他的建议
他本人还是倾向于用主机的，至少我记得我建议用主机之后，他表达了一定程度的赞同
HP
11 |
|
n****1
发帖数: 1136 | 10 你无非就是想说老中烙印大多自私功利不愿意做贡献嘛? 我同意你的观察. 我回复只是
反击他的倚老卖老(原话是"年头不够肯定能力受限, 还有就是这些稍微年轻点的有一些
不知耻"), 而且表明老魏的贡献不能和apache commitor相比, 你同意么?
我提老魏是因为这是我们讨论的context, 提教授是因为我想说, 倚老卖老他不够资格.
难道我只能回复你的帖子, 不能提自己的评论? 我的帖子带了私货就成是逻辑混
乱么?
懂语法的人都知道"学术界/开源界"是代表并列关系,不是包含关系.你这大堆问号来自
与你的胡搅蛮缠. |
|
n*****t
发帖数: 22014 | 11 来自主题: Programming版 - 真让人捉鸡 老魏划下道了，goodbug 你倒是接招啊。条件设定好，大家都可以测，愿赌服输，完了
也清静了。
你要觉得老魏的设定有陷阱，乘早提。实在没把握，认怂也是回事。成天打滚多没劲啊 |
|
n*****t
发帖数: 22014 | 12 那是内网速度，公网这么干得多少钱？这个公平点讲最好改改，比如 aws 或者 do 上
跑，大概到多少我们认为相当于老魏的 500 万。
当然，老魏觉得可以整我也不反对 |
|
n*****t
发帖数: 22014 | 13 我的方案给过了，比老魏的简单多了。老魏赢了就不用我麻烦了，
哈哈 |
|
i**i
发帖数: 1500 | 14 你正好在老魏的机器上做算法。老魏负责底层服务。 |
|
q*c
发帖数: 9453 | 15 古德吧已经简化成直接请求车次，而不是车站。
但是要满足一个请求里面有多个车次这种联票情况。
我觉得老魏毫无胜算 ～ 你去哪里找 80gb 带宽 的公共服务器啊。 这个测试要么只能
老魏单机内部测 要么就没法测， 大家显然两者都不能接受， |
|
L*****e
发帖数: 8347 | 16 我大概听明白你俩的分歧是啥了。。。我理解老魏的方案就是：
因为是单线程
1. 把所有的请求按时间顺序都读到内存的queue中，然后按顺序处理，每个请求只需要
查询内存数据库，有票就更新内存数据库中所请求路段的所有中间站该车次的票数。这
个查询时间和更新时间只受所请求的路段中的站数影响。。。
2. 一个请求处理完成后，再处理下一个请求。。。
所以老魏的方案要保证，平均1/5m秒的时间内可以处理完一个请求，换句话讲就是1/5m
秒的时间内在内存数据库里可以完成20个站的票数查询以及20个站的票数更新。
从这个方案来讲，多少条线路对performance影响确实不很相关，起码不是线性相关，
线路多只是内存数据库更大，一定程度会加长查询时间。。。 |
|
z****e
发帖数: 54598 | 17 cache机到你本机上还有一段距离
所以老魏就只算本机的时间，而不计算cache机需要的时间
500w/s就只能是本机的效率
分配到cache机上恐怕就是50w/s了
然后汇总到主机上，是500w/s
老魏你这样下去，要多少台机器才能搞定？
给个数吧
章。 |
|
L*****e
发帖数: 8347 | 18 老魏，我下面这么理解你的方案对么？
因为是单线程
1. 把所有的请求按时间顺序都读到内存的queue中，然后按顺序处理，每个请求只需要
查询内存数据库，有票就更新内存数据库中所请求路段的所有中间站该车次的票数。这
个查询时间和更新时间只受所请求的路段中的站数影响。。。
2. 一个请求处理完成后，再处理下一个请求。。。
所以老魏的方案要保证，平均1/5m秒的时间内可以处理完一个请求，换句话讲就是1/5m
秒的时间内在内存数据库里可以完成20个站的票数查询以及20个站的票数更新。
从这个方案来讲，多少条线路对performance影响确实不很相关，起码不是线性相关，
线路多只是内存数据库更大，一定程度会加长查询时间。。。 |
|
z****e
发帖数: 54598 | 19 我没有说你这个错啊
你说的，它不是单线程
我只是告诉你，我计算的条件已经经过处理了
最理想情况，按照4us来算一个core需要执行的指令
对吧
1600指令的话，现在就看老魏要做啥了
有人说老魏的这个1600指令主要浪费在网卡上
发考题你怎么看？ |
|
z****e
发帖数: 54598 | 20 老魏没有锁，千万记住，呀的就是一个计数器
用最简单的原子操作回避了锁的操作
我们都错了，多线程上来就教锁，老魏认为这是错误的
十个图零奖小意思 |
|
|
g*****g
发帖数: 34805 | 22 早说能做5M次的decrement不就完了，12306除了计数器啥也不剩了。连超卖都不用管。 |
|
z****e
发帖数: 54598 | 23 那这个我还有可能会信，但是离12306那还有十万八千里远
压根不是一个东西 |
|
n*****t
发帖数: 22014 | 24 所有前端的操作都一样，到最后性能的问题都集中到加锁上。
我的方案跟老魏的大致思路一样，不过有点小区别。老魏是用计数器，性能达到极致，
可以适用 12306 这种特定的抢票。我的性能比较差，用锁，同时给记录加上一些标志
，比如状态、计时器，等等。首长出行、置标志；屁民抢票，用锁隔离；前端某服务器
当机未按协议相应，清计时器，等等等等
了。 |
|
g****t
发帖数: 31659 | 25 你说的对的。老魏那个没解决的问题很多。
但鉴于抢票是比较独有的铁路需求。
支付是比较常见的很多系统都有的较通用需求。
我给老魏的计数器鼓掌。
现有系统抢票是瓶颈，还是支付是瓶颈？不解决瓶颈，而让上游决堤，下游洪涝灾害更
严重。。。
虽然支付可以延时，但是大量支付请求排队，那么对一大部分支付可能要等上十几分钟
或者几十分钟，如果因为系统原因支付失败，那么订票一样失败，还得重新抢票。。。
买票过程是一个完整的体验，最不能缩短整个买票时间，提高拿票概率，只是局部发达
，是不可行的，或者说离真正实用还差很远。。。
了。
★ 发自iPhone App: ChineseWeb 8.2.2 |
|
z*******3
发帖数: 13709 | 26 老魏应该向后生那个1989学习一下怎么做presentation
人家就说了三个字：计数器
老魏全国一盘棋开始，忽悠了三个月
三个字 vs 三个月
三个月其实更接近啊三的忽悠
总之拼命忽悠，没有point |
|
z*******3
发帖数: 13709 | 27 千万不要说老魏是什么实时订票
他根本没有做那么多
做的就是一个计数器
不要拔高，计数器离订票出票还有一大段距离
计数器只是其中一个功能点而已
就是需求上一句话
这个需求上其他部分都没有实现
就这么一句话的实现，老魏还给写错了
到现在回去搞单线程了，等于前三个月努力白费
三个月了
就整出这么一个东西来
简直是闹剧 |
|
s*******y
发帖数: 851 | 28 好虫的方案比老魏的强，老魏的实际上根本不可行，纯粹技术忽悠型。 |
|
z****e
发帖数: 54598 | 29 这不是行为艺术是什么？
用超级网卡解决大并发的冲突
这不是行为艺术是什么？
这也配叫做流行产品？
如果说古德霸是用流行产品来搭配的话
那这叫过气产品，老魏只知道用过气产品来组合
老魏只知道用过气产品来处理需求
狗屁算法，数据结构
这里面有个球的算法和数据结构
装逼装成傻逼了
洗地有个p用
计数器都敢上，你下一个需求遇到多线程
你试试看用计数器，你老板直接两个耳光扇死你 |
|
z*******3
发帖数: 13709 | 30 根据身份证做一个筛选就行了
取最前面的那个req，剩下相同的订单全部丢弃
同一个ip地址在一分钟内不准多次发送请求
这个你应该看看老魏注册机在做啥
想明白怎么对付老魏的注册机，就知道怎么对付多次发送的请求了
都做烂了 |
|
n*****t
发帖数: 22014 | 31 擦，我这个方案跟古德八吵了几个礼拜了，你骂我剽窃老魏是吧？
其实老魏的算力也是绰绰有余，协议里加个优先级轻松。管网卡的，收到请求扔队列，
打算盘的优先到 VIP 里去拿。
再说了，前段送个 message 说T1 次 all stop selling，我还能偷偷出票不成？ |
|
z*******3
发帖数: 13709 | 32 不过话说老魏比较适合做挖矿机，这个我信
哈哈，他现在做的就跟挖矿机很接近
guvest的建议比我们靠谱，web不需要老魏
并不代表其他行业不需要，可以搞点比特币啥的 |
|
z*******3
发帖数: 13709 | 33 哎
你这个脑子实在是转不过来啊
我问你一个简单的
点拨一下
老魏这个所谓的real time系统
处理一个request要多长时间？先不说做不做得到
你认为real time一般处理一个请求要多长时间？
我算老魏很牛逼吧，2us搞定一个req，好不好？
好，那你这个是12306吧？
公网上一个http req/resp，一般多长时间在路由上？
都不需要算路由
就算一下server拿到请求之后parse head
然后拼凑一下resp head，这恐怕就不止2ms了吧？
对吧？你对比一下这两个数据
就会觉得，你这个real time做出来干嘛用？
果。 |
|
n*****t
发帖数: 22014 | 34 我是用锁的，所以你这个情况我无所谓，能保证出票，性能 1M/s 我把握大大地，你跑
跑我昨天的 hello world 就有大致概念了。
老魏那个如果单线程做也毫无问题，或者颠簸的时候用锁也是一样。当然，老魏可能有
更高效的方案，这我不清楚了。
另外，最优化出票谁都做不到，包括你，上 1000 个 oracle 都做不到 |
|
z*******3
发帖数: 13709 | 35 老魏那个方案要有超级网卡
你怎么搞超级网卡？
而且只是一个很简单的计数器
其他什么都没有
需求的scope就比别人小了几十倍都有
你觉得计数器＝＝订票系统么？
差了十万八千里远
计数器放在db里面也是一个小部件
你都不需要用老魏的，直接找个db就有 |
|
q*c
发帖数: 9453 | 36 来自主题: Programming版 - SPECS 这个合理， 不过 10% 联票， 就算 20-30% 联票， 老魏的模型下也就 20-30%
overhead.
这都从 5MM 到 1MM了， 这点余量老魏应该没问题。 |
|
z*******3
发帖数: 13709 | 37 来自主题: Programming版 - SPECS 如果是这样一个步骤都要30s，我用老魏的干嘛？
用古德霸的都没不会这样，30s停滞的话，顾客直接关网页了
古德霸真是nice，条件这么宽
这简直就是一个web session的expire time了
老魏吹牛的那样，直接给他3ms反应时间都算是抬举他了
应该给3us才对
.. |
|
q*c
发帖数: 9453 | 38 来自主题: Programming版 - SPECS 10% 的票联票，就算一半 4 张 一半 2张 也就 30%。 这不是底线 1 mm 向 5 mm 嘛，
老魏就上吧，也就 1.3 mm 起线。 哪怕最后老魏做了 850k, 就已经非常碉堡了！
而且这样 client 好算 tps。 |
|
L*****e
发帖数: 8347 | 39 真够拧的你俩，可不可以让老魏把东西做出来，然后你老把测试结果拿到，然后再争论
你们俩谁打赌赢了？又不是赢房子赢地，大家就是想看看老魏的方案能把效率做到什么
程度，何必争个你死我活的。。。
,
database
★ 发自iPhone App: ChineseWeb 8.2.2 |
|
L*****e
发帖数: 8347 | 40 这个问题我早就有态度，我很早就表明老魏的东西不能算是一个完整的系统方案，如果
要替代整个系统还有很多很多要做。我觉得他现在做的只是解决一个系统中的一个非常
具体的一个功能的问题。我甚至都在那篇“作为一个有买票体验的用户”的帖子里表明
我觉得抢票不是解决网上买票问题的方向（一开始的设定就错了）。。。
但是我还是很有兴趣看看，老魏的方案能在他所能满足的条件下performance能达到多
少。至于你加的条件或者说你认为本来就应该有的条件之类，我真的不care，这些不过
是些干扰因素使得你们的赌赢或输的概率增大一点变小一点而已（如果发现有什么基本
功能对performance有指数级影响的，我愿意听一听，linear的就算了）。。。
老霸你也是网上的老江湖了，BBS上的输赢真的有那么重要？ |
|
n*****t
发帖数: 22014 | 41 你到底认真看过老魏的方案不？看懂了没？
老魏方案的核心，就是把核心冲突部分做成单节点，一台主机不够多台主机串联分担负
荷同时备份，其他外围的 web db 啥该啥样还啥样，一个不缺。 |
|
c******3
发帖数: 296 | 42 》每台机器管一个车次&车票类型（硬座，卧铺，站票）的分票。
》3000机器因为有冷门车次不均匀算打个折，算1000的并发度就好。
你处理的问题是单机1000的并发？老魏考虑的是单机1000万的并发。你们是在讨论同一
问题吗？
照这样假设，几十年前的486就可以了，每台机器上一个MSAccess都嫌多，就一
flatfile好了。
其实堆机器也可以。但要考虑到热门车次上百万人抢票的。你的方按也没有把同一车次
分到不同个机器上。所以你和老魏本质上都在谈论单机。但你的假设不可行，因为热门
车次抢票的会到上百万并发。冷门车次大家都不会在这废口舌。
所以你还是应该回到本质问题：如何设计卖票系统能处理百万人次同时请求同一车次。 |
|
n*****t
发帖数: 22014 | 43 来自主题: Programming版 - 简单就是美 老说一堆人给老魏打补丁，你见过给古德八打的吗？
无他，古德八那玩意毫无指望，老魏的东西证明怎么都能 pass。你也别不服，我跟古
德八叫板了，他不敢练你出来练也一样。 |
|
z****e
发帖数: 54598 | 44 哈哈，比起你这样原先行当干不下去，需要转行的
是不是好点？
你不是说你不了解么？貌似看了不少嘛
哈哈，都是服务业，谁比谁强多少？
你这个思路没转过来，而且老魏上来就打算写business logic
这个打你的脸都不知道算是怎么打的了
估计你压根没有意识到到老魏在写business logic |
|
z****e
发帖数: 54598 | 45 这次我支持老魏
几个在微软干的
就不要悲愤了
老魏说得对
开源也能创业赚钱
天朝人民可以为此贡献一份力量
哦也
当然开源可能赚不了很多钱
但是能做出来也是进步，也还是能赚钱的
历史上成功过不少开源的企业
比如spring的interface21
比如red hat，比如mysql，比如jboss
比如minecraft，比如android
都在被收购的时候大红大紫了一把
虽然不能赚很多钱，不能像大门一样成为世界首富
但是创始人自身名利双收，未尝不是一个更好的选择
什么不能抄？
backend很多很难抄，因为不直接面向终端用户
所以搞backend更容易在开源这一块做出startup
硅谷很多公司不都是在这一块忙活么？ |
|
z****e
发帖数: 54598 | 46 真不懂假不懂？
LeftEye在微软干
著名的软轮
老魏和古德霸都爱拍微软
而且这一波LeftEye表江湖也表得很勤快
你说小圈子指数怎样？
老姜在说古德霸和qxc在给老魏提供机器
所以指数高一点，这很奇怪么？
这个数据最有价值可能就是让人看看我居然排第七
我估计这个出乎不少人意料 |
|
|
b***e
发帖数: 1419 | 48 你丫这个傻逼又来装逼找打脸。从韩国回来把屁眼修好了？你丫的构架能力是从3/1350
个傻逼专利里吹逼出来的。自己把自己爆的菊裂，都忘了？你丫实战个屁，根本啥系统
都没做过的伪咖喱货。懂几个名词你丫嘚瑟的一屁。这里几个真正的architect，像京
二，半海，caltzhao，有一个像你丫个傻逼整天吧“构架能力”放在嘴上的么？Sorry
，我又说错了，你丫没有嘴，只有屁眼。你丫懂CAP？我操你妈逼的你丫以为CAP是“操
俺屁眼”的缩写了吧？我信你丫懂还不成么？
还有，再重申一遍，你丫没鸡巴的货不要老看这老魏的鸡巴。老魏有没有鸡巴你丫的鸡
巴也长不出来。 |
|
N********n
发帖数: 8363 | 49
你在这里出丑的事还少啊？光是和老魏吵架就放出"HASHTABLE当QUEUE用”的火
车，笑爆肚皮，还自诩很懂ARCHITECT, 老魏大概都忘了。省省吧, HOHO |
|
h****r
发帖数: 2056 | 50 老魏和好虫年纪相当，都是四十出头，谈不上啥糟老头子。
老魏这么激动确实有点过了，可能是因为不习惯好虫这种军版篮球板混出来的
满嘴生殖器脏话的风格，而钻牛角尖了。其实当好虫污言秽语的时候，你把他
说的那些当个屁给放了就算了。除了不得理的时候胡搅蛮缠之外，大多数时候
好虫其实算是个热心肠的人，乐于回答自己能回答的问题，对自己外行的地方
也不插嘴。
网上吵架，屁大的事，不值得伤肝动火. |
|
