redis

一 . redis 基础数据结构和核心原理

1.redis 五种基础数据结构
string(字符串) list(列表) set(集合) hash (hash) zset(有序集合)

原子计数器(单线程) 可以做分布式锁(incrby xxx谁是1谁获取锁,用完释放 decr XXX)

redis 存储键值对实际使用的是 hashtable的数据结构(和 hashMap存储一样)

二, redis 核心原理

1.客户端连接到redis的server socket 请求建立连接

2.redis的server socket 产生一个AE_READABLE事件

3.redis的IO多路复用程序，将server socket和其产生的事件放入队列

4.redis的文件事件分派器根据server socket和其AE_READABLE事件跟连接应答处理器关联

5.连接应答处理器负责和客户端建立连接，创建客户端对应的socket 01，同时将这个socket 01的AE_READABLE事件和命令请求处理器关联，使得客户端可以向主服务器发送命令请求

6.客户端发送 set key value请求

6.redis的socket 01 产生一个AE_READABLE事件

7.redis的IO多路复用程序，将socket 01和其产生的事件放入队列

8.redis的文件事件分派器根据socket 01和AE_READABLE事件关联的命令请求处理器，分配到命令请求处理器，命令请求处理器从socket 01中读出来key和value 在自己内存中完成key和value的设置

9.redis服务器准备好给客户端的响应数据后，会将socket 01的AE_WRITABLE事件和命令回复处理器关联起来

10.当客户端socket 01准备好读取响应数据时，会在redis的socket 01产生一个AE_WRITABLE事件

11.redis的IO多路复用程序，将socket 01和其产生的事件放入队列

12.redis的文件事件分派器根据socket 01和AE_WRITABLE事件关联的命令回复处理器，分配到命令回复处理器，命令回复处理器对socket 01输出本次操作的一个结果ok

13.redis的socket 01会找到客户端的socket 01，并返回结果ok

14.命令回复处理器将redis的socket 01的AE_WRITABLE事件和命令回复处理器解除关联

RDB 持久化 ,单独fork() 一个子线程 把父线程数据 复制一份,放到文件里,替换上次快照.(恢复的时候没来得及生成快照的数据容易丢失 ) 快照生成条件(默认):6秒10000次, 900秒数据变动一次,300秒 10 次
AOF 持久化 :就是把redis 所有修改的命令保存一份. 恢复的时候一个一个命令执行(命令多的时候,恢复很慢 )
AOF 重写 就是如同一个key 不停的修改肯定会用很多命令(都是重复的).这个重写就是取最后一次一个命令也就是最终值.
重写的条件:,aof 命令大小超过64M ,或者容量翻倍

混合持久化:就是把 RDB+AOF 混合使用,取RDB 快照文件,以及还未生成快照的文件的AOF 命令.一起恢复

二 ,redis 集群

redis 集群最少有3个master 节点,并且每个master 都要有一个从节点.一主一从;
哨兵模式:配置哨兵模式 也是个集群,客户端访问的时候 其实是访问的哨兵集群,哨兵集群再去访问master,只会有一个主从,
问题:支持不了百万级别的并发量(一台机器最多每秒/10W),哨兵服务也会挂掉,如果主节点挂了,主从切换 会很慢.

codis集群架构:搭建多个主从,codis 根据key 去计算 放在哪个主从里

高可用集群:
搭建
三redis 集群原理分析

总结 key 值分配: 槽位 只有 master 有
jedis虚拟分片(槽位定位算法):redis 集群 逻辑上会把内存分为 16384个槽,分配每个小集群(搭建时候可以自己配置,默认是平均分配),存放不同数据;
原理就是把key 进行 hash 算法 然后对16384 去取模,是哪个槽就会分配到哪个集群.(理解成 负载均衡)
跳转重定位:当我们get 某个可以的时候 ,你redis 客户端现在是 8001 ,发现你key 值存储位置在 8002 这台机器上,那么就会帮你定位到 8002 这台机器上
网络抖动: 配置cluster-node-timeout 时间配置,每个主从都是会有心跳联系,当你 的主节点挂了,从节点会重新选举,为了防止网络抖动 会产生不必要的选举,就会配置这个.(防止篡位);

四. 集群扩展

1.扩展
集群最多可以扩展 16384个,官方建议最多1000; 拓展方式具体看redis 命令

2.集群选举
3.主从同步的基本原理

聊了文件存储之后，回到主题上面，Redis的主从模式采用的是RDB文件同步的方式，因为Redis的服务端，数据量有可能非常的大，所以从性能考虑，没有采用AOF快照来同步。

