什么时候用Kafka什么时候用RabbitMq？
数据量大的情况：
例如我们的日志存储情况，我们就选型我们的Kafka
消费者批量消费的情况：
Kafka消费的时候是批量消费的，我们是记录一个offset，然后消费X个，失败了我们就从我们记录的offset重新开始。
而RabbitMq为了保证我们的可靠性，我们是一条一条消费不是批量消费，我们有ack机制保证我们的每条消息的可靠性
对消息可靠性不强的时候：
Kafka
想消费者完全控制消费逻辑的时候：
Kafka，我们有个pull拉取模式，重写我们的逻辑，实现对offset的完全控制
说一下Kafka你是怎么进行配置的？例如生产者配置和消费者配置
bootstrap-server Kafka集群的地址和端口号
默认的主题的名称
Producer生产者配置
ack ack消息确认的方式
- 0： 相当于异步操作，Producer 不需要Leader给予回复，发送完就认为成功，继续发送下一条（批）Message。此机制具有最低延迟，但是持久性可靠性也最差，当服务器发生故障时，很可能发生数据丢失。
- 1： Kafka 默认的设置。表示 Producer 要 Leader 确认已成功接收数据才发送下一条（批）Message。不过 Leader 宕机，Follower 尚未复制的情况下，数据就会丢失。此机制提供了较好的持久性和较低的延迟性。
- -1： Leader 接收到消息之后，还必须要求ISR列表里跟Leader保持同步的那些Follower都确认消息已同步，Producer 才发送下一条（批）Message。此机制持久性可靠性最好，但延时性最差
batch-size
批量发送大小
buffer-memory
生产者用来缓存消息的内存大小
key—serializer
key的序列化器
value-serialize
value的序列化器
retries
重试次数
Comsumer消费者配置
group-id
消费者组Id
auto-offerset-rest
当消费者没有提交offerset时，我们该从哪里开始消费。earliest也就是从最早的没提交offerset开始消费
enable-auto-commit
是否自动提交offerset
auto-commit-interval
自动提交offeset的间隔
key—serializer
key的序列化器
value-serialize
value的序列化器
max-poll-records
一次poll操作最多返回的消息数量，消费者消费一次可以拉取的最大消息个数
Listener监听配置
missing-topics-fatal
如果至少有一个topic不存在，true启动失败，false忽略
type
消费类型，batch批量，single单条
concurrency
并发消费的线程数，为每个消费者实例创建多少个线程