最重要的手段

==排查监控运行代码,定位出代码问题位置==

1. AutoMapper弃用 改为TinyMapper

提升明显,相差7倍

https://bx.rsun.com:8001/business/afterfact-payment/conpayment-detail?id=8f7c24ef-bd88-46fd-8de9-8391d50f5f96

automapper 实际效果

tinymapper实际效果

测试请求

tinymapper

automapper

测试代码

  1. Redis缓存

### 禁用长耗时的查询命令

  Redis绝大多数的读写命令的时间复杂度都是在O(1)到O(N)之间,其中O(1)就可以放心使用,但是O(N)就要当心了,因为N表示不确定性,数据越大,查询的速度就会越慢,因为Redis只用一个线程来做数据查询,如果这些指令非常耗时,就会造成Redis的阻塞,那么就会造成大量的延时。

要避免O(N)类的命令对Redis性能造成的影响,就要从以下几个方面进行改造:

  1、禁止使用key * 命令;

  2、避免一次查询所有成员,要使用 scan 命令进行分批的、游标式的遍历

  3、通过机制严格空指Hset、Set、Scorted Set 等数据结构的大小

  4、将排序、并集、交集等操作放在客户端执行,以减少Redis服务器的运行压力

  5、删除一个大的数据时,可能会需要很长的时间,所以建议用异步删除的方式unlink,他会启动一个新的线程来删除目标数据,而不是阻塞Redis主线程。

### 大Key大Value问题

  1. 数据库优化

数据库查询大value字段能不用到的就不要查询,比如列表中,可以额外的针对需要的数据进行二次特定查询,否则开销很大, 某生产1200条的预算页面查询耗时全耗这个上了

3.1 首先是监控代码

当前毫秒数:236:1
当前毫秒数:255:2
当前毫秒数:341:6
当前毫秒数:44573:7
当前毫秒数:44677:8
当前毫秒数:44745:9
当前毫秒数:44758:10
总耗时:44759毫秒

3.2 定位出问题在一个简单的表查询上,查看数据库结构以及数据库直接查询发现确实要很久,排除orm组件问题,问题就是sql问题或者表设计问题

这还只是1124条记录的表哦

3.3 查看数据库结构分析出是其中一个大value字段查询导致的慢查询,非必要可以只查询特定字段,性能提升显著

  1. 依据情况使用内存缓存和Redis

Redis 处理整表塞入无论是使用string还是hash在需要读取全部的时候效果都不理想,比如需要查出全部的用户数据做筛查,并且会有高频的获取需求,所以访问数据库不合适,会导致连接量暴增

改用内存缓存读写都是毫秒级别的,但是需要注意分布式系统中如何保存一致性同步,可以参考我的另一篇blog

https://www.dcmickey.cn/NET/210.html

  1. sdf