大数据网站建设青岛网站建设

当前位置： 首页 > news >正文

大数据网站建设,青岛网站建设-中国互联,中国室内设计联盟app,中国中建设计集团有限公司网站文章目录 1、消息整体处理过程Producer发送消息阶段手段一#xff1a;提供SYNC的发送消息方式#xff0c;等待broker处理结果。手段二#xff1a;发送消息如果失败或者超时#xff0c;则重新发送。手段三#xff1a;broker提供多master模式#xff0c;即使某台broker宕机… 文章目录 1、消息整体处理过程Producer发送消息阶段手段一提供SYNC的发送消息方式等待broker处理结果。手段二发送消息如果失败或者超时则重新发送。手段三broker提供多master模式即使某台broker宕机了保证消息可以投递到另外一台正常的broker上。 Broker处理消息阶段手段四提供同步刷盘的策略手段五提供主从模式同时主从支持同步双写 Consumer消费消息阶段手段六consumer默认提供的是At least Once机制手段七消费消息重试机制 2、如何保证消息不被重复消费所以第二个问题来了怎么保证消息队列消费的幂等性 1、消息整体处理过程 这里我们将消息的整体处理阶段分为3个阶段进行分析 Producer发送消息阶段。Broker处理消息阶段。Consumer消费消息阶段。 Producer发送消息阶段 发送消息阶段涉及到Producer到broker的网络通信因此丢失消息的几率一定会有那RocketMQ在此阶段用了哪些手段保证消息不丢失了或者说降低丢失的可能性。 手段一提供SYNC的发送消息方式等待broker处理结果。 RocketMQ提供了3种发送消息方式分别是 同步发送Producer 向 broker 发送消息阻塞当前线程等待 broker 响应 发送结果。异步发送Producer 首先构建一个向 broker 发送消息的任务把该任务提交给线程池等执行完该任务时回调用户自定义的回调函数执行处理结果。Oneway发送Oneway 方式只负责发送请求不等待应答Producer只负责把请求发出去而不处理响应结果。 我们在调用producer.send方法时不指定回调方法则默认采用同步发送消息的方式这也是丢失几率最小的一种发送方式。 手段二发送消息如果失败或者超时则重新发送。 发送重试源码如下本质其实就是一个for循环当发送消息发生异常的时候重新循环发送。默认重试3次重试次数可以通过producer指定。 手段三broker提供多master模式即使某台broker宕机了保证消息可以投递到另外一台正常的broker上。 如果broker只有一个节点则broker宕机了即使producer有重试机制也没用因此利用多主模 式当某台broker宕机了换一台broker进行投递。 总结 producer消息发送方式虽然有3种但为了减小丢失消息的可能性尽量采用同步的发送方式同步等待发送结果利用同步发送重试机制多个master节点尽可能减小消息丢失的可能性。 Broker处理消息阶段 手段四提供同步刷盘的策略 public enum FlushDiskType { SYNC_FLUSH, //同步刷盘 ASYNC_FLUSH//异步刷盘默认 }我们知道当消息投递到broker之后会先存到page cache然后根据broker设置的刷盘策略是否立即刷盘也就是如果刷盘策略为异步broker并不会等待消息落盘就会返回producer成功也就是说当broker所在的服务器突然宕机则会丢失部分页的消息。 手段五提供主从模式同时主从支持同步双写 即使broker设置了同步刷盘如果主broker磁盘损坏也是会导致消息丢失。 因此可以给broker指定slave同时设置master为SYNC_MASTER然后将slave设置为同步刷盘策略。 此模式下producer每发送一条消息都会等消息投递到master和slave都落盘成功了broker才会当作消息投递成功保证休息不丢失。 总结 在broker端消息丢失的可能性主要在于刷盘策略和同步机制。 RocketMQ默认broker的刷盘策略为异步刷盘如果有主从同步策略也默认的是异步同步这样子可以提高broker处理消息的效率但是会有丢失的可能性。因此可以通过同步刷盘策略同步slave策略主从的方式解决丢失消息的可能。 Consumer消费消息阶段 手段六consumer默认提供的是At least Once机制 从producer投递消息到broker即使前面这些过程保证了消息正常持久化但如果consumer消费消息没有消费到也不能理解为消息绝对的可靠。因此RockerMQ默认提供了At least Once机制保证消息可靠消费。 何为At least OnceConsumer先pull 消息到本地消费完成后才向服务器返回ack。 通常消费消息的ack机制一般分为两种思路 先提交后消费先消费消费成功后再提交 思路一可以解决重复消费的问题但是会丢失消息因此Rocketmq默认实现的是思路二由各自consumer业务方保证幂等来解决重复消费问题。 手段七消费消息重试机制 当消费消息失败了如果不提供重试消息的能力则也不能算完全的可靠消费因此RocketMQ本身提供了重新消费消息的能力。 总结 consumer端要保证消费消息的可靠性主要通过At least Once消费重试机制保证。 2、如何保证消息不被重复消费 回答这个问题首先你别听到重复消息这个事儿就一无所知吧你先大概说一说可能会有哪些重复消费的问题。 首先比如 RabbitMQ、RocketMQ、Kafka都有可能会出现消息重复消费的问题正常。因为这问题通常不是 MQ 自己保证的是由我们开发来保证的。挑一个 Kafka 来举个例子说说怎么重复消费吧。 Kafka 实际上有个 offset 的概念就是每个消息写进去都有一个 offset代表消息的序号然后 consumer 消费了数据之后每隔一段时间定时定期会把自己消费过的消息的 offset 提交一下表示“我已经消费过了下次我要是重启啥的你就让我继续从上次消费到的 offset 来继续消费吧”。 但是凡事总有意外比如我们之前生产经常遇到的就是你有时候重启系统看你怎么重启了如果碰到点着急的直接 kill 进程了再重启。这会导致 consumer 有些消息处理了但是没来得及提交 offset尴尬了。重启之后少数消息会再次消费一次。 有这么个场景。数据 1/2/3 依次进入 kafkakafka 会给这三条数据每条分配一个 offset代表这条数据的序号我们就假设分配的 offset 依次是 152/153/154。消费者从 kafka 去消费的时候也是按照这个顺序去消费。假如当消费者消费了 offset153 的这条数据刚准备去提交 offset 到 zookeeper此时消费者进程被重启了。 那么此时消费过的数据 ¹⁄₂ 的 offset 并没有提交kafka 也就不知道你已经消费了 offset153 这条数据。那么重启之后消费者会找 kafka 说嘿哥儿们你给我接着把上次我消费到的那个地方后面的数据继续给我传递过来。由于之前的 offset 没有提交成功那么数据 ¹⁄₂ 会再次传过来如果此时消费者没有去重的话那么就会导致重复消费。 如果消费者干的事儿是拿一条数据就往数据库里写一条会导致说你可能就把数据 ¹⁄₂ 在数据库里插入了 2 次那么数据就错啦。 其实重复消费不可怕可怕的是你没考虑到重复消费之后怎么保证幂等性。 举个例子吧。假设你有个系统消费一条消息就往数据库里插入一条数据要是你一个消息重复两次你不就插入了两条这数据不就错了但是你要是消费到第二次的时候自己判断一下是否已经消费过了若是就直接扔了这样不就保留了一条数据从而保证了数据的正确性。 一条数据重复出现两次数据库里就只有一条数据这就保证了系统的幂等性。 幂等性通俗点说就一个数据或者一个请求给你重复来多次你得确保对应的数据是不会改变的不能出错。 所以第二个问题来了怎么保证消息队列消费的幂等性 其实还是得结合业务来思考我这里给几个思路 比如你拿个数据要写库你先根据主键查一下如果这数据都有了你就别插入了update 一下好吧。 比如你是写 Redis那没问题了反正每次都是 set天然幂等性。 比如你不是上面两个场景那做的稍微复杂一点你需要让生产者发送每条数据的时候里面加一个全局唯一的 id类似订单 id 之类的东西然后你这里消费到了之后先根据这个 id 去比如 Redis 里查一下之前消费过吗如果没有消费过你就处理然后这个 id 写 Redis。如果消费过了那你就别处理了保证别重复处理相同的消息即可。 比如基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一键约束了重复数据插入只会报错不会导致数据库中出现脏数据。