kafka在设计初衷就是为了解决互联网公司的超级大量级数据的实时传输。为了实现这个目标，kafka在设计之初就需要考虑以下四个方面：(1)吞吐量/延迟(2)消息持久化(3)负载均衡和故障转移(4)伸缩性1、吞吐量/延迟
作为一个功能完备的分布式系统，kafka如果只提供了最基本的消息引擎功能肯定不足以帮助它脱颖而出。一套完整的消息引擎解决方案中必然要提供负载均衡（loadbalancing）和故障转移（fail-over）功能。何为负载均衡？顾名思义就是让系统的负载根据一定的规则均衡地分配在所有参数工作的服务器上，从而最大限度的提升整体的运行效率。kafka实现负载均衡实际上是通过智能化的分区领导者选举（partitionleaderelection）来实现的。除了负载均衡，完备的分布式系统还支持故障转移，所谓故障转移，是指当服务器意外终止时，整个集群可以快速的检测到该失效（failure），并立即将该服务器上应用或服务自动转移到其他服务器上。故障转移通常是“心跳”和“会话“的机制来实现的。kafka服务器支持故障转移的方式就是使用会话机制。每台kafka服务器启动后会以会话的形式把自己注册到zookeeper服务器上。一旦该服务运转出现问题，与zookeeper的会话变不能维持从而超时失效，此时kafka集群会选举出另外一台服务器来完全代替这台服务器继续提供服务。4、伸缩性
所谓伸缩性，英文名是scalability。伸缩性表示想分布式系统中增加额外的计算资源（比如CPU，内存，存储或带宽）时吞吐量提升的能力。阻碍线性扩容的一个很常见的因素就是状态的保存。我们知道，不论是哪类分布式系统，集群的每台服务器一定会维护很多内部状态。如果由服务器自己来保存这些状态信息，则必须处理一致性的问题。相反，如果服务器是无状态的，状态的保存和管理交与专门的协调服务来做（比如zookeeper）。那么整个集群的服务武器之间就无需繁重的状态共享，这极大的降低了维护复杂度。倘若要扩容集群节点，只需要简单的启动新的节点集群和进行自动负载均衡就可以了。Kafka正式采用了这样的思想：每台kafka服务器上的状态统一交友zookeeper保管。扩展kafka集群也只需要一步：启动新的kafka服务器即可。当然这里需要言明的是，在kafka服务器上并不是所有的状态信息都不保存，它只保存了很轻量级的内部状态（比如从kakka0.10.x版本之后，它将每个topic的消费者的偏移量自己维护了，把这些偏移量存放到了一个叫做“__consumer_offsets”的的topic进行维护）。二、Kafka简介
1、什么是JMS
2、JMS的两种工作模式
Kafka的工作模式可以把JMS的两种模式结合在一起，我们称之为消费者组模式。4、什么是Kafka
6、Kafka核心API
7、kafak特点
第一：可以处理大量数据，TB级别；第二：高吞吐量，支持每秒钟百万消息，传输速度可达到300MB/s;第三：分布式，支持在多个Server之间进行消息分区；第四：多客户端支持，和多种语言进行协同；第五：它是一个集群，扩容起来也相当方便；三、kafka消息队列
1、kafka消息队列内部实现原理
点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除,pull）点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此。发布/订阅模式（一对多，数据生产后，推送给所有订阅者,push）发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即使当前订阅者不可用，处于离线状态。2、为什么需要消息队列
1、topic和partition
2、offset
上面说过，topicpartition下的每条消息都被分配了一个位移值。实际上，Kafka消费者端也有位移（offset）的概念，但一定要注意这两个offset属于不同的概念。显然，每条消息在某个partition的位移是固定的，但消费该partition的消费者的位移是会随着消费进度不断迁移，但终究不可能超过该分区最新一条消息的位移。综合之前说的topic，partition和offset，我们可以断言Kafka中的一条消息其实就是一个
既然我们已知partition是有序的消息日志，那么一定不能只保存这一份日志，否则一旦保存在partition的Kafka服务器挂掉了，其上保存的消息也就都丢失了。分布式系统必然要实现高可靠性，而目前实现的主要途径还是依靠冗余机制。换句话说，就是备份多份日志。这些备份日志在Kafka中被称为副本（replica），它们存在的唯一目的就是防止数据丢失，这一点一定要记住！4、leader和follower
副本(replia)分为两类：领导者副本（leaderreplia）和追随者副本（followerreplia）。followerreplica是不能提供服务给客户端的，也就是说不负责响应客户端发来的消息写入和消息消费请求。它只是被动地向领导者副本（leaderreplia）获取数据，而一旦leaderreplica所在的broker宕机，Kafka会从剩余的replica中选举出新的leader继续提供服务。Kafka保证同一个partition的多个replica一定不会分配在同一台broker上。毕竟如果同一个broker上有同一个partition的多个replica，那么将无法实现备份冗余的效果。5、producer
生产者将数据发布到它们指定的topics。生产者负责选择将记录分配到topic中的哪个分区。可以以round-robin方式分配以简单地负载均衡，或可以按可以按某个分区函数（基于记录的键来计算）来分配。6、consumer
7、broker
Kafka是一个分布式消息队列。Kafka对消息保存是根据Topic进行归类，发送消息者称为Producer，消息接受者称为Consumer，此外kafka集群有多个kafka实例组成，每个实例(server)成为broker。无论是kafka集群，还是producer和consumer都依赖于zookeeper集群保存一些meta信息，来保证系统可用性。因此Zookeeper在生产环境中最少建议部署3台，如果集群较大（100个节点以上）推荐配置5台。8、ISR
Kafka以消息引擎闻名，因此它特别适合处理生产环境中的那些流式数据。以下就是Kafka在实际应用中一些典型的使用场景。1、消息传输
Kafka非常适合替代传统的消息总线（messagebus）或消息代理（messagebroker）。传统的这类系统擅长于解耦生产者和消费者以及批量处理消息，而这些特点Kafka都具备。除此之外，Kafka还具有更好的吞吐量特性，其内置的分区机制和副本机制既实现了高性能的消息传输，同时还达到了高性能的高容错性。一次Kafka特别适合用于实现一个超大量级消息处理应用。2、网站行为日志追踪
Kafka最早就是用于重建用户行为数据追踪系统的。很多网站上的用户操作都会以消息的形式发送到Kafka的某个对应的topic上。这些点击流蕴含了巨大的商业价值，事实上，目前就有很多创业公司使用机器学习或其他实时处理框架来帮助收集并分析用户的点击流数据。鉴于这种点击流数据量是很大的，Kafka超强的吞吐量特性此时就有了用武之地。3、审计数据收集
很多企业和组织都需要对关键的操作和运维进行监控和审计。这就需要从各个方面运维应用程序处实时汇总操作步骤信息进行集中式管理。在这种使用场景下，你会发现Kafka是非常适合的解决方案，它可以便捷的对多路消息进行实时收集，同时由于其持久化的特性，是的后续离线审计称为可能。4、日志收集
这可能是Kafka最常见的使用方式了（日志收集汇总解决方案），每个企业都会产生大量的服务日志，这些日志分散在不同的机器上。我们可以使用Kafka对他们进行全量收集，并集中往下游的分布式存储中（比如HDFS等）。比起其他主流的日志抽取框架（比如ApacheFlume），Kafka有更好的性能，而且提供了完备的可靠性解决方案，同时还保持了低延迟的特点。5、EventSourcing
EventSourcing实际上是领域驱动设计（Domain-DrivenDesign，简称DDD）的名次，它使用事件序列来表示状态变更，这种思想和Kafka的设计特性不谋而合。还记得吧，Kafka也是用不可变更的消息序列来抽象化表示业务信息的，因此Kafka特别适合作为这种应用的后端存储。6、流式处理
很多用户接触到Kafka都是因为它的消息存储引擎。自0.10.0.0版本开始，Kafka社区推出了一个全新的流式组件KafkaStreams。这标志着Kafka正式进入流式处理框架俱乐部。相比老牌流式处理框架ApacheStorm，ApacheSamza，或是最近风头正劲的SparkStreaming，抑或是ApacheFlink，KafkaStreams的竞争力如何？让我们拭目以待吧！六、集群环境规划
1、操作系统的选型
Kafka对于内存对使用可称作其设计亮点之一。虽然在前面我们强调了Kafka大量依靠和磁盘来保存消息，但其实它还会对消息进行缓存，而这个消息换粗你得地方就是内存，具体来说是操作系统对页缓存（pagecache）。Kafka虽然会持久化每条消息，但其实这个工作都是底层对文件系统来完成。Kafka仅仅将消息写入pagecache而已，之后将消息“flush”到磁盘对任务完全交由操作系统来完成。一般情况下，broker所需的堆内存都不会超过6GB。所以对于一台16GB内存的机器而言，文件系统pagecache的大小甚至可以达到10～14GB！总之对于内存规划的建议如下：第一：尽量分配更多的内存给操作系统的pagecache；第二：不要为broker设置过大的堆内存，最好不超过6GB；第三：page大小至少要大于一个日志段的大小；5、CPU规划
比起磁盘和内存，CPU于kafka而言并没有那么重要，严格来说，kafka不属于计算密集型（CPU-bound）的系统，因此对于CPU需要记住一点就可以了：追求多核而非高时钟频率。咱们对CPU资源规划如下：第一：使用多核系统，CPU核数最好大于8；第二：如果使用Kafka0.10.0.0之前的版本或clients端消息版本不一致（若无显式配置，这种情况多半由clients和broker版本不一致造成），则考虑多配置一些资源以防止消息解压操作消耗过多CPU）。6、带宽规划
第一：尽量使用高速网络；第二：根据自身网络条件和带宽来评估Kafka集群机器数量；第三：避免使用跨机房网络；7、关于JVM
需要使用1.8以上的JDK。推荐使用G1GC，其次可选择ParNew+CMS的组合（但是做的相应的调整也比较多）。设置充足的堆大小。以下是一个示范例子：-Xmx6g-Xms6g-XX:MetaspaceSize=96m-XX:+UseG1GC-XX:MaxGCPauseMillis=20-XX:InitiatingHeapOccupancyPercent=35-XX:G1HeapRegionSize=16M-XX:MinMetaspaceFreeRatio=50-XX:MaxMetaspaceFreeRatio=80