是不是可以把加钱、扣钱两个动作区分对待，扣钱失败的场景一般是用户余额不足之类的业务异常需要立马回滚事务，但是加钱失败则可能是出现锁竞争、网络之类的系统异常导致，重试就好了不需要回滚整个事务，可以适当延迟。

用户余额加钱逻辑：
1.写入账户流水；
2.发送 MQ ，流水表加一个同步状态字段。
后面异步执行：
3.用消费者根据 MQ 消息去扫描流水表、批量的把多个加钱的记录金额合并为一个 update 操作用户余额，把同步状态更新为已同步。

查看用户余额逻辑：
查询用户余额表 + 流水表未同步的记录金额

扣钱逻辑不变，但可能出现扣钱时，余额还没加上流水表未同步的加钱金额，导致余额不足扣钱失败，应该也还好。

没得选就去，反正实习而已，主要是积累经验，为你后面找工作做积累

35 岁找找应该还是有希望的，非互联网开发应该还行，40 岁纯开发就比较难了，真心没见过 40 岁以上的普通开发同事

想着完全凭技术吃饭, 不指着一家公司活。那你技术上至少在组里要能排的上号，遇到问题要主动挺身而出，要给你的 leader 有个好印象，至少要觉的你人靠谱虽然话不多，其实做到这样也可以了。否则你工作能力一般，对其他人又冷漠，真的很容易被劝退，路上打招呼这个，至少组内的同事和你的 leader 还是要的吧，其他没什么交集的当没看见就行

类分布式锁的一个场景，回调轮询都可以，如果实时性要求和请求量都不大轮询也没毛病。回调可以参考 zookeeper 的 watcher 机制

@fxxkingduck 老师好

有现成的 grpc-spring-boot-starter ，协议是 grpc ，实现是 netty

有责任，但不是全责，代码是经过测试、review 的，责任是大家的，没必要全往自己身上揽，如果最后全怪你只能说明这个公司很 low 。以前公司百万日活，支付代码有问题，导致异常提现了几十万，后面是追回一部分，就这样也没见要谁负全责的，大家复盘以后避免就是了。

如果流量不大属实没什么必要切分，分开后你要多处理各种异常情况，后续如果有新增什么复杂功能你可以提议新增一个服务避免影响旧服务。

要明白服务切分的意义。例如隔离影响、方便服务扩展和加机器。

新项目可以直接用最新的，老项目真的没必要，jdk 模块化是有破坏性的，一些旧点版本的框架没有适配升级，不加--add-opens 根本跑不起来

说明人家负责，我们这测试都会看你代码，测试环境有问题人家自己先看日志，然后跟你说代码 xxx 这一行是不是有问题。。。

用个 NIO 实现的异步 http client 的做就行了吧，就像 webflux ，IO 异步调用不需要太多的线程

感觉已经不错了，高并发优化的那个可以在下面项目里面展开，例如提升性能多少。项目经历可以写的丰富些，多些可以量化的指标。其实主要就是现在不缺人。

本地 debug 可以但是打包后不行，可能是打的包有问题，可以远程 debug 看看启动时会不会进 setApplicationContext

@privil 谢谢啦，试了下确实可以，之前有想过用 eval ，但搜了下网上的例子用不了
换了个姿势试了试可以了，eval_opts=`eval echo "$opts"`
这样写$opts 中的${TEMP_DIR}会被解析到，此贴完结。。。

疫情刚开始过完年那会儿，在家办公好几月，有事无事就喝瓶可乐，有一天腹部巨疼，后来发现是结石，应该很小，那几天狂喝水排出去了，真的疼怕了。