0%

Data Memcached集群迁移至Redis集群

发表于 2023-09-09

随着业务规模的增长，我们的缓存系统面临扩展性和运维效率的挑战。近期我们团队将缓存系统从Memcached迁移到Redis集群。

项目背景与迁移动机

我们的缓存系统最初基于Memcached，性能表现稳定，但随着业务发展，Memcached的局限性逐渐暴露：

扩展性受限：Memcached集群不支持自动分片，扩容和缩容需客户端手动实现，操作繁琐且运维成本高，难以应对流量快速增长。
监控能力薄弱：Memcached提供的指标有限（仅命中率、内存使用等），故障排查和告警不便，影响问题定位效率。
数据类型单一：仅支持键值对，复杂业务需求需额外开发支持，效率低下。

这些问题促使我们寻找替代方案，最终选择了Redis集群。迁移的目标不是提升性能，而是解决扩展性和监控问题，为未来发展预留空间。

技术选型：为什么选择Redis集群

我们直接选择了Redis集群，原因如下：

成熟度：Redis的社区拥有丰富文档和活跃支持，而且我们团队在其他项目中的使用已非常成熟。
功能优势：支持自动分片、丰富数据结构（如Hash、List）和内置监控，弥补Memcached的不足。
团队熟悉：团队对Redis的开发和运维经验丰富，降低了学习成本。

迁移过程

迁移分为几个阶段，确保无侵入且风险可控：

代码改造：
- 通过底层SDK适配Redis集群，封装缓存操作接口（get、set），业务代码无需改动。
- 配置动态切换缓存后端（Memcached或Redis）。
测试验证：
- 模拟业务场景验证功能正确性。
- 测试Redis集群的扩容/缩容，确保无影响。
灰度发布：
- 从5%流量开始，逐步增至20%，观察一周后全量切换。
- 按用户维度区分流量，避免数据一致性问题。
数据过渡：
- 新请求写入Redis，旧数据在Memcached过期，无需显式迁移。这种策略能有效降低迁移复杂性。但对于某些关键缓存数据，可能需要更谨慎的迁移方案。
监控支持：
- 使用Prometheus和Grafana，从测试到全量全程监控Redis和业务指标。关键监控指标包括Redis的CPU使用率、内存使用率、连接数、命中率、Key的数量，以及业务相关的错误率、请求量等。

挑战与解决方案

迁移中暴露了三个主要挑战，我们逐一解决：

大Key问题：
- 挑战：Memcached节点内存大，大Key不明显；Redis集群分片内存小，大Key导致负载不均。
- 解决方案：将大Key拆分为多个小Key（如user:123拆为user:123:profile），均匀分布。
- 效果：内存使用率从100%降至50%。
热Key问题：
- 挑战：Redis分片配置低，热Key高频访问导致QPS激增。
- 解决方案：引入本地缓存（TTL 1分钟），允许短暂不一致，优先从本地读取。
- 效果：Redis负载减少80%。
JVM崩溃：
- 挑战：在流量高峰时JVM崩溃，因为系统内部使用Redisson依赖的netty与gRPC依赖的netty版本冲突。
- 解决方案：升级Redisson到最新版。
- 效果：崩溃问题消失。

迁移成果

性能与稳定性：
- 迁移后性能和稳定性与Memcached持平，未见提升，因目标非性能优化。
- 压测显示两者在20万QPS下表现相当。
用户体验：
- 页面加载时间和服务稳定性无变化，用户无感知反馈。
实际价值：
- 扩展性：Redis集群支持动态扩容，解决了Memcached的瓶颈。
- 监控性：丰富指标提升了运维效率。

经验教训

无侵入SDK：降低风险，业务代码稳定。
灰度发布：分阶段切换，问题可控。
关闭持久化：提升性能，适配需求。为了追求更高的读写性能，我们选择关闭了Redis的持久化功能。在生产环境中，需要根据具体的业务场景权衡是否开启持久化以及选择合适的持久化策略。
全面监控：实时反馈，快速响应。
聚焦扩展性：明确目标，预留潜力。

结语

这次迁移让我们从Memcached的局限中解脱，Redis集群为未来增长奠定了基础。虽然性能未提升，但扩展性和监控能力的改善达到了预期。关于成本方面，迁移到Redis集群可能会带来一定的服务器成本增加，但运维效率的提升有望在长期降低总体成本。