[NoSQL] Redis常见、常用的知识点

• 　　缓存和数据库双写一致性问题
  
• 　　缓存雪崩问题
  
• 　　缓存击穿问题
  
• 　　缓存的并发竞争问题
  

• 　　纯内存操作
  
• 　　单线程操作，避免了频繁的上下文切换
  
• 　　采用了非阻塞 I/O 多路复用机制
  

• 　　时间都花在了抢车上了，大部分配送员都处在闲置状态，抢到车才能去送。
  
• 　　随着下单的增多，配送员也越来越多，小明发现快递店里越来越挤，没办法雇佣新的配送员了。
  
• 　　配送员之间的协调很花时间。
  

• 　　每个配送员→每个线程
  
• 　　每个订单→每个 Socket(I/O 流)
  
• 　　订单的送达地点→Socket 的不同状态
  
• 　　客户送餐请求→来自客户端的请求
  
• 　　明曲的经营方式→服务端运行的代码
  
• 　　一辆车→CPU 的核数
  

• 　　经营方式一就是传统的并发模型，每个 I/O 流(订单)都有一个新的线程(配送员)管理。
  
• 　　经营方式二就是 I/O 多路复用。只有单个线程(一个配送员)，通过跟踪每个 I/O 流的状态(每个配送员的送达地点)，来管理多个 I/O 流。
  

• 　　String：最常规的 set/get 操作，Value 可以是 String 也可以是数字。一般做一些复杂的计数功能的缓存。
  
• 　　Hash：这里 Value 存放的是结构化的对象，比较方便的就是操作其中的某个字段。我在做单点登录的时候，就是用这种数据结构存储用户信息，以 CookieId 作为 Key，设置 30 分钟为缓存过期时间，能很好的模拟出类似 Session 的效果。
  
• 　　List：使用 List 的数据结构，可以做简单的消息队列的功能。另外，可以利用 lrange 命令，做基于 Redis 的分页功能，性能极佳，用户体验好。
  
• 　　Set：因为 Set 堆放的是一堆不重复值的集合。所以可以做全局去重的功能。我们的系统一般都是集群部署，使用 JVM 自带的 Set 比较麻烦。另外，就是利用交集、并集、差集等操作，可以计算共同喜好，全部的喜好，自己独有的喜好等功能。
  
• 　　Sorted Set：Sorted Set 多了一个权重参数 Score，集合中的元素能够按 Score 进行排列。可以做排行榜应用，取 TOP N 操作。Sorted Set 可以用来做延时任务。
  

# maxmemory-policy volatile-lru

• 　　noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。
  
• 　　allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 Key。（推荐使用，目前项目在用这种）(最近最久使用算法)
  
• 　　allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个 Key。（应该也没人用吧，你不删最少使用 Key，去随机删）
  
• 　　volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 Key。这种情况一般是把 Redis 既当缓存，又做持久化存储的时候才用。（不推荐）
  
• 　　volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个 Key。（依然不推荐）
  
• 　　volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的 Key 优先移除。（不推荐）
  

• 　　利用互斥锁，缓存失效的时候，先去获得锁，得到锁了，再去请求数据库。没得到锁，则休眠一段时间重试。
  
• 　　采用异步更新策略，无论 Key 是否取到值，都直接返回。Value 值中维护一个缓存失效时间，缓存如果过期，异步起一个线程去读数据库，更新缓存。需要做缓存预热(项目启动前，先加载缓存)操作。
  
• 　　提供一个能迅速判断请求是否有效的拦截机制，比如，利用布隆过滤器，内部维护一系列合法有效的 Key。迅速判断出，请求所携带的 Key 是否合法有效。如果不合法，则直接返回。
  

• 　　给缓存的失效时间，加上一个随机值，避免集体失效。
  
• 　　使用互斥锁，但是该方案吞吐量明显下降了。
  
• 　　双缓存。我们有两个缓存，缓存 A 和缓存 B。缓存 A 的失效时间为 20 分钟，缓存 B 不设失效时间。自己做缓存预热操作。
  
• 　　然后细分以下几个小点：从缓存 A 读数据库，有则直接返回；A 没有数据，直接从 B 读数据，直接返回，并且异步启动一个更新线程，更新线程同时更新缓存 A 和缓存 B。
  

• 　　会话缓存（Session Cache）
  

• 　　全页缓存（FPC）
  

• 　　队列
  

• 　　排行榜/计数器
  

• 　　发布/订阅
  

• 　　互斥性
  
• 　　安全性
  
• 　　死锁：一个持有锁的客户端宕机而导致其他客户端再也无法获得锁，从而导致的死锁；
  
• 　　容错
  

• 　　时间复杂度：O(1)
  
• 　　返回值：设置成功，返回1，表明此时没有其他线程占用该资源；设置失败，返回0，表示此时有别的线程正在占用该资源。
  

• 　　设置key的生存时间，当key过期时（生存时间为0），会被自动删除；
  

• RedisService redisService = SpringUtils.getBean(RedisService.class);
  long status = redisService.setnx(key,"1");
  
  
  if(status == 1){
  redisService.expire(key,expire);
  //执行独占资源逻辑
  doOcuppiedWork();
  }

• 　　以上方法的缺点：原子性无法得到满足
  

• 　　EX seconds：设置键的过期时间为second（秒）
  
• 　　PX milliseconds：设置键的过期时间为millisecond（毫秒）
  
• 　　NX：只在键不存在的时候，才对键进行设置操作，效果等同于setnx
  
• 　　XX：只在键已存在的时候，才对键进行设置操作
  
• 　　SET操作成功完成时，返回OK，否则则返回nil
  

• > set lock 123 ex 10 nx
  OK
  > set lock 122 ex 10 nx
  (nil)

• RedisService redisService = SpringUtils.getBean(RedisService.class);
  String result = redisService.set(lockKey,requestId,SET_IF_NOT_EXIST,
  SET_WITH_WITH_EXPIRE_TIME,expireTime);
  if("OK".equals(result)){
  //执行独占资源逻辑
  doOcuppiedWork();
  }

• 　　twemproxy：大概概念是，它类似于一个代理方式，使用方法和普通redis无任何区别，设置好它下属的多个redis实例后，使用时在本需要连接redis的地方改为连接twemproxy，它会以一个代理的身份接收请求并使用一致性hash算法，将请求转接到具体redis，将结果再返回twemproxy。使用方式简便(相对redis只需修改连接端口)，对旧项目扩展的首选。问题：twemproxy自身单端口实例的压力，使用一致性hash后，对redis节点数量改变时候的计算值的改变，数据无法自动移动到新的节点。
  
• 　　codis：目前用的最多的集群方案，基本和twemproxy一致的效果，但它支持在 节点数量改变情况下，旧节点数据可恢复到新hash节点。
  
• 　　redis cluster3.0自带的集群，特点在于他的分布式算法不是一致性hash，而是hash槽的概念，以及自身支持节点设置从节点。具体看官方文档介绍。
  
• 　　在业务代码层实现，起几个毫无关联的redis实例，在代码层，对key 进行hash计算，然后去对应的redis实例操作数据。这种方式对hash层代码要求比较高，考虑部分包括，节点失效后的替代算法方案，数据震荡后的自动脚本恢复，实例的监控，等等。