计算机 ==>> 消息中间件
消息中间件
kafka
高可用
副本是以Topic中每个Partition的数据为单位，每个Partition的数据会同步到其他物理节点上，形成多个副本。
每个Partition的副本都包括一个Leader副本和多个Follower副本，Leader由所有的副本共同选举得出，其他副本则都为Follower副本。在生产者写或者消费者读的时候，都只会与Leader打交道，在写入数据后Follower就会来拉取数据进行数据同步。
Producer
|| topic
\/broker1 broker2 broker3
partition1 leader partition2 leader partition3 leader
partition3 follower partition1 follower partition2 follower
partition2 follower partition3 follower partition1 follower
/\
|| topic
Consumer采用一种ISR机制（In-Sync Replica）。每个Leader会动态维护一个ISR列表，该列表里存储的是和Leader基本同步的Follower。如果有Follower由于网络、GC等原因而没有向Leader发起拉取数据请求，此时Follower相对于Leader是不同步的，则会被踢出ISR列表。所以说，ISR列表中的Follower都是跟得上Leader的副本。
Kafka的Leader选举思路很简单，基于我们上述提到的ISR列表，当宕机后会从所有副本中顺序查找，如果查找到的副本在ISR列表中，则当选为Leader。另外还要保证前任Leader已经是退位状态了，否则会出现脑裂情况（有两个Leader）。怎么保证？Kafka通过设置了一个controller来保证只有一个Leader。
request.required.asks参数：Asks这个参数是生产者客户端的重要配置，发送消息的时候就可设置这个参数。该参数有三个值可配置：0、1、All。0表示发送后不管；1表示只要顺利发送给Leader即可；All或-1表示不仅Leader要接收到，LSR列表中的Follower也要同步到。
当三个节点中某个节点宕机后，集群首先会怎么做？没错，正如我们上面所说的，集群发现有Partition的Leader失效了，这个时候就要从ISR列表中重新选举Leader。如果ISR列表为空是不是就不可用了？并不会，而是从Partition存活的副本中选择一个作为Leader，不过这就有潜在的数据丢失的隐患了。
所以，只要将Topic副本个数设置为和Broker个数一样，Kafka的多副本冗余设计是可以保证高可用的，不会出现一宕机就不可用的情况（不过需要注意的是Kafka有一个保护策略，当一半以上的节点不可用时Kafka就会停止）。
问题点
- Kafka上是不是有副本个数为1的Topic？
问题出在了consumer_offset上，consumer_offset是一个Kafka自动创建的Topic，用来存储消费者消费的offset（偏移量）信息，默认Partition数为50。而就是这个Topic，它的默认副本数为1。如果所有的Partition都存在于同一台机器上，那就是很明显的单点故障了！当将存储__consumer_offset的Partition的Broker给Kill后，会发现所有的消费者都停止消费了。
- 上面的问题怎么解决？
第一点，需要将__consumer_offset删除，注意这个Topic时Kafka内置的Topic，无法用命令删除，我是通过将logs删了来实现删除。
第二点，需要通过设置offsets.topic.replication.factor为3来将__consumer_offset的副本数改为3。
通过将__consumer_offset也做副本冗余后来解决某个节点宕机后消费者的消费问题。
- 为什么__consumer_offset的Partition会出现只存储在一个Broker上而不是分布在各个Broker上？
__consumer_offsets 的副本数量默认不是1。这topic是在首个consumer消费后创建的，不是集群启动创建，默认是三副本，但是不会超过此时集群內的broker数量。问题出在只启动了一个broker就开始消费数据了。