曾经年少，用 redis 高频读写，然后不停的挂。让后一台机器换成 3 台，一样挂。

只有内存不够出现过问题

一下子删除大量的 key ，导致 redis 阻塞

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

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

没崩过

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

其他团队弄崩的，redis 公用

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

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

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

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

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