justRua

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

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

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

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

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

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

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

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

@fxxkingduck 老师好

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

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