redis 知识摘要

String结构

字符串常用操作

SET  key  value             //存入字符串键值对
MSET  key  value [key value ...]     //批量存储字符串键值对
SETNX  key  value         //存入一个不存在的字符串键值对
GET  key             //获取一个字符串键值
MGET  key  [key ...]         //批量获取字符串键值
DEL  key  [key ...]         //删除一个键
EXPIRE  key  seconds         //设置一个键的过期时间(秒)

原子加减

INCR  key             //将key中储存的数字值加1
DECR  key             //将key中储存的数字值减1
INCRBY  key  increment         //将key所储存的值加上increment
DECRBY  key  decrement     //将key所储存的值减去decrement

单值缓存

SET  key  value     
GET  key    

对象缓存

SET  user:1  value(json格式数据)
MSET  user:1:name  zhuge   user:1:balance  1888
MGET  user:1:name   user:1:balance 

分布式锁

SETNX  product:10001  true         //返回1代表获取锁成功
SETNX  product:10001  true         //返回0代表获取锁失败
。。。执行业务操作
DEL  product:10001            //执行完业务释放锁
SET product:10001 true  ex  10  nx    //防止程序意外终止导致死锁

应用场景

计数器
INCR article:readcount:{文章id}  	
GET article:readcount:{文章id} 

Web集群session共享
spring session + redis实现session共享

分布式系统全局序列号	
INCRBY  orderId  1000		//redis批量生成序列号提升性能

Hash

Hash常用操作

HSET  key  field  value             //存储一个哈希表key的键值
HSETNX  key  field  value         //存储一个不存在的哈希表key的键值
HMSET  key  field  value [field value ...]     //在一个哈希表key中存储多个键值对
HGET  key  field                 //获取哈希表key对应的field键值
HMGET  key  field  [field ...]         //批量获取哈希表key中多个field键值
HDEL  key  field  [field ...]         //删除哈希表key中的field键值
HLEN  key                //返回哈希表key中field的数量
HGETALL  key                //返回哈希表key中所有的键值
HINCRBY  key  field  increment         //为哈希表key中field键的值加上增量increment

对象缓存

HMSET  user  {userId}:name  zhuge  {userId}:balance  1888
HMSET  user  1:name  zhuge  1:balance  1888
HMGET  user  1:name  1:balance  

应用场景

电商购物车
1）以用户id为key
2）商品id为field
3）商品数量为value

购物车操作
添加商品->hset cart:1001 10088 1
增加数量->hincrby cart:1001 10088 1
商品总数->hlen cart:1001
删除商品->hdel cart:1001 10088
获取购物车所有商品->hgetall cart:1001

优点
1）同类数据归类整合储存，方便数据管理
2）相比string操作消耗内存与cpu更小
3）相比string储存更节省空间

缺点
过期功能不能使用在field上，只能用在key上
Redis集群架构下不适合大规模使用

List

List常用操作

LPUSH  key  value [value ...]         //将一个或多个值value插入到key列表的表头(最左边)
RPUSH  key  value [value ...]         //将一个或多个值value插入到key列表的表尾(最右边)
LPOP  key            //移除并返回key列表的头元素
RPOP  key            //移除并返回key列表的尾元素
LRANGE  key  start  stop        //返回列表key中指定区间内的元素，区间以偏移量start和stop指定
BLPOP  key  [key ...]  timeout    //从key列表表头弹出一个元素，若列表中没有元素，阻塞等待timeout秒,如果timeout=0,一直阻塞等待
BRPOP  key  [key ...]  timeout     //从key列表表尾弹出一个元素，若列表中没有元素，阻塞等待timeout秒,如果timeout=0,一直阻塞等待

常用数据结构

