Redis——redis集群方案之codis集群的搭建部署

一.什么是codis集群

codis集群简介

• Codis是一个分布式的Redis解决方案，对于上层的应用来说，连接Codis Proxy和连接原生的Redis Server没有明显的区别（不支持的命令列表），上层应用可以像使用单机的Redis一样使用，Codis底层会处理请求的转发，不停机的数据迁移等工作，所有后边的一切事情，对于前面客户端来说是透明的，可以简单的认为后边连接是一个内存无限大的Redis服务。

• Codis是一套用go语言编写的,为了应对高并发环境下的redis集群软件,原理是对一个redis key操作前,先把这个key通过crc32算法,分配到不同redis的某一个slot上,实现并发读写功能.而且能通过zookeeper调用redis-sentinel来实现故障切换功能.现在最新版本是3.2.1,依托于redis3.2.9开发出来。

codis的优缺点

• 优点：实现高并发读写，数据一致性高。

• 缺点：性能有较大损耗，故障切换无法保证不丢key。无法进行读写分离。

codis的架构介绍

go

描述：codis依赖语言包

codis

描述：codis集群套件，里面含有redis相关程序和集群专用程序。主要功能程序解析：

• codis-server：属于redis-server优化版，基于 redis-3.2.9 分支开发。增加了额外的数据结构，以支持slot 有关的操作以及数据迁移指令。

• codis-proxy：客户端连接的 Redis 代理服务，实现了 Redis 协议。 除部分命令不支持以外(例如：keys*，flush )，表现的和原生的 Redis 没有区别（就像 Twemproxy）。

  1. 对于同一个业务集群而言，可以同时部署多个 codis-proxy 实例；
  2.不同 codis-proxy 之间由 codis-dashboard 保证状态同步。
  

• codis-dashboard：集群管理工具，支持 codis-proxy、codis-server
  的添加、删除，以及据迁移等操作。在集群状态发生改变时，codis-dashboard 维护集群下所有codis-proxy的状态的一致性。

  对于同一个业务集群而言，同一个时刻 codis-dashboard 只能有 0个或者1个；
  
  所有对集群的修改都必须通过 codis-dashboard 完成。
  

• Codis-fe：集群web管理界面。

  多个集群实例共享可以共享同一个前端展示页面；
  通过配置文件管理后端 codis-dashboard 列表，配置文件可自动更新。
  

• redis-sentinel：可以实现对Redis的监控、通知、自动故障转移。如果Master不能工作，则会自动启动故障转移进程，将其中的一个Slave提升为Master，其他的Slave重新设置新的Master服务。Sentinel的配置由codis-dashboard和zookeeper一起控制，不需要手工填写。

jdk

描述：zookeeper依赖语言包

zookeeper

描述：用于存放数据配置路由表。zookeeper简称zk。在生产环境中，zk部署越多，其可靠性越高。由于zk集群是以宕机个数过半才会让整个集群宕机，因此，奇数个zk更佳。

逻辑架构如下：

• 访问层：

访问方式可以是类似keepalived集群的vip方式，或者是通过java代码调用jodis控件再连接上zookeeper集群，然后查找到可用的proxy端，进而连接调用不同的codis-proxy地址来实现高可用的LVS和HA功能。

• 代理层：

中间层由codis-proxy和zookeeper处理数据走向和分配，通过crc32算法，把key平均分配在不同redis的某一个slot中。实现类似raid0的条带化，在旧版本的codis中，slot需要手工分配，在codis3.2之后，只要点一个按钮slot会自动分配，相当方便，但是也可以手动分配，需要另外调用codis-admin命令。

• 数据层：

最后codis-proxy把数据存进真实的redis-server主服务器上，由于codis的作者黄东旭相当注重数据一致性，不允许有数据延时造成的数据不一致，所以架构从一开始就没考虑主从读写分离。从服务器仅仅是作为故障切换的冗余架构，由codis-dashboard监控各服务的状态，然后通过改写zookeeper数据和调用redis-sentinel实现故障切换功能。

二.codis集群的搭建部署