Zookeeper--产生原因及功能

1、分布式存在的问题

• 问题一：大的任务一台机器解决不了
  • 40TB文件
  • 普通一台机器：32TB，无法存储
• 问题二：即使一台机器能解决，但是性能比较差
  • 40TB文件：写速度1s/1TB
  • 特殊一台机器：64TB，可以存储40s
  • 分布式集群存储：16TB x 4 台，总共64TB ，可以存储10s：高并发的
• 解决：分布式
  • 通过分布式的资源整合，将存储或者计算交给多台机器并行处理
  • 分布式存储：利用多台机器的硬盘进行整体，作为一个整体
  • 分布式计算：利用多台机器的CPU和内存作为一个整体
  • 分布式网站：利用多台机器的web容器均衡的负载，作为一个网站服务的整体
• 大数据中：越快越好
  • 数据的价值会随着时间的流逝而逐渐降低
• 分布式本身存在的问题
  
• node4宕机了 ，主服务就没有了
  • 整个分布式集群就瘫痪了
  • 没有服务能接受请求以及管理所有的任务
• 如果产生了两个主服务怎么办？
  • 如果同一时刻出现了 两个主服务，功能一模一样，客户端请求谁？谁来负责管理？
• 在这样的分布式架构中，如果我们需要更改代码的配置怎么办？
  • 总共有100台机器
  • 如果不做分布式管理：就需要手动替换100台机器的代码
• 即使我们将代码都更改了，如何保证这100台机器的代码配置是一样的？
• 假设：100台机器的代码配置的JDBC连接属性都必须是一致的
  • 突然，公司要更换数据库集群，地址发生改变，需要修改jdbc配置
• 问题
  • 数据一致性问题
  • 分布式同步锁问题
  • 单节点故障

2、Zookeeper的设计思想

基于分布式架构的树形文件系统

• 只用于存储关键性的数据，不用于存储大数据
• 类似于索引数据、配置信息等等
  • 索引：类似于新华字典的目录
    • 你想查找一个字，如果没有目录，你要一页一页翻
    • 如果有目录，根据规则找到这个字所在那一页，快速找到这个字
• 为别的分布式服务提供服务

3、Zookeeper的功能

一致性服务

存放共同配置

• 将所有重要的可能产生变化的配置存储在Zookeeper中
• 所有的分布式节点，在需要读取这个配置的时候，直接从Zookeeper中读取这个配置
• 如果要修改，只要更改Zookeeper中的配置即可

注册中心

• 所有功能相同的服务节点，都要向zookeeper进行注册，才能实现应用

命名服务

构建整体，统一入口

• 将统一功能节点构建一个统一的命名，作为一个整体，在zookeeper中将两个主服务构建成一个整体
• 等客户端请求的时候，先请求zookeeper，zookeeper中会记录谁是工作的，谁是备份的，将请求转发给工作状态的节点

分布式锁

• 两个主服务
• 如果有一个主服务是工作状态的，另一个主服务能不能是工作状态的？
  • 不能
• 所有的主服务向Zookeeper进行注册，并且参加选举，会选举出一个工作的主服务，一旦选举成功
• 其他的主服务是不允许作为工作状态的，只能成为备份状态
  选举的过程
• 第一种方式：抢注谁创建成功，谁就是主服务临时节点
  • 所有的主服务都会一起到zookeeper中创建一个文件
  • 谁创建成功，谁就是工作状态，其他的就是备份状态
    
• 第二种方式：排号大家都创建一个文件，这个文件按照创建的先后顺序编号，谁的编号最小，谁就是工作状态，其他的是备份状态有序临时节点
• 备份的什么时候会自动变成工作状态呢？
  • 所有的备份服务都会监听工作状态所创建的那个文件
  • 如果工作状态的服务故障了，这个文件会自动消失
  • 如果这个文件自动消失，那么所有的备份服务会重新选举

选举

• 保证集群中选举出一个工作的主服务
• 如果工作的主服务故障了，要从多个备份的主服务中选举出一个新的工作主服务

数据发布订阅

• 将一些关键性的数据，很多程序都想要的数据存储在Zookeeper中
• 生产者：负责往Zookeeper中写入数据
• 消费者：负责从Zookeeper中读取数据

总结

• 统一化的数据一致性：关键性的数据共享的数据保持一致
• 注册中心
• 选举：谁是主节点?帮别的工具中的服务选举
• 命名服务:请求谁?
• 分布式锁:不能同时是主节点啊?