为什么需要使用kafka
从本质上来讲，是因为互联网发展太快，使用单体架构无疑会是的体量巨大。而微服务架构可以很好的解决这个问题，但是服务与服务之间会还是出现耦合、访问控制等问题。消息队列可以很好的满足这些需要。它常用来实现：异步处理、服务解耦、流量控制
异步处理
随着业务的不断增加，通常会在原有的服务上添加上新服务，这样会出现请求链路越来越长，链路latency也就逐步增加。例如：最开始的电商项目，可能就是简简单单的扣库存、下单。慢慢地又加上了积分服务、短信服务等。链路增长不可避免的latency增加。
相对于扣库存、下单，积分和短信没必要恢复的那么及时。所以只需要在下单结束的时候结束那个流程，把消息传给消息队列中就可以直接返回响应了。而且短信服务和积分服务可以并行的消费这条消息。这样响应的速度更快，用户体验更好；服务异步执行，系统整体latency（相对使用同步机制而言）也下降了。
异步处理
服务解耦
上面说的新加了短信服务和积分服务，现在又需要添加数据分析服务、以后可能又加一个策略服务等。可以发现订单的后续链路一直在增加，为了适配这些功能，就需要不断的修改订单服务，下游任何一个服务的接口改变都可能会影响到订单服务。
这个时候可以采用消息队列来解耦，订单服务只需要把消息塞到消息队列里面，下游服务谁要这个消息谁就订阅响应的topic。这样订单服务就不用被拿捏住了！！
服务解耦
流量治理
后端服务相对而言是比较脆弱的，因为业务较重，处理时间长。如果碰到高QPS情况，很容易顶不住。比如说题库数据写入到ES索引中，数据都是千万级别的。这个时候使用中间件来做一层缓冲，消息队列是个很不错的选择。
变更的消息先存放到消息队列中，后端服务尽自己最大的努力去消费队列中消费数据。
同时，对于一些不需要及时地响应处理，且业务处理逻辑复杂、流程长，那么数据放到消息队列中，消费者按照自己的消费节奏走，也是很不错的选择。
上述分别对应着生产者生产过快和消费者消费过慢两种情况，使用消息队列都能很好的起到缓冲作用。
流量治理
总结一下
kafka特点：
解耦合。消息队列提供了借口，生产者和消费者能够独立的完成读操作和写操作。
高吞吐率。即使是在廉价的商用机器上也能做到单机支持每秒K条消息的传输
信息传输快。以时间复杂度为O（1）的方式提供持久化能力，即使对TB级以上数据也能保证常数时间的访问性能
可提供持久化。消息存储在中间件上，数据持久化，直到全部被处理完，通过这一方式规避了数据丢失的风险。
kafka适用场景
根据上述功能和特点，kafka主要有以下使用场景：
信息系统Messaging。在这个领域中，kafka常常被拿来与传统的消息中间件进行对比，如RabbitMQ。
网站活动追踪WebsiteActivityTracking
监控Metrics
日志收集LogAggregation
流处理StreamProcessing
事件溯源EventSourcing
提交日志CommitLog
具体可见：使用场景
kafka组件
kafka架构图
Producer：消息生产者，就是向Kafka发送数据；
Consumer：消息消费者，从Kafkabroker取消息的客户端；
ConsumerGroup（CG）：消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
Broker：经纪人一台Kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。
Topic：话题，可以理解为一个队列，生产者和消费者面向的都是一个topic；
Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列；如果一个topic中的partition有5个，那么topic的并发度为5.
Replica：副本（Replication），为保证集群中的某个节点发生故障时，该节点上的partition数据不丢失，且Kafka仍然能够继续工作，Kafka提供了副本机制，一个topic的每个分区都有若干个副本，一个leader和若干个follower。
Leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是leader。
Follower：每个分区多个副本中的“从”，实时从leader中同步数据，保持和leader数据的同步。leader发生故障时，某个Follower会成为新的leader。
Offset
：每个Consumer消费的信息都会有自己的序号，我们称作当前队列的offset。即
消费点位标识消费到的位置
。每个消费组都会维护订阅的Topic下每个队列的offset
基本配置
参见