linchonghui888的博客

PulsarService是Pulsar服务启动的核心类，其内置了七大重要的对象如下图BrokerService: 核心是启动Netty，处理客户端的TCP连接，同时通过多个Map容器维护例如Topic信息、Topic归属信息等等，除此之外还启动一批定时线程定期检测(消息过期、压缩、客户端活跃等)LoadManager: 负责处理Broker服务的负载均衡WebService: 对外提供HTTP服务，例如管理流的操作(元数据)等。

相信大家对schema创建的流程已经很清楚了，再次简单归纳下客户端根据用户定义的结构信息创建对应的Schema对象，并将结构信息以HTTP请求发给服务端服务端检测并根据Schema兼容策略做相对应的处理，一般情况下会调用Bookkeeper创建Ledger以及EntryBookkeeper将此Schema数据持久化到磁盘，相当于Schema信息会被Bookkeeper当作一条消息进行存储这基本上就是全部内容，当然细节感兴趣的小伙伴可以自行跟踪代码，相信你会有更多收获～

在软件设计中，为了方便能够应对不同的场景，一般在一些容易有差异的环节会考虑允许用户自定义逻辑，拦截器就是其中的一种实现方式，像Spring、Kafka、Pulsar等都支持这种方式。流程简化起来就如下图，客户端跟服务端的写消息请求和接收请求都要先通过一遍拦截器，因此用户都过自定义拦截器逻辑就能以一种无侵入、规范化的方式来改动消息发送以及处理响应的行为。

Namespace下的Topic是分Bundle进行管理的，每个Namespace都是一个哈希环，而Bundle负责管理环上某个范围上的Topic。通过这种方式可以更好的进行Topic的管理。当某个Bundle上负责的Topic越来越多时，会导致负责该Bundle的Broker节点压力变大。因此Pulsar还提供了Bundle分裂的机制，这个机制支持自动触发以及手动触发，今天这篇文章就从源码的角度分析手动触发Bundle分裂时服务端会发生什么。

可以看到Pulsar里大量使用了异步回调处理，这样的设计在高并发场景大幅提升服务的性能，尽可能的避免了存在瓶颈的地方。不过带来的另一影响是，代码跟踪起来相对来说容易“迷路”，因此掌握好异步设计的逻辑是很有必要的，可以帮助我们更好的跟踪Pulsar的代码。

以上就是Pulsar的Lookup机制的实现流程，在寻址的过程中，需要阅读的伙伴具备一致性哈希的知识，因为Pulsar的Topic归属就是引入了一致性哈希算法来实现的。

以上就是Pulsar中TTL的实现源码流程，我在这个过程中尽量省略了一些非必要的逻辑，主要是跟踪了主线，像一些地方也是值得跟踪的，感兴趣的伙伴可以自行跟踪。同时在这里我们可以看到，TTL过程只移动了游标位置并不涉及到数据的删除，说明在Pulsar的设计中将两者进行了分离，这是一种很好的职责设计思路，各自负责自己的一那部分。一方面在程序维护时可以避免改动引起一些相关性不那么大的影响，另一方面对于程序执行的整体性能来说也是比较高效的。

任何东西都有生命周期，就像沙丁鱼罐头🥫也会过期一样，咱们的消息本身也是有生命周期的，因此像Pulsar这样的流平台/消息队列也提供了Retention、Backlog和TTL机制。

本文主要强调PersistentTopic类的重要性、聊聊它都负责哪些事情以及大概实现，具体每个细节展开都能单独写一篇文章，这个敬请期待～

生产者写数据的流程到这里基本就结束了，怎么样，是不是没想象中那么可怕？也许你对1、客户端对象创建 2、生产者对象创建 3、消息发送这三步之间的关系还有点迷迷糊糊，那就请允许我给你举个例子，1、客户端对象创建相当于一座新城市的创建，打好城市的地基，2、生产者对象创建相当于在这个地基的基础上建起了城市，发电厂等等，最重要的是修建其通往其他各个城市的交通要道，最后的3、消息发送相当于这个新城市的居民们乘坐高铁去其他的城市。这么说相信你一定已经明白了～如果还有其他疑问欢迎在下面的评论区一起讨论。

系统学习Pulsar的大纲。

纸上得来终觉浅，绝知此事要躬行。学习不能仅仅停留在纸面上或者理论，脱离使用去探讨设计或者源码都是不切实际的。因此今天一起体验了一把Pulsar IO，除此之外Pulsar还提供了非常丰富的跟其他系统交互的Connector，详细可以看上面发的下载地址并尝试使用自己感兴趣的Connector感受下实操的快乐～

在有些业务场景，我们需要将自己的业务逻辑“融入”路由策略，因此像Pulsar、Kafka等消息中间件都是支持用户进行路由规则的自定义的。这里为了好玩，咱们尝试将数据按照 1:2:3:4 等比例分别落在四个分区如何？说干就干，自定义路由也是比较简单的，只需要实现Pulsar MessageRouter接口的choosePartition方法即可，实现逻辑如下count++;return 3;

关于Pulsar Schema，咱们要想想以下几个问题。

以上就是Pulsar中Worker的调度过程，这里主要是以Worker独立部署的方式进行讲解的，基于Broker启动的Worker感兴趣的朋友可以自行跟踪下代码。

基于Function接口实现自己的逻辑，打包编译成jar包/***/@Override基于该jar包启动function启动客户端监听test1-output-topic往Topic test1-input-topic 里写入数据消费者打印启动function有时候会遇到下面这个问题，一般都是function命名冲突导致的，修改yaml配置里name在重新create下就可以了。

本篇主要讲述pulsar topic部分，主要从设计以及源码的视角进行讲述。在pulsar中，一个Topic的新建、扩容以及删除操作都是由Broker来处理的，而Topic相关的数据是存储在zookeeper上的。本篇文章模拟一个高效的学习流程进行展开在日常对pulsar Topic操作时，咱们常常会用到以下指令更多的操作可以参考 https://pulsar.apache.org/docs/3.0.x/admin-api-topics/在这里列举了针对分区并存储Topic的四个操作指令以上就是使用方式，

在这里解答下引言小故事张三是通过什么规则被选成“监督者”的？张三是通过zookeeper的Paxos算法选举产生的如果张三也不辞而别呢？大狗和二狗也会通过zookeeper监听张三的状态，如果张三不辞而别的话，大狗二狗会通过zookeeper选举成为新的“监督者”为啥要通过签到本的方式，而不是张三直接去挨个挨个看？通过签到本的方式比较节约张三的时间，否则当员工比较多的时候并且对感知时间比较快的时候，张三就要每隔几分钟就要跑去挨个挨个看，这样没多久张三也要“不辞而别”了。