kafka集群

zookeeper集群+kafka集群

kafka3.0之前依赖于zookeeper

zookeeper开源，分布式的架构。提供协调服务（Apache项目）

基于观察者模式设计的分布式服务管理架构

存储和管理数据。分布式节点上的服务接受观察者的注册，一旦分布式节点上的数据发生变化，由zookeeper来负责通知分布式节点上的服务

zookeeper分为领导者leader和追随者follower组成的集群。

只要有一半以上的集群存活，zookeeper集群就可以正常工作。适用于安装奇数台的服务集群。

全局数据一致，每个zookeeper每个节点都保存相同的数据。维护监控服务的数据一致

数据更新的原子性。要么都成功，要么都失败

实时性，只要有变化，立刻同步

zookeeper的应用场景

1、统一命名服务

在分布式的环境下，对所有的应用和服务进行同意命名

2、统一配置管理

配置文件要同步，KAFKA的配置文件被修改，可以快速同步到其他节点

3、统一集群管理

实时掌握所有节点的状态

4、服务器动态上下线

5、实现负载均衡

把访问服务器的数据，发送到访问最少的服务器处理客户端的请求

领导者和追随者：zookeeper的选举机制

三台服务器： A B C

A先启动，发起选举，投票给自己，只有一票，不满半数，A的状态是LOOKING

B启动，再发起一次选举，A和B分别投自己一票，交换选票信息，myid，A发现B的myid比A大，A的这票会转而投给B

此时，A有0票,B有2票，没有半数以上的结果，A和B都进入LOOKING（B有可能成为leader）

C启动，如果C的myid最大，A和B都会把票投给C

此时A是0，B是0，C是3

C的状态变为leader，A和B变成follower

只要leader确定，后续的服务器都是追随者

只有两种情况会开启选举机制

1、初始化的情况会产生选举

2、服务器之间和leader丢失了连接状态

leader已经存在，建立连接即可

leader不存在

①服务器ID大的胜出

②EPOCH大，直接胜出

③EPOCH相同，事务ID大的胜出

EPOCH每个leader任期的代号，没有leader，大家的逻辑地址相同，每投完一次之后，数据是递增

事务ID，表示服务器的每一次变更，每变更一次事务ID变化一次

服务器ID，zookeeper集群当中的机器都有一个ID，每台机器不重复，和myid保持一致

zookeeper+kafka（2.7.0）

kafka（3.4.1）【不再依赖zookeeper】

zookeeper+kafka（2.7.0）实现过程

192.168.233.10 zookeeper+kafka

192.168.233.30 zookeeper+kafka

192.168.233.40 zookeeper+kafka

同步

消息队列：kafka

为什么引入消息队列（MQ）。他也是一个中间件，在高并发环境下，同步请求来不及处理。来不及处理的请求会形成阻塞。

比方说数据库，会形成行锁或表锁。请求线程满了，超标了，too many connetction（出现这个，整个系统雪崩）

消息队列的作用：异步处理请求（核心）【典型：短信验证码】；流量削峰；应用解耦

解耦:

耦合: 在软件系统当中，修改一个组件需要修改所有其他组件，高度耦合

低度耦合:修改其中一个组件，对其他最贱影响不大，无需修改所有

只要通信保证，其他的修改不影响整个集群，每个组件可以的独立的扩展，修改，降低组件之间的依赖性

依赖点就是接口约束，通过不同的端口，保证集群通信

可恢复性：系统当中的有一部分组件消失，不影响整个系统。也就是说在消息队列当中，即使有一个处理消息的进程失败，一旦恢复还可以亚新加入到队列当中，继续处理消息。

缓冲：可以控制和优化数据经过系统的时间和速度。解决生产消息和消费消息处理速度不一致的问题。

峰值的处理能力：消息队列在峰值情况之下，能够顶住突发的访问压力。避免专门的突发情况而对系统进行修改

