REDIS

hset 对象名称 key value

QQ截图20170530103710.png

相当于 Java 语言里面的 LinkedList，注意它是链表而不是数组。这意味着 list 的插入和删除操作非常快，时间复杂度为 O(1)，但是索引定位很慢，时间复杂度为 O(n)

当列表弹出了最后一个元素之后，该数据结构自动被删除，内存被回收

Redis 的列表结构常用来做异步队列使用。将需要延后处理的任务结构体序列化成字符串塞进 Redis 的列表，另一个线程从这个列表中轮询数据进行处理。

lpush 从左边加入元素 rpush 从右边加入元素

lpop 从左边取元素 rpop 从右边取元素

linsert 插入元素

QQ截图20170530111735.png

QQ截图20170530115138.png

set是通过hashtable实现的，对集合可以去交集、并集、差集

sadd

smemebers

srem

spop

sdiff

sdiffstore

类似于 Java 的 SortedSet 和 HashMap 的结合体，一方面它是一个 set，保证了内部 value 的唯一性，另一方面它可以给每个 value 赋予一个 score，代表这个 value 的排序权重。

它的内部实现用的是一种叫做「跳跃列表」的数据结构。

最下面一层所有的元素都会串起来。然后每隔几个元素挑选出一个代表来，再将这几个代表使用另外一级指针串起来。然后在这些代表里再挑出二级代表，再串起来。

跳跃列表结构示意图.png

QQ截图20170530132942.png

命令

如果不存在则进行设置，如果存在就不进行设置，返回0

setex color 10 red

设置color的有效期为10秒，10秒后返回nil（redis里面nil表示为空）

setrange email 10 ww 10标识从第几位开始替换，后面跟上替换的字符串，ww是两个字母则只替换两个字母，索引从0开始

一次性设置多个或者获取多个值

mset key1 value1 key2 value2 key3 value3

返回旧值并设置新值

对某一个值进行递减或者递增

对某个值进行指定长度的递减和递增

语法：incrby key 步长

字符串追加方法

获取字符串的长度

Redis 的字符串叫着「SDS」，也就是Simple Dynamic String。它的结构是一个带长度信息的字节数组。

struct SDS<T> {
 T capacity; // 数组容量
 T len; // 数组长度
 byte flags; // 特殊标识位，不理睬它
 byte[] content; // 数组内容
 }

如果 capacity 不够容纳追加的内容，就会重新分配字节数组并复制原字符串的内容到新数组中，再 append 新内容

如果字符串的长度非常长，这样的内存分配和复制开销就会非常大。

字符串在长度小于 1M 之前，扩容空间采用加倍策略，也就是保留 100% 的冗余空间。当长度超过 1M 之后，为了避免加倍后的冗余空间过大而导致浪费，每次扩容只会多分配 1M 大小的冗余空间。

存储方式

dict 结构内部包含两个 hashtable，通常情况下只有一个 hashtable 是有值的。但是在 dict 扩容缩容时，需要分配新的 hashtable，然后进行渐进式搬迁，这时候两个 hashtable 存储的分别是旧的 hashtable 和新的 hashtable。待搬迁结束后，旧的 hashtable 被删除，新的 hashtable 取而代之。

为了节约内存空间使用，zset 和 hash 容器对象在元素个数较少的时候，采用压缩列表 (ziplist) 进行存储。

压缩列表是一块连续的内存空间，元素之间紧挨着存储，没有任何冗余空隙。

quicklist 是 ziplist 和 linkedlist 的混合体，它将 linkedlist 按段切分，每一段使用 ziplist 来紧凑存储，多个 ziplist 之间使用双向指针串接起来。

单个 ziplist 长度为 8k 字节，超出了这个字节数，就会新起一个 ziplist。ziplist 的长度由配置参数list-max-ziplist-size决定。

listpack，它是对 ziplist 结构的改进，在存储空间上会更加节省，而且结构上也比 ziplist 要精简。

