redis

Author: jiahaixin

docs/data-management/Redis/Cache-Design.md

@@ -0,0 +1,157 @@
+# 缓存设计
+
+### 你的系统需要加个缓存设计吗 | 缓存的收益和成本
+
+其实我们目前做的系统或多或少都会有些缓存层的设计，比如为了降低存储层（MySQL）的读写压力，我们一般会考虑加上像 Memcache 或者 Redis 这类全内存缓存层。加速读写的同时还能有效降低后端负载。
+
+但是加缓存，也是有些成本需要考虑的，比如：
+
+- 数据不一致性问题
+- 代码维护成本
+- 运维成本
+
+### 缓存更新策略
+
+缓存中的数据通常都是有生命周期的，需要在指定时间后被删除或更新，这样可以保证缓存空间在一个可控的范围。
+
+但是缓存中的数据会和数据 源中的真实数据有一段时间窗口的不一致，需要利用某些策略进行更新。下 面将分别从使用场景、一致性、开发人员开发/维护成本三个方面介绍三种 缓存的更新策略。
+
+1.LRU/LFU/FIFO算法剔除
+
+使用场景。剔除算法通常用于缓存使用量超过了预设的最大值时候，如 何对现有的数据进行剔除。例如Redis使用maxmemory-policy这个配置作为内 存最大值后对于数据的剔除策略。  
+
+一致性。要清理哪些数据是由具体算法决定，开发人员只能决定使用哪
+种算法，所以数据的一致性是最差的。
+
+维护成本。算法不需要开发人员自己来实现，通常只需要配置最大 maxmemory和对应的策略即可。开发人员只需要知道每种算法的含义，选择 适合自己的算法即可。
+
+2.超时剔除
+
+使用场景。超时剔除通过给缓存数据设置过期时间，让其在过期时间后 自动删除，例如Redis提供的expire命令。如果业务可以容忍一段时间内，缓 存层数据和存储层数据不一致，那么可以为其设置过期时间。在数据过期 后，再从真实数据源获取数据，重新放到缓存并设置过期时间。例如一个视频的描述信息，可以容忍几分钟内数据不一致，但是涉及交易方面的业务，
+后果可想而知。
+  一致性。一段时间窗口内(取决于过期时间长短)存在一致性问题，即
+缓存数据和真实数据源的数据不一致。
+
+维护成本。维护成本不是很高，只需设置expire过期时间即可，当然前 提是应用方允许这段时间可能发生的数据不一致。
+
+3.主动更新 使用场景。应用方对于数据的一致性要求高，需要在真实数据更新后，
+
+立即更新缓存数据。例如可以利用消息系统或者其他方式通知缓存更新。
+  一致性。一致性最高，但如果主动更新发生了问题，那么这条数据很可
+能很长时间不会更新，所以建议结合超时剔除一起使用效果会更好。
+  维护成本。维护成本会比较高，开发者需要自己来完成更新，并保证更
+新操作的正确性。
+
+![](/Users/apple/Desktop/screenshot/截屏2021-03-15 下午7.06.48.png)
+
+·低一致性业务建议配置最大内存和淘汰策略的方式使用。 ·高一致性业务可以结合使用超时剔除和主动更新，这样即使主动更新出了问题，也能保证数据过期时间后删除脏数据。
+
+
+
+### 缓存粒度控制
+
+我们项目中一般在DB上层加个缓存，减轻DB压力，但是是需要缓存多少数据呢，是10条、100条、还是所有数据呢？这就是缓存粒度问题。
+
+通用性。缓存全部数据比部分数据更加通用，但从实际经验看，很长时
+间内应用只需要几个重要的属性。
+  空间占用。缓存全部数据要比部分数据占用更多的空间，可能存在以下
+问题:
+
+·全部数据会造成内存的浪费。 ·全部数据可能每次传输产生的网络流量会比较大，耗时相对较大，在
+
+极端情况下会阻塞网络。
+ ·全部数据的序列化和反序列化的CPU开销更大。 代码维护。全部数据的优势更加明显，而部分数据一旦要加新字段需要修改业务代码，而且修改后通常还需要刷新缓存数据。
+
+### 缓存穿透
+
+缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不会命 中，通常出于容错的考虑，如果从存储层查不到数据则不写入缓存层，如图 11-3所示整个过程分为如下3步:
+
+1)缓存层不命中。
+
+2)存储层不命中，不将空结果写回缓存。
+
+3)返回空结果。
+
+缓存穿透问题可能会使后端存储负载加大，由于很多后端存储不具备高
+并发性，甚至可能造成后端存储宕掉。通常可以在程序中分别统计总调用
+数、缓存层命中数、存储层命中数，如果发现大量存储层空命中，可能就是
+出现了缓存穿透问题。
+
+  造成缓存穿透的基本原因有两个。第一，自身业务代码或者数据出现问
+题，第二，一些恶意攻击、爬虫等造成大量空命中。下面我们来看一下如何
+解决缓存穿透问题。
+
+1.缓存空对象
+
+当第2步存储层不命中后，仍然将空对象保留到缓存层中，之后再访问这个数据将会从缓存中获取，这样就保护了后端数据源。
+
+2.布隆过滤器拦截
+
+在访问缓存层和存储层之前，将存在的key用布隆过滤 器提前保存起来，做第一层拦截。例如:一个推荐系统有4亿个用户id，每 个小时算法工程师会根据每个用户之前历史行为计算出推荐数据放到存储层 中，但是最新的用户由于没有历史行为，就会发生缓存穿透的行为，为此可 以将所有推荐数据的用户做成布隆过滤器。如果布隆过滤器认为该用户id不 存在，那么就不会访问存储层，在一定程度保护了存储层。
+
+### 缓存雪崩
+
+什么是缓存雪崩:由于缓存层承载着大量请求，有效地 保护了存储层，但是如果缓存层由于某些原因不能提供服务，于是所有的请 求都会达到存储层，存储层的调用量会暴增，造成存储层也会级联宕机的情 况。缓存雪崩的英文原意是stampeding herd(奔逃的野牛)，指的是缓存层 宕掉后，流量会像奔逃的野牛一样，打向后端存储。
+
+![](/Users/apple/Desktop/screenshot/截屏2021-03-15 下午7.26.03.png)
+
+预防和解决缓存雪崩问题，可以从以下三个方面进行着手。
+
+1)保证缓存层服务高可用性。和飞机都有多个引擎一样，如果缓存层 设计成高可用的，即使个别节点、个别机器、甚至是机房宕掉，依然可以提 供服务，例如前面介绍过的Redis Sentinel和Redis Cluster都实现了高可用。
+
+2)依赖隔离组件为后端限流并降级。无论是缓存层还是存储层都会有 出错的概率，可以将它们视同为资源。作为并发量较大的系统，假如有一个 资源不可用，可能会造成线程全部阻塞(hang)在这个资源上，造成整个系 统不可用。降级机制在高并发系统中是非常普遍的:比如推荐服务中，如果 个性化推荐服务不可用，可以降级补充热点数据，不至于造成前端页面是开 天窗。在实际项目中，我们需要对重要的资源(例如Redis、MySQL、 HBase、外部接口)都进行隔离，让每种资源都单独运行在自己的线程池 中，即使个别资源出现了问题，对其他服务没有影响。但是线程池如何管 理，比如如何关闭资源池、开启资源池、资源池阀值管理，这些做起来还是 相当复杂的。这里推荐一个Java依赖隔离工具 Hystrix(https://github.com/netflix/hystrix)，如图11-15所示。Hystrix是解决依 赖隔离的利器，但是该内容已经超出本书的范围，同时只适用于Java应用， 所以这里不会详细介绍
+
+3)提前演练。在项目上线前，演练缓存层宕掉后，应用以及后端的负 载情况以及可能出现的问题，在此基础上做一些预案设定。
+
+
+
+### 热点key重建优化
+
+开发人员使用“缓存+过期时间”的策略既可以加速数据读写，又保证数 据的定期更新，这种模式基本能够满足绝大部分需求。但是有两个问题如果 同时出现，可能就会对应用造成致命的危害:
+
+·当前key是一个热点key(例如一个热门的娱乐新闻)，并发量非常 大。
+
+·重建缓存不能在短时间完成，可能是一个复杂计算，例如复杂的 SQL、多次IO、多个依赖等。
+
+在缓存失效的瞬间，有大量线程来重建缓存(如图11-16所示)，造成 后端负载加大，甚至可能会让应用崩溃。
+
+要解决这个问题也不是很复杂，但是不能为了解决这个问题给系统带来
+更多的麻烦，所以需要制定如下目标:
+
+·减少重建缓存的次数。
+
+·数据尽可能一致。
+
+·较少的潜在危险。
+
+![](/Users/apple/Desktop/screenshot/截屏2021-03-15 下午7.29.40.png)
+
+
+
+1.互斥锁(mutex key)
+
+此方法只允许一个线程重建缓存，其他线程等待重建缓存的线程执行 完，重新从缓存获取数据即可，整个过程如图11-17所示。
+
+![](/Users/apple/Desktop/screenshot/截屏2021-03-15 下午8.15.13.png)
+
+
+
+2.永远不过期
+
+“永远不过期”包含两层意思:
+
+·从缓存层面来看，确实没有设置过期时间，所以不会出现热点key过期 后产生的问题，也就是“物理”不过期。
+
+·从功能层面来看，为每个value设置一个逻辑过期时间，当发现超过逻 辑过期时间后，会使用单独的线程去构建缓存。
+
+整个过程如图11-18所示。
+
+从实战看，此方法有效杜绝了热点key产生的问题，但唯一不足的就是 重构缓存期间，会出现数据不一致的情况，这取决于应用方是否容忍这种不 一致。
+
+
+
+
+
+
+
+### 无底洞优化

