底层基于：单线程 + IO复用技术
常用5大数据类型
底层数据结构
参考：【2024最新版，redis7】redis底层的10种数据结构_redis最新版本中的数据结构-CSDN博客
主要数据结构：
key 基本操作
查看当前库所有 key：
key *查看某个key是否存在：
exists key查看key什么类型：
type key删除key：
del key给key设定存活时间（单位s）：
expire key 10查看key是否过期：
ttl key查看库的key数量：
dbsize key
字符串 String
String是二进制安全，可以存储jpg图片、序列化对象
底层数据结构：简单动态字符串SDS，类似java的arraylist
最大长度：512M
列表 List
类似LinkedList
底层：快速双向链表，元素较少时，用一块连续内存存储，即listpack，当元素较多时，将多个listpack采用双向指针链接成链表quicklist，双向循环链表
集合 Set
特点：不重复
底层实现：redis 7.2 后，使用intset、listpack、hashtable
哈希 Hash
适合存储对象
存储方式：value 采用hash存储
Zset 有序集合
特点：有序，无重复
发布与订阅
redis支持的一种通信模式，与各种MQ相比，它比较轻量，适合小公司
实现不同客户端之间的通信
新数据类型
Bitmaps
一个位数组，只存放0、1
HyperLogLog
只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。
支持统计，合并操作
Geographic
提供了经纬度设置，查询，范围查询，距离查询，经纬度Hash等常见操作。
事务
基本命令
错误处理
一：在组队阶段报错，则提交失败，队列命令都取消
二：在组队阶段不报错，则提交成功，队列命令除错误的都执行
事务实现机制
利用乐观锁实现，适用于多读的应用类型
Redis事务的三特性
单独的隔离操作
事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
没有隔离级别的概念
队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行
不保证原子性
事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚
与MySql事务的区别
事务实现原理：
Mysql基于undo/redo日志实现事务
Redis基于commands队列
原子性：
Mysql原子性由undolog回滚日志保证；
Redis没有实现原子性，不支持回滚
持久性：
Mysql持久性由redolog前滚日志保证；
Redis没有严格保证持久性，只是部分实现
隔离级别：
Mysql支持4种隔离标准；
Redis事务执行时，会阻塞其他操作，满足隔离性
Redis 秒杀案例
使用工具ab模拟测试
连接超时问题：使用连接池
超卖问题：乐观锁解决
乐观锁导致库存遗留问题：LUA脚本解决，其实现原子性
Redis 持久化
RDB方式
：指定间隔时间内将内存中的数据异步的方式写入磁盘
：实现：Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
备份： 启动Redis时，会自动加载指定位置的dump.rdb的数据
优点：
适合大规模的数据恢复
对数据完整性和一致性要求不高的情况下使用
节省磁盘空间
恢复快
缺点：
内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑，（两倍的内存空间）
如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。
AOF方式
以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
：AOF和RDB方式同时开启，Redis默认使用AOF方式恢复数据，即不会使用dump.rdb来恢复
优点：
备份机制更稳健，丢失数据概率更低。
可读的日志文本，通过操作AOF稳健，可以处理误操作。
缺点：
比起RDB占用更多的磁盘空间。
恢复备份速度要慢。
每次读写都同步的话，有一定的性能压力。
存在个别Bug，造成恢复不能。
主从复制
主以写为主，从以读为主
优点：
读写分离，性能扩展
容灾快速恢复
原理
l Slave启动成功连接到master后会发送一个sync命令
l Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令， 在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步
l 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
l 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步
l 但是只要是重新连接master,一次完全同步（全量复制)将被自动执行
薪火相传：上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。
反客为主：可以手动将从改为主
哨兵模式
反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库
集群
：用 N 台服务器，每台上单独开启Redis服务，将 N 台服务器集群，每台服务器存储均分存储总数据，即存储总数据的 1 / N。
好处
Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。
扩容，解决海量存储
分摊并发写操作，负载均衡
插槽
一个 Redis 集群包含 16384 个插槽（hash slot）， 数据库中的每个键都属于这 16384 个插槽的其中一个，
集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。
集群中的每个节点(服务器)负责处理一部分插槽。 举个例子， 如果一个集群可以有主节点， 其中：
节点 A 负责处理 0 号至 5460 号插槽。
节点 B 负责处理 5461 号至 10922 号插槽。
节点 C 负责处理 10923 号至 16383 号插槽。
写操作
在redis-cli每次录入、查询键值，redis都会计算出该key应该送往的插槽，如果不是该客户端对应服务器的插槽，redis会报错，并告知应前往的redis实例地址和端口。
应用问题
缓存穿透
：突然出现大量访问，且访问的数据在缓存访问不到，则访问数据库，造成数据库的崩溃
解决方案：
（1） 对空值缓存：如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟
（2） 设置可访问的名单（白名单）：
使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。
（3） 采用布隆过滤器：(布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量(位图)和一系列随机映射函数（哈希函数）。
布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。)
将所有可能存在的数据哈希到一个足够大的bitmaps中，一个一定不存在的数据会被 这个bitmaps拦截掉，从而避免了对底层存储系统的查询压力。
（4） 进行实时监控：当发现Redis的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务
缓存击穿
：Redis中的key过期，刚好有大量并发请求来访问这个key，发现过期则从数据库中找，瞬间将数据库压垮
解决问题：
（1）预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长
（2）实时调整：现场监控哪些数据热门，实时调整key的过期时长
（3）使用锁：
缓存雪崩
key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
缓存雪崩与缓存击穿的区别在于这里针对很多key缓存，前者则是某一个key
解决方案：
（1） 构建多级缓存架构：nginx缓存 + redis缓存 +其他缓存（ehcache等）
（2） 使用锁或队列：
用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况
（3） 设置过期标志更新缓存：
记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际key的缓存。
（4） 将缓存失效时间分散开：
比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。