消息队列
1：什么是消息队列
消息(Message）是指在应用间传送的数据。消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。
消息队列(Message Queue)是一种应用间的通信方式，消息发送后可以立即返回，由消息系统来确保消息的可靠传递。消息发布者只管把消息发布到中而不用管谁来取，消息使用者只管从中取消息而不管是谁发布的。这样发布者和使用者都不用知道对方的存在。
2：消息队列的特征
- (1)存储
- 与依赖于使用套接字的基本TCP和UDP协议的传统请求和响应系统不同，消息队列通常将消息存储在某种类型的缓冲区中，直到目标进程读取这些消息或将其从消息队列中显式移除为止。
- (2)异步
- 与请求和响应系统不同，消息队列通过缓冲消息可以在应用程序中公开一定程度的异步性，允许源进程发送消息并在队列中累积消息，而目标进程则可以挑选消息进行处理。这样，应用程序就可以在某些故障情况下运行，例如连接断断续续或源进程或目标进程故障。
路由：消息队列还可以提供路由功能，其中多个进程可以在同一队列中读取或写入消息，从而实现广播或单播通信模式。
3：为什么需要消息队列
- (1)解耦
- 允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
- (2)冗余
- 消息队列把数据进行持久化直到它们己经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的'插入一获取一删除'范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息己经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
- (3)扩展性
- 因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。
- (4)灵活性&峰值处理能力
- 在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
- (5)可恢复性
- 系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
- (6)顺序保证：
- 在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。(Kafka保证一个Partition内的消息的有序性）
- (7)缓冲
- 有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。
- (8)异步通信
- 很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
Kafka基础与入门
1：kafka基本概念
Kafka是一种高吞吐量的分布式发布/订阅消息系统，这是官方对kafka的定义，这样说起来，可能不太好理解，这里简单举个例子：现在是个大数据时代，各种商业、社交、搜索、浏览都会产生大量的数据。那么如何快速收集这些数据，如何实时的分析这些数据，是一个必须要解决的问题，同时，这也形成了一个业务需求模型，即生产者生产(produce)各种数据，消费者(consume) 消费（分析、处理）这些数据。那么面对这些需求，如何高效、稳定的完成数据的生产和消费呢？这就需要在生产者与消费者之间，建立一个通信的桥梁，这个桥梁就是消息系统。从微观层面来说，这种业务需求也可理解为不同的系统之间如何传递消息。
kafka是Apache组织下的一个开源系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop平台的数据分析、低时延的实时系统、storm/spark流式处理引擎等。kafka现在己被多家大型公司作为多种类型的数据管道和消息系统使用。
2：kafka角色术语
kafka的一些核心概念和角色
- (1)Broker：Kafka集群包含一个或多个服务器，每个服务器被称为broker（经纪人）。
- (2)Topic：每条发布到Kafka集群的消息都有一个分类，这个类别被称为Topic（主题）。
- (3)producer：指消息的生产者，负责发布消息到kafka brokero
- (4)consumer：指消息的消费者，从kafka broker拉取数据，并消费这些己发布的消息。
- **（5）partition：partition是物理上的概念，每个Topic包含一个或多个partition,每个 partition都是一个有序的队列。partition中的每条消息都会被分配一个有序的id (offset) **
- (6)consumer Group：消费者组，可以给每个consumer指定消费组，若不指定消费者组，则属于默认的groupo
- (7)Message： 消息，通信的基本单位，每个producer可以向一个topic发布一些消息。
3：kafka拓扑架构
一个典型的Kafka集群包含若干producer,若干broker、若干Consumer Group,以及一个 Zookeeper集群。典型架构如下图所示：
从图中可以看出，典型的消息系统有生产者(producer)，存储系统(broker)和消费者 (consumer)组成，Kafka作为分布式的消息系统支持多个生产者和多个消费者，生产者可以将消息分布到集群中不同节点的不同Partition上，消费者也可以消费集群中多个节点上的多个 Partitiono在写消息时允许多个生产者写到同一个Partition中，但是读消息时一个Partition 只允许被一个消费组中的一个消费者所消费，而一个消费者可以消费多个Partitiono也就是说同一个消费组下消费者对partition是互斥的，而不同消费组之间是共享的
kafka支持消息持久化存储，持久化数据保存在kafka的日志文件中，在生产者生产消息后， kafka不会直接把消息传递给消费者，而是先要在broker中进行存储，为了减少磁盘写入的次数， broker会将消息暂时缓存起来，当消息的个数或尺寸、大小达到一定阀值时，再统一写到磁盘上，这样不但提高了kafka的执行效率，也减少了磁盘10调用次数。
kafka中每条消息写到partition中，是顺序写入磁盘的，这个很重要，因为在机械盘中如果是随机写入的话，效率将是很低的，但是如果是顺序写入，那么效率却是非常高，这种顺序写入磁盘机制是kafka高吞吐率的一个很重要的保证。
4：Topic和partition
Kafka中的topic（主题）是以partition的形式存放的，每一个topic都可以设置它的 partition数量，Partition的数量决定了组成topic的log的数量。推荐partition的数量一定要大于同时运行的consumer的数量。另外，建议partition的数量要小于等于集群broker的数量，这样消息数据就可以均匀的分布在各个broker中
那么，Topic为什么要设置多个partition呢，这是因为kafka是基于文件存储的，通过配置多个partition可以将消息内容分散存储到多个broker上,这样可以避免文件尺寸达到单机磁盘的上限。同时，将一个topic切分成任意多个partitions,可以保证消息存储、消息消费的效率，因为越多的partitions可以容纳更多的consumer,可有效提升Kafka的吞吐率。因此，将 Topic切分成多个partitions的好处是可以将大量的消息分成多批数据同时写到不同节点上，将写请求分担负载到各个集群节点。
在存储结构上，每个partition在物理上对应一个文件夹，该文件夹下存储这个partition 的所有消息和索引文件。partiton命名规则为topic名称+序号，第一个partiton序号从0开始，序号最大值为partitions数量减1。
在每个partition(文件夹）中有多个大小相等的segment(段）数据文件，每个segment的大小是相同的，但是每条消息的大小可能不相同，因此segment < br/ >数据文件中消息数量不一定相segment数据文件有两个部分组成，分别为index file和data file,此两个文件是一一对应，成对出现后".index"和".log"分别表示为segment索引文件和数据文件。
5：Producer生产机制
producer是消息和数据的生产者，它发送消息到broker时，会根据Paritition机制选择将其存储到哪一个Partitiono如果Partition机制设置的合理，所有消息都可以均匀分布到不同的partition里，这样就实现了数据的负载均衡。如果一个Topic对应一个文件，那这个文件所在的机器1/0将会成为这个Topic的性能瓶颈，而有了Partition后，不同的消息可以并行写入不同broker的不同Partition里，极大的提高了吞吐率。
6：Consumer消费机制
Kafka发布消息通常有两种模式： 队列模式（queuing）和发布/订阅模式 (publish-subscribe)o在队列模式下，只有一个消费组，而这个消费组有多个消费者，一条消息只能被这个消费组中的一个消费者所消费；而在发布/订阅模式下，可有多个消费组，每个消费组只有一个消费者，同一条消息可被多个消费组消费。
Kafka中的Producer礻日consumer ·采用的是push、pull的《模式，即producer向broker j些行 push消息，comsumer从bork进行pull消息，push和pull对于消息的生产和消费是异步进行的。pull模式的一个好处是consumer可自主控制消费消息的速率，同时consumer还可以自己控制消费消息的方式是批量的从broker拉取数据还是逐条消费数据。
zookeeper概念介绍
zookeeper是一种分布式协调技术，所谓分布式协调技术主要是用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种共享资源，防止造成资源竞争（脑裂）的后果。脑裂是指在主各切换时,由于切换不彻底或其他原因,导致客户端和Slave误以为出现两个 activemaster,最终使得整个集群处于混乱状态
这里首先介绍下什么是分布式系统，所谓分布式系统就是在不同地域分布的多个服务器，共同组成的一个应用系统来为用户提供服务，在分布式系统中最重要的是进程的调度，这里假设有一个分布在三个地域的服务器组成的一个应用系统，在第一台机器上挂载了一个资源，然后这三个地域分布的应用进程都要竞争这个资源，但我们又不希望多个进程同时进行访问，这个时候就需要一个协调器（锁），来让它们有序的来访问这个资源。这个协调器就是分布式系统中经常提到的那个锁，例如进程1在使用该资源的时候，会先去获得这把锁，进程1获得锁以后会对该资源保持独占，此时其它进程就无法访问该资源，进程1在用完该资源以后会将该锁释放掉，以便让其它进程来获得锁。由此可见，通过这个锁机制，就可以保证分布式系统中多个进程能够有序的访问该共享资源。这里把这个分布式环境下的这个锁叫作分布式锁。这个分布式锁就是分布式协调技术实现的核心内
目前，在分布式协调技术方面做得比较好的有Google的Chubby,还有Apache的zool<eeper, 它们都是分布式锁的实现者。zool<eeper所提供锁服务在分布式领域久经考验，它的可靠性、可用性都是经过理论和实践验证的。
zookeeper是一种为分布式应用所设计的高可用、高性能的开源协调服务，它提供了一项基本服务：分布式锁服务，同时，也提供了数据的维护和管理机制，如：统一命名服务、状态同步服务、集群管理、分布式消息队列、分布式应用配置项的管理等等。
1：zookeeper应用举例
什么是单点故障问题呢？
所谓单点故障，就是在一个主从的分布式系统中，主节点负责任务调度分发，从节点负责任务的处理，而当主节点发生故障时，整个应用系统也就瘫痪了，那么这种故障就称为单点故障。那我们的解决方法就是通过对集群master角色的选取，来解决分布式系统单点故障的问题。
传统的方式是采用一个备用节点，这个备用节点定期向主节点发送ping包，主节点收到ping 包以后向备用节点发送回复Ack信息，当备用节点收到回复的时候就会认为当前主节点运行正常，让它继续提供服务。而当主节点故障时，备用节点就无法收到回复信息了，此时，备用节点就认为主节点宕机，然后接替它成为新的主节点继续提供服务。
这种传统解决单点故障的方法，虽然在一定程度上解决了问题，但是有一个隐患，就是网络问题，可能会存在这样一种情况：主节点并没有出现故障，只是在回复ack响应的时候网络发生了故障，这样备用节点就无法收到回复，那么它就会认为主节点出现了故障，接着，备用节点将接管主节点的服务，并成为新的主节点，此时，分布式系统中就出现了两个主节点（双Master节点）的情况，双Master节点的出现，会导致分布式系统的服务发生混乱。这样的话，整个分布式系统将变得不可用。为了防止出现这种情况，就需要引入zool<eeper来解决这种问题。
2：zookeeper的工作原理是什么？
下面通过三种情形来讲解：
master启动
在分布式系统中引入zookeeper以后，就可以配置多个主节点，这里以配置两个主节点为例，假定它们是主节点A和主节点B,当两个主节点都启动后，它们都会向zool<eeper中注册节点信息。我们假设主节点A锁注册的节点信息是mastereeeol，主节点B注册的节点信息是 mastereeem，注册完以后会进行选举，选举有多种算法，这里以编号最小作为选举算法为例，编号最小的节点将在选举中获胜并获得锁成为主节点，也就是主节点A将会获得锁成为主节点，然后主节点B将被阻塞成为一个备用节点。这样，通过这种方式zookeeper就完成了对两个Master 进程的调度。完成了主、备节点的分配和协作。
master故障
如果主节点A发生了故障，这时候它在zool<eeper所注册的节点信息会被自动删除，而 zool<eeper会自动感知节点的变化，发现主节点A故障后，会再次发出选举，这时候主节点B将在选举中获胜，替代主节点A成为新的主节点，这样就完成了主、被节点的重新选举。
master恢复
如果主节点恢复了，它会再次向zool<eeper注册自身的节点信息，只不过这时候它注册的节点信息将会变成mastereeeæ，而不是原来的信息。zool<eeper会感知节点的变化再次发动选举，这时候主节点B在选举中会再次获胜继续担任主节点，主节点A会担任备用节点。
zookeeper就是通过这样的协调、调度机制如此反复的对集群进行管理和状态同步的。
3：zookeeper集群架构
zookeeper一般是通过集群架构来提供服务的，下图是zookeeper的基本架构图。
Zookeeper Service
zookeeper集群主要角色有server和client' 一server．又分．为leader、f0110 er礻日 observer三个角色，每个角色的含义如下．
- Leader：领导者角色，主要负责投票的发起和决议，以及更新系统状态。
- follower：跟随着角色，用于接收客户端的请求并返回结果给客户端，在选举过程中参与投票。
- observer：观察者角色，用户接收客户端的请求，并将写请求转发给leader,同时同步leader 状态，但是不参与投票。Observer目的是扩展系统，提高伸缩性。
- client：客户端角色，用于向zookeeper发起请求。
4：zookeeper的工作流程
Zookeeper修改数据的流程：Zookeeper集群中每个server在内存中存储了一份数据，在 zookeeper启动时，将从实例中选举一个server作为leader, Leader负责处理数据更新等操作，当且仅当大多数server在内存中成功修改数据，才认为数据修改成功。
zookeeper写的流程为：客户端Client首先和一个server或者Observe通信，发起写请求，然后server将写请求转发给Leader, Leader再将写请求转发给其宀匕Server，妻《宀匕Server．在扌妾收到写请求后写入数据并响应Leader, Leader在接收到大多数写成功回应后，认为数据写成功，最后响应Client,完成一次写操作过程。
群集部署kafka
1：修改主机hosts文件（所有主机都配置）
[root@kafka1 ~]# vim /etc/hosts
192.168.10.101 kafka1
192.168.10.102 kafka2
192.168.10.103 kafka3
2：zookeeper的部署
（1）安装zookeeper（三个节点的配置相同）
[root@kafka1 ~]# systemctl stop firewalld
[root@kafka1 ~]# setenforce 0
[root@kafka1 ~]# yum -y install java
[root@kafka1 ~]# tar zxvf apache-zookeeper-3.6.0-bin.tar.gz
[root@kafka1 ~]# mv apache-zookeeper-3.6.0-bin /etc/zookeeper
（2）创建数据保存目录（三个节点的配置相同）
[root@kafka1 ~]# cd /etc/zookeeper/
[root@kafka1 zookeeper]# mkdir zookeeper-data
（3）修改配置文件（三个节点的配置相同）
[root@kafka1 zookeeper]# cd /etc/zookeeper/conf
[root@kafka1 ~]# mv zoo_sample.cfg zoo.cfg
[root@kafka1 ~]# vim zoo.cfg
dataDir=/etc/zookeeper/zookeeper-data
clientPort=2181
server.1=192.168.10.101:2888:3888
server.2=192.168.10.102:2888:3888
server.3=192.168.10.103:2888:3888
注释：zookeeper只用的端口
2181：对cline端提供服务
3888：选举leader使用
2888：集群内机器通讯使用（Leader监听此端口）
（4）创建节点id文件（按server编号设置这个id，三个机器不同）
节点1：
[root@kafka1 conf]# echo '1' > /etc/zookeeper/zookeeper-data/myid
节点2：
[root@kafka2 conf]# echo '2' > /etc/zookeeper/zookeeper-data/myid
节点3：
[root@kafka3 conf]# echo '3' > /etc/zookeeper/zookeeper-data/myid
（5）三个节点启动zookeeper进程
[root@kafka1 conf]# cd /etc/zookeeper/
[root@kafka1 zookeeper]# ./bin/zkServer.sh start
[root@kafka1 zookeeper]# ./bin/zkServer.sh status
3：kafka的部署
（1）kafka的安装（三个节点的配置相同）
[root@kafka1 ~]# tar zxvf kafka_2.13-2.4.1.tgz
[root@kafka1 ~]# mv kafka_2.13-2.4.1 /etc/kafka
（2）修改配置文件
[root@kafka1 ~]# cd /etc/kafka/
[root@kafka2 kafka]# vim config/server.properties
broker.id=1
##21行 修改，注意其他两个的id分别是2和3
listeners=PLAINTEXT://192.168.10.101:9092
#31行 修改，其他节点改成各自的IP地址
log.dirs=/etc/kafka/kafka-logs
60行 修改
num.partitions=1
##65行 分片数量，不能超过节点数
zookeeper.connect=192.168.10.101:2181,192.168.10.102:2181,192.168.10.103:218
##123行，填写集群中各节点的地址和端口
注释：
9092是kafka的监听端口
（3）创建日志目录（三个节点的配置相同）
[root@kafka1 kafka]# mkdir /etc/kafka/kafka-logs
（3）在所有kafka节点上执行开启命令，生成kafka群集（三个节点的配置相同）
[root@kafka1 kafka]# ./bin/kafka-server-start.sh config/server.properties &
如果启动不了，可以将/etc/kafka/kafka-logs中的数据清除再试试
3：测试
创建topic（任意一个节点）
bin/kafka-topics.sh --create --zookeeper kafka1:2181 --replication-factor 1 --partitions 1 --topic test
列出topic（任意一个节点）
bin/kafka-topics.sh --list --zookeeper kafka1:2181
bin/kafka-topics.sh --list --zookeeper kafka2:2181
bin/kafka-topics.sh --list --zookeeper kafka3:2181
生产消息
bin/kafka-console-producer.sh --broker-list kafka1:9092 -topic test
消费消息
bin/kafka-console-consumer.sh --bootstrap-server kafka1:9092 --topic test
删除topic
bin/kafka-topics.sh --delete --zookeeper kafka1:2181 --topic test
版权归原作者 zandsw_ 所有， 如有侵权，请联系我们删除。