人生不过如此，且行且珍惜。自己永远是自己的主角，不要总在别人的戏剧里充当着配角。

我以林语堂的《人生不过如此》中一句话来开篇。

背景

在互联网高速发展、快速演化的时代，想必在你的系统架构设计中，缓存服务是不是已经成为必不可少的一层，丰富的数据结构、高性能的读写、简单的协议，让缓存数据库很好的承担起关系型数据库的上层。我们公司为了解决节假日或高峰期的车次查询、抢票等大数据量的访问请求，很早以前就引进了Redis，来作为数据库的上游缓存层，缓解底层数据库的读写压力。

REDIS HA架构

世界上唯一可以不劳而获的就是贫穷，唯一可以无中生有的是梦想。没有哪件事，不动手就可以实现。世界虽然残酷，但只要你愿意走，总会有路；看不到美好，是因为你没有坚持走下去。人生贵在行动，迟疑不决时，不妨先迈出小小一步。前进不必遗憾，若是美好，叫做精彩；若是糟糕，叫做经历。**——林语堂《人生不过如此》

2014年10月，为了避免单点故障，我们尝试在生产环境的Redis主从架构中，引入了Redis Sentinel，实现了Redis服务的failover。当Redis-Master主机异常宕机或Redis-Master服务异常崩溃时，原有的Redis-Slave自动升级为master角色，当原有Redis-Master恢复后，自动恢复为slave角色。

由于Redis Sentinel只能做到Redis服务级别的切换，无法做到IP地址的切换，无法完全满足现网系统架构的需要，我们又尝试在HA架构中加入了负载均衡器设备，引用了浮动IP，所有应用程序访问浮动IP，IP地址的切换操作由负载均衡器设备来实现。

Redis Sentinel配置文件

    vi /appl/redis/etc/sentinel.conf  
    # Redis-ha redis-sent-0-17 redis-sent-0-18
    port 26379
    dir /appl/redis/database
    logfile /appl/redis/log/sentinel.log
    sentinel monitor redis-sent-0-17 172.19.0.17 6379 3
    sentinel down-after-milliseconds redis-sent-0-17 20000
    sentinel failover-timeout redis-sent-0-17 60000
    sentinel can-failover redis-sent-0-17 yes
    sentinel parallel-syncs redis-sent-0-17 1

测试小结：

主Redis服务器：redis-sent-0-17
从Redis服务器：redis-sent-0-18
域名：redis-sent.cache.changtu.pvt

重启redis-sent-0-17节点，60秒后，redis-sent-0-18节点成为master，用户访问redis-sent.cache.changtu.pvt域名redis服务恢复正常，2分钟后，redis-sent-0-17节点重启完成，自动成为slave；
重启redis-sent-0-18节点，60秒后，redis-sent-0-17节点成为master，用户访问redis-sent.cache.changtu.pvt域名redis服务恢复正常，2分钟后，redis-sent-0-18节点重启完成，自动成为slave。

对应用程序的要求

缓存应用服务统一通过域名访问。
缓存应用服务对Redis域名的访问有断点重连的功能。

2015年新增2台Redis Sentinel服务器，负责平台所有Redis服务器集群管理。并对平台现有Redis服务进行改造，逐步升级为Redis HA架构。

CODIS分布式集群

你可以一辈子不登山，但你心中一定要有座山。它使你总往高处爬，它使你总有个奋斗的方向，它使你任何一刻抬起头，都能看到自己的希望。——林语堂《人生不过如此》

随着业务量上涨，数据量猛增，单点的Redis容量受限于服务器的内存，Redis主从架构已经力不从心了。在业务系统对性能要求逐渐提高情况下，我们更希望将数据能存在内存中，本地持久化，而不希望写入数据库中。虽然当时用SSD将内存换成磁盘，以获取更大的容量，但是我们更想如何将redis变成一个可以水平扩展的分布式缓存服务？

