登录 / 注册
IT168技术开发频道
IT168首页 > 技术开发 > 技术开发技术 > 正文

BAT等IT大厂们都在用什么Redis集群方案?

2018-05-25 09:39    博客园 来源:博客园  作者: 大CC 编辑: 田晓旭

  【IT168 技术】redis 集群方案主要有两类,一是使用类 codis 的架构,按组划分,实例之间互相独立;另一套是基于官方的 redis cluster 的方案;下面分别聊聊这两种方案;

  类 codis 架构

BAT等IT大厂们都在用什么Redis集群方案?

  这套架构的特点:

  分片算法:基于 slot hash桶;

  分片实例之间相互独立,每组 一个master 实例和多个slave;

  路由信息存放到第三方存储组件,如 zookeeper 或etcd

  旁路组件探活

  使用这套方案的公司:阿里云: ApsaraCache, RedisLabs、京东、百度等

  codis

  slots 方案:划分了 1024个slot, slots 信息在 proxy层感知; redis 进程中维护本实例上的所有key的一个slot map;

  迁移过程中的读写冲突处理:最小迁移单位为key;访问逻辑都是先访问 src 节点,再根据结果判断是否需要进一步访问 target 节点;

  访问的 key 还未被迁移:读写请求访问 src 节点,处理后访问:

  访问的 key 正在迁移:读请求访问 src 节点后直接返回;写请求无法处理,返回 retry

  访问的 key 已被迁移(或不存在):读写请求访问 src 节点,收到 moved 回复,继续访问 target 节点处理

  阿里云

  AparaCache 的单机版已开源(开源版本中不包含slot等实现),集群方案细节未知;ApsaraCache

  百度 BDRP 2.0

  主要组件:proxy,基于twemproxy 改造,实现了动态路由表;redis内核: 基于2.x 实现的slots 方案;metaserver:基于redis实现,包含的功能:拓扑信息的存储 & 探活;最多支持1000个节点;

  slot 方案:redis 内核中对db划分,做了16384个db; 每个请求到来,首先做db选择;

  数据迁移实现:数据迁移的时候,最小迁移单位是slot,迁移中整个slot 处于阻塞状态,只支持读请求,不支持写请求;对比 官方 redis cluster/ codis 的按key粒度进行迁移的方案:按key迁移对用户请求更为友好,但迁移速度较慢;这个按slot进行迁移的方案速度更快;

  京东

  主要组件:proxy: 自主实现,基于 golang 开发;redis内核:基于 redis 2.8configServer(cfs)组件:配置信息存放;scala组件:用于触发部署、新建、扩容等请求;mysql:最终所有的元信息及配置的存储;sentinal(golang实现):哨兵,用于监控proxy和redis实例,redis实例失败后触发切换;

  slot 方案实现:在内存中维护了slots的map映射表;

  数据迁移:基于 slots 粒度进行迁移;scala组件向dst实例发送命令告知会接受某个slot;dst 向 src 发送命令请求迁移,src开启一个线程来做数据的dump,将这个slot的数据整块dump发送到dst(未加锁,只读操作)写请求会开辟一块缓冲区,所有的写请求除了写原有数据区域,同时双写到缓冲区中。当一个slot迁移完成后,把这个缓冲区的数据都传到dst,当缓冲区为空时,更改本分片slot规则,不再拥有该slot,后续再请求这个slot的key返回moved;上层proxy会保存两份路由表,当该slot 请求目标实例得到 move 结果后,更新拓扑;

  跨机房:跨机房使用主从部署结构;没有多活,异地机房作为slave;

  基于官方 redis cluster 的方案

BAT等IT大厂们都在用什么Redis集群方案?

  和上一套方案比,所有功能都集成在 redis cluster 中,路由分片、拓扑信息的存储、探活都在redis cluster中实现;各实例间通过 gossip 通信;这样的好处是简单,依赖的组件少,应对400个节点以内的场景没有问题(按单实例8w read qps来计算,能够支持 200 * 8 = 1600w 的读多写少的场景);但当需要支持更大的规模时,由于使用 gossip协议导致协议之间的通信消耗太大,redis cluster 不再合适;

  使用这套方案的有:AWS, 百度贴吧

  官方 redis cluster

  数据迁移过程:基于 key粒度的数据迁移;迁移过程的读写冲突处理:从A 迁移到 B;

  访问的 key 所属slot 不在节点 A 上时,返回 MOVED 转向,client 再次请求B;

  访问的 key 所属 slot 在节点 A 上,但 key 不在 A上, 返回 ASK 转向,client再次请求B;

  访问的 key 所属slot 在A上,且key在 A上,直接处理;(同步迁移场景:该 key正在迁移,则阻塞)

  AWS ElasticCache

  ElasticCache 支持主从和集群版、支持读写分离;集群版用的是开源的Redis Cluster,未做深度定制;

  百度贴吧的ksarch-saas:

  基于redis cluster + twemproxy 实现;后被 BDRP 吞并;twemproxy 实现了 smart client 功能;使用 redis cluster后还加一层 proxy的好处:

  对client友好,不需要client都升级为smart client;(否则,所有语言client 都需要支持一遍)

  加一层proxy可以做更多平台策略;比如在proxy可做 大key、热key的监控、慢查询的请求监控、以及接入控制、请求过滤等;

  即将发布的 redis 5.0 中有个 feature,作者计划给 redis cluster加一个proxy。

  ksarch-saas 对 twemproxy的改造已开源:https://github.com/ksarch-saas/r3proxy

标签: 集群 , Redis
  • IT168企业级IT168企业级
  • IT168文库IT168文库

扫一扫关注

行车视线文章推荐

首页 评论 返回顶部