Redis在项目中的应用总结

1、数据缓存 一个详情页包含了比较多的信息,这些信息大多是静态的,为了提高详情页的加载速度,将这些信息缓存到Redis中。
如何解决缓存和数据库的数据不一致问题?
项目中使用的是先更新数据库,后删除缓存,在非并发读写情况下,几乎不存在问题,在并发读写情况,当线程W更新完数据库,删除缓存后,R请求此时读取缓存,R请求读取缓存不存在,此时查询数据库,主从同步还没有完成或者发生了主从同步延迟,R请求从读库上获取了旧的数据,然后写入到缓存中,那么缓存和数据库就会发生不一致。
上面这种情况,可以通过延迟再删除的方法处理,W请求删除缓存后,发送一条延迟消息,消息的消费端根据实际情况再次删除缓存,消费端比较缓存中的数据版本和数据库中数据的版本,如果不一致,那么再次删除缓存,如果一致,无需操作。
关于数据库和缓存一致性更加具体的分析参考这篇文章
2、数据统计 聚合统计
所谓的聚合统计,就是指统计多个集合元素的聚合结果,包括:统计多个集合的共有元素(交集统计);把两个集合相比,统计其中一个集合独有的元素(差集统计);统计多个集合的所有元素(并集统计)。
统计用户 App 每天的新增用户数
用一个集合记录所有登录过 App 的用户 ID,同时,用另一个集合记录每一天登录过 App 的用户 ID。然后,再对这两个集合做差集统计。
我们可以使用 Set 类型,把 key 设置为 user:id,表示记录的是用户 ID,value 就是一个 Set 集合,里面是所有登录过 App 的用户 ID,我们可以把这个 Set 叫作累计用户 Set,如下图所示:
Redis在项目中的应用总结
文章图片

把每一天登录的用户 ID,记录到一个新集合中,我们把这个集合叫作每日用户 Set,它有两个特点:
1、key 是 user:id 以及当天日期,例如 user20200803;
2、value 是 Set 集合,记录当天登录的用户 ID。
Redis在项目中的应用总结
文章图片

在统计每天的新增用户时,我们只用计算每日用户 Set 和累计用户 Set 的差集就行,伪代码如下:

Set difference = getRedisTemplate().opsForSet().difference("user:id", "user:id:20200803");

然后,我们计算累计用户 Set 和 user20200803 Set 的并集结果,结果保存在 user:id 这个累计用户 Set 中,伪代码如下:
Set union = getRedisTemplate().opsForSet().union("user:id","user:id:20200803");

此时,user:id 这个累计用户 Set 中就有了 8 月 3 日的用户 ID。等到 8 月 4 日再统计时,我们把 8 月 4 日登录的用户 ID 记录到 user20200804 的 Set 中。接下来,计算累计用户 Set 和 user20200804 Set 的差集就是8月4日的新增用户
计算第二天的留存用户数
当要计算 8 月 4 日的留存用户时,我们只需要再计算 user20200803 和 user20200804 两个 Set 的交集,就可以得到同时在这两个集合中的用户 ID 了,这些就是在 8 月 3 日登录,并且在 8 月 4 日留存的用户,伪代码如下:
Set intersect = getRedisTemplate().opsForSet().intersect("user:id:20200803","user:id:20200804");

Set 的差集、并集和交集的计算复杂度较高,在数据量较大的情况下,如果直接执行这些计算,会导致 Redis 实例阻塞。所以,我给你分享一个小建议:你可以从主从集群中选择一个从库,让它专门负责聚合计算,或者是把数据读取到客户端,在客户端来完成聚合统计,这样就可以规避阻塞主库实例和其他从库实例的风险了。
二值状态统计
统计管家 App 上的打卡情况
在签到统计时,每个用户一天的签到用 1 个 bit 位就能表示,一个月(假设是 31 天)的签到情况用 31 个 bit 位就可以,而一年的签到也只需要用 365 个 bit 位,根本不用太复杂的集合类型。这个时候,我们就可以选择 Bitmap。 Bitmap 可以看作是一个 bit 数组。
Bitmap 提供了 GETBIT/SETBIT 操作,使用一个偏移值 offset 对 bit 数组的某一个 bit 位进行读和写。不过,需要注意的是,Bitmap 的偏移量是从 0 开始算的,也就是说 offset 的最小值是 0。
假设统计 ID 3000 的用户在 2020 年 8 月份的签到情况,就可以按照下面的步骤进行操作。
第一步,执行下面的命令,记录该用户 8 月 3 号已签到:
getRedisTemplate().opsForValue().setBit("uid:sign:3000:202008", 2, true);

第二步,检查该用户 8 月 3 日是否签到:
Boolean sign = getRedisTemplate().opsForValue().getBit("uid:sign:3000:202008", 2);

第三步,统计该用户在 8 月份的签到次数:
long signCount = (long)getRedisTemplate().execute((RedisCallback) con -> con.bitCount("uid:sign:3000:202008".getBytes()));

