Mr-Redis 的github 地址是https://github.com/mesos/mr-redis，是华为基于mesos开发的一个redis framework, 方便管理redis实例和集群
Mr-Redis特点
充分使用数据中心的资源, 通过dashboard统一管理
创建一个redis实例的时间为秒级
-
failover的时间为秒级
(这个沙箱测试时把redis容器stop, 几秒种内会自动启动，不过ip和端口会发生变化，但节点redis数据会丢失，一主多从的模式数据不会丢失)
客服系统中的试用场景
- redis当作cache使用
在微服务场景中，每个微服务单独一个实例，redis吞吐量小但实例多的场景
有的微服务把redis当作db使用，这种情况下redis必须是持久化和高可用的
和sentinel相比MrRedis的高可用方案更简单
部署架构
- 通过MrRedis创建Redis实例(单实例，或者一主多从)
- redis实例信息存储在zk中
- 每个mesos上的服务通过本地的proxy (HAProxy or go-proxy)代理redis请求到真正的redis实例
为了使 go-proxy自动从zk读取redis实例的更新信息，对原来的go-proxy添加了几个功能
去掉config.json这个依赖, 初始化还有同步操作都从zk中读取
-
确保redis的本地proxy转发端口对所有mesos agent的唯一性 (利用zk实现的)
最开始考虑的做法是想根据redis name hash成一个固定并且唯一的 在6100 - 6300区间的一个端口号， 不过这种方式可能冲突几率比较大
本地proxy每次启动的时候都去zk读取本地监听的端口号 (eg: 6166)
新建redis,随机选取6100 ~ 6300 之间的一个端口号 并且在zk里不存在，然后存到zk里
-
采用轮询方式
之前准备用zk的watch机制来及时更新内存中map里的redis实例信息，不过go实现的curator里的ChildrenCache没有实现，而TreeCache并不适合MrRedis的zk数据结构， 所有就采用最简单的轮询方式了
reference: https://github.com/zousheng/mr-redis
目前沙箱测试情况
手动stop redis实例容器后2秒中，redis会自动发生failover, 通过localhost访问proxy没有任何影响, 对客户端是透明的， 高可用是可以保证的
-
sched 模块重启后 dashbord里的信息都不在了，重启过程中没有从zk中重新获取一次，必须显示的逐个获取每个redis子节点信息后，dashbaorad才会显示，bug已经记录在https://github.com/mesos/mr-redis/issues/68 中了。
临时解决方案: 在marathon的sched task中，把health check改为command模式，这样定期获取zk中redis实例信息，这样重启sched就可以获取到所有的redis 信息了。
Note:
最开始我是把获取zk redis的shell命令放到启动sched的命令后面，
e.g.
work=/data/app/go_projects/src/github.com/mesos/mr-
redis/sched
cd $work && ./sched -config='config.json'
redis_instances=`curl -s 127.0.0.1:7979/Get/|jq .[].Name |tr -d '"'`;
if [ -n "$redis_instances" ]; then for redis in `echo
$redis_instances`; do curl localhost:5656/v1/STATUS/${redis} ;
done; fi
sched 启动命令后面， 但是这么做
是不生效的，因为服务启动后就变成阻塞的了，后面的命令不会被
执行到。突然想到health check中的command模式可以解决这个问
题，把health check的tcp模式改为COMMAND模式，命令行为
redis_instances=`curl -s 127.0.0.1:7979/Get/|jq .[].Name |tr -d '"'`;
if [ -n "$redis_instances" ]; then
for redis in `echo $redis_instances`;
do
curl localhost:5656/v1/STATUS/${redis} ;
done;
fi
这样配置后每次重启sched，dashboard中的数据就不会丢失了。
总结：
目前MrRedis的使用者还很少，相关资料也很少，很多坑都需要自己摸索。期间参考了张开涛涛哥公众号里介绍的JIMDB设计和实现，使我意识到MrRedis还有很多重要的特性没有支持， 比如在线全自动弹性伸缩，部分复制扩容，缩短扩容时间等等。 所以MrRedis目前看只能算一个半成品，下阶段我们会努力尝试完善这部分功能。
