Zookeeper+kafka学习笔记

Zookeeper是Apache的一个java项目，属于Hadoop系统，扮演管理员的角色。

配置管理

分布式系统都有好多机器，比如我在搭建hadoop的HDFS的时候，需要在一个主机器上（Master节点）配置好HDFS需要的各种配置文件，然后通过scp命令把这些配置文件拷贝到其他节点上，这样各个机器拿到的配置信息是一致的，才能成功运行起来HDFS服务。Zookeeper提供了这样的一种服务：一种集中管理配置的方法，我们在这个集中的地方修改了配置，所有对这个配置感兴趣的都可以获得变更。这样就省去手动拷贝配置了，还保证了可靠和一致性。

名字服务

这个可以简单理解为一个电话薄，电话号码不好记，但是人名好记，要打谁的电话，直接查人名就好了。
分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务；

• 类似于域名与ip之间对应关系，域名容易记住；
• 通过名称来获取资源或服务的地址，提供者等信息

分布式锁

单机的各个进程需要对互斥资源进行访问的时候需要加锁，分布式进程在各个主机进行对互斥资源进行访问的时候也需要加锁。

如何理解互斥资源呢？
比如mysql？

很多分布式系统有很的客服务窗口，但是在某个时刻只让一个服务区干活，当这台服务出问题的时候锁释放，立刻fail over到另外的服务。这在很多分布式系统都是这么做的，这种设计有个更好听的名字叫Leader Election（leader选举）

通俗来说比如银行取钱，有多个窗口，但是对于你来说只能有一个窗口为你提供服务，如果正在对你服务的人突然有事走了怎么办？找大堂经理（zookeeper），指定另外一个窗口为你提供服务

集群管理

在分布式集群中经常会有各种原因，比如：硬件故障，软件故障，网络问题，有些节点会进进出出。这个时候master节点需要感知这种变化，然后根据这种变化做出对应的决策。比如HDFS中namenode是通过心跳机制来感知的，那么先假设zookeeper也是通过心跳机制的功能吧

zookeeper的特点

• 最终一致性：为客户端展示同一视图，这是zookeeper最重要的功能。
• 可靠性：如果消息被到一台服务器接受，那么它将被所有的服务器接受。
• 实时性：Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
• 等待无关（wait-free）：慢的或者失效的client不干预快速的client的请求。
• 原子性：更新只能成功或者失败，没有中间状态。
• 顺序性：所有server，同一消息发布顺序一致。

用到zookeeper的系统

HDFS中的HA
YARN的HA方案
HBase：必须依赖zookeeper，保存了Regionserver的心跳信息，和其他的一些相关信息
Flume：负载均衡，单点故障

zookeeper的基本架构

主从结构

• 每个server在内存中存储了一份数据
• zookeeper启动时将从实例中选举一个leader（Paxos协议）
• Leader负责处理数据更新等操作（Zab协议）
• 一个更新操作成功，当且仅当大多数server在内存中修改数据

Leader，Learner（Follower，Observer），client
leader：领导者负责进行投票的发起和决议，更新系统状态
follower：用于接受呵护请求并向客户端返回结果，在选主的过程中参与选票
observer：observer可以接受客户端连接，将写请求转发给leader节点，但observer不参与投票过程，只同步leader的状态。observer的目的是扩展系统，提高读写速度。
client：请求发起方

Zookeeper Server节点数目

Zookeeper Server数目一般为奇数
Leader选举算法采取了Paxos协议；Paxos核心思想：当多数Serve写成功，则任务数据写成功。
3个serve两个成功即可，所以server一般为奇数
3个server最多允许1个server挂掉

Observer节点

3.3.0 以后 版本新增角色Observer

增加原因：
Zookeeper需要保证高可用和强一致性；
当集群节点数目逐渐增大，为了支持更多的客户端，需要增加更多的server，然而server增多，投票延迟增大，影响性能，为了权衡伸缩性和高吞吐率，引入Observer：
Observer不参与投票
observer接受客户端的链接，并将写请求转发给leader节点
加入更多节点，提高伸缩性，同时不影响吞吐率

zookeeper搭建

zookeeper安装有三种方式，单机模式，集群模式，伪集群模式

• 单机模式：zookeeper只运行在一台服务器上，适合测试环境
• 伪集群模式：在一台物理机上运行多个zookeeper实例
• 集群模式：zookeeper运行与一个集群之上，适合生产环境，这个计算机集群被称为一个集合体（ensemble）

zookeeper通过复制来实现高可用，只要集群中半数以上处于可用状态，就能够继续保持服务，为什么一定要超过半数呢？跟复制策略有关

https://www.cnblogs.com/ExMan/p/11011595.html
kafka入门：简介、使用场景、设计原理、主要配置及集群搭建

• zookeeper在kafka中的作用是什么
• kafka中几乎不允许对消息进行随机读写的原因是什么
• kafka集群consumer和producer状态信息是如何保存的
• partitons设计的目的根本原因是什么

简介

kafka根据topic进行归类，发送消息者成为producer，消息接受者成为consumer，此外kafka有锁哥kafka实例组成，每个server成为broker。无论是kafka集群还是peoducer和consumer都依赖zookeeper来保证系统的高可用性集群保存一些meta信息

• topics/logs topic可以认为是一类消息，每个topic将被分成多个区，每个partition（区）在存储层面是append log文件，任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置成为offset（偏移量） offset为一个long型的数字，标记了唯一的一条消息。kafka并没有提供额外的索引来存储offset，因为kafka中几乎不允许对消息进行随机读写。

kafka会保存一段时间 可以自定义日志销毁的时间
concsumer保存消费信息offset，对于offset的保存和使用，有consumer来控制，当consumer正常消费信息的时候，offset会线性向前驱动，消息将依次顺序被消费。consumer可以使用任意顺序消费信息，只需要将offset重置成任意值（offset将保存在zookeeper中）

• kafka集群不需要维护任何consumer和producer状态信息，这些信息由zookeeper保存。

• partition是的设计目的：根本原因是kafka基于文件存储，通过分区，可以将日志内容分散到多个server上，来避免文件尺寸达到单机磁盘的上限。每个partition都会被当前server（kafka实例）进行保存，将一个topic切分任意多个partition，来保证效率，partition约多可以容纳更多的consumer，提高并发能力

• 此外kafka还可以配置partitions需要备份的个数(replicas),每个partition将会被备份到多台机器上,以提高可用性.

• 本质上kafka只支持Topic.每个consumer属于一个consumer group;反过来说,每个group中可以有多个consumer.发送到Topic的消息,只会被订阅此Topic的每个group中的一个consumer消费.

  如果所有的consumer都具有相同的group,这种情况和queue模式很像;消息将会在consumers之间负载均衡.
  如果所有的consumer都具有不同的group,那这就是"发布-订阅";消息将会广播给所有的消费者.
  在kafka中,一个partition中的消息只会被group中的一个consumer消费;每个group中consumer消息消费互相独立;我们可以认为一个group是一个"订阅"者,一个Topic中的每个partions,只会被一个"订阅者"中的一个consumer消费,不过一个consumer可以消费多个partitions中的消息.kafka只能保证一个partition中的消息被某个consumer消费时,消息是顺序的.事实上,从Topic角度来说,消息仍不是有序的.

  • partition不能多于consumer的个数，否则将意味着某些consumer无法得到消息
  • zookeeper解决分布式的一致性

Rabbitmq集群高可用部署详细
https://www.cnblogs.com/ExMan/p/11011588.html