error日志治理统一收集 -》集中治理 -》增加告警-》日常监控 治理流程并且完成公司后端团队的推广。上下游调用时间统一治理使用ai 梳理代码配置和apollo配置 链路追踪整理出上下游调用的超时时间存在 上游接口超时时间 下游接口超时时间的情况异常处理无效进行治理es治理 历史数据治理增加日志 确认历史数据查询范围统计影响面调整代码数据归档目前订单业务域涉及中间件MySQL、Redis、TiDB、MQ、ES。遗漏项请补充一、RDS资源使用率实例ID实例名称规格maxCPUavgCPUmaxDISKmaxIOPSavgIOPS活跃会话maxTPSavgTPSmaxQPSavgQPS实例风险慢查询慢查询会消耗大量的系统资源包括 CPU 和内存增加数据库的负载导致并发性能下降从而影响数据库整体性能下降拖慢应用程序的响应速度。存在慢查的实例列表实例ID实例名称慢查数量【日】SQL最大执行耗时【秒】建议风险等级大表大表的定义请按照一个叶子结点的内存大小与主键、以及一行数据的大小的计算大表带来的问题产生慢查询很难在一定的时间内过滤出所需要的数据查询过大表的小伙伴应该深有体会。深分页效率低如果表中的数据量比较大当进行深分页查询的时候sql的执行时间会变的比较慢。表结构变更时间较长当进行DDL变更时、需要将表重新拷贝如果表数据量过大拷贝周期会很长、也会造成长时间的主从延迟。资源消耗较大表数据量过大不止会占用更多的磁盘空间由于阿里云规格限制大表过多会导致实例被迫升配。存在大表的实例列表实例ID实例名称数据库表名记录数总大小(GB)表注释风险等级磁盘使用率阿里云实例存在规格限制2C16G规格磁盘上限2T、8C32G/16C64G规格磁盘上限3T、32C128G规格磁盘上限6T。当磁盘超过规格限制时只能进行升配。同时磁盘使用率较高变更大表时会导致容量不足。磁盘使用率较高实例列表实例ID实例名称规格磁盘使用率日增预估可用天数风险等级二、Redis资源使用率实例ID实例名称规格maxCPUavgCPUmaxMemoryavgMemorymaxQPSavgQPSmaxNetworkavgNetwork风险等级大Keyvalue 10240bytes大Key引发的问题客户端执行命令的时长变慢。对大Key执行读请求会使实例的带宽使用率被占满导致自身服务变慢同时易波及相关的服务。对大Key执行删除操作易造成主库较长时间的阻塞进而可能引发同步中断或主从切换。存在大key的实例列表实例ID实例名称key名称qpskey大小(bytes)key类型风险等级热Keyqps 500的key热Key引发的问题占用大量的CPU资源影响其他请求并导致整体性能降低。对热Key的读请求并且key较大时很容易将实例的带宽打满。存在热key的实例列表实例ID实例名称key名称qpskey大小(bytes)key类型风险等级三、TiDBtidb-seller-order集群-ticdc集群5.3.3版本涉及tidb server、pd server、tikv server、ticdc server组件。其中ticdc为数据同步组件。ticdc在低版本中不够稳定偶发会出现数据同步延迟的情况官方建议将集群升级为7.1.5版本。ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ----------四、MQmq消费速率如何统计统计数据如果有误会给生产带来误导。统计方式记录每条数据的耗费时间 统计取平均值。或者 压测。实例IDNameServer地址订阅组消息生产速率消费速率key类型风险等级目标降低线上故障的发生提高系统的高可用性提升故障发现能力和故障止损能力1.提升性能降低故障率从可用性、准确性、系统容量、延迟 四个维度提升各业务稳定性和性能可用性系统服务能正常运行所占的时间百分比准确性1-接口错误率系统容量指系统能够支持的负载量目前可以单节点支持的qps上限为依据延迟系统收到用户请求到响应请求之间的时间间隔rt1.1量化核心接口2024年度的性能指标核心接口可用性准确性系统容量延迟xxx1.2.分析梳理核心接口性能提升点1.3.制定方案进行整改1.4.整改上线后统计最新的性能指标2.增强故障发现和故障止损能力梳理障发现现状1依据梳理结果分析目前报警指标是否需要调整2依据梳理结果查漏补缺故障分类与故障暴露方式系统维度系统cpu内存磁盘线程网络宽带其他xxx系统维度故障止损sop核心接口维度核心接口rt升高错误率升高异常qps其他xxx报警位rt xxx ms 每秒钟超过x个报警方式飞书群核心接口故障止损sop中间件核心接口cpu内存磁盘线程网络宽带qps其他xxx中间件故障止损sop强依赖服务核心接口rt升高错误率升高其他xxx报警位rt xxx ms 每秒钟超过x个报警方式飞书群强依赖服务止损sopredis规范Redis规范重点关注禁止使用大Keystring类型控制在10KB以内超过需经PM审核最大不得超过200KBhash、list、set、zset元素个数不要超过5000大Key的过期和删除操作可能导致Redis阻塞严重影响生产环境。如有必要对大key进行删除请与DBA沟通确大key的读取等操作可能导致网卡打满、请求线程阻塞等严重风险解决大Key问题可以基本解决80%的Redis问题线上禁用高风险命令keys、flushall、flushdb、monitor等可通过redis的rename机制禁掉命令或者使用scan的方式渐进式处理使用scan需要控制每次增量迭代返回的key。scan也是一个比较耗时的操作不建议线上高频使用。禁用如下时间复杂度为O(N)及以上的命令SMEMBERS keyHGETALL key复杂度N为哈希表中字段的数量SORT keyZRANGE key start stop 【返回值N】多集合操作如SUNION key [key ...]、SINTER key [key ...]、SDIFF key [key ...]等缓存击穿、穿透、雪崩预防热点Key可考虑较长的过期时间建议一热点Key可以冗余存储多个节点避免将单一节点阻塞并引入本地缓存缓解Redis带宽和CPU负载建议二缓存key超时时间较长缓存value包含实际过期时间实际过期后异步访问DB建议三需要竞争锁才能访问DB查不到的数据建议在缓存中有空标识符比如存储空对象的keykey的过期时间建议增加随机盐确保数据一致性高并发读写、DB读写分离架构下缓存数据一致性风险高可能由于更新删key主从延迟从库触发式更新写入旧数据需要重点关注变更策略。高QPS并发读写场景不一致性风险极高建议使用延迟双删的模式保证缓存与DB一致性禁止数据库事务内更新缓存数据库事务提交后读写分离则为从库同步完毕后必须有一次缓存更新/删除操作确保redis数据为最新关键数据可以采用定时核查的方式进行一致性保障最佳实践参考文档https://cloud.tencent.com/developer/article/2376751建议避免不同服务对相同缓存key的依赖常见的如B、C服务间依赖相同Redis的keyB端对数据进行变更然后更新或者失效缓存C端查询缓存。一种更好的方案是B端对数据的变更不直接操作缓存由C端来处理缓存一致性C端监听binlog消息处理缓存失效此外C端对读请求进行数据查询之后进行缓存命名规范缓存key以:作为分隔符和redis命名空间的规范一致在部分高级特性上可能有更多支持。redisKey原则上不允许包含除:、_、-、.以外的特殊字符。缓存key建议以应用名缩写作为前缀以防止key冲突缓存key建议携带环境标防止预发/生产相互污染缓存key建议携带版本号紧急情况下可以通过更新版本号刷新缓存高QPS服务慎用可能导致缓存穿透。或者再进一步增加新老版本的流量比例控制。设计规范要点数据隔离存在影子压测流量的按中间件标准接入相关组件避免污染缓存禁止不同服务共用Key可通过rpc访问不要通过多数据库模式复用实例。redis的多数据库较弱使用数字进行区分很多客户端支持较差同时多业务用多数据库实际还是单线程处理会有干扰。保证读写性能高并发下Redis读命中率不能低于85%高并发下建议客户端添加熔断功能(例如sentinel)使用批量操作提高效率但注意单次批量操作个数不要过多如500以内否则仍存在性能风险注意两者不同1. 原生是原子操作pipeline是非原子操作。2. pipeline可以打包不同的命令原生做不到。3. pipeline需要客户端和服务端同时支持4. 集群模式下pipeline建议仅对同一个key进行操作原生命令mget、mset非原生命令pipeline减少存储所有的key都应该有超时时间需要配置合理的内存淘汰策略默认策略是volatile-lru即超过最大内存后在过期键中使用lru算法进行key的剔除保证不过期数据不被删除但是可能会出现OOM问题。allkeys-lru根据LRU算法删除键不管数据有没有设置超时属性直到腾出足够空间为止。allkeys-random随机删除所有键直到腾出足够空间为止。volatile-random:随机删除过期键直到腾出足够空间为止。volatile-ttl根据键值对象的ttl属性删除最近将要过期数据。如果没有回退到noeviction策略。noeviction不会剔除任何数据拒绝所有写入操作并返回客户端错误信息(error) OOM command not allowed when used memory此时Redis只响应读操作。使用规范redis特性使用规范缓存的持久化特性并不可靠重要数据必须有其他持久化机制存储。Redis事务功能较弱不建议过多使用Redis的事务功能较弱(不支持回滚)而且集群版本(自研和官方)要求一次事务操作的key必须在一个slot上(可以使用hashtag功能解决)禁止线上使用Redispub/sub做消息服务消息传递没有ack机制不能保证到达率且不能重复消费此外一旦消费堵塞后导致内存被占满不推荐线上服务使用Redis的key过期通知事件Redis键过期通知事件是基于Redis发布/订阅(pub/sub)功能实现订阅过期channel的客户端连接是tcp长连接如果Redis-server触发Failover主从节点切换后Redis订阅连接不会自动重新建立到正确节点的连接。这类功能需求可以使用公司开发的延迟消息通知中间件(海量延迟消息通知系统)连接池配置规范连接池参数设置建议值定义如下根据节点数、访问QPS与RT敏感性进行调整。详细可以参照服务连接池配置的redis部分以及JedisPool资源池优化的关键参数设置建议部分。参数名默认值建议值描述max-active500500最大连接数节点数*最大连接数不得超过Redis的最大连接数可在实例详情页面查看max-idle5050最大空闲连接高并发凸峰访问场景下建议与max-active等同避免建连开销。min-idle00最小空闲连接max-wait100ms100ms获取连接时的最大等待毫秒数RT敏感时配置较小比如调整为50mstimeout500ms500ms命令超时时间RT敏感时配置较小比如调整为100msredis集群版使用规范建议redis-client使用jedis且使用连接池能得到更佳的效率。针对redis集群必须使用JedisCluster客户端。注1Jedis解析不了Redis-cluster协议处理不了asking和moved异常会导致Redis-cluster访问异常正确的使用方法是JedisCluster客户端操作Redis-cluster。JedisCluster包含了到所有节点的连接池JedisPoolJedisCluster每次操作完成后不需要管理连接池的借还它在内部已经完成。JedisCluster不要执行close()操作它会将所有JedisPool执行destroy操作,引发性能问题注2更多参考Jedis常见异常汇总、JedisPool资源池优化Redis集群版本在使用Lua上有特殊要求。所有key都应该由 KEYS 数组来传递redis.call/pcall 里面调用的redis命令key的位置必须是KEYS array, 否则直接返回error-ERR bad lua script for redis cluster, all the keys that the script uses should be passed using the KEYS array所有key必须在1个slot上否则直接返回error, -ERR eval/evalsha command keys must in same slot限制pipeline的使用集群模式下pipeline建议仅对同一个key操作。JedisCluster本身不支持pipeline虽然可以利用CRC16算法计算出key对应的slot以及Smart客户端保存了slot和节点对应关系的特性将属于同一个Redis节点的key进行归档然后分别对每个节点对应的子key列表执行mget或者pipeline操作。但是不建议在生产环境这样操作。因为集群会有reshard和rebalance的操作slot迁移数据期间由于键列表无法保证在同一节点会导致大量错误。