Redis高级知识概括

Posted 2022-04-12 GeorgeLin98

Redis高级知识概括

• Redis新数据类型
• Redis集群
• Redis应用问题
• 分布式锁
• Redis 脚本
• Redis内存回收策略
• Redis底层原理
• redis内部编码

Redis新数据类型

Bitmaps：

• 现代计算机用二进制（位） 作为信息的基础单位， 1个字节等于8位， 例如“abc”字符串是由3个字节组成，但实际在计算机存储时将其用二进制表示， “abc”分别对应的ASCII码分别是97、 98、 99， 对应的二进制分别是01100001、01100010和01100011。合理地使用操作位能够有效地提高内存使用率和开发效率。
• Redis提供了Bitmaps这个“数据类型”可以实现对位的操作：
  ①Bitmaps本身不是一种数据类型， 实际上它就是字符串（key-value） ， 但是它可以对字符串的位进行操作。
  ②Bitmaps单独提供了一套命令， 所以在Redis中使用Bitmaps和使用字符串的方法不太相同。 可以把Bitmaps想象成一个以位为单位的数组， 数组的每个单元只能存储0和1， 数组的下标在Bitmaps中叫做偏移量。
• 命令：
  ①setbit：setbit<key><offset><value>设置Bitmaps中某个偏移量的值（0或1）
  <1>offset:偏移量从0开始
  <2>很多应用的用户id以一个指定数字（例如10000） 开头， 直接将用户id和Bitmaps的偏移量对应势必会造成一定的浪费， 通常的做法是每次做setbit操作时将用户id减去这个指定数字。
  <3>在第一次初始化Bitmaps时， 假如偏移量非常大， 那么整个初始化过程执行会比较慢， 可能会造成Redis的阻塞。
  ②getbit：getbit<key><offset>获取Bitmaps中某个偏移量的值
  ③bitcount：bitcount<key>[start end] 统计字符串从start字节到end字节比特值为1的数量
  <1>统计字符串被设置为1的bit数。一般情况下，给定的整个字符串都会被进行计数，通过指定额外的 start 或 end 参数，可以让计数只在特定的位上进行。start 和 end 参数的设置，都可以使用负数值：比如 -1 表示最后一个位，而 -2 表示倒数第二个位，start、end 是指bit组的字节的下标数，二者皆包含。
  <2> 注意：redis的setbit设置或清除的是bit位置，而bitcount计算的是byte位置。
  ④bitop：格式bitop and(or/not/xor) <destkey> [key…]
  <1>bitop是一个复合操作， 它可以做多个Bitmaps的and（交集） 、 or（并集） 、 not（非） 、 xor（异或） 操作并将结果保存在destkey中。
• Bitmaps与set对比：
  ①假设网站有1亿用户， 每天独立访问的用户有5千万， 如果每天用集合类型和Bitmaps分别存储活跃用户可以得到表。
  
  ②但Bitmaps并不是万金油， 假如该网站每天的独立访问用户很少， 例如只有10万（大量的僵尸用户） ， 那么两者的对比如下表所示， 很显然， 这时候使用Bitmaps就不太合适了， 因为基本上大部分位都是0。
  

HyperLogLog：

• 在工作当中，我们经常会遇到与统计相关的功能需求，比如统计网站PV（PageView页面访问量）,可以使用Redis的incr、incrby轻松实现。但像UV（UniqueVisitor，独立访客）、独立IP数、搜索记录数等需要去重和计数的问题如何解决？这种求集合中不重复元素个数的问题称为基数问题。解决基数问题有很多种方案：
  ①数据存储在mysql表中，使用distinct count计算不重复个数
  ②使用Redis提供的hash、set、bitmaps等数据结构来处理
• 以上的方案结果精确，但随着数据不断增加，导致占用空间越来越大，对于非常大的数据集是不切实际的。能否能够降低一定的精度来平衡存储空间？Redis推出了HyperLogLog。
• Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog
  的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。 在 Redis 里面，每个HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64个不同元素的基数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。
• 什么是基数：比如数据集 1, 3, 5, 7, 5, 7, 8， 那么这个数据集的基数集为 1, 3, 5 ,7, 8, 基数(不重复元素)为5。 基数估计就是在误差可接受的范围内，快速计算基数。
• 命令：
  ①pfadd格式：pfadd <key>< element> [element ...] 添加指定元素到 HyperLogLog 中。
  <1>将所有元素添加到指定HyperLogLog数据结构中。如果执行命令后HLL估计的近似基数发生变化，则返回1，否则返回0。
  ②pfcount格式：pfcount<key> [key ...] 计算HLL的近似基数，可以计算多个HLL，比如用HLL存储每天的UV，计算一周的UV可以使用7天的UV合并计算即可
  ③pfmerge格式：pfmerge<destkey><sourcekey> [sourcekey ...] 将一个或多个HLL合并后的结果存储在另一个HLL中，比如每月活跃用户可以使用每天的活跃用户来合并计算可得

