加入收藏 | 设为首页 | 会员中心 | 我要投稿 晋中站长网 (https://www.0354zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长学院 > MySql教程 > 正文

一文带你揭开Redis复制原理的神秘面纱

发布时间:2019-09-18 03:59:11 所属栏目:MySql教程 来源:陈龙
导读:Redis作为一个非结构化的内存数据库,在某些应用场景具备相应优势,在实际的场景设计中也得到广泛的关注和使用。但是,大部分企业的Redis数据库架构为单机运行,没有设计容灾复制,这样对于Redis的容错特性没有发挥出来,而且无持久化情况下,数据存在丢失

从数据库1同步到缓存:

  1. 127.0.0.1:6380> keys * 
  2. 1) "test02" 
  3. 2) "c" 
  4. 3) "d" 
  5. 4) "a" 
  6. 5) "test" 
  7. 6) "kebo" 
  8. 7) "slavetest" 
  9. 8) "b" 
  10. 9) "redisfast" 
  11. 127.0.0.1:6380> get slavetest 
  12. "0851" 

重启从数据库2:

  1. 34855:S 26 Aug 2019 13:34:39.561 * DB loaded from disk: 0.000 seconds 
  2. 34855:S 26 Aug 2019 13:34:39.561 * Before turning into a replica, using my master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer. 
  3. 34855:S 26 Aug 2019 13:34:39.561 * Ready to accept connections 
  4. 34855:S 26 Aug 2019 13:34:39.561 * Connecting to MASTER 127.0.0.1:6379 
  5. 34855:S 26 Aug 2019 13:34:39.561 * MASTER <-> REPLICA sync started 
  6. 34855:S 26 Aug 2019 13:34:39.561 * Non blocking connect for SYNC fired the event. 
  7. 34855:S 26 Aug 2019 13:34:39.561 * Master replied to PING, replication can continue... 
  8. 34855:S 26 Aug 2019 13:34:39.562 * Trying a partial resynchronization (request d41f950be7593a93620b1fd872b7552668f0b355:888). 
  9. 34855:S 26 Aug 2019 13:34:39.562 * Successful partial resynchronization with master. 
  10. 34855:S 26 Aug 2019 13:34:39.562 * MASTER <-> REPLICA sync: Master accepted a Partial Resynchronization. 

从库启动后,加载本地数据,开始向主数据库进行请求同步,这里同步起点是根据从数据库的offset开始。

主库信息:

  1. 34781:M 26 Aug 2019 13:24:06.701 * Synchronization with replica 127.0.0.1:6382 succeeded 
  2. 34781:M 26 Aug 2019 13:29:45.037 # Connection with replica 127.0.0.1:6382 lost. 
  3. 34781:M 26 Aug 2019 13:34:39.562 * Replica 127.0.0.1:6382 asks for synchronization 
  4. 34781:M 26 Aug 2019 13:34:39.562 * Partial resynchronization request from 127.0.0.1:6382 accepted. Sending 56 bytes of backlog starting from offset 888. 

当从数据库重新连上主数据库时,从数据库会通过PSYNC命令将自己的复制偏移量offset发送给主数据库,主数据库会根据这个复制偏移量来决定对从数据库执行何种同步操作。以达到所有数据库的偏移量一致。

  1. 127.0.0.1:6379> info replication 
  2. # Replication 
  3. role:master 
  4. connected_slaves:2 
  5. slave0:ip=127.0.0.1,port=6380,state=online,offset=1139,lag=1 
  6. slave1:ip=127.0.0.1,port=6382,state=online,offset=1139,lag=1 
  7. master_replid:d41f950be7593a93620b1fd872b7552668f0b355 
  8. master_replid2:0000000000000000000000000000000000000000 
  9. master_repl_offset:1139 
  10. second_repl_offset:-1 
  11. repl_backlog_active:1 
  12. repl_backlog_size:1048576 
  13. repl_backlog_first_byte_offset:1 
  14. repl_backlog_histlen:1139 

总结:

Redis在主从数据库之间的复制是异步的,这意味着,主数据库执行完客户端请求的命令后会立即将命令发送给请求的客户端,并同步到从数据库,而不会等待从数据库接收到命令后再返回给客户端,因此该情况就会存在一定的数据不一致性风险,也就是Redis不保证强一致性,而是通过从库策略追赶与主数据库的数据差异,以保障主从状态一直。在Redis中也可以设置参数来强行让从库数据同步后,主库才能继续写入,这样的配置对主库访问要求较高,因此会影响主库的性能。

在主从同步中,如果出现数量差异较大,Redis会根据从库的offset进行选择全量、增量的恢复。

(编辑:晋中站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读