做网站要什么步骤,效果好的锦州网站建设,wordpress扁平模板,聊城市 网站制作消息队列已经逐渐成为分布式应用场景、内部通信、以及秒杀等高并发业务场景的核心手段#xff0c;它具有低耦合、可靠投递、广播、流量控制、最终一致性 等一系列功能。 无论是 RabbitMQ、RocketMQ、ActiveMQ、Kafka还是其它等#xff0c;都有的一些基本原理、术语、机制等它具有低耦合、可靠投递、广播、流量控制、最终一致性 等一系列功能。 无论是 RabbitMQ、RocketMQ、ActiveMQ、Kafka还是其它等都有的一些基本原理、术语、机制等总结分享出来希望大家在使用消息队列技术的时候能够快速理解。 1. 消息生产者、消息者、队列 消息生产者Producer发送消息到消息队列。 消息消费者Consumer从消息队列接收消息。 Broker概念来自与Apache ActiveMQ指MQ的服务端帮你把消息从发送端传送到接收端。 消息队列Queue一个先进先出的消息存储区域。消息按照顺序发送接收一旦消息被消费处理该消息将从队列中删除。 2.设计Broker主要考虑 1消息的转储在更合适的时间点投递或者通过一系列手段辅助消息最终能送达消费机。 2规范一种范式和通用的模式以满足解耦、最终一致性、错峰等需求。 3其实简单理解就是一个消息转发器把一次RPC做成两次RPC。发送者把消息投递到brokerbroker再将消息转发一手到接收端。 总结起来就是两次RPC加一次转储如果要做消费确认则是三次RPC。 3. 点对点消息队列模型 点对点模型 用于 消息生产者 和 消息消费者 之间 点到点 的通信。 点对点模式包含三个角色 消息队列Queue 发送者Sender 接收者Receiver 每个消息都被发送到一个特定的队列接收者从队列中获取消息。队列保留着消息可以放在 内存 中也可以 持久化直到他们被消费或超时。 特点 每个消息只有一个消费者Consumer即一旦被消费消息就不再在消息队列中 发送者和接收者之间在时间上没有依赖性 接收者在成功接收消息之后需向队列应答成功 4. 发布订阅消息模型Topic 发布订阅模型包含三个角色 主题Topic 发布者Publisher 订阅者Subscriber 多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。 特点 每个消息可以有多个消费者和点对点方式不同发布消息可以被所有订阅者消费 发布者和订阅者之间有时间上的依赖性。 针对某个主题Topic的订阅者它必须创建一个订阅者之后才能消费发布者的消息。 为了消费消息订阅者必须保持运行的状态。 5.点对点和发布订阅的区别 生产者发送一条消息到队列queue只有一个消费者能收到。 发布者发送到topic的消息只有订阅了topic的订阅者才会收到消息。 6. 消息的顺序性保证 基于Queue消息模型利用FIFO先进先出的特性可以保证消息的顺序性。 7. 消息的ACK机制 即消息的Ackownledge确认机制 为了保证消息不丢失消息队列提供了消息Acknowledge机制即ACK机制当Consumer确认消息已经被消费处理发送一个ACK给消息队列此时消息队列便可以删除这个消 息了。如果Consumer宕机/关闭没有发送ACK消息队列将认为这个消息没有被处理会将这个消息重新发送给其他的Consumer重新消费处理。 8.最终一致性的设计思路 主要是用“记录”和“补偿”的方式。 本地事务维护业务变化和通知消息一起落地然后RPC到达broker在broker成功落地后RPC返回成功本地消息可以删除。否则本地消息一直靠定时任务轮询不断重发这样就保证了消息可靠落地broker。 broker往consumer发送消息的过程类似一直发送消息直到consumer发送消费成功确认。 我们先不理会重复消息的问题通过两次消息落地加补偿下游是一定可以收到消息的。然后依赖状态机版本号等方式做判重更新自己的业务就实现了最终一致性。 如果出现消费方处理过慢消费不过来要允许消费方主动ack error并可以与broker约定下次投递的时间。 对于broker投递到consumer的消息由于不确定丢失是在业务处理过程中还是消息发送丢失的情况下有必要记录下投递的IP地址。决定重发之前询问这个IP消息处理成功了吗如果询问无果再重发。 事务本地事务本地落地补偿发送。本地事务做的是业务落地和消息落地的事务而不是业务落地和RPC成功的事务。消息只要成功落地很大程度上就没有丢失的风险。 9. 消息的事务支持 消息的收发处理支持事务例如在任务中心场景中一次处理可能涉及多个消息的接收、处理这应该处于同一个事务范围内如果一个消息处理失败事务回滚消息重新回到队列中。 10. 消息的持久化 消息的持久化对于一些关键的核心业务来说是非常重要的启用消息持久化后消息队列宕机重启后消息可以从持久化存储恢复消息不丢失可以继续消费处理。 11. 消息队列的高可用性 在实际生产环境中使用单个实例的消息队列服务如果遇到宕机、重启等系统问题消息队列就无法提供服务了因此很多场景下我们希望消息队列有高可用性支持例如 RabbitMQ的镜像集群模式的高可用性方案ActiveMQ也有基于LevelDBZooKeeper的高可用性方案以及Kafka的Replication机制等。 12.消息队列的选型和应用场景 具体请参考高并发架构系列分布式之消息队列的特点、选型、及应用场景详解 你可能也喜欢: 消息中间件系列(二)Kafka的原理、基础架构、以及使用场景消息中间件系列八Kafka、RocketMQ、RabbitMQ等的优劣势比较 消息中间件系列(九)详解RocketMQ的架构设计、关键特性、与应用场景消息中间件系列三主流的消息队列中间件有哪些 消息中间件系列(七)如何从0到1设计一个消息队列中间件消息中间件系列四消息队列MQ的特点、选型、及应用场景详解
