@deltadawn 补充思路，可以是 32 个 0-9 ，a-z ，这样每天获取到的就可以非常多了，只需要计算一个 32 的字符串，就可以算出来了。 但是缺点有很明显，微信读书可以做到分钟级别的失效，这个就做不到了。
以我浅见，这种余额类的大都是事件溯源的，即你看到的余额不是简单的存储了一个数字，而是由交易记录实时计算出来的，然后定期合并一个快照，减少计算量，那么就可以在交易记录上打标记来实现过期。这是最常用，也是最安全的做法。当然，也有简单的方案，比如将这类会过期的书币存入 redis 的 zset 中，然后将过期时间戳作为 score ，就可以使用 ZRANGEBYSCORE 之类的命令来返回当前时间和过期时间之间的数据，求和就行了。
