这篇文章主要讲解了“ KAFKA中的Replica是什么”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“ KAFKA中的Replica是什么”吧！
【能否说下Replica的主从设计？】
冗余，可以理解为一个动作，就是把一份数据多拷贝了几份出来。
而拷贝出来的数据我们就称之为副本，这也是Replica的真正含义，那么多副本之间就必然存在着数据同步的问题：
也就是不同副本之间，以哪个副本的数据为准，如何保持数据一致这两个主要问题。
因此，副本之间就有了主从的一个设计，负责提供读写的副本是leader，而其余的副本称之为follower，follower副本只需要从leader副本那里一直拉取数据就好了，正常情况下不需要提供读写。
看起来是这个样子的：
【能否说下Replica解决了什么问题？】
首先我们要明白一点——某个Partition的数据副本，都是分布在不同的broker上的，也就是说是分布在不同机器上的，那么显而易见，Replica是为了解决单点问题而设计的。
我们再考虑下会存在哪些单点问题？
1、当我们生产消息的时候，如果数据只写入了一个broker就返回了，那么一旦那个broker挂了，或者所在机器宕机了，是不是可能造成我刚才写入的消息就丢失了？
2、我们生产/消费都只针对leader-replica进行，那么是不是一旦leader所在的broker挂了，或者所在机器宕机了，就无法进行生产消费了？
以上就是主要存在的两个问题，在引入副本的设计后，解决这两个问题就很简单了：
1、由于存在多副本，因此我们可以设置写入所有副本后，才算写入消息成功；那么数据就会分散到多个节点上，从而避免了单点问题。这就是之前提到的实现了消息的高可靠。
2、由于存在多个副本，并且副本之间的数据一直在同步，一旦leader所在节点出现问题，那么我们就可以进行主备切换，让某个follower成为新的leader来继续提供读写，从而避免了整个服务不可用了。这就是之前提到的实现服务的高可用。
感谢各位的阅读，以上就是“ KAFKA中的Replica是什么”的内容了，经过本文的学习后，相信大家对 KAFKA中的Replica是什么这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
