《Redis深度历险》读后总结

以你之姓@ 2023-07-15 09:04 8阅读 0赞

最近疫情好多了，好多城市都开始清零。大家还是不要大意，在家再坚持一段时间。疫情期间，有很多安静的时间，可以用来看平时没时间看的书。趁着这段时间，来个漂亮的弯道超车(^^)  
好了，回归正题。今天读完了掌阅科技技术专家老钱的《Redis深度历险》。书不错，学到了很多东西。好记性不如烂笔头，在此记录一下，方便记忆。  
全书共分为五章  
基础和应用篇；原理篇；集群篇；拓展篇；源码篇

基础和应用篇，主要介绍了一下redis五种常见数据结构的使用方式  
没有什么可说的，这个大家应该都很熟悉了。值得注意的是zset的数据结构是跳跃表。跳跃表的设计，在我上一篇博客中已经简要介绍了一下，跳跃表的设计非常的优雅，感兴趣的同学可以研究一下。  
应用篇里提到了HyperLogLog数据结构，这个数据结构我们可以想象为是一个set结构的增强版。set如果存储上百万的数据，耗费的空间是惊人的。HyperLogLog可以用来对上百万的数据做一个去重功能，而且需要的空间很小。但是有一个缺点，它得出来的数据量不准确，标准误差是0.81%。100万数据的话，HyperLogLog统计的数量大概在991900个，对于一些要求不是很高的场景来说，已经够用了。  
紧接着，书中介绍了布隆过滤器。布隆过滤器在高并发的场景中非常的有用。布隆过滤器就是一个大的位数组和几个无偏hash函数。同一个key到来时，通过这几个hash函数分别对key求hash，得到一个整数的索引值，然后使用该索引值对位数组求模运算得到一个维数组的下标值，然后将该值置为1。同样的，其他几个hash函数对key求hash，最后也将位数组的某个位置置为1。下一个key来请求的时候，使用同样的hash函数对其求hash值，如果对应的位数组位置都是1 ，说明这个布隆过滤器见过这个key。bf.exists就会返回1。布隆过滤器也是有误差的。布隆过滤器说某个值存在时，它可能不存在。但是如果布隆过滤器说某个值没见过时，那它一定是没见过。这个特性可以很好的用来防止缓存穿透攻击。不过，布隆过滤器的使用，redis要升级到4.0版本，通过模块使用才可以。github上有人在维护，可以下载下来，将布隆过滤器配置在redis的配置文件里就可以使用了。  
基础篇里讲到了一个非常有意思的模块，GeoHash。它可以计算出附进的人。我们输入自己的坐标，然后输入别人的坐标。它可以计算出你们两个的距离，同时你输入自己的坐标，然后指定一个距离，它可以计算出你附近的元素。我们可以将Geo模块想象成zset结构，通过score排序就可以得到坐标附近的其他元素。Geo的数据存储是通过zset结构。单个key的大小不宜超过1MB，否则会导致集群迁移出现卡顿现象。所以，建议Geo模块使用单独的redis实例部署，不使用集群环境。如果数据量过亿个，甚至更大，就要对Geo数据按照一定的规律拆分，降低单个zset结构的大小  
基础篇的最后，讲了scan命令。和它意思差不多的命令是keys命令。但是keys命令在大数量的场景下，非常的危险。因为它会一次性吐出满足条件的所有key，如果key的数量超过千万级，这条命令会直接导致redis卡顿，影响redis正常的读写请求。所有的redis读写指令都要等这个keys命令执行完才能正常执行。  
scan命令完美的解决了以上问题，它提供了limit参数，可以控制每次遍历的hash槽的数量。某次遍历可能没有返回任何数据，但是不代表遍历已经完成。只有当返回的游标值为0时，才是真正的遍历完成。不同的数据结构有不同的scan命令，hsan可以遍历hash结构，zscan可以遍历zset，sscan可以遍历set。  
scan命令还可以扫描大key，大key对于集群的迁移非常有影响。不过，如果使用scan命令扫描大key，需要写脚本。redis官方在redis-cli命令中提供了这样的功能，一条命令就可以得到当前redis环境中的大key信息，很直观。  
以上就是基础篇重点内容

