Redis最佳实践

这篇具有很好参考价值的文章主要介绍了Redis最佳实践。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

Redis最佳实践

Redis键值设计

优雅的key结构
  • 遵循基本格式:[业务名称]:[数据名]:[id] eg:login:user:10
  • 长度不超过44字节:key为string类型,底层编码为int,embstr和raw(>44)三种。embstr在小于44字节使用,采用连续内存空间,占用小。
  • 不包含特殊字符
拒绝BigKey

BigKey通常以key的大小和key中成员的数量来综合判断,例如:

  • key本身的数据量过大:一个string类型的key,它的值为5MB
  • key中的成员数过多:一个ZSET类型的key,他的成员数量为10000个
  • ke0y中成员的数据量过大:一个Hash类型的key,它的成员数量虽然只有1000个,但value总大小为100MB

扩展:查看key大小:MEMORY USAGE key/value 简单:STRLEN key/LLEN key
推荐:1.单个key的value小于10KB 2.对于集合类型的key,建议元素数量小于1000

BigKey危害
  • 网络阻塞:对BigKey执行读,少量QPS就可能导致贷款使用率被占满,导致Redis变慢
  • 数据倾斜:BigKey所在的内存使用率远超其他实例,无法使数据分片的内存资源达到平衡
  • Redis阻塞:对元素较多的hash,list,zset等做运算会耗时较久,使主线程阻塞
  • CPU压力:对BigKey的数据序列化和反序列化会导致CPU飙升,影响Redis实例和本机其他应用。

如何发现BigKey:

  • redis-cli --bigkeys:可遍历所有key,返回key整体统计信息与每个数据的Top1的bigkey
  • scan扫描:自己编程,利用strlen,hlen等命令判断key长度(不建议用MEMORY USAGE)
  • 第三方工具:Reids-Rdb-Tools分析RDB快照文件
  • 网络监控:自定义工具,监控进出Reids的网络数据,超出预警值主动警告

如何删除BigKey:

  • 小于redis3:集合类型遍历所有key,先逐个删除子元素,最后删除BigKey
  • 大于redis4:异步删除命令:unlink
恰当的数据结构

推荐hash按照key打散,底层使用zipList,空间占用小,可灵活访问对象的任意字段,不推荐直接存jsonstring,hash和单个key数据
注意:hash的Entry数量超过500,会使用hash表而不是ZipList,可以调整hash-max-ziplist-entries配置entry上限,设置太大也会BigKey。

总结

key:固定格式,简短,不包含特殊字符
value:合理拆分,不BigKey。合适的数据结构。hash结构entry数量不超过1000。设置合理的超时时间。

批处理优化(如何优雅的处理海量数据)

Pipeline-大数据导入方式

MSET,HSET方式:
N条命令的批处理行:1次网络传输时间+N次Redis执行耗时
注意:不要在一次批处理中传输太多命令,否则单次命令占用带宽过多,会导致网路阻塞。

//按照奇偶数批量插入数据
void test{
    String[] arr = new String[2000];
    int j;
    for(int i = 0; i <= 10000; i++){
        j = (i%1000) << 1;
        arr[j] = "test:key_" + i;
        arr[j + 1] = "value_" + i;
        if(j == 0){  //当j=0时表示一组数据(1000)满了
            jedis.mset(arr);
        }
    }
}

缺点:格式固定只能操作基础数据类型,不能扩展复杂数据,建议使用Pipeline
Pipeline:

void testPipeline(){
    //创建管道
    Pipeline pipeline = jedis.pipelined();
    for(int i = 1; i<= 100000; i++){
        //放入命令到管道
        pipeline.set("test:key_" + i, "value_" + i);
        //pipeline.hset("test:key_" + i, "value_" + i);
        if(i % 1000 = 0){
            //每放入1000条命令,批量执行
            pipeline.sync();
        }
    }
}
总结:

批处理方案:原生M操作。Pipeline批处理
注意事项:批处理时不建议一次携带太多命令。Pipeline的多个命令之间不具备原子性

集群下的批处理

如MSET或Pipeline这样的操作需在一次请求中携带多条命令,而redis是集群那么批处理命令的多个key必须落在一个插槽内,否则就会执行失败。
spring底层采用并行slot,lettuce。springRedisTemplate.opsForValue().multiSet(map);:底层实现异步分区asynslot根据key计算插槽,把插槽一样的放在一个集合。
Redis最佳实践

