共计 6980 个字符，预计需要花费 18 分钟才能阅读完成。
21 缓冲区
缓冲区就是用一块内存空间来临时寄存命令数据，免得呈现因为数据和命令的处理速度慢于发送速度而导致的数据失落和性能问题。
缓冲器溢出：
缓冲区空间无限，当写入速度继续大于读取速度，占用内存超出设定下限时，产生缓冲区溢出。
应用场景：
- 在客户端和服务端通信时，暂存客户端命令数据，和服务端返回后果
- 在主从同步时，用来暂存主节点接管的写命令和数据
客户端
服务器端给每个连贯的客户端都设置了一个输出缓冲区和输入缓冲区，咱们称之为客户端输出缓冲区和输入缓冲区。
- 输出缓冲区会先把客户端发送过去的命令暂存起来，Redis 主线程再从输出缓冲区中读取命令，进行解决。
2. 当 Redis 主线程解决完数据后，会把后果写入到输入缓冲区，再通过输入缓冲区返回给客户端。
输出缓冲区
Redis 的客户端输出缓冲区大小的下限阈值，在代码中就设定为了 1GB，无奈调整。
溢出起因：
- 写入了 bigkey，比方一下子写入了多个百万级别的汇合类型数据；
- 服务器端解决申请的速度过慢，例如，Redis 主线程呈现了间歇性阻塞，无奈及时处理失常发送的申请，导致客户端发送的申请在缓冲区越积越多。
查看应用状况：
CLIENT LIST
id=5 addr=127.0.0.1:50487 fd=9 name= age=4 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=26 qbuf-free=32742 obl=0 oll=0 omem=0 events=r cmd=client- qbuf，示意输出缓冲区曾经应用的大小。
- qbuf-free，示意输出缓冲区尚未应用的大小。
输入缓冲区
Redis 为每个客户端设置的输入缓冲区也包含两局部：
- 一部分，是一个大小为 16KB 的固定缓冲空间，用来暂存 OK 响应和出错信息；
- 另一部分，是一个能够动静减少的缓冲空间，用来暂存大小可变的响应后果。
溢出起因：
- 服务器端返回 bigkey 的大量后果；
- 执行了 MONITOR 命令；
- 缓冲区大小设置得不合理。
MONITOR 命令是用来监测 Redis 执行的，输入会继续占用缓冲区，不要在生产环境应用：
MONITOR设置缓冲区大小：client-output-buffer-limit 配置项
client-output-buffer-limit normal 0 0 0normal 示意以后设置的是一般客户端，
第 1 个 0 设置的是缓冲区大小限度，
第 2 个 0 和第 3 个 0 别离示意缓冲区继续写入量限度和继续写入工夫限度。
客户端类型：
- 惯例和 Redis 服务器端进行读写命令交互的一般客户端
- 订阅了 Redis 频道的订阅客户端。
对于一般客户端来说，它每发送完一个申请，会等到申请后果返回后，再发送下一个申请，这种发送形式称为阻塞式发送。
所以，咱们通常把一般客户端的缓冲区大小限度，以及继续写入量限度、继续写入工夫限度都设置为 0，也就是不做限度。
订阅客户端和服务器间的音讯发送形式，不属于阻塞式发送。
因而，咱们会给订阅客户端设置缓冲区大小限度、缓冲区继续写入量限度，以及继续写入工夫限度，能够在 Redis 配置文件中这样设置：
client-output-buffer-limit pubsub 8mb 2mb 60pubsub 参数示意以后是对订阅客户端进行设置；8mb 示意输入缓冲区的大小下限为 8MB，一旦理论占用的缓冲区大小要超过 8MB，服务器端就会间接敞开客户端的连贯；2mb 和 60 示意，如果间断 60 秒内对输入缓冲区的写入量超过 2MB 的话，服务器端也会敞开客户端连贯。
主从集群缓冲区
主从节点的全量和增量复制都会用到缓冲区。
全量复制
在全量复制过程中，主节点在向从节点传输 RDB 文件的同时，会持续接管客户端发送的写命令申请。这些写命令就会先保留在复制缓冲区中，等 RDB 文件传输实现后，再发送给从节点去执行。主节点上会为每个从节点都保护一个复制缓冲区，来保障主从节点间的数据同步。
问题：
在全量复制时，从节点接管和加载 RDB 较慢，同时主节点接管到了大量的写命令，写命令在复制缓冲区中就会越积越多，最终导致溢出。
复制缓冲区一旦产生溢出，主节点也会间接敞开和从节点进行复制操作的连贯，导致全量复制失败。
优化：
- 主节点的数据量管制在 2~4GB，这样能够让全量同步执行得更快些，防止复制缓冲区累积过多命令。
- 管制和主节点连贯的从节点个数，不要应用大规模的主从集群。
设置复制缓冲区：
config set client-output-buffer-limit slave 512mb 128mb 60slave 参数表明该配置项是针对复制缓冲区的。512mb 代表将缓冲区大小的下限设置为 512MB；128mb 和 60 代表的设置是，如果间断 60 秒内的写入量超过 128MB 的话，也会触发缓冲区溢出。
增量复制
增量复制时应用的缓冲区，称为复制积压缓冲区，英文名 repl_backlog_buffer。
主节点在把接管到的写命令同步给从节点时，同时会把这些写命令写入复制积压缓冲区。一旦从节点产生网络闪断，再次和主节点复原连贯后，从节点就会从复制积压缓冲区中，读取断连期间主节点接管到的写命令，进而进行增量同步。
复制积压缓冲区是一个大小无限的环形缓冲区。当主节点把复制积压缓冲区写满后，会笼罩缓冲区中的旧命令数据。如果从节点还没有同步这些旧命令数据，就会造成主从节点间从新开始执行全量复制。
优化：
为了应答复制积压缓冲区的溢出问题，咱们能够调整复制积压缓冲区的大小，也就是设置 repl_backlog_size 这个参数的值。
22 常见问题答疑
- 如何应用慢查问日志和 latency monitor 排查执行慢的操作？
配置参数： - slowlog-log-slower-than：慢查问日志对执行工夫大于多少微秒的命令进行记录。
- slowlog-max-len：慢查问日志最多能记录多少条命令记录，默认 128，倡议 1000。
查看慢日志：
SLOWLOG GET 1
1) 1) (integer) 33 // 每条日志的惟一 ID 编号
2) (integer) 1600990583 // 命令执行时的工夫戳
3) (integer) 20906 // 命令执行的时长，单位是微秒
4) 1) "keys" // 具体的执行命令和参数
2) "abc*"
5) "127.0.0.1:54793" // 客户端的 IP 和端口号
6) "" // 客户端的名称，此处为空 设置峰值提早 (1000 毫秒)：
config set latency-monitor-threshold 1000查看峰值提早：
latency latest
1) 1) "command"
2) (integer) 1600991500 // 命令执行的工夫戳
3) (integer) 2500 // 最近的超过阈值的提早
4) (integer) 10100 // 最大的超过阈值的提早 -
如何排查 Redis 的 bigkey?
./redis-cli --bigkeys -------- summary ------- Sampled 32 keys in the keyspace! Total key length in bytes is 184 (avg len 5.75) // 统计每种数据类型中元素个数最多的 bigkey Biggest list found 'product1' has 8 items Biggest hash found 'dtemp' has 5 fields Biggest string found 'page2' has 28 bytes Biggest stream found 'mqstream' has 4 entries Biggest set found 'userid' has 5 members Biggest zset found 'device:temperature' has 6 members - lists with 15 items (12.50% of keys, avg size 3.75)
- hashs with 14 fields (15.62% of keys, avg size 2.80)
- strings with 68 bytes (31.25% of keys, avg size 6.80)
- streams with 4 entries (03.12% of keys, avg size 4.00)
- sets with 19 members (21.88% of keys, avg size 2.71)
-
zsets with 17 members (15.62% of keys, avg size 3.40)
留神：扫描数据库会对 Redis 性能产生影响，倡议在从节点执行，应用 - i 管制扫描距离。./redis-cli –bigkeys -i 0.1
- 只能返回每种类型最大的 bigkey，无奈失去多个
- 只能统计汇合元素个数，而不是理论占用内存
扫描工具：
- 应用 SCAN 命令对数据库扫描，而后用 TYPE 命令获取返回的每一个 key 的类型。
- 对于 String 类型，应用 STRLEN 命令获取字符串的长度，也就是占用的内存空间字节数。
-
汇合类型获取元素个数，乘以均匀大小就是占用内存大小。
- List 类型：LLEN 命令；
- Hash 类型：HLEN 命令；
- Set 类型：SCARD 命令；
- Sorted Set 类型：ZCARD 命令；
- 把每种数据类型占用内存前 N 位的 key 统计进去，就是 bigkey
23 旁路缓存
缓存特色：
- 在分层零碎中，数据暂存在疾速子系统中有助于减速拜访。
- 缓存容量无限，缓存写满时，数据须要被淘汰。
计算机系统缓存（两种）：
- LLC：CPU 中的末级缓存，用来缓存内存中的数据，防止每次从内存中存取数据；
- page cache：内存中的通知页缓存，用来缓存磁盘中的数据，防止每次从磁盘中存取数据。
构建计算机硬件零碎时，曾经把 LLC 和 page cache 放在了应用程序的数据拜访门路上，应用程序拜访数据时间接就能用上缓存。
旁路缓存
在应用程序中新增缓存逻辑解决的代码，读取缓存、读取数据库和更新缓存的操作都在应用程序中来实现。
旁路缓存是一个独立的零碎，咱们能够独自对 Redis 缓存进行扩容或性能优化。而且，只有放弃操作接口不变，咱们在应用程序中减少的代码就不必再批改了。
缓存类型
Redis 缓存的两种类型：只读缓存和读写缓存。
- 只读缓存能减速读申请
-
读写缓存能够同时减速读写申请，有两种数据写回策略：
- 同步直写保证数据可靠性
- 异步回写低提早
只读缓存
当 Redis 用作只读缓存时，利用要读取数据的话，会先调用 Redis GET 接口，查问数据是否存在。而所有的数据写申请，会间接发往后端的数据库，在数据库中增删改。
对于删改的数据来说，如果 Redis 曾经缓存了相应的数据，利用须要把这些缓存的数据删除，Redis 中就没有这些数据了。当利用再次读取这些数据时，会产生缓存缺失，利用会把这些数据从数据库中读出来，并写到缓存中。
只读缓存间接在数据库中更新数据的益处是，所有最新的数据都在数据库中，而数据库是提供数据可靠性保障的，这些数据不会有失落的危险。当咱们须要缓存图片、短视频这些用户只读的数据时，就能够应用只读缓存这个类型了。
读写缓存
读申请会发送到缓存进行解决（间接在缓存中查问数据是否存在 )，所有的写申请也会发送到缓存，在缓存中间接对数据进行增删改操作。
在应用读写缓存时，最新的数据是在 Redis 中，而 Redis 是内存数据库，一旦呈现掉电或宕机，内存中的数据就会失落。这也就是说，利用的最新数据可能会失落，给利用业务带来危险。
写回策略：同步直写，异步写回。
同步直写：
写申请发给缓存的同时，也会发给后端数据库进行解决，等到缓存和数据库都写完数据，才给客户端返回。
长处：即便缓存宕机或产生故障，最新的数据依然保留在数据库中，这就提供了数据可靠性保障。
毛病：升高拜访性能。
异步写回：
所有写申请都先在缓存中解决。等到这些增改的数据要被从缓存中淘汰进去时，缓存将它们写回后端数据库。
长处：性能高。
毛病：可能会失落。
举例：在商品大促的场景中，商品的库存信息会始终被批改。如果每次批改都需到数据库中解决，就会拖慢整个利用，此时，咱们通常会抉择读写缓存的模式。
24 缓存淘汰
倡议把缓存容量设置为总数据量的 15% 到 30%，兼顾拜访性能和内存空间开销。
确定了缓存最大容量，就能够设定缓存的大小了：
CONFIG SET maxmemory 4gb淘汰策略 (8 种)
不进行数据淘汰：noeviction（默认）
过期淘汰：volatile-random、volatile-ttl、volatile-lru、volatile-lfu
全范畴淘汰：allkeys-lru、allkeys-random、allkeys-lfu
noeviction：缓存写满，再申请间接返回谬误。
volatile-ttl：依据过期工夫先后进行删除
volatile-random、allkeys-random：随机算法删除
volatile-lru、allkeys-lru：LRU 算法删除
volatile-lfu、allkeys-lfu：LFU 算法删除
LRU 算法
Least Recently Used
把所有的数据组织成一个链表，链表的头和尾别离示意 MRU 端和 LRU 端，别离代表最近最常应用的数据和最近最不罕用的数据。
毛病：须要用链表治理所有的缓存数据，这会带来额定的空间开销。而且，当有数据被拜访时，须要在链表上把该数据挪动到 MRU 端，如果有大量数据被拜访，就会带来很多链表挪动操作，会很耗时，进而会升高 Redis 缓存性能。
Redis 优化：
Redis 默认会记录每个数据的最近一次拜访的工夫戳（由键值对数据结构 RedisObject 中的 lru 字段记录）。而后，Redis 在决定淘汰的数据时，第一次会随机选出 N 个数据，把它们作为一个候选汇合。接下来，Redis 会比拟这 N 个数据的 lru 字段，把 lru 字段值最小的数据从缓存中淘汰进来。
Redis 提供了一个配置参数 maxmemory-samples，这个参数就是 Redis 选出的数据个数 N。
CONFIG SET maxmemory-samples 100当须要再次淘汰数据时，Redis 须要筛选数据进入第一次淘汰时创立的候选汇合。这儿的筛选规范是：能进入候选汇合的数据的 lru 字段值必须小于候选汇合中最小的 lru 值。候选集是一个链表，当有新数据进入候选数据集后，如果候选数据集中的数据个数达到了 maxmemory-samples，Redis 就把候选数据集中 lru 字段值最小的数据淘汰进来。
应用倡议：
- 数据有显著的冷热辨别，优先应用 allkeys-lru 策略。
- 数据拜访频率相差不到，倡议 allkeys-random
- 有置顶需要的数据，应用 volatile-lru，同时置顶数据不设置过期工夫，其余数据过期后进行 LRU 筛选
解决淘汰数据
一旦被淘汰的数据选定后，如果这个数据是洁净数据，那么咱们就间接删除；如果这个数据是脏数据，咱们须要把它写回数据库
洁净数据和脏数据的区别就在于，和最后从后端数据库里读取时的值相比，有没有被批改过。洁净数据始终没有被批改，所以后端数据库里的数据也是最新值。在替换时，它能够被间接删除。
对于 Redis 来说，它决定了被淘汰的数据后，会把它们删除。即便淘汰的数据是脏数据，Redis 也不会把它们写回数据库。
所以，咱们在应用 Redis 缓存时，如果数据被批改了，须要在数据批改时就将它写回数据库。否则，这个脏数据被淘汰时，会被 Redis 删除，而数据库里也没有最新的数据了。
25 缓存异样
缓存中有数据，那么，缓存的数据值须要和数据库中的值雷同；缓存中自身没有数据，那么，数据库中的值必须是最新值。不合乎这两种状况的，就属于缓存和数据库的数据不统一问题了。
读写缓存：
- 对于读写缓存来说，要想保障缓存和数据库中的数据统一，就要采纳同步直写策略。同时更新缓存和数据库，须要咱们在业务利用中应用事务机制，来保障缓存和数据库的更新具备原子性。
- 对于数据始终性要求不高的数据，如商品的非关键属性，可应用异步写回策略。
只读缓存：
如果有数据新增，会间接写入数据库；而有数据删改时，就须要把只读缓存中的数据标记为有效。
重试机制
把要删除的缓存值或者是要更新的数据库值暂存到音讯队列中（例如应用 Kafka 音讯队列）。当利用没有可能胜利地删除缓存值或者是更新数据库值时，能够从音讯队列中从新读取这些值，而后再次进行删除或更新。
如果可能胜利地删除或更新，咱们就要把这些值从音讯队列中去除，免得反复操作，此时，咱们也能够保障数据库和缓存的数据统一了。否则的话，咱们还须要再次进行重试。如果重试超过的肯定次数，还是没有胜利，咱们就须要向业务层发送报错信息了。
分布式锁
对于写申请，须要配合分布式锁应用。
写申请进来时，针对同一个资源的批改操作，先加分布式锁，这样同一时间只容许一个线程去更新数据库和缓存，没有拿到锁的线程把操作放入到队列中，延时解决。用这种形式保障多个线程操作同一资源的程序性，以此保障一致性。
小结
缓存和数据库的数据不统一个别是由两个起因导致的，我给你提供了相应的解决方案。
- 删除缓存值或更新数据库失败而导致数据不统一，你能够应用重试机制确保删除或更新操作胜利。
- 在删除缓存值、更新数据库的这两步操作中，有其余线程的并发操作，应答计划是分布式锁。
总结：
应用读写缓存同时操作数据库和缓存时，因为其中一个操作失败导致不统一的问题，能够通过音讯队列重试来解决。
而在并发的场景下，读 + 写并发对业务没有影响或者影响较小，而写 + 写并发时须要配合分布式锁的应用，能力保障缓存和数据库的一致性。
参考
缓存和一致性问题
