w********m
发帖数: 1137 | 1 魏老师是用C++做高频交易的， 要谈单机并发
古德吧是用java做云service的，要谈多机并发
当然谈不到一块，就开始互砍了。
然后板上的C＋＋党和java党迅速站队。
比如赵蜥蜴是java党
wdong是C＋＋党
C++党和Java党炒的不可开交
.net党笑而不语。 |
b*******g
发帖数: 603 | 2 不叫党争，就是一堆外行叫嚣着要做永动机，被打脸了而已。我从来不掺和什么高频，
不会。高频也不是什么单机高并发，又不是做 exchange. client端下几个单而已。
就太监这背景，要做12306这样公认的业内难题，自然就做成了太监计数器。一堆外行
跟着被打脸。到现在不服气。
说到底，就是隔行如隔山，人贵有自知之明而已。
【在 w********m 的大作中提到】
: 魏老师是用C++做高频交易的， 要谈单机并发
: 古德吧是用java做云service的，要谈多机并发
: 当然谈不到一块，就开始互砍了。
: 然后板上的C＋＋党和java党迅速站队。
: 比如赵蜥蜴是java党
: wdong是C＋＋党
: C++党和Java党炒的不可开交
: .net党笑而不语。
|
t**********1
发帖数: 550 | 3 你造谣毛病改不了了。就冲这个，一定要搞你。
你尽情表演，让大家看看你的嘴脸。
你没发现帮你说话的越来越少了么？
【在 b*******g 的大作中提到】
: 不叫党争，就是一堆外行叫嚣着要做永动机，被打脸了而已。我从来不掺和什么高频，
: 不会。高频也不是什么单机高并发，又不是做 exchange. client端下几个单而已。
: 就太监这背景，要做12306这样公认的业内难题，自然就做成了太监计数器。一堆外行
: 跟着被打脸。到现在不服气。
: 说到底，就是隔行如隔山，人贵有自知之明而已。
|
b*******g
发帖数: 603 | 4 该说的都说完了呗，我该说的也都说完了。反正你尿遁是一次又一次的。你在这个版上
做跳梁小丑刷版面有用吗？仍然是没卵蛋的东西。
【在 t**********1 的大作中提到】
: 你造谣毛病改不了了。就冲这个，一定要搞你。
: 你尽情表演，让大家看看你的嘴脸。
: 你没发现帮你说话的越来越少了么？
|
t**********1
发帖数: 550 | 5 以前帮你的。现在都不齿你了。
撺掇着要我办了你。
http://www.mitbbs.com/article_t/Programming/31456801.html
既然如此，我就有正经事情忙了。
【在 b*******g 的大作中提到】
: 该说的都说完了呗，我该说的也都说完了。反正你尿遁是一次又一次的。你在这个版上
: 做跳梁小丑刷版面有用吗？仍然是没卵蛋的东西。
|
a*********a
发帖数: 3656 | 6 咱不懂就别乱说，好不好？
【在 b*******g 的大作中提到】
: 该说的都说完了呗，我该说的也都说完了。反正你尿遁是一次又一次的。你在这个版上
: 做跳梁小丑刷版面有用吗？仍然是没卵蛋的东西。
|
B********r
发帖数: 397 | 7 还.net 党。。。 谁tmd理你。。。
【在 w********m 的大作中提到】
: 魏老师是用C++做高频交易的， 要谈单机并发
: 古德吧是用java做云service的，要谈多机并发
: 当然谈不到一块，就开始互砍了。
: 然后板上的C＋＋党和java党迅速站队。
: 比如赵蜥蜴是java党
: wdong是C＋＋党
: C++党和Java党炒的不可开交
: .net党笑而不语。
|
b*******g
发帖数: 603 | 8 你觉得我说得不对就出来指正。话说一半有劲吗？
【在 a*********a 的大作中提到】
: 咱不懂就别乱说，好不好？
|
z****e
发帖数: 54598 | |
s********i
发帖数: 145 | 10 问题是单机的 scalability 很有限，就是C++实现的系统，用户数超过 1个M，也得上
群好不好...
我就问一个最基本的问题，单机怎么响应 1M/s的 http / tcp / udp request? 我们的
服务器128G内存，32盒，5000/s最高了，再高网络带宽都不够
我们这最快的一个专用数据库， C++实现的，就是通过一个用户账号 查询 用户存储服
务器的IP 和一个整形的flag, 还有几个GUID, 简单吧。每台服务器就能响应 1k/s 的
查询，当然速度很快，基本1ms之内有结果，所有的Latency基本都是网络传输的
latency |
|
|
s********i
发帖数: 145 | 11 刚看了一下 是16CORE. 纠正一下 省得有人纠结这个问题 |
n****j
发帖数: 1708 | 12 首先，不是单机做数据库。其次，单机 1m/s tcp request 不是什么难题，看什么类型
的 request 了。
【在 s********i 的大作中提到】
: 问题是单机的 scalability 很有限，就是C++实现的系统，用户数超过 1个M，也得上
: 群好不好...
: 我就问一个最基本的问题，单机怎么响应 1M/s的 http / tcp / udp request? 我们的
: 服务器128G内存，32盒，5000/s最高了，再高网络带宽都不够
: 我们这最快的一个专用数据库， C++实现的，就是通过一个用户账号 查询 用户存储服
: 务器的IP 和一个整形的flag, 还有几个GUID, 简单吧。每台服务器就能响应 1k/s 的
: 查询，当然速度很快，基本1ms之内有结果，所有的Latency基本都是网络传输的
: latency
|
s********i
发帖数: 145 | 13 那你告诉我，你所有跟票有关的数据放哪，怎么访问？
你所有处理中的请求怎么persist? 万一服务器crash了呢？
你的单机服务器是直接面向用户的吗？
【在 n****j 的大作中提到】
: 首先，不是单机做数据库。其次，单机 1m/s tcp request 不是什么难题，看什么类型
: 的 request 了。
|
n****j
发帖数: 1708 | 14 当然不是之间面对客户，这还用问？简单说架构是这样：
1、前端处理查询，用户选定车次
2、抢票鸡给对应车票加锁，提交订单，pass 给后端
3、支付成功，后端出票
抢票鸡的作用，就是跨 DB 给记录上锁，主要应付联票情况，解决强耦合问题。至于支
付等等，仍然是现有系统做，只不过可以无限 scale 了。
如果你理解了这个概念，其他都不是问题。
【在 s********i 的大作中提到】
: 那你告诉我，你所有跟票有关的数据放哪，怎么访问？
: 你所有处理中的请求怎么persist? 万一服务器crash了呢？
: 你的单机服务器是直接面向用户的吗？
|
s********i
发帖数: 145 | 15 我不管你联票不联票，既然你有至少三个role,我问你最简单的情况， 用户 client 端
发出一个请求，到你的前端，前端再proxy到抢票机，抢票机再查询后端有没有票，再
把结果返回到前端，前端把结果返回到client.这个过程中你一台机器怎么可能有这么
大的throughput? |
n****j
发帖数: 1708 | 16 抢票鸡不需要去查询后端，因为自己就保存了所有票的状态。一趟车算有 64 段，每段
有票没票用一个 bit，简单做几个索引的话，查票不过是 64b 的 bit mask op，算力
绰绰有余。
再省力点，查询甚至都不需要跟抢票鸡打交道。用户选定了车次，前端可以直接跟后端
管这个车次的 DB 查。再再省力，非联程票只需要更新抢票鸡状态就可以了。
【在 s********i 的大作中提到】
: 我不管你联票不联票，既然你有至少三个role,我问你最简单的情况， 用户 client 端
: 发出一个请求，到你的前端，前端再proxy到抢票机，抢票机再查询后端有没有票，再
: 把结果返回到前端，前端把结果返回到client.这个过程中你一台机器怎么可能有这么
: 大的throughput?
|
t****n
发帖数: 263 | 17 你连数据一致性都保证不了，还查。查出来一堆垃圾数据有什么用？
【在 n****j 的大作中提到】
: 抢票鸡不需要去查询后端，因为自己就保存了所有票的状态。一趟车算有 64 段，每段
: 有票没票用一个 bit，简单做几个索引的话，查票不过是 64b 的 bit mask op，算力
: 绰绰有余。
: 再省力点，查询甚至都不需要跟抢票鸡打交道。用户选定了车次，前端可以直接跟后端
: 管这个车次的 DB 查。再再省力，非联程票只需要更新抢票鸡状态就可以了。
|
n****j
发帖数: 1708 | 18 我之前已经跟你说很清楚了，数据一致性保持不了是你自己瞎琢磨的，懒得再费口舌了
。不服的话，你证明一下保持不了。车轱辘话来回打滚就不奉陪了。
【在 t****n 的大作中提到】
: 你连数据一致性都保证不了，还查。查出来一堆垃圾数据有什么用？
|
t****n
发帖数: 263 | 19 我就看见你魔杖一挥就啥都有了。
你这里最少出现了抢票机和后端数据库两个部分。他们之间得保持一致吧？怎么保证的？
【在 n****j 的大作中提到】
: 我之前已经跟你说很清楚了，数据一致性保持不了是你自己瞎琢磨的，懒得再费口舌了
: 。不服的话，你证明一下保持不了。车轱辘话来回打滚就不奉陪了。
|
n****j
发帖数: 1708 | 20 废话，抢票鸡跟后端数据库当然都有，否则还谈什么分库啊。
什么叫怎么保证？昨天帖子解释还不清楚吗？再重复一遍，看不懂我就真没办法了：
1、抢票鸡只保持有票没票状态
2、抢票鸡不需要写盘，死机重启，最终状态以 DB 为准。
3、DB 挂了，重启时先跟抢票鸡拿状态，差异部分查订单付款状态并更新
4、你把数据中心炸了我就认输
的？
【在 t****n 的大作中提到】
: 我就看见你魔杖一挥就啥都有了。
: 你这里最少出现了抢票机和后端数据库两个部分。他们之间得保持一致吧？怎么保证的？
|
|
|
t****n
发帖数: 263 | 21 昨天就说了。单一db撑不住。所以你还是按车次分库是吧？
【在 n****j 的大作中提到】
: 废话，抢票鸡跟后端数据库当然都有，否则还谈什么分库啊。
: 什么叫怎么保证？昨天帖子解释还不清楚吗？再重复一遍，看不懂我就真没办法了：
: 1、抢票鸡只保持有票没票状态
: 2、抢票鸡不需要写盘，死机重启，最终状态以 DB 为准。
: 3、DB 挂了，重启时先跟抢票鸡拿状态，差异部分查订单付款状态并更新
: 4、你把数据中心炸了我就认输
:
: 的？
|
n****j
发帖数: 1708 | 22 你不满意可以按座次分，随便
【在 t****n 的大作中提到】
: 昨天就说了。单一db撑不住。所以你还是按车次分库是吧？
|
f******2
发帖数: 2455 | 23 老姜，看了这一帖才觉得你的idea靠谱 -- 赶巧是赶上不是5/6页的主题了，如果是在5
/6页的主题里我还是没兴趣翻，关键中间夹杂了太多不雅文章
你能不能另外开个帖子，把问题描述清楚，把你的solution说清楚，用一个明确的主题
。让人为有问题的网友把challenge亮出来，你一一回答，咱们其他人有一个客观公正
的评判。
做好了的话，下次咱老中面试人的时候就用这个题，不要老用leetcode，显得特没创意。
【在 n****j 的大作中提到】
: 你不满意可以按座次分，随便
|
s********i
发帖数: 145 | 24 既然前段后端都有，那就是传统的架构了，还要你的抢票机干嘛？我直接把请求按车次
Queue到后端，联票的话就要求前端在得到所有请求的结果之后再返回最终结果给客户
不就行了？一段时间请求太多Throttle一下，大家不都是这么做的吗？热门车次的话，
我每个对应的后端可以按你说的优化一下，相当于每台DB后端都是其对应车次的抢票机
，不是比你的更scalable么 |
t****n
发帖数: 263 | 25 好多了，有进步。
那你抢票机给db发消息等不等ack。不等的话怎么保证数据一致性。等得话抢票机还能
保持performance吗？
【在 n****j 的大作中提到】
: 你不满意可以按座次分，随便
|
t****n
发帖数: 263 | 26 还有db挂了你查抢票机，那里的state一直在变。怎么作为依据？查完马上变了呢？和
订单对完后更新？更新到什么状态去？怎么保证查和更新之间的修改不被覆盖？
【在 n****j 的大作中提到】
: 废话，抢票鸡跟后端数据库当然都有，否则还谈什么分库啊。
: 什么叫怎么保证？昨天帖子解释还不清楚吗？再重复一遍，看不懂我就真没办法了：
: 1、抢票鸡只保持有票没票状态
: 2、抢票鸡不需要写盘，死机重启，最终状态以 DB 为准。
: 3、DB 挂了，重启时先跟抢票鸡拿状态，差异部分查订单付款状态并更新
: 4、你把数据中心炸了我就认输
:
: 的？
|
t**********1
发帖数: 550 | 27 告诉你了。只要设计里面有抢票机，剩下的咋做都有理。
你只要记住抢票机的负载比出票机大100倍就好了。
【在 t****n 的大作中提到】
: 还有db挂了你查抢票机，那里的state一直在变。怎么作为依据？查完马上变了呢？和
: 订单对完后更新？更新到什么状态去？怎么保证查和更新之间的修改不被覆盖？
|
n****j
发帖数: 1708 | 28 我有个给赵策的帖子，愿意好好讨论先订好规矩
在5
意。
【在 f******2 的大作中提到】
: 老姜，看了这一帖才觉得你的idea靠谱 -- 赶巧是赶上不是5/6页的主题了，如果是在5
: /6页的主题里我还是没兴趣翻，关键中间夹杂了太多不雅文章
: 你能不能另外开个帖子，把问题描述清楚，把你的solution说清楚，用一个明确的主题
: 。让人为有问题的网友把challenge亮出来，你一一回答，咱们其他人有一个客观公正
: 的评判。
: 做好了的话，下次咱老中面试人的时候就用这个题，不要老用leetcode，显得特没创意。
|
n****j
发帖数: 1708 | 29 你应该没设计过协议，这些都是基本的问题，我就懒得一一回答了。至于 performance
，你想想挂掉的机会有多小，即使发生了也不是啥灾难性的，顶多顶多几分钟恢复了。
【在 t****n 的大作中提到】
: 还有db挂了你查抢票机，那里的state一直在变。怎么作为依据？查完马上变了呢？和
: 订单对完后更新？更新到什么状态去？怎么保证查和更新之间的修改不被覆盖？
|
n****j
发帖数: 1708 | 30 抢票鸡干嘛？这问题刚才解释过了，解决强耦合问题。
举个例子，涉及到联程，你必须到若干个不同库去锁记录，尝试出票，你想想有多影响
性能吧。
【在 s********i 的大作中提到】
: 既然前段后端都有，那就是传统的架构了，还要你的抢票机干嘛？我直接把请求按车次
: Queue到后端，联票的话就要求前端在得到所有请求的结果之后再返回最终结果给客户
: 不就行了？一段时间请求太多Throttle一下，大家不都是这么做的吗？热门车次的话，
: 我每个对应的后端可以按你说的优化一下，相当于每台DB后端都是其对应车次的抢票机
: ，不是比你的更scalable么
|
|
|
b*******g
发帖数: 603 | 31 甭争了，跟民科争永动机为啥不行是没用的，他们会用无数的弱智理论打败你。阉党能
做出来就实测，做不出来就继续做太监就是了。 |
n****j
发帖数: 1708 | 32 简单回答一下：
1、DB 重启通知抢票鸡锁定这个车次，同时获取当前状态
2、跟本地数据核对，看哪些座次不一致。
3、查询订单系统，看这些座次是否付款成功。
4、以付款为准，更新本地数据。
5、更新结果通知抢票鸡，恢复工作。
拜托不要再问类似 ACK 的问题，这是通信基础知识。
【在 t****n 的大作中提到】
: 还有db挂了你查抢票机，那里的state一直在变。怎么作为依据？查完马上变了呢？和
: 订单对完后更新？更新到什么状态去？怎么保证查和更新之间的修改不被覆盖？
|
t****n
发帖数: 263 | 33 OK。听你的。
【在 b*******g 的大作中提到】
: 甭争了，跟民科争永动机为啥不行是没用的，他们会用无数的弱智理论打败你。阉党能
: 做出来就实测，做不出来就继续做太监就是了。
|
t****n
发帖数: 263 | 34 OK。听你的。
【在 b*******g 的大作中提到】
: 甭争了，跟民科争永动机为啥不行是没用的，他们会用无数的弱智理论打败你。阉党能
: 做出来就实测，做不出来就继续做太监就是了。
|
t****n
发帖数: 263 | 35 OK。听你的。
【在 b*******g 的大作中提到】
: 甭争了，跟民科争永动机为啥不行是没用的，他们会用无数的弱智理论打败你。阉党能
: 做出来就实测，做不出来就继续做太监就是了。
|
n****j
发帖数: 1708 | 36 你俩水平差不多，凑一块正好
【在 t****n 的大作中提到】
: OK。听你的。
|
y*****r
发帖数: 327 | 37 这个帖子好。本质上是大家对其他行业与设计不了解。
魏老师的思路是交易所的思路。交易所一秒百万次的订单都能搞定，小小的订票系统算
什么。最重要的的是sequence id。靠的确实不是并行。
Good bug 是neflx的思路。云计算并行处理处理订单。互联网应用。
后面还有人做telecom的。上来就是协议标准。。。
大家还是把ego放一放。各行都有高人。把这个版恢复成原来技术版比较好。原来这个
版有个c++大牛，标准巨熟。都不来了。 |
h*****y
发帖数: 298 | 38 感觉是在用单机的思路做分布式问题。
【在 y*****r 的大作中提到】
: 这个帖子好。本质上是大家对其他行业与设计不了解。
: 魏老师的思路是交易所的思路。交易所一秒百万次的订单都能搞定，小小的订票系统算
: 什么。最重要的的是sequence id。靠的确实不是并行。
: Good bug 是neflx的思路。云计算并行处理处理订单。互联网应用。
: 后面还有人做telecom的。上来就是协议标准。。。
: 大家还是把ego放一放。各行都有高人。把这个版恢复成原来技术版比较好。原来这个
: 版有个c++大牛，标准巨熟。都不来了。
|
b*******g
发帖数: 603 | 39 nasdaq exchange史上峰值是58万／秒，这还是几千个不相干的symbol和衍生物，可以
放在不同match server上做。火车你可以买联程票，要吗都有要吗都没有。股市里没有
appl和goog all or nothing这种单子。Nasdaq 是几千台机器在干这个事情，不是一台。
12306是个典型eCommerce，世界上这么多系统，为什么没有一个做成单机，阿里说最多
也就能每秒12万交易。
你再想想就太监这个外行，每秒100万票有戏吗？
【在 y*****r 的大作中提到】
: 这个帖子好。本质上是大家对其他行业与设计不了解。
: 魏老师的思路是交易所的思路。交易所一秒百万次的订单都能搞定，小小的订票系统算
: 什么。最重要的的是sequence id。靠的确实不是并行。
: Good bug 是neflx的思路。云计算并行处理处理订单。互联网应用。
: 后面还有人做telecom的。上来就是协议标准。。。
: 大家还是把ego放一放。各行都有高人。把这个版恢复成原来技术版比较好。原来这个
: 版有个c++大牛，标准巨熟。都不来了。
|
y*****r
发帖数: 327 | 40 高频进入sub micro级了，一百万也没什么不可能。这个量不是ecommerce可以比的，阿
里也比不了。这就是隔行如隔山。
订票确实是典型的ecommece。魏的思路是围绕着抢票。抢票只需要一台机器。并行意味
着不公平，或者有机可乘。其他付费交易这些都是可以等的。
台。
【在 b*******g 的大作中提到】
: nasdaq exchange史上峰值是58万／秒，这还是几千个不相干的symbol和衍生物，可以
: 放在不同match server上做。火车你可以买联程票，要吗都有要吗都没有。股市里没有
: appl和goog all or nothing这种单子。Nasdaq 是几千台机器在干这个事情，不是一台。
: 12306是个典型eCommerce，世界上这么多系统，为什么没有一个做成单机，阿里说最多
: 也就能每秒12万交易。
: 你再想想就太监这个外行，每秒100万票有戏吗？
|
|
|
b*******g
发帖数: 603 | 41 sub micro，那是延迟短，不是单机每秒处理百万次。百万次必须考虑throughput。一
台机器处理100个request sub micro是一回事，100万过来直接死给你看。
【在 y*****r 的大作中提到】
: 高频进入sub micro级了，一百万也没什么不可能。这个量不是ecommerce可以比的，阿
: 里也比不了。这就是隔行如隔山。
: 订票确实是典型的ecommece。魏的思路是围绕着抢票。抢票只需要一台机器。并行意味
: 着不公平，或者有机可乘。其他付费交易这些都是可以等的。
:
: 台。
|
y*****r
发帖数: 327 | 42 说的是可能性，不是平均值。主要是交易所的限制。有公司一次发太多单被罚了。多机
没法保证公平。如果先发的单因为match engine 机器性能不同或者反应速度慢导致单
反而排在后面就是不公平。所以虽然不是绝对1台机器，也许几台。反正不是几千台。
不过订票确实用不着宰牛刀。又不是抢钱抢微信红包。
【在 b*******g 的大作中提到】
: sub micro，那是延迟短，不是单机每秒处理百万次。百万次必须考虑throughput。一
: 台机器处理100个request sub micro是一回事，100万过来直接死给你看。
|
w**z
发帖数: 8232 | 43 throughput 对latency. 你觉得 12306哪个更重要?
【在 y*****r 的大作中提到】
: 说的是可能性，不是平均值。主要是交易所的限制。有公司一次发太多单被罚了。多机
: 没法保证公平。如果先发的单因为match engine 机器性能不同或者反应速度慢导致单
: 反而排在后面就是不公平。所以虽然不是绝对1台机器，也许几台。反正不是几千台。
: 不过订票确实用不着宰牛刀。又不是抢钱抢微信红包。
|
y*****r
发帖数: 327 | 44 你觉得exchange server这两个有弱的吗？
【在 w**z 的大作中提到】
: throughput 对latency. 你觉得 12306哪个更重要?
|
b*******g
发帖数: 603 | 45 你觉得exchange server跟在client端做trading是一回事吗？而且我跟你说了，
exchange server不会有数据耦合的问题。
【在 y*****r 的大作中提到】
: 你觉得exchange server这两个有弱的吗？
|
y*****r
发帖数: 327 | 46 Client追求的，exchange也追求，exchange 也有竞争特别是equity market。不过这些
和programming 版没什么关系。
【在 b*******g 的大作中提到】
: 你觉得exchange server跟在client端做trading是一回事吗？而且我跟你说了，
: exchange server不会有数据耦合的问题。
|
b*******g
发帖数: 603 | 47 看来你是外行。client你要亿万并发我也分分钟给你做出来，堆机器就行了。太监根本
就没有高并发的经验。
【在 y*****r 的大作中提到】
: Client追求的，exchange也追求，exchange 也有竞争特别是equity market。不过这些
: 和programming 版没什么关系。
|
b*******s
发帖数: 5216 | 48 交易所撮合机器是不管的，但也不是没有耦合问题，比如spread
在高频那一头，比如你要做套利，都是一堆equity什么的组合出一个虚拟的产品，耦合
性很强的,错一点就可能亏钱
【在 b*******g 的大作中提到】
: 你觉得exchange server跟在client端做trading是一回事吗？而且我跟你说了，
: exchange server不会有数据耦合的问题。
|
b*******s
发帖数: 5216 | 49 至于nasdaq的matching engine，是禁止了gc的，我有个前同事在nasdaq omx工作，我
问过，所以不是传统意义的java工作方式了。 they used java as a simpler c++ |
