共计 571 个字符，预计需要花费 2 分钟才能阅读完成。
在消息传递过程中，如果呈现传递失败的状况，发送会执行重试，重试可能会产生反复的音讯。对系统来说，如果没有对反复生产进行解决，会导致系统数据产生谬误。
比方，一个订单零碎，订单创立胜利后，把数据写入统计数据库，如果产生反复统计，会导致数据库数据谬误。
解决音讯反复生产，其实就是保障音讯的生产幂等性。
幂等性的定义：
屡次执行所产生的影响均与一次执行的影响雷同。
所以须要从业务逻辑上设计，将生产的业务逻辑设计成幂等性。
利用数据库的惟一束缚
在进行音讯生产，须要取一个惟一个标识，比方 id 作为惟一束缚字段，先增加数据，如果增加失败，后续做谬误提醒，或者不做后续操作。
Redis 设置全局惟一 id
每次生产者发送音讯前设置一个全局惟一 id 放在音讯体重，并寄存的 redis 里，在生产端接口上先找在 redis 查看是否存在全局 id，如果存在，调用生产接口并删除全局 id，如果不存在，不做后续操作。
多版本（乐观锁）机制
给业务数据增加一个版本号，每次更新数据前，比方以后版本和音讯中的版本是否统一，如果统一就更新数据并且版本号 +1，如果不统一就不跟新。这有点相似乐观锁解决机制。
总结
设计幂等须要依据具体的业务场景，如果是并发量比拟大的零碎，数据库个别支撑不了这么大的并发，须要应用 Redis 缓存解决。而并发不大的零碎能够抉择数据库。
如果感觉文章对你有帮忙的话，请点个赞吧!
正文完