Stack(栈) = LPUSH + LPOP
Queue(队列）= LPUSH + RPOP
Blocking MQ(阻塞队列）= LPUSH + BRPOP

应用场景

微博与微信公众号消息流

微博消息和微信公号消息
小王老师关注了MacTalk，备胎说车等大V
1）MacTalk发微博，消息ID为10018
LPUSH  msg:{小王老师-ID}  10018
2）备胎说车发微博，消息ID为10086
LPUSH  msg:{小王老师-ID} 10086
3）查看最新微博消息
LRANGE  msg:{小王老师-ID}  0  4

Set

Set常用操作
SADD  key  member  [member ...]			//往集合key中存入元素，元素存在则忽略，
							若key不存在则新建
SREM  key  member  [member ...]			//从集合key中删除元素
SMEMBERS  key					//获取集合key中所有元素
SCARD  key					//获取集合key的元素个数
SISMEMBER  key  member			//判断member元素是否存在于集合key中
SRANDMEMBER  key  [count]			//从集合key中选出count个元素，元素不从key中删除
SPOP  key  [count]				//从集合key中选出count个元素，元素从key中删除

Set运算操作
SINTER  key  [key ...] 				//交集运算
SINTERSTORE  destination  key  [key ..]		//将交集结果存入新集合destination中
SUNION  key  [key ..] 				//并集运算
SUNIONSTORE  destination  key  [key ...]		//将并集结果存入新集合destination中
SDIFF  key  [key ...] 				//差集运算
SDIFFSTORE  destination  key  [key ...]		//将差集结果存入新集合destination中

应用场景

微信抽奖小程序
1）点击参与抽奖加入集合
SADD key {userlD}
2）查看参与抽奖所有用户
SMEMBERS key	  
3）抽取count名中奖者
SRANDMEMBER key [count] / SPOP key [count]

微信微博点赞，收藏，标签
1) 点赞
SADD  like:{消息ID}  {用户ID}
2) 取消点赞
SREM like:{消息ID}  {用户ID}
3) 检查用户是否点过赞
SISMEMBER  like:{消息ID}  {用户ID}
4) 获取点赞的用户列表
SMEMBERS like:{消息ID}
5) 获取点赞用户数 
SCARD like:{消息ID}

集合操作实现微博微信关注模型
1) 诸葛老师关注的人: 
zhugeSet-> {guojia, xushu}
2) 杨过老师关注的人:
 yangguoSet--> {zhuge, baiqi, guojia, xushu}
3) 郭嘉老师关注的人: 
guojiaSet-> {zhuge, yangguo, baiqi, xushu, xunyu)
4) 我和杨过老师共同关注: 
SINTER zhugeSet yangguoSet--> {guojia, xushu}
5) 我关注的人也关注他(杨过老师): 
SISMEMBER guojiaSet yangguo 
SISMEMBER xushuSet yangguo
6) 我可能认识的人: 
SDIFF yangguoSet zhugeSet->(zhuge, baiqi}

集合操作实现电商商品筛选
SADD  brand:huawei  P40
SADD  brand:xiaomi  mi-10
SADD  brand:iPhone iphone12
SADD os:android  P40  mi-10
SADD cpu:brand:intel  P40  mi-10
SADD ram:8G  P40  mi-10  iphone12
SINTER  os:android  cpu:brand:intel  ram:8G ->{P40，mi-10}

ZSet

ZSet常用操作

ZADD key score member [[score member]…]    //往有序集合key中加入带分值元素
ZREM key member [member …]        //从有序集合key中删除元素
ZSCORE key member             //返回有序集合key中元素member的分值
ZINCRBY key increment member        //为有序集合key中元素member的分值加上increment 
ZCARD key                //返回有序集合key中元素个数
ZRANGE key start stop [WITHSCORES]    //正序获取有序集合key从start下标到stop下标的元素
ZREVRANGE key start stop [WITHSCORES]    //倒序获取有序集合key从start下标到stop下标的元素

Zset集合操作

ZUNIONSTORE destkey numkeys key [key ...]     //并集计算
ZINTERSTORE destkey numkeys key [key …]    //交集计算

应用场景

Zset集合操作实现排行榜
1）点击新闻
ZINCRBY  hotNews:20190819  1  守护香港
2）展示当日排行前十
ZREVRANGE  hotNews:20190819  0  9  WITHSCORES 
3）七日搜索榜单计算
ZUNIONSTORE  hotNews:20190813-20190819  7 
hotNews:20190813  hotNews:20190814... hotNews:20190819
4）展示七日排行前十
ZREVRANGE hotNews:20190813-20190819  0  9  WITHSCORES

redission实现分布式锁

redis 方案

首先通过setnx获取redis锁 执行业务逻辑 释放锁 

这样可能造成死锁，加锁成功后，业务逻辑异常，没有释放锁

改进

使用try...catch...finally的方式可以解决抛异常的问题

问题：还是会造成死锁 ，程序崩溃、服务器宕机、服务器重启、请求超时被终止、发	布、人为kill等finally不会运行

