justRua 最近回复了
你准备今年结婚。想安安心心结个婚的话就别去了,制造业公司的科技创新部门,做基于 AI 的质检软件。年底你们拿不出像样的产出的话,不出意外是要裁员。当然你对那个同事能力有信心可以去试试。。。
是不是跑偏了,你是想快速了解微服务相关的知识,而不是学习什么基础原理吧。自己搭一个 dubbo 服务,写个客户端调用一下。然后过一下官方文档,了解里面的一些概念。zk 、redis 这些也本地搭建一下,敲一敲命令,然后过一下官方文档基本就能上手了,再搜一下使用的最近实践。剩下的有空自己深入学习就行
最明显的就是:没有活干,长远看就是业务营收不行,这个也是迟早要裁一波的
年轻时无聊的优越感吧,岁数大点了就不在意什么语言、框架了
toG 项目一堆都是重复建设的,某种意义上就是计算机版本的以工代赈,国产化也凑活干呗,能开工资就行,这类系统大部分也没啥技术难度
百亿补贴可以买,买过 iphone12 、14pro ,还有 findx3 x5 以及好几个蓝牙耳机,没遇到过什么问题,现在手上的 vivox100p 也是 pdd 买的,不过听说百亿补贴会有一些官翻机或者那种退货后重新包装的,正品是正品,不介意的话还是能买的,毕竟便宜几百块
是不是可以把加钱、扣钱两个动作区分对待,扣钱失败的场景一般是用户余额不足之类的业务异常需要立马回滚事务,但是加钱失败则可能是出现锁竞争、网络之类的系统异常导致,重试就好了不需要回滚整个事务,可以适当延迟。
用户余额加钱逻辑:
1.写入账户流水;
2.发送 MQ ,流水表加一个同步状态字段。
后面异步执行:
3.用消费者根据 MQ 消息去扫描流水表、批量的把多个加钱的记录金额合并为一个 update 操作用户余额,把同步状态更新为已同步。
查看用户余额逻辑:
查询用户余额表 + 流水表未同步的记录金额
扣钱逻辑不变,但可能出现扣钱时,余额还没加上流水表未同步的加钱金额,导致余额不足扣钱失败,应该也还好。