在Codis发布之前，业界只有Twemproxy，Twemproxy本身是一个静态的分布式Redis方案，进行扩容、缩容对运维要求非常高，而且很难做到平滑的扩缩容。Codis的目标就是尽量兼容Twemproxy，并且加上数据迁移的功能以实现扩容和缩容，最终替换Twemproxy。本文省略了对Twemproxy的介绍。

REDIS-CLUSTER

与Codis同时期发布的官方redis-cluster，采用P2P的模式，完全去中心化架构，其实我们花了大精力研究测试过，由于当时对failover判断方式提出怀疑，高耦合的模块设计思想、客户端问题、不太友好的维护等方面，我司目前没有投入生产，没有了实际的生产维护经验，我先不发表看法。抱拳，我知道在缓存数据库里最不应该缺少的就是Redis-cluster了，以后有机会单独介绍吧！

容我感叹一下，别指望所有的人都能懂你，因为萝卜白菜，各有所爱。你做了萝卜，自然就做不成青菜。

好了，回归正题，先简单介绍一下Codis，由豌豆荚于2014年11月开源，基于Go和C开发，引用作者的一段原话， Codis采用一层无状态的proxy层，将分布式逻辑写在proxy上，底层的存储引擎是Redis，数据的分布状态存储于zookeeper(etcd)中，底层的数据存储变成了可插拔的部件。各个部件是可以动态水平扩展的，尤其无状态的proxy对于动态的负载均衡，对业务而言完全是透明的。*

核心组件说明

1. ZooKeeper：

用来存放数据路由表和Codis-proxy节点的元信息，Codis-config发起的命令都会通过ZooKeeper同步到各个存活的Codis-proxy中。

2. Codis-Proxy :

是客户端连接的Redis代理服务，本身是没状态的，Codis-proxy实现了Redis协议，对于一个业务来说，可以部署多个Codis-proxy，提供连接集群Redis服务的入口。

3. Codis-Config ：

是Codis的集成管理工具，支持添加/删除Redis节点、添加/删除Proxy节点、以及发起数据迁移等操作，Codis-config还自带了http server，会启动dashboard，用户可以在WEB上监控Codis集群的状态。

4. Codis-Server：

是Codis项目维护的一个Redis分支，基于redis-2.8.21 分支开发，增加了额外的数据结构，以支持 slot 有关的操作以及数据迁移指令。

5.Pre-Sharding技术

Codis采用 Pre-Sharding的技术来实现数据的分片, 默认分成 1024 个 slots (0-1023), 对于每个key来说, 通过以下公式确定所属的 Slot Id : SlotId = crc32(key) % 1024，每一个 slot都会有一个特定的server group id来表示这个slot的数据由哪个server group来提供。

在2016年6月左右，我们引进了Codis（当时版本是3.0，并没有Redis-Sentinel、Codis-fe等组件，1年后，才升级到3.2的，文章主要以3.0版本为背景），首先介绍一下基础环境。

192.168.0.**      codis-server1
192.168.0.**      codis-server2
192.168.0.**      codis-server3
    
192.168.0.**      codis-ha1 (zookeeper-3)
192.168.0.**      codis-ha2 (zookeeper-2)
192.168.0.**      codis-ha3 (zookeeper-1)

系统架构

在公司硬件资源有限条件下，我们计划用6台服务器部署Codis，简单分了两层，Codis-Proxy层和Codis-Server层。

Codis-Proxy层用了三台配置相对较低服务器，部署了ZooKeeper、Codis-Proxy、Keepalived、LVS等，3个节点都做了负载均衡。
Codis-Server层用来三台配置相对较高的服务器，并用SSD，3个Codis-group，每个group有一主一从，交叉部署，每个主从分配30G内存。

maxclients 30000  
maxmemory  30gb

我们分别通过jredis编写测试程序和使用redis-benchmark工具模拟压力测试（请求量：1000万~1亿，并发数：1000~50000，长度：固定/可变）：

