深入了解 Redis 集群：分片算法和架构

Redis 在许多公司中被广泛用作缓存。单个 Redis 实例可以处理数百万个读/写 qps，因为所有操作都在内存中。除了作为类似于memcached的简单内存内缓存外，Redis还提供了许多其他功能。例如，在许多情况下，Redis 也可以用作持久存储，因为 Redis 具有内置的 AOF（仅追加文件）机制，可以启用该机制以持久化对磁盘的每个写入操作。AOF有两种模式，可以在设置Redis时进行配置。

• 同步 AOF：同步 AOF 意味着每次写入都需要在返回到客户端（也称为。“阻止”写入）。在这种模式下，Redis 不再是纯粹的“内存内”存储。同步 AOF 可确保持久性，但需要牺牲高写入延迟。在我们的生产环境中，我们观察到，平均而言，同步 AOF 对于单个写入操作需要 ~1 秒。
• 异步 AOF：在此模式下，写入是非阻塞的，这意味着 Redis 仍然可以被视为客户端的“内存中”，只是内存内数据在后台定期持久化到磁盘上，这对客户端是透明的。此模式提供非常低的写入延迟，因为它仍然是客户端的内存，但需要权衡数据丢失。如果 Redis 节点发生故障或重新启动，则写入此 Redis 节点但尚未持久保存到磁盘的数据将永久丢失。

Redis集群

当数据量、读/写qps超过单个Redis实例的容量时，我们需要使用 Redis 集群来存储 kv 数据。在集群中，密钥分发到多个实例。通常，有三种方法可以将密钥分片到多个实例：

客户端分片

假设我们有一个广告排名引擎，它本质上是一种推荐服务，可以从广告数据库中调用相关广告，并为每个ad_request对广告进行排名。排名引擎需要检索每个广告的实时出价才能执行广告竞价。由于业务对延迟的高度敏感性，所有广告的实时出价都会被计算并预加载到 Redis 集群中。广告排名引擎在其二进制文件中内置了 Redis 客户端，以便从 Redis 读取。

在客户端分片中，Redis 客户端包含分片和路由逻辑。换句话说，这是一个非常厚的客户端。优点是此体系结构不依赖于任何中间件。只有两方：Redis 客户端和 redis 节点。

 

使用集中式代理（也称为中间件）的服务器端分片

中间件用作代理。来自广告排名引擎的请求将命中代理。代理包含分片和路由逻辑，用于确定访问哪个 Redis 实例来检索数据。在这种情况下，redis 客户端可以是一个非常瘦的客户端，因为它不再包含分片或路由逻辑。

 

去中心化服务器端分片

去中心化分片是官方 Redis 集群中实际使用的。集群中的每个节点都维护着“路由表”的本地副本，并通过gossip协议不断更新其路由表。换句话说，不再有集中式代理。相反，每个 Redis 节点都包含充当代理所需的完整信息集。