93 | 项目实战二：设计实现一个通用的接口幂等框架（分析）

“如果幂等号已经存在，说明业务已经执行或正在执行，则直接返回；如果幂等号不存在，说明业务没有执行过，则记录幂等号，继续执行业务“ ------------------------------------------------- 这个判断存在与否也要保证原子性

1 如果存储幂等号的外部存储器里面的数据太多了，会影响查询性能，如何优化？ 2 如果存储幂等挂掉了，幂等逻辑无法正常运行，那这个就相当于没有幂等了。这个时候咋搞呢？

幂等如果外部存储挂掉了，就不能让业务正常使用了吧，否则会出问题

1.当给代码分论别类习惯了。那业务代码和技术代码的耦合就挺扎眼，总想着分离，透明掉技术代码，保护业务代码的干净。 课后题 1.mq消费重试，网络丢包重试。。。 2.技术上的想不到。有重试的地方好像都要。 疑问 容错性这个有点不理解。限流这个不生效还好说。幂等功能不生效？刷数已经在路上。

分布式系统中，有一台机器挂了，请求会打到另一台机器上，这个时候，第二台机器不知道第一台是什么情况，第一台的日志，我认为也没有什么价值了，除非服务有状态，某一个请求一直只打到一台服务器上，但这个设计就很复杂了，老师有别的建议吗？

重试场景： 1. 微信发送消息失败，可以手动触发”重发“ 2. 网吧电脑卡顿、死机，可以重启 3. 拨打电话无人接听，请稍后再拨 4. 秒杀没有抢到，下一轮再接再厉 5. 游戏通关后升级难度从头开始 需要用到幂等设计场景： 1. 下单时不要出现重复订单 2. 提款时千万别出Bug 3. 火箭发射时，按下点火按钮，只能点火一次 4. 造小宝宝的时候，自然界超强幂等

分布式事务需要用到幂等设计：at-least-once + 幂等 == exactly-once

1. RocketMQ支持消息失败定时重试。 2. 用到幂等设计的还有：1）用户短时间内多次点击提交，2）第三方平台接口以为异常多次异步回调。

偏个题,最近刚好在做硬件设备的断点重连,场景是这样的: 在现场有wifi,所有的物联网设备通过wifi连接,有的设备在不断的移动过程中,可能移动到wifi范围之外,这个时候就需要支持断点重连,在设备进入wifi范围时重新建立连接,为此,有以下几种方案: 1.提高wifi信号的强度,减少连接断掉的几率 2.当前使用tcp连接,将其修改为udp连接,通过服务不断地向设备发包/设备向服务发包来保证,此时不需要保持连接,做法相对简单 3.定时重连,通过定时任务,每隔一段时间就重新建立连接 方案1不靠谱,毕竟现场的环境相当大,无法保证wifi能覆盖到每一个角落,成本也高 方案2无法使用,通过观察设备厂家提供的sdk,发现只提供tcp连接的调用方式,因此该方案无效 方案3感觉上可行,但是如果设备正在进行业务处理时重连,则必然会有负面影响,业务上有延迟,连接也有可能迟迟建立不起来 在上述思考之后,感觉在失去连接时重新建立连接即可,于是通过学习厂家的sdk,发现确实有提供连接断开之后的回调,于是现在的做法像是方案3的升级版,每当连接断掉后就将其加入重连队列,定时轮询队列,建立连接,连接成功后从队列中弹出,不成功则在下一轮定时任务中处理 这一版本的断点重连稳定性很好,但是依旧存在问题,有人发现了吗?那么怎么解决这个问题呢?(提醒一下,迭代器)

我有个疑问。幂等号采用随机数生成，会不会这么个场景，比如下订单过程中由于网络波动，导致用户点了两次按钮 调用了两次接口，这种情况幂等号不是相当于生成两个不同的随机数吗？如果是这样，如果确保接口幂等性呢