etcdraft vs kafka

在最新版本的fabric中，现在存在三种共识排序方式——solo、kafka、etcdraft，其中kafka和etcdraft是多机部署模式。受此启发，对fabric和kafka做一个对比。

1. 定义

1.1 etcdraft

ETCD是用于共享配置和服务发现的分布式，一致性的KV存储系统。

1.2 kafka

Kafka是由[Apache软件基金会]开发的一个开源流处理平台，是一种高吞吐量的[分布式]发布订阅消息系统。

2. 数据共识方式对比

etcd和kafka都是分布式的系统，数据在各个节点之间需要保持一致。kafka是借助zookeeper来实现数据一致性，etcd是使用raft协议来保持数据一致性。下面详细介绍一下kafka和etcd分别通过什么方式来保证数据一致的.

2.1 kafka

2.1.1 首先介绍两个重要概念

• LEO：last end offset，日志末端偏移量，记录了该副本对象底层日志文件中下一条消息的位移值。举一个例子，若LEO=10，那么表示在该副本日志上已经保存了10条消息，位移范围是[0，9]。
• HW：highwatermark，高水印值，任何一个副本对象的HW值一定不大于其LEO值，而小于或等于HW值的所有消息被认为是“已提交的”或“已备份的”。

2.1.2 数据同步过程
(1). 主节点接收到数据数据后，会把本地leo+1。
(2). 把数据分发给从节点。
(3). 从节点leo+1。
(4). 从节点执行完成后返回给主节点。
(5). 等ISR列表中的从节点都返回后，主节点执行hw+1。

kafka.png

*对于Leader新写入的msg，Consumer不能立刻消费，Leader会等待该消息被所有ISR中的replica同步后,更新HW,此时该消息才能被Consumer消费，即Consumer最多只能消费到HW位置。这样就保证了如果Leader Broker失效,该消息仍然可以从新选举的Leader中获取。对于来自内部Broker的读取请求,没有HW的限制。

2.2 etcd

在etcd中，leader扮演的是分布式事务中的协调者，每次有数据更新的时候产生二阶段提交（two-phase commit）。在leader收到数据操作的请求，先不着急更新本地数据（数据是持久化在磁盘上的），而是生成对应的log，然后把生成log的请求广播给所有的follower。然后回到leader，此时如果超过半数的follower都成功写了log，那么leader开始第二阶段的提交：正式写入数据，然后同样广播给follower，follower写入并返回结果给leader。leader先写自己的数据，然后告诉follower也开始持久化数据，步骤如下图所示：

etcd.png

3. 应用场景

3.1 kafka

1. 消息
   kafka更好的替换传统的消息系统，消息系统被用于各种场景（解耦数据生产者，缓存未处理的消息，等），与大多数消息系统比较，kafka有更好的吞吐量，内置分区，副本和故障转移，这有利于处理大规模的消息。
2. 网络活动追踪
   kafka原本的使用场景：用户的活动追踪，网站的活动（网页游览，搜索或其他用户的操作信息）发布到不同的话题中心，这些消息可实时处理，实时监测，也可加载到Hadoop或离线处理数据仓库。
3. 日志收集
   一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如Hadoop、Hbase等。
4. 流处理
   kafka消息处理包含多个阶段。其中原始输入数据是从kafka主题消费的，然后汇总，丰富，或者以其他的方式处理转化为新主题。
5. 提交日志
   kafka可以作为一种分布式的外部提交日志，日志帮助节点之间复制数据，并作为失败的节点来恢复数据重新同步

3.2 etcd

1. 配置管理
2. 服务注册于发现
3. 选主
4. 应用调度
5. 分布式队列
6. 分布式锁