Redis 横向扩展案例 | 温国兵的随想录

Redis 横向扩展案例 | 温国兵的随想录

2.2 使用 Twemproxy 横向扩展

我们尝试进行 Scale Out，增加 Redis 实例，并且使用 Twemproxy 代理，每台 Web 服务器访问本地的 Twemproxy。

在此不妨简单介绍下 Twemproxy。为了满足数据的日益增长和扩展性，数据存储系统一般都需要进行一定的分片。分片主要存在三个位置，第一层，数据存储系统本身支持；第二层，服务器端和客户端中间建代理支持；第三层，客户端支持。Redis Cluster 属于第一层，Twemproxy 属于第二层，Memcached 属于第三层。Twemproxy（又称为 nutcracker）是一个轻量级的 Redis 和 Memcached 代理，主要用于分片。Twemproxy 由 Twitter 开源出来的缓存服务器集群管理工具，主要用来弥补 Redis 和 Memcached 对集群 (Cluster) 管理的不足。Twemproxy 按照一定的路由规则，转发给后台的各个 Redis 实例，再原路返回。有了 Twemproxy，前端不再关心后端代理了多少 Redis 实例，而只需访问 Twemproxy 即可，一方面简化了开发难度，另一方面提高了性能。Twemproxy 支持大部分命令，但对多键命令的支持有限，并且会有 20% 左右的性能损失（Twitter 官方测试结果）。简单来说，Twemproxy 就是一个支持 Redis 协议，对前端透明，支持分片，性能优秀的代理。当然，目前 Redis 3.0 已经发布，不少厂商会选择使用 Redis 3.0 代替 Twemproxy，这需要时间。

我们在独立服务器新增了 4 个实例，并且 Web 服务器部署 Twemproxy，应用访问本地的 Twemproxy。但实际的效果并不理想，Redis QPS 依然高，本地的 Twemproxy 居然让 Web 服务器性能恶化。另外一个有趣的现象是，Twemproxy 代理的几个 Redis 实例存在严重的数据倾斜。有些 Redis 实例 QPS 可以达到 80K，有些 Redis 只有 5K 左右。

那目前我们的问题主要集中在两个问题上，第一，连接数过高；第二，数据倾斜。经过研发排查，找出一段令人匪夷所思的代码。Nginx Lua 中的超时时间是 60s，这也解释了为什么实际连接跟理论连接相差如此巨大。

2.3 问题解决

根据以上的分析，我们决定分两步走。第一，更改超时时间；第二，解决数据倾斜的问题。

研发把超时改为 2s，并且根据实际情况更改了连接池，观察效果。可以明显地看到，连接数降到 1K 左右，机器 Socket 使用数下降显著，连接没有阻塞，业务没有较大的波动。

解决了连接数的问题，我们接下来解决数据倾斜的问题。

如前所述，Scale Out 后，Redis 实例存在严重的数据倾斜。有些 Redis 实例 QPS 可以达到 80K，有些 Redis 只有 5K 左右。分析这个问题，这就要从业务数据形态入手。这个业务是统计业务，由大量的 INCR 操作，并且产生的 Key 较少。Twemproxy 根据配置的一致性 Hash 函数，对 Key 进行 Hash 校验，再决定转发到对应的 Redis 实例。

根据以上分析，产生的 Key 较少，也就是重复率较高，导致转发的 Redis 实例就会集中。这也解释了为什么会产生数据倾斜。针对这个问题，我们展开讨论。最开始打算写本地文件，然后定时写入 Redis，这样 Redis 的 QPS 会下降不少。但考虑到定时器实现较复杂，于是采取了拆分 Key 的办法。举个例子，比如之前是一分钟一个 Key，那现在 1 分钟产生 10+ Key，甚至更多，那这样数据倾斜的问题自然会慢慢减缓，直至消除。

经过研发的艰苦奋斗，把 Key 拆分后，效果明显。QPS 分摊到各个 Redis 实例，连接数下降，Web 服务器性能提高。

Read full article from Redis 横向扩展案例 | 温国兵的随想录