这是一个创建于 1112 天前的主题，其中的信息可能已经有所发展或是发生改变。
问这个是因为我们公司目前的方法 我觉得挺不妥的 然后我也没有接触过别的公司或者并发比较大的系统中如何存储以及如何读取 redis
使用 redisson 连接的 redis(哨兵)
目前是存人群信息, 分了 1000 个 key (redis 中 key 如果很多的话会有问题么)
1000 个 key 的 value 是 一个大 Map ,存取这个 map 用的是 getLocalCachedMap
map 的每个 key 对应一个人 value 就是他的数据(数据量肯定不大 几百 k 吧)
然后业务集群每天大概请求在 40 -50 亿 然后峰值是 70 亿(其中也会过滤一些请求 比如不合法的或者各种过滤条件过滤掉),剩下的基本每次请求都会去请求一下 Redis 拿用户数据
这样一个 map 的话就会存多个人群数据 这样子维护的话 不会混乱么 比如有的人更新了有的人数据没更新
大家有做过类似的这种 redis 数据维护么 我也想了解了解
 |
1
CantSee 2021-11-05 14:35:28 +08:00
一天 70E,歪日,什么公司
|
 |
2
hidemyself 2021-11-05 14:36:44 +08:00
40 亿请求，从来没接触过这个体量
但是光看描述是没啥问题的吧。key 对应一个人，根据 key 得到用户数据，蛮合理的吧 |
 |
3
sanggao 2021-11-05 14:39:32 +08:00
你们体量 有新浪微博大没？
|
 |
4
FantaMole 2021-11-05 15:00:08 +08:00
每日峰值 70 亿次请求，是我要请教你，你们公司的架构是怎么设计的才是
|
 |
5
sunny352787 2021-11-05 15:01:32 +08:00
没啥问题啊，Redis 就是这么用的呀，你担心的是什么呢？
|
 |
6
2i2Re2PLMaDnghL 2021-11-05 15:14:17 +08:00
意思是每秒 8 万请求，很炸裂
|
 |
7
timothyye 2021-11-05 15:14:54 +08:00
1000 个 key ，每个 key 对应了个大 map ，大 map 里面的 key 才是某个人的 key
但是你们每次拿用户数据，都会先取那个大 map ，再从大 map 里面取到某个人？ 这行会不会造成一些性能上的浪费？ |
 |
8
ily433664 2021-11-05 15:22:26 +08:00
70 亿已经打败 99.9%的人了
|
 |
9
NCZkevin 2021-11-05 15:30:25 +08:00
70 亿？？大厂大部分人也没这种经历
|
 |
10
hope4tomorrow 2021-11-05 15:35:17 +08:00
楼主有没有兴趣分享一下，在如此之高请求量，并发量的公司做后端开发的一些感受，体验，经验这些
|
 |
11
fkdtz 2021-11-05 15:36:52 +08:00
峰值 70 亿？实在不敢造次，弱弱说下我的疑问：如果每个 key 里面有 N 个人，每个 key 大约 N * 100k ，峰值 70 亿的情况下这不是纯纯的大 key + 热 key 问题吗？就算是有缓存这也是被动建的缓存，而且还存在缓存更新问题？好奇楼主 redis 集群什么规模，后端什么架构。。。
|
 |
12
asuka321 2021-11-05 15:44:12 +08:00
1000 个 key ，每个 key1000 人，1000 人的业务场景是怎么做到峰值 70 亿的。。
|
 |
13
hearfish 2021-11-05 15:50:33 +08:00 via iPhone
存实时竞价的用户画像? key 的数量规模有多少？
|
 |
14
kanhongj 2021-11-05 15:57:44 +08:00
我惊呆了，突然也很想了解你们公司什么架构了，全球人口都来访问也就差不多这个量了。
|
 |
15
FlyingDough 2021-11-05 16:06:03 +08:00
物联网？人的业务 70 亿属实牛逼啊
|
|
16
hearfish 2021-11-05 16:06:44 +08:00
> redis 中 key 如果很多的话会有问题么
没问题啊，每个节点最多存 2^32 个 key ，肯定够用了，单节点瓶颈多半是内存容量和网卡 > 这样一个 map 的话就会存多个人群数据 这样子维护的话 不会混乱么 比如有的人更新了有的人数据没更新 维护是指？你可以把每一个 map 看作一个小的 Redis node ，里面的 key 都是独立的。其实这个更接近 Redis Cluster 的设计，每一个 Map 相当于一个 Slot ，只不过 Slot 对客户端是透明的，而你们需要手动维护 Map |
 |
