三、应用最佳实践

  1. 云栖社区>
  2. rediscn>
  3. 博客>
  4. 正文

三、应用最佳实践

玄学酱 2018-02-27 15:18:00 浏览849
展开阅读全文
  • redis cluster的稳定性如何?
  • 存在哪些坑?
  • develop guideline & best practice

1、稳定性
  • 不扩容时集群非常稳定。
  • 扩容resharding时候,早期版本的Jedis端有时会出现“max-redirect”异常。
    分析Jedis源码,请求重试次数达到了上限,仍然没有请求成功。两方面分析:redis连接不上?还是集群节点信息不一致?
  • 存活检测机制缺陷
      redis 存活检测机制可能因为master 节点上慢查询、阻塞式命令、或者其它的性能问题导致长时间没有响应,这个节点会认为处于failed状态,并进行切换。这种切换是没必要的。    优化策略:a) 默认的cluster-node-timeout为15s,可以适当增大;
    b) 避免使用会引起长时间阻塞的命令,比如save/flushdb等阻塞操作,或者keys pattern这种慢查询。
总体来说,redis cluster已经非常稳定了,但是要注意一些应用中的小问题,下面是5个坑,大家注意了。

2、有哪些坑?

2.1 迁移过程中Jedis“Max Redirect”异常。

  • github上讨论的结果是程序retry。
  • max redirt issues:https://github.com/xetorthio/jedis/issues/1238
  • retry时间应该大于failover 时间。
  • Jedis参数优化调整:增大jedis中的‘DEFAULT_MAX_REDIRECTIONS’参数,默认值是5.
  • 避免使用multi-keys操作,比如mset/mget. multi-key操作有些客户端没有支持实现。

2.2 长时间阻塞引起的不必要的failover
  • 阻塞的命令。比如save/flushall/flushdb
  • 慢查询。keys *、大key的操作、O(N)操作
  • rename危险操作:
    • rename-command FLUSHDB REDIS_FLUSHDB
    • rename-command FLUSHALL REDIS_FLUSHALL
    • rename-command KEYS REDIS_KEYS

2.3 同时支持ipv4和ipv6侦听服务埋下的坑
具体现象:redis启动正常,节点的协议端口只有ipv6 socket创建正常。异常节点也无法加入到集群中,也无法获取epoch。
解决方法:启动时指定网卡ipv4地址,也可以是0.0.0.0,配置文件中添加:bind 0.0.0.0
这个是在setup集群的时候发生过的一个问题,bind 0.0.0.0虽然存在一些安全性问题,但是是比较简单通用的解决方法。

2.4 数据迁移速度较慢
  • 主要使用的redis-trib.rb reshard来完成数据迁移。
  • redis-3.0.6版本以前migrate操作是单个key逐一操作。从redis-3.0.6开始,支持单次迁移多个key。
  • redis集群内部最多只允许一个slot处于迁移状态,不能并发的迁移slots。
  • redis-trib.rb reshard如果执行中断,用redis-trib.rb fix修复集群状态。

2.5 版本选择/升级建议
  • 我们已经开始使用3.0.7版本,很多3.2.0修复的bug已经backport到这个版本。
  • 另外我们也开始测试3.2.0版本,内存空间优化很大。
  • Tips
    • redis-trib.rb支持resharding/rebalance,分配权重。
    • redis-trib.rb支持从单个redis迁移数据到cluster集群中。后面2点不算坑把,算是不足,tips也很实用.开始分享下最佳实践。

3、最佳实践3.1 应用做好容错机制
  • 连接或者请求异常,进行连接retry和reconnect。
  • 重试时间应该大于cluster-node-time时间
    还是强调容错,这个不是针对cluster,所有的应用设计都适用。

3.2 制定开发规范
  • 慢查询,进程cpu 100%、客户端请求变慢,甚至超时。
  • 避免产生hot-key,导致节点成为系统的短板。
  • 避免产生big-key,导致网卡打爆、慢查询。
  • TTL, 设置合理的ttl,释放内存。避免大量key在同一时间段过期,虽然redis已经做了很多优化,仍然会导致请求变慢。
  • key命名规则。
  • 避免使用阻塞操作,不建议使用事务。
    开发规范,使你们的开发按照最优的方式使用nosql。

3.3 优化连接池使用
  • 主要避免server端维持大量的连接。
  • 合理的连接池大小。
  • 合理的心跳检测时间。
  • 快速释放使用完的连接。
  • Jedis一个连接创建异常问题(fixed):
    https://github.com/xetorthio/jedis/issues/1252
连接问题是redis开发使用中最常见的问题,connection timeout/read timeout,还有borrow connection的问题。

3.4 区分redis/twemproxy和cluster的使用
  • redis建议使用pipeline和multi-keys操作,减少RTT次数,提高请求效率。
  • twemproxy也支持pipeline, 支持部分的multi-key可以操作。
  • redis cluster不建议使用pipeline和multi-keys操作,减少max redirect产生的场景。
区分redis 和 cluster的使用,一方面是数据分片引起的;另一方面,与client的实现支持相关。

3.5 几个需要调整的参数
1)设置系统参数vm.overcommit_memory=1,可以避免bgsave/aofrewrite失败。
2)设置timeout值大于0,可以使redis主动释放空闲连接。
3)设置repl-backlog-size 64mb。默认值是1M,当写入量很大时,backlog溢出会导致增量复制不成功。
4)client buffer参数调整
     client-output-buffer-limit normal 256mb 128mb 60
     client-output-buffer-limit slave  512mb  256mb 180





本文作者:geelou
本文来自云栖社区合作伙伴rediscn,了解相关信息可以关注redis.cn网站。

网友评论

登录后评论
0/500
评论
玄学酱
+ 关注
所属云栖号: rediscn