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

突然想起一个问题,你们用的 redis 有崩过吗?是什么原因崩的?

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

    个人感觉 redis 稳如泰山,完全不会坏,没遇到过 redis 崩的情况

    唯一的一次,还是自己 py 程序的问题,原因记不清楚了,好像是自己往 redis 里面写日志,忘了设置过期时间了.

    还是就是 celery 用 redis 做 broker,会断联的问题,但是这个 python 单线程遇到 pub/sub 导致的,redis 还是稳

    第 1 条附言  ·  357 天前
    有种感觉 redis 比阿里滴滴还难崩
    54 条回复    2024-04-06 14:47:59 +08:00
    cs3230524
        1
    cs3230524  
       358 天前   ❤️ 1
    稳如老狗
    opengps
        2
    opengps  
       358 天前   ❤️ 1
    内存爆了有可能伤及 redis
    v2orz
        3
    v2orz  
       358 天前   ❤️ 1
    用了几百个节点的 redis ,差不多 8 年。没有崩
    kingjpa
        4
    kingjpa  
       358 天前   ❤️ 1
    说来惭愧,项目那点流量,不配用 redis,mysql 就足够抗了
    chenqh
        5
    chenqh  
    OP
       358 天前
    @kingjpa 只是有些东西用框架用惯了,其实我都单机 redis 了,有什么并发量呢?
    allendavis
        6
    allendavis  
       358 天前   ❤️ 1
    key 过期机制不合理,塞满内存挂了。。。
    chenqh
        7
    chenqh  
    OP
       358 天前
    @allendavis 这不跟我一样?
    opengps
        8
    opengps  
       358 天前
    @allendavis 让我想起了我用 memcached 时候,批量设置缓存结果 30 天后突然击穿的诡异线上事故,我连续经历了多次才找到原因。。。
    potatowish
        9
    potatowish  
       358 天前 via iPhone   ❤️ 1
    稳如老狗,我直接当数据库用,每天定时备份
    Cloud200
        10
    Cloud200  
       358 天前   ❤️ 3
    没有挂过,有次硬盘写满 Redis 报错也不挂
    xieshaohu
        11
    xieshaohu  
       357 天前   ❤️ 1
    只有内存用满的时候挂过
    xuanbg
        12
    xuanbg  
       357 天前   ❤️ 1
    前几天硬盘被某个服务的日志打满了,Redis 写不了数据,但硬盘空间清出来后,立马自己恢复正常。
    Seanfuck
        13
    Seanfuck  
       357 天前   ❤️ 1
    遇到作为从库同步的时候单个 cpu 一直 100%的情况,有哪里进入死循环了。
    buried
        14
    buried  
       357 天前   ❤️ 1
    刚毕业第一年,见识过组长没配置任何验证直接放公网了,然后就被黑了(这个算另一种崩
    magicZ
        15
    magicZ  
       357 天前   ❤️ 1
    flink 统计数据写入 redis, 没写过期时间,3 个月后发现 redis 挂了
    Ayanokouji
        16
    Ayanokouji  
       357 天前   ❤️ 1
    小公司,有人开了公网,没加认证,被人写爆了。。。
    8355
        17
    8355  
       357 天前
    稳的飞起,同事代码 key bug 无限 append 单 key 200mb 的超级大 key 才打挂 aws 的一个节点
    timetutor
        18
    timetutor  
       357 天前   ❤️ 1
    hgetall 频繁调用,直接导致其他 redis 操作缓慢
    picone
        19
    picone  
       357 天前
    昨天才遇到,key 多,内存爆了,使用 allKeysLRU 策略,导致 CPU 打满了。。
    SilenceLL
        20
    SilenceLL  
       357 天前   ❤️ 1
    key 太过,开发手动模糊查询后连接池爆了 Could not get a resource since the pool is exhausted ,昨天的事情
    chenqh
        21
    chenqh  
    OP
       357 天前
    @magicZ 跟我一样...
    chenqh
        22
    chenqh  
    OP
       357 天前
    @SilenceLL 这是什么意思?
    chenqh
        23
    chenqh  
    OP
       357 天前
    @Ayanokouji 这种我倒不会放到公网上去
    SilenceLL
        24
    SilenceLL  
       357 天前
    @chenqh #22 打错字,系统中 key 比较多,然后开发排查问题的时候用[Redis 客户端]( https://github.com/qishibo/AnotherRedisDesktopManager)模糊查询了一次,然后 Redis 服务器 CPU 和内存暴涨,应用调用 Redis 变慢,最终连接池耗尽导致系统崩溃。后面重新打包了一个 Redis 的客户端,禁用掉了模糊搜索,以免再次不小心拖垮 Redis 。
    kestrelBright
        25
    kestrelBright  
       357 天前   ❤️ 1
    不算崩,只是存满了
    cdlnls
        26
    cdlnls  
       357 天前   ❤️ 1
    确实稳,没遇到过 redis 崩。
    占用内存多的情况下,触发自动 dump 的时候,在写入磁盘时长时间占用磁盘 IO ,CPU 占用异常的高。但是问题不大。
    dlmy
        27
    dlmy  
       357 天前   ❤️ 1
    谁说 redis 稳的?

    面试的时候,面试官说他们 redis 每天都崩,问你怎么办
    Frankcox
        28
    Frankcox  
       357 天前   ❤️ 1
    @dlmy 那能咋办?尊重祝福然后准备面下一家呗
    kuituosi
        29
    kuituosi  
       357 天前
    小流量不太可能崩,主要是大流量的情况崩
    大批量缓存过期,大 key 都容易崩
    taliove
        30
    taliove  
       357 天前   ❤️ 1
    崩过好多好多回。
    skywalkerfc
        31
    skywalkerfc  
       357 天前   ❤️ 1
    自己部署的 redis ,cpu 和内存跑满的情况都碰到过。
    Shiroka
        32
    Shiroka  
       357 天前   ❤️ 1
    thinkwei2012
        33
    thinkwei2012  
       357 天前   ❤️ 1
    5 年只有一次写日志搞崩了
    opsonly
        34
    opsonly  
       357 天前   ❤️ 1
    大 key, 热 key, 引发 slow query.
    kytrun
        35
    kytrun  
       357 天前   ❤️ 1
    集群,部分用代码 key 扫不到,Another Redis Desktop 可以,重启后解决,没深挖原因,猜测是集群节点通信问题?
    Wyearn
        36
    Wyearn  
       357 天前   ❤️ 1
    内存和磁盘原因导致的。
    thinkershare
        37
    thinkershare  
       357 天前   ❤️ 1
    曾经年少,用 redis 高频读写,然后不停的挂。让后一台机器换成 3 台,一样挂。
    ily433664
        38
    ily433664  
       357 天前   ❤️ 1
    只有内存不够出现过问题
    Goooooos
        39
    Goooooos  
       357 天前   ❤️ 1
    一下子删除大量的 key ,导致 redis 阻塞
    chenqh
        40
    chenqh  
    OP
       357 天前
    @thinkershare 为什么?
    cloverzrg2
        41
    cloverzrg2  
       357 天前   ❤️ 2
    我同事弄了个 big key
    把所有用户的头像的地址 url 写在一个 key 里面的,hash 类型。
    然后 key 太大,把 redis 拖挂了
    Worldispow
        42
    Worldispow  
       357 天前   ❤️ 1
    我们的项目业务数据不多,redis 基本没出过问题。
    隔壁项目组搞千万级物联设备接入和计算,redis 、流计算、数据库、消息队列三天两头各种小问题需要处理。
    chenqh
        43
    chenqh  
    OP
       357 天前
    @cloverzrg2 这种也会挂吗?
    thinkershare
        44
    thinkershare  
       357 天前   ❤️ 1
    @thinkershare Redis 不适合高频写操作。
    chenqh
        45
    chenqh  
    OP
       357 天前
    @thinkershare 可能吧,毕竟我也没有高频读写经验.
    layxy
        46
    layxy  
       356 天前   ❤️ 1
    没崩过
    twofox
        47
    twofox  
       356 天前   ❤️ 1
    上家的时候崩过,大概原因就是大 key ,还有频繁查询,线程池弄得也不是很合理,导致查询慢

    其他团队弄崩的,redis 公用

    公用还导致个问题,key 冲突,太炸裂了,两个团队在那里排查好几天

    我们团队最容易崩的是数据库,两万行存储过程的含金量懂不懂啊( doge
    ccde8259
        48
    ccde8259  
       356 天前
    流量不够大……亿级 Key 百万 QPS 下边愁的是分片不能无限可分和节点负载不均
    chenqh
        49
    chenqh  
    OP
       356 天前
    @twofox redis 这东西还是不要公用的好吧.
    chenqh
        50
    chenqh  
    OP
       356 天前
    @twofox redis 也可以搞 lua script 啊,只不过很少用而已,不像数据库,存储过程会的人太多了
    joyanhui
        51
    joyanhui  
       356 天前   ❤️ 1
    很早之前,因为 qps 太高,cpu 炸了。后来优化了业务端,并换到了 keydb
    twofox
        52
    twofox  
       356 天前   ❤️ 1
    @chenqh 前东家情况是这样的,有很多个系统,客户按需采购。然后技术中台的部门就提供权限中心、单点登录门户之类的环境(私有化部署)

    然后各个业务部门就对接,对接完了之后就不用自己管权限之类的了,整个公司的各个部门用的都是同一个 redis
    大 key 也是有个部门搞了首页的一些动态加载的资料在里面。整个公司的业务都崩了

    貌似印象中,还有过集群配置的问题,导致有的时候连接失败

    redis 用 lua 的太少了,大多数把 redis 当作个 map 用就完了。。

    现在会存储过程的也不多了,年轻一点的基本都不会。虽然可以学,上手也挺快
    但是谁愿意碰这个屎山呢。。让他们学也都是推脱的

    能碰这个屎山的人太少了,我也受不了这个屎山,工资又低,润了
    剩下的同事明年也准备润了的
    julyclyde
        53
    julyclyde  
       353 天前
    遇到过 zrange 性能的问题
    https://julyclyde.org/?p=512
    不过访问其他 key 性能倒是正常。只是需要排队等 zrange
    ecloud
        54
    ecloud  
       257 天前   ❤️ 1
    大年三十下午,生产系统,5 个实例的 redis 集群崩了( 3 个),然后 acl 丢失,整个业务停了 2 个小时,简直是世界末日。值班的运维既不知道 acl 密码也不知道怎么配的。幸好还有 2 台活着的上去查到了密码……
    我也不知道他们运维怎么配置的还是 AWS 自己的毛病,有些业务 docker 就拼命去访问那 3 个挂掉的 redis 而不会去访问好用的那 2 台,这特喵的集群有个鸟用?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1073 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 22:44 · PVG 06:44 · LAX 14:44 · JFK 17:44
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.