通过实现Feign的RequestInterceptor接口，重写里面的apply方法，为RequestTemplate添加请求头信息。

Kafka的Topic是由多个Partition组成，理论上一个Topic的分区越多，集群所能达到的吞吐量就越大。分区不是越多越好1、客户端/服务端所需要的内存就越多由于Kafka支持批量消息发送，它会为每个分区缓存消息，当消息的大小达到batch.size后，就会将消息打包发送，如果分区数量很大，就会占用producer服务器一部分内存，consumer端由于分区数量很多，就会创建很多线程去消费

例如Zookeeper集群都是奇数，为什么需要这样的要求呢？主要有以下两种原因1、节省资源Zookeeper集群的master节点选举为过半机制，例如集群节点总数为7，那么需要4个节点集群才能选举出来master节点，最多允许3个节点不可用；如果集群节点总数为8，那么需要5个节点才能选举出来master节点，最多允许3个节点不可用所以7个节点和8个节点的容错能力是相同，所以奇数个更加节省资源2、防

1、顺序读写kafka的消息是不断追加到文件中的，这个特性使kafka可以充分利用磁盘的顺序读写性能，顺序读写不需要硬盘磁头的寻道时间，只需很少的扇区旋转时间，所以速度远快于随机读写。2、零拷贝Kafka高吞吐量的原因其中有个重要技术就是Zero-Copy(零拷贝)系统调用机制传统的文件拷贝由于应用程序无法直接读取内核空间的数据，如果要读取这些数据，那么必须把数据从读取缓冲区拷贝到应用程序缓冲区用

生产者丢失消息生产者(Producer) 调用send方法发送消息之后，消息可能因为网络问题并没有发送过去。Kafka提供了同步发送消息方法，会返回一个Future对象，调用get()方法进行阻塞等待，就可以知道消息是否发送成功。如果消息发送失败的话，可以通过Producer 的retries（重试次数）参数进行设置，当出现网络问题之后能够自动重试消息发送，避免消息丢失。另外，建议还要设置重试间隔

Redisson的加锁方法有两个，tryLock和lock，使用上的区别在于tryLock可以设置锁的过期时长leaseTime和等待时长waitTime，核心处理的逻辑都差不多Redission分布式锁原理_知知之之的博客-CSDN博客_redission实现分布式锁原理原理源码中加锁lua代码if (redis.call('exists', KEYS[1]) == 0) then redis.

文件事件处理器的四个部分:套接字、I/O多路复用程序、文件事件分发器、事件处理器套接字socket文件事件就是对套接字的抽象，每当一个套接字准备好执行连接、写入、读取、关闭等操作时，都会产生一个文件事件。因为一个Redis服务器会有多个客户端连接，也就是说有多个套接字，所以多个文件事件可能会并发出现。I/O多路复用程序I/O多路复用程序，负责监听多个套接字，按照处理顺序，将套接字存放在一个队列中。