短视频app源码，实现幂等设计的重要方式
短视频app源码，实现幂等设计的重要方式
取消重试有两种方法，第一是设置重试次数为零，第二是选择不重试的集群容错策略。
<!-- 设置重试次数为零 -->
<dubbo:reference id="helloService" interface="com.java.front.dubbo.demo.provider.HelloService" retries="0" />
<!-- 选择集群容错方案 -->
<dubbo:reference id="helloService" interface="com.java.front.dubbo.demo.provider.HelloService" cluster="failfast" />
假设短视频app源码中用户支付成功后，支付系统将支付成功消息，发送至消息队列。物流系统订阅到这个消息，准备为这笔订单创建物流单。
但是消息队列可能会重复推送，物流系统有可能接收到多次这条消息。我们希望达到效果是：无论接收到多少条重复消息，只能创建一笔物流单。
解决方案是幂等表方案。新建一张幂等表，该表就是用来做幂等，无其它业务意义，有一个字段名为key建有唯一索引，这个字段是幂等标准。
早短视频app源码的物流系统订阅到消息后，首先尝试插入幂等表，订单编号作为key字段。如果成功则继续创建物流单，如果订单编号已经存在则违反唯一性原则，无法插入成功，说明已经进行过业务处理，丢弃消息。
这张表数据量会比较大，我们可以通过定时任务对数据进行归档，例如只保留7天数据，其它数据存入归档表。
还有一种广义幂等表就是我们可以用Redis替代数据库，在创建物流单之前，我们可以检查Redis是否存在该订单编号数据，同时可以为这类数据设置7天过期时间。
物流单创建成功后会发送消息，短视频app源码的订单系统订阅到消息后更新状态为完成，假设变更是将订单状态0更新至状态1。订单系统也可能收到多条消息，可能在状态已经被更新至状态1之后，依然收到物流单创建成功消息。
解决方案是状态机方案。首先绘制状态机图，分析状态流转形态。例如经过分析状态1已经是最终态，那么即使接收到物流单创建成功消息也不再处理，丢弃消息。
数据库锁又可以分为悲观锁和乐观锁两种类型，悲观锁是在获取数据时加锁：
select * from table where col='xxx' for update
乐观锁是在更新时加锁，第一步首先查出数据，数据包含version字段。第二步进行更新操作，如果此时记录已经被修改则version字段已经发生变化，无法更新成功：
update table set xxx,
version = #{version} + 1
where id = #{id}
and version = #{version}
以上就是短视频app源码，实现幂等设计的重要方式， 更多内容欢迎关注之后的文章
