Kafka集群实战与原理分析线上问题优化

一、为什么使用消息队列?

1.1 Kafka知识点思维导图

以电商为业务背景

消息队列解决的具体问题是什么？ – 通信问题。

1.2 使用同步的通讯方式来解决多个服务之间的通讯

同步的通讯方式会存在性能和稳定性的问题。

1.3 使用异步通讯方式

在业务的上游与下游间加入 通讯模块 （消息队列 存储消息的队列）

最终一致性

针对同步的通讯方式来说，异步的方式，可以让上游快速成功，极大提高了系统的吞吐量。而且在分布式系统中，通过下游多个服务的分布式事务保障，也能保证业务执行之后的最终一致性。

二、消息队列的流派

2.1 什么是MQ ？

Message Queue（MQ），消息队列中间件。

很多人都说：

MQ 通过将消息的发送和接收分离来实现应用程序的异步和解偶，这个给人的直觉是——MQ 是异步的，用来解耦的，但是这个只是 MQ 的效果而不是目的。

MQ 真正的目的是为了通讯，屏蔽底层复杂的通讯协议，定义了一套应用层的、更加简单的通讯协议。

一个分布式系统中两个模块之间通讯要么是 HTTP，要么是自己开发的 TCP，但是这两种协议其实都是原始的协议。

HTTP 协议很难实现两端通讯——模块 A 可以调用 B，B 也可以主动调用 A，如果要做到这个两端都要背上 WebServer，而且还不支持长连接（HTTP 2.0 的库根本找不到）。 TCP 就更加原始了，粘包、心跳、私有的协议，想一想头皮就发麻。

MQ 所要做的就是在这些协议之上构建一个简单的“协议”——生产者/消费者模型。

MQ 带给我的“协议”不是具体的通讯协议，而是更高层次通讯模型。 它定义了两个对象——发送数据的叫生产者，接收数据的叫消费者； 提供一个 SDK 让我们可以定义自己的生产者和消费者实现消息通讯而无视底层通讯协议。

2.2 中间件选型

目前消息队列的中间件选型有很多种：

rabbit MQ：内部可玩性（功能性）是非常强的

rocket MQ :阿里内部大神根据Kafka的内部执行原理，手写的一个消息中间件。性能比肩kafka，除此之外，在功能上封装了更多的功能。（消息的逆序） kafka：全球消息处理性能最快的一款MQ（纯粹）

zeroMQ

这些消息队列中间件有什么区别？

我们把消息队列分为两种

MQ，分为有Broker的MQ，和没有Broker的MQ。 Broker，代理，经纪人的意思。

2.2.1 有broker

有broker的MQ 这个流派通常有一台服务器作为Broker，所有的消息都通过它中转。生产者把消息发送给它就结束自己的任务了，Broker则把消息主动推送给消费者（或者消费者主动轮询）。

重topic：Kafka 、RocketMQ 、 ActiveMQ 整个broker，依据topic来进行消息的中转，在重topic的消息队列里必然需要topic的存在

轻topic：RabbitMQ topic只是其一种中转模式。

2.2.2 无broker

在生产者和消费者之间没有使用broker，例如zeroMQ，直接使用socket进行通信

无broker的MQ代表是ZeroMQ，该作者非常睿智，他非常敏锐的意识到–MQ是更高级的Socket

它是解决通信问题的。所以ZeroMQ被设计成了一个“库”而不是一个中间件，这种实现也可以达到–没有Broker的目的。

三、Kafka的基本知识

Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统.

它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：

比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。

3.1 Kafka的特性:

高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。

可扩展性：kafka集群支持热扩展

持久性、可靠性：消息被持久化到本地磁