kafka分布式架构下上下游两个微服务通信性能不匹配的话比如上游的QPS是200下游QPS只有100那么此时上游和下游之间以联机接口的方式通信就会把下游给打垮。没有什么是加一层不能解决的尤其是这种平衡二者速度的问题如果是写场景就加队列如果是读场景就加缓存计算机领域的常规操作啦。1、高性能加了消息队列以后本质上是一个生产者消费者模型并且属于多生产者多消费者模型我们知道按照生产者消费者模型的规则同一时刻最多只能有一个生产者/消费者来访问临界资源除非临界资源划分了槽位那就可以把并发粒度控制在每个槽位。首先按照Topic划分槽位这样并发粒度就可以是Topic级别进一步每个topic内部再划分patition这样并发的粒度又精细化到了patition。2、高可用备份我们直接按照最小的单位patition去说就像谈论k8s的时候最常提及的就是最小的单位podpatition不能只有一份一定要有副本patition越来越多肯定不能都部署在同一个服务上所以就要划分broker把patition打散分布在不同broker上并且patition的本体和副本不在同一个broker上这样防止一个broker崩了patition的本体和副本全崩了。说到这里你应该就发现了kafka实现高可用不是redis、MySQL那样的主从集群kafka的备份粒度不是一整台MySQL服务器而是patition。持久化再就是要持久化到磁盘目的后面再来补充//todo3、消费者组因为一个topic不止被一个下游服务消费比如说有个订单的topic既要被扣减库存的服务消费又要被增加积分的服务消费但是二者消费的进度不一样可能扣减库存的服务已经消费到offset9的位置了增加积分的服务比较慢才消费到offset3的位置。既然大家对于同一个topic的消费速度不一样就只能划分组。4、zookeeper组件太多了每个组件都有自己的状态所以需要有一个统一来管理维护的角色——分布式协调服务。rocketMQ对于rocketMQ不需要从0到1去学聪明的做法是跟kafka对比着去学主要是两点在架构上做了减法在功能上做了加法。在架构上做了减法去掉zookeeper采用轻量级的nameserver服务。因为zookeeper其实很强大可以实现名字服务、分布式锁、配置管理等等但是kafka只用到了名字服务这个功能属于杀鸡用牛刀后来kafka的开发者也意识到了这个问题所以新版的kafka去掉了zookeeper改用Raft算法。底层存储逻辑变了提升写入速度。kafka存储patition的时候给每个patition划分成多个segment每个segment对应磁盘里的一个文件每个文件里是顺序写。但是随着patition的增多这个文件写一下那个文件写一下顺序写逐渐“收敛”到了随机写。所以rocketMQ索性维护一个大文件在这个大文件里顺序写然后每个patition里维护索引指向大文件读的时候读两次有点“回表”的感觉哈在功能上做了加法新增了定时消息比如你12点下单晚上17点的预定外卖可能16:00的时候rocketMQ才会推给商家服务。下面是2023年写的理解不够一、消息队列的流派有broker的MQ重Topic必须有topic kafka轻Topic无broker的MQ二、kafka基本概念三、demo——生产者和消费者——单机官方demo;:Apache Kafka消费者有两种消费的方式如下就像我们进群一样有的刚进来以后只能看见进群之后的消息有的可以看到全部历史群聊。既然“历史群聊”也可以被看见那就说明消息不是和socket通信一样发完以后关掉server和client就没有了的而是被保存了下来。对的以日志的形式保存在kafka服务器上。具体位置可以自己指定。有个问题“历史聊天记录”太多多达几个T一个磁盘放不下怎么办这就引出了Topic分区。3.1 Topic分区除了能让磁盘放下之外分区还有一个好处。之前只放在一个文件的时候一次只能有一个producer去写这个文件但是分区以后 读写可以并行了如何指定创建几个分区把一个topic分成几个区在创建topic的时候用命令参数--partitions 去指定3.2 单播和多播其实是一个东西单播对于同一个consumerGroup里订阅了同一个topic的消费者们只有一个consumer能收到producer发送的消息而且是最新加入的那个consumer。PS:consumer1和consumer2在一个组里运行时指定的截图的时候可能被挡住了多播不同的consumerGroup组订阅同一个topic那么每个组里只有一个consumer能收到消息。四、搭建kafka集群以3个brokerkafka节点的集群为例这里我们用3个端口代表3个节点就不开3个服务器了要新建3个server.properties文件然后启动3个节点有了集群以后创建topic的时候可以指定生成副本也就是备份一共有3个节点也就可以有3个备份。而且kafka会自动指定哪个节点作为leaderleader可以理解为MySQL主从复制的master以leader节点存储的信息为主producer也只往leader节点上发消息不是3个节点都发同样consumer也只去读leader节点上的消息其他两个节点去同步/拷贝leader的信息其他两个节点只是在leader挂了的时候才能用到这又涉及到了选举的问题以后再说选举策略如上图所示名为my-replicated-topic的topic有两个分区partition0和partition1这两个分区各自都有3个副本其中partition0的leader是2号节点partition1的leader是0号节点示意如下