Rax 是 Redis 内部比较特殊的一个数据结构，它是一个有序字典树 (基数树 Radix Tree)

按照 key 的字典序排列，支持快速地定位、插入和删除操作。

rax 跟 zset 的不同在于它是按照 key 进行排序的。

当我们调用套接字的读写方法，默认它们是阻塞的，比如read方法要传递进去一个参数n，表示最多读取这么多字节后再返回，如果一个字节都没有，那么线程就会卡在那里，直到新的数据到来或者连接关闭了，read方法才可以返回，线程才能继续处理。而write方法一般来说不会阻塞，除非内核为套接字分配的写缓冲区已经满了，write方法就会阻塞，直到缓存区中有空闲空间挪出来了。

非阻塞 IO 在套接字对象上提供了一个选项Non_Blocking，当这个选项打开时，读写方法不会阻塞，而是能读多少读多少，能写多少写多少。能读多少取决于内核为套接字分配的读缓冲区内部的数据字节数，能写多少取决于内核为套接字分配的写缓冲区的空闲空间字节数。读方法和写方法都会通过返回值来告知程序实际读写了多少字节。

解决数据不完整的情况

select函数、epoll(linux)、kqueue(freebsd & macosx)

客户端的指令通过队列来排队进行顺序处理，先到先服务。

snapshotting 默认方式，将内存中以快照的方式写入二进制文件中，默认为dump.rdb。可以通过配置设置自动做快照持久化方式，可以配置redis在n秒内如果超过m个key修改就自动做快照

如果redis意外down就会丢失最后一次快照的所有修改的数据

冷备份

生产环境使用方式

appendonly yes 启用aof持久化的方式

rewrite

AOF备份原理：AOF 日志存储的是 Redis 服务器的顺序指令序列，AOF 日志只记录对内存进行修改的指令记录。Redis 会在收到客户端修改指令后，先进行参数校验，如果没问题，就立即将该指令文本存储到 AOF 日志中，也就是先存到磁盘，然后再执行指令。这样即使遇到突发宕机，已经存储到 AOF 日志的指令进行重放一下就可以恢复到宕机前的状态。

AOF瘦身方案：Redis 提供了 bgrewriteaof 指令用于对 AOF 日志进行瘦身。其原理就是开辟一个子进程对内存进行遍历转换成一系列 Redis 的操作指令，序列化到一个新的 AOF 日志文件中。序列化完毕后再将操作期间发生的增量 AOF 日志追加到这个新的 AOF 日志文件中，追加完毕后就立即替代旧的 AOF 日志文件了，瘦身工作就完成了。

fsync

快照是通过开启子进程的方式进行的，它是一个比较耗资源的操作

（1）如果RDB在执行snapshotting操作，那么redis不会执行AOF rewrite; 如果redis再执行AOF rewrite，那么就不会执行RDB snapshotting

（2）如果RDB在执行snapshotting，此时用户执行BGREWRITEAOF命令，那么等RDB快照生成之后，才会去执行AOF rewrite

（3）同时有RDB snapshot文件和AOF日志文件，那么redis重启的时候，会优先使用AOF进行数据恢复，因为其中的日志更完整

（1）写crontab定时调度脚本去做数据备份

（2）每小时都copy一份rdb的备份，到一个目录中去，仅仅保留最近48小时的备份

（3）每天都保留一份当日的rdb的备份，到一个目录中去，仅仅保留最近1个月的备份

（4）每次copy备份的时候，都把太旧的备份给删了

（5）每天晚上将当前服务器上所有的数据备份，发送一份到远程的云服务上去

如果是redis进程挂掉，那么重启redis进程即可，直接基于AOF日志文件恢复数据,其他选择 相应备份重启即可

AOF没有破损，也是可以直接基于AOF恢复的

AOF append-only，顺序写入，如果AOF文件破损，那么用redis-check-aof fix

appendonly.aof + dump.rdb，优先用appendonly.aof去恢复数据

