目标ZooKeeper很流行，有一个基本的问题：ZooKeeper是用来做什么的？之前没有ZK，为什么会诞生ZK？OK，我来回答上面的问题：（以下是凭直觉）ZooKeeper用于简化分布式应用的开发，屏蔽开发者对分布式应用开发过程的底层细节。ZooKeeper暴露了简单的API，支持分布式应用开发ZooKeeper是一个高性能、高可用、高可靠的分布式集群，同时提供上述功能解决问题。至此，多了一个疑问：分布式应用开发中常见的问题有哪些？ZK是如何屏蔽这些底层细节的呢？ZooKeeper对外暴露了哪些API？这些API如何支持分布式应用程序开发？这些API可以简化吗？API的语义如何？ZooKeeper本身就是一个高性能、高可用、高可靠的分布式集群，那么有一个简单的问题：高性能是什么意思？ZooKeeper做了什么来实现高性能？HighAvailabilityDittoHighReliabilityDitto为什么会有ZooKeeper应用，当涉及多个进程协作时，业务逻辑代码中混杂着大量复杂的进程协作逻辑。上述多进程协作逻辑有两个特点：复杂的处理逻辑可以复用。因此，考虑将多进程协同的共性问题作为基础设施，让RD更专注于业务逻辑开发，即：ZooKeeper是上述多进程协同的基础服务的一类。ZooKeeper的特性ZooKeeper有几个简单的特性：ZooKeeperAPI：受文件系统API的启发，它提供了一个简单的API。ZooKeeper运行在专用服务器上，与业务逻辑分离，保证了高容错性和可扩展性。ZooKeeper是一个存储设施，但要特别注意ZK上存储数据的重点：协作数据（元数据）而不是应用数据。应用数据有自己的存储方案，比如HDFS等ZK。从本质上讲，它可以看作是一个特殊的FS。特别说明：应用数据和元数据因使用场景不同，对一致性和持久化有不同的要求。因此，在架构设计和数据治理过程中，应该将两类数据独立对待和存储。ZooKeeper的使命ZK要解决的核心问题：ZK目标：简化分布式应用开发中的多进程协作问题。针对分布式应用，提供高效可靠的分布式协调服务（基础服务），如：统一命名服务、分布式锁进程崩溃检测、leader选举配置管理：当配置发生变化时，及时发送给各个客户端。一个简单的问题：什么是多进程协作？尼玛，没完没了，你有各种各样的问题，面对这个疯脑袋，我来解答吧。多进程协作可以分为2类：协作：多个进程需要共同处理某些事情，一些进程采取行动，使其他进程能够正常工作。比如：主从结构，M给S分配任务，S来执行。否则，S会保持空闲并竞争：两个进程不能同时工作，一个进程必须等待另一个进程执行完，例如：主从结构，M节点故障后，很多S想变成M，这时候就需要互斥锁，只有第一个获得锁的S变成M特别说明：不能跨网协同：多进程，可以在同一台物理主机上，同步原语很方便（比如pipes,sharedmemory,messagequeues,semaphores）跨网络协作：多进程，分布在不同的物理主机上，ZK专注于这种跨网络多进程协作，进程通信，有两个基本思想：消息机制：通过网络，直接信息交换，多消息传递算法，实现同步原语共享存储：利用外部共享存储实现多进程协作，需要共享存储提供有序访问。ZK就采用了这种方式。在实际系统中，跨网络通信存在几个常见的问题：消息延迟：由于网络原因，延迟发送，先到达处理器性能：由于系统调度原因，消息到达后，延迟处理Clockoffset：不同物理主机，clockoffsetZK精心设计屏蔽了以上三个常见问题，让这些问题在Layer之间是完全透明的。ZooKeeper特性ZooKeeper解决的本质问题分布式系统的一致性问题：消息传递：延迟，先发送的消息不一定先到达；消息传递：丢失，发送的消息可能丢失；节点崩溃：分布式系统任何节点都可能崩溃；在这种情况下，如何保证数据的一致性呢？提案投票：基于投票策略，2PC选举投票：基于投票策略，投票给优先级最高的节点（包含最新数据的节点）Paxos目标：解决分布式一致性问题，改进分布式系统的共识算法容错。Paxos的本质：一种基于消息传递的高容错共识算法ZooKeeper定位ZooKeeper是：分布式协调服务高效、可靠、方便应用程序，专注于业务逻辑开发而无需过多关注分布式交互细节进程协作ZooKeeper没有直接暴露Primitives，而是暴露了一部分由调用方法组成的API，类似于文件系统API，允许应用程序实现自己的原语。ZooKeeper特性ZooKeeper可以保证以下分布式一致性特性：顺序一致性：同一Client发起的事务请求严格按照发起顺序执行。原子性：事务请求要么应用到所有节点，要么一个节点不应用单个视图：无论Client连接到哪个节点，看到的服务器数据都是一致的（注：不准确，其实是最终一致性)可靠性：一旦事务执行成功，状态永久保持实时：不能立即看到最新数据，但ZooKeeper保证最终一致性ZooKeeper设计目标ZooKeeper致力于提供高性能，高可用，和顺序一致的分布式协调服务，保证数据的最终一致性。目标一：高性能（简单数据模型）使用树结构组织数据节点；所有数据节点都存储在内存中；Follower和Observer直接处理非事务性请求；目标二：过半机器的高可用（搭建集群）如果存活下来，服务就可以正常运行。领导人选举将自动进行。目标3：顺序一致性（交易操作的顺序）每个交易请求都会转发给Leader处理每个交易，并分配一个全局唯一的增量id（zxid，64位：epoch+auto-incrementid）目标4:FinalConsistency通过提议的投票方式，保证交易提交的可靠性。所提出的投票方式只能保证Client收到交易提交成功后，超过半数的节点可以看到最新的数据。在ZooKeeper出现之前的ZK在出现之前，分布式系统常用两种方式来实现多进程协作：分布式锁管理器分布式数据库ZK更侧重于进程协作，不提供任何锁接口或通用存储数据接口。（问题：ZK也可以提供，我们只是不需要）应用服务器，两个常见的需求：Master-SlaveLeaderelection：需要Master节点选举功能ProcessresponsetrackingCrashdetection：需要process的trackingdistribution生存状态类型锁：互斥锁和排它锁ZK为以上两种策略提供了基础API。ZooKeeper不适用的场景：海量数据存储：ZK本质上是一种特殊的FS，但ZK是用来存储元数据的，应用数据需要单独存储。技术术语介绍文章来源：http://ningg.top/zookeeper-po...
