类似每日限额这类功能怎么做表设计

Question

小弟这边有个类似每日限额的功能，这个字段目前放在用户的扩展信息表中。
但是由于要进行每日限额校验计算，所以还需要有其他的数据和表，现在小弟有三种方案
方案一：
根据用户每日的消费情况从订单表中进行实时统计，查询当前的数据
方案二：
创建一个每日限额信息表，根据用户每天生成一个限额记录信息，每次消费后去这条记录中对今日消费进行累加
方案三：
不加表，只在用户扩展信息中添加一个今日已消费的字段，进行累加，然后每天晚上12点用一个定时任务去清0

但是针对上面的情况，小弟有如下疑问：

1. 方案一由于是订单信息，所以表数据会很大，到后期统计可能会有耗时问题。

2. 方案二相当于每个用户每天都会有一条记录，同时这个记录只会在当天有用，剩下的记录就相当于一个日志信息了，这样的话，随着时间的推移，这张表就会存在大量无用数据。

3. 方案三由于是定时任务，所以会有延时的情况，就会出现在12点那一刻有用户进行购买时，此时应该可以购买，但是定时任务没有执行完毕而导致超出限额的情况。

所以小弟想问下各位大神，通常每日限额这类功能是怎么做设计的？希望大大解答

Answer 1

方案一增加耗时且降低用户体验，但简单易行，交易量小时，也不是不可做。。。
方案三的坑无限多，题主也提出了些，建议不用考虑了。

目前在用方案二，只是存储用的redis的hashTable，过期时间设置为距第二天零点的秒数。在交易成功后在hashTable内累加统计数据，在交易前验证。
此方案：

• redis内存效率高；

• 过期时间方便可控；

• 交易量极大时分布式扩展也好弄。