改进

对锁设置超时时间，使用redis的expire设置超时时间

问题：加锁，设置超时时间不是原子性，即将执行设置超时时间的时候系统发生崩溃，同			   	

样还是会导致死锁。

改进

lua脚本  set原生命令（Redis 2.6.12版本及以上）

`valueOperations.setIfAbsent(lockKey, "1", 10, TimeUnit.SECONDS);`

问题：在高并发场景下会存在问题，超时时间设置不合理导致的问题，业务逻辑还没实现

完就释放锁了，

改进

加锁的时候，把value值设置为唯一值，比如说UUID这种随机数

释放锁的时候，获取锁的值判断value是不是当前进程设置的唯一值，如果是再去删除

finally {
        if (clientId.equals(valueOperations.get(lockKey))) {
            //释放锁
            redisTemplate.delete(lockKey);
        }
    }    

问题：finally代码块中，释放锁的时候，get和del并非原子操作，存在进程安全问题。

改进

删除锁的正确姿势是使用lua脚本，通过redis的eval/evalsha命令来运行

通俗一点的说，即lua脚本能够保证原子性，在lua脚本里执行是一个命令（eval/evalsha）	

去执行的，一条命令没有执行完，其他客户端是看不到的。

问题：虽然通过上面的方式解决了会删除其他进程的锁的问题，但是超时时间的设置依然

是没有解决的，

改进

在加锁成功之后，启动一个守护线程

守护线程每隔1/3的锁的超时时间就去延迟锁的超时时间，比如说锁设置为30秒，那就是

每隔10秒就去延长锁的超时时间，重新设置为30秒

业务代码执行完成，关闭守护线程

在实际操作中，需要注意几点：

只续对的：和释放锁一样，需要判断锁的对象有没有发生变化，否则会造成无论谁 加锁，守护线程都会重新设置锁的超时时间

不能动不动就续：守护线程要在合理的时间再去设置锁的超时时间，否则会造成资源的浪费

及时销毁：如果加锁的线程/进程已经处理完业务了，那么守护进程应该被销毁，否则会 造成资源的浪费

问题：redis部署问题

单机模式

Master-Slave + Sentinel（哨兵）选举模式

Redis Cluster（集群）模式

改进

针对这个问题，有两个解决方案：

RedLock

Zookeeper【推荐】

最终redission集成redis实现了分布式锁，支持可重入锁、公平锁、读写锁、锁超时、RedLo

ck等都提供了完整实现。看门狗机制实现锁时间续约

注意：Redison并不能有效的解决Redis的主从切换问题的，目前推荐使用Zookeeper分布式

锁来解决。

分段锁

电商网站在大促的时候并发量很大：

（1）若抢购不是同一个商品，则可以增加Redis集群的cluster来实现，因为不是同一个商品，所以通过计算 key 的hash会落到不同的 cluster上；

（2）若抢购的是同一个商品，则计算key的hash值会落同一个cluster上，所以加机器也是没有用的。

针对第二个问题，可以使用库存分段锁的方式去实现。

分布式锁总结

追求数据可靠性/强一致性：使用Zookeeper
追求性能：选择Redis，推荐Redisson
Redis分布式锁目前最大问题在于：主从模式下/集群模式下，master节点宕机，异步同步数据导致锁丢失问题
Redis的RedLock算法具有很大争议性，一般不推荐使用

缓存雪崩、缓存穿透、缓存击穿

缓存穿透

用户请求的key再数据库中并不存在，是一个违法的key，导致每次都从数据库中查找，从而可能压垮数据库。如果黑客利用大量的违法key进行请求，将会导致数据库瞬间崩塌

解决方案

• 可以使用redis的布隆过滤器，
  如果布隆过滤器认为某个键 不存在，那么就不会访问存储层。
  将所有可能的key存放到bitmap中，一个一定不存在的key将会被布隆过滤器拦截掉，从而截断对数据库的访问，如果key没有被布隆过滤器拦截下来，查询库中，没有返回结果，我们可以将一个空值存放到缓存中，缓存时间不宜过长。
  适用于数据命中不高，数据相对固定实时性低（通常是数据集较大）的应用场景，代码维护较为复杂，但是缓存空间占用少。
