字符串：类似vector，有空闲的空间 capacity和len，当长度小于1M时，每次扩容加倍，大于1M，每次扩容1M，最大512M
hash: 相当于c++ unordered_map,当需要rehash时，不是一次性，而是循序渐进式将旧hash的内容一点点迁移到新的hash结构中(定时任务，以及hash的子指令)
set:unordered_set 值具有唯一性
zset: 里面的值根据score值排序，使用跳跃列表，(还需要一个hash结构来存储value和score的对应关系)
跳跃列表
L2 25%
L1 50%
L0 100%
排好序，二分查找法，查找到合适的地方进行插入
list：quicklist ziplist<==>ziplist<==>ziplist(多个连续的空间)
redis的列表结构常用作异步队列，将需要延后处理的任务结构体序列化成字符串进redis的列表，另一个列表从这个列表轮询数据处理，不能保证100%的可靠性
压缩列表ziplist:小对象压缩存储，zset和hash容器对象在元素个数较少的时候，采用ziplist进行存储，是一块连续的内存，元素之间紧挨着存储
当元素增多，会升级成标准结构
位图:不是特殊的数据结构，内容就是普通的字符串，byte数组，可以使用get/set直接获取和设置整个位图的内容，也可以使用
getbit/setbit将byte数组看成位数组来处理
redis分布式锁：setnx和expire组合在一起形成一个原子指令，是分布式锁的奥义，原子操作：不会被线程调度打断的操作，中间不会有context switch的线程切换
不能处理较长时间的业务逻辑，set的时候设置一个随机数，然后删除的时候，判断是否跟这个随机数一致
延时队列：
redis的zset实现，消息序列化到zset的value，到期时间作为score，消费者根据到期时间进行处理
HyperLogLog：提供不精确的去重计数方案，虽然不精确，但也不是非常不精确，误差率0.81%,元素少时，占用少，多时会占用12k的空间，相对于set四两拨千斤，但不能确定某个值是否已经存在
布隆过滤器：判断元素是否在里面，有误判。可以装入大量的数据，如果使用set空间太大了,可以理解为不怎么精确的set结构
限流{
简单限流
漏斗限流
令牌桶
}
GeoHash:将二维的经纬度数据映射到一维的整数，所有的元素都挂在一条线上，然后取该点附近的点。等于是将地球看成一个棋盘，二分法。放到zset(skiplist),比较简单得到附近的元素
将其想象成zset结构，将所有的数据放到zset中，会很大，需要单独部署，按照国家等区分，减小单个key的数量
keys: 会阻塞线程 scan：不会阻塞线程
指令队列：redis将每个客户端套接字都关联一个指令队列，排队顺序处理。响应队列：将查询结果放到队列中，注册写事件。
持久化：
快照：rdb，内存数据二进制序列化形式 aof：内存数据的修改的指令记录文本
rdb：fork子进程，子进程持久化，父进程负责写，cow(写时复制页面修改)，每个页面4k大小，从节点来持久化，主节点提供访问
混合持久化：aof是持久化开始，到持久化结束这段时间的aof日志。在redis重启时，先加载rdb，然后重放aof日志
管道：
客户端类似合并多条读或者多条写，能够大幅提升效率
pub/sub:
redis消息队列不足：不支持消息多播
但是有缺点，不能持久化
生产者--->通道(channel){订阅者，订阅者。。。}
主从同步
CAP
C:一致性
A:可用性
P：分区容忍性
网络分区发生时，一致性和可用性两难全
redis满足最终一致性，
1.增量同步
主节点将修改性指令记录在本地内存buffer中，然后异步的将buffer中的指令同步到从节点，从节点一边同步指令，一边向主机点反馈同步的地点
buffer是环形数组，如果满了，从头覆盖内容
2.快照同步
如果主从长时间断开，则会快照同步，主库bgsave，然后将快照内容传递给从节点，从节点执行全量加载，需要设置正确的buffer大小，避免快照同步的死循环
从节点刚刚假如集群时，会先执行一次快照同步，然后执行增量同步
3.主从复制是分布式的基础，如果只当缓存用无需，如果用到了持久化功能，就必须认真对待主从同步，是数据安全的保障
sentinel:
当故障发生时，自动的进行主从切换
redis-sentinel --- redis-sentinel --- redis-sentinel(3-5个)
master master master
slave slave slave
c->redis-sentinel(返回master地址) 客户端来连接集群时，先连接sentinel,通过sentinel来查询主节点的地址，然后连接主节点进行数据交互
连接池建立新连接时，会去查询主库地址，然后跟内存中的主库地址比对，如果变更了，就断开所有连接
codis
集群方案之一
1024个slot
key->crc32->%1024 的值就是key对应的槽位
每个槽位，对应唯一的redis实例
cluster
官方的redis集群方案
去中心化
16384slot
redisnode(slot) -- redisnode(slot) -- redisnode(slot)
key->crc32->%16384 的值就是key对应的槽位
迁移工具：redis_trib
从源节点获取内容->存到目标节点->从源节点删除
stream
是可持久化的消息队列
stream消息模型借鉴了kafka的消息分组的概念，弥补了pub/sub不能持久化的缺点，kafka可以分partition而redis不行，
info
了解redis的运行状态，内部一系列运行参数
info stats
monitor:快速观察哪些key访问比较频繁
info client:redis连接了多少客户端 client list
info memory
复制缓冲区
info replication
info stats|grep sync
分布式锁
过期策略
redis将设置了过期的key放入一个独立的字典中，以后定时遍历这个字典来删除，还有惰性删除，惰性删除就是在访问key的时候，发现过期了就立马删除
定时删除是集中处理，惰性删除是零散处理
给过期时间加一个随机值，防止在同一个时间过期
从库同步异步删除
LRU
懒惰处理：当redis执行写操作时，发现内存超出maxmemory，执行一次LRU淘汰算法
volatile-xxx:只会针对带过期时间的key进行淘汰
allkeys-xxx:会对多有的key进行淘汰
懒惰删除 lazy free
引入unlink 能对删除进行懒惰处理，对给后台线程异步回收内存
字典：
1.hash结构
rax:
zset按照score排序，rax按照key排序，类似与英语字典，这样可以快速检索单词，并且可以某个前缀开头的单词
