cap理论
分区容错性；可用性；一致性
分区容错性：分布式系统的某个节点或网络分区出现故障的时候，整个系统还可以对外提供服务，不影响整体的使用。
可以性：服务对外可以被使用，不出现故障
一致性：分布式系统执行完写操作，读取数据时，读取的是写入的最新数据。
场景：生产者--》队列--》消费者，生产者如何知道消费者已经完成了每一个消费，可以通过zookeeper维护的消费信息的节点来通知
简介：ZooKeeper是一个开放源码的分布式应用程序协调服务
下面是集群的结构：
zookeeper的特性：
最终一致性：客户端访问的不同的服务显示的值都是一样的；
实时新：服务端保证客户端在一定的时间范围内获取最新的数据，如果需要获取最新的，也可以执行sync(),获取最新数据。
原子性：更新数据，要么失败，要么成功；
顺序性:从客户端到服务端的写操作是按顺序执行的
zookeeper的结构图：
zookeeper已文件的结构存储：
存储节点的介绍：
zookeeper产生的每个子目录都被称为节点znode，这个节点在所在的路径是唯一的，作为一个标识，如Server1这个znode的标识为/NameService/Server1。 每个节点都可以存储数据，。除了临时节点，其他节点都可以有子节点。
znode是有版本的：每个znode中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据，version号自动增加。
znode的类型：
1、Persistent 节点，一旦被创建，便不会意外丢失，即使服务器全部重启也依然存在。每个 Persist 节点即可包含数据，也可包含子节点。
2、Ephemeral 节点：临时回话节点，服务器和客户端结束回话后，会被删除
3、Non-sequence 节点：多个客户端同时创建同一 Non-sequence 节点时，只有一个可创建成功，其它匀失败
4、Sequence 节点，创建出的节点名在指定的名称之后带有10位10进制数的序号。多个客户端创建同一名称的节点时，都能创建成功，只是序号不同。
监控功能：
zookeeper节点的修改是会被监控到的
事务功能：
节点的修改会产生事务
ZooKeeper Watch
zookeeper节点修改后的触发器： 特点：
1、一次触发:如果对客户端设置了触发，当服务端修改了数据，通知会发给客户端，但是当服务端在发生改变，如果客户端没有对客户端设置监听，客户端收不到服务端修改的通知。
2、触发保证数据一致性:由于网络的问题，修改的通知可能无法传到部分客户端，但是服务端是确保所有的客户端都收到通知后，客户端在显示服务端的数据被修改，也就保证了所有客户端的数据是一致的。
zookeeper集群：
集群的角色：leader、follower、observer
服务的状态：
leading ：当前Server即为选举出来的leader
followering:leader已经选举出来，当前Server与之同步
observering：observer的行为在大多数情况下与follower完全一致，但是他们不参加选举和投票，而仅仅接受(observing)选举和投票的结果
looking：当前Server不知道leader是谁，正在搜寻
Zookeeper保证服务同步的原理：核心是原子广播，实现这个机制的协议叫做Zab协议； Zab协议的两种模式：
1、恢复模式（Recovery选主）：用于服务启动或者在领导者崩溃后，对新leader的选举，保证leader和Server具有相同的系统状态。为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。
2、广播模式（Broadcast同步）。
cap理论：
zookeeper用什么通信
zookeeper的选举机制
在开启服务的时候：
1、第一台开启，服务的编号为1，发起投票信息，由于其他机器没启动，没收到反馈的信息，服务1处于选举状态
2、第二台开启，开始自己投票，同时和之前的1服务交换结果，由于服务2大于服务1的编号，服务2胜出，但此时的投票数没大于半数，所以两个服务器的状态依然是LOOKING。
3、服务3启动，给自己投票，同时与之前的服务1，2交换信息，由于服务3的编号大于所有的服务，同时投票数大于半数（一共有5台服务器需要投票）
4、服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。
5、服务器5启动，后面的逻辑同服务器4成为小弟。
