CN115190005B - 一种基于Redis的双宿主系统的高可用方法 - Google Patents

一种基于Redis的双宿主系统的高可用方法 Download PDF

Info

Publication number
CN115190005B
CN115190005B CN202210778785.XA CN202210778785A CN115190005B CN 115190005 B CN115190005 B CN 115190005B CN 202210778785 A CN202210778785 A CN 202210778785A CN 115190005 B CN115190005 B CN 115190005B
Authority
CN
China
Prior art keywords
physical machine
data
server
sentinel node
written
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202210778785.XA
Other languages
English (en)
Other versions
CN115190005A (zh
Inventor
杜景林
陈子文
李鑫
王坤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nanjing Suwei Boxin Information Technology Co ltd
Original Assignee
Nanjing University of Information Science and Technology
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nanjing University of Information Science and Technology filed Critical Nanjing University of Information Science and Technology
Priority to CN202210778785.XA priority Critical patent/CN115190005B/zh
Publication of CN115190005A publication Critical patent/CN115190005A/zh
Application granted granted Critical
Publication of CN115190005B publication Critical patent/CN115190005B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Hardware Redundancy (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明公开了一种基于Redis的双宿主系统的高可用方法，包括客户端、基于Redis模式的物理机A、物理机B并且三者之间两两通信，客户端将待写入数据写入物理机A的Master服务器，物理机B的slave服务器从物理机A的Master服务器中读取缓存并将该待写入数据更新后反馈给客户端；通过物理机A、B的Sentinel分别监控物理机A、B的工作状态，在物理机A发生故障时将客户端的待写入数据写入物理机B的缓冲服务器,并实时监测物理机A,在其恢复时重新启用；或通过调用物理机B的缓冲服务器和其slave服务器，并实时监测物理机A,在其恢复时重新启用；实现待写入数据与物理机B反馈给客户端数据的正确性。

Description

一种基于Redis的双宿主系统的高可用方法
技术领域
本发明涉及数据通信技术领域，特别是涉及一种基于Redis的双宿主系统的高可用方法。
背景技术
Redis数据库将所有数据存储在内存中，有很高的读写性能，支持RDB(快照方式)和AOF(文件追加方式)，常被用作高性能缓存服务器使用。Redis Sentinel(哨兵)节点是一个独立的进程，通过Sentinel节点可以提供高可用性。
在基础的Sentinel节点模式下，包括：三个Sentinel节点，一个Master服务器，两个Slave服务器，其中三个Sentinel节点互相通信，且每个Sentinel节点都监视一个Master服务器和两个Slave服务器，两个Slave服务器从Master服务器中同步数据，当Master服务器意外宕机时，Sentinel节点通过基于raft协议的投票选举算法，先从Sentinel节点中选出一个成为Leader，再由Leader从两个Slave服务器中选出一个升为Master服务器，自动完成故障转移。在故障转移的过程中，Redis服务是不可用的，可能会导致数据丢失的情况出现，且现有的Sentinel节点选举Leader的投票算法不能在两台物理机上实现，故无法自动实现故障转移，提供高可用性。
发明内容
本发明的目的在于：提供一种基于Redis的双宿主系统的高可用方法。该新的Redis服务模式，即双宿主模式，可在两台物理机上组建缓存高可用系统。
为实现上述目的，本发明提供如下技术方案：一种基于Redis的双宿主系统的高可用方法，包括客户端、基于Redis模式的一台物理机A、一台物理机B；所述客户端、物理机A、物理机B三者之间两两相连通信，所述客户端将待写入数据写入物理机A的Master服务器中，物理机B的slave服务器从物理机A的Master服务器中读取并缓存该待写入数据更新后反馈给客户端；所述物理机A包括一个Sentinel节点1、物理机B包括一个Sentinel节点2，所述Sentinel节点1和Sentinel节点2分别监控物理机A和物理机B的工作状态，通过执行步骤W1至步骤W3对物理机A进行状态监控，并在物理机A发生故障时，判断物理机A的故障类型I或故障类型II；
针对物理机A的故障类型I：暂时下线；物理机A的故障类型II：物理机A已经下线；
之后针对物理机A的故障类型I，通过调用物理机B的缓冲服务器，将来自客户端的待写入数据写入物理机B的缓冲服务器,并实时监测物理机A,在其恢复时重新启用；
针对物理机A故障类型II，通过调用物理机B的缓冲服务器和物理机B的slave服务器，并实时监测物理机A,在其恢复时重新启用；实现待写入数据与物理机B反馈给客户端数据的正确性；
步骤W1：物理机B通过Sentinel节点2、物理机A通过Sentinel节点1分别周期性地发送ping命令至物理机A的Master服务器，并在预设第一时长周期内判断物理机A的Sentinel节点1或物理机B的Sentinel节点2是否接收到来自物理机A的Master服务器反馈该ping命令对应的正确pong命令，是则执行步骤W3；否则，则执行步骤W2；
步骤W2：物理机B的Sentinel节点2、物理机A的Sentinel节点1分别在预设第二时长内判断物理机A的Sentinel节点1或物理机B的Sentinel节点2是否接收到来自物理机A的Master服务器反馈该ping命令对应的正确pong命令，是则判定物理机A的故障类型为I：物理机A暂时下线，同时根据收到反馈命令的Sentinel节点，获得判断物理机A暂时下线的物理机；否则在预设第二时长周期内均未接收到正确pong命令、或接收到错误pong命令，即判定物理机A的故障类型为II：物理机A已经下线，同时根据收到反馈命令的Sentinel节点获得判断物理机A已经下线的物理机；
步骤W3:返回步骤W1。
进一步地，前述的针对物理机A的故障类型I，通过调用物理机B的缓冲服务器，将待写入数据写入物理机B,并实时监测物理机A,在其恢复时重新启用，包括如下步骤S1至步骤S7；
步骤S1：判断物理机A发生故障暂时下线的物理机通知客户端，将待写入的数据写入至物理机B的缓冲服务器中，物理机B的缓冲服务器缓存该待写入的数据，并更新保存为数据M；物理机B的Slave读取物理机B的缓冲服务器的数据M,客户端自动识别并连接物理机B的Slave服务器，并读取数据M；随后执行步骤S2；
步骤S2：基于Sentinel节点1和Sentinel节点2分别监控物理机A和物理机B的工作状态，并判断物理机A发生故障暂时下线是否恢复，是则根据Sentinel节点的位置，获得判断物理机A恢复的物理机，进入步骤S3；否则执行步骤S7；
步骤S3：判断物理机A发生故障暂时下线恢复的物理机通知客户端物理机A暂时下线已恢复,命令客户端将待写入数据写入物理机A的Master服务器中；随后进入步骤S4；
步骤S4:判断物理机A发生故障暂时下线恢复的物理机通知物理机B，将物理机B的缓冲服务器中数据M全部缓存至物理机A的Master服务器中,随后执行步骤S5；
步骤S5:物理机B的缓冲服务器判断该数据M是否成功缓存至物理机A的Master服务器中；是则进入步骤S6；否则进入步骤S4；
步骤S6:物理机B的缓冲服务器清空其缓存服务器中的数据M；
步骤S7:执行步骤S1。
进一步地，前述的针对故障类型II，通过调用物理机B的缓冲服务器和物理机B的slave服务器，并实时监测物理机A,在其恢复时重新启用，包括如下步骤Q1至步骤Q9；
步骤Q1：触发故障转移机制：判断物理机A发生故障已经下线的物理机命令客户端将待写入数据写入物理机B的缓冲服务器中，物理机B的缓冲服务器缓存该待写入的数据，更新并保存为数据N；并定义客户端将待写入数据写入物理机B的缓冲服务器的时间点为t0判断物理机A发生故障已经下线的物理机命令客户端将时间点t0之后的待写入数据写入物理机B的Slave服务器中，随后进入步骤Q2；
步骤Q2:判断客户端在时间点t0之后是否将待写入数据写入物理机B的Slave服务器中；是则故障转移机制完成，进入步骤Q3；否则执行步骤Q9；
步骤Q3:基于Sentinel节点1和Sentinel节点2分别监控物理机A和物理机B的工作状态,判断物理机A发生故障已经下线的物理机通知物理机B将物理机B的缓冲服务器中数据N全部缓存至物理机B的Slave服务器中；随后进入步骤Q4；
步骤Q4:客户端读取物理机B的slave服务器中的数据，物理机B的缓冲服务器清空其缓存服务器中的数据N；随后进入步骤Q5；
步骤Q5:物理机A的Sentinel节点1，物理机B的Sentinel节点2分别判断物理机A发生故障已经下线是否恢复，是则进入步骤Q6,同时获得判断物理机A已经下线恢复的物理机，否则进入步骤Q8；
步骤Q6:判断物理机A已经下线恢复的物理机通知客户端物理机A已经下线已恢复,命令客户端将待写入数据写入物理机A的MASTER服务器中；并命令物理机A的Master服务器读取并缓存物理机B的Slave服务器中缓存的数据；随后进入步骤Q7；
步骤Q7:客户端从物理机A的Master服务器中读取数据；
步骤Q8:返回步骤Q5；
步骤Q9：返回步骤Q2。
进一步地，前述的物理机A的缓冲服务器在收到Sentinel节点1或Sentinel节点2的命令后与物理机B的Slave服务器相连；所述物理机A的缓冲服务器用于与物理机B的Slave服务器传输数据，所述物理机B的缓冲服务器用于与物理机A的Master服务器传输数据。
进一步地，前述的所述物理机A的Sentinel节点1、物理机B的Sentinel节点2均通过心跳检测机制监测所述物理机A、物理机B工作状态。
进一步地，前述的步骤W1中，物理机B通过Sentinel节点2、物理机A通过Sentinel节点1分别周期性地发送ping命令至物理机A的Master服务器，并在0.5秒内判断物理机A的Sentinel节点1或物理机B的Sentinel节点2是否接收到来自物理机A的Master服务器反馈该ping命令对应的正确pong命令。
进一步地，前述的步骤W2中，物理机B通过Sentinel节点2、物理机A通过Sentinel节点1分别在大于0.5秒的时间判断物理机A的Sentinel节点1或物理机B的Sentinel节点2是否接收到来自物理机A的Master服务器反馈该ping命令对应的正确pong命令。
通过新增添的双宿主模式，在出现断电、网络中断、服务器磁盘损坏、服务器故障，用户会访问不了，导致页面刷不出数据的青情况下，实现了在两台物理机上的故障转移，其中的缓冲服务器在Redis服务不可用的情况下，起到临时保存数据的作用，能自动在短时间内恢复服务，避免了数据的丢失，提高了系统服务的可用性。基于Redis提供的高可用服务，尤其是对微型企业来说，从至少三台物理机减少到两台，节约了运营成本。
附图说明
图1是系统工作流程图；
图2是本发明双宿主模式下的系统架构示意图。
具体实施方式
为了更了解本发明的技术内容，特举具体实施例并配合所附图式说明如下。
在本发明中参照附图来描述本发明的各方面，附图中示出了许多说明性实施例。本发明的实施例不局限于附图所述。应当理解，本发明通过上面介绍的多种构思和实施例，以及下面详细描述的构思和实施方式中的任意一种来实现，这是因为本发明所公开的构思和实施例并不限于任何实施方式。另外，本发明公开的一些方面可以单独使用，或者与本发明公开的其他方面的任何适当组合来使用。
本申请实例可通过对Redis数据库源码进行修改实现，使之能够在两台物理主机的情况下，提供Redis的高可用服务。
如图2所示，铁路售票系统作为客户端，物理机A和物理机B提供Redis的高可用服务。Redis里存储的数据是K1102这趟车各个站的名字、各个站点的到时和发时，余票信息等，这些数据用户访问会比较频繁，Redis性能很高，非常适合缓存这些访问频繁的数据。客户端、物理机A、物理机B三者之间两两相连通信，客户端将待写入数据写入物理机A的Master服务器中，物理机B的slave服务器从物理机A的Master服务器中读取并缓存该待写入数据更新后反馈给客户端；物理机A包括一个Sentinel节点1、物理机B包括一个Sentinel节点2。物理机A的Sentinel节点1、物理机B的Sentinel节点2均使用心跳检测机制监测所述物理机A、物理机B工作状态。
如图1所示，步骤W1：物理机B通过Sentinel节点2、物理机A通过Sentinel节点1分别周期性地发送ping命令至物理机A的Master服务器，并在0.5秒内判断物理机A的Sentinel节点1或物理机B的Sentinel节点2是否接收到来自物理机A的Master服务器反馈该ping命令对应的正确pong命令，是则继续执行该周期性的监测指令。
如果物理机B通过Sentinel节点2、物理机A通过Sentinel节点1未能在0.5秒内收到来自物理机A的Master服务器反馈该ping命令对应的正确pong命令，则物理机B的Sentinel节点2、物理机A的Sentinel节点1分别在1秒内长内判断物理机A的Sentinel节点1或物理机B的Sentinel节点2是否接收到来自物理机A的Master服务器反馈该ping命令对应的正确pong命令，是则判定物理机A的故障类型为I：物理机A暂时下线，同时根据收到反馈命令的Sentinel节点，获得判断物理机A暂时下线的物理机；如果超过1秒未接收到来自物理机A的Master服务器反馈该ping命令对应的正确pong命令，或者接收到错误pong命令，即判定物理机A的故障类型为II：物理机A已经下线，同时根据收到反馈命令的Sentinel节点获得判断物理机A已经下线的物理机。
针对故障类型I：当Sentinel节点2判定Master服务器暂时下线时，Sentinel节点2通知客户端将待写入数据写入物理机B的缓冲服务器中，物理机B的缓冲服务器缓存代写入数据，并更新保存。Sentinel节点1和Sentinel节点2分别监控物理机A和物理机B的工作状态，并判断物理机A发生故障暂时下线是否恢复，是则根据Sentinel节点的位置，获得判断物理机A恢复的物理机，该物理机通知客户端物理机A暂时下线已恢复,命令客户端将待写入数据写入物理机A的Master服务器中，并且通知物理机B，将物理机B的缓冲服务器中数据全部缓存至物理机A的Master服务器中数据同步完成后，物理机B的缓冲服务器清空。
针对故障类型II：触发故障转移机制：判断物理机A发生故障已经下线的物理机向客户端订阅的频道发布switch-master的消息，告知客户端Redis服务正在进行物理机A的Master和物理机B的Slave服务器的切换，客户端根据IP地址和端口号将待写入数据写入物理机B的缓冲服务器中，物理机B的缓冲服务器缓存该待写入的数据，更新并保存为数据N；并定义客户端将待写入数据写入物理机B的缓冲服务器的时间点为t0判断物理机A发生故障已经下线的物理机命令客户端将时间点t0之后的待写入数据写入物理机B的Slave服务器中。
判断客户端在时间点t0之后是否将待写入数据写入物理机B的Slave服务器中；是则故障转移机制完成,判断物理机A发生故障已经下线的物理机通知物理机B将物理机B的缓冲服务器中数据N全部缓存至物理机B的Slave服务器中；客户端读取物理机B的slave服务器中的数据，物理机B的缓冲服务器清空其缓存服务器中的数据N；判断客户端在时间点t0之后是否将待写入数据写入物理机B的Slave服务器中；是则故障转移机制完成，否则继续执行判断故障转移是否完成的指令；如果故障转移完成，那么基于Sentinel节点1和Sentinel节点2分别监控物理机A和物理机B的工作状态,判断物理机A发生故障已经下线的物理机通知物理机B将物理机B的缓冲服务器中数据N全部缓存至物理机B的Slave服务器中；随后客户端读取物理机B的slave服务器中的数据，物理机B的缓冲服务器清空其缓存服务器中的数据N；随后，物理机A的Sentinel节点1，物理机B的Sentinel节点2分别判断物理机A发生故障已经下线是否恢复，如果故障已下线恢复，判断物理机A已经下线恢复的物理机通知客户端物理机A已经下线已恢复,命令客户端将待写入数据写入物理机A的MASTER服务器中；并命令物理机A的Master服务器读取并缓存物理机B的Slave服务器中缓存的数据；之后客户端即可从物理机A的Master服务器中读取数据；如果故障下线没有恢复，那么就继续执行判断故障下线是否恢复的指令。
当客户端写入缓存数据时，如果物理机A突然宕机，物理机B将自身的IP地址和要写入的端口号发送给客户端，客户端根据IP地址和端口号将缓存数据写入物理机B中，物理机B中的Slave服务器自动更新成为逻辑上的Master服务器，期间通过缓冲服务器依然保持整个系统的服务可用状态，客户端自动识别并连接Master服务器，实现服务高可用。
缓冲服务器拥有发布与订阅功能(pub/sub)，通过将信息发送给频道(channel)来实现与其他Redis进程通信。在缓冲服务器初始化时，Sentinel节点通过Master服务器和Slave服务器上的__sentinel__:hello频道使用info命令获得缓冲服务器的身份信息，包括IP地址、端口号和运行ID(runid)，来更新网络拓扑结构。
缓冲服务器拥有自己的TCP端口号，使用Socket与Master服务器和Salve服务器建立联系，传输缓存数据，并且使用AOF文件形式实现缓存数据持久化。
通过新增添的双宿主模式，在出现断电、网络中断、服务器磁盘损坏、服务器故障，用户会访问不了，导致页面刷不出数据的青情况下，实现了在两台物理机上的故障转移，其中的缓冲服务器在Redis服务不可用的情况下，起到临时保存数据的作用，能自动在短时间内恢复服务，避免了数据的丢失，提高了系统服务的可用性。基于Redis提供的高可用服务，尤其是对微型企业来说，从至少三台物理机减少到两台，节约了运营成本。
虽然本发明已以较佳实施例阐述如上，然其并非用以限定本发明。本发明所属技术领域中具有通常知识者，在不脱离本发明的精神和范围内，当可作各种的更动与润饰。因此，本发明的保护范围当视权利要求书所界定者为准。

Claims (5)

1.一种基于Redis的双宿主系统的高可用方法，其特征在于，包括客户端、基于Redis模式的一台物理机A、一台物理机B；所述客户端、物理机A、物理机B三者之间两两相连通信，所述客户端将待写入数据写入物理机A的Master服务器中，物理机B的slave服务器从物理机A的Master服务器中读取并缓存该待写入数据更新后反馈给客户端；所述物理机A包括一个Sentinel节点1、物理机B包括一个Sentinel节点2，所述Sentinel节点1和Sentinel节点2分别监控物理机A和物理机B的工作状态，通过执行步骤W1至步骤W3对物理机A进行状态监控，并在物理机A发生故障时，判断物理机A的故障类型I或故障类型II；
步骤W1：物理机B通过Sentinel节点2、物理机A通过Sentinel节点1分别周期性地发送ping命令至物理机A的Master服务器，并在预设第一时长周期内判断物理机A的Sentinel节点1或物理机B的Sentinel节点2是否接收到来自物理机A的Master服务器反馈该ping命令对应的正确pong命令，是则执行步骤W3；否则，则执行步骤W2；
步骤W2：物理机B的Sentinel节点2、物理机A的Sentinel节点1分别在预设第二时长内判断物理机A的Sentinel节点1或物理机B的Sentinel节点2是否接收到来自物理机A的Master服务器反馈该ping命令对应的正确pong命令，是则判定物理机A的故障类型为I：物理机A暂时下线，同时根据收到反馈命令的Sentinel节点，获得判断物理机A暂时下线的物理机；否则在预设第二时长周期内均未接收到正确pong命令、或接收到错误pong命令，即判定物理机A的故障类型为II：物理机A已经下线，同时根据收到反馈命令的Sentinel节点获得判断物理机A已经下线的物理机；
步骤W3:返回步骤W1；
物理机A的故障类型I：暂时下线；物理机A的故障类型II：物理机A已经下线；
之后针对物理机A的故障类型I，通过调用物理机B的缓冲服务器，将来自客户端的待写入数据写入物理机B的缓冲服务器,并实时监测物理机A,在其恢复时重新启用；具体包括如下步骤S1至步骤S7；
步骤S1：判断物理机A发生故障暂时下线的物理机通知客户端，将待写入的数据写入至物理机B的缓冲服务器中，物理机B的缓冲服务器缓存该待写入的数据，并更新保存为数据M；物理机B 的Slave读取物理机B 的缓冲服务器的数据M,客户端自动识别并连接物理机B的Slave服务器，并读取数据M；随后执行步骤S2；
步骤S2：基于Sentinel节点1和Sentinel节点2分别监控物理机A和物理机B的工作状态，并判断物理机A发生故障暂时下线是否恢复，是则根据Sentinel节点的位置，获得判断物理机A恢复的物理机，进入步骤S3；否则执行步骤S7；
步骤S3：判断物理机A发生故障暂时下线恢复的物理机通知客户端物理机A暂时下线已恢复, 命令客户端将待写入数据写入物理机A的Master服务器中；随后进入步骤S4；
步骤S4: 判断物理机A发生故障暂时下线恢复的物理机通知物理机B，将物理机B的缓冲服务器中数据M全部缓存至物理机A的Master服务器中,随后执行步骤S5；
步骤S5: 物理机B的缓冲服务器判断该数据M是否成功缓存至物理机A的Master服务器中；是则进入步骤S6；否则进入步骤S4；
步骤S6: 物理机B的缓冲服务器清空其缓存服务器中的数据M；
步骤S7: 执行步骤S1；
针对故障类型II，通过调用物理机B的缓冲服务器和物理机B 的slave服务器，并实时监测物理机A,在其恢复时重新启用；实现待写入数据与物理机B反馈给客户端数据的正确性；包括如下步骤Q1至步骤Q9；
步骤Q1：触发故障转移机制：判断物理机A发生故障已经下线的物理机命令客户端将待写入数据写入物理机B的缓冲服务器中，物理机B的缓冲服务器缓存该待写入的数据，更新并保存为数据N；并定义客户端将待写入数据写入物理机B的缓冲服务器的时间点为t0判断物理机A发生故障已经下线的物理机命令客户端将时间点t0之后的待写入数据写入物理机B的Slave服务器中，随后进入步骤Q2；
步骤Q2:判断客户端在时间点t0之后是否将待写入数据写入物理机B的Slave服务器中；是则故障转移机制完成，进入步骤Q3；否则执行步骤Q9；
步骤Q3:基于Sentinel节点1和Sentinel节点2分别监控物理机A和物理机B的工作状态,判断物理机A发生故障已经下线的物理机通知物理机B将物理机B的缓冲服务器中数据N全部缓存至物理机B的Slave服务器中；随后进入步骤Q4；
步骤Q4:客户端读取物理机B的slave服务器中的数据，物理机B的缓冲服务器清空其缓存服务器中的数据N；随后进入步骤Q5；
步骤Q5:物理机A 的Sentinel节点1 ，物理机B的Sentinel节点2分别判断物理机A发生故障已经下线是否恢复，是则进入步骤Q6,同时获得判断物理机A已经下线恢复的物理机，否则进入步骤Q8；
步骤Q6: 判断物理机A已经下线恢复的物理机通知客户端物理机A已经下线已恢复,命令客户端将待写入数据写入物理机A的MASTER服务器中；并命令物理机A的Master服务器读取并缓存物理机B 的Slave服务器中缓存的数据；随后进入步骤Q7；
步骤Q7: 客户端从物理机A的Master服务器中读取数据；
步骤Q8: 返回步骤Q5；
步骤Q9：返回步骤Q2。
2.根据权利要求1所述的一种基于Redis的双宿主系统的高可用方法，其特征在于，物理机A的缓冲服务器在收到Sentinel节点1或Sentinel节点2的命令后与物理机B的Slave服务器相连；所述物理机A的缓冲服务器用于与物理机B的Slave服务器传输数据，所述物理机B 的缓冲服务器用于与物理机A的Master服务器传输数据。
3.根据权利要求2所述的一种基于Redis的双宿主系统的高可用方法，其特征在于，所述物理机A的Sentinel节点1、物理机B的Sentinel节点2均通过心跳检测机制监测所述物理机A、物理机B工作状态。
4.根据权利要求1所述的一种基于Redis的双宿主系统的高可用方法，其特征在于，步骤W1中，物理机B通过Sentinel节点2、物理机A通过Sentinel节点1分别周期性地发送ping命令至物理机A的Master服务器，并在0.5秒内判断物理机A的Sentinel节点1或物理机B的Sentinel节点2是否接收到来自物理机A的Master服务器反馈该ping命令对应的正确pong命令。
5.根据权利要求1所述的一种基于Redis的双宿主系统的高可用方法，其特征在于，步骤W2中，物理机B通过Sentinel节点2、物理机A通过Sentinel节点1分别在大于0.5秒的时间判断物理机A的Sentinel节点1或物理机B的Sentinel节点2是否接收到来自物理机A的Master服务器反馈该ping命令对应的正确pong命令。
CN202210778785.XA 2022-06-30 2022-06-30 一种基于Redis的双宿主系统的高可用方法 Active CN115190005B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210778785.XA CN115190005B (zh) 2022-06-30 2022-06-30 一种基于Redis的双宿主系统的高可用方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210778785.XA CN115190005B (zh) 2022-06-30 2022-06-30 一种基于Redis的双宿主系统的高可用方法

Publications (2)

Publication Number Publication Date
CN115190005A CN115190005A (zh) 2022-10-14
CN115190005B true CN115190005B (zh) 2023-05-16

Family

ID=83514488

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210778785.XA Active CN115190005B (zh) 2022-06-30 2022-06-30 一种基于Redis的双宿主系统的高可用方法

Country Status (1)

Country Link
CN (1) CN115190005B (zh)

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109769028A (zh) * 2019-01-25 2019-05-17 深圳前海微众银行股份有限公司 Redis集群管理方法、装置、设备及可读存储介质
CN110659262A (zh) * 2019-09-20 2020-01-07 聚好看科技股份有限公司 一种redis节点主从切换方法及装置
CN110674192A (zh) * 2019-10-09 2020-01-10 浪潮云信息技术有限公司 一种Redis高可用VIP漂移方法、终端及存储介质
CN110781039A (zh) * 2019-09-30 2020-02-11 新华三信息安全技术有限公司 哨兵进程选举方法及装置
CN111026379A (zh) * 2019-12-06 2020-04-17 南京联创信息科技有限公司 一种Redis主从分片集群高可用方法
CN111125261A (zh) * 2020-03-31 2020-05-08 四川新网银行股份有限公司 基于分布式缓存的数据传输方法
CN112100005A (zh) * 2020-08-20 2020-12-18 紫光云(南京)数字技术有限公司 一种Redis副本集的实现方法及装置
CN112860379A (zh) * 2021-02-24 2021-05-28 紫光云技术有限公司 一种云平台上安装部署redis高可用的方法
CN114090574A (zh) * 2021-10-27 2022-02-25 青岛海尔科技有限公司 Redis哨兵集群部署方法、装置、设备及存储介质
CN114138568A (zh) * 2021-12-08 2022-03-04 兴业银行股份有限公司 Redis哨兵模式下客户端故障转移的调度方法及系统

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109769028A (zh) * 2019-01-25 2019-05-17 深圳前海微众银行股份有限公司 Redis集群管理方法、装置、设备及可读存储介质
CN110659262A (zh) * 2019-09-20 2020-01-07 聚好看科技股份有限公司 一种redis节点主从切换方法及装置
CN110781039A (zh) * 2019-09-30 2020-02-11 新华三信息安全技术有限公司 哨兵进程选举方法及装置
CN110674192A (zh) * 2019-10-09 2020-01-10 浪潮云信息技术有限公司 一种Redis高可用VIP漂移方法、终端及存储介质
CN111026379A (zh) * 2019-12-06 2020-04-17 南京联创信息科技有限公司 一种Redis主从分片集群高可用方法
CN111125261A (zh) * 2020-03-31 2020-05-08 四川新网银行股份有限公司 基于分布式缓存的数据传输方法
CN112100005A (zh) * 2020-08-20 2020-12-18 紫光云(南京)数字技术有限公司 一种Redis副本集的实现方法及装置
WO2022036901A1 (zh) * 2020-08-20 2022-02-24 紫光云(南京)数字技术有限公司 一种Redis副本集的实现方法及装置
CN112860379A (zh) * 2021-02-24 2021-05-28 紫光云技术有限公司 一种云平台上安装部署redis高可用的方法
CN114090574A (zh) * 2021-10-27 2022-02-25 青岛海尔科技有限公司 Redis哨兵集群部署方法、装置、设备及存储介质
CN114138568A (zh) * 2021-12-08 2022-03-04 兴业银行股份有限公司 Redis哨兵模式下客户端故障转移的调度方法及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Redis分布式缓存实现与解析";周智;;《信息通信》(06);全文 *

Also Published As

Publication number Publication date
CN115190005A (zh) 2022-10-14

Similar Documents

Publication Publication Date Title
US7518983B2 (en) Proxy response apparatus
CN110677282B (zh) 一种分布式系统的热备份方法及分布式系统
CN102137017A (zh) 用于虚拟网络单元的工作方法及装置
CN111371625A (zh) 一种双机热备的实现方法
CN112218321B (zh) 主备链路切换方法、装置、通信设备和存储介质
CN112052127B (zh) 一种用于双机热备环境的数据同步方法及装置
WO2012155630A1 (zh) 一种容灾的方法、装置及系统
CN110661705B (zh) 一种硬件网络交换引擎和网络故障处理系统及方法
CN114764380A (zh) 一种基于etcd的分布式集群控制方法和装置
CN102045187A (zh) 一种利用检查点实现高可用性系统的方法和设备
CN114422335A (zh) 通信方法、装置、服务器及存储介质
CN111880947B (zh) 一种数据传输方法及装置
CN115190005B (zh) 一种基于Redis的双宿主系统的高可用方法
CN105939254A (zh) Vrrp备份组状态切换的方法及装置
CN110351122B (zh) 容灾方法、装置、系统与电子设备
JP5285044B2 (ja) クラスタシステム復旧方法及びサーバ及びプログラム
CN103391324A (zh) 一种基于tftp协议的热备份方法
CN112637337B (zh) 一种数据处理方法及装置
CN113890817A (zh) 一种通信优化方法和装置
CN110716827B (zh) 适用于分布式系统的热备份方法及分布式系统
CN115866018B (zh) 业务处理方法、装置、电子设备及计算机可读存储介质
CN115250232B (zh) 一种主管理口的配置方法、装置及存储介质
CN115412603B (zh) 一种消息中间件的消息客户端模块的高可用的方法及装置
CN104702422A (zh) 实现通信设备高可用性的方法、装置和系统
CN114422567B (zh) 数据请求的处理方法、装置、系统、计算机设备及介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20240711

Address after: Room 201, Building 8, Xingzhihui Business Garden, No. 19 Xinghuo Road, Jiangbei New District, Nanjing City, Jiangsu Province 210000

Patentee after: Nanjing Suwei Boxin Information Technology Co.,Ltd.

Country or region after: China

Address before: 210044, No. 219, Ning six road, Pukou District, Jiangsu, Nanjing

Patentee before: Nanjing University of Information Science and Technology

Country or region before: China