工作问题记录

seller 4万
order 200万
item 4000万

1、直接导出内存问题

jconsole查看内存增长情况
Runtime.getRuntime方法查看内存增变化，https://blog.youkuaiyun.com/code_while/article/details/102463928
设置最大数量，分批次导出，将没用的对象置空
异步

2、threadlocal问题

偶现用A从threadlocal中获取到用户B的信息，每次重启后刚开始没问题，过段时间就会出现，因为threadlocal使用错误，remove的时候清楚的是另外一个threadlocal的数据，而tomcat使用的是线程池，
导致当当用户A用时了用户B使用过的线程，所以从threadlocal中拿到的是用户B的数据，正常remove后解决

框架使用，设置了值抛异常 未remove导致用户信息获取不正确

3、dashboard功能解决方案

业务背景：
原来的统计页面功能不全，响应慢

解决方案:
从2.0迁移到3.0 补全功能，很多缺失功能其实已经有对应的接口，封装调用一下就可以了

响应慢是因为统计维度多，如
商家待处理信息 售后 代发货 物流异常 待回复 退货等
商家基础信息 评分 会员等级 平均发货时间，绩效，收支信息
商品信息
订单信息
库存 定价指导 商品推荐

调用服务多，还涉及到别的团队的接口，所有这次改为按模块从redis拿数据，前端传模块类型 后端返回对应的数据

具体实现：

定时加异步刷新数据到redis

为了减少并发量，将4万sellerId分片存到redis，同时监听数据库binglog，有更新时刷新redis的seller数据
然后定时任务没小时跑一个分片，大概2000+数据，发送更新请求到mq，然后按模块消费，调用api查询数据写入redis
api使用@async注解自定义线程池

热点seller 每10分钟刷新一次

异步是当seller登录的时候单独发送一次mq 异步刷新数据，就算刚进来的时候没有更新，刷新一下页面就会拿到最新的数据

问题：
线程池配置不合理 触发拒绝策略
数据延迟大，因为别的团队接口有问题，让他们优化

4、线程池问题

redis刷新接口，为了提升效率使用@Async注解，默认会使用sping提供的默认线程池，有内存溢出问题，自定义线程池，按照以往的逻辑核心线程数是内核的4倍 最大线程数64，等待队列设置的最大线程数的4倍
没有考虑出到一个服务提供了多个接口，使用的同一个线程池，导致并发量到了8000，触发拒绝策略，抛异常
增加等待队列长度或者每个api单独配置线程池解决