意味着之前的人亏的能少一点

@importmeta #16
2 如果错误就抛给用户??
条件全都合理 报错不是应该抛给你自己吗 发钉钉或着什么提示报错啊。

第三方 api 如果报错都应该报给项目维护者，如果参数本身有问题应该从前置校验中剔除，如果只是偶发报错，那应该记录错误代码中增加判断，直接忽略等待系统重试，没见过的发消息报给开发者。

6.3 如果错误了 积分表加行级锁 返积分 where 扣费记录 是否返了积分 = 否
6.4 扣费记录 是否返了积分 设为 是
这两部分按你的描述属于退款逻辑，在原始订单进行变更，但我觉得扣费记录这表的积分变更数值可以设置为有符号，通过正负值来确定积分的变化，通过这个表都是插入数据，相当于一个积分流水表，除了关联 id 就是数值变化字段 还可以加个备注，为什么变化，前台在展示时会比较好看。

@reoah2
取向不同吧
插混是油车全套+小电池小电机 本质上是油车，更倾向于没有家用充电桩比纯油车省油的用法。
增程式电车全套+发动机 本质上是电车，更倾向于有家用充电桩日常省钱用法，偶尔兼顾加油跑长途高速。

插混是这样的
首先他是一个完全的油车 具备发动机和变速箱，油车有的他全有
所以也存在机油机滤 变速箱油之类的保养项目
区别是在油车的基础上又一个小电机和电池，有动能回收，在不充电的情况下可以比普通油车百公里少 1 个油左右
低速和大油门电机接入，动力更强，低速+驻车用电，发动机停，空调不停。
还可以充电，充电幅度比较频繁了，但是高速没有里程焦虑。

个人理解
同价位油车<插混车保险价格<纯电
毫无疑问，开的少就买油车

不至于差这点吧。。。
要不换电车吧。。。

Under Armour Adult Training 15 刀 6 双一包 两包穿了 6 年
最近又买两包 真的好穿又吸汗 毛巾底

@crc8 “怎么？有这种烂摊子要我接手？你当我傻？”

@importmeta #10 那你要做冻结金额的逻辑，防止超发队列消息，不然一个人可以发起 n 多条消息 如果攻击就可以打崩，你请求接口响应速度不会太快，并发的话就会超售。

1.必然是先扣费然后插入请求数据，此时状态待执行
2.异步扫表统一入队列
3.队列消费确保请求成功才 ack 掉 redis stream 可以做到 无论是否成功都记录日志，并记录请求时间。
4.单个 request_id 最多请求几次，每次消费前先检查该请求的执行次数，超过直接消费并跳出，防止队列多入。
5.异步检查达到失败次数的返还积分，执行成功的记录变更状态为完成。
6.未达到失败次数上限并且超过一定时间间隔的的消息重新入队列重试。

查积分表本身就不对
积分余额设置无符号，默认为 0
扣款操作直接 update points = points-10 where user_id = x
不够扣会直接报 UNSIGNED 错的

没想过 抵触和兴奋会连起来用
https://i.imgur.com/km62MY2.png

还有后台应用吧

啊？这不是最传统的简单方案就可以解决的吗
mysql 抢占啊
增加一个状态字段 假设 active_status = 0 未启动
按照不同机房你最多有 2 个实例参与抢占
update table set active_status = 1 where id = xxx
看影响行数 = 1 视为抢占成功，开始执行就行了。。 其他的 return
为啥还需要分布式锁之类的，mysql update 一定是原子的啊

@AbysmalSorrow 你开玩笑呢吧。。。 不还？催收懂不懂