Redis集群以及应用场景文档的补充

docs/database/Redis/redis集群以及应用场景.md

@@ -103,16 +103,45 @@
 
 
 ## 使用场景
+
 ### 热点数据
-### 会话维持 session
+
+存取数据优先从 Redis 操作，如果不存在再从文件（例如 MySQL）中操作，从文件操作完后将数据存储到 Redis 中并返回。同时有个定时任务后台定时扫描 Redis 的 key，根据业务规则进行淘汰，防止某些只访问一两次的数据一直存在 Redis 中。
+>例如使用 Zset 数据结构，存储 Key 的访问次数/最后访问时间作为 Score，最后做排序，来淘汰那些最少访问的 Key。  
+  
+如果企业级应用，可以参考：[阿里云的 Redis 混合存储版][1]
+
+### 会话维持 Session
+
+会话维持 Session 场景，即使用 Redis 作为分布式场景下的登录中心存储应用。每次不同的服务在登录的时候，都会去统一的 Redis 去验证 Session 是否正确。但是在微服务场景，一般会考虑 Redis + JWT 做 Oauth2 模块。
+>其中 Redis 存储 JWT 的相关信息主要是留出口子，方便以后做统一的防刷接口，或者做登录设备限制等。
+
 ### 分布式锁 SETNX
+
+命令格式：`SETNX key value`：当且仅当 key 不存在，将 key 的值设为 value。若给定的 key 已经存在，则 SETNX 不做任何动作。
+
+1. 超时时间设置：获取锁的同时，启动守护线程，使用 expire 进行定时更新超时时间。如果该业务机器宕机，守护线程也挂掉，这样也会自动过期。如果该业务不是宕机，而是真的需要这么久的操作时间，那么增加超时时间在业务上也是可以接受的，但是肯定有个最大的阈值。
+2. 但是为了增加高可用，需要使用多台 Redis，就增加了复杂性，就可以参考 Redlock：[Redlock分布式锁](Redlock分布式锁.md#怎么在单节点上实现分布式锁)
+
 ### 表缓存
+
+Redis 缓存表的场景有黑名单、禁言表等。访问频率较高，即读高。根据业务需求，可以使用后台定时任务定时刷新 Redis 的缓存表数据。
+
 ### 消息队列 list
+
+主要使用了 List 数据结构。  
+List 支持在头部和尾部操作，因此可以实现简单的消息队列。
+1. 发消息：在 List 尾部塞入数据。
+2. 消费消息：在 List 头部拿出数据。
+
+同时可以使用多个 List，来实现多个队列，根据不同的业务消息，塞入不同的 List，来增加吞吐量。
+
 ### 计数器 string
 
+主要使用了 INCR、DECR、INCRBY、DECRBY 方法。
 
-
-
+INCR key：给 key 的 value 值增加一 
+DECR key：给 key 的 value 值减去一
 
 ## 缓存设计
 ### 更新策略
@@ -145,5 +174,4 @@
 1. 用户请求先访问本地缓存,无命中后再访问 Redis,如果本地缓存和 Redis 都没有再查数据库,并把数据添加到本地缓存和 Redis；
 1. 由于设置了限流,一段时间范围内超出的请求走降级处理(返回默认值,或给出友情提示).
 
-
-
+[1]: https://promotion.aliyun.com/ntms/act/redishybridstorage.html?spm=5176.54432.1380373.5.41921cf20pcZrZ&aly_as=ArH4VaEb