021-66889888
你可曾碰到过消费Kafka消息时出现重复或者丢失的状况呢？就在今天，我们会选择一种通俗易懂的形式，将Kafka从生产消息一直到消费消息的完整消息策略阐述明白清晰，以此助力你完全透彻地理解这个分布式消息系统。
发送消息的生产者的第一步是建立连接，你得配置Kafka集群地址、序列化方式等基础参数，这些配置把生产者与服务器通信的方式给决定了。生产者对象创建完以后，要送的数据就得准备好，包括发送到哪个主题以及分区都要进行指定。
消息并非会马上发出去，而是先进入一个按批次存放消息的数据收集缓存区，每个批次默认是16K。可是要注意一个细节，倘若某条消息自身就超过了16K，Kafka会将它单独当作一个批次来处理，以此保证数据的完整性。
缓存区积累至某一程度时，发送线程便会开启工作状态。此处的处理逻辑并非单纯依主题予以划分，而是要作进一步的细致区分，如此一来能够促使消息更为精准地投递给目标地方。消息进入在途请求列表之后，该列表默认能够同时处理5个请求，借助Kafka的网络层面将消息发送至对应的分区副本处。
生产者发送消息之后，要等待服务器的ack响应。ack配置存在差异，可靠性级别便有所不同。ack设置为 -1时，意味着要等待同步完所有副本才算顺利成功，这属于最为严格的方式。发送若失败，生产者会实施重试，将数据重新放置回缓存区，再度走过一遍流程。
生产者为了确保消息不存在重复以及不出现丢失的情况，生产者能够开启幂等性配置，开启之后Kafka会为生产者分配一个生产者的ID，每一条消息都会附上唯一的序列号，如此一来同一分区的消息便能够保证具有唯一性并且拥有顺序，生产者会对最近5个批次的数据进行缓存，新到来的消息若是跟缓存当中的消息重复就会被选择性忽略，要是出现不连续的情况就会触发重试操作，直到排列顺序正确为止。
幂等性尽管好用，不过它仅能确保同一个生产者会话之内的消息不会重复，倘若生产者重启了，那么它所获取的生产者ID会发生改变，原本的信息便会断掉，在这种情况下就应运生产者事务功能来处理跨会话的幂等问题。
当开启事务之后，Kafka内部的事务管理器会创建一个内部主题，该主题用于存储事务ID以及相关状态信息。如此一来，即便生产者出现挂掉后重启的情况，它也能够凭借事务ID恢复之前的状态，进而继续确保消息的唯一性与有序性。事务与ack=-1以及重试机制相互配合，最终形成了一个完整的具备高可靠性的方案。
在Kafka里，消费者组是达成并行消费的关键中心所在，于一个消费者组之中，有着多个消费者一同去消费一个主题，并且每个分区仅仅能够被组内的一个消费者用来消费，Kafka默认所采用的分配策略是范围分配方式，后续会一步步地升级成为协作粘性分配。
轮询分配策略极为简易，它是先将所有那些消费者依据UUID予以排序，随后再轮流着向每一个消费者去分配分区。范围分配策略会尽可能地把分区平均地分给消费者，但若处于多主题的情形下则容易出现分配不均衡的状况。协作粘性分配乃是对粘性分配进行的一种优化，在重新分配之际减少了分区连接的关闭次数，进而提高了效率。
消费者所消费消息的位置，是依靠偏移量予以记录的。倘若属于新近加入的消费者组，且尚未提交过偏移量，那么便会依据auto.offset.reset参数来判定从何处起始消费。当提交之后，Kafka会记得您消费至何处，下次启动时便会从所记录的位置持续进行。
在生产环境里头，消费者存在着重启的可能性，要是偏移量管理得不够妥善，那么就会致使重复消费或者消息丢失的情况出现。除了将生产者的幂等性开启外，消费者这边能够挑选手动提交偏移量，与此同时，维持一个记录着已处理消息的列表，每一次消费之前，都先去核查一下这条消息是否已然被处理过，以此来防止重复消费。
当生产者开启事务完毕后，或许会有一小部分尚未提交成功的数据留存着。消费者能够设置事务隔离级别，在默认情形下仅仅读取已经提交的事务数据，如此一来能够避免读到脏数据。这种机制确保了消费端所看到的数据是完整并且一致的。
从Kafka的2.4版本起，便开始支持自首选副本读取数据，于跨机房场景里，这尤为有用。采用主动拉取模式的消费者，依据自身处理能力去拉取数据，不同消费者间不会彼此产生影响。在副本同步层面，仅有副本管理器所指定的副本进行数据写入，其他副本借由定时同步来确保数据一致性。
于你于Kafka运用之际，可有消息遭重复涵盖或者遗失之状况？那你系怎样进而去化解此等问题的？欢迎处于评论区域之内分享你的相关情形，要是感觉此次篇章对你存有协助作用，同样也请予以点赞开展支持一番。