这是一个创建于 813 天前的主题，其中的信息可能已经有所发展或是发生改变。
东软核酸检测系统在上海经受住了平均每小时超过 600 万人次的峰值考验，在北京经受住了平均每天超过 2000 万人次的压力考验。
 |
1
westoy 2022-09-04 13:55:37 +08:00  2
对外包方案商来说， 我觉得 qps 能超过一千就挺牛的了。 做政企业务方案的， 没哪家主打的是并发啊， 不都是业务的覆盖和完整性么， 一个大集团能有多少并发.....
或者说有大并发需求的， 有几家业务是外包或者整套方案买的方案商的 |
 |
2
Torpedo 2022-09-04 13:58:51 +08:00
有一说一，你想想人家的核心竞争力是啥。技术这边能用就行了
|
 |
3
lscho 2022-09-04 14:01:19 +08:00 via Android
如果真是每小时 600 万人次，每秒 tps 至少 1666 ，qps 至少翻个倍，每秒 3000 。相当牛了。
|
 |
4
bigbyto 2022-09-04 14:09:06 +08:00 via iPhone
换算到每秒的话一台 2 核 4g 服务器就可以扛下。当然这么复杂的系统架构不可能这么简单，但这并不是值得炫耀的事。为啥不敢换算成每秒呢，还是因为太拉了……
|
 |
5
Rrrrrr 2022-09-04 14:51:12 +08:00 via iPhone
能接单和不能接单的区别
|
 |
6
SeaTac 2022-09-04 14:52:28 +08:00
每小时 600 万，平均下来每秒 1666 人次
没做过核酸，不知道做核酸的效率是接近平均分布（一个小时做的人次没有大波动）还是更接近正态分布，假定正态分布，峰值 qps 大概在 3000 到 4000 左右 单从 qps 来说，没什么大不了的，问题在于这个系统的要求是什么，是核酸结果要求在几百 ms 内做到不同客户端 query 结果一致，还是允许有几十分钟到几个小时的延迟 如果有很强的一致性要求的话，那这个数字挺不错的，如果没有的话，就没什么意思了 当然，这顿分析的前提就有点问题，所以结论也不靠谱，就是随便想想而已... |
 |
7
murmur 2022-09-04 16:26:22 +08:00 1
@seaiaddca 错了，核酸系统的并发只跟大白数量有关，跟成都人数没太大关系
核酸是 20 混 1 的，你录入 20 个人和试管的绑定数据，需要 20 个请求，除了开发者 sb 我找不到任何借口 至于生成核酸二维码，那个就是明文的编码，至少广州是这样，广州把核酸编码的任务给了腾讯小程序，广州弄了 6 个核酸码不是炫富吧，这就是天然的负载均衡 |
 |
8
yhxx 2022-09-04 16:32:22 +08:00 2
每小时 600 万约等于每分钟 10 万。
按照上海官方发布的信息，截至 5 月 5 日，上海已布局设置常态化核酸采样点 9021 个。 我们知道大部分核酸采样点是有相互错开的固定工作时间的，不可能同时运行，按最大计算，最多也就一半能同时采样。 我们按 4000+个采样点来算，平均每分钟每个采样点需要扫码+采样 25 人次才能达到东软发布的 600 万次 /小时的数量。 实际同时开放的采样点能有 1/4 就已经很不错了，几乎每秒一次的采样频率，可以吹一波东软速度了 |
 |
9
justanetizen 2022-09-04 16:33:42 +08:00
12306 不就是这卵样吗，最开始垃圾的要死，后面堆积起就搞成现在那样了
|
 |
10
winglight2016 2022-09-04 16:33:53 +08:00 2
即使这个数字我也是不信的，平均 600 万 /小时，一天 24 小时，意味着 1.4 亿人次，这是给上海加了 7 倍人口。北京的数据就更有问题，明显是从北京总人口数推出来的。
|
 |
11
hiro0729 2022-09-04 17:14:12 +08:00 5
“孙(去掉)春(去掉)兰 东(去掉)软” Google 下，就知道了技术之外的东西
|
 |
12
paullee 2022-09-04 18:25:28 +08:00 via iPhone 2
那是因为成都这几天全员核酸，晚上雨中排队，系统经常崩溃，P 民苦不敢言。东软此举算是把锅磨小点。群里都有段子，物业催促业主下楼做核酸的口号是：快来做核酸，马上要切到东软的系统了。
|
 |
13
huangmingyou 2022-09-04 19:44:36 +08:00 1
今天成都听到天空传来一声巨响，知情人士透露是东软甩的锅。
|
 |
14
bitdepth 2022-09-05 00:18:58 +08:00 1
上海那個垃圾核酸碼是不是就是東軟的？開頭幾天塞爆了，後面改手動分流
|
 |
15
GopherDaily 2022-09-05 00:41:28 +08:00
6000000 / 3600 = 1667
|
 |
16
mingl0280 2022-09-05 07:28:40 +08:00 via Android
很拉的说法，完全体现了系统宣传人员既不懂技术也不想懂技术的心态
|
 |
17
zhou405x 2022-09-05 09:21:06 +08:00
人笑麻了 . 6000000/3600 = 1666.6667
平均每秒 qps 1666 . 这还是峰值 , 但是底层没有复杂业务逻辑, 就是简单的查一下数据 , 你弄个大点的 redis 或者本地缓存就可以了. redis 能支持 10w qps , 整一个 ng 路由 + 本地缓存的话那就更快了 . 啥也不是 |
 |
20
unco020511 2022-09-05 10:24:16 +08:00
我觉得这个系统很简单啊,首先就是大白扫管子上的码,然后依次扫 10 个人的健康码,在本地将这 10 个人的信息+管子的信息一次性上报服务,假设 20 秒一个人,那就是一个终端 3 分钟才 post 一次,并且多个终端之间还不存在读写一致性的问题(一个人不可能同时在多个队伍排队做核酸,核酸结果查询是健康码系统,与核酸系统无关).真不觉得这个玩意有什么技术难度
|
 |
21
xuelu520 2022-09-05 10:37:23 +08:00
粤核酸表示，你们还是不行。
|
 |
22
cominghome 2022-09-05 10:46:57 +08:00
|
 |
26
pluvet 2022-09-05 14:35:52 +08:00
对于一个外包来说确实不错了
当然，这个复杂度和并发量还不如我在实习时候遇到的百分之一 |
 |
27
glfpes 2022-09-05 15:00:31 +08:00
这种系统做的越差越好。感谢东软的助攻。
|
 |
28
zdw406 2022-09-05 16:28:26 +08:00
北京那 2000 万是直接拿人口靠的吧
|
Select Language