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
  错误信息:

• 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 内存弹性扩容

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
  错误信息:

• 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 内存弹性扩容