业务场景:

小程序端消息通知tab页中点赞通知列表、新粉丝通知列表、评论通知列表等UGC消息接口响应速度高达7s左右,经排查问题优化之后响应时间从7s优化至200ms以内,效果展示图如下:

21e92934251b02be0db37da32b9fb0d

04311382a71018148382f9092cfdc5f

问题分析及排查:

  1. 索引问题?

刚开始以为是数据量太大且没有添加索引导致查询速度很慢从而导致接口反映速度很慢,但是一看数据量也不是很大,而且也有通过添加索引(是通过receiverBid(接受者的主键id)创建)的手段,并且通过explain语句分析我所写的语句走了索引,因此排除索引问题。

  1. 业务逻辑代码问题?

后面去查看业务代码、发现业务代码中除了分页查询UGC消息列表、还有一个同步的修改UGC消息读取状态的操作,也就是当用户拉取了UGC消息之后,将未读的记录转变成已读状态,一看到这里发现是两个同步操作,就赶紧通过打日志的方式判断查询操作和修改操作所耗时间,来进一步确定究竟是哪里出了问题,查看日志发现真的是因为修改操作耗时太多(为什么MySQL写操作比读操作慢?)导致的,我当时就想到了两个思路:

​ 1、通过一个事务来进行批量的修改操作,不过还是采取同步,但是我感觉这样如果批量同步修改的话,如果修改的数据太多,可能效率没太大提升

​ 2、就是在批量操作的基础上采用异步的方式,让这个修改操作打入kafka中异步,进一步提高接口响应速率。

  1. 如果异步修改操作失败怎么办?根据什么判断失败?

可以根据Mybatis的Example类update方法返回的int值进行判断,如果大于0说明操作成功如果小于0则采取重试机制,重新打入kafka进行重新消费,至于重试次数的控制由redis来记录控制重试次数

开发思路:

1、根据前端穿过来的参数进行查询UGC消息列表操作,并筛选出status字段是UNREAD状态的记录传给kafka生产者的业务逻辑方法。

2、编写kafka生产者将修改操作的消息写入kafka,并编写消费者对这个消息进行消费。