zookeeper基础

0.介绍：分布式协调系统。类似于linux文件系统的数据存储结构！！！
a)选举leader端口：3888，数据通讯端口：2888,默认客户连接端口：2181.
b)剩余节点总数大于总数据的1/2时，才正常运行
c)选择leaderf规则（二阶段/2pc提交）：
d)一些名词：leader,follow,leading,following,ZNode,Watcher.
e)leader==》读写，follower==>只负责读
1.Zookeeper安装（先安装java）有三种方式：安装的数量建议是单数。
单机模式/standalone：Zookeeper运行一台机器上
伪集群模式：一台物理机上运行多个zookeeper实例
集群模式：Zookeeper运行一个集群上，适合生产环境
2.布置standalone模式：
a)修改环境：增加zk_home路径;增加bin目录路径
ZOOKEEPER_HOME=/usr/local/zookeeper-3.4.14
export ZOOKEEPER_HOME
PATH=$ZOOKEEPER_HOME/bin:$PATH
export PATH
b)修改配置文件：修改数据保存路径;指定ZK的主机;指定主机的myid.
dataDir=/usr/local/zookeeper-3.4.14/tmp
server.1=zk_31:2888:3888
vi /usr/local/zookeeper-3.4.14/tmp/myid
//输入1，与配置文件中的server.1对应
c)启动
zkServer.sh start
d)使用
zkServer.sh status//查看状态，stop,关闭
zkCli.sh //不加参数，默认登录本机zk
ls / //查根节点,允许多个根节点
ls /mydata //查看mydata节点下的子节点
create /mydata helloworld //创建/mydata节点，数据是helloworld

3.应用：
a)分布式锁（与redis实现的区别，setnx）
b)负载均衡:利用树形数据结构和watch原理，自己代码实现
4.一致性：
a)强一致性：当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。在分布式中，一般是实现不了的，所以在单体应用层中，可以使用更新锁或者插入锁，当查询时必须等解锁后才能读到数据。
b)弱一致性： 系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。大多数分布式都是如此，存在脏数据，需要优化。
c)最终一致性：对弱一致性的优化结果。
弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。
最终一致性的解决方案有:MQ(发布订阅消息,队列消息),分布式事务(要不全部成功,要不全部失败,也是首先基于mq的发布订阅事务消息实现),还有补偿模式,校对模式,缓存一致性模式

---

附多节点配置：
在每台节点的配置上增加
“`
server.1=zk_31:2888:3888
server.2=zk_32:2888:3888
server.3=zk_33:2888:3888

myid文件的内容分别为1，2，3
“`