Redis故障转移和分区？

Question

我在4节点redis设置上使用客户端分区。写入和读取分布在节点之间。 Redis用作易失性数据的持久层，以及应用程序不同部分的缓存。我们还有一个用于持久化非易失性数据的cassandra部署。

在redis上，我们的峰值接近1k ops / sec（instantaneous_ops_per_sec）。预计负载会随着时间的推移而增加。我们在许多操作中查询不存在的密钥，以检查该密钥是否存在数据。

我想实现以下目标：

• 当redis节点出现故障时，写入应该故障转移。
• 当redis节点出现故障时，应该有一个备份来读取丢失的数据。
• 如果我们将来添加更多redis节点（或者一个死节点重新启动），读取和写入应该一致地重新分配。

我正在尝试找出合适的设计来处理上述情况。我想到了以下几个选项：

• 为现有节点创建热从属服务器，并在主服务器关闭时进行交换。这不会解决第三点。
• 编写一个Application层来保存redis和cassandra中的数据，从而在redis节点关闭时允许读取的延迟加载路径。这种方法会有写入两个商店的开销。

哪种方法更好？是否有适合上述方法的替代方案？

Answer 1

1k ops / s的负载远低于Redis的能力。在接近超载之前，您需要增加两个或更多个数量级。如果您不希望超过50-70,000 ops /秒并且不超过可用的单/ 0节点内存，我真的不会为分割数据而烦恼，因为它比它的价值更省力。

那就是说，我不会为这个客户端进行分片。我会看看像Twemproxy / Nutcracker这样的事情。这提供了Redis群集的路径以及扩展连接的能力，并证明了对故障转移方案的透明客户端支持。

要在客户端中处理故障转移，您需要为每个插槽设置两个实例（在您的描述中为写入节点），其中一个实例与另一个实例相同。然后，您将运行Sentinel Constellation来管理故障转移。

然后，您需要将客户端代码连接到sentinel，以获取每个插槽的当前主连接。这也意味着客户端代码可以在发生故障转移时重新连接到新升级的主服务器。如果您有可用的负载均衡器，则可以将Redis节点置于一个或多个（最好是两个具有故障转移）后面，并消除客户端重新连接要求，但是您需要实现一个标记脚本或监视器以在故障转移时更新负载平衡器配置。

对于Sentinel Constellation，标准的3节点设置可以正常工作。如果您使用您控制的节点中的软件进行负载平衡，最好在负载均衡器上至少有两个标记节点，以提供自然连接测试。

根据您的描述，我将测试运行具有多个读取从属的单个主服务器，而不是在客户端代码中进行散列，将读取分发到从属服务器并写入主服务器。这将在客户端提供更简单的设置和可能不那么复杂的代码。缩放读取从设备更容易，更简单，并且正如您所描述的那样，绝大多数操作将是读取请求，因此它可以精确地符合您描述的使用模式。

您仍然需要使用Sentinel来管理故障转移，但这种复杂性仍然存在，从而导致代码和代码复杂性的净减少。对于单个主人来说，哨兵几乎是微不足道的，所以设置;警告是管理负载均衡器或虚拟IP或处理客户端代码中的标记发现的代码。

Answer 2

您正在此处打开分布式数据库Pandora的框。

我最好的建议是;不要这样做，不要实施自己的Redis群集，除非你能负担得起的数据丢失和/或你可以停止一些停机。

如果你能负担得起尚未生产的软件，我的建议是看看正式的Redis Cluster实施;如果您的要求足够低，无法启动自己的群集实施，那么您可以直接使用具有社区背后的Redis群集。

您是否考虑过使用与Redis不同的软件？ Cassandra，Riak，DynamoDB，Hadoop是成熟的分发数据库的绝佳例子，可以满足您的要求。