kafka日志收集平台（原理）

项目描述：

搭建nginx web静态网页，收集用户访问日志，清洗数据调用淘宝接口，得出IP所属的isp、province和bandwidth并入库。

项目环境：

centos7.4机器共3台,nginx,filebeat,kafka2.12,zookeeper,python3.6、mysql

项目原理：

第一部分：user访问nginx web服务

• 测试环境时，可以直接使用ip访问nginx
  web服务，也可以绑定域名访问。但由于我有三台机器，对应着三个ip，为了提高服务的体验，我使用了DNS做负载均衡。

• 但是DNS具有一定的局限性，例如www.abc.com可以解析成多个ip地址，一般来说会用轮询的方式去解析成各个ip，但是如果其中一个服务器挂了，DNS不会立马将这个ip地址去掉，还是会解析成挂掉的ip，可能会造成访问失败。虽然客户端有重试，但是还是会影响用户体验

• 在nginx web前面加入nginx反向代理，安全性也会高一些，负载均衡控制起来容易很多，nginx反向代理相当于一个门卫。引入keepalive通过vrrp（虚拟路由冗余协议）解决高可用的问题，有master核backup，master挂了vip立马漂到backup那里去，这样就能解决高可用。但是如果其中一个一直没有出问题，就会闲置另一个，所以就弄双vip互为主备，提高资源的利用率，需要注意的是两个ip都是虚拟ip。

• nginx web服务只能做静态页面的展示，这里使用了三台虚拟机做web服务，在三台机器上面分别部署filebeat收集本机器的日志再吐到kafka

第二部分：kafka和zookeeper

2.1、kafka是什么？为什么要使用kafka？

刚开始做项目时我也感到很疑惑，既然在每一台机器上面部署了filebeat为什么不直接把filebeat收集来的日志吐到数据库里去呢？后来我意识到，收集日志很大一个作用用于故障定位，我用了三台机器来部署filebeat，如果在公司多的会有成千上万台机器，如果发生故障日志确实是收集到了，但是不方便做故障的定位；其次kafka日志集中管理，后续如果又有新的机器需要获取数据，直接从kafka里面获取就好了，不需要再在每台机器上面重新部署加入新机器，能够尽可能的减少日志处理对nginx的影响，总的来说kafka起到了一个消息缓冲的作用。

2.1.1、 kafka是什么？

kafka是一个开源流处理平台，是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据，kafka是消息中间介的一种；通常用于：日志收集、业务解耦、流量削峰；消息中间件有两种通信模式：点对点、发布订阅，kafka属于发布订阅模式；

2.1.2、kafka中有什么？

• broker：kafka节点，每台机器就是一个broker；

• topic：主题，消息的分类，比如nginx，mysql日志给不同的主题，就是不同的类型

• replica：副本，是kafka里的高可用 – 就是完整的分区备份

• partition：分区，设置多个提高吞吐量，提高并发（但是对顺序很有要求的话就不要设置多个partition了，就设置一个）多个partition会造成消息顺序很混乱。partition是针对于topic来说的

2.1.3、kafka如何保证高可用

使用多个broker+多个partition+多个replica；但是副本多了就意味着生产者要发很多份消息了，会产生很高的带宽，并且会造成资源浪费。 所以可以将replica的数量设置得和broker的数量一致，这样就可以坏掉n-1台机器了。

2.1.4、kafka如何保证数据的一致性

• 设置ack–producer可以通过request.required.acks设置
• ack设置为0：生产者不需要接收响应，一个劲的死命发就好了
• ack设置为1：这是默认设置，当leader收到之后就给生产者发送响应
• ack设置为n：当n个副本收到之后才给生产者发送响应
• ack设置为-1：等待ISR列表里的每一个副本都接收到时，才给生产者发送响应

2.1.5、fakfa中的ISR

ISR – in-sync-replica 集合列表 – 需要同步的follower集合
比如说5个副本，那么就有1个leader和4个follower，ISR就是5；那么有一条消息来了，leader怎么知道要同步哪些副本呢？根据ISR来—如果一个follower挂了，那就从这个列表里删除，如果一个follower卡住或者同步过慢，也会从ISR里删除；如果有一个机器宕机，后续启动之后想要重新加入ISR，必须得同步到High Water值。

2.1.6、kafka存储大量的数据不会爆吗？

肯定是不会的，因为kafka有自己清理数据的方式，kafka可以按照两个维度清理数据
（1）按大小：当数据达到规定大小时即开始清理数据
（2）按时间：规定保存几天，过期就删除
其中任何一个条件满足都可以触发日志清理，kafka将数据存储于<topic_name>-<分区号>这个目录下，每个partition的数据都是由很多个segment存储，每一个segment由一个index和log文件组成，分出多个segment便于做数据清理。

2.17 使用kafka，kafka的优势是什么？

• 多生产者与多消费者：
  kafka可以支持多个生产者，不论客户端使用单个主题还是多个主题，并且kafka可以支持多个消费者从一个单独的消息流上读取数据，消费者之间互不影响
• 基于磁盘的数据存储（持久化）：
  由于消息被提交到磁盘根据设定地规则进行保存，kafka可以支持消费者非实时地读取消息。当消费者发生异常意外掉线时，由于有持久化地数据保证可以实现联机后从上次中断的地方继续处理消息。
• 伸缩性：
  用户在开发阶段可以先用单个broker，再扩展到包含多个broker的小型开发集群，随着数量不断增长，部署到生产环境的集群可能包含上百个broker
• 高性能：
  kafka可以轻松处理巨大的信息流，再处理大量数据的同时还能保证亚秒级的消息延迟