17
shiny 2021-11-05 16:09:08 +08:00  1
目测是广告平台
|
 |
18
4771314 2021-11-05 16:10:12 +08:00
这流量，厉害了
lz 有空分享下系统的架构设计 |
 |
19
CodeGou 2021-11-05 16:19:26 +08:00
大佬视察民情来了么~
|
 |
20
CodeCodeStudy 2021-11-05 16:40:56 +08:00
你们公司是做什么业务的
|
 |
21
JKeita 2021-11-05 16:45:16 +08:00
这访问量，触及我知识盲区
|
 |
22
Maboroshii 2021-11-05 16:45:31 +08:00
你们是不是代码写错了？ 批量的请求变成了循环请求...
|
 |
23
ffxrqyzby 2021-11-05 16:48:13 +08:00
70 亿感觉请求那边放大了, 我记得阿里双十一才 40 亿
|
 |
24
siweipancc 2021-11-05 16:48:30 +08:00 via iPhone
……我大胆设想一下，你们的数据更新推送是不是没做，靠前端轮询
|
 |
25
iColdCat 2021-11-05 16:51:00 +08:00
40-50E 的量如果你们系统没崩就说明 redis 就应该是这么用的
|
 |
26
NoString 2021-11-05 16:57:50 +08:00
楼主这是广告业务吗？ 70 亿也太猛了 ..我真不知道
|
 |
27
gemini767 2021-11-05 17:03:02 +08:00
假设一个 value 100k
峰值给你估 10e 来算 你需要的瞬时带宽是 100 * 10e = 100,000,000,000k = 100tb/s 要不就是你对项目还没有完全了解，要不就是你的数据统计是混乱的 |
 |
28
Yiki 2021-11-05 17:04:32 +08:00
一天 70e 我的天
中国网民都没有 70e...开个专栏具体说说吧 |
 |
29
stop9125 2021-11-05 17:08:22 +08:00
要换成 8W/s 的 qps ，峰值算 10 倍，80w/s 感觉一些核心业务还是能拿到的
这个量大多考虑的是分片数据均不均匀，会不会把某个分片搞高，然后整体宽带够不够的问题 |
 |
30
peyppicp 2021-11-05 17:13:27 +08:00
我们有系统使用 redis 缓存 RPC 结果的，接口调用量级大概在 20w qps 左右
比较推荐的方法是每个人一个 Key ，这样在进行 redis 主从同步时压力较小； redis 大 key 会降低 redis 吞吐，p99 也会上升 还有一个问题是，拆分的 1000 个 key ，是按照人群维度拆分的吗 |
 |
31
cheng6563 2021-11-05 17:16:15 +08:00
Redisson 的 getLocalCachedMap 对应的 Redis 类型就是 hash 吧，那就没啥问题了啊就是这样用的啊，甚至都不需要这 1000key 吧
|
 |
32
swulling 2021-11-05 17:22:39 +08:00 via iPhone
8w qps 可以了
|
 |
33
xiatian0415 2021-11-05 17:29:56 +08:00
一开始我对我们系统还没啥感觉，现在发现系统 100 多万 QPS ，看评论，感觉这个量级还是挺高啊😂。 得好好看架构代码了。刚毕业不久的
|
 |
34
shanghai1943 2021-11-05 17:33:56 +08:00
我还是想等楼主来澄清一下 70e 的数据是怎么来的。。
|
 |
35
dynastysea 2021-11-05 17:38:15 +08:00
@CantSee 一天 70e 真不多啊，redis 的可以做到几十万 /s ，就是因为有类似这种需求啊，大厂里就很多场景了。也不要简单理解为 70e 就要对应多少人。有些写扩散场景，比如微信，一个人发一条消息，大群要同时给 500 人扩散写，这种并发一下就上去了。
|
|
36
dynastysea 2021-11-05 17:39:21 +08:00
@Yiki 你是开发吗？请求 70e 代表 70e 用户吗？一万个用户也有可能啊
|
 |
37
flexbug 2021-11-05 17:40:05 +08:00
你们还在用哨兵,不用集群模式吗
|
|
38
dynastysea 2021-11-05 17:46:39 +08:00 1
这样维护的意义只是为了减少 key 吗？否则一个用户一个 key 也是可以的，看起来也没有太大问题
|
 |
