Suzf Blog

高可用开源的 Redis 缓存集群方案

Jeffrey Mar 21, 2016 redis

由于单台Redis服务器的内存管理能力有限，使用过大内存的Redis又会使得服务器的性能急剧下降，一旦服务器发生故障将会影响更大范围业务，而Redis 3.0 beta1支持的集群功能还不适合生产环境的使用。于是为了获取更好的Redis缓存性能及可用性，很多公司都研发了Redis缓存集群方案。现对NetFlix、Twitter、国内的豌豆荚在缓存集群方面的解决方案进行一个汇总，以供读者参考，具体内容如下：

1、NetFlix对Dynamo的开源通用实现Dynomite

Dynomite是NetFlix对亚马逊分布式存储引擎Dynamo的一个开源通用实现，使用C/C++语言编写、以代理的方式实现的Redis缓存集群方案。Dynomite不仅能够将基于内存的Redis和Memcached打造成分布式数据库，还支持持久化的MySQL、BerkeleyDB、LevelDB等数据库，并具有简单、高效、支持跨数据中心的数据复制等优点。Dynomite的最终目标是提供数据库存储引擎不能提供的简单、高效、跨数据中心的数据复制功能。Dynomite遵循Apache License 2.0开源协议发布，更多关于Dynomite的信息请查看NetFlix技术博客对Dynomite的介绍。

2、Twitter的Redis/Memcached代理服务Twemproxy

Twemproxy是一个使用C语言编写、以代理的方式实现的、轻量级的Redis代理服务器，它通过引入一个代理层，将应用程序后端的多台Redis实例进行统一管理，使应用程序只需要在 Twemproxy上进行操作，而不用关心后面具体有多少个真实的Redis或Memcached实例，从而实现了基于Redis和Memcached的集群服务。当某个节点宕掉时，Twemproxy可以自动将它从集群中剔除，而当它恢复服务时，Twemproxy也会自动连接。由于是代理，所以 Twemproxy会有微小的性能损失。根据 Redis作者的测试结果，在大多数情况下，Twemproxy的性能相当不错，同直接操作Redis相比，最多只有20%的性能损失。 Twemproxy遵循Apache License 2.0开源协议发布，更多关于Twemproxy的信息请登录其在GitHub的主页查看。

3、豌豆荚的 Redis 集群解决方案Codis

Codis是豌豆荚使用Go和C语言开发、以代理的方式实现的一个Redis分布式集群解决方案,且完全兼容Twemproxy。Twemproxy对于上一层的应用来说, 连接Codis Proxy（Redis代理服务）和连接原生的Redis服务器没有明显的区别,上一层应用能够像使用单机的 Redis一样对待。Codis底层会处理请求的转发、不停机的数据迁移等工作, 所有底层的一切处理, 对于客户端来说是透明的。总之，可以简单的认为后台连接的是一个内存无限大的Redis服务。Codis遵循MIT开源协议发布，更多关于Codis的信息请登录其在GitHub的主页查看。

另外，还有一些未开源的解决方案，比如新浪、百度、淘宝、腾讯等的Redis集群方案。在Redis官方正式推出可用于生产环境的集群方案前，以上三种方案是非常值得考虑在生产环境使用的方案。

Redis 常用命令总结

Jeffrey Mar 21, 2016 redis

Redis 提供了丰富的命令（ command）对数据库和各种数据类型进行操作下面对常用操作做出简单总结, 希望对大家有所帮助。 Redis commands -- http://redis.io/commands *** redis 默认端口 6379 *** redis-cli -p ${port} # 指定端口

Nginx+Redis+Tomcat实现session共享的集群

Jeffrey Mar 18, 2016 redis

Nginx 作为目前最流行的开源反向代理HTTP Server，用于实现资源缓存、web server负载均衡等功能，由于其轻量级、高性能、高可靠等特点在互联网项目中有着非常普遍的应用，相关概念网上有丰富的介绍。分布式web server集群部署后需要实现session共享，针对 tomcat 服务器的实现方案多种多样，比如 tomcat cluster session 广播、nginx IP hash策略、nginx sticky module等方案，本文主要介绍了使用 redis 服务器进行 session 统一存储管理的共享方案。

