t型布局网站实例,wordpress主题 翠竹林,wordpress在本地搭建,做网站赚什么钱目录
编辑一、构建主从架构
1、集群结构
2、准备实例和配置
#xff08;1#xff09;创建目录
#xff08;2#xff09;修改原始配置
#xff08;3#xff09;拷贝配置文件到每个实例目录
#xff08;4#xff09;修改每个实例的端口#xff0c;工作目录
1创建目录
2修改原始配置
3拷贝配置文件到每个实例目录
4修改每个实例的端口工作目录
5修改每个实例的声明 IP
3、启动
4、开启主从关系
二、数据同步原理
1、全量同步
2、增量同步 3、主从同步的优化 一、构建主从架构
1、集群结构
单节点Redis的并发能力是有上限的要进一步提高Redis的并发能力就需要搭建主从集群实现读写分离。 为什么 Redis 要做成主从集群而不是传统的负载型集群呢
这是因为 Redis 应用当中大多数都是 读多写少 正因如此更多的是面对 读 的压力搭建主从集群可以实现读写分离多个从节点共同承担 读 的请求使 读 的并发能力大幅度提升
但是主从集群必须得保证客户端不管是读的哪个从节点都必须拿到的是相同的结果那么如何保证呢
就需要 master 把它上面的数据同步给每一个 slave / replica 节点
共包含三个节点一个主节点俩个从节点
这里我在同一台服务器中开启 3 个 redis 实例搭建主从集群信息如下 2、准备实例和配置
要在一台虚拟机开启 3 个实例必须准备三份不同的配置文件和目录配置文件所在目录也就是工作目录
1创建目录
我们创建 3 个文件夹名字分别叫700170027003
# 进入到 tmp 目录
cd tmp# 创建 7001,7002,7003
mkdir 7001 7002 7003
2修改原始配置
修改 redis.conf 文件将其中持久化模式改为默认的 RDB 模式AOF 保持关闭 3拷贝配置文件到每个实例目录 然后将 redis.conf 文件拷贝到三个目录中在 /tmp 目录下执行下列命令
# 第一种逐个拷贝
cp /usr/redis/redis.conf 7001
cp /usr/redis/redis.conf 7002
cp /usr/redis/redis.conf 7003# 第二种一键拷贝
echo 7001 7002 7003 | xargs -t -n 1 cp /usr/redis/redis.conf
4修改每个实例的端口工作目录
修改每个文件夹内的配置文件将端口分别改为 700170027003将 RDB 文件保存位置都改成自己所在的目录这里的 7000 对应的是 redis 的端口我之前修改过
sed -i -e s/7000/7001/g -e s/dir .\//dir \/tmp\/7001\//g 7001/redis.conf
sed -i -e s/7000/7002/g -e s/dir .\//dir \/tmp\/7002\//g 7002/redis.conf
sed -i -e s/7000/7003/g -e s/dir .\//dir \/tmp\/7003\//g 7003/redis.conf
5修改每个实例的声明 IP
虚拟机本身有多个 IP为了避免混乱我们将 redis.conf 文件中指定每一个实例的绑定 ip 信息
# redis 实例的声明 IP
replica-announce-ip 111.229.153.16
每个目录都要改我们一键完成修改
sed -i la replica-announce-ip 111.229.153.16 7001/redis.conf
sed -i la replica-announce-ip 111.229.153.16 7002/redis.conf
sed -i la replica-announce-ip 111.229.153.16 7003/redis.conf 3、启动
为了方便查看日志我们打开三个窗口分别启动 3 个 redis 实例启动命令
./redis-server /usr/tmp/7001/redis.conf./redis-server /usr/tmp/7002/redis.conf./redis-server /usr/tmp/7003/redis.conf4、开启主从关系
现在这三个实例还没有任何的关系要配置主从可以使用 replicaof 或者 slaveof(5.0之前)命令
一共有两种模式
永久模式
修改配置文件在 redis.conf 中添加一行配置 slaveof masterip masterport
临时模式重启后失效
使用 redis-cli 客户端连接到 redis 服务执行命令slaveof masterip masterport 意义让 7002 成为 7001 的从节点
我们可以通过 info replication 来查看集群状态信息 二、数据同步原理
1、全量同步
主从第一次同步是全量同步 slave 在和 master 第一次建立连接的时候需要执行 replicaof 命令然后 slave 就可以向 master 发起请求了与此同时master 会判断是否是第一次同步如果是第一次就会返回 master 的版本信息
然后 master 执行 bgsave 生成 RDBRDB 里面记录了完整的内存信息master 将这个 RDB 发送给 slaveslave 清空本地数据并加载 RDB 文件这样就能确保 slave 与 master 的数据基本一致
为什么说是 slave 和 master 的数据基本一致而不是完全一致呢
这是因为 bgsave 是异步执行的在执行 bgsave 的时候主进程还会去处理用户的请求也就是说会有新数据的写入而新数据是并没有同步给 slave 的
此时主进程除了处理新的命令以外还会把这些 RDB 期间的命令记录在 repl_baklog 缓冲区中
repl_baklog RDB 里面的数据加载一起就是 master 的数据
随后master 将 repl_baklog 中的命令发送给 slave
这个过程为什么叫全量同步呢
因为这里面有一个 RDB 的过程会把内存形成快照整体发送给 slave 所以叫全量同步但是这种同步实际上是比较消耗性能的因为生成 RDB 文件的速度是比较慢的所以只有在第一次建立连接的时候才会进行全量同步
那么 master 如何判断 slave 是不是第一次进行同步数据呢
先来了解几个概念 Replication Id简称replid是数据集的标记id一致则说明是同一数据集。每一个master都有唯一的replidslave则会继承master节点的 replid offset偏移量随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset说明slave数据落后于master需要更新。 由此可以根据 replid 来判断是否是第一次同步replid 只要不一致就是第一次同步
完整 2、增量同步
slave重启后同步则执行增量同步 offset 是记录在了 repl_baklog 的哪个部分呢如何找到之后的那些命令呢
repl_baklog 本质是一个数组而这个数组比较特殊它的大小是固定的但是当数组内数据记满了之后还会接着记录数据会从 0 开始将原来的数据进行覆盖形成了一种环形的记录方式 要同步的内容就是从 slave 的 offset 到 master 的 offset 之间的这部分数据
只要 slave 和 master 的存储差距不超过这个环的上限那么永远可以从这个环里面找到所需要的数据就可以进行增量同步
那么什么情况下会出现无法进行增量同步呢
假设 slave 出现了宕机它宕机之后我们的 master 还在持续的做数据的记录此时因为 slave 宕机了就无法进行数据同步因此欠的债就越来越多所需要同步的数据也就越来越多逐渐的挤满了整个数组
当所需要同步的数据达到一定数量的时候master 新记录的数据就会将 slave 的 offset 覆盖掉那么此时我们的 slave 恢复运行之后就无法进行增量同步也就只能进行全量同步了
也就是说 repl_baklog 大小有限写满后会覆盖最早的数据如果 slave 断开时间过久导致尚未备份的数据被覆盖则无法基于 log 做增量同步只能再次全量同步 3、主从同步的优化
我们可以从下面几个方面来对 Redis 主从就集群进行优化
提高全量同步的性能
1、在master中配置repl-diskless-sync yes启用无磁盘复制避免全量同步时的磁盘IO。
2、Redis单节点上的内存占用不要太大减少RDB导致的过多磁盘IO
减少全量同步
3、适当提高repl_baklog的大小发现slave宕机时尽快实现故障恢复尽可能避免全量同步
4、限制一个master上的slave节点数量如果实在是太多slave则可以采用主-从-从链式结构减少master压力