Geospatial：

• Redis 3.2中增加了对GEO类型的支持。GEO，Geographic，地理信息的缩写。该类型，就是元素的2维坐标，在地图上就是经纬度。redis基于该类型，提供了经纬度设置，查询，范围查询，距离查询，经纬度Hash等常见操作。
• 命令：
  ①geoadd格式：geoadd<key>< longitude><latitude><member> [longitude latitude member...] 添加地理位置（经度，纬度，名称）
  <1>两极无法直接添加，一般会下载城市数据，直接通过 Java 程序一次性导入。
  <2>有效的经度从 -180 度到 180 度。有效的纬度从 -85.05112878 度到 85.05112878 度。当坐标位置超出指定范围时，该命令将会返回一个错误。已经添加的数据，是无法再次往里面添加的。
  ②geopos格式：geopos <key><member> [member...] 获得指定地区的坐标值
  ③geodist格式：geodist<key><member1><member2> [m|km|ft|mi ] 获取两个位置之间的直线距离
  <1>单位：
  1、m 表示单位为米[默认值]。
  2、km 表示单位为千米。
  3、mi 表示单位为英里。
  4、ft 表示单位为英尺。
  <2>如果用户没有显式地指定单位参数， 那么 GEODIST 默认使用米作为单位。
  ④georadius格式：georadius<key>< longitude><latitude>radius m|km|ft|mi 以给定的经纬度为中心，找出某一半径内的元素

Redis集群

什么是集群：

• Redis 集群实现了对Redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。
• Redis 集群通过分区（partition）来提供一定程度的可用性（availability）：即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。

redis集群配置基本信息：

• redis.conf：

cluster-enabled yes    打开集群模式
cluster-config-file nodes-XXX.conf  设定节点配置文件名
cluster-node-timeout 15000   设定节点失联时间，超过该时间（毫秒），集群自动进行主从切换。

集群设置：

• 搭建集群命令：

cluster create --cluster-replicas 1 192.168.11.101:6379 192.168.11.101:6380 192.168.11.101:6381 192.168.11.101:6389 192.168.11.101:6390 192.168.11.101:6391

• redis cluster 如何分配这六个节点?
  ①一个集群至少要有三个主节点。
  ②选项 --cluster-replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。分配原则尽量保证每个主数据库运行在不同的IP地址，每个从库和主库不在一个IP地址上。

什么是slots：

• 一个 Redis 集群包含 16384 个插槽（hash slot）， 数据库中的每个键都属于这 16384 个插槽的其中一个， 集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16(key) 语句用于计算键 key 的CRC16 校验和 。
• 集群中的每个节点负责处理一部分插槽。 举个例子， 如果一个集群可以有主节点， 其中：
  ①节点 A 负责处理 0 号至 5460 号插槽。
  ②节点 B 负责处理 5461 号至 10922 号插槽。
  ③节点 C 负责处理 10923 号至 16383 号插槽。

故障恢复：

• 如果主节点下线？从节点能否自动升为主节点？注意：15秒超时
• 主节点恢复后，主从关系会如何？主节点回来变成从机。
• 如果所有某一段插槽的主从节点都宕掉，redis服务是否还能继续?
  ①如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为yes ，那么 ，整个集群都挂掉
  ②如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为no ，那么，该插槽数据全都不能使用，也无法存储。
  ③redis.conf中的参数 cluster-require-full-coverage

Redis 集群优劣：

• 提供了以下好处：
  ①实现扩容
  ②分摊压力
  ③无中心配置相对简单
• Redis 集群的不足：
  ①多键操作是不被支持的
  ②多键的Redis事务是不被支持的。lua脚本不被支持
  ③由于集群方案出现较晚，很多公司已经采用了其他的集群方案，而代理或者客户端分片的方案想要迁移至redis cluster，需要整体迁移而不是逐步过渡，复杂度较大。

Redis应用问题

缓存穿透：

• 问题描述：key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会压到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。
  
• 解决方案：一个一定不存在缓存及查询不到的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。
  ①对空值缓存：如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟
  ②设置可访问的名单（白名单）：使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。
  ③采用布隆过滤器：(布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量(位图)和一系列随机映射函数（哈希函数）。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。)将所有可能存在的数据哈希到一个足够大的bitmaps中，一个一定不存在的数据会被 这个bitmaps拦截掉，从而避免了对底层存储系统的查询压力。
  ④进行实时监控：当发现Redis的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务

缓存击穿：

• 问题描述：key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
  
