Mr-Redis是华为基于mesos开发的一个redis framework , 方便管理 redis 实例和集群 （github url: https://github.com/mesos/mr-redis）。Mr-Redis 可以创建单个实例，也可以创建主从实例，并实现了高可用, 这比使用 redis-sentinel 来实现 redis 高可用架构上简单很多。下面是我从测试Mr-Redis到上线过程中遇到的问题，希望对正在打算使用和调研Mr-Redis的同学有所帮助...
Mr-Redis特点
充分使用数据中心的资源
创建一个redis实例的时间为秒级
-
failover 的时间为秒级
(在沙箱测试failover时把 redis 容器stop, 几秒种内会启动一个新的redis容器，ip和端口可能会发生变化，没有做主从的 redis 数据会丢失，做了主从的数据不会丢失)
Mr-Redis 解决了客服系统中哪些问题
每个微服务都拥有自己的
redis, 所以随着业务增长，微服务的拆分，redis实例会不断的增长，通过Mr-Redis统一管理可以简化运维工作量Mr-Redis提供了 redis 的高可用，解决线上 redis 单点的问题
部署架构
使用 Mr-Redis 遇到的问题
-
通过
Mr-Redis部署的 redis 性能会损失多少和作者 Dhilip Kumar 聊过,他说 redis 性能会损失 30% 左右，当时不确定性能是在哪里损失掉的，经过沙箱测试发现性能是损失在proxy转发上面了，我的压测结果显示go-proxy损失了30-40％的性能，以后会逐步分析这个proxy是不是有改进的空间。｀如果服务对 redis qps 要求特别高，建议考虑其他集群方案`**
-
redis 实例 failover 后， 客户端如何发现新的redis 地址
为了解决这个问题，我们做了如下改进:
- redis 信息储存在 zk 里， 去掉 config.json 这个依赖, 初始化还有同步操作都从zk中读取
- 每个 mesos slave 机器上的 proxy 所代理的 redis 在本地的转发端口是一致的 (利用zk的一致性实现的)
1. 最开始考虑的做法是想根据redis name hash成一个固定并且唯一的 在6100 - 6300区间的一个端口号， 不过这种方式可能冲突几率比较大 2. 本地proxy每次启动的时候都去zk读取本地监听的端口号 (eg: 6166) 3. 新建redis,随机选取6100 ~ 6300 之间的一个端口号 并且在zk里不存在，然后存在zk 4. 采用轮询方式，proxy 会定时去获取 zk 中 redis 相关信息 之前准备用zk的事件通知机制来处理, 不过由于 Mr-Redis 在 zk 中的数据结构复杂， 不能 通过childrenW 简单的实现， 所以只好折衷选择了轮训的方式来获取 proxy 代理的 redis 信息
-
scheduler 重启之后不会从zk中load redis信息，dashboard上不会显示任何redis实例，但是redis实例确实还在运行。
这个问题可以通过一个 tricky 的方式来解决，在 zk 中查询出所有运行中的 redis 实例名称(eg. redis_name), 对每一个实例执行 curl <scheduler_ip>:5656/v1/STATUS/redis_name, 执行完这个命令， dashboard 上就会显示所有运行的 redis 实例
-
在 dashboard 中创建 redis 实例，dashboard 上不会自动更新
可以手动刷新，如果有时间可以帮忙解一下这个bug
-
MrRedisExecutor 运行过程中 docker pull 拉取 redis 镜像的时候会连接外网，如果没有外网会报错。为了解决这个问题可以在内网环境里可以为 dockerd 配置代理 也可以在内网里搭建自己的 docker registry
https://docs.docker.com/engine/admin/systemd/#httphttps-proxy错误信息:
dockerd: time="2017-08-29T12:19:16.361567332+08:00" level=error msg="Not continuing with pull after error: Network timed out while trying to connect to https://index.docker.io/v1/repositories/library/redis/images. You may want to check your internet connection or if you are behind a proxy." -
mr-redis scheduler 配置文件中不支持写多zk地址, 导致 zk 会成为单点
提了一个pr
https://github.com/mesos/mr-redis/pull/70需要重新编译 scheduler 和 MrRedisExecutor.
-
Mr-Redis scheduler 高可用不能像 marathon 那样实现 failover (3个实例，一个 leader, 另外2个 follower, 当 leader 挂掉的时候，follower会自动选举出leader）, scheduler 的 leader 挂掉后，另外2个 follower 没有得到通知。解决方法:通过 marathon 只起一个 scheduler 实例， constrains 配置为 hostname:UNIQUE, 这样配置如果 scheduler 所在服务器宕机， 会在其他机器重新启动一个scheduler, 并重新连接master。经过多种 redis 破坏性测试，redis 都是可以 failover的。
需要改进的地方
- 查看本地 redis 代理监听端口列表需要通过api调用，可以考虑加到dashboard上方便查看
- 提供 proxy 转发性能, 减少 redis qps 损耗
- redis 内存弹性扩容
