高并发和海量数据下的 9 个 Redis 经典案例剖析！

业务背景

这次分享主要是围绕 Redis，分享在平时的日常业务开发中遇到的 9 个经典案例，希望通过此次分享可以帮助大家更好的将 Redis 的高级特性应用到日常的业务开发中来。

首先介绍一下业务背景：总用户量大概是 5亿左右，月活 5kw，日活近 2kw 。服务端有 1000 多个 Redis 实例，100+ 集群，每个实例的内存控制在 20g 以下。

KV 缓存

第一个是最基础也是最常用的就是KV功能，我们可以用 Redis 来缓存用户信息、会话信息、商品信息等等。

下面这段代码就是通用的缓存读取逻辑。

def get_user(user_id):
user = redis.get(user_id)
if not user:
user = db.get(user_id)
redis.setex(user_id, ttl, user) // 设置缓存过期时间
return user
def save_user(user):
redis.setex(user.id, ttl, user) // 设置缓存过期时间
db.save_async(user) // 异步写数据库

这个过期时间非常重要，它通常会和用户的单次会话长度成正比，保证用户在单次会话内尽量一直可以使用缓存里面的数据。

当然如果贵公司财力雄厚，又极致注重性能体验，可以将时间设置的长点甚至干脆就不设置过期时间。

当数据量不断增长时，就使用 Codis 或者 Redis-Cluster 集群来扩容。

除此之外 Redis 还提供了缓存模式，Set 指令不必设置过期时间，它也可以将这些键值对按照一定的策略进行淘汰。

打开缓存模式的指令是：config set maxmemory 20gb ，这样当内存达到 20gb 时，Redis 就会开始执行淘汰策略，给新来的键值对腾出空间。

这个策略 Redis 也是提供了很多种，总结起来这个策略分为两块：划定淘汰范围，选择淘汰算法。

比如我们线上使用的策略是 allkeys-lru。这个 allkeys 表示对 Redis 内部所有的 key 都有可能被淘汰，不管它有没有带过期时间，而volatile只淘汰带过期时间的。

Redis 的淘汰功能就好比企业遇到经济寒冬时需要勒紧裤腰带过冬需要进行一轮残酷的人才优化。它会选择只优化临时工呢，还是所有人一律平等都可能被优化。

当这个范围圈定之后，会从中选出若干个名额，怎么选择呢，这个就是淘汰算法。

最常用的就是 LRU 算法，它有一个弱点，那就是表面功夫做得好的人可以逃过优化。

比如你乘机赶紧在老板面前好好表现一下，然后你就安全了。所以到了 Redis 4.0 里面引入了 LFU 算法，要对平时的成绩也进行考核，只做表面功夫就已经不够用了，还要看你平时勤不勤快。

最后还一种极不常用的算法 —— 随机摇号算法，这个算法有可能会把 CEO 也给淘汰了，所以一般不会使用它。

分布式锁

下面我们看第二个功能 —— 分布式锁，这个是除了 KV 缓存之外最为常用的另一个特色功能。

比如一个很能干的资深工程师，开发效率很快，代码质量也很高，是团队里的明星。所以呢诸多产品经理都要来烦他，让他给自己做需求。

如果同一时间来了一堆产品经理都找他，它的思路呢就会陷入混乱，再优秀的程序员，大脑的并发能力也好不到哪里去。

所以呢他就在自己的办公室的门把上挂了一个请勿打扰的牌子，当一个产品经理来的时候先看看门把上有没有这个牌子，如果没有呢就可以进来找工程师谈需求，谈之前要把牌子挂起来，谈完了再把牌子摘了。

这样其它产品经理也要来烦他的时候，如果看见这个牌子挂在那里，就可以选择睡觉等待或者是先去忙别的事。如是这位明星工程师从此获得了安宁。

这个分布式锁的使用方式非常简单，就是使用 Set 指令的扩展参数如下

加锁

set lock:$user_id owner_id nx ex=5

释放锁

if redis.call(“get”, KEYS[1]) == ARGV[1] then
return redis.call(“del”, KEYS[1])
else
return 0
end

等价于

del_if_equals lock:$user_id owner_id

一定要设置这个过期时间，因为遇到特殊情况 —— 比如地震（进程被 kill -9，或者机器宕机），产品经理可能会选择从窗户上跳下去，没机会摘牌，导致了死锁饥饿，让这位优秀的工程师成了一位大闲人，造成严重的资源浪费。

同时还需要注意这个 owner_id，它代表锁是谁加的 —— 产品经理的工号。以免你的锁不小心被别人摘掉了。

释放锁时要匹配这个 owner_id，匹配成功了才能释放锁。这个 owner_id 通常是一个随机数，存放在 ThreadLocal 变量里（栈变量）。

官方其实并不推荐这种方式，因为它在集群模式下会产生锁丢失的问题 —— 在主从发生切换的时候。官方推荐的分布式锁叫 RedLock，作者认为这个算法较为安全，推荐我们使用。

不过我们一直还使用上面最简单的分布式锁。为什么我们不去使用 RedLock 呢，因为它的运维成本会高一些，需要 3 台以上独立的 Redis 实例，用起来要繁琐一些。

另外，Redis 集群发生主从切换的概率也并不高，即使发生了主从切换出现锁丢失的概率也很低，因为主从切换往往都有一个过程，这个过程的时间