1.设计概述

1.1. 目标

(1).核心服务可以同时在两个机房运行，但备机房服务依然访问主机房数据。

(2).主机房出现故障后，可以迅速将全站业务流量都切换到备机房，同时备机房服务也将数据访问切换到备机房并且只读访问。

2.架构设计

2.1. codis同城双活架构

fe：codis集群管理web服务，实时获取集群状态并展示给用户。

dashboard：codis集群的操作和信息采集中心，用来搭建集群并实时收集集群中所有组件运行状态。

proxy：作为代理与客户端交互，将客户端请求按照一定的规则转发给对应的server实例，并将执行结果返回给客户端。

server实例：数据存储组件(redis或pika)

jodis: 访问redis的 java客户端

keeper：用于主从机房数据同步

2.2 业务访问流程

3.模块设计

3.1. dashboard

每个dashboard唯一标识一个集群，多活项目中主机房codis集群相当与主集群，备机房codis相当与从集群，从集群自己负责添加server实例、proxy实例和分组信息，从集群中slot信息从主集群数据中读取。

从集群也是在主机房创建，然后通过mysql将信息同步到备机房，备机房进行只读操作。

dashboard整体结构不会有大的改动，主要改动如下：

(1). dashboard将集群信息写入到mysql数据库，备机房dashboard只从mysql中读取数据。

(2). dashboard中增加一个master-product字段，用于标识主备集群的主从关系；如果master-product字段为空，则该集群为主集群；如果master-product字段不为空，在该集群为从集群，从集群没有在数据库中不保存自己的slot映射关系，从集群从数据库中读取主集群的slot映射关系。

(3). dashboard中增加一个配置项mysql-readonly，标记备机房dashboard，跳过dashboard启动过程中需要去mysql注册topom节点的逻辑

(4). 备机房的数据暂不写入监控。

(5). 本地缓存整个集群信息，即使mysql出问题也能正常运行。

(6). dashboard 的 overview 页面处增加 overview 信息刷新按钮，强制 dashboard 去 mysql 上获取最新的集群状态，同时还要刷新proxy的状态

(7). 从 dashboard 的 proxy的刷新按钮需要先强制更新slots的最新状态

3.2 codis-fe

codis-fe不需要任何修改。

3.3. proxy

proxy不需要任何修改，主机房proxy只访问主机房server实例，备机房proxy只访问备机房server实例。

3.4. jodis

业务方jodis客户端使用公司定制的jodis客户端。jedis负责与consul之间进行通讯，当codis服务触发切换时，consul主动通知jodis进行切换。

(1). jodis配置中增加数据中心和zk配置，可以配置多个数据中心和多个zk地址。

(2). jodis启动时先去consul获取当前正在使用的数据中心，然后去相应数据中心zk上获取proxy节点使用。

(3). 当consul监控到服务对应数据中心发生切换后，主动通知jodis进行数据中心切换。

(4). jodis与备机房建立连接时，只能将读请求发送到备机房；写请求直接返回失败。

(5). 多读支持。

3.5. redis(codis-server)

codis-server实例为公司原有codis-redis实例，不做任何修改和调整。

3.6. consul

整个同城双活中的服务治理中心，负责服务的注册、销毁和查询，主机房故障或者主机房中服务出现故障后通知所有相关业务切换到备机房。

3.7. consul-agent

每个服务器上运行一个consul-agent服务，用于注册proxy服务和检测proxy健康状态。启动proxy实例时将proxy与所属appid写入到相应的consul服务配置文件，consul-agent自动读取consul服务配置文件并将新添加服务注册到consul中。周期检测服务器上注册服务的健康状态并上报到consul中。

3.8. keeper

keeper负责将主机房redis实例数据同步到备机房redis实例；如果codis后端使用pika则直接使用pika主从同步不需要使用keeper同步(pika中使用binlog方式进行同步)。

4.风险与规避

1.consul-agent需要监听到所有proxy都宕掉之后，才能认为集群不可用。

2.备机房与主机房实例对应关系要从两个集群中人工查看和人工同步。

3.备机房的group结构必须和主机房group结构保持一致，需要运维人员手动操作

4.当主dashboard上的slots信息发送变化后需要运维人员去从dashboard上执行mysql节点信息重新获取的操作

5.注意事项

1. 主机房集群group节点状态改变的时候什么时间去刷新备机房slots状态
2. 主机房数据迁移的时候备机房如何处理？包括slots迁移和自动扩容
3. 备机房开始同步主机房slots状态之前需要先将主机房的slots迁移开关关闭