V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
chengouzi
V2EX  ›  Redis

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

  •  1
     
  •   chengouzi · 77 天前 · 5672 次点击
    这是一个创建于 77 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    使用 redisson 连接的 redis(哨兵)

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

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

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

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

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

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

    73 条回复    2021-11-12 17:58:34 +08:00
    CantSee
        1
    CantSee  
       77 天前
    一天 70E,歪日,什么公司
    hidemyself
        2
    hidemyself  
       77 天前
    40 亿请求,从来没接触过这个体量
    但是光看描述是没啥问题的吧。key 对应一个人,根据 key 得到用户数据,蛮合理的吧
    sanggao
        3
    sanggao  
       77 天前
    你们体量 有新浪微博大没?
    FantaMole
        4
    FantaMole  
       77 天前
    每日峰值 70 亿次请求,是我要请教你,你们公司的架构是怎么设计的才是
    sunny352787
        5
    sunny352787  
       77 天前
    没啥问题啊,Redis 就是这么用的呀,你担心的是什么呢?
    2i2Re2PLMaDnghL
        6
    2i2Re2PLMaDnghL  
       77 天前
    意思是每秒 8 万请求,很炸裂
    timothyye
        7
    timothyye  
       77 天前
    1000 个 key ,每个 key 对应了个大 map ,大 map 里面的 key 才是某个人的 key
    但是你们每次拿用户数据,都会先取那个大 map ,再从大 map 里面取到某个人? 这行会不会造成一些性能上的浪费?
    ily433664
        8
    ily433664  
       77 天前
    70 亿已经打败 99.9%的人了
    NCZkevin
        9
    NCZkevin  
       77 天前
    70 亿??大厂大部分人也没这种经历
    hope4tomorrow
        10
    hope4tomorrow  
       77 天前
    楼主有没有兴趣分享一下,在如此之高请求量,并发量的公司做后端开发的一些感受,体验,经验这些
    fkdtz
        11
    fkdtz  
       77 天前
    峰值 70 亿?实在不敢造次,弱弱说下我的疑问:如果每个 key 里面有 N 个人,每个 key 大约 N * 100k ,峰值 70 亿的情况下这不是纯纯的大 key + 热 key 问题吗?就算是有缓存这也是被动建的缓存,而且还存在缓存更新问题?好奇楼主 redis 集群什么规模,后端什么架构。。。
    asuka321
        12
    asuka321  
       77 天前
    1000 个 key ,每个 key1000 人,1000 人的业务场景是怎么做到峰值 70 亿的。。
    hearfish
        13
    hearfish  
       77 天前 via iPhone
    存实时竞价的用户画像? key 的数量规模有多少?
    kanhongj
        14
    kanhongj  
       77 天前
    我惊呆了,突然也很想了解你们公司什么架构了,全球人口都来访问也就差不多这个量了。
    FlyingDough
        15
    FlyingDough  
       77 天前
    物联网?人的业务 70 亿属实牛逼啊
    hearfish
        16
    hearfish  
       77 天前
    > redis 中 key 如果很多的话会有问题么

    没问题啊,每个节点最多存 2^32 个 key ,肯定够用了,单节点瓶颈多半是内存容量和网卡

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

    维护是指?你可以把每一个 map 看作一个小的 Redis node ,里面的 key 都是独立的。其实这个更接近 Redis Cluster 的设计,每一个 Map 相当于一个 Slot ,只不过 Slot 对客户端是透明的,而你们需要手动维护 Map
    shiny
        17
    shiny  
       77 天前   ❤️ 1
    目测是广告平台
    4771314
        18
    4771314  
       77 天前
    这流量,厉害了
    lz 有空分享下系统的架构设计
    CodeGou
        19
    CodeGou  
       77 天前
    大佬视察民情来了么~
    CodeCodeStudy
        20
    CodeCodeStudy  
       77 天前
    你们公司是做什么业务的
    JKeita
        21
    JKeita  
       77 天前
    这访问量,触及我知识盲区
    Maboroshii
        22
    Maboroshii  
       77 天前
    你们是不是代码写错了? 批量的请求变成了循环请求...
    ffxrqyzby
        23
    ffxrqyzby  
       77 天前
    70 亿感觉请求那边放大了, 我记得阿里双十一才 40 亿
    siweipancc
        24
    siweipancc  
       77 天前 via iPhone
    ……我大胆设想一下,你们的数据更新推送是不是没做,靠前端轮询
    iColdCat
        25
    iColdCat  
       77 天前
    40-50E 的量如果你们系统没崩就说明 redis 就应该是这么用的
    NoString
        26
    NoString  
       77 天前
    楼主这是广告业务吗? 70 亿也太猛了 ..我真不知道
    gemini767
        27
    gemini767  
       77 天前
    假设一个 value 100k
    峰值给你估 10e 来算 你需要的瞬时带宽是 100 * 10e = 100,000,000,000k = 100tb/s

    要不就是你对项目还没有完全了解,要不就是你的数据统计是混乱的
    Yiki
        28
    Yiki  
       77 天前
    一天 70e 我的天
    中国网民都没有 70e...开个专栏具体说说吧
    stop9125
        29
    stop9125  
       77 天前
    要换成 8W/s 的 qps ,峰值算 10 倍,80w/s 感觉一些核心业务还是能拿到的
    这个量大多考虑的是分片数据均不均匀,会不会把某个分片搞高,然后整体宽带够不够的问题
    peyppicp
        30
    peyppicp  
       77 天前
    我们有系统使用 redis 缓存 RPC 结果的,接口调用量级大概在 20w qps 左右
    比较推荐的方法是每个人一个 Key ,这样在进行 redis 主从同步时压力较小; redis 大 key 会降低 redis 吞吐,p99 也会上升

    还有一个问题是,拆分的 1000 个 key ,是按照人群维度拆分的吗
    cheng6563
        31
    cheng6563  
       77 天前
    Redisson 的 getLocalCachedMap 对应的 Redis 类型就是 hash 吧,那就没啥问题了啊就是这样用的啊,甚至都不需要这 1000key 吧
    swulling
        32
    swulling  
       77 天前 via iPhone
    8w qps 可以了
    xiatian0415
        33
    xiatian0415  
       77 天前
    一开始我对我们系统还没啥感觉,现在发现系统 100 多万 QPS ,看评论,感觉这个量级还是挺高啊😂。 得好好看架构代码了。刚毕业不久的
    shanghai1943
        34
    shanghai1943  
       77 天前
    我还是想等楼主来澄清一下 70e 的数据是怎么来的。。
    dynastysea
        35
    dynastysea  
       77 天前
    @CantSee 一天 70e 真不多啊,redis 的可以做到几十万 /s ,就是因为有类似这种需求啊,大厂里就很多场景了。也不要简单理解为 70e 就要对应多少人。有些写扩散场景,比如微信,一个人发一条消息,大群要同时给 500 人扩散写,这种并发一下就上去了。
    dynastysea
        36
    dynastysea  
       77 天前
    @Yiki 你是开发吗?请求 70e 代表 70e 用户吗?一万个用户也有可能啊
    flexbug
        37
    flexbug  
       77 天前
    你们还在用哨兵,不用集群模式吗
    dynastysea
        38
    dynastysea  
       77 天前   ❤️ 1
    这样维护的意义只是为了减少 key 吗?否则一个用户一个 key 也是可以的,看起来也没有太大问题
    X0ray
        39
    X0ray  
       77 天前   ❤️ 2
    70 亿 也可能是读放大造成的,比如一个事件到了以后需要查 100 次 redis ,并不是说就有 70 亿次业务调用。
    nicebird
        40
    nicebird  
       77 天前
    等于手动再分了一次表,看上去没啥问题
    chengouzi
        41
    chengouzi  
    OP
       77 天前
    晚上我看看对应的类型.... 之前的版本是 redis 一个人存一个 key 貌似 redis 总是挂
    可能还是请求 redis 的量太大了
    e7
        42
    e7  
       77 天前
    好像最新的 redis 支持客户端缓存了
    chengouzi
        43
    chengouzi  
    OP
       77 天前   ❤️ 1
    统一回复一下 做的是广告业务 小公司而已 70 亿说的是十一月一号 的请求量 ,请求量不等于用户量....
    nekochyan
        44
    nekochyan  
       77 天前
    同意 39 楼,楼主应该说的是查询次数有 70 亿,我们游戏后端就是,一个前端请求可能调用几十次 redis
    chengouzi
        45
    chengouzi  
    OP
       77 天前
    @peyppicp 按 key 用的 hash 拆分....
    mmuggle
        46
    mmuggle  
       77 天前   ❤️ 1
    key 还是一人一个比较好,聚合在一起更能造成 big key 和 hot key 。请求量大,可以根据业务来看是否可以做二级缓存,以及是否可以提升为 localcache
    cassyfar
        47
    cassyfar  
       77 天前
    一人一 key 理论上会减轻单一 node 的压力(特别是你有频繁访问的大 key )
    RedisMasterNode
        48
    RedisMasterNode  
       77 天前
    @2i2Re2PLMaDnghL 再考虑白天和晚上,高峰和低谷的请求体量差异,很可能白天每秒超过 30w 请求。。 峰值可能能超过 100w 请求 /秒

    有一说一这种 case 没有团队讨论和经验积累,还是安静听大佬说话比较好哈哈哈
    glfpes
        49
    glfpes  
       77 天前 via iPhone
    8 万 qps 的缓存访问而已。。。一个用户请求触发几十个缓存访问的场景也不少啊

    不要大惊小怪
    GoopleXD
        50
    GoopleXD  
       77 天前   ❤️ 1
    请求量是 70 亿?
    人群标识的量级估计 1 亿的量级?
    不知道存的是啥东西,不过广告业务很多环节都是用布隆过滤器来做
    chippai
        51
    chippai  
       77 天前
    场景:新老客判定
    QPS:峰值 20W+
    Redis 配置:cluster 、16 * 16g 、double
    毫无压力
    Huelse
        52
    Huelse  
       77 天前
    具体没做过,但这个量级我能想到的就是增加增强硬件和简化过程
    iyaozhen
        53
    iyaozhen  
       77 天前
    突然想到一个问题 面试经常考的这个还是有场景呀,现在真的造火箭感觉又不会了
    hallDrawnel
        54
    hallDrawnel  
       77 天前
    1000 个 Key 不算多,我们一个服务的 key 数量随便就几百万了。不懂你们上层业务逻辑,但是这样用也没啥问题。

    比较好奇的是为什么要拆分固定的 1000 个 key ?意思是分为固定的 1000 个人群?
    lysS
        55
    lysS  
       77 天前
    70 亿 Bytes/s 既 64GB/。。。。。不是我不信
    jakezh
        56
    jakezh  
       77 天前
    没明白问题是什么
    我们公司 200 个 pod , 每个 32GB
    请求没下过 20 亿,从来没出过大问题
    raycool
        57
    raycool  
       77 天前
    这是做 RTA 广告么
    alexzz117
        58
    alexzz117  
       77 天前
    哪有这么干的,reids 存几十亿个 key 都没问题,完全没必要用一个 key 存一个大 map
    读取效率低,而更新修改还麻烦,有一致性问题
    makdon
        59
    makdon  
       77 天前
    同做过广告业务,10w+ 级别地 QPS ,用腾讯云的 tendis 就可以直接扛住了, 每个用户一个 kv ,value 当时是纯 protobuff marshal 后的二进制值,每个 kv 加起来不到 KB 级别
    dayeye2006199
        60
    dayeye2006199  
       77 天前
    这个不是 sharding 么。大致是 map 套 map 的搞法。但这个一般是处理多机的问题把,一级查询返回 下一步去哪个机器上查。第二部去那台机器上把真正的值取出来。

    单机这么弄是不是有点没必要,还增加了一些管理上的难度
    v2orz
        61
    v2orz  
       77 天前   ❤️ 1
    比你们小一半左右的量
    我觉得不是很妥当,key 数量并不会显著影响存取性能,但是大 key or 大 value 会显著降低 redis 性能
    小于 1k 的键值对操作性能,和 10k 以上的 k-v 操作性能,有数量级差距
    印象中 redis hash 结构推荐的 field 数量应该在 100 左右以内

    另一方面,我的理解,你们是手动将人群进行了 hash 分片,自己维护。但这本身是可以由 cluster 来做的事情。
    eric96
        62
    eric96  
       77 天前
    应该是广告相关的,看描述,是实时竞价相关的吗,交易所或者 DSP 吧
    draymonder
        63
    draymonder  
       77 天前
    感觉楼上的 xdm ,都不好好看内容啊,人家说的是 一天的峰值在 70 亿,平均下来是 8w qps ,平均峰值三倍 24w qps ,用 localcache + redis 是能抗住的吧...
    chengouzi
        64
    chengouzi  
    OP
       77 天前
    @v2orz 看了你说的, 我现在理解是我们公司 redis 撑不住 每次业务请求来了都去请求 redis 拿数据,最后你说的
    你们是手动将人群进行了 hash 分片,自己维护。但这本身是可以由 cluster 来做的事情。
    这个问题是因为 redis 现在是跨机房的(一个在金华 三个从节点在北京),运维说 集群如果同步挂了 很麻烦,所以只能是主从同步这样子搞,
    然后就把多个人群数据放到一个 map 中 使用 redisson 的 localcachemap 缓存到本地, 这样子也就减少了请求 redis
    (这么算下来还是公司钱不够哇...... 可能老板也是想着 降低成本 然后做更高效的事情 ...)
    chengouzi
        65
    chengouzi  
    OP
       77 天前
    @eric96 怎么好多人都知道.... 这么明显么 大佬做过 ADX 么
    v2orz
        66
    v2orz  
       76 天前
    @chengouzi
    这个问题是因为 redis 现在是跨机房的(一个在金华 三个从节点在北京),运维说 集群如果同步挂了 很麻烦,所以只能是主从同步这样子搞,

    确实有点麻烦。所以我们的做法是,直接建了两个一样的 cluster , 第一个挂了直接干掉,转移到第二个 cluster 去

    单 redis 撑不住就 cluster 分片。cluster 太大了就手动先分一次(比如多个主 cluster )
    kieoo
        67
    kieoo  
       76 天前
    广告业务一天流量 70 亿很正常的, 多 region, 多集群部署, 是抗得下来的, 说白了就是堆机器; 这边 redis 主要存临时数据(数据存储是在 mongodb, s3 上比较稳, 然后通过类 ETL 定期更新 redis), 按广告业务的量级, 肯定要做本地缓存(从 redis 集群成本和稳定性考虑); 楼主是哪家 ADX?
    kerro1990
        68
    kerro1990  
       76 天前
    facebook 开源的那一套很轻松搞定
    chengouzi
        69
    chengouzi  
    OP
       76 天前
    @kieoo 我们 redis 用来存人群信息和请求的进行匹配 比较简单是频次限制 ,我看你说的你们是存临时数据的,咱们可能用法不太一样

    哪家 ADX 就不方便说了.... 小公司而已
    itfisher
        70
    itfisher  
       75 天前 via iPhone
    @chengouzi 非广告也有这么高的呀,redis 请求有可能是服务放大之后的结果,之前搞过 redis 1000w qps 的项目,也就是怼机器罢了
    SirCarol
        71
    SirCarol  
       70 天前
    楼主也是在做计算广告相关的业务吗?看这种场景,应该是用户通过移动端(或 PC 端)经过无线请求到后端检索平台的 ADX ,然后 ADX 会经过分发、过滤、排序(粗排、精排)等过程,然后查 Redis 。与 ADX 对接的可能还会有公司内部的 DSP 和外部的 DSP 平台。

    但是你说的「 redis 用来存人群信息和请求的进行匹配」,针对人群信息,我所在的公司有内部自己搭建的 DMP 平台,在进行人群信息匹配的时候,后端会将 ADX 的请求通过用户唯一标识( imei 或 idfa 或 oaid )与 DMP 平台匹配人群定向信息,当然也会有人群包的概念,对于匹配的结果其实会放在本地缓存或 MySQL 中的。具体展开讲的话,会有很多细节的部分。因为我自己本身也在做品牌广告投放端和检索端的事情,如果感兴趣的话,可以多多交流~
    SirCarol
        72
    SirCarol  
       70 天前
    @chengouzi # 62 我所在的部门也是自己实现的 ADX 、DSP ,只不过是单独实现了一个频控服务工程,这些都是 C 端的服务,它们要求系统的性能比较高,由于调用链路短,因此对代码的要求比较高。而 B 端的话,流量比较小,而且调用链路比较长,要求系统具有一定的稳定性。
    chengouzi
        73
    chengouzi  
    OP
       70 天前 via iPhone   ❤️ 1
    @SirCarol 我们现在比较成熟的就是 adx ssp ,然后现在在慢慢做 dmp dmp 现在就是把人群包解析到 redis 中 然后请求来了进行匹配

    以后可以多交流 哈哈
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2424 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 03:09 · PVG 11:09 · LAX 19:09 · JFK 22:09
    ♥ Do have faith in what you're doing.