linchonghui888的博客

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

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

pulsar服务是经典的C/S架构，由客户端和服务端构成。服务端提供处理读写请求服务，客户端负责发起读写请求。pulsar将客户端按照读写分成了生产者和消费者，但是无论怎么分，它们本质上都是Pulsar客户端并有很多相同的地方，本篇就针对客户端进行分析。

通过上面一套组合拳打下来，相信你对go的基础知识以及设计系统都有一定的了解，如果可以希望可以基于自己的理解实现一个，因为实践才是检验真理的唯一标准。基于Go开发出学生成绩管理系统(或者其他系统)并不是终点，只是一个起点，准备好用这门优雅的语言去打开属于你的新世界吧～ 😋。

而内心世界里，我仿佛就是一个无所不能的魔法师🧙‍♀️，一挥动魔法棒🪄，高楼大厦拔地而起，再念一段咒语，山川河流、各个形态的动物都随我所想的模样出现，最后大喝一声，“启动～”，这个“世界”就仿佛被赋予了生命力一样活了过来，河流唱着歌从高山流下来，经过嬉闹的丛林，丛林里小鹿在跟蝴蝶🦋嬉闹，此时池边蛰伏已久的鳄鱼🐊正准备扑向小鹿，只听我大喝一声，“停～”，整个世界就像按下了暂停键，所有东西都停止在那一刻，于是乎我敲着键盘重新编码鳄鱼的行为，鳄鱼不需要捕食其他动物也能存活，只需要通过呼吸和喝水也能获得足够能量。

直奔主题，针对小白无法正确使用自定义的package包进行讲解。

在软件设计中，为了方便能够应对不同的场景，一般在一些容易有差异的环节会考虑允许用户自定义逻辑，拦截器就是其中的一种实现方式，像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类的重要性、聊聊它都负责哪些事情以及大概实现，具体每个细节展开都能单独写一篇文章，这个敬请期待～

在人生的每个阶段，我好像都有遇到那种天然就知道自己该做什么事情并且极度“自律”的人，上学那会就有同学雷打不动的学习，哪怕没人监督也照样认真学习。与之相比的我感觉就像是这个世界的NPC一样，做事三分热度，感兴趣的时候也能热血沸腾狠狠学一段时间，但是大部分时候还是想偷懒，一直以来觉得是自己自控力问题导致自己不够自律，也会是不是给自己定制计划并设置奖惩，但最后都不了了之。你是否也有同样的经历并且苦恼呢。