kafka的集群与可靠性 - 有点懒惰的大青年

kafka做集群的目标

高并发

高可用

动态扩容

./kafka-topics.sh --bootstrap-server localhost:9092 --create --topic laoli --partitions 2 --replication-factor 2

topic：创建名为laoli的主题

partitions：该主题下2个分区

replication-factor：复制因子，因为有集群，这里写2。如果写1的话，就不存在复制副本了。也不能写3，因为只有两台服务器集群。

例如，一个主题下有两个分区，做两个复制因子，在broker1有，在broker2也有。分区0的首领是broker1，分区1的首领有可能就是broker2了。

查看topic详细信息：

以topic为laoli为例，Leader：后面的数字表示broker的id。数据的复制都是从leader首领副本，复制到follower跟随副本的。

创建生产者，topic名为laoli，发送消息：

./kafka-console-producer.sh --broker-list 192.168.40.115:9092 --topic laoli

创建消费者，topic名为laoli，消费消息：

./kafka-console-consumer.sh --bootstrap-server 192.168.40.115:9092 --topic laoli --from-beginning --consumer.config ../config/consumer.properties

kafka处理请求的内部机制：

作为生产也好，作为消费也好，所有的请求，发送或者消费，都应该放在首领所在的broker，比如往分区0发，要发往首领所在的broker，任意一台broker启动的时候，会在客户端获取一个元数据，(元数据：创建的主题，哪些是首领，分区，以及分区里面哪个是首领，类似于查看topic详细信息的这么一个元数据)，并且元数据在任意一台broker上都有。所以最终进行生产或者消费的时候，都是客户端根据元数据缓存，发送到指定的首领所在的broker节点上来。非首领的分区上的数据来自于对应首领分区上的数据的复制。

发送确认的ACKS机制，三种模式：

1.acks=0，只要发出去了，不管确认(认为消息已经写入kafka)

2.acks=1，写入分区的副本数，只要写入1个就返回确认了。（先写到leader，然后再由leader同步到follower）

3.acks=all或-1，简单的理解全部（min.insync.replicas参数）都收到了，就返回确认。

总结：

1.追求性能，min.insync.replicas=1，leader同步成功返回成功；(leader宕机了，必然会丢数据)

2.min.insync.replicas = 3, 3个副本，3个副本的服务器，任意一台在发送消息时宕机了，返回发送不成功。

消费者来说，比较重要的参数：

1.group.id，消息的重复消费

2.auto.offset.reset，自动偏移量的设置，从哪里开始找，可以设置为earliest，latest，none，anything else。拉取消息的时候如果这个偏移量在broker上不存在，或者是第一次获取消息，那从哪里offset开始找消息呢？如果配置为latest，之前的消息就收不到了。如果配置的是earliest，必然有可能之前的消息已经消费过了，又把之前最老的消息从头再消费一次。

3.enable.auto.commit，自动提交，默认情况下自动提交的。也就是说只要消息通过poll方法拿到，拿到之后就会自动提交。但是有可能在这个过程中会发生错误，所以经常在确保消息不会发生丢失、重复时，尽量可以取消自动提交，交给程序进行手动提交，consumer.commitAsync()-异步，不会阻塞线程；consumer.commitSync()-同步，会阻塞线程，并且会重试。

4.auto.commit.interval.ms，和上面自动提交的参数相关，如果选择了默认自动提交，那这个参数表示多久提交一次，3.0的kafka版本默认是5秒提交一次。当然如果你这边消费的很快，可以设置快点，比如1ms提交一次，当然如果你提交的越频繁的话肯定会有额外的开销。

kafka的存储机制

基本的存储单位：分区，同一个broker多个磁盘再划分，粒度就是分区。

在server.properties中有配置：

log.dirs=/tmp/kafka-logs 存储路径