Redis

save命令

bgsave命令

配置文件配置（save m n ）

主从复制场景

执行shutdown命令之后执行

1、Redis父进程首先判断：当前是否在执行save，或bgsave的子进程，如果在执行则bgsave命令直接返回。

2、父进程执行fork操作创建子进程，这个过程中父进程是阻塞的，Redis不能执行来自客户端的任何命令

3、父进程fork后，bgsave命令返回”Background saving started”信息并不再阻塞父进程，并可以响应其他命令

4、子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换

5、子进程发送信号给父进程表示完成，父进程更新统计信息

说明

具体步骤

说明

AOF缓存区的同步文件策略由参数appendfsync控制

说明

触发条件

流程

文件校验

伪客户端

1、使用AOF Redis会更具有可持久性(durable)：你可以有很多不同的fsync策略：没有fsync，每秒fsync，每次请求时fsync。使用默认的每秒fsync策略，写性能也仍然很不错(fsync是由后台线程完成的，主线程继续努力地执行写请求)，即便你也就仅仅只损失一秒钟的写数据。

2、AOF日志是一个追加文件，所以不需要定位，在断电时也没有损坏问题。即使由于某种原因文件末尾是一个写到一半的命令(磁盘满或者其他原因),redis-check-aof工具也可以很轻易的修复。

3、当AOF文件变得很大时，Redis会自动在后台进行重写。重写是绝对安全的，因为Redis继续往旧的文件中追加，使用创建当前数据集所需的最小操作集合来创建一个全新的文件，一旦第二个文件创建完毕，Redis就会切换这两个文件，并开始往新文件追加。

4、AOF文件里面包含一个接一个的操作，以易于理解和解析的格式存储。你也可以轻易的导出一个AOF文件。例如，即使你不小心错误地使用FLUSHALL命令清空一切，如果此时并没有执行重写，你仍然可以保存你的数据集，你只要停止服务器，删除最后一条命令，然后重启Redis就可以。

1、对同样的数据集，AOF文件通常要大于等价的RDB文件。

2、AOF可能比RDB慢，这取决于准确的fsync策略。通常fsync设置为每秒一次的话性能仍然很高，如果关闭fsync，即使在很高的负载下也和RDB一样的快。不过，即使在很大的写负载情况下，RDB还是能提供能好的最大延迟保证。

3、在过去，我们经历了一些针对特殊命令(例如，像BRPOPLPUSH这样的阻塞命令)的罕见bug，导致在数据加载时无法恢复到保存时的样子。这些bug很罕见，我们也在测试套件中进行了测试，自动随机创造复杂的数据集，然后加载它们以检查一切是否正常，但是，这类bug几乎不可能出现在RDB持久化中。为了说得更清楚一点：Redis AOF是通过递增地更新一个已经存在的状态，像MySQL或者MongoDB一样，而RDB快照是一次又一次地从头开始创造一切，概念上更健壮。但是，1)要注意Redis每次重写AOF时都是以当前数据集中的真实数据从头开始，相对于一直追加的AOF文件(或者一次重写读取老的AOF文件而不是读内存中的数据)对bug的免疫力更强。2)我们还没有收到一份用户在真实世界中检测到崩溃的报告。

master：完全关闭持久化（包括RDB和AOF），这样可以让master的性能达到最好

slave：关闭RDB，开启AOF（如果对数据安全要求不高，开启RDB关闭AOF也可以），并定时对持久化文件进行备份（如备份到其他文件夹，并标记好备份的时间）；然后关闭AOF的自动重写，然后添加定时任务，在每天Redis闲时（如凌晨12点）调用bgrewriteaof。

总结

格式：psync{runId}{offset}

runId：从节点所复制主节点的运行 id

offset：当前从节点已复制的数据偏移量

主节点复制积压缓冲区：

执行流程

1、slave发送psync，由于是第一次复制，不知道master的runid，自然也不知道offset，所以发送psync ？ -1

2、master收到请求，发送master的runid和offset给从节点。

3、从节点slave保存master的信息

4、主节点bgsave保存rdb文件

5、RDB文件生成完毕之后，主节点会将RDB发送给slave。

并且在④和⑤的这个过程中产生的数据，会写到复制缓冲区repl_back_buffer之中去。

6、从节点收到 RDB 文件并加载到内存中

7、主节点在从节点接受数据的期间，将新数据保存到“复制客户端缓冲区”，当从节点加载 RDB 完毕，再发送过去。
（如果从节点花费时间过长，将导致缓冲区溢出，最后全量同步失败）

8、从节点清空数据后加载 RDB 文件，如果 RDB 文件很大，这一步操作仍然耗时，如果此时客户端访问，将导致数据不一致，可以使用配置slave-server-stale-data 关闭.

9、从节点成功加载完 RBD 后，如果开启了 AOF，会立刻做 bgrewriteaof。

1、如过 RDB 文件大于 6GB，并且是千兆网卡，Redis 的默认超时机制（60 秒），会导致全量复制失败。可以通过调大 repl-timeout 参数来解决此问题。

