分布式-Zookeeper介绍

ZK具体安装步骤见：https://www.cnblogs.com/xin-xing/p/13109655.html

分布式和微服务的关系

微服务更多强调不同业务服务放在不同物理机上实现相互调用，是一种特殊的分布式。

分布式更多强调相同服务放在不同物理机上实现集群部署。

分布式的缺点

1.分布式session问题

解决方案：

session粘滞：用户访问集群中的某台设备后，强制后续所有请求都落在这台机器。

• 使用场景：机器数量适中、不适合对稳定性要求较高的系统
• 优点：实现简单、配置方便、没有额外网络开销
• 缺点：集群中有机器Down掉，用户session会丢失、容易造成单点故障
• 技术：Nginx的ip_hash负载均衡方案

session复制：将一台机器的session广播到其他机器

• 使用场景：机器数量较少，网络流量较少
• 优点：实现简单、配置方便、集群中有机器Down掉不影响客户访问
• 缺点：广播复制存在一定延时，有网络开销
• 技术：tomcat-redis-session-manager

session缓存集中管理：将session内容直接放到某个机器集中管理，当用户访问不同节点时从缓存中取session

• 使用场景：集群数量多，网络环境复杂
• 优点：可靠性好
• 缺点：实现复杂，稳定性依赖缓存稳定性，session信息存入缓存要有写入策略
• 技术：redis、spring-session

2.分布式配置问题

多台机器配置文件（如：线程池、数据库配置）需要多份，一个配置修改需要改多个地方，使用需要统一管理方便后期维护

解决方案：

etcd：CoreOS开源，轻量级分布式key-value数据库。可以为集群提供发现注册服务、管理节点状态，提供TTL数据失效时间、数据改变监控、多值、目录监听、分布式锁操作。

zookeeper：后续说

3.分布式的事务管理

4.分布式锁

解决方案：

mysql的行级锁和表级锁机制，不推荐使用。

内存数据库：redis分布式锁

etcd分布式锁、zookeeper分布式锁

5.分布式定时任务

定时任务只需要某个机器运行，由于分布式服务每台机器上都有定时任务代码，这事就会跑多次，这时我们不需要的。如果单机部署，一旦部署机器Down掉，则定时服务不执行。

解决方案：Elastic-job是当当网基于Quartz二次开发的弹性分布式任务调度系统，采用zookeeper实现分布式协调，实现任务高可用及分片。

 

Zookeeper介绍

Zookeeper可以理解为一个数据库，这个数据库存储的数据类型是树型目录结构。

Zookeeper中服务端集群的角色

领导者（Leader）：负责进行投票的发起和决议，大于半数成为Leader，最终更新状态

跟随者（Follower）：可以接收客户端请求并返回客户端，参与Leader投票

观察者（Observer）：可以接收客户端链接，将写请求转发给Leader节点，但不参与Leader投票

客户端写请求流程

0）Client发送写请求

1）收到的所有写请求都转发给Leader

2）向Follower发送提议

3）Follower收到提议后，向Leader返回ack表示收到，Leader收到半数以上回复（加上自己）表示数据可以写入

4）向Follower和Observer发送commit数据

如上图可知，Leader、Follower、Observer无论哪个角色，都有存储完整的数据，所有如果是Client的读请求，那么4个节点都可以为Client直接响应

 

Observer的作用：1）为Follower分担读请求；2）不参与投票，提高写请求的操作速度

如果是Observer节点，在集群node1、node2、node3、node4所有节点zoo.cfg配置文件中需要加红色字内容

tickTime = 2000
initLimit = 10
syncLimit = 5
dataDir = $zookeeper_path/data #数据所在目录
dataLogDir = $zookeeper_path/datalog #数据日志所在目录
peerType = observer #只有是observer中才配置这个，不是observer的不用加这个配置
server.1 = node1:2888:3888 #2888集群内部同步端口，3888投票端口
server.2 = node2:2888:3888
server.3 = node3:2888:3888
server.4 = node4:2888:3888:observer