@ykrank #177 说的有道理，我在新西兰，高级程序员中的中位数收入，在楼主口中也只是刚达标而已。要知道新西兰这边的收入比国内高太多（当然 IT 可能不会，但整体水平比国内高很多而且福利很好）。你说这样的在国内是普通水平，那就是同龄人应该会有不少在你之上。我就没见几个打工收入在我之上的，涵盖亲戚朋友同学同村人。楼主如果仅限杭州我还可以勉强赞同一下。

看完了我想说就算是工作 10 年后年薪能在 50-100 万的都不是普通人，这一点楼主就已经判断错了。其他思路不错，但真不是普通人就能做到的。好在我移民出来了，三座大山没有，资产重置概率比较低。

总之还是能收获一些东西，引发一些思考的。感谢楼主分享。

@letitbesqzr #22 这个 timestamp 实际上与计数器没区别，之所以使用 timestamp 是因为绝大部分场景下调用方使用频率低，推荐他们使用 timestamp 直接无需保存计数器，方便直接。调用多了就考虑让他们使用队列或全局计数器当 timestamp 甚至 IP 白名单适当放宽都可。

@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 呢