消息队列学习
概念学习
参考资料:
- IBM Messages and queues
- Microsoft-MSMQ Overview
- KM-消息队列原理简介与对比选型
基础概念
- 消息(messages):一组信息的集合
- topic。
- Topic和Queue应该指的是两种不同的模型,根据这篇JMS的文章、Kafka is it a topic or a queue、JMS Topic vs Queues。在Queue中,发送方直到消息会被发送到哪里去,存在特定的发送者和特定的接受者,而且一般是一对一的;在Topic中,虽然仍然存在发送者和接受者,但是它们互相之间是不知道的。
- 而且在队列中接受者不用担心超时问题;在Topic中接受者必须continuously active并且按时接收,不然消息就会超时。
- 在pulsar中,topic甚至不用预先创建,会根据
{persistent|non-persistent}://tenant/namespace/topic
的名称自动生成。
- Topic和Queue应该指的是两种不同的模型,根据这篇JMS的文章、Kafka is it a topic or a queue、JMS Topic vs Queues。在Queue中,发送方直到消息会被发送到哪里去,存在特定的发送者和特定的接受者,而且一般是一对一的;在Topic中,虽然仍然存在发送者和接受者,但是它们互相之间是不知道的。
- 元数据(metadata):参考BookKeeper Ledger Metadata,metadata更多应该是配置项的数据,以及一些全局范围内有作用的变量。
- Pub/Sub:Pub-Sub Messaging
消息队列的优点:
- 分离消息的生产者和消费者,使其在代码层面解耦合
- 允许消费者对消息进行异步处理,加快处理速度。
- 访问控制中的峰值控制。
Pulsar
参考资料:
- 下一代消息队列pulsar到底是什么
- pulsar/concepts-messaging
架构上来说,Pulsar是Pub-sub架构
- Broker:无状态服务层,负责接受和传递消息、集群负载均衡
- Apache BookKeeper:有状态持久化层,由一组名为Bookie的存储节点组成
- Producer:数据生产者,负责发布数据到Topic
- Consumer:数据消费者,负责从Topic订阅数据
使用ZooKeeper作为元数据存储
其他消息队列是分区存储,Pulsar是分片存储。
Pub-sub架构(发布/订阅),异步的服务间通信方式,适用于无服务器和微服务。发布到主题的任何消息都会立即被主题的所有订阅者接收。
多层架构:
- 租户,可以看作是第一个层级,比如大的部门
- namespace:命名空间,可以看作是第二个层级。
Subscriptions
有四种模式:
- Consumerless subscriptions,这个是例外,没有consumer的时候subscription mode的undefined的。
- Exclusive:只有一个Consumer允许连接到subscription
- Failover:允许连接多个Consumer,一般情况下都发送给master consumer,如果master consumer无法连接了(如上图ConsuemrB-1)则全部转发到另外一个Consumer上。
- Shared,或者说round-robin,同样是多个Consumer对应单个Subscription,每个包以均等的概率分配给这些Consumer,且只发送给一个Consumer。
- 如果一个Consumer断开连接,那所有发送给它且还没有ack的包会被重新调度,发送给剩下的consumer。
- 不保证顺序
- Key_shared:同样是多个Consumer对应单个Subscription,但是每个Consumer只接受指定的Key的Message
- 原文是message with same key or same ordering key are delivered to only one consumer. 感觉意思好像有点区别
- 如果consumer断开连接,则它所对应的key会重新分配。
pulsar中,一个Consumer可以同时订阅多个topic(multi-topic subscriptions)
partition topic
一般的topic只能够由一个broker服务,这限制了它的最大流量。
Partitioned topic可以由多个broker处理,本质上由N个内部topic实现,其中N被称为partition的数量。
当向topic发送数据的时候,每一个message会被转发到其中一个broker