分布式系统里用Redis怎么搞最优方案，真有啥诀窍没？

（一）分布式系统为啥爱用Redis？说白了就是因为它快 在分布式系统这个大家庭里，不同的服务可能散落在不同的机器上，它们之间要频繁地说话、交换数据，如果每次聊天都直接去问数据库，数据库老头儿迟早得累趴下，这时候，Redis就像一个超级速记员，它把大家常问的数据记在内存里，下次谁再问，它能瞬间给出答案，大大减轻了数据库的压力，大家爱用它，核心就是一个字：快，内存操作比读写硬盘快几个数量级,这让整个系统的响应速度蹭蹭往上涨。

（二）想把Redis用出花来？这几个诀窍你得懂 别看Redis用起来好像就是set、get那么简单，真想让它在你分布式系统里发挥最大威力，里头门道可不少,这可不是简单搭个服务就完事了。

别把Redis当数据库，它是个缓存 这是最核心的一条心法，Redis的强项是速度，但它的数据默认是在内存里的，虽然能持久化，但真碰上断电等极端情况，还是有丢数据的风险，关键的数据，源头一定得在MySQL这类正经的数据库里存好，Redis里的数据，应该看作是数据库数据的一个“快照”或“副本”，它的存在是为了加速访问，心里要有这么一根弦：缓存数据是可以丢失的，丢了咱们再从数据库里捞回来就行，这个定位摆正了,很多设计决策就不会跑偏。

数据分片是必须的，单机扛不住 一个再厉害的Redis实例，内存和CPU也是有限的，当你的数据量大到一台机器装不下，或者请求多到一台机器处理不过来时，就必须得“分片”，简单说，就是把一大块数据切成很多小块，分散到不同的Redis服务器上，这就好比一个仓库放不下所有货，那就多租几个仓库，把货分开放，常见的做法是用客户端分片（比如用一致性哈希算法算出数据该存到哪台机器），或者用Redis Cluster这种官方提供的分布式方案，分片做好了，你的Redis缓存才能具备水平扩展的能力,容量和性能才能跟着业务一起长。

过期时间一定要设，还得有策略 既然Redis是缓存，就不能让数据在里面“长生不老”，如果数据只存不删，再大的内存也会被撑爆，几乎所有的缓存数据都应该设置一个合理的过期时间，这个时间设多长有讲究：太短了，缓存容易失效，命中率低，数据库压力大；太长了，数据可能已经变了，用户看到的就是旧数据，当内存满了需要淘汰旧数据时，要用对策略，默认的noeviction策略（不淘汰，直接报错）在生产环境很危险，通常推荐用allkeys-lru（最近最少使用的键被淘汰）或volatile-lru（在设置了过期时间的键中淘汰最近最少使用的）,这能保证最常用的数据尽量留在内存里。

搞定缓存穿透、雪崩和击穿 这是三个经典的缓存难题,处理不好能让系统直接挂掉。

• 缓存穿透：有人故意请求根本不存在的数据（比如查用户ID为-1的信息），这个请求缓存没有，就会直接打到数据库上，如果这种恶意请求很多，数据库就惨了。诀窍是：即使数据库查不到，也在缓存里存个空值（比如"null"），并设置一个短的过期时间，或者用布隆过滤器这种数据结构,在查询缓存前先快速判断这个数据是否存在。
• 缓存雪崩：同一时间，大量缓存数据集体过期失效，导致所有请求瞬间都涌向数据库，数据库承受不住就崩了。诀窍是：给不同的缓存数据设置过期时间时，加一个随机扰动值，比如原本都设1小时过期，现在可以改成1小时加减个几分钟的随机数，这样就能避免数据在同一时刻全部失效,把压力均匀开。
• 缓存击穿：某个非常热点的key（比如明星八卦）突然过期了，这时候海量的请求发现缓存没了，同时去数据库查，就像在墙上打了个洞。诀窍是：对于这种极品热点数据，可以不设置过期时间，由后台任务定期更新，或者使用“互斥锁”，当第一个请求发现缓存失效时，它先去抢一个锁，然后由它去数据库加载数据回填缓存，其他请求等着，等缓存好了直接读缓存就行,避免都去查库。

读写模式也得选对路 怎么往Redis里写数据，怎么读数据，也有讲究，最常见的是“旁路缓存模式”：读的时候，先读缓存，缓存没有就读数据库，然后回写到缓存，写的时候，先更新数据库，然后删除缓存，注意，这里一般是删除缓存，而不是更新缓存，因为直接更新缓存可能会因为并发写操作的顺序问题导致脏数据，直接删掉更简单可靠，等下次读的时候自然就会用新数据填充，对于数据一致性要求非常高的场景，可能需要更复杂的方案,但旁路缓存模式在绝大多数情况下已经够用且高效。

（三）真有诀窍吗？ 答案是肯定的，Redis在分布式系统里的最优方案，诀窍不在于某个高深莫测的神秘配置，而在于一系列贴合实际业务场景的设计思想和最佳实践的组合，核心就是：摆正缓存的位置、做好数据分片扩展、精心设计过期和淘汰策略、防御好三大缓存难题、选择简单的读写模式，把这些基础打牢，你的Redis用起来就不会差，它就像一把好刀，用得顺手能帮你披荆斩棘，用不好也可能伤到自己，多思考你的业务数据特点，多做测试，才能找到最适合你自己的那个“最优解”。（来源：综合自《Redis设计与实现》、Redis官方文档、以及高并发系统设计常见实践）