服务端优化

持久化配置

Redis持久化虽然可以保证数据安全,但会带来额外开销,需遵循以下建议:

  1. 用来做缓存的Redis实例尽量不要开启持久化
  2. 建议关闭RDB,使用AOF
  3. 利用脚本定期在salve节点做RDB,实现数据备份
  4. 设置合理的rewrite阈值,避免频繁bgrewrite
  5. 配置no-appendfsync-no-rewrite=yes(追求安全性配置no,性能yes),禁止在rewrite期间做aof,避免AOF引起的阻塞。

部署建议:

  1. Redis实例的物理机要预留足够内存,应对fork和rewrite
  2. 单个Redis实例内存上限不要太大,eg:4/8G,可以加快fork的速度,减少主从同步,数据迁移的压力。
  3. 不要与CPU密集型应用部署在一起。
  4. 不要与高硬盘负载应用一起部署。eg:数据库,消息队列。
慢查询

在Redis执行时耗时超过某个阈值的命令,成为慢查询。由于Redis单线程,客户端发送指令后会在服务端入队等待执行,超过阈值则报错。
慢查询的阈值配置:slowlog-log-slower-than:慢查询阈值,微秒。默认10000,建议1000
慢查询会被存入日志,日志长度配置:slowlog-max-len:默认128,建议1000
查询慢查询:slowlog get[n]
清空慢查询列表:slowlog reset

命令及安全配置

Redis会绑定在0.0.0.0:6379,这样将会将Redis服务暴露在公网,而redis没做身份认证,会出现严重的安全漏洞。
Redis未授权访问配合SSH key:https://cloud.tencent.com/developer/article/1039000
漏洞原因:

  • Redis暴露到公网,且没有密码
  • 利用了Redis的config set命令动态修改Redis配置
  • 使用了Root账号权限启动Redis

建议:

  1. 一定要设置密码,开启防火墙,不使用默认端口,不使用root账户启动redis
  2. 禁止线上使用:keys,flushall,flushdb,config set等命令。可利用rename-command禁用。
  3. bind:限制网卡,禁止外网网卡访问。
内存配置

当redis内存不足,会导致key频繁被删除,响应时间变长,QPS不稳定。内存占用超过90%就需要注意。
Redis最佳实践

  • 数据内存:BigKey,内存碎片 主要
  • 进程内存:redis进程占用内存(代码,常量池) 可忽略
  • 缓冲区内存:客户端缓冲区(输入,输出),AOF缓冲区,复制缓冲区。 波动大

Redis查看内存分配命令:info memory;memory xxx
内存缓冲区配置:

  • 复制缓冲区:主从复制的repl_backlog_buf,如果太小可能导致频繁的全量复制,影响性能。通过repl-backlog-size来设置。默认1mb
  • AOF缓冲区:AOF刷盘之前的缓存区域,AOF执行rewrite的缓冲区,无法设置容量上限。
  • 客户端缓冲区:分为输入输出缓冲区,输入缓冲区最大1G且不能设置。输出可以。

集群最佳实践

集群还是主从?集群存在一些问题:

  1. 集群完整性问题-reids默认配置中,如果发现一个插槽不可用,整个集群都会停止。建议设置为false
  2. 集群带宽问题-集群节点之间会不断的ping来确定集群中其他节点的状态,每次ping都会包含插槽信息集群状态信息

集群节点越多,集群状态信息数据量也越大,10个节点的相关信息可能达到1kb,此时每次集群互通需要的带宽非常高。
解决:
① 避免大集群,最好小于1000
② 避免在单个物理机中运行太多的Redis实例
③ 配置合适的cluster-node-timeout值文章来源地址https://www.toymoban.com/news/detail-420721.html

  1. 数据倾斜问题-bigkey或者批处理时使用相同的hashkey从而导致部分节点负担较重
  2. 客户端性能问题-节点的选择,读写分离的判断,插槽的判断
  3. 命令的集群兼容性问题-批处理问题方案
  4. lua和事务问题-集群下不好保证
    注意:单体Redis(主从)已经能达到万级别的QPS,并且也具备很强的高可用特性。如果主从能满足业务需要的情况下,尽量不要搭建Reids集群。