下一篇是原理篇  
原理篇，先讲的是redis的IO模型  
redis的IO模型是IO多路复用。关于redis的多路复用，我前面也有一篇文章，感兴趣的可以看一下。IO多路复用，我理解就一句话。之前的socket是顺序执行，现在的多个socket被linux内核监控起来，可读可写时就返回可读可写的状态。这样就可以顺序执行已经就绪的socket，省了很多无用的操作。  
之后，非常重要的一个环节介绍是redis的持久化机制。我们知道redis是完全基于内存操作的。那么一旦redis宕机，所有的数据都会丢失。这对于生产环境来说是灾难性的。所以，这就引出了redis的持久化机制，redis的持久化机制一共有两种。RDB和AOF。前者是快照模式，后者是连续的增量备份模式。  
快照模式就是，redis会调用glibc函数fork一个子进程。由子进程执行持久化操作。父进程继续处理客户端的请求。一次性就redis中的所有数据全部持久化，这里面涉及到了COW机制。  
redis默认是RDB模式，默认策略是：  
900 1  
300 10  
60 10000  
900秒内有1个key变更  
300秒内有10个key变更  
60秒内有10000个key变更  
以上情况都会触发快照模式持久化，生成一个rdb文件。redis重启时，会加载持久化文件中的数据  
第二种持久化机制是AOF模式，redis会将redis实例启动以来所有修改性的指令全部持久化到AOF文件中，当redis服务端收到客户端的修改性指令时，先校验然后执行，最后写入AOF文件。当redis启动时，读取AOF文件中的内容。注意，redis是先执行指令然后再生成AOF文件，这不同于很多的存储引擎。redis为什么要这样做？  
因为redis认为，除非程序员自己输错，否则redis指令不会出现错误。如果先记日志，就会导致AOF中有大量的错误指令。程序员先把命令输入正确，redis再记日志。  
AOF增量备份模式是以文件的形式存在的，调用Linux提供的fsync(int fd)函数强制将指定文件的内容从内核缓存刷到磁盘。只要redis进程实时调用fsync函数就可以保证redis数据不丢失。默认情况下，redis每秒钟调用一次fsync函数，这个时间可以调，我们要在性能和安全性之间做一个权衡。除此之外，redis还提供了两种策略，一种是永不调用fsync函数，由linux系统决定何时将数据刷到磁盘中。一种是每执行一次指令调用一次fsync函数。这两种在生产上用的都不多.  
以上这两种模式，都有缺点：  
1 .RDB方式大块写磁盘，会加重系统负担  
2 .AOF方式每秒调用一次fsync，这是一个耗时的操作。会降低redis的性能。同时也会加重IO负担  
基于以上2点原因，redis的主节点不会进行持久化操作，持久化操作一般都会在从节点上进行。但是这样做，一定要注意主节点和从节点的同步工作，一旦出现网络分区，主节点没有及时将数据同步到从节点，就会导致数据丢失，所以生产上要注意多增加几个从节点。并做好对redis的监控工作  
重启redis时，一般不会采用rdb恢复内存数据，因为会丢失大量数据。但是重放AOF日志，redis启动时间又太长  
redis4.0采用了一种混合持久化的方式。也就是将rdb文件和增量的aof文件放在一起，这里的aof文件不再是全量的aof文件，而是rdb持久化开始到持久化结束的增量数据，通常这部分数据很少。所以，当redis4.0启动时，可以先加载rdb的内容，然后再重放aof的文件内容，大大提高了重启的效率  
接着，本书介绍了redis的管道操作，以及redis的事务。redis的管道操作对于操作同一个key来说的话，效率非常高，它的原理是将相同的操作放在一起，比如读读，写写。redis的事务不具备原子性。  
用的不多。之后讲了redis的发布订阅，redis原生的发布订阅是不具备持久化能力的，这就意味着一旦redis的订阅端宕机，宕机这段期间的消息就会全部丢失。所以，基于这个原因redis作者在5.0版本搞了一个stream数据结构，用来做持久化的消息队列。

接着进入拓展篇  
首先介绍redis的过期策略。redis的过期策略是redis会将设置了过期时间的key全部放入一个独立的字典中。每隔100毫秒扫描一次字典。但是redis没有说全部扫描，而是随机从字典中选取20个key，然后删除这20个key中已经过期的key，如果过期key的比例超过所有key比例的1/4，此时就会继续扫描20个key。如果这个操作过于频繁，redis会将扫描时间缩短到25毫秒一次，加快过期key的回收。除了这种过期策略，redis还提供了懒惰删除，也就是当访问这个key的时候检查检查该key是否失效。  
所以，redis会持续扫描这个过期key集合。直到其中的key变的稀疏（可能会持续多次），所以在此期间，一个正常的客户端请求到了，该请求至少会等待25毫秒。这样在生产中就会带来一个问题，如果我们将请求redis的超时时间设置的太短，比如：10毫秒，此时就会出现大量的请求超时。而且该种超时，不属于慢查询。无法查询出来。另外，我们要注意给key的过期时间都加上一个随机值，防止大量的key在同一时间过期，造成缓存击穿。  
redis的LRU策略，当redis的内存不足时，redis提供了多个LRU策略maxmemory-policy。redis的内存参数配置为：maxmemory  
默认是：不能写，只能读。  
redis采取的LRU淘汰策略是一种近似的LRU淘汰算法，使用随机采样法。随机挑出5个key，删除最旧的key，如果内存还是超出maxmemory。继续以上操作。  
接着，我们讲一下懒惰删除，这个操作在生产上来说，非常的重要。对于一个很大的key来说，如果我们直接del的话，很可能会导致单线程卡顿。此时，我们就会用到懒惰删除。懒惰删除的根本原理就是服务端发出一个删除命令，然后交给异步线程后台操作。比如删除：  
unlink key。  
比如flushall，对应的就是flushall async  
很好的解决了卡顿的问题。  
下面说了一些redis的安全操作，比如：我们限制redis的访问ip  
bind，再比如：keys命令很危险，我们可以直接在生产上把keys命令禁用掉，可以直接在配置文件的securiry模块中增加  
rename-command flushall " "  
这样flushall命令就不能用了  
然后关于安全，老钱讲解了spiped，用来在客户端和服务端之间构建ssl通道，防止redis跨机房访问时被窃听数据。  
最后一章，讲到了redis5种数据类型的底层实现。  
总体来说，redis就是一个大的hashmap，key对redis可见，value对redis不可见。value可以是任何值，比如list,zset等等。zset的数据结构，面试常问，感兴趣的，可以去看我的上一篇博客。  
好了，这本书的总结就到这里了。