Redis高可用架构之主从同步

CAP原理

最终一致性

Redis提供的同步机制

  • 主从同步
  • 丛丛同步 缓解master节点的压力

Redis的同步方式

  • 增量同步

    • Redis同步的指令流，环形Buffer存储指令流
    • 缺点:buffer大小固定，会存在未执行的指令被覆盖掉的情况
  • 快照同步
    • 耗费资源，主节点Bgsave到磁盘文件中，再将文件中的内容传送到从节点

      • 从节点在进行快照文件接受完毕后进行全量加载，加载前先删除当前内存的数据，记载完毕后才继续进行增量同步

    需要合理设置buffer大小，避免发生快照同步死循环

增加从节点

首先进行一次全量的快照同步后，接下来再进行增量同步

无盘复制

快照同步的缺点:带来大量的资源消耗，特别是对于非SSD的磁盘存储来说会带来更大的系统负载。

主节点直接通过socket通信来将快照内容发送到从节点，主节点一边遍历内存一边发送内容到从节点。

从节点记录下内容后，再一次性加载到内存中。

wait指令

Redis的同步是异步复制的，可以使用wait指令来强制使用同步复制。但是一旦发生网络分区，将会导致Redis不可用

原文地址：https://www.cnblogs.com/chakawelkin/p/11333889.html

时间： 2024-08-03 07:05:32

Redis高可用架构之主从同步的相关文章

redis高可用架构

一.背景 公司的业务在大量的使用redis,访问量大的业务我们有在使用codis集群,redis 3.0集群,说到redis 3.0集群,我们线上已经跑了半年多了,集群本身没有出现过任务问题,但是由于我们这个业务是海外的,集群建在aws的ec2上,由于ec2的网络抖动或者ec2本身的原因,导致主从切换,目前aws的技术正在跟进,这个集群目前的QPS 50w+,集群本身已经做到了高可用和横向扩展,但是,实际情况一些小的业务没必要上集群,单个实例就可以满足业务需求,那么我们就要想办法如何保证单个实例

Redis 实战搭建高可用架构

前言:最近在看关于redis缓存方面的知识,今天就来个 Redis sentinel 高可用架构,实战开始之前,先看看sentinel的概念 什么是redis-sentinel Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案,当用Redis做Master-slave的高可用方案时,假如master宕机了,Redis本身(包括它的很多客户端)都没有实现自动进行主备切换,而Redis-sentinel本身也是一个独立运行的进程,它能监控多个master-slave集群,发

Redis的高并发、持久化、高可用架构设计

就是如果你用redis缓存技术的话,肯定要考虑如何用redis来加多台机器,保证redis是高并发的,还有就是如何让Redis保证自己不是挂掉以后就直接死掉了,redis高可用 我这里会选用我之前讲解过这一块内容,redis高并发.高可用.缓存一致性 redis高并发:主从架构,一主多从,一般来说,很多项目其实就足够了,单主用来写入数据,单机几万QPS,多从用来查询数据,多个从实例可以提供每秒10万的QPS. redis高并发的同时,还需要容纳大量的数据:一主多从,每个实例都容纳了完整的数据,比

Redis Sentinel高可用架构

Redis目前高可用的架构非常多,比如keepalived+redis,redis cluster,twemproxy,codis,这些架构各有优劣,今天暂且不说这些架构,今天主要说说redis sentinel高可用架构. 它的主要功能有以下几点 不时地监控redis是否按照预期良好地运行; 如果发现某个redis节点运行出现状况,能够通知另外一个进程(例如它的客户端); 能够进行自动切换.当一个master节点不可用时,能够选举出master的多个slave(如果有超过一个slave的话)中

mysql高可用研究之主从+MHA架构

最近在研究mysql的高可用架构,自己想总结下常用的高可用方案都有哪些.有哪些优缺点以及应用的场景?搞得是头昏脑涨,天昏地暗,看了诸多资料,每次都觉得公说公有理婆说婆有理.其实嘛,大家都没有说错,只不过适合自己的才是最正确的选择.今天就从比较常用的主从+MHA说起. 学习一种新的架构还是软件,最好还是先从了解它的原理开始,这样才能在做实验时测试出它的优势和弱势. ###################################################################

数据库高可用架构(MySQL、Oracle、MongoDB、Redis)

一.MySQL MySQL小型高可用架构 方案:MySQL双主.主从 + Keepalived主从自动切换 服务器资源:两台PC Server 优点:架构简单,节省资源 缺点:无法线性扩展,主从失败之后需要手动恢复主从架构 MySQL中型高可用架构 方案:MMM + MySQL双主 + 多从高可用方案 服务器资源: 1.至少五台PC Server,2台MySQL主库,2台MySQL从库,1台MMM Monitor: 2.1台MMM Monitor选择低配: 3.如果不采用F5作为从库的负载均衡器

[转]数据库高可用架构(MySQL、Oracle、MongoDB、Redis)

一.MySQL MySQL小型高可用架构 方案:MySQL双主.主从 + Keepalived主从自动切换 服务器资源:两台PC Server 优点:架构简单,节省资源 缺点:无法线性扩展,主从失败之后需要手动恢复主从架构 MySQL中型高可用架构 方案:MMM + MySQL双主 + 多从高可用方案 服务器资源: 1.至少五台PC Server,2台MySQL主库,2台MySQL从库,1台MMM Monitor: 2.1台MMM Monitor选择低配: 3.如果不采用F5作为从库的负载均衡器

maxscale配合MHA搭建读写分离的高可用架构（基于GTID replication主从架构，mysql5.6）

基于GTID的主从replication并配合MHA搭建高可用架构,请参考之前的博客:http://linzhijian.blog.51cto.com/1047212/1906434.这里只叙述如何在此基础上增加maxscale中间件,实现读写分离的功能. MaxScale是maridb开发的一个MySQL数据中间件,其配置简单,能够实现读写分离,并且可以根据主从状态实现写库的自动切换.官方文档:https://mariadb.com/kb/en/mariadb-enterprise/about

亿级商品详情页架构演进技术解密 | 高可用架构系列

亿级商品详情页架构演进技术解密 | 高可用架构系列 --http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=210272034&idx=1&sn=3be9d2b53c7fec88716ee8affd2515f8&scene=1&srcid=UfXZNNOVZZyZjQmp0VOh&from=groupmessage&isappinstalled=0#rd 此文是开涛在[三体高可用架构群]之分享内容