命令行参数的解析

对于重试机制，假如订单系统消费了消息，但是由于网络等问题消息系统未收到反馈是否已成功处理。这时消息系统会根据配置的规则隔段时间就 retry 一次。你 retry 一次没错，是为了保证系统的处理正常性，但是如果这时网络恢复正常，我第一次收到的消息成功处理了，这时我又收到了一条消息，如果没有做一些防护措施，会产生如下情况：用户付款一次但是订单系统计算了两次，这样会造成财务账单异常对不上账的情况发生。那就可能用户笑呵呵老板哭兮兮了。

接口幂等性 #

为了防止上述情况的发生，我们需要提供一个防护措施，对于同一笔支付信息如果我其中某一次处理成功了，我虽然又接收到了消息，但是这时我不处理了，即保证接口的 幂等性 。

维基百科上的定义：

• 幂等(idempotent、idempotence)是一个数学与计算机学概念，常见于抽象代数中。

在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例如，“setTrue()”函数就是一个幂等函数,无论多次执行，其结果都是一样的，更复杂的操作幂等保证是利用唯一交易号(流水号)实现.

任意多次执行所产生的影响均与一次执行的影响相同，这是幂等性的核心特点。其实在我们编程中主要操作就是CURD，其中读取(Retrieve)操作和删除(Delete)操作是天然幂等的，受影响的就是创建(Create)、更新(Update)。

对于业务中需要考虑幂等性的地方一般都是接口的重复请求，重复请求是指同一个请求因为某些原因被多次提交。导致这个情况会有几种场景：

• 前端重复提交 ：提交订单，用户快速重复点击多次，造成后端生成多个内容重复的订单。
• 接口超时重试 ：对于给第三方调用的接口，为了防止网络抖动或其他原因造成请求丢失，这样的接口一般都会设计成超时重试多次。
• 消息重复消费 ：MQ消息中间件，消息重复消费。

对于一些业务场景影响比较大的，接口的幂等性是个必须要考虑的问题，例如金钱的交易方面的接口。否则一个错误的、考虑不周的接口可能会给公司带来巨额的金钱损失，那么背锅的肯定是程序员自己了。

幂等性实现方式 #

对于和web端交互的接口，我们可以在前端拦截一部分，例如防止表单重复提交，按钮置灰、隐藏、不可点击等方式。

但是前端做控制实际效益不是很高，懂点技术的都会模拟请求调用你的服务，所以安全的策略还是需要从后端的接口层来做。

那么后端要实现分布式接口的幂等性有哪些策略方式呢?主要可以从以下几个方面来考虑实现：

Token机制 #

针对前端重复连续多次点击的情况，例如用户购物提交订单，提交订单的接口就可以通过 Token 的机制实现防止重复提交。
 

再做一次实验，这次选中实验的服务器和客户端直接位于同一个机房内，ping延迟在0.2ms~0.3ms左右。跑了以上脚本以后，实验结果是50000 TCP连接总共消耗了11605ms，平均每次需要0.23ms。

线上架构提示：这里看到同机房延迟只有零点几ms，但是跨个距离不远的机房，光TCP握手耗时就涨了4倍。如果再要是跨地区到广东，那就是百倍的耗时差距了。线上部署时，理想的方案是将自己服务依赖的各种mysql、redis等服务和自己部署在同一个地区、同一个机房(再变态一点，甚至可以是甚至是同一个机架)。因为这样包括TCP链接建立啥的各种网络包传输都要快很多。要尽可能避免长途跨地区机房的调用情况出现。

2. 连接队列溢出

测试完了跨地区、跨机房和跨机器。这次为了快，直接和本机建立连接结果会咋样呢?Ping本机ip或127.0.0.1的延迟大概是0.02ms，本机ip比其它机器RTT肯定要短。我觉得肯定连接会非常快，嗯实验一下。连续建立5W TCP连接，总时间消耗27154ms，平均每次需要0.54ms左右。嗯!?怎么比跨机器还长很多? 有了前面的理论基础，我们应该想到了，由于本机RTT太短，所以瞬间连接建立请求量很大，就会导致全连接队列或者半连接队列被打满的情况。一旦发生队列满，当时撞上的那个连接请求就得需要3秒+的连接建立延时。所以上面的实验结果中，平均耗时看起来比RTT高很多。

在实验的过程中，我使用tcpdump抓包看到了下面的一幕。原来有少部分握手耗时3s+，原因是半连接队列满了导致客户端等待超时后进行了SYN的重传。

（编辑：济宁站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!