rqlite 6.0:分布式数据库设计的演变

rqlite是一个轻量级的、开源的、用Go编写的分布式关系数据库,它使用SQLite作为其存储引擎。6.0.0版本已经发布使集群更加强大。它还为更多的重要功能奠定了基础。

6.0有什么新内容?

6.0使用现有的Raft节点间TCP连接,在rqlite节点间复用了多个逻辑连接。这种多路复用存在于早期版本中,后来被删除,但现在以一种更复杂、更强大的方式重新引入。

这个新的逻辑连接允许追随者以更强大和无状态的方式找到领导者,当提供需要客户端联系领导者的查询时。它还在这个逻辑连接上使用了协议缓冲区,导致了更强大、可扩展的代码。

rqlite集群中的节点间通信已经发展很多年,看看这3种设计模式的背景是很有意思的。在这种情况下,我所说的节点间通信是什么意思?我指的是在集群节点之间传输rqlite本身特有的信息,但不是Hashicorp代码之间的Raft特有通信

首先要理解的是,每个rqlite节点都暴露了两个网络接口--第一,一个由Hashicorp Raft系统管理的Raft网络地址,第二,一个HTTP API,客户用它来查询SQLite数据库。从客户的角度来看,Raft网络地址是一个实现细节,它只是为了实现集群功能。

由于Hashicorp Raft的实现,每个节点都知道其他节点的Raft网络地址,而每个rqlite节点也必须了解Leader的HTTP URL_,所以_它可以告知客户端代码在哪里重定和查询。由于领导者可以改变,甚至被完全取代,每个rqlite节点必须随时拥有关于领导者HTTP URL的最新信息。

核心的挑战是,这些关于HTTP URL的信息不是Hashicorp Raft内在处理的,因为Raft层只知道Raft网络地址。HTTP URLs是rqlite的概念,而不是Raft的概念。

因此,如果服务客户的请求需要与领导者联系,就需要rqlite代码来处理将客户重定向到领导者的HTTP URL(不是所有的查询都涉及领导者,但大多数都涉及)。

如何做到这一点已经随着时间的推移而演变。

模式1:客户必须搜索领导者

上图是一个3节点的rqlite集群。在rqlite 2.x中,如果客户联系一个跟随者,跟随者返回的信息客户可以用来找到领导者,但客户可能需要联系过程中的其他每个节点来确定哪个是领导者。

在3.x版本之前,如果请求的操作只能由领导者提供,rqlite节点会将领导者的Raft网络地址返回给客户端(假设该节点本身不是领导者)。这迫使客户端检查所有其他集群节点,看哪个节点有相关的Raft地址,然后将查询本身重定向到该节点的HTTP API URL。

虽然这意味着rqlite的代码比后来的版本要简单得多,但这种方法只有在客户端知道rqlite集群中的每个节点,或者总是知道哪个节点是Leader的情况下才有效。这不是很实用,尤其是当集群中的节点发生变化或失效时。没有可靠的、简单的方法可以让客户端代码知道这些变化,所以客户端可以有效地与集群失去联系。

模式2:节点通过Raft共识沟通HTTP API URLs

在3.x、4.x和5.x中,rqlite节点使用Raft共识将Raft网络地址映射到HTTP API URLs,对于每个节点都是如此。如果客户端联系追随者,追随者知道领导者的HTTP URL(通过Raft共识更新和管理的映射),并将其返回给客户端。这通常是有效的,但从长远来看,这个实现并不健全。

到了3.0版本,很明显rqlite Follower节点需要返回适当的HTTP重定向。但问题是_Follower节点如何_在_任何时候_都_知道Leader的HTTP URL_,而不考虑集群发生的任何变化?

3.x、4.x和5.x版本使用Raft共识系统本身来广播这一信息。当一个节点加入集群时,它将向Raft日志提交一个更改,更新将Raft网络地址映射到HTTP API URL的配置。由于Raft共识系统,每个节点都知道其他每个节点的Raft网络地址,所以理论上,每个节点都可以通过这种映射了解其他每个节点的HTTP API URL。因此,每个节点都知道领导者的HTTP API URL,甚至在领导者变更时也是如此。

这种设计在很长一段时间内运行良好,但也有一些不足之处。一个可能的问题是,如果一个节点加入了集群,但却没有更新它的HTTP API URL映射(无论什么原因)该怎么办?这有可能发生,因为这是对Raft系统的两个不同的变化,但可能性很小。但如果发生了,集群可能需要大量的人工干预才能恢复。

随着时间的推移,其他的错误被发现,这表明当集群成员定期改变时,这种方法并不健全。这种设计还要求操作者明确地从集群配置中删除失败的节点,否则Raft地址到HTTP-URL的映射就会变得陈旧。最终,这种设计意味着除了SQLite数据库外,还需要通过Raft存储额外的状态。而更多的状态意味着有更多的机会出现错误。

因此,虽然这种方法在3.x、4.x和5.x版本中多年来运作良好,但到了6.0版本,已经发现了一种更好的方法。因此,与其说是修复错误,不如说是重新设计。

模式3:追随者按要求查询领导者

在6.x版本中,如果客户端联系追随者,追随者将根据需求查询领导者的HTTP URL,并将其返回给客户端,然后客户端将直接联系领导者。这种设计是无状态的,而且不涉及Raft共识。

在6.0版本中,当追随者需要了解领导者的HTTP API时,它可以按需联系领导者。关键是,它通过Raft TCP连接与领导者联系,无论如何,这个连接必须始终存在--没有这个连接,节点就不是集群的一部分,而集群有更大的问题。因此,这种新的设计并没有引入任何新的故障模式,尽管它确实引入了一个额外的网络跳。

这种类型的设计也是无状态的,即使联系Leader以了解其HTTP API URL失败了,这种失败也是在查询时发生的--这意味着客户可以被告知,客户可以决定如何处理。最有可能的是,如果错误是暂时性的,客户端可以简单地重试请求。

你可以在CHANGELOG中找到关于6.0设计的进一步细节。

未来的版本中会有什么?

这种新的设计和实现使得实现以下即将到来的功能更加简单。

连接池

6.0确实导致了节点之间更多的网络流量,如果一个追随者被不断地查询。这并不是大量的网络流量,但节点之间的连接池将有助于减少连接建立时间。

透明的请求转发

今天,如果一个rqlite_Follower_收到一个必须由_Leader_服务的请求,它将返回HTTP 301。现在,有了更复杂的节点间通信机制,未来的版本将允许Follower节点代表客户端直接查询Leader,并将结果直接返回给客户端。这将使CLI的使用和客户端库的编码更简单,并使集群更容易工作--允许rqlite更透明地提供查询。

更好的Kubernetes支持

在6.0的开发过程中,我从Sosivio的团队那里得到了一些很大的帮助。他们发现了5.x系列中的一些bug,并提供了关于如何改变rqlite以便在Kubernetes上更好地工作的最佳实践建议。这些改变可能会在未来的版本中出现。

接下来的步骤

下载6.0版本,并尝试更强大的集群--并关注未来版本的新功能。

原文链接:www.philipotoole.com/rqlite-6-0-…