zookeeper（1）

分布式环境特点

• 分布性
  各个节点可以分布在任一一个地点。可以在一个机房或多个机房，甚至多个城市。

• 并发性
  同一个分布式系统中的多个节点，同时访问一个共享资源。数据库、分布式存储（基于多进程）

• 无序性
  进程之间发送的消息，在接到的顺序有可能不一致。（网络问题）

分布式环境下的问题

• 网络通信
  服务是分布在不同的机器上 ， 每次交互都需要跨机器操作，就会出现以下问题。
  1）网络延迟
  同机房内的网络通信还是比较快的，当出现跨机房操作，io就会出现性能呢个问题，频繁的rpc操作，会带来超时等，这时一般会采用异步访问，失败重试等。
  2）网络丢包

• 网络分区（脑裂，双主问题）
  当出现集群中的部分节点不可用（节点请求压力较大，导致其他节点与该节点的心跳检测不可用），那么这些部分节点会重新选举出一个master，造成原本的集群会同时存在多个master节点。
  

  原本这个集群中有4个slave节点，当有2个slave节点出现不可用时，这2个节点就脱离出这个master，就会重新选举出一个master。集群中就出现两个master，这时会出现数据重复。
  

• 三态
  在分布式架构里面，除了成功、失败，还有一个超时（出现网络故障，客户端一直没收到消息）

• 分布式事务
  ACID(原子性、一致性、隔离性、持久性)

中心化和去中心化
中心化：领导需要管理5个码农，领导需要监督6个码农的任务，当一个码农病倒了，他就会把这个码农踢出去，将任务分配给其他的码农。（master，slave）
当领导病倒了。
冷备：有一个备用领导（未激活状态），当一个领导病倒了，这个备用领导会立即启动。
热备：当一个领导病倒了，立即选举出一个领导。

去中心化：没有领导和码农的角色，架构是水平的。部分节点出现问题时，不会导致别的节点出现问题。（解决脑裂）。

分布式架构里面，很多的架构思想采用的是：当集群发生故障的时候，集群中的人群会自动“选举”出一个新的领导。
zookeeper，etcd

CAP
C（一致性 Consistency）：所有的节点上的数据，时刻保持一致。
当一个写请求落到master上，他会将数据同步到slave节点上，这个会出现网络延迟等。，不能时刻保证数据一致。
A （可用性Availability）：每个请求都能够收到一个响应，无论响应成功或者失败。（发出去消息，都能收到响应）
P （分区容错Partition-tolerance）：表示系统出现脑裂以后，可能导致某些server与集群中的其他机器失去联系。
不能同时满足，最多只能满足一个。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。
系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

CAP理论仅适用于原子读写的Nosql场景，不适用于数据库系统
BASE
基于CAP理论，CAP理论并不适用于数据库事务（因为更新一些错误的数据而导致数据出现紊乱，无论什么样的数据库高可用方案都是
徒劳） ，虽然XA事务可以保证数据库在分布式系统下的ACID特性，但是会带来性能方面的影响；

eBay尝试了一种完全不同的套路，放宽了对事务ACID的要求。提出了BASE理论

Basically available ： 数据库采用分库模式， 把100W的用户数据分布在5个数据库上。如果破坏了其中一个数据库，仍然可以保证
其余四个数据库的用户可用。

soft-state： 在基于client-server模式的系统中，server端是否有状态，决定了系统是否具备良好的水平扩展、负载均衡、故障恢复等特性。
Server端承诺会维护client端状态数据，这个状态仅仅维持一小段时间, 这段时间以后，server端就会丢弃这个状态，恢复正常状态

Eventually consistent：数据的最终一致性

1）用户下订单到支付时，状态都是处理中（短时间内有这个处理中间状态）
2） 支付成功后，异步通知，状态变成成功（保证最终的一致性）。

---

初步认识zookeeper

zookeeper能做什么

• 数据的发布/订阅（配置中心:disconf）
• 负载均衡（dubbo利用了zookeeper机制实现负载均衡）
• 命名服务
• master选举(kafka、hadoop、hbase)
• 分布式队列
• 分布式锁

zookeeper的特性

• 顺序一致性
  从同一个客户端发起的事务请求，最终会严格按照顺序被应用到zookeeper中

• 原子性
  所有的事务请求的处理结果在整个集群中的所有机器上的应用情况是一致的，也就是说，要么整个集群中的所有机器都成功应用了某一事务、
  要么全都不应用。

• 可靠性
  一旦服务器成功应用了某一个事务数据，并且对客户端做了响应，那么这个数据在整个集群中一定是同步并且保留下来的

• 实时性
  一旦一个事务被成功应用，客户端就能够立即从服务器端读取到事务变更后的最新数据状态；（zookeeper仅仅保证在一定时间内，近实时）

zookeeper安装

准备好两个虚拟机。192.168.152.136，192.168.152.137

• 单机环境
  1） 下载zookeeper的安装包
  http://apache.fayea.com/zookeeper/stable/zookeeper-3.4.10.tar.gz
  2） 解压zookeeper
  tar -zxvf zookeeper-3.4.10.tar.gz
  3）cd zookeeper-3.4.10/conf/
  cp zoo_sample.cfg zoo.cfg
  4）sh zkServer.sh
  {start|start-foreground|stop|restart|status|upgrade|print-cmd}
  5) sh zkCli.sh -server localhost:2181
  sh zkCli.sh -server ip:port
• 集群环境
  角色
  leader:接受所有follower的请求并统一分配任务，负责与所有的follower进行数据交换（同步）
  follower：负责leader转发过来的请求，并且参与leader投票，同时与leader进行数据同步
  observer：与leader进行数据同步，但不参与leader投票。

192.168.152.136
192.168.152.137

1）每台服务器都按照上面单机模式装好。
2) vim zoo.cfg
server.1=192.168.152.136:2888:3181
server.2=192.168.152.137:2888:3181
2888 : 表示follower节点与leader节点交换信息的端口号
3181 :如果leader节点挂掉了, 需要一个端口来重新选举。
3）创建myid
在每一个服务器的dataDir目录下创建一个myid的文件，文件就一行数据，数据内容是每台机器对应的server ID的数字
4）关闭每台服务器的防火墙 systemctl stop firewalld.service
5）启动每个机器的zookeeper
sh zkServer.sh start
6）利用sh zkServer.sh status

192.168.152.136是follower
192.168.152.137是leader

 //192.168.152.136显示  ZooKeeper JMX enabled by default  Using config: /data/zookeeper/zookeeper-  3.4.10/bin/../conf/zoo.cfg  Mode: follower //192.168.152.137显示 ZooKeeper JMX enabled by default Using config: /data/zookeeper/zookeeper-3.4.10/bin/../conf/zoo.cfg Mode: leader

ps -ef|grep zookeeper

分析

客户端的写请求都会发送到leader节点
客户端的读请求会根据算法落到follower节点

• 顺序性
  当客户端发生请求a->b->c->d,都会严格按照这个顺序应用到zookeeper上。

• 原子性
  客户端发起一个写操作落到leader，leader会数据同步到follower，大于一半的follower成功后，会返回给leader节点。

leader选举是通过zab协议选举的。