Kafka与Zookeeper

Zookeeper

 

Zookeeper是一个高性能分布式应用协调服务

》Naming Service

》配置管理

》Leader Election

》服务发现

》同步

》Group Service

》Barrier

》分布式队列(其实zookeeper并不适合作为分布式队列，性能不高只不过在特定场合可以)

》两阶段提交

 

Zookeeper工作方式

》Zookeeper集群包含一个1个Leader，多个Follower

》所有的Follower都可提供读服务

》所有的写操作都会被forward到Leader

》Client与Server通过NIO通信

》全局串行化所有的写操作

》保证同一客户端的指令被FIFO执行

》保证消息通知的FIFO

 

 

与Kafka读写操作不一样，Kafka只有Leader提供读写操作。

 

Zab协议-广播模式

客户端每发送一个更新请求，ZooKeeper都会生成一个全局唯一的递增编号，这个编号反映了所有事务操作的先后顺序，这个唯一编号就是事务ID(ZXID)，只有更新请求才算是事务请求。
为保证按照事务的ZXID先后顺序来处理，Leader服务器会分别为每个Follower服务器创建一个队列，并将事务的先后顺序放入队列中，并按照FIFO的策略进行消息发送。收到需要处理的事务后，Follower服务器会首先以事务日志的形式写入服务器的磁盘中，写入成功后会向Leader服务器发送ACK响应。当Leader服务器收到超过一半的Follower服务器的ACK响应后，会向所有Follower服务器广播Commit消息，收到Commit消息的Follower服务器也会完成对事务的提交。
如果接收到事务请求的是Follower服务器，它会将请求转发给Leader服务器处理。

 

 

 

Zab协议-恢复模式

进入恢复模式：当Leader宕机或者丢失大多数Follower后，即进入恢复模式

结束恢复模式：新领导被选举出来，且大多数Follower完成了与Leader的状态同步后，恢复模式即结束，从而进入广播模式

恢复模式的意义

》发现集群中被commit的proposal的最大zxid

》建立新的epoch，从而保证之前的Leader不能再commit新的proposal

 

 

》集群中大部分节点都commit过前一个Leader commit过的信息，而新的Leader是被大部分节点所支持的，所以被之前Leader commit过的Proposal不会丢失，至少被一个节点所保存

》新Leader会与所有Follower通信，从而保证大部分节点都拥有最新的数据

 

 

 

Zookeeper一致性保证

顺序一致性：从一个客户端发出的更新操作会发送顺序被顺序执行

原子性：更新操作要么成功要么失败，无中间状态

单一系统镜像：一个客户端只会看到同一个view，无论它连到哪台服务器

可靠性：

》一旦一个更新被应用，该更新将被持久化，直到有客户端更新该结果

》如果一个客户端得到更新成功的状态码，则该更新一定生效

》任何一个被客户端通过读或者更新“看到”的结果，将不会被回滚，即使是从失败中恢复

实时性：保证客户端可在一定时间（通常是几十秒）内看到最新的视图

 

Zookeeper使用注意事项

》只保证同一客户端的单一系统镜像，并不保证多个不同客户端在同一时刻一定看到同一系统镜像，如果要实现这种效果，需要在读取数据之前调用sync操作

》Zookeeper读性能好于写性能，因为任何Server均可提供读服务，而只有Leader可提供写服务

》为了保证Zookeeper本身的Leader Election顺利进行，通常将Server设置为奇数

》若需容忍f个Server的失败，必须保证有2f+1个以上的Server