背景技术
Zookeeper是一个分布式协调服务系统,能够为大型分布式计算提供开源的分布式配置、同步服务和命名注册等服务。图1为现有技术中原生Zookeeper系统的实现方案示意图,其中,多个Zookeeper服务器110组成一个服务器集群,为Zookeeper客户端120的数据写入提供数据一致性服务。
Zookeeper服务器110之间使用Zab(Zookeeper Atomic Broadcast,Zookeeper原子广播)协议来保证数据一致性。在实际处理过程中,ZooKeeper服务器集群使用分布式选举算法来选举出Leader节点,其余服务器则成为Follower节点。对于来自ZooKeeper客户端的写请求,一律转发到Leader节点发起投票,当收到半数以上的Follower的确认,即认为数据写入成功,将成功消息返回给客户端。如果超出一定时限,确认的Follower节点还没过半,则写失败。对于读请求,收到请求的ZooKeeper服务器直接向ZooKeeper客户端返回结果。
Leader节点和Follower节点之间定期发送心跳以确认节点存活,如果Follower节点失效,则将其剔除出节点列表,如果Leader节点失效,则Follower节点将发起重新选举。在重新选举的过程中,ZooKeeper服务器集群将无法对外提供服务,直到重新选举出Leader节点。
在实际场景下,重新选举的策略对ZooKeeper服务器集群所在网络稳定性的要求比较高。但是对于部署在云上的服务,网络的波动和偶尔的不稳定是比较常见的,这种网络问题的持续时间也许只是0.5到1秒,但是若导致leader节点短时间失效而引发重新选举,将会使得ZooKeeper服务器集群在较长时间(可能是30~120秒)内不可用,从而放大网络波动造成的不可用时间,这对依赖ZooKeeper进行协作的软件系统来说是难以接受的。
进一步地,ZooKeeper作为一种分布式系统,为了提供一定程度的可用性,即允许一定数量的服务器节点失效,通常需要部署奇数个服务器节点,比如部署3个服务器节点时允许一个节点失效,部署5个服务器节点时允许2个服务器节点失效,这些服务器节点分别部署在不同的机房,则对应地能在某个机房失效时让ZooKeeper服务器集群依旧可用。但是这个部署策略和常见的双机房容灾冲突,在双机房部署时,无论如何都难以合理部署奇数个数的ZooKeeper节点,因为其中一个机房必定部署了查过半数的服务器节点,一旦这个机房失效,整个ZooKeeper服务器集群都不可用。
申请内容
本申请的一个目的是提供一种适用于Zookeeper的兼容通信方案,用以解决现有技术中Zookeeper服务器集群在应对网络波动时可用性较差的问题。
为实现上述目的,本申请提供了一种Zookeeper兼容通信方法,该方法包括:
获取Zookeeper请求;
根据所述Zookeeper请求生成数据库请求,并向数据库发送所述数据库请求;
接收所述数据库根据所述数据库请求发送的数据库应答;
根据所述数据库应答生成与所述Zookeeper请求对应的Zookeeper应答,反馈所述Zookeeper应答。
进一步地,所述Zookeeper请求包括Zookeeper写请求;
所述方法包括:
获取Zookeeper写请求;
根据所述Zookeeper写请求生成数据库事务请求,并向数据库发送所述数据库事务请求;
接收所述数据库根据所述数据库事务请求发送的数据库事务应答;
根据所述数据库事务应答生成与所述Zookeeper写请求对应的Zookeeper写应答,反馈所述Zookeeper写应答。
进一步地,根据所述Zookeeper写请求生成数据库事务请求之前,还包括:
获取已注册的监视器;
接收所述数据库根据所述数据库事务请求发送的数据库事务应答之后,还包括:
触发已注册的监视器,以反馈所述Zookeeper写请求对应的数据变更的通知。
进一步地,所述Zookeeper请求包括Zookeeper读请求;
所述方法包括:
获取Zookeeper读请求;
根据所述Zookeeper读请求生成数据库读请求,并向数据库发送所述数据库读请求;
接收所述数据库根据所述数据库读请求发送的数据库读应答;
根据所述数据库读应答生成与所述Zookeeper读请求对应的Zookeeper读应答,反馈Zookeeper读应答。
进一步地,获取Zookeeper请求,包括:
建立长连接,通过所述长连接取Zookeeper请求;
反馈所述Zookeeper应答,包括:
通过所述长连接反馈所述Zookeeper应答。
进一步地,所述数据库为关系数据库。
基于本申请的另一方面,还提供了一种Zookeeper兼容通信服务器,该服务器包括:
Zookeeper接口装置,用于获取Zookeeper请求,以及反馈Zookeeper应答;
数据库接口装置,用于向数据库发送数据库请求,以及接收所述数据库根据所述数据库请求发送的数据库应答;
内部处理装置,用于根据所述Zookeeper请求生成所述数据库请求,以及根据所述数据库应答生成与所述Zookeeper请求对应的Zookeeper应答。
进一步地,所述Zookeeper请求包括Zookeeper写请求;
所述Zookeeper接口装置,用于获取Zookeeper写请求,以及反馈Zookeeper写应答;
所述数据库接口装置,用于向数据库发送数据库事务请求,以及接收所述数据库根据所述数据库事务请求发送的数据库事务应答;
所述内部处理装置,用于根据所述Zookeeper写请求生成所述数据库事务请求,以及根据所述数据库事务应答生成与所述Zookeeper写请求对应的Zookeeper写应答。
进一步地,所述Zookeeper接口装置,还用于在根据所述Zookeeper写请求生成数据库事务请求之前,获取已注册的监视器;以及在接收所述数据库根据所述数据库事务请求发送的数据库事务应答之后,触发所述已注册的监视器,以反馈所述Zookeeper写请求对应的数据变更的通知。
进一步地,所述Zookeeper请求包括Zookeeper读请求;
Zookeeper接口装置,用于获取Zookeeper读请求,以及反馈Zookeeper读应答;
数据库接口装置,用于向数据库发送数据库读请求,以及接收所述数据库根据所述数据库读请求发送的数据库读应答;
内部处理装置,用于根据所述Zookeeper读请求生成所述数据库读请求,以及根据所述数据库读应答生成与所述Zookeeper读请求对应的Zookeeper读应答。
进一步地,Zookeeper接口装置,用于建立长连接,通过所述长连接获取Zookeeper请求,以及通过所述长连接反馈所述Zookeeper应答
进一步地,所述数据库为关系数据库。
此外,本申请还提供了一种Zookeeper兼容通信服务器,该服务器包括:
处理器;以及
被安排成存储计算机可执行指令的存储器,所述可执行指令在被执行时使所述处理器:获取Zookeeper请求;根据所述Zookeeper请求生成数据库请求,并向数据库发送所述数据库请求;接收所述数据库根据所述数据库请求发送的数据库应答;根据所述数据库应答生成与所述Zookeeper请求对应的Zookeeper应答,反馈所述Zookeeper应答。
本申请还提供了一种Zookeeper兼容通信系统,所述系统包括多个服务器,每个服务器用于获取Zookeeper请求;根据所述Zookeeper请求生成数据库请求,并向数据库发送所述数据库请求;接收所述数据库根据所述数据库请求发送的数据库应答;根据所述数据库应答生成与所述Zookeeper请求对应的Zookeeper应答,反馈所述Zookeeper应答。
与现有技术相比,本申请提供了一种Zookeeper的兼容通信方案,该方案不使用Zab协议来确保数据写入的一致性,在处理Zookeeper请求时,无需区分Leader节点和Follower节点,任意服务器节点均都可以对收到的Zookeeper请求进行处理,直接获取Zookeeper请求,将其转化为数据库请求,然后将收到的数据库应答转换为Zookeeper应答,并反馈。因此,当任意一个服务器因网络波动而短时间失效时,无需进行选举,相应的Zookeeper客户端可以等待网络恢复或者向其它可用服务器节点发送请求,来实现数据写入或者读取。由此,本申请的方案不会放大网络波动造成的不可用时间,可用性较高。
具体实施方式
下面结合附图对本申请作进一步详细描述。
在本申请一个典型的配置中,终端、服务网络的设备均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体,可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。
本申请实施例提供的一种Zookeeper兼容通信系统,所述系统包括多个服务器210,用于为来自Zookeeper客户端120的数据请求提供协调服务,可理解为位于Zookeeper客户端与数据库之间的兼容层。所述Zookeeper客户端120部署于应用服务器140,所述应用服务器140的数据请求均通过Zookeeper客户端120交由Zookeeper兼容通信系统中的各个服务器210来进行协调处理,由服务器转发数据库130对数据进行操作。图2示出了所述Zookeeper兼容通信系统的交互示意图,为简明起见,图中示出的各类元素的数量可能小于实际场景中相应元素的数量,但这种省略无疑地是以不会影响对本发明进行清楚、充分的公开为前提的。
在所述Zookeeper兼容通信系统中各个服务器之间不使用Zab协议来确保数据写入的一致性,在处理来自Zookeeper客户端的Zookeeper请求时,无需区分Leader节点和Follower节点,任意服务器节点均都可以对收到的Zookeeper请求进行处理。具体地,各个服务器所实现的Zookeeper兼容通信方法,包括以下处理步骤:
步骤S101,服务器获取Zookeeper请求。在本实施例中,所述Zookeeper请求可以来自Zookeeper客户端,所述服务器可以提供与原生Zookeeper系统中Zookeeper服务器相同的API(Application Program Interface,应用程序接口)实现与Zookeeper客户端数据交互,即Zookeeper客户端可以采用与原来相同的Zookeeper请求,无需改变Zookeeper请求格式、内容等。由此,能够较好的兼容普通的Zookeeper客户端,使得本申请实施例提供的Zookeeper兼容通信系统能够实现与原生Zookeeper系统相同的功能。
步骤S102,服务器根据所述Zookeeper请求生成数据库请求,并向数据库发送所述数据库请求。根据不同的数据库,解析Zookeeper请求中的内容,根据Zookeeper请求中的内容,生成适应于特定数据库的数据库请求,以实现数据读、写等操作。数据库在收到相应的数据库请求之后,能够据此进行处理,向所述服务器返回数据库应答。
步骤S103,服务器接收所述数据库根据所述数据库请求发送的数据库应答。所述数据库的应答即为Zookeeper请求中需要对数据库进行的数据操作的结果,例如对于Zookeeper读请求,此时返回的结果可能是读取成功的信息和相应的数据内容,或者是读取失败的信息;对于Zookeeper写请求,则可能写入成功或者写入失败的信息。
步骤S104,根据所述数据库应答生成与所述Zookeeper请求对应的Zookeeper应答,并反馈所述Zookeeper应答。对于来自Zookeeper客户端的Zookeeper请求,则向所述Zookeeper客户端反馈所述Zookeeper应答。在本步骤中,生成的Zookeeper应答中的实质内容根据数据库的应答中的内容相同,即为Zookeeper请求中需要对数据库进行的数据操作的结果,为了便于Zookeeper客户端接收该信息,因此需要转换为特定格式的Zookeeper应答。
由于Zookeeper兼容通信系统中每个服务器均可以实现上述处理,因此当任意一个服务器失效时,无需进行选举,相应的Zookeeper客户端可以等待网络恢复或者向其它可用服务器节点发送请求,来实现数据写入或者读取。由此,本申请的方案不会放大网络波动造成的不可用时间,可用性较高。并且在极端情况下,只要有一个服务器可用,则Zookeeper兼容通信系统仍可以为Zookeeper客户端提供服务。此外,由于各个服务器之间无需相互通信,因此,便于所述Zookeeper兼容通信系统的水平扩容,能够方便地部署更多的服务器,以支持更多的Zookeeper客户端连接。
在实际场景中,Zookeeper客户端所发出的Zookeeper请求一般包括Zookeeper写请求和Zookeeper读请求。其中,对于Zookeeper写请求,在整个处理过程中,Zookeeper客户端、Zookeeper兼容通信系统的服务器以及数据库之间的交互过程如图3所示,包括:
步骤S301,Zookeeper客户端向服务器发起Zookeeper写请求。
步骤S302,服务器收到Zookeeper客户端发出的Zookeeper写请求。
步骤S303,服务器根据所述Zookeeper写请求生成数据库事务请求。由于写请求需要对数据库中的数据进行增加、修改、删除等操作,会导致数据库中的数据发生变化。而在实际场景中,可能存在如下的情况,即多个Zookeeper客户端短时间内对一个数据进行修改,此时将Zookeeper写请求转换为数据库事务请求,利用数据库事务来保证数据修改的一致性,即根据数据库事务请求的先后,依次进行处理。
步骤S304,服务器向数据库发送数据库事务请求。
步骤S305,数据库根据收到的数据库事务请求进行相应的处理,并根据事务处理的结果向服务器返回数据库事务应答。以短时间内对账户A的余额进行操作的写请求为例,假设账户A当余额为200,Zookeeper客户端C1的在先请求1为提取300,Zookeeper客户端C2在后请求2为存储200,由此分别转换为相应的数据库事务请求后,对于请求1由于账户A的余额不足,无法进行操作,因此事务的处理结果为提取失败,在提交请求1对应的事务之后再处理请求2对应的事务。若在完成请求2对应的事务之后,Zookeeper客户端C1再次发送了提取300的请求3,此时由于账户余额大于300,则其对应事务的处理结果为提取成功,此时余额变更为100。
步骤S306,服务器收到数据库事务应答。
步骤S307,服务器根据所述数据库事务应答生成与所述Zookeeper写请求对应的Zookeeper写应答。
步骤S308,服务器向所述Zookeeper客户端发送所述Zookeeper写应答。
步骤S309,Zookeeper客户端收到Zookeeper写应答,从而完成整个处理过程。
在整个处理过程中,服务器可以根据请求的处理结果,更新相应事务提交记录、数据变更记录等,例如以日志的形式记录,以便于通过备份这些日志进行数据的同步。
此外,为更好的兼容现有的Zookeeeper客户端,本申请实施例提供的兼容通信方法还可以进一步实现Zookeeper中的watch机制,在处理Zookeeeper写请求的过程中,更新监视器(Watcher)通知状态,即获取以及触发对应Zookeeeper客户端的监视器。具体地,关于监视器的处理如图4所示,即服务器在执行步骤S303,根据所述Zookeeper写请求生成数据库事务请求之前,还会获取所述Zookeeper客户端注册的监视器。
作为一种可行的实施方式,所述Zookeeper客户端在向服务器发起Zookeeper请求之前,会与服务器建立长连接,服务器从Zookeeper客户端获取Zookeeper请求以及向所述Zookeeper客户端发送所述Zookeeper应答均会通过所述长连接进行交互。在处理zookeeper请求的过程中,服务器和Zookeeper客户端之间会维持该长连接,因此,通过服务器该长连接可以获知当前通信的Zookeeper客户端的唯一标识,通过记录这些Zookeeper客户端的唯一标识,对每个客户端所注册的监视器进行标记,确定当前有哪些Zookeeper客户端注册了监视器。
相应地,服务器在执行步骤S303,收到数据库事务应答之后,还触发所述Zookeeper客户端注册的监视器,以向所述Zookeeper客户端发送所述Zookeeper写请求对应的数据变更的通知。在实际场景中,监视器的触发条件一般是在写请求所处理的数据发生变更时,即服务器获取到数据库事务应答后。具体地,服务器可以采用轮询策略,定期查看Zookeeper客户端注册的监视器是否处于可以触发的状态,当满足触发条件就可以触发监视器,以向所述Zookeeper客户端发送所述Zookeeper写请求对应的数据变更的通知。此后,可以进入休眠状态,等待下次Zookeeper客户端注册新的监视器。
对于Zookeeper读请求,Zookeeper客户端、Zookeeper兼容通信系统的服务器以及数据库之间的交互过程如图5所示,包括:
步骤S501,Zookeeper客户端向服务器发起Zookeeper读请求。
步骤S502,服务器收到Zookeeper客户端发出的Zookeeper读请求。
步骤S503,服务器根据所述Zookeeper读请求生成数据库读请求。由于读请求无需对数据库中的数据进行增加、修改、删除等操作,不会导致数据库中的数据发生变化,因此无需涉及数据库事务的处理。
步骤S504,服务器向数据库发送数据库读请求。
步骤S505,数据库根据收到的数据库读请求进行相应的处理,并根据读处理的结果向服务器返回数据库读应答。
步骤S506,服务器收到数据库读应答。
步骤S507,服务器根据所述数据库读应答生成与所述Zookeeper读请求对应的Zookeeper读应答。
步骤S508,服务器向所述Zookeeper客户端发送所述Zookeeper读应答。
步骤S509,Zookeeper客户端收到Zookeeper读应答,从而完成整个处理过程。
进一步地,由于关系数据库在写入数据时,能够严格实现数据库的事务特定,相对于非关系数据库,能够更加可靠地保证数据一致性。由此,本申请实施例提供的方法中所涉及的数据库可以采用关系数据库,具体实现时,可以采用MySQL、SQL Server、PostgreSQL等数据库,或者RDS(Relational Database Service,关系数据库服务)等可以实现上述数据库功能的在线数据库服务。
为了提高数据库的可用性,本实施例所采用的关系数据库可以采用高可用(HA,High Availably)的主备节点部署方式,主节点向备节点复制数据,主备节点之间使用keepalived做VIP(虚拟IP)漂移,如果主节点失效,则将VIP漂移至备节点,实现主备切换,使得备节点能够继续提供数据库服务。
基于同一发明构思,本申请实施例中还提供了Zookeeper兼容通信服务器,该服务器对应的方法是前述实施例中的Zookeeper兼容通信方法,并且其解决问题的原理与所述方法相似。
具体地,本申请实施例提供的所述Zookeeper兼容通信服务器的结构如图6所示,包括Zookeeper接口装置610、数据库接口装置620和内部处理装置630。其中,所述Zookeeper接口装置610用于从Zookeeper客户端获取Zookeeper请求,以及向所述Zookeeper客户端发送Zookeeper应答。所述数据库接口装置620用于向数据库设备发送数据库请求,以及接收所述数据库设备根据所述数据库请求发送的数据库应答。内部处理装置630用于根据所述Zookeeper请求生成所述数据库请求,以及根据所述数据库应答生成与所述Zookeeper请求对应的Zookeeper应答。
在本实施例中,所述服务器可以提供与原生Zookeeper系统中Zookeeper服务器相同的API(Application Program Interface,应用程序接口)实现与Zookeeper客户端数据交互,即Zookeeper客户端可以采用与原来相同的Zookeeper请求,无需改变Zookeeper请求格式、内容等。由此,能够较好的兼容普通的Zookeeper客户端,使得本申请实施例提供的Zookeeper兼容通信系统能够实现与原生Zookeeper系统相同的功能。
根据不同的数据库,解析Zookeeper请求中的内容,根据Zookeeper请求中的内容,生成适应于特定数据库的数据库请求,以实现数据读、写等操作。数据库在收到相应的数据库请求之后,能够据此进行处理,向所述服务器返回数据库应答。
所述数据库的应答即为Zookeeper请求中需要对数据库进行的数据操作的结果,例如对于Zookeeper读请求,此时返回的结果可能是读取成功的信息和相应的数据内容,或者是读取失败的信息;对于Zookeeper写请求,则可能写入成功或者写入失败的信息。
Zookeeper接口装置生成的Zookeeper应答中的实质内容根据数据库的应答中的内容相同,即为Zookeeper请求中需要对数据库进行的数据操作的结果,为了便于Zookeeper客户端接收该信息,因此需要转换为特定格式的Zookeeper应答。
由于Zookeeper兼容通信系统中每个服务器均可以实现上述处理,因此当任意一个服务器失效时,无需进行选举,相应的Zookeeper客户端可以等待网络恢复或者向其它可用服务器节点发送请求,来实现数据写入或者读取。由此,本申请的方案不会放大网络波动造成的不可用时间,可用性较高。并且在极端情况下,只要有一个服务器可用,则Zookeeper兼容通信系统仍可以为Zookeeper客户端提供服务。此外,由于各个服务器之间无需相互通信,因此,便于所述Zookeeper兼容通信系统的水平扩容,能够方便地部署更多的服务器,以支持更多的Zookeeper客户端连接。
在实际场景中,Zookeeper客户端所发出的Zookeeper请求一般包括Zookeeper写请求和Zookeeper读请求。其中,对于Zookeeper写请求,在整个处理过程中,Zookeeper客户端、Zookeeper兼容通信系统的服务器以及数据库之间的交互过程如图3所示,包括:
步骤S301,Zookeeper客户端向服务器发起Zookeeper写请求。
步骤S302,服务器的Zookeeper接口装置收到Zookeeper客户端发出的Zookeeper写请求。
步骤S303,服务器的内部处理装置根据所述Zookeeper写请求生成数据库事务请求。由于写请求需要对数据库中的数据进行增加、修改、删除等操作,会导致数据库中的数据发生变化。而在实际场景中,可能存在如下的情况,即多个Zookeeper客户端短时间内对一个数据进行修改,此时将Zookeeper写请求转换为数据库事务请求,利用数据库事务来保证数据修改的一致性,即根据数据库事务请求的先后,依次进行处理。
步骤S304,服务器的数据库接口装置向数据库发送数据库事务请求。
步骤S305,数据库根据收到的数据库事务请求进行相应的处理,并根据事务处理的结果向服务器返回数据库事务应答。以短时间内对账户A的余额进行操作的写请求为例,假设账户A当余额为200,Zookeeper客户端C1的在先请求1为提取300,Zookeeper客户端C2在后请求2为存储200,由此分别转换为相应的数据库事务请求后,对于请求1由于账户A的余额不足,无法进行操作,因此事务的处理结果为提取失败,在提交请求1对应的事务之后再处理请求2对应的事务。若在完成请求2对应的事务之后,Zookeeper客户端C1再次发送了提取300的请求3,此时由于账户余额大于300,则其对应事务的处理结果为提取成功,此时余额变更为100。
步骤S306,服务器的数据库接口装置收到数据库事务应答。
步骤S307,服务器的内部处理装置根据所述数据库事务应答生成与所述Zookeeper写请求对应的Zookeeper写应答。
步骤S308,服务器的Zookeeper接口装置向所述Zookeeper客户端发送所述Zookeeper写应答。
步骤S309,Zookeeper客户端收到Zookeeper写应答,从而完成整个处理过程。
在整个处理过程中,服务器可以根据请求的处理结果,更新相应事务提交记录、数据变更记录等,例如以日志的形式记录,以便于通过备份这些日志进行数据的同步。
此外,为更好的兼容现有的Zookeeeper客户端,本申请实施例提供的服务器还可以进一步实现Zookeeper中的watch机制,在处理Zookeeeper写请求的过程中,更新监视器(Watcher)通知状态,即获取以及触发对应Zookeeeper客户端的监视器。具体地,关于监视器的处理如图4所示,即服务器的Zookeeper接口装置在根据所述Zookeeper写请求生成数据库事务请求之前,还会获取所述Zookeeper客户端注册的监视器。
作为一种可行的实施方式,所述Zookeeper客户端的Zookeeper接口装置在向服务器发起Zookeeper请求之前,会与服务器建立长连接,服务器从Zookeeper客户端获取Zookeeper请求以及向所述Zookeeper客户端发送所述Zookeeper应答均会通过所述长连接进行交互。在处理zookeeper请求的过程中,服务器和Zookeeper客户端之间会维持该长连接,因此,通过服务器该长连接可以获知当前通信的Zookeeper客户端的唯一标识,通过记录这些Zookeeper客户端的唯一标识,对每个客户端所注册的监视器进行标记,确定当前有哪些Zookeeper客户端注册了监视器。
相应地,服务器的Zookeeper接口装置在收到数据库事务应答之后,还触发所述Zookeeper客户端注册的监视器,以向所述Zookeeper客户端发送所述Zookeeper写请求对应的数据变更的通知。在实际场景中,监视器的触发条件一般是在写请求所处理的数据发生变更时,即服务器获取到数据库事务应答后。具体地,服务器可以采用轮询策略,定期查看Zookeeper客户端注册的监视器是否处于可以触发的状态,当满足触发条件就可以触发监视器,以向所述Zookeeper客户端发送所述Zookeeper写请求对应的数据变更的通知。
对于Zookeeper读请求,Zookeeper客户端、Zookeeper兼容通信系统的服务器以及数据库之间的交互过程如图5所示,包括:
步骤S501,Zookeeper客户端向服务器发起Zookeeper读请求。
步骤S502,服务器的Zookeeper接口装置收到Zookeeper客户端发出的Zookeeper读请求。
步骤S503,服务器的内部处理装置根据所述Zookeeper读请求生成数据库读请求。由于读请求无需对数据库中的数据进行增加、修改、删除等操作,不会导致数据库中的数据发生变化,因此无需涉及数据库事务的处理。
步骤S504,服务器的数据库接口装置向数据库发送数据库读请求。
步骤S505,数据库根据收到的数据库读请求进行相应的处理,并根据读处理的结果向服务器返回数据库读应答。
步骤S506,服务器的数据库接口装置收到数据库读应答。
步骤S507,服务器的内部处理装置根据所述数据库读应答生成与所述Zookeeper读请求对应的Zookeeper读应答。
步骤S508,服务器的Zookeeper接口装置向所述Zookeeper客户端发送所述Zookeeper读应答。
步骤S509,Zookeeper客户端收到Zookeeper读应答,从而完成整个处理过程。
进一步地,由于关系数据库在写入数据时,能够严格实现数据库的事务特定,相对于非关系数据库,能够更加可靠地保证数据一致性。由此,为本申请实施例中的服务器提供存储的数据库可以采用关系数据库,具体实现时,可以采用MySQL、SQL Server、PostgreSQL等数据库,或者RDS(Relational Database Service,关系数据库服务)等可以实现上述数据库功能的在线数据库服务。
为了提高数据库的可用性,本实施例所采用的关系数据库可以采用高可用的主备节点部署方式,主节点向备节点复制数据,主备节点之间使用keepalived做VIP(虚拟IP)漂移,如果主节点失效,则将VIP漂移至备节点,实现主备切换,使得备节点能够继续提供数据库服务。
作为另一种可行的实施方式,本申请实施例还提供了另一种Zookeeper兼容通信服务器,该服务器包括:
处理器;以及
被安排成存储计算机可执行指令的存储器,所述可执行指令在被执行时使所述处理器:从Zookeeper客户端获取Zookeeper请求;根据所述Zookeeper请求生成数据库请求,并向数据库设备发送所述数据库请求;接收所述数据库设备根据所述数据库请求发送的数据库应答;根据所述数据库应答生成与所述Zookeeper请求对应的Zookeeper应答,并向所述Zookeeper客户端发送所述Zookeeper应答。
综上所述,在所述Zookeeper兼容通信系统中各个服务器之间不使用Zab协议来确保数据写入的一致性,在处理来自Zookeeper客户端的Zookeeper请求时,无需区分Leader节点和Follower节点,任意服务器节点均都可以对收到的Zookeeper请求进行处理。当任意一个服务器失效时,无需进行选举,相应的Zookeeper客户端可以等待网络恢复或者向其它可用服务器节点发送请求,来实现数据写入或者读取。由此,本申请的方案不会放大网络波动造成的不可用时间,可用性较高。并且在极端情况下,只要有一个服务器可用,则Zookeeper兼容通信系统仍可以为Zookeeper客户端提供服务。
此外,本申请的方案可以采用关系数据库作为底层的数据库,由于关系数据库在写入数据时,能够严格实现数据库的事务特定,相对于非关系数据库,能够更加可靠地保证数据一致性。
需要注意的是,本申请可在软件和/或软件与硬件的组合体中被实施,例如,可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中,本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地,本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中,例如,RAM存储器,磁或光驱动器或软磁盘及类似设备。另外,本申请的一些步骤或功能可采用硬件来实现,例如,作为与处理器配合从而执行各个步骤或功能的电路。
另外,本申请的一部分可被应用为计算机程序产品,例如计算机程序指令,当其被计算机执行时,通过该计算机的操作,可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令,可能被存储在固定的或可移动的记录介质中,和/或通过广播或其他信号承载媒体中的数据流而被传输,和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此,根据本申请的一个实施例包括一个装置,该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器,其中,当该计算机程序指令被该处理器执行时,触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。
对于本领域技术人员而言,显然本申请不限于上述示范性实施例的细节,而且在不背离本申请的精神或基本特征的情况下,能够以其他的具体形式实现本申请。因此,无论从哪一点来看,均应将实施例看作是示范性的,而且是非限制性的,本申请的范围由所附权利要求而不是上述说明限定,因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外,显然“包括”一词不排除其他单元或步骤,单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。