使用Nginx作为Tomcat的负载平衡器，Tomcat的会话Session数据存储在Redis，能够实现0当机的7×24运营效果。因为将会话存储在Redis中，因此Nginx就不必配置成stick粘粘某个Tomcat方式，这样才能真正实现后台多个Tomcat负载平衡，用户请求能够发往任何一个tomcat主机，当我们需要部署新应用代码时，只要停止任何一台tomcat，所有当前在线用户都会导向到运行中的tomcat实例，因为会话数据被序列化到Redis，在线用户不会受到影响，一旦停掉的tomcat实例上线，另外其他重复部署过程。

Redis Sentinel Test

Jeffrey Mar 17, 2016 redis

Redis Sentinel 是一套用于管理Redis实例的分布式系统,主要完成3项任务:

1. Monitoring:持续监控Redis master或slave实例的运行情况是否符合预期
2. Notification:若被监控的Redis实例运行异常,sentinel会通过API通知外界（人或程序）
3. Automation failover:若master实例故障,sentinel会重新选主并启动自动故障切换:选择slave-priority最小的那个slave实例并将其提升为master,同时修改其它slave的配置,使其master配置项指向新的master,当old master恢复重启后,会自动降级为new master的slave.最后,根据配置,Redis Sentinel还会将新的master地址通知给当前正在访问Redis的应用程序.

Redis 主从复制

Jeffrey Mar 17, 2016 redis

Redis 安装见 Redis Setup

环境
CentOS 6.x
Redis=3.0.7

master01
port 1111
192.168.9.10/24

ocean-lab
port 2222
192.168.9.70/24

主从复制
1.为什么使用，好处？
1.1 单个redis服务器压力过大，可考虑，master写，slave读，分散缓解服务器压力。
1.2 一个master可以拥有多个slave，而一个slave又可以拥有多个slave

2.主从复制过程
2.1 master、slave 建立连接且slave 向master 发起同步请求
2.2 请求成功之后 slave 接受master发送过来的dump.rdb的快照文件
2.3 slave载入dump.rdb文件
2.4 当master和slave的连接断开时slave可以自动重新建立连接。如果master同时收到多个 slave发来的同步连接命令，只会使用启动一个进程来写数据库镜像，然后发送给所有slave。

Redis 监控技巧

Jeffrey Mar 14, 2016 redis

本文来自 Bugsnag 的联合创始人 Simon Maynard 的系列文章，作者根据几年来对 Redis 的使用经历，对 Redis 监控方法进行了系统性的总结，干货很多，值得一看。

原文链接：Redis Masterclass – Part 2, Monitoring

Redis 监控最直接的方法当然就是使用系统提供的 info 命令来做了，你只需要执行下面一条命令，就能获得 Redis 系统的状态报告。

redis-cli info

内存使用

如果 Redis 使用的内存超出了可用的物理内存大小，那么 Redis 很可能系统会被 OOM Killer 杀掉。针对这一点，你可以通过 info 命令对 used_memory 和 used_memory_peak 进行监控，为使用内存量设定阈值，并设定相应的报警机制。当然，报警只是手段，重要的是你得预先计划好，当内存使用量过大后，你应该做些什么，是清除一些没用的冷数据，还是把 Redis 迁移到更强大的机器上去。

持久化

如果因为你的机器或 Redis 本身的问题导致 Redis 崩溃了，那么你唯一的救命稻草可能就是 dump 出来的 rdb文件了，所以，对 Redis dump 文件进行监控也是很重要的。你可以通过对 rdb_last_save_time 进行监控，了解你最近一次 dump 数据操作的时间，还可以通过对 rdb_changes_since_last_save 进行监控来知道如果这时候出现故障，你会丢失多少数据。

主从复制

如果你设置了主从复制模式，那么你最好对复制的情况是否正常做一些监控，主要是对 info 输出中的 master_link_status 进行监控，如果这个值是 up，那么说明同步正常，如果是 down，那么你就要注意一下输出的其它一些诊断信息了。比如下面这些：

