文本已收录至我的GitHub仓库,欢迎Star:https://github.com/bin392328206/six-finger 种一棵树最好的时间是十年前,其次是现在
面试指南系列,很多情况下不会去深挖细节,是小六六以被面试者的角色去回顾知识的一种方式,所以我默认大部分的东西,作为面试官的你,肯定是懂的。
https://www.processon.com/view/link/600ed9e9637689349038b0e4
上面的是脑图地址
这个系列也写了几篇了,今天我们来看看redis,前面的可以去github上看看。然后下面是前面的文章汇总
Redis是一个开放源代码(BSD许可)的内存中数据结构存储,用作数据库,缓存和消息代理。它支持数据结构,例如字符串,哈希,列表,集合,带范围查询的排序集合,位图,超日志,带有半径查询和流的地理空间索引。Redis具有内置的复制,Lua脚本,LRU逐出,事务和不同级别的磁盘持久性,并通过Redis Sentinel和Redis Cluster自动分区提供了高可用性。
优点
缺点
主要是为了提高系统的吞吐量,应对高并发,高性能场景
1、完全基于内存,绝大部分请求是纯粹的内存操作,非常快速。数据存在内存中,类似于HashMap,HashMap的优势就是查找和操作的时间复杂度都是O(1);
2、数据结构简单,对数据操作也简单,Redis中的数据结构是专门进行设计的;
3、采用单线程,避免了不必要的上下文切换和竞争条件,也不存在多进程或者多线程导致的切换而消耗 CPU,不用去考虑各种锁的问题,不存在加锁释放锁操作,没有因为可能出现死锁而导致的性能消耗(绝大多数的瓶颈不在cpu)
4、使用多路I/O复用模型,非阻塞IO;
5、使用底层模型不同,它们之间底层实现方式以及与客户端之间通信的应用协议不一样,Redis直接自己构建了VM 机制 ,使用了resp协议
Redis是Redis序列化协议,Redis客户端RESP协议与Redis服务器通信。Redis协议在以下几点之间做出了折衷:
其实就是一个二进制的序列化协议,举几个简单的例子哈 在RESP中,某些数据的类型取决于第一个字节:
“+”代表简单字符串Simple Strings
“+”代表错误类型
“:”代表整数
基于这种协议的话,其实我们可以自己去实现一个redis的客户端,以后有机会给大家写写。
那也很简单,你多起几个Redis进程就好了。Redis是key-value数据库,又不是关系数据库,数据之间没有约束。只要客户端分清哪些key放在哪个Redis进程上就可以了。redis-cluster可以帮你做的更好。
跳跃表。
sds
Redis的字符串,不是 C 语言中的字符串(即以空字符’\0’结尾的字符数组),它是自己构建了一种名为 简单动态字符串(simple dynamic string,SDS)的抽象类型,并将 SDS 作为 Redis的默认字符串表示。
1、len 保存了SDS保存字符串的长度
2、buf[] 数组用来保存字符串的每个元素
3、free j记录了 buf 数组中未使用的字节数量
链表
链表是一种常用的数据结构,C 语言内部是没有内置这种数据结构的实现,所以Redis自己构建了链表的实现
字典
字典又称为符号表或者关联数组、或映射(map),是一种用于保存键值对的抽象数据结构。字典中的每一个键 key 都是唯一的,通过 key 可以对值来进行查找或修改。C 语言中没有内置这种数据结构的实现,所以字典依然是 Redis自己构建的。
跳跃表 跳跃表(skiplist)是一种有序数据结构,它通过在每个节点中维持多个指向其它节点的指针,从而达到快速访问节点的目的。具有如下性质:
1、由很多层结构组成;
2、每一层都是一个有序的链表,排列顺序为由高层到底层,都至少包含两个链表节点,分别是前面的head节点和后面的nil节点;
3、最底层的链表包含了所有的元素;
4、如果一个元素出现在某一层的链表中,那么在该层之下的链表也全都会出现(上一层的元素是当前层的元素的子集);
5、链表中的每个节点都包含两个指针,一个指向同一层的下一个链表节点,另一个指向下一层的同一个链表节点;
压缩列表
压缩列表(ziplist)是Redis为了节省内存而开发的,是由一系列特殊编码的连续内存块组成的顺序型数据结构,一个压缩列表可以包含任意多个节点(entry),每个节点可以保存一个字节数组或者一个整数值。
压缩列表的原理:压缩列表并不是对数据利用某种算法进行压缩,而是将数据按照一定规则编码在一块连续的内存区域,目的是节省内存。
一个缓存雪崩发过程
如何解决缓存雪崩
第一种方案:缓存层设计成高可用,防止缓存大面积故障。即使个别节点、个别机器、甚至是机房宕掉,依然可以提供服务,例如 Redis Sentinel 和 Redis Cluster 都实现了高可用。
第二种方案:在批量往Redis存数据的时候,把每个Key的失效时间都加个随机值就好了,这样可以保证数据不会在同一时间大面积失效,我相信,Redis这点流量还是顶得住的。
我个人理解 击穿 就是正面刚 比如我是矛 你是盾 我直接把你的盾击穿, 就是比如 几个热点Key 同时几百万并发直接把redis 干掉了, 然后数据全部打到数据库的情况,或者是redis的这几个热点数据失效的情景下,同时全部的并发查这个热数据,导致最后打到数据库的情况 这个就是缓存击穿。
如何解决缓存击穿
还是分布式锁 哈哈 因为分布式锁能控制到数据库的最后一到防线 redis做集群 哨兵
正常来说一般系统的qps都有一个峰值,一般我们使用能抗住这个峰值的内存去做这个缓存
缓存穿透是指缓存和数据库中都没有的数据,而用户不断发起请求,如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者,攻击会导致数据库压力过大。
如何解决缓存穿透
第一种方案 和上面的双重锁一样 如果是拿到数据库为空 那么就给这个key 设置一个null值 时间设置短一点 30s, 这样下次并发进来就不会说把数据打到我们的数据库上了
还有就是我们写代码的时候 要对一些非法的请求参数校验 我相信大家都是这样做的。
第二种方案 采用我们第一篇中学到的一个高级用法 bitMap,查询的时候先查bitmap确定是否含有这个key
几种方式缓存不一致的原因和解决方案
方案一 先更新数据库,再删缓存 这个方案的问题是什么呢?就是假设我们更新数据成功了 然后去删除缓存的时候失败了 这就导致了缓存中是老数据,会造成缓存不一致
那我们就要保证删除一定要成功,我们可以在最后删除的时候 多删除几次,第二个就是用一个中间件canal 去兼听mysql的binlog 然后 从binlong中解析出要删除的字段 然后 继续上面第一个的方式(这个方式的好处 全程也算是异步的跟业务代码是没有关系的)
方案二 先更新数据库,再更新缓存
这个操作 问题更多感觉 首先 更新数据成功 更新缓存失败,或者是开始更新数据库成功 然后更新缓存成功 然后事务回滚,也是缓存不一致。
方案三 删除缓存 再更新数据库 看起来好像最好 我反正是删除缓存了 就算更新失败 下次去读也是最新的数据(一切看起来很美好),其实不然,试想2个并发一个更新 一个查询 你先更新的时候 删除了缓存 但是此时 查询发现没有缓存 然后吧数据缓存到了数据库 就会去查数据库 但是此时更新的又更新成功,最后就会再很长的一个时间内 缓存和数据库是不一致的,所以这种是方案是不可取的
综上所诉,我觉得最好的方式先查再删除 然后再配合订阅binlong 来做多重删除的方式是不错的,可能我接触的不是很多,希望各位大佬有更好的方式提出
其实我觉得用volatile-lru就好了 毕竟报错是完全没有必要的 还有就是设置一个报警装置 如果不够了 就搞主从 哈哈
Redis为持久化提供了两种方式:
rdb是默认的持久化方式,打个比方,你可以设置比如 90s内 有一次写入,就持久化一次,30s内5次写入就持久化一次等等,当然如果你想要禁用RDB配置,也是非常容易的,只需要在save的最后一行写上:save ""。
在Redis中RDB持久化的触发分为两种:自己手动触发与Redis定时触发。针对RDB方式的持久化,手动触发可以使用:
appendonly yes 首先是要开启aof。appendfsync everysec 它其实有三种模式:
AOF的整个流程大体来看可以分为两步,一步是命令的实时写入(如果是 appendfsync everysec 配置,会有1s损耗),第二步是对aof文件的重写。
对于增量追加到文件这一步主要的流程是:命令写入=》追加到aof_buf =》同步到aof磁盘。那么这里为什么要先写入buf在同步到磁盘呢?如果实时写入磁盘会带来非常高的磁盘IO,影响整体性能。
启动时会先检查AOF文件是否存在,如果不存在就尝试加载RDB。那么为什么会优先加载AOF呢?因为AOF保存的数据更完整,通过上面的分析我们知道AOF基本上最多损失1s的数据。
一些线上经验
主从架构的特点
主从架构的好处
主从架构的特点之一:主服务器和从服务器的数据是一致的。主从同步的2种情况
完整的同步
部分重同步
Redis 一般以主/从方式部署(这里讨论的应用从实例主要用于备份,主实例提供读写)该方式要实现 HA 主要有如下几种方案:
这个问题其实就是问 再集群环境下, redis 不同的key 存储到哪个节点的问题 , Redis 集群中内置了 16384 个哈希槽,当需要在 Redis 集群中放置一个 key-value 时,redis 先对 key 使用 crc16 算法算出一个结果,然后把结果对 16384 求余数, 这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽,redis 会根据节点数量大 致均等的将哈希槽映射到不同的节点。
Redis Cluster是自己做的crc16的简单hash算法,没有用一致性hash。Redis的作者认为它的crc16(key) mod 16384的效果已经不错了,虽然没有一致性hash灵活,但实现很简单,节点增删时处理起来也很方便。
这个话题基本上是分布式系统开发的一个必问的题目了 问你分布式锁是怎么实现的,然后大家可能就搭用它的 set NX EX命令 然后用lua脚本做成一个原子性操作来实现分布式锁。其实这么搭也可以吧,然后我们一般在生产环境的话,可能会用一些开源框架,你不如说Redisson来实现分布式锁。
redis就这些吧,接下来复习下es吧