本来插曲系列是应大家要求去更新的，但是好像第一篇的kafka效果还可以所以更插曲就勤快些了（毕竟谁不想看着自己被多多点赞呢hhh🤣），上一篇说了一个案例是为了说明如何去考量一个kafka集群的部署，算是一个参考吧，毕竟大家在不同的公司工作肯定也会有自己的一套实施方案。 这次我…

此时我们要拉取一个version的值，并把一个 needUpdate 参数修改为true，然后去唤醒 Sender 线程去拉取元数据，而这需要通过一个网络组件 NetworkClient 和Broker通信。 在此同时，主线程会进行阻塞，等待元数据的到来。而当元数据拉取完成后，…

之前我们介绍过了 Kafka 整体架构，Kafka 生产者，Kafka 生产的消息最终流向哪里呢？当然是需要消费了，要不只产生一系列数据没有任何作用啊，如果把 Kafka 比作餐厅的话，那么生产者就是厨师的角色，消费者就是客人，只有厨师的话，那么炒出来的菜没有人吃也没有意义，如…

ZooKeeper是用来协调（同步）分布式进程的服务，提供了一个简单高性能的协调内核，用户可以在此之上构建更多复杂的分布式协调功能。 多个分布式进程通过ZooKeeper提供的API来操作共享的ZooKeeper内存数据对象ZNode来达成某种一致的行为或结果，这种模式本质上是…

在分布式架构中经常采用的结构就是一主多从，主节点祈使句就是负责协调管理集群用的。我们可以借用这个场景去展开。 首先我们需要有一个master节点，然后cluster代表的是集群的名字，name是指服务名，address是指服务的地址。masterPath是指master的zno…

前面几篇以spring作为主题也是有些时日了，高并发分布式这个主题也挺大能说挺多东西的，也是再开了个坑，然后分P来慢慢跟进吧。 我和大部分人一样是一名学习者，不是布道者，更多的是自己的学习总结而不具有权威，进行总结，尽量让人看的简单是我的本意，然后有错则改，无则加勉是最好的，在…

虽然这是一个源码的预热篇同样这也是插曲篇的一个总结，我们从一开始的集群的各个角色，到集群的设计，到网络模型，到生产者，消费者都已经提了个遍。这一篇会把最后的一个内核提一下，然后对以往的概念三篇做一个总结，把流程梳理一下，增加记忆的同时，也让后面的源码变得更加轻松愉快，好的这是最…

假设每天集群需要承载10亿数据。一天24小时，晚上12点到凌晨8点几乎没多少数据。 使用二八法则估计，也就是80%的数据（8亿）会在16个小时涌入，而且8亿的80%的数据（6.4亿）会在这16个小时的20%时间（3小时）涌入。 QPS计算公式：640000000 ÷ (3x60…

从上一年开始鸽了好久的源码篇，终于也是给整了一下。其实一方面也是，怕自己整理不好，看的云里雾里，那也没什么意思，所以还是花了些时间准备，也是希望能够和大家一起进步吧。注意，本文篇幅非常长，建议结合PC端的右侧导航观看，效果更佳。好的！话不多说，开始吧！ 如果要一个一个类地去说明…