前言
写这篇文章的起因是由于之前的一篇关于Kafka异常消费，当时为了解决问题不得不使用临时的方案。
总结起来归根结底还是对Kafka不熟悉导致的，加上平时工作的需要，之后就花些时间看了Kafka相关的资料。
何时使用MQ
谈到Kafka就不得不提到MQ，是属于消息队列的一种。作为一种基础中间件在互联网项目中有着大量的使用。
一种技术的产生自然是为了解决某种需求，通常来说是以下场景：
需要跨进程通信：B系统需要A系统的输出作为输入参数。
当A系统的输出能力远远大于B系统的处理能力。
针对于第一种情况有两种方案:
使用RPC远程调用,A直接调用B。
使用MQ,A发布消息到MQ,B订阅该消息。
当我们的需求是:A调用B实时响应，并且实时关心响应结果则使用RPC，这种情况就得使用同步调用。
反之当我们并不关心调用之后的执行结果，并且有可能被调用方的执行非常耗时，这种情况就非常适合用MQ来达到异步调用目的。
比如常见的登录场景就只能用同步调用的方式，因为这个过程需要实时的响应结果，总不能在用户点了登录之后排除网络原因之外再额外的等几秒吧。
但类似于用户登录需要奖励积分的情况则使用MQ会更好，因为登录并不关系积分的情况，只需要发个消息到MQ,处理积分的服务订阅处理即可，这样还可以解决积分系统故障带来的雪崩效应。
MQ还有一个基础功能则是限流削峰，这对于大流量的场景如果将请求直接调用到B系统则非常有可能使B系统出现不可用的情况。这种场景就非常适合将请求放入MQ，不但可以利用MQ削峰还尽可能的保证系统的高可用。
Kafka简介
本次重点讨论下Kafka。
简单来说Kafka是一个支持水平扩展，高吞吐率的分布式消息系统。
Kafka的常用知识:
Topic:生产者和消费者的交互都是围绕着一个Topic进行的，通常来说是由业务来进行区分，由生产消费者协商之后进行创建。
Partition(分区):是Topic下的组成，通常一个Topic下有一个或多个分区，消息生产之后会按照一定的算法负载到每个分区，所以分区也是Kafka性能的关键。当发现性能不高时便可考虑新增分区。
备注：
其实就是初始化出三个消费者实例，用于三个线程消费。其中加入了一些统计，最后也是消费120009条数据结果如下。
由于是并行运行，可见消费120009条数据可以提高2秒左右，当数据以更高的数量级提升后效果会更加明显。
但这也有一些弊端:
灵活度不高，当分区数量变更之后不能自适应调整。
消费逻辑和处理逻辑在同一个线程，如果处理逻辑较为复杂会影响效率，耦合也较高。当然这个处理逻辑可以再通过一个内部队列发出去由另外的程序来处理也是可以的。
总结
Kafka的知识点还是较多，Kafka的使用也远不这些。之后会继续分享一些关于Kafka监控等相关内容。
项目地址：https://github.com/crossoverJie/SSM.git
原文：https://blog.csdn.net/zty1317313805/article/details/80269609