39
X0ray 2021-11-05 17:46:51 +08:00 2
70 亿 也可能是读放大造成的，比如一个事件到了以后需要查 100 次 redis ，并不是说就有 70 亿次业务调用。
|
 |
40
nicebird 2021-11-05 17:59:08 +08:00
等于手动再分了一次表，看上去没啥问题
|
 |
41
chengouzi OP 晚上我看看对应的类型.... 之前的版本是 redis 一个人存一个 key 貌似 redis 总是挂
可能还是请求 redis 的量太大了 |
 |
42
e7 2021-11-05 18:06:44 +08:00
好像最新的 redis 支持客户端缓存了
|
|
43
chengouzi OP 1
统一回复一下 做的是广告业务 小公司而已 70 亿说的是十一月一号 的请求量 ,请求量不等于用户量....
|
 |
44
nekochyan 2021-11-05 18:11:03 +08:00
同意 39 楼，楼主应该说的是查询次数有 70 亿，我们游戏后端就是，一个前端请求可能调用几十次 redis
|
 |
46
mmuggle 2021-11-05 18:25:28 +08:00 1
key 还是一人一个比较好，聚合在一起更能造成 big key 和 hot key 。请求量大，可以根据业务来看是否可以做二级缓存，以及是否可以提升为 localcache
|
 |
47
cassyfar 2021-11-05 18:33:44 +08:00
一人一 key 理论上会减轻单一 node 的压力（特别是你有频繁访问的大 key ）
|
 |
48
RedisMasterNode 2021-11-05 18:43:48 +08:00
@2i2Re2PLMaDnghL 再考虑白天和晚上，高峰和低谷的请求体量差异，很可能白天每秒超过 30w 请求。。 峰值可能能超过 100w 请求 /秒
有一说一这种 case 没有团队讨论和经验积累，还是安静听大佬说话比较好哈哈哈 |
 |
49
glfpes 2021-11-05 18:48:55 +08:00 via iPhone
8 万 qps 的缓存访问而已。。。一个用户请求触发几十个缓存访问的场景也不少啊
不要大惊小怪 |
 |
50
GoopleXD 2021-11-05 18:57:13 +08:00 1
请求量是 70 亿？
人群标识的量级估计 1 亿的量级？ 不知道存的是啥东西，不过广告业务很多环节都是用布隆过滤器来做 |
 |
51
chippai 2021-11-05 19:19:31 +08:00
场景：新老客判定
QPS：峰值 20W+ Redis 配置：cluster 、16 * 16g 、double 毫无压力 |
 |
52
Huelse 2021-11-05 20:15:21 +08:00
具体没做过，但这个量级我能想到的就是增加增强硬件和简化过程
|
 |
53
iyaozhen 2021-11-05 20:54:31 +08:00
突然想到一个问题 面试经常考的这个还是有场景呀，现在真的造火箭感觉又不会了
|
 |
54
hallDrawnel 2021-11-05 21:20:37 +08:00
1000 个 Key 不算多，我们一个服务的 key 数量随便就几百万了。不懂你们上层业务逻辑，但是这样用也没啥问题。
比较好奇的是为什么要拆分固定的 1000 个 key ？意思是分为固定的 1000 个人群？ |
 |
55
lysS 2021-11-05 22:01:59 +08:00
70 亿 Bytes/s 既 64GB/。。。。。不是我不信
|
 |
56
jakezh 2021-11-05 22:09:54 +08:00
没明白问题是什么
我们公司 200 个 pod ， 每个 32GB 请求没下过 20 亿，从来没出过大问题 |
 |
57
raycool 2021-11-05 22:42:36 +08:00
这是做 RTA 广告么
|
 |
58
alexzz117 2021-11-05 23:13:18 +08:00
哪有这么干的，reids 存几十亿个 key 都没问题，完全没必要用一个 key 存一个大 map
读取效率低，而更新修改还麻烦，有一致性问题 |
 |
59
makdon 2021-11-05 23:55:01 +08:00
同做过广告业务，10w+ 级别地 QPS ，用腾讯云的 tendis 就可以直接扛住了， 每个用户一个 kv ，value 当时是纯 protobuff marshal 后的二进制值，每个 kv 加起来不到 KB 级别
|
 |
