Pulsar由雅虎开发,是Apache下的开源项目,但并不是主流的消息队列,一般主流的消息队列,都是将消息存储在Broker的磁盘或者内存中
但是当某个Broker节点出现故障的时候,并不是集群中个人和的一个节点都能代替这个故障的节点,只有和故障节点具有同样的节点才可以代替,这种存储了状态的节点称为有状态的节点
Stateful Node
Pulsar和其他的消息队列在架构上,最大的不同就是,Broker是无状态的,也就是说,Pulsar的Broker既不保存元数据,也不存储消息,那么Pulsar消息存在哪里了呢?
上面是Pulsar的架构图,上面的架构图中,我们看右侧的BK和ZK,ZK是用于分布式元数据保存的
而BK是存储消息数据的,BK类似HDFS,是一个分布式存储的集群,其存储单元和HDFS不一样,HDFS中存储单元就是文件,BK的存储单元是Ledger
本质上就是一个WAL,就是主题队列中的一段,存储了连续的若干条消息,消息在Ledger中称为Entry,为了保证Ledger中的Entry严格顺序
Broker一旦创建了一个Ledger之后,只有该Broker可以写入Entry,而且Broker关闭了之后,Ledger就不能再写入了
连接上也能新建一个Ledger了
这种一次性写入的设计,就是为了解决并发写入控制的问题,也不共享,也不用加锁了
而且因为任何数据都不在Broker上保存,所以Broker也就是无状态的节点
因为无状态,所以一个时刻,每个主题的分区,都是会落在具体的Broker上的,不能说多个Broker同时读写一个分区,会出问题的
所以我们有一个功能,需要确定并划分哪些Broker管理哪些的主题分区,就是Load Balancer,Managed Ledger这个模块负责管理本节点用到了哪些Ledger
Pulsar的客户端在读写之前,要在元数据中找到分区当前所在的那个Broker,而这个查找,在Pulsar中由于关系是动态的,需要根据Broker的复杂情况调整
于是先去读写Service Discovery模块,获取当前的主题和Broker的关系,连接到Broker上进行消息收发
剩下的Global replicators模块虽然会复制消息,但只是为了在不同的集群中共享数据
像这种将存储分离出去的架构,有何优缺点?
因为对于Pulsat本身来说,不需要存储数据,节点变为无数据的了,所以管理一个无状态的节点的集群,相对会容易些,集群中的每个节点都是一样,可以快速的水平扩展
但是这样本质上就是讲问题抛给了存储系统,存储系统需要实现的功能是很简单,高效的存储数据,但是BK仍然绕不过数据一致性,节点故障转移,而且因为集群从一变成多个了,系统更加负载
Pulsar从自身去请求BK去读数据,会增加一次网络传输,消耗了性能
但是对于一些常见的业务系统,这种设计很合理,因为存储系统是现有成熟的,只需要专注于业务就可以了
那么我们说一下Pulsar这个消息队列为何没有发扬光大呢?
做项目本质上可以说是做加减法
我们从这个架构的设计上进行分析
好处是,读写分离,专注传输,集群状态变更速度快,利用现成的存储系统开发效率高
坏处是,增加网络传输,降低性能,读写性能低
从上面来看,好处的确不少,但是我们现阶段对于MQ的要求主要就是性能,在性能提升不上去的情况下,好处多也没啥用,就好比是容器界的gVisor,虽然代表着一种发展方向,但是由于性能问题,应用面仍然上不去