哪里有做家教网站的,做暧暧视频网站安全吗,东莞网站推广公司,容桂网站制作效率好Redis主从、哨兵、Redis Cluster集群架构
Redis主从架构 Redis主从架构搭建
主从搭建的问题 如果同步数据失败#xff0c;查看log日志报错无法连接#xff0c;检查是否端口未开放出现”Error reply to PING from master:...“日志#xff0c;修改参数protected-mode no
…Redis主从、哨兵、Redis Cluster集群架构
Redis主从架构 Redis主从架构搭建
主从搭建的问题 如果同步数据失败查看log日志报错无法连接检查是否端口未开放出现”Error reply to PING from master:...“日志修改参数protected-mode no
Redis主从复制原理 详细流程 如果你为master配置了一个slave不管这个slave是否是第一次连接上master它都会发送一个psync指令给master请求复制数据master收到psync指令之后会在后台进行数据持久化通过bgsave生成最新的rdb文件持久化期间master会继续接收客户端的请求它会把这些可能修改数据集的请求缓存在内存中当持久化完毕之后master会把这份rdb文件数据集发送给slaveslave会把接收到的数据进行持久化生成rdb然后再加载到内存中然后master再将之前缓存在内存中的命令发送给slave当master与slave之间的连接由于某些原因而断开的时候slave能够自动重连master如果master收到了多个slave并发连接请求它只会进行一次持久化而不是一个连接一次然后再把一份持久化的数据发送给多个并发连接的slave 简概 从节点每次都会向主节点发送psync同步指令如果是首次连接主节点会开启bgsave子线程进行全量数据复制并且生成rdb文件并且在持久化期间会将从节点新的写命令缓存下来当持久化结束后主节点将rdb文件同步给从节点进行持久化如果同步期间存在网络波动从节点会进行重连恢复连接后主节点会将部分缺失的数据同步给从节点
数据部分复制(断点续传) 当master和slave断开重连后一般都会对整份数据进行复制。但从Redis 2.8之后Redis开始改用支持部分数据复制的命令psync去master同步数据slave和master能够在网络连接断开重连之后只进行部分数据复制(断点续传)master会在其内存中创建一个复制数据用的缓存队列缓存最近一段时间的数据master和它所有的slave都维护了复制的数据下标offset和master的进程id因此当网络连接断开后slave会请求master继续进行未完成的复制从所记录的数据下标开始。如果master进程id变化了或者从节点数据下标offset太旧已经不在master的缓存队列里了那么将会进行一次全量数据的复杂
主从复制风暴 如果有很多从节点为了缓解主从复制风暴(多个节点同时复制主节点导致主节点压力过大)我们可以让部分从节点与从节点(与主节点同步)同步数据也就是分层结构
Redis哨兵架构 哨兵模式
主从复制存在不能自动故障转移、达不到高可用的功能哨兵模式解决了这些问题通过哨兵机制可以自动切换主从节点客户端连接Redis的时候先连接哨兵哨兵会告诉客户端Redis主节点的地址然后客户端连接上Redis进行后续的操作当主节点宕机的时候哨兵监测到主节点宕机会重新推选出过半选举后的从节点作为新的主节点然后通过发布订阅模式通知其他从节点让它们切换主机哨兵是特殊的Redis服务不提供读写服务主要是用来监控Redis实例节点
哨兵集群选举流程 每个sentinel每秒钟向master节点进行ping当master回复时间超过指定值会被标记为主观下线如果master节点被标记为主观下线那么正在监视这个master节点的所有sentinel都会ping去确认是否真的主观下线当有足够数量的sentinel确认master节点主观下线那么master会被标记为客观下线反之解除标记 每个发现master节点进入客观下线的sentinel都会要求其他sentinel将自己设置为局部leader选举是先到先得的同时每个sentinel每次选举都会自增epoch而每个纪元只会选择出一个sentinel作为局部leader如果所有超过一半的sentinel选举某个sentinel作为局部leader之后这个sentinel会进行故障转移从存活的slave节点中选举出新的master节点这个选举过程跟集群的master选举很类似的 如果哨兵集群只有一个sentinel节点Redis的主从节点也能正常运行以及选举master如果master挂了那唯一的sentinel节点就是局部leader 注意情况 哨兵集群虽然也是可以选举leader但是哨兵架构配置复杂只会提供一个master节点进行对外服务还是不能解决线上并发问题而且哨兵模式还会出现访问瞬断问题基于以上情况我们可以选择Redis集群架构集群架构也能进行选举而且是配置多主多从的配置简单性能上远远高于哨兵模式
Redis Cluster集群架构
哨兵模式的缺陷
在Redis 3以前的版本要实现集群一般是借助哨兵SentInel工具来监控master节点的状态如果master节点异常就会做主从切换将某一台slave作为master哨兵的配置略微复杂并且性能和高可用等各方面表现一般特别是在主从切换的瞬间存在访问瞬断的情况而且哨兵模式只有一个主节点对外提供服务没法支持很高的并发并且单个主节点内存页不适合设置得过大否则会导致持久化文件过大影响数据恢复或主从同步的效率 Sentinel模式的主从切换出现访问瞬断的问题该怎么解决呢? 集群架构已经包括了Sentinel模式
Redis Cluster集群模式 Redis集群是一个由多个主从节点群组成的分布式服务器群它具有复制、高可用和分片特性Redis集群不需要Sentinel哨兵也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式这种集群模式没有中心节点可水平扩展据官方文档称可以线性扩展到上万个节点官方推荐不超过1k节点)Redis集群的性能和高可用性均优于之前版本的哨兵模式并且集群配置非常简单
Redis集群原理分析
Redis Cluster将所有数据划分为16384个slots(Redis集群没有使用一致性hash)每个节点负责其中一部分slotsslots的信息存储于每个节点中 槽位定位算法 Redis集群默认会对key值使用CRC16算法进行hash得到一个整数值然后用这个整数值对16384进行取模来得到具体槽位HASH_SLOT CRC16(key) mod 16384 当Redis Cluster的客户端来连接集群时它也会得到一份集群的slots配置信息并且将其缓存在客户端本地这样当客户端要查找某个key的时候可以直接定位到目标节点同时因为slots的信息可能会存在客户端与服务器不一致的问题还需要纠正机制来实现槽位信息的校验调整 跳转重定位 当客户端向一个错误的节点发出了指令该节点会发现指令的key所在的槽位并不归自己管理这时它会向客户端发送一个特殊的跳转指令携带目标操作的节点地址告诉客户端去连这个节点去获取数据客户端收到指令后除了跳转到正确的节点上去操作还会同步更新纠正本地的槽位映射表缓存后续所有key将使用新的槽位映射表
Redis集群节点间的通信机制 集中式(如zookeeper) 优点在于元数据的更新和读取时效性非常好一旦数据出现变更立即就会更新到集中式的存储中吗其他节点读取的时候立即就能感知到不足在于所有的元数据的更新压力全部集中在一个地方可能导致元数据的存储压力很多中间件都会借助zookeeper集中式存储数据 gossip协议(默认) ping节点之间互相发送ping交换元数据信息pong对ping和meet消息的返回包含自己的状态和其他信息也可以用于信息广播和更新meet 某个节点发送meet给新加入的节点让新节点加入集群中然后新节点就会开始与其他节点进行通信fail某个节点判断另一个节点fail之后就发送fail给其他节点通知其他节点指定的节点宕机了 gossip协议优缺点 优点元数据的更新比较分散不是集中在一个地方更新请求会陆陆续续打到所有节点上去更新有一定的延时降低了压力缺点元数据更新有延时可能导致集群的一些操作会有一些滞后 网络抖动 问题: 假如不同的机房网络不太好的情况下突然节点之间访问延迟不了的情况(过几秒又连接上了)为了避免因为这种场景而导致Cluster频繁切换(数据的重新赋值)造成性能消耗该如何解决 Redis Cluster提供cluster-node-timeout表示如果超过这个时间则认定节点出现故障需要切换
Redis集群选举原理 当slave发现自己的master变为FAIL状态时便会尝试进行Failover以期待成为新的master由于挂掉的master可能会有多个slave从而存在多个slave竞争成master节点的过程 slave发现自己的master变为FAIL将自己记录的集群currentEpoch加1并广播FAILOVER_AUTH_REQUEST信息其他节点收到该信息(只有master响应)判断请求者的合法性并发送FAILOVER_AUTH_ACK对每一个epoch只发送一次ack尝试failover的slave收集master返回的FAILOVER_AUTH_ACKslave收到超过半数master的ack后变为新master(这里解释了集群为什么至少需要三个主节点如果只有两个当其中一个节点挂了只剩一个主节点是不能选举成功的)slave广播pong消息通知其他集群节点 问题: 如果重新选举时出现同一时刻多个slave发送请求给master节点进行选举可能会出现选举失败而且还可能会多次失败如果避免此问题 延迟每个节点发送重新选举的时间: DELAY 500ms random(0 ~ 500ms) SLAVE_RANK * 1000ms SLAVE_RANK 表示slave已经从master复制数据的总量的rankrank越小代表已经复制的数据越新(理论上持有最新数据的slave将会首先发起选举)
Redis集群脑裂数据丢失问题 Redis集群没有过半机制会有脑裂问题 网络分区导致脑裂后出现多个主节点对外提供写服务一旦网络恢复会将其中一个主节点变成从节点(因为从节点初始化或启动时会删除本地的所有数据然后再从主节点同步数据)这时会有大量数据丢失 解决方案: min-replicas-to-write 1 写数据成功的前提是最少同步的slave节点数这种机制类似zookeeper的zab机制比如集群共三个加上master就是2个节点超过半数 注意:脑裂问题的解决方案有个弊端如果需要至少一个slave节点同步数据成功才算成功的话就可能引发另一个问题Redis本就是AP机制(可以看CAP机制)如果改变这样的机制使其成为CP机制一旦slave节点写入失败就会造成Redis返回失败就牺牲了可用性这样就违背了Redis的初衷 CAP含义 C表示一致性访问所有的节点得到的数据应该是一样的A表示可用性所有的节点都保持高可用性P表示分区容错性这里的分区是指网络意义上的分区由于网络是不可靠的所有节点之间很可能出现无法通讯的情况在节点不能通信时要保证系统可以继续正常服务 分析: Redis和Zookeeper的脑裂问题以及解决方案都很类似都是需要半数或半数以上数据同步成功才能避免脑裂问题 集群是否只有在完整的情况才能对外提供服务 当Redis的配置文件中cluster-require-full-coverage no时表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时集群仍然可用如果为yes则集群不可用。 问题: Redis集群为什么至少需要三个master节点并且推荐节点数为奇数 因为新master的选举需要大于半数的集群master节点同意才能选举成功如果只有两个master节点其中一个挂了是达不到选举新的master的条件的 3个master节点和4个master节点的场景 奇数master节点可以在满足选举该条件的基础上节省一个节点 3个或者4个master节点如果挂了一个节点是可以重新选举新的master节点3个或4个master节点如果挂了两个节点就都无法选举出新的master节点了(无法满足半数以及以上) 所以奇数的master节点更多的是从节省机器资源角度出发的 Redis集群对大批量操作命令的支持 Redis集群支持将key落到同一个slots中 解决方案: 数据分片时hash计算的只会是大括号里的值确保不同的key落到同一个slots中 例子 **mset {user1}:1:name linc {user1}:1:age 18 ** Redis集群架构下的数据倾斜问题如何解决 使用本地缓存 使用分片算法的特性对key进行打散处理 big key形成集群数据倾斜对big key进行拆分
总结 问题: Redis的主从复制原理 从节点每次都会向主节点发送psync同步指令如果是首次连接主节点会开启bgsave子线程进行全量数据复制并且生成rdb文件并且在持久化期间会将从节点新的写命令缓存下来当持久化结束后主节点将rdb文件同步给从节点进行持久化如果同步期间存在网络波动从节点会进行重连恢复连接后主节点会将部分缺失的数据同步给从节点 问题: 主从复制会有什么问题 主从复制会带来主从复制风暴问题 如果有很多从节点为了缓解主从复制风暴(多个节点同时复制主节点导致主节点压力过大)我们可以让部分从节点与从节点(与主节点同步)同步数据也就是分层结构 问题: 哨兵模式的缺陷 哨兵模式不适合线上高并发场景主从切换会导致访问瞬断以及只是监控master节点并不做转发最终还是单节点master提供访问性能并没有提升多少高可用集群模式不仅很好的弥补了哨兵模式的缺点而且还具备了哨兵模式的选举机制所以推荐在生产环境使用 问题: Redis集群的数据是怎么存储的 Redis集群的所有数据被划分到16384个槽位中并且每个节点管理一部分的槽位而到客户端连接集群的时候会去缓存一份槽位信息方便定位到目标节点但是缓存的槽位信息可能会存在数据不一致的问题所以Redis集群提供了纠错机制当客户端通过槽位信息去定位目标节点的时候发现异常集群会帮忙纠错并且重定位到目标节点以及缓存一份新的槽位信息给客户端定位是通过CRC算法进行位运算的 问题: ZK和Redis的通信机制 ZK是集中式存储数据的时效性好但是会有数据存储压力Redis是gossip协议的数据存储被分散开了时效性稍微滞后 问题: Redis集群选举原理 当slave发现自己的master挂掉了就会尝试进行故障转移期待自己成为新的master首先会将自己记录集群的epoch进行加1并且广播通知给其他存活的master节点让他们来判断请求者是否合法如果合法就只会给每一个epoch发送一次ack尝试故障转移的slave收到超过一半的master节点的同意的ack信息就会成为新的master然后广播通知其他集群的节点自己成为新的master了注意: 建议设置3个以上的奇数master节点 问题: Redis集群为什么至少需要三个master节点并且推荐节点数为奇数 因为新master的选举需要大于半数的集群master节点同意才能选举成功如果只有两个master节点其中一个挂了是达不到选举新的master的条件的例子 3个master节点和4个master节点的场景 奇数master节点可以在满足选举该条件的基础上节省一个节点3个或者4个master节点如果挂了一个节点是可以重新选举新的master节点3个或4个master节点如果挂了两个节点就都无法选举出新的master节点了(无法满足半数以及以上) 所以奇数的master节点更多的是从节省机器资源角度出发的 问题: 如果重新选举时出现同一时刻多个slave发送请求给master节点进行选举可能会出现选举失败而且还可能会多次失败如果避免此问题 集群选举并不一定是一次就能成功的假如同一时刻有多个slave节点发送信息给maste节点master节点可能会同时发送到所有slave节点如果slave节点收到的结果都是各自持有一票这样就会再次重新选举我们可以通过参数设置slave发送信息给master的时间避免让所有slave同一时刻发送信息 问题: Redis集群的脑裂问题 Redis集群没有过半机制会有脑裂问题网络分区导致出现多个master节点一旦网络恢复了会将其中一个master变成slave而变成从节点后会将从节点本地数据清空同步master节点的rdb快照数据如果变成slave节点的服务数据是最新的而另外一个master节点不是最新的这样直接从master同步数据就会出现数据丢失问题Redis也有解决脑裂问题的方案但是是牺牲性能换来的可以通过设置参数让半数节点数据同步成功之后才能响应客户端避免脑裂问题但是性能却大大降低了这个其实就违背了Redis的AP机制Redis和ZK的脑裂问题以及解决方案都很类似都是需要半数或半数以上数据同步成功才能避免脑裂问题 问题: CAP理论 CAP理论是分布式领域⾮常重要的⼀个理论很多分布式中间件在实现时都需要遵守这个理论 C表示⼀致性指的的是分布式系统中的数据的⼀致性A表示可⽤性表示分布式系统是否正常可⽤P表示分区容错性表示分布式系统出现⽹络问题时的容错性 CAP理论是指在分布式系统中不能同时保证C和A也就是说在分布式系统中要么保证CP要么保证 AP也就是⼀致性和可⽤性只能取其⼀如果想要数据的⼀致性那么就需要损失系统的可⽤性如果需要系统⾼可⽤那么就要损失系统的数据⼀致性特指强⼀致性CAP理论太过严格在实际⽣产环境中更多的是使⽤BASE理论BASE理论是指分布式系统不需要保证数据的强⼀致只要做到最终⼀致也不需要保证⼀直可⽤保证基本可⽤即可 问题: Redis集群架构下的数据倾斜问题如何解决 使用本地缓存 使用分片算法的特性对key进行打散处理 big key形成集群数据倾斜对big key进行拆分