• 解决方案：key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题。
  ①预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长
  ②实时调整：现场监控哪些数据热门，实时调整key的过期时长
  ④使用锁：
  <1>就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db。
  <2>先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX）去set一个mutex key
  <3>当操作返回成功时，再进行load db的操作，并回设缓存,最后删除mutex key；
  <4>当操作返回失败，证明有线程在load db，当前线程睡眠一段时间再重试整个get缓存的方法。
  

缓存雪崩：

• 问题描述：key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。缓存雪崩与缓存击穿的区别在于这里针对很多key缓存，前者则是某一个key。
  ①正常访问
  
  ②缓存失效瞬间
  
• 解决方案：缓存失效时的雪崩效应对底层系统的冲击非常可怕！
  ①构建多级缓存架构：nginx缓存 + redis缓存 +其他缓存（ehcache等）
  ②使用锁或队列：用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况
  ③设置过期标志更新缓存：记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际key的缓存。
  ④将缓存失效时间分散开：比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

分布式锁

分布式锁简介：

• 随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！
• 分布式锁主流的实现方案：
  ①基于数据库实现分布式锁
  ②基于缓存（Redis等）
  ③基于Zookeeper
• 每一种分布式锁解决方案都有各自的优缺点：
  ①性能：redis最高
  ②可靠性：zookeeper最高
• 这里我们就基于redis实现分布式锁。

解决方案：

• set命令：
  ①EX second ：设置键的过期时间为 second 秒。 SET key value EX second 效果等同于 SETEX key second value 。
  ②PX millisecond ：设置键的过期时间为 millisecond 毫秒。 SET key value PX millisecond 效果等同于 PSETEX key millisecond value 。
  ③NX ：只在键不存在时，才对键进行设置操作。 SET key value NX 效果等同于 SETNX key value。
  ④XX ：只在键已经存在时，才对键进行设置操作。

• 流程：
  ①多个客户端同时获取锁（setnx）
  ②获取成功，执行业务逻辑从db获取数据，放入缓存，执行完成释放锁（del）
  ③其他客户端等待重试
  

• 优化之设置锁的过期时间：(问题：setnx刚好获取到锁，业务逻辑出现异常，导致锁无法释放)
  ①解决：设置过期时间，自动释放锁。设置过期时间有两种方式：
  <1>首先想到通过expire设置过期时间（缺乏原子性：如果在setnx和expire之间出现异常，锁也无法释放）
  <2>在set时指定过期时间（推荐）
  

• 优化之UUID防误删：
  

• 优化之LUA脚本保证删除的原子性：(问题：删除操作缺乏原子性。)

为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件：

• 互斥性。在任意时刻，只有一个客户端能持有锁。
• 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。
• 解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。
• 加锁和解锁必须具有原子性。

Redis 脚本

简介：

• Redis 脚本使用 Lua 解释器来执行脚本。 Redis 2.6 版本通过内嵌支持 Lua 环境。执行脚本的常用命令为 EVAL。
• 命令：
  ①EVAL：执行 Lua 脚本。
  ②EVALSHA ：执行 Lua 脚本。
  ③SCRIPT EXISTS ：查看指定的脚本是否已经被保存在缓存当中。
  ④SCRIPT FLUSH：从脚本缓存中移除所有脚本。
  ⑤SCRIPT KILL：杀死当前正在运行的 Lua 脚本。
  ⑥SCRIPT LOAD ：将脚本 script 添加到脚本缓存中，但并不立即执行这个脚本。
• 一般来说：
  ①脚本保存在服务器端，不易修改，但执行速度快。
  ②脚本保存在客户端，易修改，但执行速度慢。

Redis内存回收策略

Redis内存回收机制主要体现在以下两个方面：

• 删除到达时间的键对象(key失效机制)：
  ①Redis所有的键都可以设置过期属性，内部保存在过期字典中。由于进程内保存了大量的键，维护每个键精准的过期删除机制会导致消耗大量的CPU，对于单线程的Redis来说成本过高，因此Redis采用惰性删除和定时任务删除机制实现过期键的内存回收。
  <1>惰性删除：惰性删除用于当客户端读取带有超时属性的键时，如果已经超过键设置的过期时间，会执行删除操作并返回空，这种策略是出于节省CPU成本考虑，不需要单独维护TTL链表来处理过期键的删除。但是单独用这种方式存在内存泄露的问题，当过期键一直没有访问将无法得到及时删除，从而导致内存不能及时释放。正因为如此，Redis还提供另一种定时任务删除机制作为惰性删除的补充。
  <2>定时任务删除：Redis内部维护一个定时任务，默认每秒运行10次（通过配置hz控制）。定时任务中删除过期键逻辑采用了自适应算法，根据键的过期比例，使用快慢两种速率模式回收键。比如：
  1、定时任务在每个数据库空间随机检查20个键，当发现过期时删除对应的键。
  2、如果超过检查数25%的键过期，循环执行回收逻辑直到不足25%或运行超时为止，慢模式下超时时间为25ms。
  3、如果之前回收键逻辑超时，则在Redis触发内部事件之前再次以快模式运行回收过期键任务，快模式下超时时间为1ms且2s内只能运行1次。
  4、快慢两种模式内部删除逻辑相同，只是执行的超时时间不同。
  ②归纳：
  <1>定时删除：在设置键的过期时间的同时，创建一个定时器（timer），让定时器在键的过期时间来临时，立即执行对键的删除操作
  <2>惰性删除：在取出键时才对键进行过期检查，如果发现过期了就会被删除
  <3>定期删除：定期删除策略是定时删除策略和惰性删除策略的一个折中。定期删除策略每隔一段时间执行一次删除过期键的操作，并通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响。
  ③总结：Redis服务器实际使用的是惰性删除和定期删除两种策略：通过配合使用这两种删除策略，服务器可以很好地在合理使用CPU时间和避免浪费内存空间之间取得平衡。Redis默认每隔100ms随机抽取一些设置了过期时间的key，检查是否过期，如果过期就删除。