过程大概如下：

从机上线，主动链接主机，发送SYNC命令
主机接到命令后，执行BGSAVE命令，生成RDB文件
主机向从机发送RDB文件，开始同步数据
同步之后，主机将最近的更新，采用命令的形式同步到从机上面。

旧版复制的缺陷

上述的过程对于一个从机，新加入到集群里面的时候，比较合适，但是如果因为断线重连，则需要重新复制主机上所有的内容，主机也因此要进行一次全量级的RDB，比较耗费性能。

在2.8版本之后，采用了一个新的增量复制的过程，流程如下：

前面的sync的过程还是一样，没有差异
当从机断线重连之后，会发送PSYNC,要求增量同步，并包括一个offset
主机根据offset的位置，对之后的数据进行一次增量同步，到从机上面

这里面的offset是由主机和从机共同维护的，相当于一个乐观锁，描述了两方的版本差异。

那决定能否增量同步的主要因素，包括如下三个：

是否具备偏移量，与主机进行对比
主服务器的复制积压缓冲区（Replication backlog）
从服务器的ID

第一条不难理解，重点解释一下第二和第三条
复制积压缓冲区

Redis每分钟都会处理很多的数据，不可能一直把更新的操作存起来，等待从机上线在传输，AOF也不是都在内存中一直保存，所以Redis有一个缓冲区，采用队列的模式来存储这些写操作。

所有的更新操作以队列的形式放入里面，内存大小默认是1MB，超过1MB之后，前面进入队列的写操作就会被移除。

所以当从机上线之后，如果offset与主机版本差距的内容还在缓冲区内，则可以从缓冲区进行增量同步。否则依然还是全量同步（RDB），这里就好比你的机器宕机了一天，在上线，你不能要求我把这一天的数据都给你吧，你直接全量同步得了。

这里我就想到了一个问题，如果我们反复对Redis更新特别大的K-V的话，超过1M，会使得这个缓冲区失效，因为每次的更新都超过这个缓冲区大小了，所以同步操作对于从机来说，都是全量同步，如果太频繁的话，则会产生很大的问题。

当然这个缓冲区的大小也是可以设置调整的饿，可以根据需求配置。
从服务器ID

这个不难理解，因为Redis有一个Slot的概念，每个机器负责一部分的Key，所以如果你之前不是我的从机，那你内存内的数据肯定都不是我的值，就不能只看offset了，还要看一下你之前是不是我的从机，这里主机会维护从机的唯一ID，来校验。
整个复制流程

1. 设置端口号进行连接

SLAVEOF master_ip master_port 命令，或者通过配置文件配置均可。
2. 建立套接字连接

建立连接之后，从服务器会负责处理后续的RDB文件和写命令，主服务器将从服务器作为一个客户端进行响应
3. 发送PING请求

连接之后，通过PING请求检查相互的状态，类似心跳校测的内容。
4. 身份验证

这里需要主服务器和从服务器都设置校验选项，然后校验密码。

如果两方都没有设置，则这一步可以忽略
如果从服务器设置了，主服务没有设置，则会返回 no password is set
如果都设置了，则会进行验证
如果主服务器设置了，但是从服务器没有设置，则会返回NOAUTH

5. 发送端口

由于从服务类似于客户端，等待接受信息，所以需要告知主服务器自己接受所用的端口号，方便未来接受RDB和写命令。
6. 同步

这个时候就进入到我们上面描述的同步机制里面了，SYNC or PSYNC 等等的内容。
7. 命令传播

后续的写命令，都会通过上面配置的端口号不停传输。
其他内容
心跳检测

进行了套接字连接，执行过PING命令之后，虽然保证了连接，但是后续的写同步操作，依然需要实时连接。所以从服务器会定期发送自己的offset到主服务器上，检测是否需要同步写操作。
检测从服务状态

主服务器在一个时间周期内没有收到从服务器上述的心跳检测内容，则察觉从服务器可能异常了，所以这个时候会需要查看从服务器的信息。

Redis会配置一些拒绝写操作的内容，在一些特定情况下会认为写操作不安全，这里的不安全是通过配置决定的：

min-slaves-to-write 3
min-slaves-max-lag 10

以上的信息表示从节点不能少于3个，或者3个从服务延迟不能超过10秒。否则拒绝写操作，只执行读操作。
命令丢失

由于定期的心跳检测的存在，所以定期检测版本，发现消息丢失这种内容就自动实现了，可以通过offset准确的了解到从服务器哪些信息没有接受到，及时的作出响应。