b*******g
发帖数: 603 | 1 两个cluster.
一个上随便多台机器，从cassandra读取订单。简单验证单子有效性等，然后发到分票
的cluster.
上3000台机器分票，每台机器管一个车次&车票类型（硬座，卧铺，站票）的分票。
对于联票，request并发发给两台不同机器，都成功返回后写入数据库。一个成功一个
不成功则发撤销request.
分票只需要在内存里搜索，单线程即可，1000张票，20段，简单的O(N) bruteforce算
法即可，还可以满足多票，保证满足同车厢，尽量满足连号没问题。有多少规则，支持
多少规则。分票结果无锁写入后台数据库，无冲突极快。
异步通知另外一个线程合并数据库结果，从数据库里读出分配座位信息，更新座位覆盖
状况。并定时(比如5秒）更新分票服务器内存。
对于所有可能的网络问题，硬件问题，导致分票结果不能存入数据库。不会有重票错票
，会暂时丢票。5秒后跟数据库sync恢复。
像这样的架构能达到什么样的分票速度？
如果一个单张票分票算法只能到0.1ms, 太监的单机单线程算法只能分10000张票。我这
个算网络延迟0.1ms, 一个单子2张票，0.2ms, 联票并发进行无影响，所以是0.3ms,
3000机器因为有冷门车次不均匀算打个折，算1000的并发度就好。
0.3ms -> 3000单机＊1000, 300万单 ＝ 600万票，
轻松秒了宇宙第一的太监算法妥妥的。真要实时，像我这么分布式分票才是王道。做客
户端的就会上硬件，压榨性能，挖空心思想算法。我这单票搜索哪怕比他慢100倍，最
后都轻松秒它6倍的速度没压力。
我举3000台机器就是直观一点，其实大约就跑两个线程，一台机器可以撑一堆线路。 |
t**********1
发帖数: 550 | 2 傻逼，知道你这个帖子错在哪里么？
【在 b*******g 的大作中提到】
: 两个cluster.
: 一个上随便多台机器，从cassandra读取订单。简单验证单子有效性等，然后发到分票
: 的cluster.
: 上3000台机器分票，每台机器管一个车次&车票类型（硬座，卧铺，站票）的分票。
: 对于联票，request并发发给两台不同机器，都成功返回后写入数据库。一个成功一个
: 不成功则发撤销request.
: 分票只需要在内存里搜索，单线程即可，1000张票，20段，简单的O(N) bruteforce算
: 法即可，还可以满足多票，保证满足同车厢，尽量满足连号没问题。有多少规则，支持
: 多少规则。分票结果无锁写入后台数据库，无冲突极快。
: 异步通知另外一个线程合并数据库结果，从数据库里读出分配座位信息，更新座位覆盖
|
L*****e
发帖数: 8347 | 3 赞详细，不过没提数据库大概怎么建，是所有的都一个数据库?还是一个车次一个数据
哭?
【在 b*******g 的大作中提到】
: 两个cluster.
: 一个上随便多台机器，从cassandra读取订单。简单验证单子有效性等，然后发到分票
: 的cluster.
: 上3000台机器分票，每台机器管一个车次&车票类型（硬座，卧铺，站票）的分票。
: 对于联票，request并发发给两台不同机器，都成功返回后写入数据库。一个成功一个
: 不成功则发撤销request.
: 分票只需要在内存里搜索，单线程即可，1000张票，20段，简单的O(N) bruteforce算
: 法即可，还可以满足多票，保证满足同车厢，尽量满足连号没问题。有多少规则，支持
: 多少规则。分票结果无锁写入后台数据库，无冲突极快。
: 异步通知另外一个线程合并数据库结果，从数据库里读出分配座位信息，更新座位覆盖
|
L*****e
发帖数: 8347 | 4 消气消气。。。
【在 t**********1 的大作中提到】
: 傻逼，知道你这个帖子错在哪里么？
|
b*******g
发帖数: 603 | 5 回qxc的问题，关于数据库模型。
数据库主要就是三个表, 把座位用个bitmap实现，其余的没什么滑头。
Line
id，line number, sequence number, start, end
0 K1 0 beijing tianjin
1 K1 1 tianjin hefei
21 K2 0 shanghai ....
Seat
id, line id, car id, seat # in car, seat type, date, occupy_vector
booked_seat
id， user_id, seat_id, start, end, booked_vector, date |
n*****t
发帖数: 22014 | 6 LOL
【在 b*******g 的大作中提到】
: 回qxc的问题，关于数据库模型。
: 数据库主要就是三个表, 把座位用个bitmap实现，其余的没什么滑头。
: Line
: id，line number, sequence number, start, end
: 0 K1 0 beijing tianjin
: 1 K1 1 tianjin hefei
: 21 K2 0 shanghai ....
: Seat
: id, line id, car id, seat # in car, seat type, date, occupy_vector
: booked_seat
|
n*****t
发帖数: 22014 | 7 数据库搞不定了抄我们算法，你好歹给个实现啊
【在 b*******g 的大作中提到】
: 回qxc的问题，关于数据库模型。
: 数据库主要就是三个表, 把座位用个bitmap实现，其余的没什么滑头。
: Line
: id，line number, sequence number, start, end
: 0 K1 0 beijing tianjin
: 1 K1 1 tianjin hefei
: 21 K2 0 shanghai ....
: Seat
: id, line id, car id, seat # in car, seat type, date, occupy_vector
: booked_seat
|
t**********1
发帖数: 550 | 8 买了联票会reserve单张票，如果有其它单张票请求就会被拒绝。
不是还指出过我的计数器震荡问题吗？没张记性？
不是正确性一定要保证么？不是性能要按照最差的算吗？
我看，丫3000台机器，每秒能上千就不错了。
给我台96核单机，我6000万都没问题。
【在 L*****e 的大作中提到】
: 消气消气。。。
|
b*******g
发帖数: 603 | 9 给你96核也是96核的并发度，俺这个是3000的并发度呀。哈哈，强了无数倍。
【在 t**********1 的大作中提到】
: 买了联票会reserve单张票，如果有其它单张票请求就会被拒绝。
: 不是还指出过我的计数器震荡问题吗？没张记性？
: 不是正确性一定要保证么？不是性能要按照最差的算吗？
: 我看，丫3000台机器，每秒能上千就不错了。
: 给我台96核单机，我6000万都没问题。
|
n*****t
发帖数: 22014 | 10 你干脆每个座位一台服务器算了
【在 b*******g 的大作中提到】
: 给你96核也是96核的并发度，俺这个是3000的并发度呀。哈哈，强了无数倍。
|
|
|
t**********1
发帖数: 550 | 11 你这个傻逼，明白次序依赖性的问题吗？
我的单机都带调度器，你提都不提，明显根本没概念。
调度器也解决不了worst case。还是要看单机性能。
【在 b*******g 的大作中提到】
: 给你96核也是96核的并发度，俺这个是3000的并发度呀。哈哈，强了无数倍。
|
b*******g
发帖数: 603 | 12 依赖个头呀，你所有多核能做的，俺这个也能做，无非就是分到了更多的机器上。
你丫弄了三个月的计数器，上来被我秒了30倍，不丢人吗？
【在 t**********1 的大作中提到】
: 你这个傻逼，明白次序依赖性的问题吗？
: 我的单机都带调度器，你提都不提，明显根本没概念。
: 调度器也解决不了worst case。还是要看单机性能。
|
t**********1
发帖数: 550 | 13 傻逼，依赖性导致worst case是串行。比的是通信开销。我的是1m每秒，你的是多少？
【在 b*******g 的大作中提到】
: 依赖个头呀，你所有多核能做的，俺这个也能做，无非就是分到了更多的机器上。
: 你丫弄了三个月的计数器，上来被我秒了30倍，不丢人吗？
|
L*****e
发帖数: 8347 | 14 但是别忘了他还有个waiting list，而且出票时是异步出票。联票reserver单张票，最
后购票失败返回reserver的票时，waiting list里的就买上了。。。
当然这只是一定程度上减轻问题而已，如果waiting list里的请求也是要买联票的，然
后连锁反应。。。
【在 t**********1 的大作中提到】
: 买了联票会reserve单张票，如果有其它单张票请求就会被拒绝。
: 不是还指出过我的计数器震荡问题吗？没张记性？
: 不是正确性一定要保证么？不是性能要按照最差的算吗？
: 我看，丫3000台机器，每秒能上千就不错了。
: 给我台96核单机，我6000万都没问题。
|
i**i
发帖数: 1500 | 15 联票可以有多种联法. 不断重试会产生无效请求. 影响正常出票.
另外, 如果某人买票, 不太会在意什么票, 甚至有座没座. 目前的分库分得太细了. |
t**********1
发帖数: 550 | 16 和waiting list无关。
联票紧跟着一个单张都可能失败。
【在 L*****e 的大作中提到】
: 但是别忘了他还有个waiting list，而且出票时是异步出票。联票reserver单张票，最
: 后购票失败返回reserver的票时，waiting list里的就买上了。。。
: 当然这只是一定程度上减轻问题而已，如果waiting list里的请求也是要买联票的，然
: 后连锁反应。。。
|
L*****e
发帖数: 8347 | 17 照你的方案，数据库也可为每个车次分建在1000个机子上。。。
【在 b*******g 的大作中提到】
: 回qxc的问题，关于数据库模型。
: 数据库主要就是三个表, 把座位用个bitmap实现，其余的没什么滑头。
: Line
: id，line number, sequence number, start, end
: 0 K1 0 beijing tianjin
: 1 K1 1 tianjin hefei
: 21 K2 0 shanghai ....
: Seat
: id, line id, car id, seat # in car, seat type, date, occupy_vector
: booked_seat
|
c******3
发帖数: 296 | 18 》每台机器管一个车次&车票类型（硬座，卧铺，站票）的分票。
》3000机器因为有冷门车次不均匀算打个折，算1000的并发度就好。
你处理的问题是单机1000的并发？老魏考虑的是单机1000万的并发。你们是在讨论同一
问题吗？
照这样假设，几十年前的486就可以了，每台机器上一个MSAccess都嫌多，就一
flatfile好了。
其实堆机器也可以。但要考虑到热门车次上百万人抢票的。你的方按也没有把同一车次
分到不同个机器上。所以你和老魏本质上都在谈论单机。但你的假设不可行，因为热门
车次抢票的会到上百万并发。冷门车次大家都不会在这废口舌。
所以你还是应该回到本质问题：如何设计卖票系统能处理百万人次同时请求同一车次。 |
b*******g
发帖数: 603 | 19 你也够不要脸的，上次500万次跨DC， 延迟微妙级，我这同一DC, 就在一个rack上，延
迟0.1ms都不行。
【在 t**********1 的大作中提到】
: 傻逼，依赖性导致worst case是串行。比的是通信开销。我的是1m每秒，你的是多少？
|
L*****e
发帖数: 8347 | 20 是失败了，然后排进了waitinglist里，等到前面联票失败了，返回reserve的票，
waitinglist里就买到了。可以说中间结果错误，但最终结果还是正确了。。。
【在 t**********1 的大作中提到】
: 和waiting list无关。
: 联票紧跟着一个单张都可能失败。
|
|
|
b*******g
发帖数: 603 | 21 你错了，我们是在讨论一个系统。它不会做分布式的，我会，性能秒杀它不是很正常吗？
如果百万人都抢的同一车次，我的性能的确不会比他的更好。但是我前端单子存起来了，
我可以慢慢搞，我没有实时要求，不会处理不了就丢单，这就是优越之处。
【在 c******3 的大作中提到】
: 》每台机器管一个车次&车票类型（硬座，卧铺，站票）的分票。
: 》3000机器因为有冷门车次不均匀算打个折，算1000的并发度就好。
: 你处理的问题是单机1000的并发？老魏考虑的是单机1000万的并发。你们是在讨论同一
: 问题吗？
: 照这样假设，几十年前的486就可以了，每台机器上一个MSAccess都嫌多，就一
: flatfile好了。
: 其实堆机器也可以。但要考虑到热门车次上百万人抢票的。你的方按也没有把同一车次
: 分到不同个机器上。所以你和老魏本质上都在谈论单机。但你的假设不可行，因为热门
: 车次抢票的会到上百万并发。冷门车次大家都不会在这废口舌。
: 所以你还是应该回到本质问题：如何设计卖票系统能处理百万人次同时请求同一车次。
|
t**********1
发帖数: 550 | 22 还是买不到，被随后的买到了。
人家先来的等一天买不到，被后到的买到了。
不得操他古德八100遍？
【在 L*****e 的大作中提到】
: 是失败了，然后排进了waitinglist里，等到前面联票失败了，返回reserve的票，
: waitinglist里就买到了。可以说中间结果错误，但最终结果还是正确了。。。
|
c******3
发帖数: 296 | 23 》如果百万人都抢的同一车次，我的性能的确不会比他的更好
好虫还是挺谦虚的。
这样的话，我建议热门车次交给老魏做，冷门车次分发到你的机群里，这样你的虽然不
是实时，但也不会等多长。你俩就别吵了。
吗？
了，
【在 b*******g 的大作中提到】
: 你错了，我们是在讨论一个系统。它不会做分布式的，我会，性能秒杀它不是很正常吗？
: 如果百万人都抢的同一车次，我的性能的确不会比他的更好。但是我前端单子存起来了，
: 我可以慢慢搞，我没有实时要求，不会处理不了就丢单，这就是优越之处。
|
b*******g
发帖数: 603 | 24 太监你又气急败坏了，弄了三个月就弄个计数器，还被我秒了30次。
我那个不会想你那样震荡，因为是异步的。如果有ABC和AB, 99.99%的订单都是ABC，而
BC卖完了。
数据库的snapshot就保证了前面那个cluster就看到BC余票为0，根本不提交订单到后面
的cluster上。
所以0.01%的订单很快就成功了。
【在 t**********1 的大作中提到】
: 还是买不到，被随后的买到了。
: 人家先来的等一天买不到，被后到的买到了。
: 不得操他古德八100遍？
|
b*******g
发帖数: 603 | 25 实践中，哪怕不考虑冷门车次，热门车次有10种，我就秒它10倍。当然游泳。
另外，单子无限，票子有限，都卖完了我就不用卖了。你说的只有订单过来反复出不了
票，我的才会跟它的一样。
实际上单车次，大家很快卖完了后面不找了。
【在 c******3 的大作中提到】
: 》如果百万人都抢的同一车次，我的性能的确不会比他的更好
: 好虫还是挺谦虚的。
: 这样的话，我建议热门车次交给老魏做，冷门车次分发到你的机群里，这样你的虽然不
: 是实时，但也不会等多长。你俩就别吵了。
:
: 吗？
: 了，
|
t**********1
发帖数: 550 | 26 傻逼，你连我说的是啥都看不明白。
继续秀智商下限。
【在 b*******g 的大作中提到】
: 太监你又气急败坏了，弄了三个月就弄个计数器，还被我秒了30次。
: 我那个不会想你那样震荡，因为是异步的。如果有ABC和AB, 99.99%的订单都是ABC，而
: BC卖完了。
: 数据库的snapshot就保证了前面那个cluster就看到BC余票为0，根本不提交订单到后面
: 的cluster上。
: 所以0.01%的订单很快就成功了。
|
b*******g
发帖数: 603 | 27 你这个傻逼弱智，三个月弄个计数器被我秒了30倍，智商没有比你更低的了。
【在 t**********1 的大作中提到】
: 傻逼，你连我说的是啥都看不明白。
: 继续秀智商下限。
|
t**********1
发帖数: 550 | 28 你这辈子算完了。
如果被nflx雷了，你吃屎都抢不到热乎的。
【在 b*******g 的大作中提到】
: 你这个傻逼弱智，三个月弄个计数器被我秒了30倍，智商没有比你更低的了。
|
L*****e
发帖数: 8347 | 29 那就对于被reserve的票，随后的都wait，直到这张票有结果了再说。。。当然，这样
worst case是比较糟糕，因为可能产生一连锁的wait。不过在实际中一连锁的wait机率
会非常小，不会对performance产生太大影响。。。
【在 t**********1 的大作中提到】
: 还是买不到，被随后的买到了。
: 人家先来的等一天买不到，被后到的买到了。
: 不得操他古德八100遍？
|
t**********1
发帖数: 550 | 30 我单机抢票，都是12核并行带调度器，每核接近1m，都不愿claim 1m的指标。
实际上，都是放票就抢的。
丫根本就没有数据依赖的概念，调度都没提。剩下的根本不用看。
他那个设计毛病多了。拿C*当messaging queue用，你们这些傻逼还捧场。这简直是一
锤走天下的。没见过这么傻逼的。
【在 L*****e 的大作中提到】
: 那就对于被reserve的票，随后的都wait，直到这张票有结果了再说。。。当然，这样
: worst case是比较糟糕，因为可能产生一连锁的wait。不过在实际中一连锁的wait机率
: 会非常小，不会对performance产生太大影响。。。
|
|
|
L*****e
发帖数: 8347 | 31 这个呢，恐怕双方都要改变一下态度。绝大部分情况下（你看我说话多谨慎），一个设
计不会完美无缺，或者说不会是做出了完美的trade off，所以看到别人的设计时，自
然会看到很多缺陷。。。
看到缺陷后，我觉得一个比较积极的态度是想怎么样去improve这个设计，怎么样去调
整trade off，而不是先把对方的设计贬为一堆屎。。。看到大部分板油（我又一次说
话谨慎）积极地为双方的方案打补丁，大概就是出于这种积极态度，和捧谁的场，捧谁
的臭脚没关系。大部分板油和您二位也往日无怨，近日无仇的（我其实和古德霸应该算
近日无怨，往日有仇的，坛子里大家都知道），也不会刻意捧谁踩谁。。。
具体到你们的这次争执，后面大部分争执已经是在做意气之争了，对真正的设计讨论和
学习已经营养不多，甚至误导新人。比如说什么0出错率啦，还有的板油说的好的程序
员就不能容忍1%的出错可能啦，还有魏老您说的技术人员要在技术上把东西做到极限啦
，等等等等。。。
做过设计的人就知道，系统设计一开始就要考虑容错率，避免1%的出错率可能要多花20
%的资源，设计也要考虑不能over engineering，做到极限理论上大家玩玩可以，用来
比评设计优劣就偏颇了，客户要求是最少的花费达到满足的要求，多花一分钱实现了一
个程序员自己觉得很fancy但是对于用户来讲没有意义的功能就是在浪费，是在忽悠用
户。。。
anyway，到现在我觉得你们的赌也没啥意义了，很大可能最后不了了之，或者即使有某
种形式的测试结果出来，一样是各有各的解读，都觉得自己是赢家。不客气点讲，网上
打赌这种事本来就有点。。。算了，不说了，我这人还真不会不客气地说话。。。
★ 发自iPhone App: ChineseWeb 8.2.2
★ 发自iPhone App: ChineseWeb 8.2.2
【在 t**********1 的大作中提到】
: 我单机抢票，都是12核并行带调度器，每核接近1m，都不愿claim 1m的指标。
: 实际上，都是放票就抢的。
: 丫根本就没有数据依赖的概念，调度都没提。剩下的根本不用看。
: 他那个设计毛病多了。拿C*当messaging queue用，你们这些傻逼还捧场。这简直是一
: 锤走天下的。没见过这么傻逼的。
|
w**z
发帖数: 8232 | 32 这个必须顶。
【在 L*****e 的大作中提到】
: 这个呢，恐怕双方都要改变一下态度。绝大部分情况下（你看我说话多谨慎），一个设
: 计不会完美无缺，或者说不会是做出了完美的trade off，所以看到别人的设计时，自
: 然会看到很多缺陷。。。
: 看到缺陷后，我觉得一个比较积极的态度是想怎么样去improve这个设计，怎么样去调
: 整trade off，而不是先把对方的设计贬为一堆屎。。。看到大部分板油（我又一次说
: 话谨慎）积极地为双方的方案打补丁，大概就是出于这种积极态度，和捧谁的场，捧谁
: 的臭脚没关系。大部分板油和您二位也往日无怨，近日无仇的（我其实和古德霸应该算
: 近日无怨，往日有仇的，坛子里大家都知道），也不会刻意捧谁踩谁。。。
: 具体到你们的这次争执，后面大部分争执已经是在做意气之争了，对真正的设计讨论和
: 学习已经营养不多，甚至误导新人。比如说什么0出错率啦，还有的板油说的好的程序
|
c******3
发帖数: 296 | 33 你和老魏的方按相同支处就是都用单线程在单机内存里搜索分票，而且都用bitmap实现
。但你的设计里N张联票就要发给N台机器。你怎么维护distributed transaction?还是
你所有机器只用同一个数据库？
【在 b*******g 的大作中提到】
: 两个cluster.
: 一个上随便多台机器，从cassandra读取订单。简单验证单子有效性等，然后发到分票
: 的cluster.
: 上3000台机器分票，每台机器管一个车次&车票类型（硬座，卧铺，站票）的分票。
: 对于联票，request并发发给两台不同机器，都成功返回后写入数据库。一个成功一个
: 不成功则发撤销request.
: 分票只需要在内存里搜索，单线程即可，1000张票，20段，简单的O(N) bruteforce算
: 法即可，还可以满足多票，保证满足同车厢，尽量满足连号没问题。有多少规则，支持
: 多少规则。分票结果无锁写入后台数据库，无冲突极快。
: 异步通知另外一个线程合并数据库结果，从数据库里读出分配座位信息，更新座位覆盖
|
h*****a
发帖数: 1718 | 34 赞左兄说的靠谱。
【在 L*****e 的大作中提到】
: 这个呢，恐怕双方都要改变一下态度。绝大部分情况下（你看我说话多谨慎），一个设
: 计不会完美无缺，或者说不会是做出了完美的trade off，所以看到别人的设计时，自
: 然会看到很多缺陷。。。
: 看到缺陷后，我觉得一个比较积极的态度是想怎么样去improve这个设计，怎么样去调
: 整trade off，而不是先把对方的设计贬为一堆屎。。。看到大部分板油（我又一次说
: 话谨慎）积极地为双方的方案打补丁，大概就是出于这种积极态度，和捧谁的场，捧谁
: 的臭脚没关系。大部分板油和您二位也往日无怨，近日无仇的（我其实和古德霸应该算
: 近日无怨，往日有仇的，坛子里大家都知道），也不会刻意捧谁踩谁。。。
: 具体到你们的这次争执，后面大部分争执已经是在做意气之争了，对真正的设计讨论和
: 学习已经营养不多，甚至误导新人。比如说什么0出错率啦，还有的板油说的好的程序
|
b*******g
发帖数: 603 | 35 不需要维护distributed transaction, 订票都成功了以一个transaction发给DB并且写
入的才是成功的。每
过一段时间，用DB的数据sync 分票服务器。DB才是source of truth, 由于网络错误，
硬件错误没有写入DB而丢掉的票会重新出来。
换句话说，分票服务器保证不会错票，重票。DB sync保证不会丢票。
这不是完全公平的，比如网络丢包造成retry，有可能导致后面的人先上去拿到票。但
所有分布式排队都没有严格意义的公平。
【在 c******3 的大作中提到】
: 你和老魏的方按相同支处就是都用单线程在单机内存里搜索分票，而且都用bitmap实现
: 。但你的设计里N张联票就要发给N台机器。你怎么维护distributed transaction?还是
: 你所有机器只用同一个数据库？
|
c******3
发帖数: 296 | 36 这样所有机器只能用同一个数据库了。单一数据库就成为瓶径。3000台机器一起写，数
据库就发呆了。怎么达到6M/s?
【在 b*******g 的大作中提到】
: 不需要维护distributed transaction, 订票都成功了以一个transaction发给DB并且写
: 入的才是成功的。每
: 过一段时间，用DB的数据sync 分票服务器。DB才是source of truth, 由于网络错误，
: 硬件错误没有写入DB而丢掉的票会重新出来。
: 换句话说，分票服务器保证不会错票，重票。DB sync保证不会丢票。
: 这不是完全公平的，比如网络丢包造成retry，有可能导致后面的人先上去拿到票。但
: 所有分布式排队都没有严格意义的公平。
|
b*******g
发帖数: 603 | 37 Because you can write the result locally, merge the result and write to DB
in batch.
At 1000 concurrency level, you can issue 10 writes every second for each
node and it's only 10K write for the DB. Don't forget the write for
different lines don't conflict one another.
There won't be much wait in DB. It's kept in one DB to satisfy 10% multiple
stop tickets.
【在 c******3 的大作中提到】
: 这样所有机器只能用同一个数据库了。单一数据库就成为瓶径。3000台机器一起写，数
: 据库就发呆了。怎么达到6M/s?
|
h**********c
发帖数: 4120 | 38 First, we talk something only based on tech:
let's say they are not virtual machines,
one normal cabinet ,say, we put twenty blade servers (already too much), 10
units.
one switch 48 ports, each server two nics or one nics.
How to stack the switches?
Let's say if I can repeat your plan, one machine 10k, two machines 20k, if
my three machines do 30k, I believe you.
But for me 30 machines are already difficult. |
n*****t
发帖数: 22014 | 39 古德八，你能贴个实现不？好歹给个表设计、伪码啥的，说了半天没干货啊
比如你要求的碎片最小化？
multiple
【在 b*******g 的大作中提到】
: Because you can write the result locally, merge the result and write to DB
: in batch.
: At 1000 concurrency level, you can issue 10 writes every second for each
: node and it's only 10K write for the DB. Don't forget the write for
: different lines don't conflict one another.
: There won't be much wait in DB. It's kept in one DB to satisfy 10% multiple
: stop tickets.
|
h**********c
发帖数: 4120 | 40 my point is that, maybe it is wrong,
when you stack up the servers/switches, there must be a central switch, that
is
the bottle neck of the network.
maybe there are equipments can overcome this.
The bandwith is not each nic max bw. But the central switch's divided by the
sub pivots. Not very clear how to describe this model. Welcome corrections! |
|
|
b*******g
发帖数: 603 | 41 这是说明怎么scale out, 具体怎么实现单线路分票，你咋实现，我也能实现呀。我有
这么高的并发，单查找慢点也没啥。
我老说过的，去jobhunting找个newgrad算法都比太监强。
【在 n*****t 的大作中提到】
: 古德八，你能贴个实现不？好歹给个表设计、伪码啥的，说了半天没干货啊
: 比如你要求的碎片最小化？
:
: multiple
|
n*****t
发帖数: 22014 | 42 QXC 今天再找这个数据库实现，你给解解？就用 SQL，大家学习学习
【在 b*******g 的大作中提到】
: 这是说明怎么scale out, 具体怎么实现单线路分票，你咋实现，我也能实现呀。我有
: 这么高的并发，单查找慢点也没啥。
: 我老说过的，去jobhunting找个newgrad算法都比太监强。
|
b*******g
发帖数: 603 | 43 表我都给出来了，你不会写SQL?
【在 n*****t 的大作中提到】
: QXC 今天再找这个数据库实现，你给解解？就用 SQL，大家学习学习
|
n*****t
发帖数: 22014 | 44 赞机智啊，自己不会写先反问对方
【在 b*******g 的大作中提到】
: 表我都给出来了，你不会写SQL?
|
