分布式

分布式：基于多台机器的资源，从逻辑上合并为一个整体，对外提供一个统一的服务。

分布式存储：磁盘（外存）+内存条（内存）。
分布式计算：CPU+内存条。

集群：构建多台机器，一般指代机器硬件。

分布式一定有集群（虚拟机和云主机可以视为模拟出来的硬件），集群（如机房的一大坨裸金属服务器）不一定是分布式服务。

功能

如果某1s有100w请求，服务器的处理速度是5w/s，假设不会宕机，但是要处理20多秒，性能表现极差。

如果持续有100w/s请求，服务器还是5w/s，会出现宕机的状况。

如果可以多台服务器均衡负载，就可以解决这些问题。

故分布式的功能主要就是：

单机资源不足以满足需求：可以避免应用故障。
单机资源可以满足需求，但性能较差：可以实现高并发，提高性能。

企业中有管理成本，同理，分布式的服务器也有沟通交流成本，分布式集群的性能一定不如单机性能累加之和，但有的代价不得不付。

在正向代理中，服务端不知道真正的客户端是谁（咳咳，科学上网）。而在反向代理中，可以用Nginx转发给Tomcat服务器，采用取模、轮询等多种方式实现负载均衡，这种情况下，客户端不知道真正的服务端是谁，分布式集群大概率对外只暴露1个IP。

设计思想

先分后合，分而治之。

分：将单机性能不足以支撑的大任务拆分成多个小任务，由分布式集群中的每个节点各自完成自己的小任务，每个小任务结束后会得到一个小结果。

合：将所有小任务各自的小结果合并为最终的大结果。

分布式架构

分布式主从架构

绝大多数分布式是分布式主从架构。类似组织中的管理层与执行层（可能还有类似决策层的更高层级）。

主节点Master：
管理节点的死活，管理任务的分配，管理元数据，接客（接收客户端请求），类似部门的经理。

从节点Worker：
负责利用自己所在机器的资源实现主节点分配的小任务。类似部门的职员。

单点故障及解决

如果从节点故障，不会影响对外提供的分布式业务（除非从节点全部阵亡）。就像厂里的机修部门少了谁也照样转，机修老狮虎们的可替代性很强。

如果主节点故障，可能影响任务分配等行为，也就可能影响到对外提供的分布式业务。这种情况下，如果主节点只有一个，一旦主节点故障，整个分布式集群就不可用。这就像经理出差，厂里的机修老狮虎们放了🐏。。。

所以主节点不能只有一个，必须构建多个主节点，一个主节点故障时还能有其它主节点顶上。作为部门老大级别的主节点，当然也不能同时有多个一起工作（不能同时进行决策），只能有1个主节点工作（Active状态），其它主节点替补（Standby备份状态）。Active状态的主节点故障时，Standby状态的主节点就会竞选，出现新的Active状态主节点。

ZooKeep

概述

Hadoop生态圈是个动物园（zoo），有各种动物：大象Hadoop，🐖猪pig，🐝蜜蜂Hive，松鼠Flink，虎鲸HBase、鹿🦌Impala、麒麟Kylin。。。

动物园需要管理员，也就是Zookeeper。

分布式架构中，决定多个Master中谁可以Active（剩下的都是Standby）的时候，就需要一个共享的外部存储来解决选举的问题。很多时候也需要共享存储。ZooKeeper的本质就是一种特殊的外部存储系统，提供数据的读写。

功能

存储共享数据（元数据），辅助选举，分布式锁，命名空间。

应用场景

存储共享核心元数据，辅助选举Active的Master。

架构

分布式主从架构，主节点Leader对外提供读写，从节点Follower对外提供读（写的请求会转发给Leader）。

设计

ZooKeeper是公平节点架构。

Follower有故障，还有别的Follower，不会影响功能。

Leader有故障，剩余的Follower会选举出一个新的Leader。ZooKeeper中每个节点存储的内容是一致的，写入数据只能写入Leader节点，Leader会同步给所有的Follower节点（同步超过半数，才代表写入成功）。可以看出ZooKeeper自己首先保证了自己不会出问题，才能协调其它分布式框架。