Redis 到底应该怎么存储使用?

[chengouzi]

问这个是因为我们公司目前的方法 我觉得挺不妥的 然后我也没有接触过别的公司或者并发比较大的系统中如何存储以及如何读取 redis

使用 redisson 连接的 redis(哨兵)

目前是存人群信息, 分了 1000 个 key (redis 中 key 如果很多的话会有问题么)

1000 个 key 的 value 是 一个大 Map ,存取这个 map 用的是 getLocalCachedMap

map 的每个 key 对应一个人 value 就是他的数据(数据量肯定不大 几百 k 吧)

然后业务集群每天大概请求在 40 -50 亿 然后峰值是 70 亿(其中也会过滤一些请求 比如不合法的或者各种过滤条件过滤掉),剩下的基本每次请求都会去请求一下 Redis 拿用户数据

这样一个 map 的话就会存多个人群数据 这样子维护的话 不会混乱么 比如有的人更新了有的人数据没更新

大家有做过类似的这种 redis 数据维护么 我也想了解了解

[JKeita]

这访问量，触及我知识盲区

[Maboroshii]

你们是不是代码写错了？ 批量的请求变成了循环请求...

[ffxrqyzby]

70 亿感觉请求那边放大了, 我记得阿里双十一才 40 亿

[siweipancc]

……我大胆设想一下，你们的数据更新推送是不是没做，靠前端轮询

[iColdCat]

40-50E 的量如果你们系统没崩就说明 redis 就应该是这么用的

[NoString]

楼主这是广告业务吗？ 70 亿也太猛了 ..我真不知道

[gemini767]

假设一个 value 100k
峰值给你估 10e 来算 你需要的瞬时带宽是 100 * 10e = 100,000,000,000k = 100tb/s

要不就是你对项目还没有完全了解，要不就是你的数据统计是混乱的

[Yiki]

一天 70e 我的天
中国网民都没有 70e...开个专栏具体说说吧

[stop9125]

要换成 8W/s 的 qps ，峰值算 10 倍，80w/s 感觉一些核心业务还是能拿到的
这个量大多考虑的是分片数据均不均匀，会不会把某个分片搞高，然后整体宽带够不够的问题

[peyppicp]

我们有系统使用 redis 缓存 RPC 结果的，接口调用量级大概在 20w qps 左右
比较推荐的方法是每个人一个 Key ，这样在进行 redis 主从同步时压力较小； redis 大 key 会降低 redis 吞吐，p99 也会上升

还有一个问题是，拆分的 1000 个 key ，是按照人群维度拆分的吗

[cheng6563]

Redisson 的 getLocalCachedMap 对应的 Redis 类型就是 hash 吧，那就没啥问题了啊就是这样用的啊，甚至都不需要这 1000key 吧

[swulling]

8w qps 可以了

[xiatian0415]

一开始我对我们系统还没啥感觉，现在发现系统 100 多万 QPS ，看评论，感觉这个量级还是挺高啊😂。 得好好看架构代码了。刚毕业不久的

[shanghai1943]

我还是想等楼主来澄清一下 70e 的数据是怎么来的。。

[dynastysea]

@CantSee 一天 70e 真不多啊，redis 的可以做到几十万 /s ，就是因为有类似这种需求啊，大厂里就很多场景了。也不要简单理解为 70e 就要对应多少人。有些写扩散场景，比如微信，一个人发一条消息，大群要同时给 500 人扩散写，这种并发一下就上去了。

[dynastysea]

@Yiki 你是开发吗？请求 70e 代表 70e 用户吗？一万个用户也有可能啊

[flexbug]

你们还在用哨兵,不用集群模式吗

[dynastysea]

这样维护的意义只是为了减少 key 吗？否则一个用户一个 key 也是可以的，看起来也没有太大问题

[X0ray]

70 亿 也可能是读放大造成的，比如一个事件到了以后需要查 100 次 redis ，并不是说就有 70 亿次业务调用。

[nicebird]

等于手动再分了一次表，看上去没啥问题