数据类型
string/list/hash/set/zset
其中list底层数据结构3.2版本为quicklist(由linkedlist+ziplist组合而成)，zset由dict+skiplist实现
持久化机制
https://blog.csdn.net/JavaTeachers/article/details/108998121
rdb
关注点
- bgsave(即开始rbd备份)开启方式为x时间内发生了x次事件
- 可后台执行，通过操作系统命令fork子进程，该过程阻塞父线程（即不可接受新消息），fork之后通过内存快照异步生成rdb文件然后替换原rdb文件（即每次生成的rbd都是全量文件）
- 生成内存快照到下次fork子进程时间段中父进程做的增加命令无法同步
- rdb是格式紧凑的二进制文件，redis异常恢复速度快
aof
关注点
- aof本质是记录命令操作日志放入内存缓存区，然后在合适时机（可配置，默认为1s1次）写入磁盘
- aof很臃肿，记录了很多无用命令，需要重写
- 重写流程为fork子进程，子进程对内存快照中的数据转化为新增命令写入新的aof文件，同时父进程新开辟重写缓冲区，用来缓存生成内存快照到写完新aof文件这段时间内的新命令，完成新的aof文件后将重写缓冲区中的命令追加到aof，然后替换旧文件即完成整个重写流程
写时复制
fork子进程采用了写时复制技术，通俗来讲即当发生fork时，内核会把父进程的内存页权限设置为read-only，在父进程内存没有发生变化的场景下，子进程无需开辟新的物理内存空间，直接映射到父进程的内存地址，当此进程内存数据发生变化时，cpu硬件检测到内存页时read-only，会触发页异常中断，此时内核会开辟内存，复制内存数据，至此父子进程各有一份独立数据，在redis场景中表现出子进程在备份过程中，无法感知到最新的数据变化。
慢查询
showlog get
通信
客户端与服务端采用resp协议通信，协议特点简单、易读。
架构
- 单节点
- 主从
- 哨兵+主从，哨兵使用raft保持分布式一致性
- 集群
- 可扩展性，一致性hash,哈希槽
- 客户端如何知道数据在哪个节点：
- redis-cli这种最简单的客户端可以随意访问一个节点，然后如果数据不在该节点，节点会使用crc16算法计算key所在节点并返回一个move指令（包含key所在节点信息），然后客户端重定向到新的节点获取数据。
- 比如使用redisson工具类，实现了crc16算法，即可在客户端完成key所在节点计算，然后直接访问key所在节点
缓存异常场景
缓存雪崩
现象：大量key在短时间内集体过期/失效，导致数据库压力增大
解决：错开过期时间，预热数据，热点数据不过期
缓存击穿
现象：某一个key不在缓存中，高并发请求都查询这个key，导致数据库压力大
解决：对查库操作加锁即可，个人认为不需要互斥锁，目标只需要减少查库压力，只用sycronize锁即可
缓存穿透
现象：高并发查询不存在的key,导致数据库压力大，这种情况要不就是bug要不就是攻击
解决：从缓存角度来说解决，可以将空值缓存，可以在缓存层前面增加布隆过滤器，可以保证不存在的key极大概率不存在。布隆过滤器可以用redis bitmap实现，实现手段可使用轮子redisson开发，本质为hash算法，即为一个key采用多个hash算法，所以该key在hash表上会有多个位置，把这些位置全部设置为1，这样的目的是减少hash冲突，1个位置冲突容易，多个位置冲突就不容易了。
key过期策略
redis中key可以设置有效期expire，到期后key失效，但并不意味着这个时候key从redis中删除了。触发删除只有3种时机
- key失效后客户端又进行key查询，此时会将key删除并返回不存在
- redis定时任务扫描key进行删除
- redis内存满了之后触发删除
详情参考https://www.cnblogs.com/chenpingzhao/p/5022467.html?utm_source=tuicool&utm_medium=referral