kafka的HA机制
1、kafka的HA机制：副本机制+消息同步+leader选举。
每个topic有多个partition，每个partition又有多个副本，这些副本当中也存在不同的角色，leader、follower。producer和consumer都只跟leader进行交互，leader进行读写操作。leader负责将消息写进本地log当中，follower去leader上pull拉取数据，将数据同步到本地log当中。当leader挂了的时候，就利用zookeeper重新选出一个leader即可。
其中，kafka将所有的partition均匀分布在集群中的broker上，所有的Replica副本也均匀分布在集群中的broker上，这样做主要是保证负载均衡和容错能力。因为所有的分区和副本都在一个broker上，那样这个broker挂了，数据也就都丢失了。实现这个均匀分布，使用的是一种算法。主要就是用求余数的运算。
Kafka分配Replica的算法如下：
1.将所有Broker（假设共n个Broker）和待分配的Partition排序
2.将第i个Partition分配到第（i mod n）个Broker上
3.将第i个Partition的第j个Replica分配到第（(i + j) mode n）个Broker上
总之，kafka的健壮性主要来源其强大的副本策略。
2、消息同步策略：producer发送消息到某个partition时，首先通过zookeeper获取这个partition的leader， producer只将消息发送给leader ，leader将该消息写入其本地log中，follower从leader上pull数据。为了提高性能，follower收到消息之后直接向leader返回Ack，follower将消息写进本地log中。一旦leader收到了ISR列表中的所有Replica的ack，该消息就被认为已经commit了，leader向producer发送ACK。
consumer读消息也只从leader读取，只有commit的消息才会暴露给consumer。
3、leader选举：所有的follower都在zookeeper上注册watch监听，一旦leader宕机，其对应的ephemeral znode临时节点会被删除，此时所有的follower都去尝试创建该节点，创建成功者，成为新的leader，其他的Replica就是follower。
leader选举本质上是分布式锁，有两种方式实现基于zookeeper的分布式锁。
节点名称唯一性：多个客户端创建一个节点，只有创建成功的才会获得锁。
临时顺序节点：所有的客户端在某个目录下创建自己的临时顺序节点，只有序号最小的才会获得锁。
参考博客：https://www.cnblogs.com/frankdeng/p/9310704.html
最新文章
- LeetCode刷题系列
- C#元组示例详解
- ubuntu14.04安装pycurl报错: __main__.ConfigurationError: Could not run curl-config: [Errno 2] No such file or directory
- 黄聪：PHP5.6+7代码性能加速-开启Zend OPcache-优化CPU
- C#中常用的排序算法的时间复杂度和空间复杂度
- JVM内存回收机制
- OpenStack core components CLI快速调用API
- IOS计划 分析
- ALAssetsLibrary 照片相关 浅析
- Effective Java 第三版——43.方法引用优于lambda表达式
- 图的深度优先遍历(DFS)—递归算法
- Babel 配置选项
- 01-JavaScript介绍
- centos6.5 Python.7 pip install PIL --allow-external PIL --allow-unverified PIL报错 no such option: --allow-external
- HTML5 CSS3 Transform 笔记 (scale不起作用)
- Python——列表、元祖、字典、集合的基本操作
- struts2：struts.properties配置文件介绍及常量加载顺序
- （转）Thread中yield方法
- 通过 ulimit 改善系统性能
- 【转】Phong和Blinn-Phong光照模型