Redis 数据安全

逃离我推掉我的手 2021-08-31 00:29 419阅读 0赞

### Redis 数据安全 ###

*  1. 前言
 *  2. 缓存与数据库双写时的数据一致性
 *   *  2.1 cache aside pattern
     *  2.2 cache aside pattern 一定能保证数据一致性吗
     *  2.3 数据库与缓存更新与读取操作进行异步串行化
 *  3. redis 的并发竞争问题该如何解决

# 1. 前言 #

这里所说的数据安全并不是像`Java`语言中，多个线程修改一个变量如`i++`，造成结果错误。我们知道`Redis`是单线程的，即使有在多的客户端进行`i++`操作，结果也总是符合预期。而这里的数据安全更多的是指缓存数据不符合我们的预期。

# 2. 缓存与数据库双写时的数据一致性 #

对于缓存和数据库的操作是两个操作，并不是原子性的，所以如果没有合适的方法去保证，一定会带来数据不一致性的情况。

## 2.1 cache aside pattern ##

最经典的缓存+数据库读写的模式，`cache aside pattern`

*  读的时候，先读缓存，缓存没有的话，那么就读数据库，然后取出数据后放入缓存，同时返回响应。
 *  更新的时候，先删除缓存，然后再更新数据库。

为什么选择删除缓存而不是先更新缓存，或者说是更新数据库成功后，在将删除的缓存进行重新保存？

首先说一下第一种方案的缺陷：

如果我们先更新缓存，但是如果更新数据库失败，那么此时便造成数据库与缓存状态不一致。

第二种方案的缺陷：

该方案相当于我们每进行一次数据的更新，就保存一次缓存，那么这些缓存是否一定是热点数据呢？如果不是的话，其不仅浪费内存，而且缓存并不仅仅是数据库中的数据，更有可能需要经过大量的计算才能保存到缓存中。

如我之前写的一个视频排行榜程序，需要进行全表扫描，根据视频的播放量和评论数计算热度。如果视频的播放量每播放一次，便进行一次热度计算，毫无疑问，很浪费资源。

而选择只删除缓存，不进行缓存数据重新更新，是一种懒加载的思想，当我们需要缓存的时候再重新保存。

## 2.2 cache aside pattern 一定能保证数据一致性吗 ##

考虑如下场景，序号代表执行过程，注意并不意味着请求先到来，其先来的请求一定先于后来的请求执行完毕。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70]  
       可以看到，即使采用`cache aside pattern`，在请求`A`更新完数据库之后，数据库中的数据与缓存中的数据依然处于不一致的状态。

该情况通常只会出现在只有在对一个数据在并发的进行读写的时候，才可能会出现这种问题。并且如果并发量很低的话，特别是读并发很低，每天访问量就1万次，那么很少的情况下，会出现刚才描述的那种不一致的场景。但如果每天的是上亿的流量，每秒并发读是几万，每秒只要有数据更新的请求，就可能会出现上述的数据库+缓存不一致的情况。

## 2.3 数据库与缓存更新与读取操作进行异步串行化 ##

为解决上述的问题，我们可以采用数据库与缓存更新与读取操作进行异步串行化的方案。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 1]  
       我们在`JVM`针对该商品创建一个内存队列，只有前面的请求结束才可以轮到后面的请求执行，如此便可以做到缓存与数据库的一致性。

但是如果我们对于每一个读请求，都将其加入到内存队列中，毫无疑问是比较浪费时间的。我们可以用过一个`volatile`变量维护当前内存队列中写请求的个数，只有写请求个数不为`0`时，才将其加入队列，否则直接进行读取操作即可。

在上面我们仅仅是创建了一个内存队列，倘若我们有多个商品，只使用一个内存队列显然并发性非常有限，可以针对每一种或每一类商品创建一个内存队列，这样粒度降低，并发性便可以提供。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 2]

上述方案在多服务实例部署时，有这样一种情况，即对于同一个商品的操作被路由分发的不同的实例中，因为内存队列是基于`JVM`的，所以依然有可能造成数据的不一致。

解决方案：通过`nginx`进行路由分流时，同一个商品使其分流到一台实例中。

# 3. redis 的并发竞争问题该如何解决 #

多客户端同时并发写一个`key`，可能本来应该先到的数据后到了，导致数据版本错了。或者是多客户端同时获取一个`key`，修改值之后再写回去，只要顺序错了，数据就错了。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 3]  
       `Redis`中的数据变化可能有如下几种情况：

v0 --> v1 --> v2 -- v3
    	v0 --> v2 --> v1 -- v3
    	v0 --> v3 --> v1 -- v2
    	......

如果我们想让数据按时间的先后顺序进行保存，即数据变化的方式为`v0 --> v1 --> v2 -- v3`，可以采用时间戳+`CAS`的方式。

如果当前的时间戳大于缓存中的数据库才允许操作。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 4]  
       如此便可以保证缓存中的数据符合我们最终的目标数据。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70]: /images/20210813/fb4583a907884e8e90da487a8d306bc9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 1]: /images/20210813/92c9b6f9933043d19e44b5f5ae02dd02.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 2]: /images/20210813/888d484b54a04a9e87b0e67650c74167.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 3]: /images/20210813/cfac90fd60fe469fb462538f208b9e49.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmdfemhhb18_size_16_color_FFFFFF_t_70 4]: /images/20210813/701b7e47420d436f8fb8f6b5e36968ee.png