• 内存使用达到maxmemory上限时触发内存溢出控制策略(淘汰策略)：当Redis所用内存达到maxmemory上限时会触发相应的溢出控制策略。具体策略受maxmemory-policy参数控制，Redis支持6种策略，如下所示：
  ①noeviction：默认策略，当内存不足以容纳新写入数据时，新写入操作会报错。应该没人用吧。
  ②allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 Key。推荐使用，目前项目在用这种。
  ③allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个 Key。应该也没人用吧，你不删最少使用 Key，去随机删。
  ④volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 Key。这种情况一般是把 Redis 既当缓存，又做持久化存储的时候才用。不推荐。
  ⑤volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个 Key。依然不推荐。
  ⑥volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的 Key 优先移除。不推荐。如果没有对应的键，则回退到noeviction策略。
  ⑦记忆方式：
  <1>单词组成：3个volatile开头的，2个all_keys开头。都是lru，random，只有volatile有ttl方式。最后加一个noeviction
  <2>volatile：指的都是快过期的数据集。
  <3>all_keys:是所有的数据集。
  <4>lru:是选择最近长时间不使用的，一般用作缓存机制。
  <5>random:就是随机选一个。
  <6>ttl:就是过期时间的设置
  <7>noeviction:不做任何设置

Redis底层原理

Redis单线程简介：

• Redis采用的是基于内存的采用的是单进程单线程模型的 KV 数据库，由C语言编写，官方提供的数据是可以达到100000+的QPS（每秒内查询次数）
• 完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；
• 数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；
• 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
• 使用多路I/O复用模型，非阻塞IO；
• 使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；
• 链接：为什么说Redis是单线程

下边我们针对多路 I/O 复用模型进行简单的探讨：

• 多路I/O复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。
• 这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络IO 的时间消耗），且 Redis在内存中操作数据的速度非常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈，主要由以上几点造就了 Redis 具有很高的吞吐量。

那么为什么Redis是单线程的：

• 因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。
• 既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了（毕竟采用多线程会有很多麻烦！）。

IO多线程简介：

• Redis6终于支撑多线程了，告别单线程了吗？
• IO多线程其实指客户端交互部分的网络IO交互处理模块多线程，而非执行命令多线程。Redis6执行命令依然是单线程。
• 原理架构：Redis 6 加入多线程,但跟 Memcached 这种从 IO处理到数据访问多线程的实现模式有些差异。Redis 的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程。之所以这么设计是不想因为多线程而变得复杂，需要去控制 key、lua、事务，LPUSH/LPOP 等等的并发问题。整体的设计大体如下：
  
• 另外，多线程IO默认也是不开启的，需要再配置文件中配置：

io-threads-do-reads  yes 
io-threads 4

redis内部编码

Redis 9种内部编码实现：

• 链接：Redis 9种数据结构以及它们的内部编码实现
• 我们常说的String，List，Hash，Set，SortedSet只是对外的编码，实际上每种数据结构都有自己底层的内部编码实现，而且是多种实现，这样Redis可以在合适的场景选择更合适的内部编码。
• 如下图所示（图片纠正：intset编码，而不是inset编码），可以看到每种数据结构都有2种以上的内部编码实现，例如String数据结构就包含了raw、int和embstr三种内部编码。同时，有些内部编码可以作为多种外部数据结构的内部实现，例如ziplist就是hash、list和zset共有的内部编码，而set的内部编码可能是hashtable或者intset：
  
• 首先redis内部使用一个redisObject对象来表示所有的key和value，redisObject最主要的信息如上图所示：type表示一个value对象具体是何种数据类型，encoding是不同数据类型在redis内部的存储方式。比如：type=string表示value存储的是一个普通字符串，那么encoding可以是raw或者int。