• 进入"运维那点事"后,希望您第一件事就是阅读“关于”栏目,仔细阅读“关于Ctrl+c问题”,不希望误会!

Redis Cluster应用最佳实践

Redis 彭东稳 7年前 (2017-07-26) 31571次浏览 已收录 0个评论

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命名规则。
  • 避免使用阻塞操作,不建议使用事务。

PS:开发规范,使你们的开发按照最优的方式使用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

本内容来自唯品会Redis Cluster大规模生产实践文章。


如果您觉得本站对你有帮助,那么可以支付宝扫码捐助以帮助本站更好地发展,在此谢过。
喜欢 (6)
[资助本站您就扫码 谢谢]
分享 (0)

您必须 登录 才能发表评论!