role:slave master_host:192.168.1.128 master_port:6379 master_link_status:down master_last_io_seconds_ago:-1 master_sync_in_progress:0 master_link_down_since_seconds:1356900595

Fork 性能

当 Redis 持久化数据到磁盘上时，它会进行一次 fork 操作，通过 fork 对内存的 copy on write 机制最廉价的实现内存镜像。但是虽然内存是 copy on write 的，但是虚拟内存表是在 fork 的瞬间就需要分配，所以 fork 会造成主线程短时间的卡顿（停止所有读写操作），这个卡顿时间和当前 Redis 的内存使用量有关。通常 GB 量级的 Redis 进行 fork 操作的时间在毫秒级。你可以通过对 info 输出的 latest_fork_usec 进行监控来了解最近一次 fork 操作导致了多少时间的卡顿。

配置一致

Redis 支持使用 CONFIG SET 操作来实现运行实的配置修改，这很方便，但同时也会导致一个问题。就是通过这个命令动态修改的配置，是不会同步到你的配置文件中去的。所以当你因为某些原因重启 Redis 时，你使用 CONFIG SET 做的配置修改就会丢失掉，所以我们最好保证在每次使用 CONFIG SET 修改配置时，也把配置文件一起相应地改掉。为了防止人为的失误，所以我们最好对配置进行监控，使用 CONFIG GET 命令来获取当前运行时的配置，并与 redis.conf 中的配置值进行对比，如果发现两边对不上，就启动报警。

慢日志

Redis 提供了 SLOWLOG 指令来获取最近的慢日志，Redis 的慢日志是直接存在内存中的，所以它的慢日志开销并不大，在实际应用中，我们通过 crontab 任务执行 SLOWLOG 命令来获取慢日志，然后将慢日志存到文件中，并用 Kibana 生成实时的性能图表来实现性能监控。

值得一提的是，Redis 的慢日志记录的时间，仅仅包括 Redis 自身对一条命令的执行时间，不包括 IO 的时间，比如接收客户端数据和发送客户端数据这些时间。另外，Redis 的慢日志和其它数据库的慢日志有一点不同，其它数据库偶尔出现 100ms 的慢日志可能都比较正常，因为一般数据库都是多线程并发执行，某个线程执行某个命令的性能可能并不能代表整体性能，但是对

来说，它是单线程的，一旦出现慢日志，可能就需要马上得到重视，最好去查一下具体是什么原因了。

监控服务

-Sentinel

Sentinel 是 Redis 自带的工具，它可以对 Redis 主从复制进行监控，并实现主挂掉之后的自动故障转移。在转移的过程中，它还可以被配置去执行一个用户自定义的脚本，在脚本中我们就能够实现报警通知等功能。

-Redis Live

Redis Live 是一个更通用的 Redis 监控方案，它的原理是定时在 Redis 上执行 MONITOR 命令，来获取当前 Redis 当前正在执行的命令，并通过统计分析，生成web页面的可视化分析报表。

-Redis Faina

Redis Faina 是由著名的图片分享应用 instagram 开发的 Redis 监控服务，其原理和 Redis Live 类似，都是对通过 MONITOR 来做的。

数据分布

弄清 Redis 中数据存储分布是一件很难的是，比如你想知道哪类型的 key 值占用内存最多。下面是一些工具，可以帮助你对 Redis 的数据集进行分析。

-Redis-sampler

Redis-sampler 是 Redis 作者开发的工具，它通过采样的方法，能够让你了解到当前Redis 中的数据的大致类型，数据及分布状况。

-Redis-audit

Redis-audit 是一个脚本，通过它，我们可以知道每一类 key 对内存的使用量。它可以提供的数据有：某一类 key 值的访问频率如何，有多少值设置了过期时间，某一类 key 值使用内存的大小，这很方便让我们能排查哪些 key 不常用或者压根不用。

-Redis-rdb-tools

Redis-rdb-tools跟 Redis-audit 功能类似，不同的是它是通过对 rdb 文件进行分析来取得统计数据的。

来源: nosqlfan

Redis 安装与特性简述