微信读书的书币逻辑是怎样做到独立过期的呢？

余额就是一个数字，过期时间到了给你扣掉不就好了

硬件足够的话，数据越细越好
不需要每次计算，缓存，或者保存预计算结果就可以了

@yefuchao 不能吧，他付款肯定是先用旧的奖励记录，那就必须每笔记录是否被消费都记

更新 30 条记录也没啥吧，余额可以存另外一个表里

跟游戏开发中的道具类似, 每次获得的书币道具, 只是 configId 一样, 但是 instanceId 是新增的, 不同 instanceId 的道具都有独立的有效期. 扣减书币道具的时候, 优先扣减即将到期的

每次领取都是一条领取记录。领取的商品有过期时间。到时间了。减一下总表的 书币数就好了

想了想还有一个情况是，30 块的交易，用户有 29 个 1 块书币奖励和 1 个 2 块书币奖励，还得在最后一个 2 块奖励里记录消费了 1 块，还有 1 块没被消费，这太不优雅了吧

@xxxaadsdss 这只能解决 sum 的问题，实际消费还得一条一条的更新奖励记录

参考比特币的区块嘛
做一个表，只记录交易信息，譬如 xxxx(时间戳) 入账 1 币，一个月后该条交易记录失效
消费的时候就是手动将依然在有效期内的前 3 条 1 币交易记录失效，如果是入账 3 币只消费 2 币的记录就失效掉 3 币的记录重新生成一条基于原时间戳的 1 币记录
余额计算就是简单的所有有效入账记录求和

@NessajCN 是的，就是觉得这逻辑太重了，在微信读书这种大体量用户下，这个独立过期逻辑有点自己坑自己的意思

@zero47 不重啊......你自己试一下就知道了，没啥计算量的，也就 IO 多一些。不过这种程度的 IO 相对微信本身那就是毛毛雨了

每条领取记录都是库里一条记录
定期跑离线任务去库里把数据都过期掉
算余额会把库里的值全部加起来


这里会出现几个问题:
跑全量任务更新过期会不会太重了? (记录很多, 真正要过期的很少)
每次算余额要把所有的记录加起来会不会慢查询?

(留为作业吧)

领取的时候就写入了这些币的过期时间，到时间自动过期了。

@Fish1024 我感觉也是 写个定时任务扫描过期

之前做一个简单的系统想积分带过期功能，硬着头皮做了类似的方案，基本也实现了需求，结果最后做到退款功能时，还是给整破防了，因为还要考虑退款时退积分，退的积分要根据退款金额计算，退的积分还要保持原来的过期时间，还要考虑退款时，退回的积分有可能已经过期了，过期的积分是直接过期，还是根据规则折算成新积分，感觉本来一个简单的功能越做越复杂，最后索性不做积分过期功能了

按每月存 1 条记录，初始值为 32 个 0 ，签到的时候把当前天数那一位改成获得的金币数，过期只要把上个月当前天那一位改成 0 ，扣钱的时候，从上个月当天开始循环减。这样数据库操作就少了

先进先出呗。
先获取的，先到期/先使用

balance 另有个 detail 表，独立过期时间就行了，不是啥麻烦事

存成 sortedMap ，key 是过期时间，value 是积分，每次登录把过期的删除，积分就是未过期的所有 value 的和，使用时候优先扣过期时间近的

使用书币是先用快过期的还是先用新领取的。