项目背景：某电商平台系统演示，在上午访问各模块时，响应时间均正常。在下午十二点半左右，访问“采购计划”，“订单查询”时，出现响应时间超过十秒的现象。在一点半就要开始演示，所以进行紧急处理。
     涉及到的阿里产品：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
系统访问正常，演示正常进行。
总结：梳理的时候觉得问题挺明显的，但是处理时，对业务逻辑不完全了解，根本无法定位到实际问题所在，还有数据库的前期分库分表设计真的太重要了。