@ -702,6 +702,64 @@ try {
- 主要的机制是两阶段提交（ ）
### 2.7 消费者组到底是什么？
- 用一句话概括就是：
- 既然是一个组， （ ） ， ， （ ） （ ） ，
- Consumer Group 记住下面这三个特性
- Consumer Group 下可以有一个或多个 Consumer 实例。这里的实例可以是一个单独的进程，也可以是同一进程下的线程。在实际场景中，**使用进程更为常见一些**。
- Group ID 是一个字符串，在一个 Kafka 集群中，它标识唯一的一个 Consumer Group。
- Consumer Group 下所有实例订阅的主题的单个分区，只能分配给组内的某个 Consumer 实例消费。这个分区当然也可以被其他的 Group 消费。
- 两种消息引擎模型
- 点对点模型和发布 / 订阅模型，前者也称为消费队列。
- Kafka 的 Consumer Group 就是这样的机制。当 Consumer Group 订阅了多个主题后，**组内的每个实例不要求一定要订阅主题的所有分区，它只会消费部分分区中的消息**。
- Consumer Group 之间彼此独立，互不影响，它们能够订阅相同的一组主题而互不干涉。再加上 Broker 端的消息留存机制，
- 可以这么说，
- 如果所有实例都属于同一个 Group， ； ，
- 在实际使用场景中，我怎么知道一个 Group 下该有多少个 Consumer 实例呢？
- ** 理想情况下，
- 假设一个 Consumer Group 订阅了 3 个主题，分别是 A、B、C， ， ，
- ** 在实际使用过程中一般不推荐设置大于总分区数的 Consumer 实例**。设置多余的实例只会浪费资源，而没有任何好处。
- 针对 Consumer Group， ， ： （ ）
- 看上去该 Offset 就是一个数值而已，其实对于 Consumer Group 而言，它是一组 KV 对， ，
- 如果用 Java 来表示的话，你大致可以认为是这样的数据结构，即 Map< TopicPartition , Long > ，其中 TopicPartition 表示一个分区，而 Long 表示位移的类型。
- Kafka 源码中并不是这样简单的数据结构，而是要比这个复杂得多
- Kafka 有新旧客户端 API 之分，那自然也就有新旧 Consumer 之分。老版本的 Consumer 也有消费者组的概念，它和我们目前讨论的 Consumer Group 在使用感上并没有太多的不同，只是**它管理位移的方式和新版本是不一样的**。
- 老版本的 Consumer Group 把位移保存在 ZooKeeper 中。Apache ZooKeeper 是一个分布式的协调服务框架，
- ** 现在比较流行的提法是将服务器节点做成无状态的，这样可以自由地扩缩容，实现超强的伸缩性。**
- Kafka 最开始也是基于这样的考虑，才将 Consumer Group 位移保存在独立于 Kafka 集群之外的框架中。
- 发现了一个问题，即 ZooKeeper 这类元框架其实并不适合进行频繁的写更新，而 Consumer Group 的位移更新却是一个非常频繁的操作。这种大吞吐量的写操作会极大地拖慢 ZooKeeper 集群的性能，因此 Kafka 社区渐渐有了这样的共识：将 Consumer 位移保存在 ZooKeeper 中是不合适的做法。
- 于是，在新版本的 Consumer Group 中，
- ** 新版本的 Consumer Group 将位移保存在 Broker 端的内部主题中**。
- 最后，我们来说说 Consumer Group 端大名鼎鼎的重平衡，也就是所谓的 Rebalance 过程。我形容其为“大名鼎鼎”，从某种程度上来说其实也是“臭名昭著”，因为有关它的 bug 真可谓是此起彼伏，从未间断
- Rebalance 本质上是一种协议，规定了一个 Consumer Group 下的所有 Consumer 如何达成一致，来分配订阅 Topic 的每个分区。
- 比如某个 Group 下有 20 个 Consumer 实例，它订阅了一个具有 100 个分区的 Topic。正常情况下，
- 那么 Consumer Group 何时进行 Rebalance 呢？
- 组成员数发生变更。比如有新的 Consumer 实例加入组或者离开组，抑或是有 Consumer 实例崩溃被“踢出”组。
- 订阅主题数发生变更。Consumer Group 可以使用正则表达式的方式订阅主题，比如 consumer.subscribe(Pattern.compile(“t.*c”)) 就表明该 Group 订阅所有以字母 t 开头、字母 c 结尾的主题。在 Consumer Group 的运行过程中，你新创建了一个满足这样条件的主题，那么该 Group 就会发生 Rebalance。
- 订阅主题的分区数发生变更。Kafka 当前只能允许增加一个主题的分区数。当分区数增加时，就会触发订阅该主题的所有 Group 开启 Rebalance。
- Rebalance 发生时，
- 当前 Kafka 默认提供了 3 种分配策略，每种策略都有一定的优势和劣势，我们今天就不展开讨论了
- 例子来说明一下 Consumer Group 发生 Rebalance 的过程。假设目前某个 Consumer Group 下有两个 Consumer， ， ， ，
- 
- 显然，
- Rebalance 过程对 Consumer Group 消费过程有极大的影响
- 在 Rebalance 过程中，所有 Consumer 实例都会停止消费，等待 Rebalance 完成。
- 其次，目前 Rebalance 的设计是所有 Consumer 实例共同参与，全部重新分配所有分区。其实更高效的做法是尽量减少分配方案的变动。
- 例如实例 A 之前负责消费分区 1、2、3， ， ，
- 最后，
- 最好的解决方案就是避免 Rebalance 的发生。
- 补充
- 消费组中的消费者个数如果超过topic的分区数， ， ？
- 如果使用assign， （ ） ， ， ，
- 减少topic的分区数可以减少服务部署时rebalance的时间呢？
- 减少consumer个数也有缩短rebalance。
- Kafka 社区重新设计了 Consumer Group 的位移管理方式”
- 0.9版本引入了新版本consumer。新版本将位移保存在__consumer_offsets中， ， ，
### 2.8 揭开神秘的“位移主题”面纱
