消息中间件定义？
其实没有标准定义，一般认为消息中间件属于分布式系统中的一个子系统，关注于数据的发送和接收，利用高效可靠的异步消息传递机制对分布式系统中的其余各个子系统进行集成
为什么要用消息中间件？
低耦合，不管是程序还是模块之间，使用消息中间件进行间接通信逻辑运算
异步通信能力，使得子系统之间得以充分执行自己的逻辑而无需等待。
缓冲能力，消息中间件像是一个巨大的蓄水池，将高峰期大量的请求存储下来慢慢交给后台进行处理，对于秒杀业务来说尤为重要。
伸缩性 是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。就像弹簧一样挂东西一样，用户多，伸一点，用户少，缩一点
扩展性 网站增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或者很少改动既有业务功能 就可以上线新产品
消息队列分类
1 JMS（JAVA Message Service）标准（消息模型）
P2P（Point to Point）：每个消息只有一个消费者。消息生产者将消息发送到消息队列（Queue）中，只有一个消费者能够消费此消息，消费完成之后消息即删除，任意一个消费者都可以消费这个消息，但消息绝对不会被两个消费者重复消费
Publish/Subscribe(Pub/Sub) ：Pub/Sub 的特点是发布到 Topic 的消息会被所有订阅者消费。消息生产者将消息发送到消息主题（Topic）中，所有订阅这个主题的消费者都可以消费此消息，当所有订阅者都消费完成之后才能删除消息。
2 实时流式架构
队列（Queue）模型：当一条消息从队列发送出来后，多个消费者中的只有一个（任何一个都有可能）接收和消费这条消息。消息系统的具体实现决定了最终哪个消费者实际接收到消息。队列模型通常与无状态应用程序一起结合使用。无状态应用程序不关心排序
流式（Stream）模型：相比之下，流模型要求消息的消费严格排序或独占消息消费。对于一个管道，使用流式模型，始终只会有一个消费者使用和消费消息。消费者按照消息写入管道的确切顺序接收从管道发送的消息，流模型通常与有状态应用程序相关联。有状态的应用程序更加关注消息的顺序及其状态
消息中间件发展
Pulsar简介
关于 Apache Pulsar
在2012年由Yahoo开发设计，助力Yahoo的主要应用，如Yahoo Mail、Yahoo Finance，并于2016年底开源，现在是 Apache 软件基金会顶级项目,誉为下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体。
云原生: 面向 K8S，非常适合在 K8S 这种容器编排的系统里面运作
消息流平台: Apache Pulsar 是融合了消息队列以及流处理两种特性的数据平台
Apache Pulsar 的定位
统一的云原生的消息流平台” 兼顾Streaming（流处理消费模式）（重复消费、消费顺序）和 Queuing（队列消费模式）（单消费者
Apache Pulsar 诞生要解决的问题
企业需求和数据规模 多租户 - 百万 Topic - 低延时 - 持久化 - 跨地域复制
解除存储计算耦合 运维痛点：替换机器、服务扩容、数据 rebalance
减少文件系统依赖 性能难保障: 持久化(fsync)、一致性(ack: all)、多 Topic IO 不隔离：消费者读 Backlog 的时候会影响其他生产者和消费者
Apache Pulsar 多租户空间
Apache Pulsar 架构
Broker 计算层 Bookie： Segment 为颗粒度 提供一个存储层
Apache Pulsar 核心组件
Broker（计算层）（协议的解析处理）
BookKeeper / Bookie（存储层）（面向 Segment 的存储语义）
ZooKeeper（协调组件）（元数据的管理、服务发现）
Zookeeper
Pulsar使用Zookeeper进行元数据存储、集群配置和协调
**配置存储：**存储租户，命名域和其他需要全局一致的配置项 每个集群由自己独立的Zookeeper保存集群内部配置和协调信息，例如归属信息，broker负载报告。Bookeeper ledger信息等等
Bookeeper
Pulsar使用Bookeeper进行持久化存储 Apache Pulsar 为应用程序提供有保证的信息传递, 如果消息成功到达broker, 就认为其预期到达了目的地。
为了提供这种保证，未确认送达的消息需要持久化存储直到它们被确认送达。这种消息传递模式通常称为持久消息传递 . 在Pulsar内部，所有消息都被保存并同步N份，例如，2个服务器保存四份，每个服务器上面都有镜像的RAID存储。
Pulsar用Apache bookKeeper作为持久化存储。 bookKeeper是一个分布式的预写日志（WAL）系统，有如下几个特性，特别适合Pulsar的应用场景：
使Pulsar能够李永独立的日志，称为Ledgers、可以随着时间的推移为Topic创建多个Ledger
Apache Pulsar 核心组件-消息存储
Ledger介绍
Ledger介绍 Ledger是一个只追加的数据结构，并且只有一个写入器，这个写入器负责多个Bookeeper存储节点的写入，ledger的条目会被复制到多个Bookies。Ledger本身有着非常简单的语义
Pulsar Broker可以创建、添加内容和关闭Ledger 当一个Ledger被关闭后，除非明确的要写数据或者是因为写入器挂掉导致Ledger关闭，ledger将会以只读打开。 当ledger的条目不再有用的时候，整个ledger可以被删除（Ledger的分布式跨Bookie的）
Pulsar代理（Pulsar Proxy）
Pulsar客户端和Pulsar集群交互的一种方式就是直连Pulsar brokers。然而，在某些情况下，这种直连既不可行也不可取，因为客户端并不知道broker的地址。 例如在云环境或者Kubernetes以及其他类似的系统上面运行Pulsar，直连brokers就基本上不可能了。
Pulsar proxy 为这个问题提供了一个解决方案, 为所有的broker提供了一个网关, 如果选择运行了Pulsar Proxy. 所有的客户都会通过这个代理而不是直接与brokers通信
Apache Pulsar 用户案例
雅虎用 Pulsar 构建日均千亿的消息平台
Apache Pulsar 在腾讯计费场景下的应用
Apache Pulsar 助力江苏移动重塑 5G 时代计费支撑系统
Kafka VS Pulsar
Kafka是一个分布式的流处理平台，最初由Linkedin公司开发，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目，高性能、高吞吐的消息中间件
Kafka VS Pulsar 架构
Kafka 单片架构模型，将服务与存储相结合
Pulsar 则采用了多层架构 无分区，也没有重平衡
Kafka VS Pulsar 性能
单分区的最大写入吞吐量 (MB/s)：数值越高，代表性能越好。
Kafka VS Pulsar 特性
线性扩展（Pulsar扩容丝滑，kafka扩容需要拷贝数据） 高吞吐 （每秒数百万消息） 低延迟(Pulsar大规模消息下依然能够保持) 持久化机制（构建在BookKeeper上，读写IO分离） 部署方式的多样化（裸机、Docker、K8S容器） 消息与流二和一（kafka流处理） 日志层面（kafka追加文件、Pulsar 分段日志到不同服务器） 无状态（Pulsar broker 无状态，kafka broker包含分区日志）
Kafka VS Pulsar 优劣势
优势
更灵活消息和流兼备 创建 topic 数量没有限制，百万topic 与 Kafka 兼容，易于集成 存储与 broker 分离，因此扩展性更好，重新平衡更快、更可靠 易于操作运维：架构解耦和 n 层存储
劣势
相对缺乏支持、文档和案例 插件和客户端相对 Kafka 较少 n 层体系结构导致需要更多组件：BookKeepe
总结来说plusar扩容，增加节点时比kafka更快更方便，且数据处理速度上也比kafka更上一层楼,但是文档支持和资料相对Kafka较少
Pulsar担的起下一代消息引擎的'称号'吗？
• 计算存储分离 解耦计算和存储负载,系统负载均衡调度更加灵活 系统更加的健壮,计算可以认为是无状态的
• 云原生是未来的趋势
docker容器化、k8s服务编排的发展
大数据时代
机器硬件的发展自建机房的高昂成本
微服务架构
动态扩缩容的需求
• 竞争驱动创新 pulsar的出现推动了已有中间件的发展
