1. 消费者负责订阅kafka中的主题topic,并且从订阅的主题上拉取消息，与其他一些消息中间件不同的是:
还有一层消费组的概念
2. 每一个分区只能被一个消费组中的一个消费者所消费
3. 消费者与消费组这种模型可以让整体的消费能力具备横向伸缩性，我们可以增加(或减少)消费者的个数
来提高(或降低)整体的消费能力
4. 如果所有的消费者都禄属于同一个消费组，那么所有的消息都会被均衡地投递给每一个消费者，即每条
消息只会被一个消费者处理，这就相当于点对点模式的应用
5. 如果所有的消费者都禄属于不同的消费组，那么所有的消息都会被广播给所有的消费者，即每条消息会
被所有的消费者处理，这就相当于发布/订阅模式的应用
一个正常的消费逻辑需要具备以下几个步骤
- 1）配置消费者客户端参数及创建相应的消费者实例
- 2）订阅主题
- 3）拉取消息并消费
- 4）提交消费位移
- 5）关闭消费者实例
3.2.2 订阅主题与分区
对于同一个消费者而言，如果前后两次订阅了不同的主题，那么消费者以最后一次为准
3.2.4 消息消费
kafka中的消费是基于拉模式的
针对ConsumerRecord，里面的字段tomestampType有两种类型createTime，LogAppendTime分别代表消息的创建时间和消息追加到日志的时间
到目前为止，可以简单认为poll()方法只是简单拉取一下下消息而已，但就其内部逻辑而言并不简单，它涉及消费位移，消费者协调器，组协调器，消费者的选举，分区分配的分发，再均衡的逻辑，心跳等内容
3.2.5 位移的提交
对于消息在分区中的位置，我们将offset称为"偏移量"
对于消费者消费到的位置，将offset称为"位移"
在每次调用poll()方法的时候，它返回的事还没有被消费过的消息集(当然这个前提是消息已经存储在kafka中了，
并且暂时不考虑异常情况的发生)，要做到这一点，就需要记录上一次消费时的位移
position: 下一次拉取消息的位置
lastConsumedOffset: 当前消费到的位置
commited offset: 已经提交过的消费位移
对于位移提交的具体时机也很有讲究，有可能造成重复消费和消息丢失的现象
eg: x+5表示当前正在处理的位置，如果拉取到消息之后就进行了位移提交，即提交了x+8，那么当前消费x + 5
的时候遇到了异常，在故障恢复后，我们重新拉取的消息是从x+8开始的，也就是说x+5~x+7之间的消息并
未能消费，如此便发生了消息丢失的情况，如下图3-7
eg: 在考虑另外一种情形，唯一提交的动作是在消费完所有拉取到的消息之后才执行的，那么当消费x + 5的时候遇到
了异常，在故障恢复之后我们重新拉取的消息是从x + 2开始的。也就是说x + 2至 x + 4之间的消息又被重新
消费了一次,故而又发生了重复消费的现象
3.2.5 位移的提交
在kafka中默认的消费位移的提交方式是自动提交，在默认的方式下，消费者每隔五秒会将拉取到的每个分区中
的最大消息位移进行提交
自动提交方式中，消息丢失是怎么产生的？
拉取线程A不断地拉取消息并存入本地缓存，比如在Blocking Queue中，另一个处理线程B从缓存中读取消息并进行
相应的逻辑处理，假设目前已经进行到了y + 1次拉取，以及第m次位移提交的时候，也就是x + 6之前的位移已经
确认提交了，处理线程B却还在消费x + 3的消息，此时如果处理线程B发生了异常，待其恢复之后会从第m
此位移提交，也就是x + 6的位置开始拉取消息，那么x + 3~ x + 6之间的消息就没有得到相应的处理，这样便会
发生消息丢失的现象
很多时候并不是说拉取到消息就算消费完成，而是需要将消息写入数据库、写入本地缓存，或者是更加复杂的
业务处理
针对异步位移提交，如果某一次异步提交的消费位移为x,但是提交失败了然后下一次又异步提交了消费位移x + y
成功了。如果这里引入了重试机制，前一次的异步提交的消费位移在重试的时候提交成功了，那么此时的消费位移
又变成了x
解决办法: 设置一个递增的序列号来维护异步提交的顺序，每次位移提交之后就增加序号相应的值
3.2.6 控制或关闭消费
在调用close()方法之后还会进行一次提交位移的操作
3.2.7 控制或关闭消费
kafka中的KafkaConsumer中的seek()方法提供了追溯消费或回溯消费的能力(有指定时间范围的方法)
seek()方法为我们提供了从特定位置读取消息的能力，我们可以通过这个方法向前跳过若干消息
向后回溯若干消息，这样子就为笑嘻嘻的消费提供了很大的灵活性。seek()方法也为我们提供了将消费位移保存
在外部存储介质中的能力，还可以配合再均衡监听器来提供更加精准的消费能力
3.2.10 多线程实现
...
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
