这是一个创建于 1750 天前的主题，其中的信息可能已经有所发展或是发生改变。
需求：
记录商品的购买用户和数量，实现：
- 购买限制：例如每个用户 24 小时内只能购买 2 次
- 清空并重新计算指定产品的购买限制：删除指定产品的全部用户的购买记录。
方案一
使用哈希：
hset product_{product} {user} {qty} 优点：清空限制很方便，del product_{product}。
缺点：hash 貌似不能针对指定 field(用户)设置缓存过期时间, 相关讨论： https://github.com/redis/redis/issues/1042 。只能在 qty 加一个过期时间 /购买，维护起来麻烦，也不太优雅。
方案二
使用字符串：
set product_{product}_{user} {qty} 优点：可以针对产品 /用户设置过期时间，实现购买限制简单。
缺点：清空指定产品的购买限制复杂度是 O(N)，类似于 keys product_{product}_* |xargs redis-cli DEL
有没有比较优雅的实现方式？
 | 1 junan0708 2021-02-26 15:55:55 +08:00 product_{product}_{user}_{Ymd} |
 | 2 also24 2021-02-26 15:58:10 +08:00 『 24 小时内』 指的是滚动的 24 小时，还是固定的 24 小时（ 1 天）。 前者：昨天 8 点 1 次，18 点 1 次；今天 0 点不能购买。 后者：昨天 8 点 1 次，18 点 1 次；今天 0 点可以购买。 |
 | 5 myd OP 打错，前者。 |
 | 6 beryl 2021-02-26 16:11:01 +08:00 如果是固定 24 小时（绝对时间）： set product_{product}_{user} count expire_time(固定时间) 这个有个问题是，会在固定时间清除大量的 key, redis 会有压力。 如果是滚动 24 小时，从第一次购买算为原点： set product_{product}_{user} count expire_time(当前时间+24 小时) 这种压力就分散多了 |
| 7 also24 2021-02-26 16:18:06 +08:00 @beryl #6 如果按照： set product_{product}_{user} count expire_time(当前时间+24 小时) 那么距离第一次购买 24 小时后，仍然无法购买了。 可以改成 set product_{product}_{user}_{timestamp} timestamp expire_time(当前时间+24 小时) 取数量的时候 keys product_{product}_{user}_* 就好 |
| 8 junan0708 2021-02-26 16:33:55 +08:00 hset product_{product}_{user} count 值：购买次数 hset product_{product}_{user} expire 值：第一次购买时间 + 86400 expire < now 可以购买 expire >= now && count < 2 可以购买 |
| 9 beryl 2021-02-26 16:43:21 +08:00 @also24 #7 如果只是第一次购买，24 小时后，被自动清掉了，key 不存在可以认为 0 次，可以购买的。 但确实有问题，因为『第二次购买后，24 小时时间被重置了』（- set product_{product}_{user}_{timestamp} timestamp expire_time(当前时间+24 小时) 这个同样会有『第二次购买后的过期时间是根据第二次的当前时间+24 小时』这样第一次购买 24 小时后，购买次数并没有被重置 可以在你的这个思路上，第二个 key 拿到第一个的时间戳 |
| 10 also24 2021-02-26 16:46:16 +08:00 |
| 11 beryl 2021-02-26 16:50:14 +08:00 @also24 嗯，那我的方案的问题理解一致 『 key 是包含了 timestamp 的，第二次购买的时候设置的是另一个 key，不存在覆盖问题』 如果第一次购买的时候是：2021-02-26 18:00，过期时间 2021-02-27 18:00 第二次购买是：2021-02-26 20:00 , 过期时间 2021-02-27 20:00 如果在 2021-02-27 18:00-20:00 理论上可以购买一次，但是其实只有一次机会了 |
| 12 myd OP @also24 可以把设置 key 和设置过期时间分开。如果 key 存在就不设置过期时间。主要是使用字符串，需要遍历用户，变成 O(N)了。 |
| 13 also24 2021-02-26 16:53:33 +08:00 @beryl #11 2021-02-27 18:00-20:00 的时候，第一次购买的 key 已经过期了。 此时 keys product_{product}_{user}_* 只能查出 1 条购买记录，没啥问题啊。 |
 | 14 thet 2021-02-26 16:56:07 +08:00 hset product_{product} {user} "qty {qty} expire {expire}" 值序列化一下 |