redis启动的时候，自动重新基于内存的数据，生成了一份最新的rdb快照，

重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。

通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。

Redis 4.0将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小。

于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。

使用操作系统的多进程 COW(Copy On Write) 机制来实现快照持久化

（1）redis采用异步方式复制数据到slave节点，不过redis 2.8开始，slave node会周期性地确认自己每次复制的数据量

（2）一个master node是可以配置多个slave node的

（3）slave node也可以连接其他的slave node

（4）slave node做复制的时候，是不会block master node的正常工作的

（5）slave node在做复制的时候，也不会block对自己的查询操作，它会用旧的数据集来提供服务; 但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了

（6）slave node主要用来进行横向扩容，做读写分离，扩容的slave node可以提高读的吞吐量

如果采用了主从架构，那么建议必须开启master node的持久化！

主从架构的核心原理

主从复制的断点续传

无磁盘化复制

过期key处理

作用

sdown和odown转换机制

哨兵集群的自动发现机制

slave配置的自动纠正

slave->master选举算法

quorum和majority

configuration epoch

configuraiton传播

海量数据+高并发+高可用

（1）客户端执行数据写入操作

（2）redis server接收到写入操作之后，检查maxmemory的限制，如果超过了限制，那么就根据对应的policy清理掉部分数据

（3）写入操作完成执行

（1）noeviction: 如果内存使用达到了maxmemory，client还要继续写入数据，那么就直接报错给客户端

（2）allkeys-lru: 就是我们常说的LRU算法，移除掉最近最少使用的那些keys对应的数据

（3）volatile-lru: 也是采取LRU算法，但是仅仅针对那些设置了指定存活时间（TTL）的key才会清理掉

（4）allkeys-random: 随机选择一些key来删除掉

（5）volatile-random: 随机选择一些设置了TTL的key来删除掉

（6）volatile-ttl: 移除掉部分keys，选择那些TTL时间比较短的keys

（7）volatile-lfu Redis 4.0以上支持

（8）allkeys-lfu Redis 4.0以上支持

Least Recently Used，最近最少使用算法

maxmemory，设置redis用来存放数据的最大的内存大小，一旦超出这个内存大小之后，就会立即使用LRU算法清理掉部分数据

redis的LRU近似算法

Least Frequently Used，表示按最近的访问频率进行淘汰，它比 LRU 更加精准地表示了一个 key 被访问的热度。

如果一个 key 长时间不被访问，只是刚刚偶然被用户访问了一下，那么在使用 LRU 算法下它是不容易被淘汰的，因为 LRU 算法认为当前这个 key 是很热的。而 LFU 是需要追踪最近一段时间的访问频率，如果某个 key 只是偶然被访问一次是不足以变得很热的，它需要在近期一段时间内被访问很多次才有机会被认为很热。

客户端访问这个 key 的时候，redis 对 key 的过期时间进行检查，如果过期了就立即删除

从过期字典中随机 20 个 key；

删除这 20 个 key 中已经过期的 key；

如果过期的 key 比率超过 1/4，那就重复步骤 1；

为了保证过期扫描不会出现循环过度，导致线程卡死现象，算法还增加了扫描时间的上限，默认不会超过 25ms。

从库不会进行过期扫描，从库对过期的处理是被动的

主库在 key 到期时，会在 AOF 文件里增加一条 del 指令，同步到所有的从库，从库通过执行这条 del 指令来删除过期的 key。

客户端进程调用write将消息写到操作系统内核为套接字分配的发送缓冲send buffer。

客户端操作系统内核将发送缓冲的内容发送到网卡，网卡硬件将数据通过「网际路由」送到服务器的网卡。

服务器操作系统内核将网卡的数据放到内核为套接字分配的接收缓冲recv buffer。

服务器进程调用read从接收缓冲中取出消息进行处理。

服务器进程调用write将响应消息写到内核为套接字分配的发送缓冲send buffer。

服务器操作系统内核将发送缓冲的内容发送到网卡，网卡硬件将数据通过「网际路由」送到客户端的网卡。