基于上面签到签到统计的方法,如果记录了 1 亿个用户 10 天的签到情况,怎样统计出这 10 天连续签到的用户总数?
Bitmap 支持用 BITOP 命令对多个 Bitmap 按位做“与”“或”“异或”的操作,操作的结果会保存到一个新的 Bitmap 中。以按位“与”操作为例来具体解释一下。从下图中,可以看到,三个 Bitmap bm1、bm2 和 bm3,对应 bit 位做“与”操作,结果保存到了一个新的 Bitmap 中(示例中,这个结果 Bitmap 的 key 被设为“resmap”)
Redis在项目中的应用总结
文章图片

在统计 1 亿个用户连续 10 天的签到情况时,可以把每天的日期作为 key,每个 key 对应一个 1 亿位的 Bitmap,每一个 bit 对应一个用户当天的签到情况。
接下来,对 10 个 Bitmap 做“与”操作,得到的结果也是一个 Bitmap。在这个 Bitmap 中,只有 10 天都签到的用户对应的 bit 位上的值才会是 1。最后,用 BITCOUNT 统计下 Bitmap 中的 1 的个数,这就是连续签到 10 天的用户总数了
所以,如果只需要统计数据的二值状态,例如商品有没有、用户在不在等,就可以使用 Bitmap,因为它只用一个 bit 位就能表示 0 或 1。在记录海量数据时,Bitmap 能够有效地节省内存空间。
基数统计
基数统计就是指统计一个集合中不重复的元素个数。对应到实际的场景中,就是统计网页的 UV。
网页 UV 的统计有个独特的地方,就是需要去重,一个用户一天内的多次访问只能算作一次。在 Redis 的集合类型中,Set 类型默认支持去重,所以看到有去重需求时,我们可能第一时间就会想到用 Set 类型。但对于大数据量,Set会消耗很大的内存空间。
HyperLogLog 是一种用于统计基数的数据集合类型,它的最大优势就在于,当集合元素数量非常多时,它计算基数所需的空间总是固定的,而且还很小。在 Redis 中,每个 HyperLogLog 只需要花费 12 KB 内存,就可以计算接近 2^64 个元素的基数。
在统计 UV 时,把访问页面的每个用户都添加到 HyperLogLog 中。如下伪代码:
getRedisTemplate().opsForHyperLogLog().add("page1:uv", "user1", "user2", "user3", "user3");

接下来,就可以获得 page1 的 UV 值了, HyperLogLog 的统计结果:
long pfCount = (long)getRedisTemplate().execute((RedisCallback) con -> con.pfCount("page1:uv".getBytes()));

HyperLogLog 的统计规则是基于概率完成的,所以它给出的统计结果是有一定误差的,标准误算率是 0.81%。这也就意味着,你使用 HyperLogLog 统计的 UV 是 100 万,但实际的 UV 可能是 101 万。虽然误差率不算大,但是,如果你需要精确统计结果的话,最好还是继续用 Set 或 Hash 类型。
Redis在项目中的应用总结
文章图片

3、分布式锁 加锁代码:
public String lock(final CacheKey key, final Long expire, final TimeUnit unit) { try { String result = (String)this.redisCacheTemplate.execute(new RedisCallback() { public String doInRedis(RedisConnection connection) throws DataAccessException { JedisCommands commands = (JedisCommands)connection.getNativeConnection(); String uuid = UUID.randomUUID().toString(); String result = commands.set(key.getCacheKey(), uuid, "NX", "PX", unit.toMillis(expire)); return "OK".equals(result) ? uuid : null; } }); return result; } catch (Exception var5) { logger.error("set redis occured an exception", var5); return null; } }

解锁代码:
public boolean releaseLock(CacheKey key, String token) { if (token == null) { logger.warn("lock token can not be null for key=" + key); return false; } else { try { final List keys = new ArrayList(); keys.add(key.getCacheKey()); final List args = new ArrayList(); args.add(token); String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end"; Long result = (Long)this.redisCacheTemplate.execute(new RedisCallback() { public Long doInRedis(RedisConnection connection) throws DataAccessException { Object nativeConnection = connection.getNativeConnection(); if (nativeConnection instanceof JedisCluster) { return (Long)((JedisCluster)nativeConnection).eval("if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end", keys, args); } else { return nativeConnection instanceof Jedis ? (Long)((Jedis)nativeConnection).eval("if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end", keys, args) : 0L; } } }); return result != null && result == 1L; } catch (Exception var7) { logger.error("release lock occured an exception", var7); return false; } } }

关于分布式锁的高可用性,为了避免 Redis 实例故障而导致的锁无法工作的问题,Redis 的开发者 Antirez 提出了分布式锁算法 Redlock。
【Redis在项目中的应用总结】Redlock 算法的基本思路,是让客户端和多个独立的 Redis 实例依次请求加锁,如果客户端能够和半数以上的实例成功地完成加锁操作,那么就认为,客户端成功地获得分布式锁了,否则加锁失败。

    推荐阅读