mybatis-flex 看有类似的实现，可以去看看它是怎么实现的参考下，或者直接用这个
https://mybatis-flex.com/zh/base/querywrapper.html#join-left-join-inner-join

你准备今年结婚。想安安心心结个婚的话就别去了，制造业公司的科技创新部门，做基于 AI 的质检软件。年底你们拿不出像样的产出的话，不出意外是要裁员。当然你对那个同事能力有信心可以去试试。。。

是不是跑偏了，你是想快速了解微服务相关的知识，而不是学习什么基础原理吧。自己搭一个 dubbo 服务，写个客户端调用一下。然后过一下官方文档，了解里面的一些概念。zk 、redis 这些也本地搭建一下，敲一敲命令，然后过一下官方文档基本就能上手了，再搜一下使用的最近实践。剩下的有空自己深入学习就行

最明显的就是：没有活干，长远看就是业务营收不行，这个也是迟早要裁一波的

年轻时无聊的优越感吧，岁数大点了就不在意什么语言、框架了

toG 项目一堆都是重复建设的，某种意义上就是计算机版本的以工代赈，国产化也凑活干呗，能开工资就行，这类系统大部分也没啥技术难度

百亿补贴可以买，买过 iphone12 、14pro ，还有 findx3 x5 以及好几个蓝牙耳机，没遇到过什么问题，现在手上的 vivox100p 也是 pdd 买的，不过听说百亿补贴会有一些官翻机或者那种退货后重新包装的，正品是正品，不介意的话还是能买的，毕竟便宜几百块

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

用户余额加钱逻辑：
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 根本跑不起来