@letitbesqzr #22 校验码 = md5(AppID + RequestData + timestamp + key)，然后规定 timestamp 不能重复且必须大于上一次请求，这个检验通过 Redis 实现，只需要存一个就行，缓存的 Key 可以是：AppID 加上固定前缀这种。每次请求验证通过后即可更新此值。甚至如果你愿意你还可以保存在 DB 中，通过 update Table set LastTimeSamp=@0 where Id=AppId and LastTimeStamp<@0 这种更新来确保它是递增的。

要不要严格判断取决于业务被重放的代价。

楼主你头像猛一看还以为是我老婆。。。

@henryhu #3 现在更多人做的是第三种：把别人的数据带回自己家，哈哈。

@sujin190 #13 其实也能在指定场景下完全避免重放。我这边就是时间戳，同时限定后来的请求时间戳要比之前的大，这个数据 Redis 缓存即可。在他们请求不太频繁的情况下随便调用不影响，太频繁了调用方就需要控制调用顺序啦 - 一举两用。这个时间戳其实也就是计数器，用时间戳的好处是绝大部分情况下（非高频）无需对方全局管理这个值。

大部分广告都可以通过启动前开启飞行模式屏蔽。

@binux #4 跟明文攻击没关系，验证算法比如是：MD5 ( Reqeust Data + KEY + Salt )，Salt 是时间戳，Key 是自己的密码。这种方式中间人只能重复这个请求，直到这个请求不被认可，比如重复使用 Salt 或者 Salt 过期（如果是时间戳）。

就是避免攻击者使用同一个请求。一般不会使用随机数而使用时间戳，比如允许有 5 分钟时间差，这样复制原请求的攻击只能限定在一定时间内。严格的话可以缓存这个时间戳（比如根据日志分析某个 Client 可能被攻击，标记此 Client 需要检查）

我这里是夏天 哈哈

赞一下，楼主的产品跟我提的有点接近了。/t/815919

@sujin190 #40

下单最后又失败了：订单系统做最终一致性检查，对于失败的已经出库的，及时通知库存回库，简单讲你下单后，生成一个若干分钟后的任务检查是否完成支付和出库。下单前已经锁定库存，所以有时间差也不会导致超卖除非锁库超时自动退回。

超卖问题：这个无法完全避免，你总会在各个流程遇到意外情况：比如拖着不付款或付款时间太长的，导致锁库超时已返回库存。这时下单使用的就是未锁定的库存 - 不能保证有货。付款锁定和库存锁定这两个东西即使一致也无法保证出库，因为付款可以因为第三方支付而拖时间。所以都只能满足大部分场景，然后通过最终一致化完成少数不正常的。

@sujin190 支付前可以 Lock 库存。支付成功后出库失败，则订单需要自己处理取消逻辑，达到最终一致即可。

@hookybaby 好媳妇能自己搞定，最近她找到了一种方便快速的方法，可能楼上已经有人列出来了，哈哈。

我的方案是直接使用 queue ，一个消费者负责增减库存。库存在 Redis 中，带版本号。读从 Redis 中，写同时写。版本号在写时加入判断可确保不会有脏数据。

queue 性能还可以，一般你的系统不会一秒上万修改库存请求。

以上方案已在生产环境使用

同样推荐 k3s ，1G 的都可以跑起，推荐至少 2G 内存

@RivetCity #15 我的 iPad mini 2 还在发光发热，供小盆友使用

@xlsepiphone antd 怎么了？删库事件？正准备把公司的项目从 Google martial 换到 antd 呢

我有咖啡机，之前办公用的。放家用很方便。

@zenwong 第一次 Lockdown 就买剃头工具啦，现在即使不 Lock 也不用出去剪发了

@jh163888 可能是因为我们这边时区最早吧，好多人还没起床呢。哈哈。