Redis在分布式架构里怎么用才靠谱又强大，聊聊那些实操经验和坑

说到Redis在分布式架构里怎么用,这事儿真是让人又爱又恨，爱的是它速度飞快，能帮我们解决很多性能瓶颈；恨的是如果用得不对，分分钟就能给你挖个大坑，下面我就结合一些实际经验和大家聊聊，怎么把它用得既靠谱又强大。

第一，高可用是底线，别拿单点开玩笑。

最早我们就是图省事,搞了个单机Redis，觉得访问量不大没问题，结果有一次服务器硬件故障，整个缓存层挂了，数据库直接被打满，网站瘫痪了好几个小时，从那以后我们就明白了，在生产环境里，单点Redis绝对不能用，必须上哨兵模式（Sentinel）。

哨兵模式说白了就是给主Redis配几个“保镖”，主节点负责写，从节点负责读和备份，哨兵这几个“保镖”不干别的，就时时刻刻盯着主节点是不是还活着，一旦主节点挂了，哨兵们就会开会投票，从从节点里选出一个新的主节点，然后通知所有客户端连接新的主节点，这个过程是自动的，业务代码基本无感知，大大提高了可用性，这是我们踩了坑之后上的第一道保险，不过哨兵模式也有个问题，就是它主要解决了高可用，但扩容缩容比较麻烦，而且所有数据还是全量在每个节点上，内存大小受限于单机。

所以当数据量再大,或者读写压力再高的时候，我们就考虑用Redis集群（Cluster） 模式了，这个模式是把数据分片（分成了16384个槽位）存储在不同的节点上，相当于把压力分摊了，这样既能水平扩容，也具备了高可用性（每个分片有自己的主从），但集群模式也有代价，比如不支持跨多个key的操作（除非这些key在同一个槽位），客户端也得支持集群协议，稍微复杂一点。

第二，持久化策略要选对，别等丢了数据再哭。

Redis是内存数据库,数据都在内存里，一断电就没了，所以必须把数据存到硬盘上，这就是持久化，Redis主要有两种方式：RDB和AOF。

RDB像是拍快照，隔一段时间把整个内存数据生成一个压缩的二进制文件，优点是文件小，恢复快，缺点是如果两次快照之间服务器宕机，这段时间的数据就丢了。

AOF像是写日记，把每一个写命令都记录下来，优点是数据安全性高，最多丢一秒的数据（如果配置为每秒同步一次），缺点是文件会越来越大，恢复速度慢。

那怎么选呢？我们的经验是，通常两者都开启，用AOF来保证数据不丢失，用RDB来做冷备和快速恢复，可以设置成每小时生成一个RDB文件，同时开启AOF，这样即使AOF文件出问题了，我们还能用RDB文件恢复到一小时前的状态，损失可控。

第三，缓存设计有讲究，弄不好反而拖后腿。

最经典的坑就是缓存穿透，比如有人恶意请求一个数据库中根本不存在的数据ID，这个请求每次都会绕过缓存打到数据库上，瞬间就可能把数据库压垮，解决办法也简单，即使查不到数据，也在缓存里存一个空值（NULL”），并设置一个较短的过期时间，这样下次同样的请求来就直接返回空，不会再去查库了。

还有一个是缓存雪崩，假设缓存里大量数据在同一时间点过期，这时候所有请求都会涌向数据库，数据库又可能扛不住，解决办法是给缓存过期时间加一个随机值，比如原本设置过期10分钟，可以改成8-12分钟之间的一个随机数，让缓存失效的时间点尽量均匀。

第四，别把Redis当万能数据库，要清楚它的边界。

Redis性能极致是因为它简单,所以千万别用它去做复杂的事务或者复杂的查询，我们曾经有个需求是要按多个条件查询用户，有人图快就想把用户数据全塞Redis里然后用key的模式匹配来查，结果发现效率奇低，而且对Redis内存压力巨大，这种场景老老实实用Elasticsearch之类的搜索引擎才是正道。

还有,Redis的“热key”问题也是个暗坑，如果某一个key访问量极其巨大，比如某个顶流明星发了微博，他的粉丝列表这个key会被瞬间访问几百万次，即使你是集群模式，但这个key只存在于某一个节点上，会导致这个节点的网卡被打满，成为瓶颈，解决办法可以是本地缓存（在应用服务器本地也存一份），或者对key进行打散，比如一个粉丝列表key拆成10个，用hash取模的方式分散访问。

监控和慢查询是保命符。

一定要给Redis配上监控,时刻关注内存使用率、连接数、CPU、网络流量、慢查询等关键指标，我们设置了一个慢查询日志的阈值，比如超过5毫秒的查询就记录下来，定期检查这些慢查询，很多时候能发现一些不经意的性能问题，比如一个keys *这样的命令在生产环境跑了一下，可能就会导致Redis短暂卡顿。

Redis是个神器,但想用得靠谱又强大，就得在高可用、持久化、缓存策略、使用边界和监控这几个方面多下功夫，把这些经验和坑都考虑到了，它才能真正成为你分布式架构里的性能加速器，而不是一颗定时炸弹。