客户端操作系统内核将网卡的数据放到内核为套接字分配的接收缓冲recv buffer。

客户端进程调用read从接收缓冲中取出消息返回给上层业务逻辑进行处理。

结束。

如果当前 Redis 内存有 10G，当你删除了 1GB 的 key 后，再去观察内存，你会发现内存变化不会太大。原因是操作系统回收内存是以页为单位，如果这个页上只要有一个 key 还在使用，那么它就不能被回收。Redis 虽然删除了 1GB 的 key，但是这些 key 分散到了很多页面中，每个页面都还有其它 key 存在，这就导致了内存不会立即被回收。

Redis 虽然无法保证立即回收已经删除的 key 的内存，但是它会重用那些尚未回收的空闲内存。

Redis 可以使用 jemalloc(facebook) 库来管理内存

rename-command keys abckeysabc

rename-command flushall ""

直接抛出异常，通知用户稍后重试；

sleep 一会再重试；

将请求转移至延时队列，过一会再试；

主节点挂掉时，从节点会取而代之，客户端上却并没有明显感知。

解决方案：使用blpop/brpop 阻塞读在队列没有数据的时候，会立即进入休眠状态，一旦数据到来，则立刻醒过来。消息的延迟几乎为零。

方案问题：如果线程一直阻塞，Redis 的客户端连接就成了闲置连接，闲置过久，服务器一般会主动断开连接，减少闲置资源占用。这个时候blpop/brpop会抛出异常来。

所以编写客户端消费者的时候要小心，注意捕获异常，还要重试。

消息序列化成一个字符串作为 zset 的value，这个消息的到期处理时间作为score，然后用多个线程轮询 zset 获取到期的任务进行处理

Redis 的 zrem 方法是多线程多进程争抢任务的关键，它的返回值决定了当前实例有没有抢到任务，因为 loop 方法可能会被多个线程、多个进程调用，同一个任务可能会被多个进程线程抢到，通过 zrem 来决定唯一的属主。

支持多播的可持久化的消息队列

Stream数据结构.png

[object Object]

Key结构：前缀_年Y-月m_用户类型_用户ID

标准Key：KEYS loginLog_2017-10_client_1001
 检索全部：KEYS loginLog_*
 检索某年某月全部：KEYS loginLog_2017-10_*
 检索单个用户全部：KEYS loginLog_*_client_1001
 检索单个类型全部：KEYS loginLog_*_office_*

设置用户1001，217-10-25登录：SETBIT loginLog_2017-10_client_1001 25 1
 获取用户1001，217-10-25是否登录：GETBIT loginLog_2017-10_client_1001 25
 获取用户1001，217-10月是否登录：BITCOUNT loginLog_2017-10_client_1001
 获取用户1001，217-10/9/7月是否登录：BITOP OR stat loginLog_2017-10_client_1001 loginLog_2017-09_client_1001 loginLog_2017-07_client_1001

每周同步一次数据到数据库，表中一条数据对应一个BitMap，记录一个月数据。每次更新已存在的、插入没有的

pfadd

pfcount

pfmerge

public class JedisTest {
 public static void main(String[] args) {
 Jedis jedis = new Jedis();
 for (int i = 0; i < 100000; i++) {
 jedis.pfadd("codehole", "user" + i);
 }
 long total = jedis.pfcount("codehole");
 System.out.printf("%d %d\n", 100000, total);
 jedis.close();
 }
 }

bf.add 添加一个

bf.exists 查询一个

bf.madd 添加多个

bf.mexists 查询多个

public class BloomTest {
 
 public static void main(String[] args) {
 Client client = new Client();
 
 client.delete("codehole");
 for (int i = 0; i < 100000; i++) {
 client.add("codehole", "user" + i);
 boolean ret = client.exists("codehole", "user" + (i + 1));
 if (ret) {
 System.out.println(i);
 break;
 }
 }
 
 client.close();
 }
 
 }