CN103973424A - 缓存***中的故障解决方法和设备 - Google Patents
缓存***中的故障解决方法和设备 Download PDFInfo
- Publication number
- CN103973424A CN103973424A CN201410218797.2A CN201410218797A CN103973424A CN 103973424 A CN103973424 A CN 103973424A CN 201410218797 A CN201410218797 A CN 201410218797A CN 103973424 A CN103973424 A CN 103973424A
- Authority
- CN
- China
- Prior art keywords
- data
- node
- host node
- current host
- operation requests
- 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.)
- Granted
Links
Landscapes
- Computer And Data Communications (AREA)
Abstract
本发明的实施方式提供了一种缓存***中的故障解决方法。该方法包括:a)、利用keepalived技术检测作为缓存服务器的主节点是否发生故障;b)、如果所述主节点发生故障,将与所述主节点绑定的虚拟IP地址绑定到所述主节点的备用节点上,使得所述备用节点作为当前主节点。本发明的方法可以减缓甚至避免现有技术中的因节点故障而导致的应用层服务被拖死的可能性增大的问题。此外,本发明的另一方面提供了一种缓存***中的故障解决设备。
Description
技术领域
本发明的实施方式涉及数据缓存技术领域,更具体地,本发明的实施方式涉及缓存***中的故障解决方法和设备。
背景技术
本部分旨在为权利要求书中陈述的本发明的实施方式提供背景或上下文。此处的描述可包括可以探究的概念,但不一定是之前已经想到或者已经探究的概念。因此,除非在此指出,否则在本部分中描述的内容对于本申请的说明书和权利要求书而言不是现有技术,并且并不因为包括在本部分中就承认是现有技术。
在大负载、高并发的各个网站中,为了减少对数据库的I/O操作次数,减轻数据库的负载,通常采用memcached作为缓存***。memcached是一个高性能的、分布式的内存缓存***,由于它利用内存来缓存数据,支持快速读写数据,因此,可以显著提高网站页面的访问速度。
发明内容
但是,本发明人在研究过程中发现,在memcached缓存***中,是将数据缓存在一个缓存服务器节点中,当该节点因各种原因出现故障(如,网络方面的故障或该节点自身的故障)时,该节点上的数据就会访问不到。如果此时某个应用服务器(即,缓存客户端)上的应用层服务需要对该故障节点上的数据进行操作,该故障节点上的数据无法访问得到。在这种情况下,该应用服务器会等待一段时间,如果在这段时间内一直没有获得响应,就会转而向数据库发起数据操作请求。
依照现有技术,当应用服务器在这等待的时间内一直没有获得响应,就会确定其想要操作的数据所在的节点出现了故障,进而再向数据库发起数据操作请求。但是,在该应用服务器等待的同时,很有可能会迅速产生一些新的应用层服务也需要对该故障节点上的数据进行操作,并且,由于无法获得响应,这些应用层服务就会越堆积越多。当再向数据库发起数据操作请求时,数据库很可能无法对数量众多的应用层服务做到及时响应,最终,一些应用层服务被拖死的可能性就会非常大。
为此,非常需要一种缓存***中的故障解决方法和设备,以减缓甚至避免现有技术中的因节点故障而导致的应用层服务被拖死的可能性增大的问题。
在本上下文中,本发明的实施方式期望提供一种缓存***中的故障解决方法和设备。
在本发明实施方式的第一方面中,提供了一种缓存***中的故障解决方法,包括:
a)、利用keepalived技术检测作为缓存服务器的主节点是否发生故障;
b)、如果所述主节点发生故障,将与所述主节点绑定的虚拟IP地址重新绑定到所述主节点的备用节点上,使得所述备用节点作为当前主节点。
在本发明实施方式的第二方面中,提供了一种缓存***中的故障解决设备,包括:
检测模块,用于利用keepalived技术检测作为缓存服务器的主节点是否发生故障;
主备切换模块,用于如果所述主节点发生故障,将与所述主节点绑定的虚拟IP地址重新绑定到所述主节点的备用节点上,使得所述备用节点作为当前主节点。
在本发明实施方式中,对memcached缓存***采用主备双节点的结构,即,为每一个作为缓存服务器的主节点建立一个备用节点。先由主节点执行各数据操作,一旦检测到主节点发生故障,就由备用节点作为当前主节点执行各数据操作。因此,即使主节点发生了故障,各应用服务器上的应用层服务也可以获得备用节点的及时响应,从而减少应用层服务出现被拖死的可能性。
附图说明
通过参考附图阅读下文的详细描述,本发明示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中,以示例性而非限制性的方式示出了本发明的若干实施方式,其中:
图1示意性地示出了本发明实施方式可以在其中实施的一个示例性场景;
图2示意性地示出了根据本发明的一个实施方式的缓存***中的故障解决方法的流程图;
图3示意性地示出了根据本发明的一个实施方式的缓存***中的数据读取方法的流程图;
图4示意性地示出了根据本发明的另一个实施方式的缓存***中的数据读取方法的流程图;
图5示意性地示出了根据本发明的一个实施方式的从当前主节点中读取数据的方法的流程图;
图6示意性地示出了根据本发明的一个实施方式的缓存***中的数据写入方法的流程图;
图7示意性地示出了根据本发明的一个实施方式的缓存***中的故障解决设备的结构框架图;
图8示意性地示出了根据本发明的一个实施方式的缓存***中的数据读取设备的结构框架图;
图9示意性地示出了根据本发明的另一个实施方式的缓存***中的数据读取设备的结构框架图;
图10示意性地示出了根据本发明的一个实施方式的缓存***中的数据写入设备的结构框架图。
在附图中,相同或对应的标号表示相同或对应的部分。
具体实施方式
下面将参考若干示例性实施方式来描述本发明的原理和精神。应当理解,给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本发明,而并非以任何方式限制本发明的范围。相反,提供这些实施方式是为了使本公开更加透彻和完整,并且能够将本公开的范围完整地传达给本领域的技术人员。
本领域技术人员知道,本发明的实施方式可以实现为一种***、装置、设备、方法或计算机程序产品。因此,本公开可以具体实现为以下形式,即:完全的硬件、完全的软件(包括固件、驻留软件、微代码等),或者硬件和软件结合的形式。
根据本发明的实施方式,提出了一种缓存***中的故障解决方法和设备。
在本文中,需要理解的是,附图中的任何元素数量均用于示例而非限制,以及任何命名都仅用于区分,而不具有任何限制含义。
下面参考本发明的若干代表性实施方式,详细阐释本发明的原理和精神。
发明概述
本发明人发现,在采用memcached作为缓存***时,如果仅是将数据缓存在一个缓存服务器节点中的话,当该节点出现故障(如,网络方面的故障或该节点自身的故障)时,由于该故障节点上的数据无法访问,就会使需要操作该故障节点上的数据的某个应用服务器(即,缓存客户端)上的应用层服务无法获得响应。对于该应用服务器而言,在没有获得响应时会再等待一段时间,只有在等待的这段时间内一直没有获得响应的情况下,才会转而向数据库发起数据操作请求。但是,在该应用服务器等待的这段时间内,很有可能会迅速产生一些新的应用服务也需要对该故障节点上的数据进行操作,并且,这些应用层服务还可能越堆积越多。即使再向数据库发起数据操作请求,数据库也很可能无法及时对数量众多的应用层服务进行响应,最终,一些应用层服务被拖死的可能性就会非常大。
如果对memcached缓存***采用主备双节点的结构,即,为每一个作为缓存服务器的主节点建立一个备用节点,先由主节点执行各数据操作,一旦检测到主节点发生故障,就由备用节点作为当前主节点执行各数据操作,那么,即使主节点发生了故障,各应用服务器上的应用层服务也可以获得备用节点的及时响应,从而减少应用层服务出现被拖死的可能性。
在介绍了本发明的基本原理之后,下面具体介绍本发明的各种非限制性实施方式。
应用场景总览
首先参考图1,图1示意性地示出了本发明的实施方式可以在其中实施的示例性应用场景。以下仅以缓存服务器集群中的两个缓存服务器为例进行说明。其中,初始化时,缓存服务器10为主节点,缓存服务器20为备用节点。当缓存服务器10正常工作时,虚拟IP地址绑定在缓存服务器10上,如果缓存客户端30发出一个数据操作请求31(如,数据写入请求或数据读取请求),该数据操作请求31会到达缓存服务器10上,并由缓存服务器10为缓存客户端30提供服务。缓存服务器20检测缓存服务器10是否发生故障。如果缓存服务器10发生故障,缓存服务器20将虚拟IP地址绑定到自己身上,使缓存服务器20成为当前主节点。在成为当前主节点后,如果缓存客户端30发出一个数据操作请求32(如,数据写入请求或数据读取请求),该数据操作请求32会到达缓存服务器20上,并由缓存服务器20为缓存客户端30提供服务。缓存服务器10和20可以是Web服务器,也可以是其他类型的服务器,例如APP服务器。本领域技术人员可以理解,图1所示的示意图仅是本发明的实施方式可以在其中得以实现的一个示例。本发明实施方式的应用范围不受到该框架任何方面的限制。
示例性方法
下面结合图1的应用场景,参考图2来描述根据本发明示例性实施方式的、用于缓存***中的故障解决方法。需要注意的是,上述应用场景仅是为了便于理解本发明的精神和原理而示出,本发明的实施方式在此方面不受任何限制。相反,本发明的实施方式可以应用于适用的任何场景。
请参阅图2,其示意性地示出了根据本发明的一个实施方式的缓存***中的故障解决方法的流程图,方法具体例如可以包括:
步骤201:利用keepalived技术检测作为缓存服务器的主节点是否发生故障。
步骤202:如果所述主节点发生故障,将与所述主节点绑定的虚拟IP地址绑定到所述主节点的备用节点上,使得所述备用节点作为当前主节点。
在主备双节点的模式下,虚拟IP地址在某一时刻只能属于某一个节点(即,缓存服务器),另一个节点作为备用节点存在。当主节点因故障而不可用时,备用节点接管虚拟IP地址,继续向各个应用服务器(即,缓存客户端)提供正常服务。
例如,主节点A的实际IP地址为:192.168.0.11,备用节点B的实际IP地址为:192.168.0.12,虚拟IP地址(用于对外提供服务)为:192.168.0.200。默认情况下,虚拟IP地址绑定在主节点A上,并由主节点A通过该虚拟IP地址对外提供服务,当主节点A因故障不可用时,该虚拟IP地址绑定到备用节点B上,并由备用节点B通过该虚拟IP地址对外提供服务。
在现有技术中,keepalived的作用是检测web服务器的状态,如果有一台web服务器出现工作故障,keepalived将检测到,并将有故障的web服务器从服务器群中剔除出去。当web服务器工作正常后,keepalived还会自动将web服务器加入到服务器群中,这些工作全部自动完成,不需要人工干涉,需要人工做的只是修复故障的web服务器。
在本发明的实施方式中,可以利用keepalived技术检测memcached缓存***中作为缓存服务器的主节点是否发生故障。具体地,在节点A和节点B上分别运行一个keepalived进程,并且,节点A为主节点,节点B为备用节点。节点B上的keepalived进程实时检测节点A是否出现故障,一旦检测到节点A出现故障,就将绑定在节点A上的虚拟IP地址绑定到节点B上,使节点B成为当前主节点。而当节点A的故障被解除并恢复正常后,节点A上的keeplived进程实时检测节点B是否出现故障,一旦检测到节点B出现故障,就会将绑定到节点B上的虚拟IP地址重新绑定回节点A上,使节点A再次成为当前主节点。
其中,keepalived进程的工作机制类似于层3、层4或层5的交换机制。这里,层3、层4和层5分别指IP/TCP协议栈的IP层、TCP(TransmissionControl Protocol,传输控制协议)层以及应用层。keepalived进程做故障检测的原理分别如下:
1、当使用层3的工作方式时:
层3的工作方式是以服务器的IP地址是否有效作为该服务器工作正常与否的标准。备用节点中的keepalived进程会定期向主节点发送一个ICMP的数据包(即,常用的Ping程序),如果发现主节点的IP地址没有激活,备用节点中的keepalived进程向备用节点报告主节点故障。
这种情况的典型例子是当主节点被非法关机时,备用节点上的keepalived进程可以通过上述方式检测出主节点出现故障。
2、当使用层4的工作方式时:
层4的工作方式主要是以服务器的TCP端口的状态作为该服务器工作正常与否的标准。如,缓存服务器的TCP端口一般是80,如果备用节点中的keepalived进程检测到主节点的80端口没有启动,备用节点中的keepalived进程向备用节点报告主节点故障。
3、当使用层5的工作方式时:
层5的工作方式比层3和层4的复杂一些,在网络上占用的带宽也要大一些。备用节点上的keepalived进程将根据用户的设定检测主节点的程序是否运行正常,如果与用户的设定不相符,备用节点中的keepalived进程向备用节点报告主节点故障。
在本发明的一个优选实施方式中,如图3所示,本实施方式示意的方法还可以包括:
步骤203A:响应于缓存客户端读数据的操作请求,从当前主节点中读取所述读数据的操作请求针对的数据,并将从所述当前主节点读到的数据返回给所述缓存客户端。
在本发明的另一个优选实施方式中,如图4所示,上述方法还可以进一步包括:
步骤204A:从所述当前主节点的备用节点读取所述读数据的操作请求针对的数据。
步骤205A:将从所述当前主节点读到的数据以及从所述当前主节点的备用节点读到的数据进行比较,如果两者不一致,利用从所述当前主节点读到的数据对所述当前主节点的备用节点中的对应数据进行更新。
需要说明的是,本发明的实施方式并不限定步骤203A与204A的执行顺序,两者可以先后执行,也可以同时执行。
可以理解的,在主备双节点的模式下,只从当前主节点中读取数据。而对于当前主节点的备用节点(即,原来的主节点),当其解除故障并恢复正常时,再利用从当前主节点读到的数据更新当前主节点的备用节点中的对应数据。
在本发明的一个优选实施方式中,如图5所示,上述步骤203A包括:
步骤2031A:利用SocketServer技术监听是否有来自于缓存客户端的读数据的操作请求,如果是,进入步骤2032A,否则,返回步骤2031A。
步骤2032A:根据所述读数据的操作请求执行读数据操作。
步骤2033A:将从所述当前主节点中读到的数据返回给所述缓存客户端。
本发明的实施方式中,当主备双节点的模式建立后,当前主节点可以利用SocketServer技术实现数据的读取。具体地,在节点A和节点B上分别运行一个SocketServer进程,并且,节点A为主节点,节点B为备用节点。在节点A出现故障之前,节点A上的SocketServer进程先监听是否有来自于缓存客户端的建立通信连接请求(该建立通信连接请求由运行在缓存客户端上的SocketClient进程发出),如果监听到建立通信连接请求,节点A上的SocketServer进程建立节点A与缓存客户端之间的通信连接。当节点A上的SocketServer进程在与缓存客户端之间的通信连接上监听到一个读数据的操作请求时,节点A上的SocketServer进程通知节点A上的服务进程执行读数据的操作。在节点A出现故障,并且,备用节点B成为当前主节点后,同样的,节点B上的SocketServer进程先监听是否有来自于缓存客户端的建立通信连接请求,如果监听到建立通信连接请求,节点B上的SocketServer进程建立节点B与缓存客户端之间的通信连接。当节点B上的SocketServer进程在与缓存客户端之间的通信连接上监听到一个读数据的操作请求时,节点B上的SocketServer进程通知节点B上的服务进程执行读数据的操作。
当然,除了当前主节点之外,当前主节点的备用节点也可以利用SocketServer技术实现数据的读取。因此,在本发明的另一个优选实施方式中,上述步骤204A进一步包括:
步骤1:利用SocketClient技术将所述读数据的操作请求发送给所述当前主节点的备用节点,以便所述当前主节点的备用节点利用SocketServer技术监听是否有来自于所述当前主节点的读数据的操作请求,如果有,根据所述读数据的操作请求执行读数据操作。
步骤2:接收所述当前主节点的备用节点返回的从所述当前主节点的备用节点中得到的数据。
仍然以上面的场景为例,在节点A出现故障之前,节点A上还运行一个SocketClient进程,节点A上的SocketClient进程向节点B发出建立通信连接请求,节点B上的SocketServer进程监听是否有来自节点A的建立通信连接请求,如果监听到建立通信连接请求,节点B上的SocketServer进程建立节点B与节点A之间的通信连接。通信连接建立后,节点A上的SocketClient进程再向节点B转发缓存客户端的读数据的操作请求,当节点B上的SocketServer进程在与节点A之间的通信连接上监听到一个读数据的操作请求时,节点B上的SocketServer进程通知节点B上的服务进程执行读数据的操作,节点B上的SocketServer进程将操作结果返回给节点A。
当节点A出现故障,节点B成为了当前主节点,并且节点A故障恢复后成为备用节点后,同样的,在节点B上的SocketClient进程向节点A发出建立通信连接请求,节点A上的SocketServer进程监听是否有来自节点B的建立通信连接请求,如果监听到建立通信连接请求,节点A上的SocketServer进程建立节点A与节点B之间的通信连接。通信连接建立后,节点B上的SocketClient进程在向节点A转发缓存客户端的读数据的操作请求,当节点A上的SocketServer进程在与节点B之间的通信连接上监听到一个读数据的操作请求时,节点A上的SocketServer进程将操作结果返回给节点B。
在本发明的另一个优选实施方式中,如图6所示,本实施方式示意的方法还可以包括:
步骤203B:响应于缓存客户端写数据的操作请求,将所述写数据的操作请求针对的数据写入到当前主节点和所述当前主节点的备用节点中。
在本发明的另一个优选实施方式中,上述步骤203B具体为:先将所述写数据的操作请求针对的数据写入到当前主节点中,再将所述写数据的操作请求针对的数据异步写入到所述当前主节点的备用节点中。
可以理解的,在主备双节点的模式下,既要向当前主节点写数据,又要向当前主节点的备用节点写数据,即,写两份数据。可以在向当前主节点写入数据的同时,同步向当前主节点的备用节点写入相应的数据。但是,为了节省当前主节点的***开销,更优选的方式是,分先后顺序写入,即,先向当前主节点写入数据,待写入完毕后,再向当前主节点的备用节点写入相应的数据。
在本发明的一个优选实施方式中,上述步骤203B包括:
步骤1:利用SocketServer技术监听是否有来自于所述缓存客户端的写数据的操作请求,如果有,进入步骤2,否则,返回步骤1。
步骤2:根据所述写数据的操作请求对当前主节点执行写数据操作,并利用SocketClient技术将所述写数据的操作请求发送给当前主节点的备用节点,以便所述当前主节点的备用节点利用SocketServer技术监听是否有来自于所述当前主节点的写数据的操作请求,如果有,根据所述写数据的操作请求对所述当前主节点的备用节点执行写数据操作。
上述步骤1的具体执行过程可以参见步骤2031A的执行过程,上述步骤2的具体执行过程可以参见步骤2041A的执行过程,此处不再赘述。
根据本发明,对memcached缓存***采用主备双节点的结构,即,为每一个作为缓存服务器的主节点建立一个备用节点。先由主节点执行各数据操作,一旦检测到主节点发生故障,就由备用节点作为当前主节点执行各数据操作。因此,即使主节点发生了故障,各应用服务器上的应用层服务也可以获得备用节点的及时响应,从而减少应用层服务出现被拖死的可能性。
示例性设备
在介绍了本发明示例性实施方式的方法之后,接下来,参考图7来描述根据本发明示例性实施方式的、用于缓存***中的故障解决设备。
参考图7,其示意性地示出了根据本发明一个实施方式的缓存***中的故障解决设备的结构框架图,具体地,该设备例如可以包括:
检测模块701,用于利用keepalived技术检测作为缓存服务器的主节点是否发生故障;
主备切换模块702,用于如果所述主节点发生故障,将与所述主节点绑定的虚拟IP地址重新绑定到所述主节点的备用节点上,使得所述备用节点作为当前主节点。
在本发明的一个优选实施方式中,如图8所示,该设备还可以包括:
第一读取模块703A,用于响应于缓存客户端读数据的操作请求,从当前主节点中读取所述读数据的操作请求针对的数据,并将从所述当前主节点读到的数据返回给所述缓存客户端。
在本发明的另一个优选实施方式中,如图9所示,该设备还可以进一步包括:
第二读取模块704A,用于从所述当前主节点的备用节点读取所述读数据的操作请求针对的数据;
更新模块705A,用于将从所述当前主节点读到的数据以及从所述当前主节点的备用根节点读到的对应数据进行比较,如果两者不一致,利用从所述当前主节点读到的数据对所述当前主节点的备用节点中的对应数据进行更新。
在本发明的一个优选实施方式中,如图10所示,该设备也可以包括:
写入模块703B,用于响应于缓存客户端的写数据的操作请求,将所述写数据的操作请求针对的数据写入到当前主节点和所述当前主节点的备用节点中。
在本发明的另一个优选实施方式中,写入模块703B具体用于,先将所述写数据的操作请求针对的数据写入到当前主节点中,再将所述写数据的操作请求针对的数据异步写入到所述当前主节点的备用节点中。
在本发明的一个优选实施方式中,第一读取模块703A包括:
第一监听子模块,用于利用SocketServer技术监听是否有来自于缓存客户端读数据的操作请求;
读操作执行子模块,用于在所述第一监听子模块监听到来自于缓存客户端的读数据的操作请求时,根据所述读数据的操作请求执行读数据操作;
执行结果返回子模块,用于将从所述当前主节点中读到的数据返回给所述缓存客户端。
在本发明的另一个优选的实施方式中,第二读取模块704A包括:
请求发送子模块,用于利用SocketClient技术将所述读数据的操作请求发送给所述当前主节点的备用节点,以便所述当前主节点的备用节点利用SocketServer技术监听是否有来所述当前主节点的读数据的操作请求,如果有,根据所述读数据的操作请求执行读数据操作;
数据接收子模块,用于接收所述当前主节点的备用节点返回的从所述当前主节点的备用节点中读到的数据。
在本发明的另一个优选实施方式中,写入模块703B包括:
第二监听子模块,用于利用SocketServer技术监听是否有来自于所述缓存客户端的写数据的操作请求;
写操作执行子模块,用于在所述第二监听子模块监听到来自于缓存客户端写数据的操作请求时,根据所述写数据的操作请求对当前主节点执行写数据操作,并利用SocketClient技术将所述写数据的操作请求发送给当前主节点的备用节点,以便所述当前主节点的备用节点利用SocketServer技术监听是否有来自于所述当前主节点的写数据的操作请求,如果有,根据所述写数据的操作请求对所述当前主节点的备用节点执行写数据操作。
根据本发明,对memcached缓存***采用主备双节点的结构,即,为每一个作为缓存服务器的主节点建立一个备用节点。先由主节点执行各数据操作,一旦检测到主节点发生故障,就由备用节点作为当前主节点执行各数据操作。因此,即使主节点发生了故障,各应用服务器上的应用层服务也可以获得备用节点的及时响应,从而减少应用层服务出现被拖死的可能性。
应当注意,尽管在上文详细描述中提及了缓存***中的故障解决设备的若干装置,但是这种划分仅仅并非强制性的。实际上,根据本发明的实施方式,上文描述的两个或更多装置的特征和功能可以在一个装置中具体化。反之,上文描述的一个装置的特征和功能可以进一步划分为由多个装置来具体化。
此外,尽管在附图中以特定顺序描述了本发明方法的操作,但是,这并非要求或者暗示必须按照该特定顺序来执行这些操作,或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地,可以省略某些步骤,将多个步骤合并为一个步骤执行,和/或将一个步骤分解为多个步骤执行。
虽然已经参考若干具体实施方式描述了本发明的精神和原理,但是应该理解,本发明并不限于所公开的具体实施方式,对各方面的划分也不意味着这些方面中的特征不能组合以进行受益,这种划分仅是为了表述的方便。本发明旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。
Claims (16)
1.一种方法,包括:
a)、利用keepalived技术检测作为缓存服务器的主节点是否发生故障;
b)、如果所述主节点发生故障,将与所述主节点绑定的虚拟IP地址绑定到所述主节点的备用节点上,使得所述备用节点作为当前主节点。
2.根据权利要求1所述的方法,还包括:
c1)、响应于缓存客户端读数据的操作请求,从当前主节点中读取所述读数据的操作请求针对的数据,并将从所述当前主节点读到的数据返回给所述缓存客户端。
3.根据权利要求2所述的方法,还包括:
d1)、从所述当前主节点的备用节点读取所述读数据的操作请求针对的数据;
e1)、将从所述当前主节点读到的数据以及从所述当前主节点的备用节点读到的对应数据进行比较,如果两者不一致,利用从所述当前主节点读到的数据对所述当前主节点的备用节点中的对应数据进行更新。
4.根据权利要求1所述的方法,还包括:
c2)、响应于缓存客户端写数据的操作请求,将所述写数据的操作请求针对的数据写入到当前主节点和所述当前主节点的备用节点中。
5.根据权利要求4所述的方法,其中,所述步骤c2)具体为:
先将所述写数据的操作请求针对的数据写入到当前主节点中,再将所述写数据的操作请求针对的数据异步写入到所述当前主节点的备用节点中。
6.根据权利要求2或3所述的方法,其中,所述步骤c1)包括:
c11)、利用SocketServer技术监听是否有来自于缓存客户端的读数据的操作请求,如果有,依次进入步骤c12)和c13);
c12)、根据所述读数据的操作请求执行读数据操作;
c13)、将从所述当前主节点中读到的数据返回给所述缓存客户端。
7.根据权利要求6所述的方法,其中,所述步骤d1)包括:
d11)、利用SocketClient技术将所述读数据的操作请求发送给所述当前主节点的备用节点,以便所述当前主节点的备用节点利用SocketServer技术监听是否有来自于所述当前主节点的读数据的操作请求,如果有,根据所述读数据的操作请求执行读数据操作;
d12)、接收所述当前主节点的备用节点返回的从所述当前主节点的备用节点中读到的数据。
8.根据权利要求4所述的方法,其中,所述步骤c2)包括:
c21)、利用SocketServer技术监听是否有来自于所述缓存客户端的写数据的操作请求,如果有,进入步骤c22);
c22)、根据所述写数据的操作请求对当前主节点执行写数据操作,并利用SocketClient技术将所述写数据的操作请求发送给当前主节点的备用节点,以便所述当前主节点的备用节点利用SocketServer技术监听是否有来自于所述当前主节点的写数据的操作请求,如果有,根据所述写数据的操作请求对所述当前主节点的备用节点执行写数据操作。
9.一种设备,包括:
检测模块,用于利用keepalived技术检测作为缓存服务器的主节点是否发生故障;
主备切换模块,用于如果所述主节点发生故障,将与所述主节点绑定的虚拟IP地址重新绑定到所述主节点的备用节点上,使得所述备用节点作为当前主节点。
10.根据权利要求9所述的设备,还包括:
第一读取模块,用于响应于缓存客户端读数据的操作请求,从当前主节点中读取所述读数据的操作请求针对的数据,并将从所述当前主节点读到的数据返回给所述缓存客户端。
11.根据权利要求10所述的设备,还包括:
第二读取模块,用于从所述当前主节点的备用节点读取所述读数据的操作请求针对的数据;
更新模块,用于将从所述当前主节点读到的数据以及从所述当前主节点的备用节点读到的对应数据进行比较,如果两者不一致,利用从所述当前主节点读到的数据对所述当前主节点的备用节点中的对应数据进行更新。
12.根据权利要求9所述的设备,还包括:
写入模块,用于响应于缓存客户端的写数据的操作请求,将所述写数据的操作请求针对的数据写入到当前主节点和所述当前主节点的备用节点中。
13.根据权利要求12所述的设备,其中,所述写入模块具体用于,先将所述写数据的操作请求针对的数据写入到当前主节点中,再将所述写数据的操作请求针对的数据异步写入到所述当前主节点的备用节点中。
14.根据权利要求10或11所述的设备,其中,所述第一读取模块包括:
第一监听子模块,用于利用SocketServer技术监听是否有来自于缓存客户端读数据的操作请求;
读操作执行子模块,用于在所述第一监听子模块监听到来自于缓存客户端的读数据的操作请求时,根据所述读数据的操作请求执行读数据操作;
执行结果返回子模块,用于将从所述当前主节点中读到的数据返回给所述缓存客户端。
15.根据权利要求14所述的设备,其中,所述第二读取模块包括:
请求发送子模块,用于利用SocketClient技术将所述读数据的操作请求发送给所述当前主节点的备用节点,以便所述当前主节点的备用节点利用SocketServer技术监听是否有来所述当前主节点的读数据的操作请求,如果有,根据所述读数据的操作请求执行读数据操作;
数据接收子模块,用于接收所述当前主节点的备用节点返回的从所述当前主节点的备用节点中读到的数据。
16.根据权利要求12所述的设备,其中,所述写入模块包括:
第二监听子模块,用于利用SocketServer技术监听是否有来自于所述缓存客户端的写数据的操作请求;
写操作执行子模块,用于在所述第二监听子模块监听到来自于缓存客户端写数据的操作请求时,根据所述写数据的操作请求对当前主节点执行写数据操作,并利用SocketClient技术将所述写数据的操作请求发送给当前主节点的备用节点,以便所述当前主节点的备用节点利用SocketServer技术监听是否有来自于所述当前主节点的写数据的操作请求,如果有,根据所述写数据的操作请求对所述当前主节点的备用节点执行写数据操作。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410218797.2A CN103973424B (zh) | 2014-05-22 | 2014-05-22 | 缓存***中的故障解决方法和设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410218797.2A CN103973424B (zh) | 2014-05-22 | 2014-05-22 | 缓存***中的故障解决方法和设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103973424A true CN103973424A (zh) | 2014-08-06 |
CN103973424B CN103973424B (zh) | 2017-12-29 |
Family
ID=51242502
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201410218797.2A Active CN103973424B (zh) | 2014-05-22 | 2014-05-22 | 缓存***中的故障解决方法和设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN103973424B (zh) |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104301184A (zh) * | 2014-10-31 | 2015-01-21 | 北京百度网讯科技有限公司 | 链路的健康检查方法和装置 |
CN105515838A (zh) * | 2015-11-26 | 2016-04-20 | 青岛海信传媒网络技术有限公司 | 一种服务配置方法及ha集群*** |
CN106603319A (zh) * | 2017-03-02 | 2017-04-26 | 腾讯科技(深圳)有限公司 | 一种故障处理的方法、管理服务器以及逻辑服务器 |
CN108259239A (zh) * | 2018-01-11 | 2018-07-06 | 郑州云海信息技术有限公司 | 一种数据库高可用性保障方法和*** |
CN109101196A (zh) * | 2018-08-14 | 2018-12-28 | 北京奇虎科技有限公司 | 主节点切换方法、装置、电子设备及计算机存储介质 |
CN109218096A (zh) * | 2018-09-19 | 2019-01-15 | 新智能源***控制有限责任公司 | 一种基于主备冗余的scada实时库访问*** |
CN109474674A (zh) * | 2018-10-26 | 2019-03-15 | 腾讯科技(成都)有限公司 | 内容的传输方法和装置、存储介质、电子装置 |
CN109510867A (zh) * | 2018-10-31 | 2019-03-22 | 恒生电子股份有限公司 | 数据请求处理的方法、装置、存储介质及电子设备 |
CN109634530A (zh) * | 2018-12-14 | 2019-04-16 | 郑州云海信息技术有限公司 | 端口冗余的双控制器nas存储***及实现方法、装置 |
CN113992696A (zh) * | 2020-07-10 | 2022-01-28 | 中国电信股份有限公司 | memcache缓存***、其同步方法及计算机可读存储介质 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102663017A (zh) * | 2012-03-21 | 2012-09-12 | 互动在线(北京)科技有限公司 | 增强MySQL数据库可用性的实现***及实现方法 |
JP2012528382A (ja) * | 2009-05-25 | 2012-11-12 | アリババ・グループ・ホールディング・リミテッド | キャッシュクラスタを構成可能モードで用いるキャッシュデータ処理 |
CN102810111A (zh) * | 2012-05-07 | 2012-12-05 | 互动在线(北京)科技有限公司 | 一种保持Oracle数据库服务高可用的实现方法和*** |
-
2014
- 2014-05-22 CN CN201410218797.2A patent/CN103973424B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012528382A (ja) * | 2009-05-25 | 2012-11-12 | アリババ・グループ・ホールディング・リミテッド | キャッシュクラスタを構成可能モードで用いるキャッシュデータ処理 |
CN102663017A (zh) * | 2012-03-21 | 2012-09-12 | 互动在线(北京)科技有限公司 | 增强MySQL数据库可用性的实现***及实现方法 |
CN102810111A (zh) * | 2012-05-07 | 2012-12-05 | 互动在线(北京)科技有限公司 | 一种保持Oracle数据库服务高可用的实现方法和*** |
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104301184A (zh) * | 2014-10-31 | 2015-01-21 | 北京百度网讯科技有限公司 | 链路的健康检查方法和装置 |
WO2016065700A1 (zh) * | 2014-10-31 | 2016-05-06 | 北京百度网讯科技有限公司 | 链路的健康检查方法和装置 |
KR101770498B1 (ko) | 2014-10-31 | 2017-08-22 | 베이징 바이두 넷컴 사이언스 앤 테크놀로지 코., 엘티디. | 링크의 건전성을 점검하는 방법 및 장치 |
CN104301184B (zh) * | 2014-10-31 | 2017-10-27 | 北京百度网讯科技有限公司 | 链路的健康检查方法和装置 |
US9912560B2 (en) | 2014-10-31 | 2018-03-06 | Beijing Baidu Netcom Science And Technology Co., Ltd. | Method and device for checking health of link |
CN105515838A (zh) * | 2015-11-26 | 2016-04-20 | 青岛海信传媒网络技术有限公司 | 一种服务配置方法及ha集群*** |
CN106603319A (zh) * | 2017-03-02 | 2017-04-26 | 腾讯科技(深圳)有限公司 | 一种故障处理的方法、管理服务器以及逻辑服务器 |
CN108259239A (zh) * | 2018-01-11 | 2018-07-06 | 郑州云海信息技术有限公司 | 一种数据库高可用性保障方法和*** |
CN109101196A (zh) * | 2018-08-14 | 2018-12-28 | 北京奇虎科技有限公司 | 主节点切换方法、装置、电子设备及计算机存储介质 |
CN109218096A (zh) * | 2018-09-19 | 2019-01-15 | 新智能源***控制有限责任公司 | 一种基于主备冗余的scada实时库访问*** |
CN109474674A (zh) * | 2018-10-26 | 2019-03-15 | 腾讯科技(成都)有限公司 | 内容的传输方法和装置、存储介质、电子装置 |
CN109474674B (zh) * | 2018-10-26 | 2021-06-25 | 腾讯科技(成都)有限公司 | 内容的传输方法和装置、存储介质、电子装置 |
CN109510867A (zh) * | 2018-10-31 | 2019-03-22 | 恒生电子股份有限公司 | 数据请求处理的方法、装置、存储介质及电子设备 |
CN109510867B (zh) * | 2018-10-31 | 2021-11-12 | 恒生电子股份有限公司 | 数据请求处理的方法、装置、存储介质及电子设备 |
CN109634530A (zh) * | 2018-12-14 | 2019-04-16 | 郑州云海信息技术有限公司 | 端口冗余的双控制器nas存储***及实现方法、装置 |
CN113992696A (zh) * | 2020-07-10 | 2022-01-28 | 中国电信股份有限公司 | memcache缓存***、其同步方法及计算机可读存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN103973424B (zh) | 2017-12-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103973424A (zh) | 缓存***中的故障解决方法和设备 | |
US9391877B2 (en) | System and method for reducing information loss in an aggregated information handling system | |
CN105024855B (zh) | 分布式集群管理***和方法 | |
CN106254179B (zh) | 一种心跳包异步控制方法及装置 | |
US9049241B2 (en) | Peer discovery and secure communication in failover schemes | |
CN103139157B (zh) | 一种基于socket的网络通信方法、装置及*** | |
CN105933253A (zh) | 一种sdn网络下交换机配置恢复方法 | |
CN103188172A (zh) | 链路聚合的异常恢复方法和交换设备 | |
CN103064761B (zh) | 一种数据同步方法、设备和*** | |
US11924024B2 (en) | Switching method and apparatus, device, and storage medium | |
CN104866528B (zh) | 多平台数据采集方法及*** | |
CN104980307A (zh) | 数据访问请求的处理方法、装置及数据库服务器 | |
CN107688512A (zh) | 一种优化虚拟机数据备份方法和*** | |
CN110401651A (zh) | 一种分布式集群节点监测方法、装置及*** | |
CN107888434B (zh) | 网络设备配置同步方法和装置 | |
CN109245953A (zh) | 一种网络配置方法和装置 | |
CN103179162B (zh) | 一种输出日志的方法及*** | |
CN105490847B (zh) | 一种私有云存储***中节点故障实时检测及处理方法 | |
WO2009006843A1 (fr) | Système de sauvegarde de données, carte de commande principale et procédé de sauvegarde de données | |
CN106231003B (zh) | 一种地址分配方法及装置 | |
CN106230658B (zh) | 一种监控网络设备的方法和装置 | |
CN101355483A (zh) | 一种多网口发送数据包的方法和设备 | |
CN1874310A (zh) | 分布式设备中地址解析协议数据同步的方法 | |
CN105871524B (zh) | 一种基于tipc协议实现双机热备的方法及*** | |
CN110519397B (zh) | 一种基于nginx的sip终端接入的负载均衡***及方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
CB02 | Change of applicant information |
Address after: 100190, Zhongguancun 1 East Road, Beijing, Haidian District Tsinghua Science and Technology Park, building 8, building 21, enlightenment technology building, A Applicant after: NetEase Lede Technology Co., Ltd. Address before: 401, room 4, building 599, 310052 business road, Changhe Road, Binjiang District, Zhejiang, Hangzhou Applicant before: Lede Technology Co., Ltd. |
|
COR | Change of bibliographic data | ||
GR01 | Patent grant | ||
GR01 | Patent grant |