docs/data-management/Redis/Redis-Cluster.md

@@ -97,7 +97,7 @@ redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.
 
 观察控制台输出：
 
-![](/Users/apple/JavaKeeper/docs/_images/redis/redis-cluster-new.jpg)
+![](https://cdn.jsdelivr.net/gh/Jstarfish/picBed/redis/redis-cluster-new.jpg)
 
 看到 `[OK]` 的信息之后，就表示集群已经搭建成功了，可以看到，这里我们正确地创建了三主三从的集群。
 
@@ -139,7 +139,7 @@ Redis 集群最核心的功能就是数据分区，数据分区之后又伴随
 
 数据分区有**顺序分区**、**哈希分区**等，其中哈希分区由于其天然的随机性，使用广泛；集群的分区方案便是哈希分区的一种。
 
-哈希分区的基本思路是：对数据的特征值（如key）进行哈希，然后根据哈希值决定数据落在哪个节点。常见的哈希分区包括：哈希取余分区、一致性哈希分区、带虚拟节点的一致性哈希分区等。
+哈希分区的基本思路是：对数据的特征值（如key）进行哈希，然后根据哈希值决定数据落在哪个节点。常见的哈希分区包括：<mark>哈希取余分区、一致性哈希分区、带虚拟节点的一致性哈希分区等</mark>。
 
 #### 方案一：哈希取余分区