大名县建设局网站,巴州移动网站建设,昆明二建建设集团网站,选择一个网站进行优化老生常谈 顺序发送 只用一个消费者去消费该队列 为了吞吐量的话#xff0c;有多个消费者去消费怎么办 #xff1f; 保证入队有序就行#xff0c;出队以后的顺序交给消费者自己去保证#xff0c;没有固定套路 通过一定算法#xff0c;将一组顺序消息发送到…老生常谈 顺序发送 只用一个消费者去消费该队列 为了吞吐量的话有多个消费者去消费怎么办 保证入队有序就行出队以后的顺序交给消费者自己去保证没有固定套路 通过一定算法将一组顺序消息发送到同一个broker下面的同一个队列消费者进行顺序监听即可。 例如一条信息的唯一标识 通过一定算法 路由到 同一个 broker 下到 某一个队列下。 通过业务层面处理。 RocketMQ通过MessageQueueSelector中实现的算法来确定消息发送到哪一个队列上 RocketMQ默认提供了两种MessageQueueSelector实现随机/Hash 当然你可以根据业务实现自己的MessageQueueSelector来决定消息按照何种策略发送到消息队列中。
丢失消息 三个角度来分析生产者弄丢数据、消息队列弄丢数据、消费者弄丢数据。 先持久化数据。 生产端可以指定发送次数失败后 异常处理 消费端重试-进行重新消费问题注意幂等性问题数据库或者分布式锁 。 一般指定次数。超过限制则记录 日志表 进行人工补偿机制 启用ack
重复消费消息 如RabbitMQ是发送一个ACK确认消息RocketMQ是返回一个CONSUME_SUCCESS成功标志kafka实际上有个offset的概念 业务方面 1.消费端处理消息的业务逻辑保持幂等性 2.保证每条消息都有唯一编号且保证消息处理成功与去重表的日志同时出现 3.第三方介质,来做消费记录。以redis为例给消息分配一个全局id只要消费过该消息将id,message以K-V形式写入redis。那消费者开始消费前先去redis中查询有没消费记录即可。
消息积压问题 解决办法 1.对生产者发消息接口进行适当限流不太推荐影响用户体验 2.多部署几台消费者实例推荐 3.适当增加 prefetch 的数量让消费端一次多接受一些消息推荐可以和第二种方案一起用 4.增加消费者的多线程处理 https://blog.csdn.net/hanguihb/article/details/123493103
原理及应用原理和机制 消息中间件kafkaRabbitMQ等掌握rocketMQ原理及集群布署 rocketmq 集群架构模型 多Master模式一个集群无Slave 优点配置简单单个Master宕机或重启维护对应用无影响。 缺点单台机器宕机期间这台机器上未被消费的消息在机器恢复之前不可订阅消息实时性会受到影响 多 Master 多 Slave 模式 HA采用异步复制方式主备有短暂消息延迟毫秒级 优点同时Master宕机后消费者仍然可以从Slave消费 缺点Master宕机磁盘损坏情况下会丢失少量消息。 多 Master 多 Slave 模式同HA采用同步双写方式即只有主备都写成功才向应用返回成功 优点数据与服务都无单点故障Master宕机情况下消息无延迟服务可用性与数据可用性都非常高 缺点性能比异步复制模式略低大约低10%左右发送单个消息的RT会略高且目前版本在主节点宕机后备机不能自动切换为主机。 Dledger 模式 采用 Master-Slave 架构来部署能在一定程度上保证数据的不丢失也能保证一定的可用性 缺陷很明显最大的问题就是当 Master Broker 挂了之后 没办法让 Slave Broker 自动 切换为新的 Master Broker 需要手动更改配置将 Slave Broker 设置为 Master Broker以及重启机器这个非常麻烦。 在手式运维的期间可能会导致系统的不可用。 使用 Dledger 技术要求至少由三个 Broker 组成 一个 Master 和两个 Slave这样三个 Broker 就可以组成一个 Group 也就是三个 Broker 可以分组来运行。 一但 Master 宕机Dledger 就可以从剩下的两个 Broker 中选举一个 Master 继续对外提供服务。 三个 NameServer 极端情况下确保集群的可用性任何两个 NameServer 挂掉也不会影响信息的整体使用。 参考https://www.cnblogs.com/xwgblog/p/14055449.html