| 15 also24 2021-02-26 16:59:21 +08:00 这个方法的缺点还是 keys product_{product}_{user}_* 的效率比较低，性能差。 有一个优化方案是做一次剪枝，大部分用户不存在 24 小时内购买过商品，那么我们设置一个 『用户是否在 24 小时内购买过商品』的 key 就好了。 也就是每次用户产生购买行为，都 set product_{product}_{user} timestamp expire_time （不论原 key 是否存在，都续期 24 小时） 这样对于大部分用户，只需要查询 product_{product}_{user} 不存在，就可以认为不存在限制了。 而对于 product_{product}_{user} 存在的用户，再进行 keys product_{product}_{user}_* 查询，确认具体是否超过了限制。 |
 | 16 dreamstart 2021-02-26 17:06:47 +08:00 我觉得可以按照 key 值顺序来删除吧 毕竟购买记录是按顺序写进去的（就是个队列），每次只看队列头的时间是否满足了 24 小时就可以的 |
| 18 beryl 2021-02-26 17:11:28 +08:00 题外话 qty 是什么的缩写 |
 | 20 k9982874 2021-02-26 17:18:13 +08:00 我在项目里使用的方案二，起初也是使用方案一，后来发现很难维护内容时效性就切到了方案二。 方案一的问题在于，如果 qty 增加时间戳，在删除时必须把 qty 的内容一起取回来，当 qty 本身是个很大的对象时，成本就很高。 如果像楼上说的增加一个 expired set，在查找 qty 时，还需要再请求一次 redis 取出来 expire 值，然后校验数据有效性，一次请求硬变成两次。 |
 | 21 hw93 2021-02-26 17:27:40 +08:00  1 方案二再维护一个 `set product_{product} [user1, user2]`方便去`删除指定产品的全部用户的购买记录` |
| 22 also24 2021-02-26 17:33:24 +08:00 |
 | 23 adamwong 2021-02-26 17:47:48 +08:00 每个用户存两个时间戳不就完了？代码里做判断 参考 golang 的令牌桶算法 time/rate.Limiter |
 | 24 yuankui 2021-02-26 17:58:32 +08:00 删除的动作不频繁就 2 方案了 |
 | 25 PiersSoCool 2021-02-26 18:03:12 +08:00 这就是个限流器的问题 可参考开源方案 |
 | 26 whileFalse 2021-02-26 18:29:39 +08:00 via iPhone 1 为产品指定版本号，product-{product}.{product.v}-{user} 清空产品时不做清空操作，而是产品版本号+1 |
 | 27 palmers 2021-02-26 20:08:37 +08:00 第一次插入的时候设置 key 的过期时间 第二使用 incr 不会清理过期时间， 通过 key 获取值如果没有了一定是可以购买的 否则累加一 |
| 28 palmers 2021-02-26 20:09:59 +08:00 哦 可以购买的时候 还有判断 2 |
 | 29 night98 2021-02-26 20:57:09 +08:00 redisson，有个分布式对象你可以参考下 |
 | 30 rocky114 2021-02-26 21:31:45 +08:00 1 存储俩份 hset product_{product} {user} {qty}，set product_{product} expire_time |
 | 31 lldld 2021-02-26 22:42:24 +08:00 如果“清空并重新计算指定产品的购买限制” 是实际需求, 而"删除指定产品的全部用户的购买记录"只是你想的实现方法的话, 我觉得没必要删除购买记录 key. 新增一个 key "product_reset_<product_id>", value 存重置的时间. service 这边可以定时更新(比如每 5 分钟)这个数据存在内存里面, 因为这个行为应该是运营有计划的, 所以可以要求(或者告之)他们至少要提前 10 分钟在系统设置重置. 用户购买记录, key "product_buy_<product_id>_<user_id>", value 存 购买时间,数量, ... , 购买时间,数量, 每次购买刷新过期时间为 24 小时 用户购买时, 读其购买记录, 并过滤时间早于重置时间的数量, 然后计算是否可以购买, 能购买几个 |
Select Language