在性能方面：基本上能达到我们的预期，理想情况Codis性能值能达到50~60K OP/S，各个codis-group中master-slave实例数据能实时同步，详情可以参考《Codis高可用集群性能测试报告_20160315》。
数据一致性问题：一方面，Codis的HA并不能保证数据完全不丢失，由于M-S是异步复制，当master节点异常或崩溃，将slave切换成master后，刚刚没来得及同步的数据就会丢失。另一方面，Codis支持的mget/mset命令是无法保证单点时的原子语义的，如果mset指定KEY分布在不同slot上，从而导致KEY在不同机器上，造成要不一起成功，不要一起失败。所以对于分布式事务的问题，这是一个痛点。在实际场景中，也有人使用了lua脚本以扩展Redis的功能，虽然Codis支持，但是并不保证你的脚本操作的数据是否在正确的节点执行，仅仅起到一个转发功能。如果你并不能保证lua操作的KEY是否在同一个机器上，Codis只能将这个脚本分配到参数列表中的第一个key的机器上执行。
不支持命令列表，参考
https://github.com/CodisLabs/codis/blob/release3.2/doc/unsupported_cmds.md
Redis 修改部分（增加若干指令），参考
https://github.com/CodisLabs/codis/blob/release3.2/doc/redis_change_zh.md

倔强的青铜

于是组织研发同事进行多次分析讨论，并提出了对缓存服务进行接口改造，经过2个多月的辛劳，取得了很大进展，让我们Codis项目顺利上线迈开了重要一步，打断一下，容我在此特别感谢一下同事王慧，在他的主导下，完成公司绝大部分缓存服务接口改造工作。

几点改造思路

1.缓存服务分类。

针对业务缓存服务不容许数据丢失，在现有的逻辑中，Codis和数据库都会保留，优先从Codis读取，如读取不到时，会从后端数据库里读取。
针对车次、合作方缓存服务，由于数据量大，拉取频率高的数据，只会从Codis里读取。

2.对缓存服务进行接口改造，新增基础缓存服务层，将生产的Redis/Codis相关的服务纳入基础缓存服务进行统一管理。

制定一套标准KEY命名、管理规范，包括数据类型的选择、长度、过期时间等。我们会统一在后台管理系统公示，限定新数据的规则，限制一切不合规范的行为。
在基础缓存服务层，对部分Codis不支持的命令进行改写，规范Redis/Codis日常操作。
统计热点数据，维护热点数据，在基础缓存服务层上假设二级缓存，作为热点数据的快速通道。

3.SLOT的分配
哈希算法

Codis采用 Pre-sharding的技术来实现数据的分片, 默认分成 1024 个 slots (0-1023), 对于每个key来说, 通过以下公式确定所属的 Slot Id : SlotId = crc32(key) % 1024。例如pub_cty_ct018根据算法得出的值是997。

key值重定向分配

比如你有一个脚本是操作某个用户的多个信息，如uid1age，uid1sex，uid1name形如此类的key，如果你不用hashtag的话，这些key可能会分散在不同的机器上，如果使用了hashtag(用花括号扩住计算hash的区域)：{uid1}age，{uid1}sex，{uid1}name，这样就保证这些key分布在同一个机器上。这个是twemproxy引入的一个语法，我们这边也支持了。