• 对于不存在的key，可以设置成key-null存于redis缓存中，缓存失效时间可以适当设小一点，即缓存层中存了更多的键，这就需要更多的内存空间 ，可以对其设置一个较短的过期时间，让其自动清除。
  优点是实时性高，代码维护简单。

缓存击穿

某个被高频访问的key在某一时间点过期，这时出现大量对这个key的访问，这时候缓存中又没有数据，导致同时去库中查询数据，造成数据库压力瞬间增大。

解决方案

• 设置互斥锁 就是只让一个线程构建缓存，其他线程等待构建缓存的线程执行完，重新从缓存获取数据就可以了
• 设置key永不过期(不推荐)

缓存雪崩

指大批量的key在同一时刻过期，导致数据库查询压力瞬间增大，与缓存击穿不同的是，缓存雪崩是大批量的key同时过期。

解决方案

• 保证缓存层服务高可用性 例如Redis Sentinel 和 Redis Cluster 都实现了高可用。
• 赖隔离组件为后端限流并降级 对重要的资源 ( 如 Redis、 MySQL、 Hbase、外部接口 ) 都进行隔离，让每种资源都单独运行在自己的线程池中。 而Hystrix 是解决依赖隔离的利器
• 缓存key的过期时间设置为随机
• 设置数据永不过期
• 重新设计缓存的使用方式，当我们通过key去查询数据时，首先查询缓存，如果此时缓存中查询不到，就通过分布式锁进行加锁，取得锁的进程查DB并设置缓存，然后解锁；其他进程如果发现有锁就等待，然后等解锁后返回缓存数据或者再次查询DB。

热点key：

缓存中的某些Key(可能对应用与某个促销商品)对应的value存储在集群中一台机器，使得所有流量涌向同一机器，成为系统的瓶颈，该问题的挑战在于它无法通过增加机器容量来解决。

热点key的解决方案：

• 客户端热点key缓存：将热点key对应value并缓存在客户端本地，并且设置一个失效时间。对于每次读请求，将首先检查key是否存在于本地缓存中，如果存在则直接返回，如果不存在再去访问分布式缓存的机器。
• 将热点key分散为多个子key，然后存储到缓存集群的不同机器上，这些子key对应的value都和热点key是一样的。当通过热点key去查询数据时，通过某种hash算法随机选择一个子key，然后再去访问缓存机器，将热点分散到了多个子key上。

热点key的重建

热点key需要重建的原因
当前 key 是一个热点 key( 例如一个热门的娱乐新闻），并发量非常大。

重建缓存不能在短时间完成，可能是一个复杂计算，例如复杂的 SQL、多次 IO、多个依赖等。

解决思路

• 减少重建缓存的次数
• 数据尽可能一致
• 较少的潜在危险

解决方法

• 互斥锁 (mutex key) 只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可 可使用 Redis 的setnx 命令实现该功能。

• 永不过期 物理”不过期：没有设置过期时间，所以不会出现热点 key 过期后产生的问题。 为每个 value
  设置一个逻辑过期时间，当发现超过逻辑过期时间后，会使用单独的线程去构建缓存。

• 热点散列
  参考阿里的Tair，在每一个DataServer上开辟一个HotZone，统计到的热点KEY就保存到集群每一个节点上的HotZone中，客户端把热点数据KEY的请求随机打到任意一台DataServer的HotZone区域（热点KEY并不是Hash取模），这样热点KEY请求就会被散列到多个节点乃至整个集群。
  HotRing是Tair的重要组件，实现原理是由冲突环取代之前的冲突链表，并且有一个Head指针，它会指向或者接近最热的KEY，并且这个环是有序的。Head指针非常有用，当热点数据发生转移时，只需要更改这个Head指针，让其指向环上最热的数据，或者一个更好的位置。无锁设计（Occupied位）解决并发问题。

@Cacheable

Spring 在执行 @Cacheable 标注的方法前先查看缓存中是否有数据，如果有数据，则直接返回缓存数据；若没有数据，执行该方法并将方法返回值放进缓存。 参数： value缓存名、 key缓存键值、 condition满足缓存条件、unless否决缓存条件

@CachePut

@Cacheable 类似，但会把方法的返回值放入缓存中, 主要用于数据新增和修改方法。

@CacheEvict

方法执行成功后会从缓存中移除相应数据。 参数： value缓存名、 key缓存键值、 condition满足缓存条件、 unless否决缓存条件、 allEntries是否移除所有数据（设置为true时会移除所有缓存）