一 . redis 基础数据结构和核心原理
1.redis 五种基础数据结构
string(字符串) list(列表) set(集合) hash (hash) zset(有序集合)
原子计数器(单线程) 可以做分布式锁(incrby xxx谁是1谁获取锁,用完释放 decr XXX)
![在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/88daa0a03c2a8e0651921da4c322a61a.png)
![**scan 渐进性遍历**](https://i-blog.csdnimg.cn/blog_migrate/d276bd135db8925b946f07139ff94811.png)
redis 存储键值对实际使用的是 hashtable的数据结构(和 hashMap存储一样)
![在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/380f932770d92bd5ab98fb175cee3d65.png)
二, 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 去计算 放在哪个主从里
![在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/403831d9e45d49a706e4e8560bb8766a.png)
高可用集群:
搭建
![在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/d66e3ab5a0bca5bfec381a96edb08a39.png)
三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,来校验。
整个复制流程
- 设置端口号进行连接
SLAVEOF master_ip master_port 命令,或者通过配置文件配置均可。
2. 建立套接字连接
建立连接之后,从服务器会负责处理后续的RDB文件和写命令,主服务器将从服务器作为一个客户端进行响应
3. 发送PING请求
连接之后,通过PING请求检查相互的状态,类似心跳校测的内容。
4. 身份验证
这里需要主服务器和从服务器都设置校验选项,然后校验密码。
如果两方都没有设置,则这一步可以忽略
如果从服务器设置了,主服务没有设置,则会返回 no password is set
如果都设置了,则会进行验证
如果主服务器设置了,但是从服务器没有设置,则会返回NOAUTH
- 发送端口
由于从服务类似于客户端,等待接受信息,所以需要告知主服务器自己接受所用的端口号,方便未来接受RDB和写命令。
6. 同步
这个时候就进入到我们上面描述的同步机制里面了,SYNC or PSYNC 等等的内容。
7. 命令传播
后续的写命令,都会通过上面配置的端口号不停传输。
其他内容
心跳检测
进行了套接字连接,执行过PING命令之后,虽然保证了连接,但是后续的写同步操作,依然需要实时连接。所以从服务器会定期发送自己的offset到主服务器上,检测是否需要同步写操作。
检测从服务状态
主服务器在一个时间周期内没有收到从服务器上述的心跳检测内容,则察觉从服务器可能异常了,所以这个时候会需要查看从服务器的信息。
Redis会配置一些拒绝写操作的内容,在一些特定情况下会认为写操作不安全,这里的不安全是通过配置决定的:
min-slaves-to-write 3
min-slaves-max-lag 10
以上的信息表示从节点不能少于3个,或者3个从服务延迟不能超过10秒。否则拒绝写操作,只执行读操作。
命令丢失
由于定期的心跳检测的存在,所以定期检测版本,发现消息丢失这种内容就自动实现了,可以通过offset准确的了解到从服务器哪些信息没有接受到,及时的作出响应。