2、Redis 虽然支持无盘复制，即直接通过网络发送给从节点，但功能不是很完善，生产环境慎用。

1、当从节点出现网络中断，超过了 repl-timeout 时间，主节点就会中断复制连接。

2、主节点会将请求的数据写入到“复制积压缓冲区”，默认 1MB。

3、当从节点恢复，重新连接上主节点，从节点会将 offset 和主节点 id 发送到主节点。

4、主节点校验后，如果偏移量的数后的数据在缓冲区中，就发送 cuntinue 响应 —— 表示可以进行部分复制。

5、主节点将缓冲区的数据发送到从节点，保证主从复制进行正常状态。

1、复制偏移量

2、复制积压缓冲区

3、服务器运行ID

可顺序访问

键值与业务相关

顺序分区的数据量不可确定性导致倾斜

不支持批量操作

数据分散度高

如果要增加分区，数据迁移量在80%左右

数据迁移第一次是无法从数据中取到的，数据库需要进行回写到新节点

迁移数量和添加节点数量有关：建议翻倍扩容

键值与业务无关

可顺序访问

客户端分片：哈希+顺时针（优化取余）

节点伸缩：只影响邻近节点，但是还是有数据迁移

翻倍伸缩：保证最小迁移数据和负载均衡

比较适合节点多的情况

预设虚拟槽：每个槽映射一个数据子集，一般比节点数大

良好的哈希函数：例如CRC16

服务端管理节点、槽、数据：例如Redis Cluster

共享消息模式

采用了异步复制机制，向某个节点写入数据时，无需等待其它节点的写数据响应。

无中心代理节点，而是将客户端直接重定向到拥有数据的节点。

对于N个 Master 节点的 Cluster ，整体性能理论上相当于单个 Redis 的性能的N倍。

采用了主从复制的机制，Master 节点失效时 Slave 节点自动提升为 Master 节点。如果 Cluster 中有N个 Master 节点，每个 Master 拥有1个 Slave 节点，那么这个 Cluster 的失效概率为 1/(2*N-1)，可用概率为 1-1/(2*N-1)。

可支持多达1000个服务节点。随时可以向 Cluster 中添加新节点，或者删除现有节点。Cluster 中每个节点都与其它节点建立了相互连接。

结构图

键(keys)空间有 16384 个 slots。理论上 Redis Cluster 可以支持 16384 个 Master 节点，但是推荐的节点数量最多为 1000 个 Master 。每个 Master 节点处理这些 slots 中的一部分。如果没有 Cluster 的重新配置，那么 Cluster 中的 slots 的分配是稳定的。在稳定状态下，每个 slot 被分配到唯一一个 Master 节点上，这个 Master 节点可以有一个或多个 Slave 节点，从而同样保证了高可用。
据此，对于任意一个指定的键，可以知道这个键存储在哪个 slot 中，从而进一步可以知道在哪个 Master 中。

Redis Cluster 能够在人工组建了一个初始网络后，最终能够自动完成全网连接拓扑的建立。

Redis Cluster 能够阻止一个 Cluster 的节点在改变IP和端口后错误的混入其它 Cluster。

概述

降低重定向思路

结构图

概述

新增节点

删除节点

概述

结构图

概述

解决方案

每个做主观下线的Sentinel节点向其他Sentinel节点发送命令，要求将它设置为领导者。

收到命令的Sentinel节点如果没有同意通过其他Sentinel节点发送的命令，那么将同意该请求，否则拒绝

如果该Sentinel节点发现自己的票数已经超过Sentinel集合半数且超过quorum，那么它将成为领导者。

如果此过程有多个Sentinel节点成为了领导者，那么将等待一段时间重新进行选举。

1.从slave节点中选出一个“合适的"节点作为新的master节点

2.对上面的slave节点执行slaveof no one命令让其成为master节点。

3.向剩余的slave节点发送命令，让它们成为新master节点的slave节点，复制规则和parallel-syncs参数有关。

4.更新对原来master节点配置为slave，并保持着对其“关注"，当其恢复后命令它去复制新的master节点。

最大内存和淘汰策略

超时剔除和主动更新结合，最大内存和淘汰策略兜底。

这种解决方案思路比较简单，就是只让一个线程构建缓存，其他线程等待构建缓存的线程执行完，重新从缓存获取数据就可以了
 如果是单机，可以用synchronized或者lock来处理，如果是分布式环境可以用分布式锁就可以了（分布式锁，可以用memcache的add, redis的setnx, zookeeper的添加节点操作）。

在value内部设置1个超时值(timeout1), timeout1比实际的redis timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候，马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中

子主题

从redis上看，确实没有设置过期时间，这就保证了，不会出现热点key过期问题，也就是“物理”不过期。

从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期

流程图

代码

该方法类似于方法一：使用countDownLatch和atomicInteger.compareAndSet()方法实现轻量级锁