标签：produce 网络 大于 消息 需求 开始 响应 原因 cer
消息重复一直是消息领域的一个痛点，而消息重复可能发生于下面这些场景
1.消息发送端发出消息，服务端落盘以后因为网络等种种原因发送端得到一个发送失败的响应，然后发送端重发消息导致消息重复。
2.消息消费端在消费过程中挂掉另一个消费端启动拿之前记录的位点开始消费，由于位点的滞后性可能会导致新启动的客户端有少量重复消费。
先说说问题2，一般的解决方案是让下游做幂等或者尽量每消费一条消息都记位点，对于少数严格的场景可能需要把位点和下游状态更新放在同一个数据库里面做事务来保证精确的一次更新或者在下游数据表里面同时记录消费位点，然后更新下游数据的时候用消费位点做乐观锁拒绝掉旧位点的数据更新。
问题1的解决方案也就是kafka实现的方案是每个producer有一个producer id，服务端会通过这个id关联记录每个producer的状态，每个producer的每条消息会带上一个递增的sequence，服务端会记录每个producer对应的当前最大sequence，如果新的消息带上的sequence不大于当前的最大sequence就拒绝这条消息，问题1的场景如果消息落盘会同时更新最大sequence，这个时候重发的消息会被服务端拒掉从而避免消息重复。后面展开详细说一下这个解决方案。
标签：produce 网络 大于 消息 需求 开始 响应 原因 cer
原文地址：https://www.cnblogs.com/wangzhuxing/p/10124308.html
