zookeeper集群（很少用）+kafka集群（常用）

一、zookeeper

zookeeper+kafka（2.7.0版本）

kafka（3.4.1版本）不依赖于zookeeper

1、定义：zookeeper开源，分布式架构，提供协调服务（Apache项目），基于观察者模式涉及的分布式服务管理架构。作用：存储和管理数据，分布式节点上的服务接受观察者的注册，一旦分布式节点上的数据发生变化，由zookeeper来负责通知分布式节点上的服务

2、特点：zookeeper分为领导者（leader）和追随者（follower）。只要有一般以上的集群存活，zookeeper集群就可以正常工作，适用于安装奇数台的服务器集群；全局数据一致，每个zookeeper节点都保存相同的数据

3、主要作用

（1）维护监控服务器的数据一致，每个zookeeper节点都保存相同的数据；

（2）数据更新的原子性，要么全成功，要么全失败；

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

4、应用场景（记）

（1）统一命名服务：在分布式环境下，对所有的应用和服务进行统一命名

（2）统一配置管理（配置文件同步）：假设kafka的配置文件被修改，可以快速同步到其他节点

（3）统一集群管理★★★：实时掌握所有节点的状态

（4）服务器动态上下线

（5）实现服务在均衡：将访问服务器的数据发送到访问最少的服务器，来处理客户端的请求

5、选举机制

以三台服务器为例：A B C

第一步：A先启动，发起第一次选举，投票给自己，只有1票，不满足半数，此时A是looking状态

第二步：B启动，再发起一次选举，A和B分别投自己一票，交换选票信息，A发现B的myid比自己大，A的这1票会转投给B，此时B2票，A1票，还是不满足半数，A和B都是looking状态

B可能成为leader，C直接成为follower，如果B没有成为leader，那么执行第三步

特殊情况：

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

②leader不存在，服务器ID大的胜出

服务器ID：zookeeper集群中的机器都有一个ID，和myid保持一致

③epoch大，直接胜出

epoch：每个leader任期的代号，如果没有leader代号，大家的逻辑地位相同，但是每投完一次之后，数据递增

④epoch相同，事务ID大的胜出

事务ID：用来标识服务器的每一次变更，每变更一次，事务ID变化一次

第三步：C启动，若C的myid最大，A和B都会把票投给C，此时A—0票，B—0票，C—3票，C的状态变为leader，A和B变为follower

只有leader确定，后续的服务器都是追随者，无论myid大小

只有两种情况重新开启选举机制：

①初始化的情况下产生选举

②服务器之间和leader丢失连接状态

二、消息队列kafka（重要）

1、为什么要引入消息队列（MQ）？

kafka是一个中间件，负责发消息。在高并发环境下，同步请求来不及处理，会形成阻塞。比如，数据库会形成表锁或行锁。请求线程超标，会出现错误too many connection，整个系统崩溃（系统雪崩）

客户端————kafka————服务端

2、消息队列的作用

（1）异步处理请求（留一个延迟时间）

（2）流量削峰

（3）应用解耦

（4）可恢复性

（5）缓冲机制

（6）峰值处理能力

（7）异步通信★★★

2、消息队列的模式

（1）点对点模式（一对一模式）

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

（2）发布和订阅模式（一对多、观察者模式）

生产者发布一个消息到主题（topic）中，所有消费者都是通过主题获取消息，消费者提取数据后，队列中的消息不会被移除

★主题：topic，类似于一个数据流管道，生产者把消息发布到主题，消费者从主题中订阅数据（获取数据），每个主题可以分成多个分区，每个分区有自己的偏移量。kafka默认不允许删除主题（可以理解成微信群）

★分区：partition，每个主题可以分成多个分区，每个分区是数据有序子集，分区可以允许kafka进行水平拓展，以处理大量数据，消息在分区中按照偏移量存储，消费者可以独立读取每个分区的数据【人为创建】（可以理解成备份）

★偏移量：是每个消息在分区中的唯一标识，消费者通过偏移量来跟踪、获取、已读、未读消息的位置；也可以通过提交偏移量记录已处理的信息——指示消费者到底要获取哪个位置的数据（可以理解成微信群中的聊天时间）

分区数量越多，存储数据越多，处理并发能力越强

获取消息的两种方式：

①begin：从头开始获取所有【常用】

②实时获取，只消费后续产生的消息【常用】

③指定偏移量消费【代码实现】

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

消费者：consumer，从主题中读取数据，消费者是一个或多个，每个消费者都有一个唯一的消费者组ID，kafka通过消费者实现负载均衡和容错

3、kafka的工作流程

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

三、zookeeper+kafka实验

实验目的：监控所有服务器上的数据一致

实验条件：

主机名	IP地址	组件	硬件条件 （最少）
test1	20.0.0.10	zookeeper+kafka（2.7.0版本）	2核4G
test2	20.0.0.20	zookeeper+kafka（2.7.0版本）	2核4G
test3	20.0.0.30	zookeeper+kafka（2.7.0版本）	2核4G

实验步骤：

1、部署zookeeper【所有服务器】

（1）升级java环境

yum install -y java-1.8.0-openjdk java-1.8.0-openjdk-devel

（2）解zookeeper安装包，改名

（3）修改zookeeper配置文件

1，2，3表示每个zookeeper集群的初始myid【自定义】

3188表示领导者和追随者之间交换信息的端口（内部通信的端口）

3288表示一旦leader丢失响应，重新开启选举的端口（选举端口—互相通知选票信息的端口）

（4）创建目录【已在配置文件中自定义】

（5）给集群中的每台服务器分配myid

test1

test2

test3

（6）启动脚本【所有服务器】

1）创建脚本文件

2）赋权脚本文件

chmod +x /etc/init.d/zookeeper

3）添加到系统服务中，让系统识别

chkconfig --add zookeeper

4）依次启动zookeeper，查看leader和follower状态

启动service zookeeper start

查看service zookeeper status

①第一次先启动test1

②第二次启动test2

此时再次查看test1的状态，选举完成后test1自动变为follower

③第三次启动test3

选举完成，2票大于1票，即便test3启动，leader也不会改变

2、部署kafka【所有服务器】

（1）升级java环境

yum install -y java-1.8.0-openjdk java-1.8.0-openjdk-devel

（2）解kafka压缩包

（3）声明kafka环境变量

添加

export KAFKA_HOME=/opt/kafka

export PATH=$PATH:$KAFKA_HOME/bin

（4）修改kafka的配置文件

test1

test2

test3

（5）创建kafka的启动脚本【所有服务器】

①赋权脚本chmod +x /etc/init.d/kafka

②添加系统命令，让系统识别chkconfig --add kafka

③启动kafka

kafka的默认端口号9092

（6）主机映射

【注意：在kafka的bin目录下创建，bin是kafka所有可执行命令文件】

（7）创建主题topic

【在任意一台服务器上创建主题即可，所有服务器都可使用这个主题】

kafka-topics.sh --create --zookeeper 20.0.0.10:2181,20.0.0.20:2181,20.0.0.30:2181 --replication-factor 2 --partitions 3 --topic yyy

①查看所有主题topic详情

②查看指定主题topic详情

（8）发布消息

test1发布

（9）消费（订阅）

test2消费

①实时同步

②begin同步

test3也能同步获取消息

（10）不同主机订阅不同主题

①test3创建主题mmm

test3创建主题nnn

②test2在mmm主题上发布消息

test1订阅主题mmm

③test2在nnn主题上发布消息

test1订阅mmm

结论：主题之间互相隔离

（11）修改分区数

（12）删除主题【kafka机制默认不能删除主题】

（13）查看内部保存的元数据信息