项目背景：某电商平台系统演示，在上午访问各模块时，响应时间均正常。在下午十二点半左右，访问“采购计划”，“订单查询”时，出现响应时间超过十秒的现象。在一点半就要开始演示，所以进行紧急处理。
涉及到的阿里产品：EDAS ,DRDS,RDS，MQ,DTS
----
排查思路：因为不确认是网络还是系统问题，所以进行双向排查。
1. 排查内网以及外网访问延迟
2. 登录edas平台根据服务监控查看系统调用链网络验证
1. telnet 应用ip 端口 ##连通性没有问题
2. netstat -antulp | grep 端口 ##没有网络延迟现象
鹰眼调用链查看
观察发现应用耗时普遍偏高，点击查看调用链
选择其中一个TraceId进入查看详情
可以看到大量时间都耗在数据库查询上
查看相应数据库
直接查看DRDS下面挂载的RDS资源情况
发现其中一个RDS的CPU从中午十二点半开始逐渐升高达到98%
发生这种情况很奇怪，就拉上开发，咨询相应业务逻辑
发现A中心通过MQ调用B中心，而今天中午有大量数据落库，导致业务逻辑大并发处理数据，由此导致cpu升高，因为客户处理的这张表未进行分库分表，所以压力都集中在一个RDS上
解决
数据落库是通过DTS数据订阅实现的，所以暂停了数据订阅通道（数据订阅数据保存时间为24小时）
升级cpu过高的rds
系统访问正常，演示正常进行。
总结：梳理的时候觉得问题挺明显的，但是处理时，对业务逻辑不完全了解，根本无法定位到实际问题所在，还有数据库的前期分库分表设计真的太重要了。
