分布式Redis集群解决方案

最新推荐文章于 2024-10-10 19:18:07 发布

郑梦佳

最新推荐文章于 2024-10-10 19:18:07 发布

阅读量9.1k

点赞数

分类专栏： linux

linux 专栏收录该内容

14 篇文章 0 订阅

订阅专栏

RebirnDB

QDB是很棒的，我们能够在一个机器上存储巨大的数据，并且获得较好的读写性能，但是随着数据集的增长，我们仍然会面临这样的问题，即：我们不能将所有数据都保存在一个机器上。同时，QDB服务器将变成一个瓶颈并且面临单点失败的风险。

现在我们必须要考虑集群解决方案了。

介绍

RebornDB是一个基于代理的分布式Redis集群解决方案。它有点像twemproxy，一个几乎是最早的、最著名的基于代理的Redis集群解决方案。

但是twemproxy有它自己的问题，它仅仅支持静态的集群拓扑，因此我们不能动态的添加或者删除redis节点来重新切分数据。如果我们运行着许多的twemproxy并且希望添加一个Redis后端节点，另一个问题是如何让所有的twemproxy安全的更新配置，而这将增加IT操作的复杂性。同时，Twitter（正在开发twemproxy的公司）目前已经放弃并不再将其应用于生产环境。

不同于twemproxy，RebornDB有一个杀手锏：动态的切分数据集，这将非常有用，特别是在你的数据集增长很快，你不得不增加更多的存储节点来扩展集群的情况下。总之，RebornDB将会透明的重新切分数据而不影响目前正在运行的服务。

架构

我们可以将RebornDB想象成一个黑盒，像一个单节点的Redis服务器一样用任何现有的Redis客户端去和它通信。下面的图片展示了RebornDB的架构。

RebornDB有以下组件： reborn-proxy, backend store, coordinator, reborn-config, and reborn-agent.

Reborn-proxy

reborn-proxy为客户端提供单一的外部服务。任何redis客户端都能连接到任一reborn-proxy并运行命令。

reborn-proxy用RESP解析来自客户端的命令，将其分发至对应的后端存储，接收到后端存储的答复并返回客户端。

Reborn-proxy 是无状态的，意思是说你可以很容易的水平扩展redis-proxy来处理更多的服务请求。
我们可以有许多的Reborn-proxy，在分布式系统设计的时候怎么让客户端发现它们是另一个主题,但是我们不会在这里深入探讨这个问题，一些实用的方法是使用DNS，LVS，HAProxy等等。

后端存储器（Backend store ）

后端存储器是reborn-server（一个修改的redis版本）或者QDB。我们引入一个概念叫做组（group）来管理一个或者多个后端存储。一个组（group）必须有一个主节点和零个、一个或者多个从节点形成复制拓扑结构。

我们将整个数据集分成1024个slots（我们用hash(key)24来决定这个key属于哪个slot），并且将不同的slot保存到不同的组。如果你想重新切分数据，你可以增加一个新的组并让RebornDB 从另一个组迁移一个slot的所有数据到新的组。

我们也可以让不同的组采用不同的后端存储器。例如：我们希望group1来保存热点数据，group2来保存大量的冷数据，那么我们就能使用reborn-server构成group1，QDB构成group2.Reborn-server比QDB快很多，因此我们能够保证热点数据的读写性能。

协调器（Coordinator ）

我们使用zookeeper或者etcd作为协调服务器，当我们需要做一些写操作的时候，例如重新切分，故障转移等，它们会协调所有的服务。

所有RebornDB的信息都被保存在协调器中，例如关键路由规则，reborn-proxy可以根据它将命令正确的分发至后端存储器。

Reborn-config

Reborn-config是一个管理工具，我们可以使用它增加或删除组，例如增加或删除组中的存储，从一个组迁移数据至另一个组等等。

如果我们想要改变RebornDB集群的信息，就必须使用Reborn-config。例如：我们不能直接使用“SLAVE NO ONE”命令将后端存储器提升为主节点，而必须使用“reborn-config server promote groupid server”我们必须不仅仅改变组内的复制拓扑结构，而且要更新协调器中的信息，而这些只有Reborn-config能够做到。

