qq_36180997的博客

背景由于用户数的飙升，推荐使用的技术栈也在不断升级，以满足更高并发和更大数据量的推荐场景。推荐相关的原始数据从小几十万到几百万，到几千万，再到上亿。推荐1.0从全库的用户数据中load出满足条件的用户，在jvm做计算，得到推荐结果。随着用户数量的上升，满足条件的用户越来越多，导致计算量越来越大，性能逐渐变低推荐2.0一边从数据库中load出满足条件的用户，一边用sql在数据库做计算，直接得到推荐结果。利用索引，性能提升五倍左右。随着用户量继续上升，性能也在逐渐变低。推荐3.0将数据库推荐相

背景发现一个实例的推荐请求比另外一个实例慢10+倍。分析通过各种监控工具，最终发现慢的实例执行着canal同步消息，并且更新到es。结论canal更新频繁造成网络IO开销大，数据准备和发送的时间加长。因此，如果使用canal做数据 同步，建议使用独立的服务做这件事，避免彼此影响，造成性能下降以及同步延迟加大。...

异常信息Server side(172.24.0.20,9090) thread pool is exhausted, detail msg:Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-172.24.0.20:9090, Pool Size: 500 (active: 500, core: 500, max: 500, largest: 500), Task: 546 (completed: 46), Executor statu

背景在做数据导入时，服务器报以下异常：Caused by: org.apache.dubbo.remoting.transport.ExceedPayloadLimitException: Data length too large: 10794838, max payload: 8388608, channel: NettyChannel [channel=[id: 0x5aa64030, L:/172.31.8.190:51674 - R:/172.31.9.63:9090]] at

在线上调用dubbo服务有时候发现线上BUG的时候，想要在线上环境复现这个bug，除了使用arthars帮助定位问题外，还可以手动调用dubbo服务复现BUG。进入dubbo提供方服务,需要dubbo服务提供方的ip和端口，端口通常为9090telnet ip port查看服务提供方有哪些服务ls查看某个服务有哪些子方法ls serviceName调试服务提供方某个方法invoke classPath.methodName...

背景偶然看到一个核心业务功能在监控中响应时间很长，接近10s。但是在其它时间段发现响应时间很快，200ms左右。原因通过数据库监控发现，在中午12:00到12:10这个时间段内，数据库的流量、查询数、插入数、cpu、内存等指标都出现不同程度的飙升。但是除了流量外，其它数据虽然飙升，但还在正常区间内。初步判断是网络带宽不够导致了业务性能变慢。验证查看接口监控通过PINPOINT查看这个接口在不同时间的响应时间，发现每天都会有这个现象。查看其它接口监控信息通过监控工具查看其它核心接口的性能，发现

实用命令以下是在工作经验中经常接触到的命令watch查看方法的实时调用情况，包括入参和响应值，但是需要提前知道观测哪些值watch class method “{params,params[0],params[1],returnObj}” “#cost>5” -x 2 -ftttt允许同时记录多次调用，之后可以查看任一次请求结果，可以暂存多次请求，指定查看某次请求的请求参数和响应值，弥补watch的不足1. tt -t class method -n 10 ‘#cost > 5

背景由于项目中使用了kafka自动配置，导致在添加某些看起来不相干的包的时候，程序启动失败。解决在启动类中，直接将kafka自动配置类干掉。原因分析看自动配置类信息@Configuration( proxyBeanMethods = false)@ConditionalOnClass({KafkaTemplate.class})@EnableConfigurationProperties({KafkaProperties.class})@Import({KafkaAnnota

背景新项目刚上线，需要导入一批种子用户。运营测从公司的其他产品中拉取了一批种子用户，通过表格的形式进行导入。困难点由于需要不断导入数据，单一渠道无法获取足量的数据，所以数据来源渠道是多个的，导致数据源的格式很难统一起来，和一开始和产品约定好的格式不一致，导致导入逻辑需要跟着发生变化；导入的用户需要和走正常业务逻辑得到的数据一致，因此涉及到的业务细节比较多，涉及到的数据库表逻辑比较多excel数据格式的不确定性增加了导入的难度，比如列数据没有按照数据库定义的枚举走、列数据多了一个空格导致入库时也带

背景根据条件，每天给每个用户推荐十名合适的用户(用户当天第一次登录时触发)，已经推荐过的不允许再次推荐。每天定时给设置了允许自动推荐的用户跑推荐逻辑。要求被推荐人具备随机性，否则有些人每天被重复推荐多次，有些人虽然满足条件却长时间遍历不到。其它解决方案以及利弊采用mysql的随机排序函数，每次查出来的数据都不一致，因此达到随机性。缺点采用随机排序的方式，可能会有部分数据始终遍历不到，无法做到极端情况下将所有用户数据都遍历一遍，因此得到的遍历结果如果不满足十人，并不能表示没有十人满足推荐要求。

获取当天0点的时间long zeroTime = LocalDateTime.of(LocalDate.now(), LocalTime.MIN).toInstant(ZoneOffset.of("+8")).toEpochMilli();

背景在偶然情况下，调用微信api出现40001,accessToken is invalid。通过日志发现，获取的accessToken为null。原因因为微信分发一个accessToken最多有两个小时的有效时间，我们会在本地每半小时自动刷新accessToken。在刷新前会先删除redis缓存，然后再更新accessToken到redis缓存。刚好由于删除的时间间隙内，其它模块去redis拿accessToken，导致拿到的为null，导致无效accessToken异常。另外，微信accessT

背景异常信息代码private void customSort(List<Customer> customers) { Collections.sort(customers, (c1, c2) -> c1.getActiveLevel() < c2.getActiveLevel() ? 1 : (c1.getActiveLevel().equals(c2.getActiveLevel()) ? (c1.getAuthStatu

日志打印如下原因未在对应方法上加@Transactional注解加了@Transactional注解后

简介ureport是一个比较强大的开源免费报表工具，在原有功能基础之上，本文使用nacos作为配置中心，支持多个主库的数据查询操作，进一步拓展ureport的功能。环境信息数据库信息dating数据库有一张活动表activity，里面有141条记录dating_jb数据库有一张job职位表，里面有1条记录现在要实现在同一个工程下，根据mapper的路径不同，支持查询两个数据库的数据。pom依赖nacos对springboot版本有要求，具体可以去看nacos文档。nacos文档地址&

背景在开发过程中，可能需要使用第三方库，而这些库的源码可能是C写的，这时候会在java这边定义成native文件，程序运行的时候，链接到指定的dll文件。dll文件生效windowswindows环境下，会默认去 java.library.path下找dll文件，我们可以通过System.getProperty("java.library.path")查看所有路径信息。通过System.loadLibrary("lpsolve55j");查看是否配置成功。注： lpsolve55j.dll只需要写