60
dayeye2006199 2021-11-06 01:49:05 +08:00
这个不是 sharding 么。大致是 map 套 map 的搞法。但这个一般是处理多机的问题把，一级查询返回 下一步去哪个机器上查。第二部去那台机器上把真正的值取出来。
单机这么弄是不是有点没必要，还增加了一些管理上的难度 |
 |
61
v2orz 2021-11-06 10:31:19 +08:00 1
比你们小一半左右的量
我觉得不是很妥当，key 数量并不会显著影响存取性能，但是大 key or 大 value 会显著降低 redis 性能 小于 1k 的键值对操作性能，和 10k 以上的 k-v 操作性能，有数量级差距 印象中 redis hash 结构推荐的 field 数量应该在 100 左右以内 另一方面，我的理解，你们是手动将人群进行了 hash 分片，自己维护。但这本身是可以由 cluster 来做的事情。 |
 |
62
eric96 2021-11-06 10:41:41 +08:00
应该是广告相关的，看描述，是实时竞价相关的吗，交易所或者 DSP 吧
|
 |
63
draymonder 2021-11-06 10:45:36 +08:00
感觉楼上的 xdm ，都不好好看内容啊，人家说的是 一天的峰值在 70 亿，平均下来是 8w qps ，平均峰值三倍 24w qps ，用 localcache + redis 是能抗住的吧...
|
|
64
chengouzi OP @v2orz 看了你说的, 我现在理解是我们公司 redis 撑不住 每次业务请求来了都去请求 redis 拿数据,最后你说的
你们是手动将人群进行了 hash 分片，自己维护。但这本身是可以由 cluster 来做的事情。 这个问题是因为 redis 现在是跨机房的(一个在金华 三个从节点在北京),运维说 集群如果同步挂了 很麻烦,所以只能是主从同步这样子搞, 然后就把多个人群数据放到一个 map 中 使用 redisson 的 localcachemap 缓存到本地, 这样子也就减少了请求 redis (这么算下来还是公司钱不够哇...... 可能老板也是想着 降低成本 然后做更高效的事情 ...) |
|
66
v2orz 2021-11-06 14:50:00 +08:00
@chengouzi
这个问题是因为 redis 现在是跨机房的(一个在金华 三个从节点在北京),运维说 集群如果同步挂了 很麻烦,所以只能是主从同步这样子搞, 确实有点麻烦。所以我们的做法是，直接建了两个一样的 cluster ， 第一个挂了直接干掉，转移到第二个 cluster 去 单 redis 撑不住就 cluster 分片。cluster 太大了就手动先分一次（比如多个主 cluster ） |
 |
67
kieoo 2021-11-06 16:44:36 +08:00
广告业务一天流量 70 亿很正常的, 多 region, 多集群部署, 是抗得下来的, 说白了就是堆机器; 这边 redis 主要存临时数据(数据存储是在 mongodb, s3 上比较稳, 然后通过类 ETL 定期更新 redis), 按广告业务的量级, 肯定要做本地缓存(从 redis 集群成本和稳定性考虑); 楼主是哪家 ADX?
|
 |
68
kerro1990 2021-11-07 09:52:50 +08:00
facebook 开源的那一套很轻松搞定
|
|
69
chengouzi OP |
 |
70
itfisher 2021-11-07 12:25:08 +08:00 via iPhone
@chengouzi 非广告也有这么高的呀，redis 请求有可能是服务放大之后的结果，之前搞过 redis 1000w qps 的项目，也就是怼机器罢了
|
 |
71
SirCarol 2021-11-12 13:16:15 +08:00
楼主也是在做计算广告相关的业务吗？看这种场景，应该是用户通过移动端（或 PC 端）经过无线请求到后端检索平台的 ADX ，然后 ADX 会经过分发、过滤、排序（粗排、精排）等过程，然后查 Redis 。与 ADX 对接的可能还会有公司内部的 DSP 和外部的 DSP 平台。
但是你说的「 redis 用来存人群信息和请求的进行匹配」，针对人群信息，我所在的公司有内部自己搭建的 DMP 平台，在进行人群信息匹配的时候，后端会将 ADX 的请求通过用户唯一标识（ imei 或 idfa 或 oaid ）与 DMP 平台匹配人群定向信息，当然也会有人群包的概念，对于匹配的结果其实会放在本地缓存或 MySQL 中的。具体展开讲的话，会有很多细节的部分。因为我自己本身也在做品牌广告投放端和检索端的事情，如果感兴趣的话，可以多多交流~ |
Select Language