2.18 kafka和RabbitMQ区别

（1）使用的开发语言不通，使用场景也存在一定差异
RabbitMQ是由erlanng语言开发的，用在实时的对可靠性要求比较高的消息传递上，而kafka是采用scala语言开发，主要用于处理活跃的流式数据、大数据量的处理上
（2）结构不同
RabbitMQ采用AMQP（高级消息队列协议）是一个进程间传递异步消息的网络协议，RabbitMQ主要的组成部分是Exchange、Binding、queue；kafka采用mq结构，broker有partition分区的概念；
（3）broker与consume交互方式不同
RabbitMQ采用push的方式，kafka采用pull的方式
（4）负载均衡方面
RabbitMQ的负载均衡需要单独的loadbalancer进行支持，kafka则采用zookeeper对集群中的broker、consumer进行管理
（5）使用场景
RabbitMQ支持对消息的可靠的传递，支持事务但不支持批量操作，基于存储可靠性的要求，可以采用内存或者硬盘进行存储，在金融场景中经常使用。kafka具有高吞吐量，内部采用消息的批量处理，数据的存储和获取是本地磁盘顺序批量操作，消息处理的效率很高。
（6）RabbitMQ的局限性
RabbitMQ集群中的任何一个节点都拥有集群上所有队列的元信息，所以连接到集群中的任何一个节点都可以，主要区别在于有的consumer连在master queue所在节点，有的连在非master queue节点上。因为mirror queue要和master queue保持一致，故需要同步机制，正因为一致性的限制，导致所有的读写操作都必须都操作在master queue上，然后由master节点同步操作到mirror queue所在的节点。即使consumer连接到了非master queue节点，该consumer的操作也会被路由到master queue所在的节点上，这样才能进行消费。所以由于master queue单节点，导致性能瓶颈，吞吐量受限。虽然为了提高性能，内部使用了Erlang这个语言实现，但是终究摆脱不了架构设计上的致命缺陷。
参考博客：https://blog.csdn.net/truelove12358/article/details/106077305

2.2、zookeeper是什么？

zookeeper：分布式应用程序协调管理服务，用于配置管理、域名管理、分布式数据存储、集群管理；在kafka3.0版本已经脱离zookeeper，kafka自己实现zookeeper功能。

2.2.1、zookeeper中数据同步问题

zookeeper中数据的同步只需要过半节点同步完成，就表示数据已经commit。需要注意的是zookeeper不是强一致性，它属于最终一致性，由于每个节点的数据量默认不超过1M，所以最终同步性不影响使用。

2.2.2、zookeeper中的leader和follower

在kafka中生产者和消费者只和leader打交道，但是生产者和任何一台broker连接都可以，因为broker会返回当前请求副本leader的信息，最后生产者再跟leader打交道。而在zookeeper中也差不多，客户端连接任意一台zk都可以进行操作，但是数据新增修改等事务的操作必须在leader上运行，客户端如果连接到follower上进行事务操作，follower会返回给leader的ip，最终客户端还是会在leader上操作。
zookeeper中的follower用于查询和选举

2.2.3、zookeeper中的选举机制

zookeeper中选举采用一致性算法zab，遵循少数服从多数的原则，随机投票票数过半的当选leader，如果出现平票的情况则重新投票，所以通常将节点数设置为奇数。

2.2.4、zookeeper的脑裂问题

zookeeper集群中，节点间的网络通信不良时，容易出现脑裂的现象。集群中的节点监听不到leader节点的心跳，就会认为leader节点出现异常，此时一个大集群将分成小集群，在这些小集群会各自选举出自己的leader，一旦网络通信恢复，原有的集群就会出现多个leader造成脑裂。
所以可以通过设置节点的数量，比如节点数量设置为5，当分裂成小集群时候分为2、3，节点数为2的那个集群很再难选出leader。

2.2.5、zookeeper在kafka中的作用

• 保存kafka的元信息：topic、partition、副本信息

• 选举kafka controller：通过抢占的方式来选出controller，选举出的kafka
  controller管理kafka副本的leader和follower

  2.2.6、zookeeper与kafka选举机制差异

  zookeeper采用一致性算法，遵循少数服从多数的原则；kafka的选举则是在ISR里面使用顺延的方式来进行选举。

  2.3、kafka中数据流向

  在这里打一个小小的比方，暂且将Kafka比喻成一个书店，消费者相当于进去书店看书的人（在这里假设这个书店的书只能看不能买），而生产者就是向书店提供书本的出版社。书店里有很多不同专题的书，比如少儿类、科研类等等，这就相当于kafka里的topic，假如有一个门类例如小说类，由于这个类型非常热门，所以来看书的人非常多，多到一个小分区已经坐不下了，于是书店决定为小说类多开几个分区，这就相当于kafka的partition。每个分区都要记录下哪些出版社提供了哪些书籍，为了防止这个信息丢失，于是将A类书籍出版设提供书籍的信息备份一份在B类书籍的分区里，A类中自己的信息和B类中备份的信息就相当于kafka中的两个replica。

  第三部分：kafka与消费者

消费者在消费数据时怎么保证数据一致性：

消费者消费时为保证数据的一致性引入了High Water Mark机制。木桶效应（短板效应），只能消费ISR列表里偏移量最少的副本的消息和数量。

消费者怎么知道自己消费到哪儿了？

offset记录消费者消费偏移量，消费者消费时会记录下自己的消费偏移量，消费便宜量可以保存在本地，也可以提交到kafka的__consumer_offset主题里面保存。