@bleepbloop 股份不多，公司应该不太至于，也不是高管

1. 如果只是单纯 CRUD 操作，那么可以考虑重复性工作用代码生成器
2. 如果不只是 1，可以考虑一些架构设计，业务抽象能力，将接口和功能做的更合理公用
3. 在 2 的基础，可以针对业务细节，工程化方向思考，或者框架研究，例如一个 CRUD 请求，能够分析到每一步具体怎么做的
4. 在 3 的基础上，考虑中间件，稳定性，复用性等场景

@lipd
@Dye8 其实和 965 关系不是那么大，因为 965 同样会有久坐，饮食习惯等问题，当然 996 可能会加剧这些 （-

@slamDunkLINk
@Dashy
感想支持，希望能够贡献一起维护，个人力量比较有限

@Myprincess 怎么联系你呢 -

@ysc3839 我理解和 json 没关系吧，只是利用 json.dump 做了个编码转换而已

@Myprincess cG9sYW5kZW1lI2dtYWlsLmNvbQ==
邮箱，thx

@Myprincess cG9sYW5kZW1lI2dtYWlsLmNvbQ==

@Myprincess 还有位置么，搭你个车算了

@LokiSharp 一会看下 taobao， 话说淘宝为什么会比官网便宜这么多呢

题外话 qty 是什么的缩写

@also24 #13

2021-02-27 18:00-20: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 理论上可以购买一次，但是其实只有一次机会了

@also24 #7

如果只是第一次购买，24 小时后，被自动清掉了，key 不存在可以认为 0 次，可以购买的。

但确实有问题，因为『第二次购买后，24 小时时间被重置了』（-

set product_{product}_{user}_{timestamp} timestamp expire_time(当前时间+24 小时)
这个同样会有『第二次购买后的过期时间是根据第二次的当前时间+24 小时』这样第一次购买 24 小时后，购买次数并没有被重置


可以在你的这个思路上，第二个 key 拿到第一个的时间戳

如果是固定 24 小时（绝对时间）：
set product_{product}_{user} count expire_time(固定时间)

这个有个问题是，会在固定时间清除大量的 key, redis 会有压力。


如果是滚动 24 小时，从第一次购买算为原点：
set product_{product}_{user} count expire_time(当前时间+24 小时)

这种压力就分散多了

@dgjungle 之前接触过一些，但是里面细研究起来也是特别大的