进入微软，混出成绩，以后可坐火箭移民啦，哈哈。

行外人，感觉这是不是要上 AI 啦，规则你有了，然后不断加入训练库中

@ykrank #228 现在我真觉得我提的移民更可靠更可行，相比而言，显然我即使有心也不想大力宣扬，这对我没什么好处，哈哈。

@smileherd #208 相比楼主的方案，我还是觉得移民更靠谱可行。我成功移民了也摆脱大环境了，相比而言我如果按楼主的方案可能无论怎么搞也搞不了 1 个亿甚至一半。

哎，打了很多字又删除了。确实没必要争了，有人分享已经不错了。

@smileherd #201 插一下。

正常人分享不会投入这么多精力，把文章做精美。
也不会搞公众号。
更不会在文章尾放二维码引流。

再加上你对普通人的定义。即便真如你所说，但你说的 1 亿人这件事是不可信的，只是小概率事件。就像我移民出来了，我认为绝大部分写代码的程序员都可以做到像我一样技术移民摆脱三座大山，但我如果这样写，也一样被骂：这与现实不符。

分享的精神值得赞扬。内容有待商榷，捡自己需要的吸收即可。

@gushu #184 所以楼主写这个也是实现 1 亿目标的方式之一，而且很可能占很大比重。

@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

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

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