为了更好的做好容灾保障,使业务能够应对机房级别的故障,滴滴的存储服务都在多机房进行部署。本文简要分析了 Redis 实现异地多活的几种思路,以及滴滴 Redis 异地多活架构演进过程中遇到的主要问题和解决方法,抛砖引玉,给小伙伴们一些参考。
Redis 异地多活的主要思路
业界实现 Redis 异地多活通常三种思路:主从架构、Proxy双写架构、数据层双向同步架构。
主从架构
主从架构的思路:
各机房的 Redis 通过 Proxy 对外提供读写服务,业务流量读写本机房的 Redis-proxy
主机房里的 Redis-master 实例承担所有机房的写流量
从机房里的 Redis-slave 实例只读,承担本机房里的读流量
主从架构的优点:
实现简单,在 Proxy 层开发读写分流功能就可以实现
Redis 层使用原生主从复制,可以保证数据一致性
主从架构的缺点:
从机房里的 Redis-proxy 需要跨机房写,受网络延时影响,业务在从机房里的写耗时高于主机房
主机房故障时,从机房的写流量也会失败,需要把从机房切换为主机房,切换 Redis-master
网络故障时,从机房的写流量会全部失败,为了保障数据一致性,这种场景比较难处理
Proxy 双写架构
Proxy 双写架构的思路:
各机房的 Redis 通过 Proxy 对外提供读写服务,业务流量读写本机房的 Redis-proxy
不区分主从机房,每个机房都是独立的 Redis 集群
各机房的读写流量都是访问本机房的 Redis 集群
Proxy 层在写本机房成功后,将写请求异步发送到对端机房
Proxy 双写架构的优点:
实现简单,在 Proxy 层开发双写功能就可以实现
一个机房故障时,其他机房的流量不受影响
网络故障时,各机房内部的流量也不受影响
Proxy 双写架构的缺点:
不能保证数据一致性,Proxy 异步 write 请求可能会失败,失败丢弃请求后,导致双机房数据不一致
假设机房-A的集群先上线,机房-B 后上线,Pro