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

我同事弄了个 big key
把所有用户的头像的地址 url 写在一个 key 里面的，hash 类型。
然后 key 太大，把 redis 拖挂了

我们的项目业务数据不多，redis 基本没出过问题。
隔壁项目组搞千万级物联设备接入和计算，redis 、流计算、数据库、消息队列三天两头各种小问题需要处理。

@cloverzrg2 这种也会挂吗?

@thinkershare Redis 不适合高频写操作。

@thinkershare 可能吧,毕竟我也没有高频读写经验.

没崩过

上家的时候崩过，大概原因就是大 key ，还有频繁查询，线程池弄得也不是很合理，导致查询慢

其他团队弄崩的，redis 公用

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

我们团队最容易崩的是数据库，两万行存储过程的含金量懂不懂啊（ doge

流量不够大……亿级 Key 百万 QPS 下边愁的是分片不能无限可分和节点负载不均

@twofox redis 这东西还是不要公用的好吧.

@twofox redis 也可以搞 lua script 啊,只不过很少用而已,不像数据库,存储过程会的人太多了

很早之前，因为 qps 太高，cpu 炸了。后来优化了业务端，并换到了 keydb

@chenqh 前东家情况是这样的，有很多个系统，客户按需采购。然后技术中台的部门就提供权限中心、单点登录门户之类的环境（私有化部署）

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

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

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

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

能碰这个屎山的人太少了，我也受不了这个屎山，工资又低，润了
剩下的同事明年也准备润了的

遇到过 zrange 性能的问题
https://julyclyde.org/?p=512
不过访问其他 key 性能倒是正常。只是需要排队等 zrange

大年三十下午，生产系统，5 个实例的 redis 集群崩了（ 3 个），然后 acl 丢失，整个业务停了 2 个小时，简直是世界末日。值班的运维既不知道 acl 密码也不知道怎么配的。幸好还有 2 台活着的上去查到了密码……
我也不知道他们运维怎么配置的还是 AWS 自己的毛病，有些业务 docker 就拼命去访问那 3 个挂掉的 redis 而不会去访问好用的那 2 台，这特喵的集群有个鸟用？