weixin_48352162的博客

Request引发的血案

业务场景用户预存一定余额，可以用余额在平台购买套餐商品，支付扣除余额需控制并发，当前采用的是乐观锁方式。即每个用户的余额记录都有一个版本号，更新记录时，需要带上版本号。版本号采用整数递增。问题当有两个扣减余额的操作同时发生时，其中一个有几率失败。失败结果直接返回给用户，此时用户操作重试即可，但会影响用户体验。如果一直处于高并发状态，用户可能会连续操作失败多次。主要针对此扣款失败场景进行优化。方案演进增加失败重试int i = 0, max = 3;//最多尝试3次while (i < m

​​概述线上系统出现文件无法成功导出，或者导出导致虚拟机崩溃等情况。为保证系统稳定和功能正常，需对导出功能做一轮整体优化，以及整理一些可进一步优化的点。初始导出流程如下​原因分析1、业务数据处理异常出现比较少，测试的正常操作难以提前发现，系统运行过程中，产生了特定数据可能就会出现的bug2、数据量大导致内存溢出目前系统最大数据量导出为单表3百万行，60列，全部加载到内存中极易导致OOM3、并发操作导致内存溢出与2中类似，实质还是数据量大的问题。由于是并行处理，因此同时存在CPU瓶颈

背景在本地session移至redis存储时，原本以为引入spring-session-data-redis依赖，配置RedisHttpSessionConfiguration，在web.xml中引入springSessionRepositoryFilter就结束了，没想到遇到序列化相关的问题，具体就是只有getter，没有setter。日志如下：26-Jun-2021 15:53:16.432 涓ラ噸 [http-nio-8081-exec-6] org.apache.catalina.core.St

日志中存在大量的连接超时内容：errorMsg=Connect to api.10646.cn:443 [api.10646.cn/122.97.213.18] failed: connect timed out首先使用telnet排除客户端原因telnet api.10646.cn 443 阻塞telnet www.baidu.com 443 正常说明客户端是正常的，很可能是被服务器限制了查看与服务器122.97.213.18之间的连接状态netstat -n | grep 122.97.2

实现了一个shell脚本，自动提交代码更新。配合jenkins使用。完整代码git add .is_change=0temFile="temFile"git status > $temFilewhile read alinedoecho $aline if [ "$aline" = "Changes to be committed:" ]# if [ "$aline" = "Untracked files:" ] then