[发明专利]Zookeeper兼容通信方法、服务器及系统

说明书

本申请的目的是提供一种Zookeeper的兼容通信方案，该方案不使用Zab协议来确保数据写入的一致性，在处理Zookeeper请求时，无需区分Leader节点和Follower节点，任意服务器节点均都可以对收到的Zookeeper请求进行处理，直接获取Zookeeper请求，将其转化为数据库请求，然后将收到的数据库应答转换为Zookeeper应答，并反馈。因此，当任意一个服务器因网络波动而短时间失效时，无需进行选举，相应的Zookeeper客户端可以等待网络恢复或者向其它可用服务器节点发送请求，来实现数据写入或者读取。由此，本申请的方案不会放大网络波动造成的不可用时间，可用性较高。

技术领域

本申请涉及信息技术领域，尤其涉及一种适用于Zookeeper的兼容通信方案。

背景技术

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请求生成数据库请求，并向数据库发送所述数据库请求；

接收所述数据库根据所述数据库请求发送的数据库应答；