以pub_cty为例，通过crc32hash算法得出，key存放在237 slot中，类似测试了{pub_cty}_ct01，{pub_cty}_ct02…{pub_cty}_ctnn都存放在237 slot中。第一，有了hashtag算法支持，我们可以对特定需求的key做一些特需的规划，将这些特殊的key有序的存放在codis slot中，保证mget/mset,以及lua脚本正常执行。我们目前大概管理200多个redis键，统一锁定到一个codis-server（slot）中。第二，在某些极端情况（不希望发生），如某codis-group中的master异常或崩溃时，我们从程序设计角度，尽可能对出现的无法进行操作KEY的行为做一些"某种意义上"保护。譬如，当某codis-group的maser宕机时，对codis进行写操作，如果对应的key落到宕机的主机上，会得到异常或者错误，可以通过捕获异常信息，将异常的key通过改变key名的规则将其存放到其他codis-group上。同理，如果是读取宕机主机上的key数据时，将其引导到调整后的key上，在一定程度上保障codis的完整性（不保障数据不丢失，只保证业务系统操作缓存数据完整性）。

有点意思的整改

在长达几年的迭代演变过程中，维护团队推动多次缓存服务架构的升级与优化，缓存服务逐渐完善和稳定。记下了一些“有点意思”的整改，提供大家参考。

热点数据

统计缓存热点数据，在基础缓存服务层上假设二级缓存，作为热点数据的快速通道，具备可动态获取，最快访问，少变化的特点。

根据缓存服务各主、子键关系，使用index_{主键}的方式来作为管理主子键关系的SortedSet集合，统计数据的使用频率，抽取Top100的数据，作为热点数据。对这批数据进行分析，结合数据的改动频率，制定这批数据缓存在内存中的时长。

二级缓存设计

缓存数据列表生成与维护

内存缓存数据的key列表由缓存服务生成和维护，Key列表包括后台手动配置（如，10个）和系统根据使用热度生成（如，20个）共同组成，其中cache-manager的jar包只负责对该数据使用，通过定时任务获取codis中的前20位和后台手动配置的相关数据，期间要保证获取到数据的有效性。

维护本地内存中的数据

自然统计内存缓存： 用sortedSet集合，统计各主键下的所有键Get的次数，汇总成score_{主键}方式的集合。利用ZIncrby命令统计对应的子键的次数，最终汇总每个主键，统计出Top100的key，利用zunionstore命令将信息统计汇总作为内存缓存的基础，此集合内数据均从内存中获取。

管理类内存缓存： 分析和统计项目主流程的关键的基础缓存数据保存到内存中,保障对应区域的数据获取与缓存时间，在离开数据源后能够最大程度的展现畅途网的功能。

在发生手动更新时，对内存中对应的主键进行更新

在发生更新时，由后台发起，在缓存服务向codis中置入标志位，各客户端在定时任务中获取标志位，如果标志位（cache_memory_update_flag）为Y，则清空内存和Key规则表，等到下一个更新周期来临重新获取数据。

总结

多年后，再回想年少时的迷茫和执著，或许原因都记不得了。青春就是让你张扬的笑，也给你莫名的痛。——林语堂《人生不过如此》

经过大半年的时间测试、缓存服务接口改造，在2016年9月份，赶在国庆前，我们的Codis3.0上线了，在车次查询等方面，有了质的飞越，尤其节假日或高峰期期间，平滑的扩缩容、数据迁移、高可用等方面展示出巨大优势。

三个codis_proxy节点的均衡情况：

    ipvsadm -Ln
      -> RemoteAddress:Port Forward Weight ActiveConn InActConn
    FWM  3 rr
      -> 192.168.0.**:19000   Local   1 1560  7
      -> 192.168.0.**:19000   Route   1 1534  5 
      -> 192.168.0.**:19000   Route   1 1498  1

1年后，2018年8~9月份，我们将Codis升级到3.2的，由之前6台服务器，扩展到7台，实际上多一台Codis-web节点，独立承担Codis-fe、Codis-dashboard等组件。对于Redis-Sentinel、Codis-fe等组件的引进，解决了运维人员很多问题，在此不再描述，有兴趣的可以参考。
https://github.com/CodisLabs/codis/blob/3.2.2/doc/tutorial_zh.md

目前Codis作为最为核心的缓存层，一如既往的稳定输出，肩负起它的神圣使命！

创作场景

这些年，我们一起追过的缓存数据库