Redis - 分区

Redis - 分片与扩展

分片（Partitioning）是将数据分散到多个 Redis 实例的策略。这使你能够克服单台服务器的内存限制，并扩展计算能力和网络吞吐量。在现代 Redis 中，实现这一目标的主要推荐方式是使用 Redis Cluster。

为何要分片？

• 更大的数据集：通过结合多个节点的内存，将数据库扩展到超出单台机器的 RAM 容量。
• 更高的吞吐量：通过将负载分布到多个 CPU、核心和网络接口上，扩展读/写操作。
• 高可用性：当与复制（Replication）（如 Redis Cluster 中）结合使用时，分片提供了容错能力。如果一个节点发生故障，其他节点可以继续提供服务。

现代分片：Redis Cluster

自 Redis 3.0 起，Redis Cluster 是官方内置的分片和高可用性解决方案。它自动化了分片的大部分复杂性。

Redis Cluster 工作原理

• 哈希槽（Hash Slots）：整个键空间被划分为 16,384 个哈希槽。Redis 通过对键进行哈希（使用 CRC16）并执行模运算来确定键属于哪个槽：HASH_SLOT = CRC16(key) mod 16384。
• 节点分布：集群中的每个主（master）节点负责这些哈希槽的一个子集。例如，在一个 3 节点集群中，节点 A 可能持有槽 0-5500，节点 B 持有 5501-11000，节点 C 持有 11001-16383。
• 客户端重定向：智能客户端（大多数现代 Redis 客户端都是如此）可以获取集群的槽映射。当发送命令时，客户端会计算键的哈希槽，并将命令直接发送到正确的节点，从而最大限度地减少延迟。
• 再平衡（Rebalancing）：Redis Cluster 支持向集群添加或从中移除节点。发生这种情况时，它可以自动且透明地在节点之间迁移哈希槽（及其内部数据），且停机时间最短。

限制与注意事项

• 多键操作：涉及多个键的操作（如 SUNION 或事务）仅在所有键属于同一个哈希槽时才受支持。为了强制实现这一点，你可以使用一个名为“哈希标签”（hash tags）的功能。通过将键的一部分放在花括号 {} 中，你可以确保只有这部分被哈希。例如，user:{123}:profile 和 user:{123}:orders 将映射到同一个槽。
• 管理开销：虽然 Redis Cluster 自动化了大部分工作，但自行托管集群仍然需要配置、监控和维护多个实例。
• 数据处理：备份集群涉及在每个单独节点上创建 RDB/AOF 快照。恢复需要仔细协调。

其他分片策略

虽然 Redis Cluster 是标准方案，但了解其他概念性方法也很有用，这些方法通常由客户端库或代理服务管理。

概念性：范围分片

这涉及将键的范围映射到特定的实例。例如，用户 ID 1-10000 映射到节点 R0，10001-20000 映射到 R1。这很容易理解，但可能导致数据分布不均（“热点”），并且难以再平衡。

概念性：客户端哈希分片

在此模型中，客户端应用程序（或其使用的库）负责对键进行哈希并决定将请求发送到哪个 Redis 节点。这不如 Redis Cluster 健壮，因为它要求所有客户端共享相同的哈希算法和集群映射，并且再平衡是一个手动、复杂的过程。

行业最佳实践：托管服务

对于许多生产应用程序来说，最实用的方法是使用云提供商（例如 AWS ElastiCache、Google Cloud Memorystore、Azure Cache for Redis）提供的托管 Redis 服务。这些服务负责 Redis 集群的设置、管理、扩展和备份，使开发团队能够专注于其应用程序逻辑。