沧州市东光建设局 网站python网页版

沧州市东光建设局 网站,python网页版,wordpress paged,琼海网站建设公司1分钟看图掌握核心观点#x1f447;图片一、问题描述1.1 报错信息应用服务报错#xff0c;通过监控日志发现凌晨2点的时候#xff0c;应用报错获取不到Redis key。1.2 告警与监控信息首先想到是否由于内存满导致的key淘汰#xff0c;生产的所有Redis都有设置内存告警#…1分钟看图掌握核心观点图片一、问题描述1.1 报错信息应用服务报错通过监控日志发现凌晨2点的时候应用报错获取不到Redis key。1.2 告警与监控信息首先想到是否由于内存满导致的key淘汰生产的所有Redis都有设置内存告警但没有收到内存告警信息内存告警需要每隔10秒连续3次触发才会告警。从监控图中可以看到Redis内存稍有增长但使用率一直偏低并没有达到使用率告警。图片查看监控信息在问题时间点发生了大量的key过期初步怀疑是由于key批量设置了过期时间正好到期了导致大量key失效。图片查看Redis错误日志没有发现异常。二、问题定位基于前面的监控初步怀疑是key设置了过期时间导致失效。是否有上线其他新功能导致但是业务反馈不是由于设置过期时间导致并且第二天问题复现因此继续深入定位。2.1 key是否过期查看淘汰策略查看key过期时间初步判断确实不是因为key过期导致的大量淘汰这里TTL接近5天但是连着2天出现问题因此不应该是过期时间到了导致。xxx:xxx config getmaxmemory-policy1)maxmemory-policy2)volatile-lruxxx:xxx ttl finance:xxxx_cms_version_10000- Redirected to slot [9229] located at xxx:xxx(integer)387585xxx:xxx ttl finance:xxxcms_basic_data_10423(integer)387574key是被删除还是淘汰查看监控发现存在key确实被淘汰说明接下来需要考虑内存问题。图片2.2 是否内存满了发现确实短时间内存写满了一开始查看监控由于时间拉的比较长查看增长趋势没发现内存写满情况但是由于没有达到告警条件没有满足连着3次触发阈值故没有触发告警。同时内存用满问题持续时间较短约10分钟左右。图片其他指标检查发现出现问题时client_longest_output_list指标存在明显突刺该指标非常可疑。图片请求量的大涨怀疑是请求堆积导致buffer增长使得内存写满。但是此时还有疑点写入也上涨是否是由于读请求积压导致还是因为写入数据导致内存满2.3 找出内存涨的来源设置定时任务对出问题时间点前后20分钟这段时间进行抓包分析。对比出问题前后几分钟的请求对应时间点请求量飙升并且请求量来源基本是get请求set请求也少量增长。4860 get finance:xxxx__101224925 get finance:xxxx__100324945set finance:xxxx_data_10013-04947 get finance:xxxx_data_10013_cms_version_100004976 get finance:xxxx__102515054set finance:xxxx__undefined5098 get finance:xxxx__100188729 get finance:xxxx_data_10415_cms_version_100009152 get finance:xxxx_data_10401_cms_version_100009553 get finance:xxxx_data_10228_cms_version_100009597 get finance:xxxx_data_10213_cms_version_100009622 get finance:xxxx_data_10032_cms_version_100009647 get finance:xxxx_data_10347_cms_version_100009674 get finance:xxxx_data_10182_cms_version_100009742 get finance:xxxx_data_10251_cms_version_1000010085 get finance:xxxx_data_10019_cms_version_1000023064 get finance:xxxx__1042345176 get finance:xxxx_data_10423_cms_version_10000[rootdb-prd-xxx.v-bj-3.vivo.lan:/data/redis/scpdir]# cat 0807.cap | grep 2024-08-07 01:59|awk {print $8,$10}|sort |uniq -c |sort -k 1 -n同时也对set的内容进行分析发现set的数据并不足使内存写满且上面监控可以看到内存写满问题持续时间很短因此应该不是数据增长导致。进一步对get请求来源分析结合 IP来源以及 keyname跟业务同学沟通确认由于业务读请求量大涨导致业务请求从每分钟27w左右上涨到70w左右主要有2.4 机制分析内存用量上涨超限会触发Redis节点基于已经配置的volatile-lru策略进行过期数据淘汰所以需要找到内存上涨的来源。基于监控指标排查分析基本确定了发生异常期间没有集中的大量数据写入反而发现大量网络数据的输出抓包也印证了此时节点主要是在处理get命令读请求。进一步地发现了client-output-buffer-limit这个指标出现异常上涨才最终锁定到Redis的回包积压问题。关于Redis的结果回包逻辑首先要了解Redis的结果存储空间设计。Redis针对每一个连接客户端都会初始化一个大小为16K的静态的buf区域和一个空的链表结果相关声明代码如下#define REDIS_REPLY_CHUNK_BYTES (16*1024) /* 16k output buffer */char buf[REDIS_REPLY_CHUNK_BYTES];list *reply;c-reply listCreate();对于Redis而言正常执行的命令都会有数据回包而回包结果都需要在客户端中做暂存。Redis是如何结合以上两个数据进行结果存储的呢主要逻辑是如果静态buf区域能够满足回包结果存储即结果不大于16k那么结果就会存储静态buf中将结果不断插入reply链表中同时我们都知道Redis支持丰富的数据类型和操作命令有些批量数据读取命令的结果可能会有很多字段这些字段也会作为一个个链表元素追加到reply链表中。正常情况下我们在Redis节点上执行info clients命令可以获得如下客户端的统计信息 info clients# Clientsconnected_clients: 1client_longest_output_list: 0client_biggest_input_buf: 0blocked_clients:其中的client_longest_output_list字段代表此时节点的所有连接客户端中回包结果的缓存情况。但是按照之前服务监控和抓包结果分析具体执行的指令都是get实际数据也没有超过16k大小并没有满足将结果存储到链表的条件。这里有个经常被忽略的场景就是Redis其实支持pipeline命令执行方式的简单来说就是Redis支持一次性接收一个客户端的多个指令具体执行过程中会把这些指令的结果不断暂存然后在后续流程中集中回包如果这时候不能及时地把数据通过网络发出去就有可能出现reply链表长度激增的现象进而导致客户端占用内存激增这正是我们本次遇到的场景。图片Redis的maxmemory参数限制的是Redis实例可以使用的最大内存这部分内存主要包括以下几个部分业务数据占用的内存、客户端连接的输入/输出缓冲区、复制积压缓冲区、AOF 缓冲区以及其他一些内部开销。具体来说Redis 的maxmemory 限制包括业务数据占用的内存,这部分是用户在Redis中存储的数据。客户端连接的输入/输出缓冲区用于暂存客户端发送的命令和Redis 返回给客户端的数据。复制积压缓冲区:用于主从复制当从节点断线重连时可以从这个缓冲区拉取丢失的数据。AOF 缓冲区:用于持久化当开启AOF 持久化时Redis 会将写操作追加到AOF 缓冲区然后异步地写入AOF 文件。其他内部开销:包括Redis 进程本身的一些数据结构、对象、碎片内存等。因此在设置Redis 的maxmemory 参数时需要综合考虑业务数据的内存占用、各个缓冲区的大小以及内存碎片率等因素合理地分配内存避免出现内存溢出或性能下降的问题。三、问题解决3.1 紧急修复临时扩大Redis集群内存,避免内存写满。限制client-output-buffer-limit大小避免由于请求过大导致内存突增。业务限流削峰避免请求量突增。增加兜底机制如果由于Redis key被淘汰则去MySQL查询避免业务直接报错。3.2 根本解决业务进行业务逻辑优化将请求打散避免同一时间集中大量请求Redis。四、总结本次问题是由于业务集中请求Redis导致缓存积压内存增长达到最大内存限制触发Redis淘汰策略对key进行驱逐。key被淘汰丢失后需要增加兜底机制去DB侧请求避免业务报错。虽然Redis性能比较好但是也要尽量打散请求合理评估存储侧的性能。