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

余额会单独存储，每次买书同时更新余额和 30 条消费记录
DB 性能很强的，现在的硬件太牛逼了

@somebody1 多几个字段，都是 32 个 0-9 ，分别表示个、十、百、千、万位，这样每天的数量取就没有上限了。

每天记录多加一个余额和状态字段. 消费前拉出所有可用余额, 找出要扣除的记录更新对应状态和余额就好了吧?

至于总余额 临时算或找个地方 cache 下. 每条记录的过期的话, 定时任务或找个用户查询/消费的时候进行一次统一计算就行.但用户也就是一次批量查询 + 一次批量更新. 计算量也不大

大体量用户❎
蝇量级计算✅

数字产品没有库存问题，所以各用户间购买行为无关，自己消费自己的就行。
购买行为不涉及用户间的借款、代付，所以自己算自己的账就行。
每个用户独立计算自己的币和消费过程，总共百条书币记录，0.1TPS 的操作，单用户放文件存储都不怕效率低。
过期状态更新只存在于查看时、消费时，依然百条书币记录，0.1TPS 的操作。

先不考虑其他功能需求，单说你的问题来看，这简直和大体量没关系啊。。。
唯一和大体量有关的是，如何在亿级用户中找到这个用户独立的账户存储空间。

可以算一下， 我们默认存储金币记录 1 年， 假设所有用户每天全部签到 365 ，假设共 2 亿用户，那么 2 年的金币记录就是：2*2*365 亿，假设分 128 个表，每个表就是 6 亿左右，所以目前来看存储不是大问题， 那么问题来了就是过期怎么搞，单纯的定时任务去扫这几百亿的数据很扯，所以分开看线上用户实时查看： 实时算每个用户请求自己实时算生效的金币。运营数据统计： 离线任务