异步通信：允许用户把一个消息放入队列，但是不立即处理，等用户想处理的时候再处理

消息队列的模式

点对点一对一：消息的生产者发送消息到队列中，消费者从队列中提取消息，消费者提取完之后，队列中被提取的消息将会被移除。后续消费者不能再消费队列当中的消息。消息队列可以有多个消费者，但是一个消息只能由一个消费者提取

RABBITMQ

发布/订阅模式：一对多，又叫做观察者模式（kafka默认模式）

消费者提取数据之后，队列中的消息不会被清除

生产者发布一个消息到主题，所有消费者都是通过主题获取消息

主题：topic。topic类似于一个数据流的管道，生产者把消息发布到主题，消费者从主题当中订阅数据。主题可以分区，每个分区都有自己的偏移量

分区：partition。每个主题都可以分成多个分区，每个分区都是数据的有序子集，分区可以允许kafka进行水平拓展，以处理大量数据消息在分钟按照偏移量存储，消费者可以独立读取每个分区的数据。

偏移量:是每个消息在分区中唯一的标识。消费者可以通过偏移量来跟踪获取已读或者未读消息的位置。也可以提交偏移量来记录已处理的信息。

生产者: producer 生产者把数据发送kafka的主题当中，负责写入消息

消费者：从主题当中读取数据,消费者可以是一个也可以是多个。每个消费者有一个唯一的消费者组ID，kafka通过消费老实现负载均衡和容错

经纪人：Broker。每个咖啡ka节点都有一个Broker，每个负责一台kafka服务器，ID唯一，存储主题分区当中数据，处理生产和消费者的请求

维护元数据（zookeeper）

zookeeper：zookeeper负责保存元数据，元数据就是topic的相关信息（发在哪台主机上，指定了多少分区，以及副本数、偏移量）

zookeeper自建一个topic主题：__consumer_offsets

3.0之后不依赖zookeeper的核心，元数据由kafka节点自己管理

kafka的工作流程

至少一次语义：只要消费者进入，确保消息至少被消费一次

同步操作

取消同步

brokerid不能重复

10

30

40

同步

#!/bin/bash

#chkconfig:2345 22 88

#description:Kafka Service Control Script

KAFKA_HOME='/opt/kafka'

case $1 in

start)

echo "---------- Kafka 启动 ------------"

${KAFKA_HOME}/bin/kafka-server-start.sh -daemon ${KAFKA_HOME}/config/server.properties

;;

stop)

echo "---------- Kafka 停止 ------------"

${KAFKA_HOME}/bin/kafka-server-stop.sh

;;

restart)

$0 stop

$0 start

;;

status)

echo "---------- Kafka 状态 ------------"

count=$(ps -ef | grep kafka | egrep -cv "grep|$$")

if [ "$count" -eq 0 ];then

        echo "kafka is not running"

    else

        echo "kafka is running"

    fi

;;

*)

    echo "Usage: $0 {start|stop|restart|status}"

esac

kafka默认端口：9092

所有kafka命令都在bin下面

30

kafka-topics.sh --create --zookeeper 192.168,233.10:2181,192.168.232.30:2181,192.168.233.40:2181 --replication-factor 2 --partitions 3 --topic test1

创建主题:

1、在kafka的bin月录下，是所有的kafka可执行命令文件

2、--zookeeper 指定的是zookeeper的地址和端口，保存kafka的元数据

3、--replication-factor 2 定义每人分区的副本数

4、partitions3 指定主题的分区数

5、--topic test1 指定主题的名称

10

查看所有

查看指定

同步

30

40

10

30

40

10

不同主机订阅不同主题

新开10 30 40

30

40

两台10

30

40

修改分区数

30

30

1、zookeeper: 主要是分布式，观察者模式，统一各个服务器节点的数据在kafka当中，收集保存kafka的元数据

2、kafka消息队列 订阅发布模式

RABBIT MQ(实现rabbit MQ消息队列)