1：什么是三高，里面的高可用是什么？
高并发：应用要提供某一业务要能支持很多客户端同时访问的能力，我们称为并发，
高性能：性能带给我们最直观的感受就是：速度快，时间短
高可用：
可用性：一年中应用服务正常运行的时间占全年时间的百分比
我们把下图时间加在一起就是全年应用服务不可用的时间：
4小时27分15秒+11分36秒+2分16秒=4小时41分7秒=16867秒
1年=3652460*60=31536000秒
可用性=（31536000-16867）/31536000*100%=99.9465151%
业界可用性目标5个9，即99.999%，即服务器年宕机时长低于315秒，约5.25分钟
2：单机redis的风险与问题
问题1.机器故障
现象：硬盘故障、系统崩溃
本质：数据丢失，很可能对业务造成灾难性打击结论：基本上会放弃使用redis.
问题2.容量瓶颈
现象：内存不足，从16G升级到64G，从64G升级到128G，需要无限升级内存
本质：穷，硬件条件
为了避免单点Redis服务器故障，准备多台服务器，互相连通。
将数据复制多个副本保存在不同的服务器上，连接在一起，并保证数据是同步的。
即使有其中一台服务器宕机，其他服务器依然可以继续提供服务：
实现Redis的高可用，同时实现数据冗余备份。
3：Redis集群方案
提供数据方：master（单个 主服务器，主节点，主库主客户端）
功能：提供给后台执行写操作时，将出现变化的数据自动同步到slave
接收数据方：slave（多个 从服务器，从节点，从库）
功能：提供给后台读数据 禁止后台直接写数据（禁止）
1：读写分离：master写、slave读，提高服务器的读写
2：负载能力负载均衡：
基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数:量；
通过多个从节点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量；
3：故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复
4：数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式
5：高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案
4：主从复制工作
对于集群来说：最重要就是主从同步的过程
主从复制过程大体可以分为3个阶段：
1：建立连接阶段（即准备阶段）
2：数据同步阶段
3：命令传播阶段（反复同步）
5：阶段一：建立连接（主从复制工作）
1：设置master的地址和端口，保存master信息
2：建立socket连接 （传输通道）
3：发送ping命令（定时器任务）步骤
4：身份验证 （如果有密码需要授权访问 不是必有的）
5：发送slave端口信息 （master知道slave是提供了哪个对外端口）
最终状态：
slave：保存master的地址与端口
master：保存slave的端口
slave操作：进行配置或者客户端发送命令操作
master操作：不需要进行任何操作
在slave服务器：
# 推荐 在redis的conf里面配置 配置对应的master 地址 以及 端口号 （需要进行重启）
1：replicaof masterip masterpot （默认是注释的）
同样的可以通过
客户端发送命令启动：replicaof masterip masterpot （可以不进行重启）
启动服务器参数启动：redis-server --replicaof masterip masterport （需要进行重启）
#配置该服务只允许只读
2：replica-read-only yes （默认是 yes）
#推荐 slave配置文件设置连接 master redis的密码 （不一定有第三步）
3：masterauth <master-password>
同样的可以通过
客户端发送命令启动：masterauth password（可以不进行重启）
启动服务器参数启动：redis-server –a password（需要进行重启）
断开连接：在slave上执行 slaveof no one
注意：新版本为 replicaof 旧版本为 slaveof
查询 master服务器 或者 slave服务器 里面的主从配置信息：
输入info命令 可以查看相应信息
6：阶段二：数据同步（主从复制工作）
在slave初次连接master后，复制master中的所有数据到slave
将slave的数据库状态更新成master当前的数据库状态
（ 全量复制）：slave通过master 传输过来的RDB文件完成持久化
同步过程如下：
1：请求同步数据
2：创建RDB同步数据
3：恢复RDB同步数据
4：请求部分同步数据
5：恢复部分同步数据
当前状态：
slave：具有master端全部数据，包含RDB过程接收的数据
master：保存slave当前数据同步的数据
注意：第三点：创建的缓冲区是 AOF的缓冲区
第八点：执行的命令：begrewriteaof 是使用AOF命令恢复数据
第九点和第10点 是以后的事情 这个时候数据同步实际上已经完成了
数据同步阶段master 说明：
1：如果master数据量巨大，避免造成master阻塞，影响业务正常执行
执行bgsave是RDB中非阻塞后台运行的持久化方式 但也是需要消耗资源的。
解决方案：数据同步阶段应避开流量高峰期，
2：复制缓冲区大小设定不合理，会导致数据溢出。
如进行全量复制周期太长，进行部分复制时发现数据已经存在丢失的情况，必须进行第二次全量复制，致使slave陷入死循环状态。
解决方案：master 设置复制缓冲区的 repl-backlog-size 1mb (默认是1mb)
3：master单机内存占用主机内存的比例不应过大，建议使用50%-70%的内存，
留下30%-50%的内存用于执 行bgsave命令和创建复制缓冲区
数据同步阶段slave说明：
1：为避免slave进行全量复制、部分复制时服务器响应阻塞或数据不同步，建议关闭此期间的对外服务
replica-serve-stale-data yes （默认为true）
2：多个slave同时对master请求数据同步，master发送的RDB文件增多，会对带宽造成巨大冲击，
如果master带宽不足，因此数据同步需要根据业务需求，适量错峰。（好处 同时执行时 只有一个RDB）
3：slave过多时，调整拓扑结构，由一主多从结构变为树状结构，中间的节点既是master（同步数据给其他slave），也是 slave。
注意使用树状结构时，由于层级深度，导致深度越高的slave与最顶层master间数据同步延迟 较大，数据一致性变差，应谨慎选择
7：阶段三：命令传播（主从复制工作）
当master数据库状态被修改后，导致主从服务器数据库状态不一致，此时需要让主从数据同步到一致的状态，
同步的动作称为命令传播master将接收到的数据变更命令发送给slave，slave接收命令后执行命令
（部分恢复） ：slave通过master 传输过来的命令 使用AOF的bgrewriteof完成持久化
命令传播阶段的部分复制命令传播阶段出现了断网现象：
网络闪断闪连：忽略
短时间网络中断：部分复制
长时间网络中断：全量复制
主要来看部分复制，部分复制的三个核心要素
1：服务器的运行 id（run id）
2：主服务器的复制缓冲区 （复制积压缓冲区）
3：主从服务器的复制偏移量
服务器的运行 id：
概念：服务器运行ID是每一台服务器每次运行的身份识别码，一台服务器重启异常一个新的运行id
组成：运行id由40位字符组成，是一个随机的十六进制字符
例如：fdc9ff13b9bbaab28db42b3d50f852bb5e3fcdce
实现方式：
运行id在每台服务器启动时自动生成的，master在首次连接slave时，
会将自己的运行ID发送给slave，slave保存此ID，通过info Server命令，可以查看节点的runid
主服务器的复制缓冲区：
数据来源：当master接收到主客户端的指令时，除了将指令执行，会将该指令存储到缓冲区中
概念：复制缓冲区，又名复制积压缓冲区，是一个先进先出（FIFO）的队列，用于存储服务器执行过的命令，
每次传播命令，master都会将传播的命令记录下来，并存储在复制缓冲区
复制缓冲区默认数据存储空间大小是1M
当入队元素的数量大于队列长度时，最先入队的元素会被弹出，而新元素会被放入队列
作用：用于保存master收到的所有指令（仅影响数据变更的指令，例如set，select）
复制缓冲区（偏移量与字节值）内部工作原理
偏移量概念：一个数字，描述复制缓冲区中的指令字节位置
分类：
master复制偏移量：记录发送给所有slave的指令字节对应的位置（多个 分别对应多个slave）
slave复制偏移量：记录slave接收master发送过来的指令字节对应的位置（一个 只对应一个master）
作用：同步信息，比对master与slave的差异，当slave断线后，恢复数据使用
数据来源：
master端：发送一次记录一次
slave端：接收一次记录一次
注意：复制缓冲区 只存在于master端
网友评论