到了这里,关于Redis最佳实践的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • GaussDB表设计最佳实践

    目录 如何选择存储模型 如何选择数据分布方式 如何选择分布列 其他最佳设计建议 使用局部聚簇 使用分区表 选择数据类型 进行数据库设计时,表设计上的一些关键项将严重影响后续整库的查询性能。表设计对数据存储也有影响:好的表设计能够减少I/O操作及最小化内存使

    2023年04月09日
    浏览(43)
  • 软件架构设计最佳实践(课程大纲)

    课程介绍: 1、深入阐述软件架构设计的思想、方向及趋势; 2、剖析软件架构的全景视图; 3、结合实际案例分析架构设计过程及需求对架构的影响; 4、如何实用设计模式来实现好的架构; 5、实践分享多种类型架构设计的实现; 6、SOA架构、企业集成系统架构、企业门户架

    2023年04月21日
    浏览(50)
  • 一文了解函数设计的最佳实践

    良好设计的函数具有清晰的职责和逻辑结构,提供准确的命名和适当的参数控制。它们促进代码复用、支持团队协作,降低维护成本,并提供可测试的代码基础。通过遵循最佳实践,我们能够编写出高质量、可读性强的代码,从而提高开发效率和软件质量。下面我们将一一描

    2024年02月10日
    浏览(31)
  • 延迟队列的设计与最佳实践

    在现代分布式系统中,延迟任务是一种非常重要的概念。它们可以用来处理需要特殊关注或执行的任务,如发邮件、推送消息或生成报告等。为了实现这些任务,我们需要一种强大而可靠的工具,即延迟队列。 在本博客中,我们将介绍延迟队列的设计和最佳实践。我们将使用

    2023年04月13日
    浏览(33)
  • 【最佳实践】如何设计 RESTful API ?

    良好的 API 设计是一个经常被提及的话题,特别是对于那些试图完善其 API 策略的团队来说。一个设计良好的 API 的好处包括:改进开发者体验、更快速地编写文档以及更高效地推广你的 API。但是,到底什么才构成了良好 API 设计呢?在这篇博客文章中,我将详细介绍几个为

    2024年02月07日
    浏览(34)
  • 物联网架构:设计与实现最佳实践

    物联网(Internet of Things, IoT)是指通过互联网技术将物体、设备、车辆等实体对象与互联网联网互联,使之能够互相传递信息、协同合作,从而实现智能化管理和控制。物联网技术已经广泛应用于各个行业,如智能家居、智能城市、智能交通、智能能源、医疗健康等。 物联网架

    2024年02月22日
    浏览(38)
  • 精通代码复用:设计原则与最佳实践

    在你开始设计的所有层次上,从单一函数、类,到整个库和框架,都需要从一开始就考虑到代码复用。在接下来的文本中,所有这些不同的层次都被称为组件。以下策略将帮助你合理地组织你的代码。注意,所有这些策略都专注于使你的代码具有通用性。设计可复用代码的第

    2024年02月08日
    浏览(48)
  • Java 设计模式最佳实践:6~9

    原文:Design Patterns and Best Practices in Java 协议:CC BY-NC-SA 4.0 译者:飞龙 本文来自【ApacheCN Java 译文集】,采用译后编辑(MTPE)流程来尽可能提升效率。 这一章将描述反应式编程范式,以及为什么它能很好地适用于带有函数元素的语言。读者将熟悉反应式编程背后的概念。我们

    2023年04月14日
    浏览(56)
  • 第九篇 API设计原则与最佳实践

    深入浅出HTTP请求前后端交互系列专题 第一章 引言-HTTP协议基础概念和前后端分离架构请求交互概述 第二章 HTTP请求方法、状态码详解与缓存机制解析 第三章 前端发起HTTP请求 第四章 前后端数据交换格式详解 第五章 跨域资源共享(CORS):现代Web开发中的关键机制 第六篇 提

    2024年01月23日
    浏览(44)
  • AI推理实践丨多路极致性能目标检测最佳实践设计解密

    摘要: 基于CANN的多路极致性能目标检测最佳实践设计解密。 本文分享自华为云社区《基于CANN的AI推理最佳实践丨多路极致性能目标检测应用设计解密》,作者: 昇腾CANN 。 当前人工智能领域,最热门的无疑是以ChatGPT为代表的各种“新贵”大模型,它们高高在上,让你无法

    2024年02月12日
    浏览(82)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包