redis全套参数配置及降级解决方案

文章目录

  • redis高可用核心参数配置
    • 1.Lettuce
    • 2.Jedis
    • 3.Redisson
    • 4.其他客户端
  • redis降级场景简介
  • 一、业务背景
  • 二、设计方案
  • 三、实现方案
  • 四、总结


redis高可用核心参数配置

1.Lettuce

提示:该客户端无主动探活机制,只能依赖于 OS KeepaAlive 机制,探测周期过长,且底层采用共享连接,遇到网络抖动或故障时,影响半径较大,强烈建议换为Jedis

2.Jedis

  • 需要通过设置连接探活机制缩短影响时间。建议将testWhileIdle设置为true;对于业务连接极端敏感的,并且节点连接数在5000以下(是节点连接数,不是集群连接数),testOnBorrow也可以配置为true;
  • 将Jedis版本升级到>=3.6.1;
  • Jedis全套高可用配置可参考另一篇。

3.Redisson

  • 需要通过设置连接探活机制缩短影响时间。建议将pingConnectionInterval调小,设置为3000ms;
  • 关闭读写分离。将readMode和subscriptionMode设置为MASTER;
  • 将Redission版本升级到>3.18.0;
  • Redission全套高可用配置可参考另一篇。

4.其他客户端

  • 其他客户端(Python、Node.js、PHP等)需要进行模拟测试Redis节点主备切换的情况下服务是否仍能正常连接redis

redis降级场景简介

提示:连接redis集群带有重试连接机制和实例转移连接机制,所以导致每一个请求中对redis的连接非常耗时

场景一:业务存在下游资源支撑如数据库或其他存储实例,这种情况只需要处理redis连接异常导致的接口请求超时问题,采用的方式为初次超时捕获连接异常后向监控系统抛出特定告警,打印日志。随后查询下游存储实例获取数据返回。告警向运维人员发送通知,修改逻辑参数后重启实例,使后续每次查询都直接访问下游存储实例避免浪费时间,同时安排redis恢复工作,待恢复好后修改再参数重启。

场景二:SDK里的redis损毁,无直接可用的下游存储实例支撑。处理方案为在redis中维护一个本地缓存如caffeine,定时同步redis数据至本地缓存,当redis崩溃或连接超时直接访问本地缓存。或创建Redis数据的直接操作方系统,开启备用的接口调用,由第三方的系统服务加第三方数据库提供SDK-Redis降级支撑,最差的方案可以直接mock静态数据返回,满足核心业务流程不阻塞。


一、业务背景

  • 认证验权服务中台提供的用于分布式会话权限管理功能的SDK,里的redis组件存在崩溃风险,需要对其做出降级,用于支持在redis崩溃后,不影响某段时间内已登录过的用户的正常使用。可以拒绝登录业务流程

二、设计方案


三、实现方案


四、总结

提示:这里对文章进行总结:
例如:以上就是今天要讲的内容,本文仅仅简单介绍了pandas的使用,而pandas提供了大量能使我们快速便捷地处理数据的函数和方法。

你可能感兴趣的:(redis,java)