字符串：类似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排序，类似与英语字典，这样可以快速检索单词，并且可以某个前缀开头的单词