Reborn-config也提供了一个网站服务，因此你可以很容易的管理RebornDB，如果需要更多的控制，你可以使用它的HTTP RESTFUL API。

Reborn-agent

Reborn-agent是一个高可用组件。你可以用它启动和停止应用（reborn-config, qdb-server, reborn-server, reborn-proxy）。我们将在接下来的高可用部分详细讨论。

重新切分（Resharding）

RebornDB支持动态的重新切分数据。我们是怎么做到的呢？

正如我们上面说的，我们将整个数据集分成1024个slots，并且将不同的slot保存到不同的组。当我们新增加一个组的时候，我们会将一些slots从旧的组迁移到新组中。在重新切分过程中我们将它叫做迁移。在RebornDB中最小的迁移单元是slot。

让我们从下面的一个简单的例子开始：

我们有两个组，group1有两个slot 1和2，group2有三个slot 3、4、5.现在group2的工作量比较大，我们将会增加group3并将slot5迁移进去。

我们可以使用下面的命令来将slot5从group2迁移至group3。

reborn-config slot migrate 5 2 3

（译者注：原文为 reborn-config slot migrate 5 5 3有误）

这个命令看起来很简单，但是我们需要在内部做很多工作来保证迁移的安全性。我们必须使用两阶段提交协议（2PC）来告诉reborn-proxy我们将把slot5从group2迁移至group3。待所有reborn-proxy确认并且答复之后，我们将开始迁移操作。

迁移的流程比较简单：从slot5中得到一个key，从group2迁移它的数据至group3，然后删除group2中的key，如此循环。最后group2中就没有slot5的数据而所有slot5的数据都在group3中。

key的迁移是原子性的，因此无论这个key之前是否在group2或者group3中，我们能够确定的是在执行迁移命令之后它是在group3中的。

如果在group2中没有数据是属于slot5的，我们将停止迁移，拓扑结构看起来是下面这个样子：

高可用性（High Availability）

RebornDB使用reborn-agent来提供HA解决方案。

reborn-agent每时每刻都在检查它启动的应用是否是活动的，如果reborn-agent发现一个应用挂掉了，它会重新启动这个应用。

Reborn-agent有点像一个管理员，但是它有更多的特点。

Reborn-agent提供HTTP Restful API方便我们添加或删除需要被动态监控的应用程序。例如：我们能够使用HTTP “/api/start_redis” API来启动一个新的reborn-server，或者“/api/start_proxy” API来启动一个新的reborn-proxy，我们也能够用“/api/stop”来停止一个正在运行的应用并且从目前的监控列表中删除它。

Reborn-agent不仅仅应用于本地应用的监控，同样适用于后台存储的HA。多个Reborn-agent将首先通过协调器选择一个主reborn-agent，它会不断检查后端存储器是否是活动的，如果发现后端存储器宕机了，它就会进行故障转移。如果宕机的后端存储器是一个从节点，reborn-agent将只会在协调器中将它设置为离线，但是如果它是主节点，reborn-agent将会从现有的从节点中选择一个作为主节点并进行故障转移操作。

即将要做的......

尽管RebornDB有许多很棒的特性，我们仍然需要更多的工作去进一步提升它，我们后续可能做这些事情：

更好的用户体验：现在运行RebornDB并不是那么容易，我们将要做一系列工作诸如初始化slots、添加服务到group中、分配slots给一个组等等，在未来的工作中，如何降低用户的使用门槛是我们必须要考虑的问题；
复制迁移：现在我们迁移是逐个key迁移slot，如果一个slot包含许多数据的话速度就不是很快，使用复制迁移可能会好很多。在上面的例子中，group2首先产生一个快照，group3 能够在那个时间点取得所有slot5的数据，之后group3将从group2增量同步变化的数据。当我们发现group3取得了group2中slot5所有变化的数据之后，我们将进行切换，并从group2中删除slot5；
精美的仪表板：为了提供更好的用户体验，我们希望通过仪表板控制和监控一切事务。基于 P2P的集群：现在RebornDB是一个基于代理的集群解决方案，我们可能重新设计整个架构，之后将使用P2P，就像官方redis集群一样