初步认识分布式和集群

基本概念

分布式就是不同的业务模块部署在不同的服务器上或者同一个业务模块分拆多个子业务，部署在不同的服务器上，解决高并发的问题。

集群简单理解就是把单机复制几分，一起组成的就是集群。集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍。

初识NGINX

• 首先对NGINX有一个初步的了解，它是基于C语言开发的一款高性能的Web服务器软件，主要用于提供网上信息浏览服务，为高并发网站的应用场景而设计，可以在Linux、macOS和Windows等操作系统中运行，它的优点包括性能高、稳定性好、结构模块化、配置简单以及资源消耗非常低等。拥有HTTPS访问、gzip压缩、虚拟主机和URL重写等功能，不但可以搭配FastCGI程序处理动态请求，还可以用于代理、反向代理、负载均衡和缓存服务器等功能。
• 底层实现
  许多web服务器和应用服务器使用简单的线程的（threaded）、或基于流程的（process-based）架构， NGINX则以一种复杂的事件驱动（event-driven）的架构脱颖而出，这种架构能支持现代硬件上成千上万的并发连接。

NGINX是如何工作的?

NGINX使用一个了可预见式的（predictable）进程模型，调度可用的硬件资源：
　1. 主进程执行特权操作，如读取配置和绑定端口，还负责创建子进程(下面的三种类型)。
　2. 缓存加载进程（cache loader process）在启动时运行，把基于磁盘的缓存（disk-based cache）加载到内存中，然后退出。对它的调度很谨慎，所以其资源需求很低。　
　3. 缓存管理进程（cache manager process）周期性运行，并削减磁盘缓存（prunes entries from the disk caches），以使其保持在配置范围内。
　4. 工作进程（worker processes）才是执行所有实际任务的进程：处理网络连接、读取和写入内容到磁盘，与上游服务器通信等。
　多数情况下，NGINX建议每1个CPU核心都运行1个工作进程，使硬件资源得到最有效的利用。你可以在配置中设置如下指令： worker_processes auto，当NGINX服务器在运行时，只有工作进程在忙碌。每个工作进程都以非阻塞的方式处理多个连接，以削减上下文切换的开销。 每个工作进程都是单线程且独立运行的，抓取并处理新的连接。进程间通过共享内存的方式，来共享缓存数据、会话持久性数据（session persistence data）和其他共享资源。
　NGINX内部的工作进程
　每一个NGINX的工作进程都是NGINX配置（NGINX configuration）初始化的，并被主进程设置了一组监听套接字（listen sockets）。
　NGINX工作进程会监听套接字上的事件(accept_mutex和kernel socketsharding)，来决定什么时候开始工作。事件是由新的连接初始化的。这些连接被会分配给状态机（statemachine）—— HTTP状态机是最常用的，但NGINX还为流（原生TCP）和大量的邮件协议（SMTP，IMAP和POP3）实现了状态机。

• 主要功能
  1）进程和访问控制
  Nginx由一个主进程和多个工作进程组成，主进程接收客户端请求，再转交给工作进程处理，从而很好地利用多核心CPU的计算能力。
  
  Nginx的访问控制是网络安全防范和保护的主要策略，其任务是保证网络资源不被非法访问。
  2）日志记录功能
  Nginx提供了一个非常灵活的日志记录功能，它可以使每个块的配置拥有各自独立的日志进行记录，并且根据记录内容的不同又分为访问日志和错误日志。
  （1）访问日志用于记录客户端访问Nginx的每一个请求。记录用户的IP、访问时间、请求方式、响应状态、地域来源、跳转来源、使用终端等信息。
  （2）错误日志记录在访问Nginx时出错的记录，可以查看某个服务的性能瓶颈。
  3）虚拟主机技术
  虚拟主机技术是指一台物理主机服务器上划分出多个磁盘空间，每个磁盘空间都是一台虚拟主机，每台虚拟主机都可以独立对外提供Web服务，且互不干扰。
  利用虚拟主机可把多个不同域名的网站部署在同一台服务器上，而不必再为建立一个网站单独购买一台服务器，既解决了维护难题，又节省了硬件成本。
• 关于代理
  此时就涉及到两个角色，一个是被代理角色，一个是目标角色，被代理角色通过这个代理访问目标角色完成一些任务的过程称为代理操作过程；如同生活中的专卖店~客人到adidas专卖店买了一双鞋，这个专卖店就是代理，被代理角色就是adidas厂家，目标角色就是用户。
  1）正向代理
  代理也称为正向代理，是一个位于客户端和目标服务器之间的代理服务器，客户端将发送的请求和指定的目标服务器提交给代理服务器，然后代理服务器向目标服务器发起请求，并将获得的响应结果返回给客户端。正向代理模式屏蔽或者隐藏了真实客户端信息。
  
  2）反向代理
  反向代理对于客户端而言就是目标服务器，客户端反向代理服务器发送请求后，反向代理服务器将该请求转发给内部网络上的后端服务器，并从后端服务器上得到的响应结果返回给客户端。
  
  两种代理的特性有：安全性和功能性。
• 负载均衡
  将服务器接收到的请求按照规则分发的过程，称为负载均衡。
  Nginx支持的负载均衡调度算法方式如下：
  1.weight轮询（默认）：接收到的请求按照顺序逐一分配到不同的后端服务器，即使在使用过程中，某一台后端服务器宕机，Nginx会自动将该服务器剔除出队列，请求受理情况不会受到任何影响。 这种方式下，可以给不同的后端服务器设置一个权重值（weight），用于调整不同的服务器上请求的分配率；权重数据越大，被分配到请求的几率越大；该权重值，主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的。
  2**.ip_hash**：每个请求按照发起客户端的ip的hash结果进行匹配，这样的算法下一个固定ip地址的客户端总会访问到同一个后端服务器，这也在一定程度上解决了集群部署环境下session共享的问题。
  3.fair：智能调整调度算法，动态的根据后端服务器的请求处理到响应的时间进行均衡分配，响应时间短处理效率高的服务器分配到请求的概率高，响应时间长处理效率低的服务器分配到的请求少；结合了前两者的优点的一种调度算法。但是需要注意的是Nginx默认不支持fair算法，如果要使用这种调度算法，请安装upstream_fair模块。
  4.url_hash：按照访问的url的hash结果分配请求，每个请求的url会指向后端固定的某个服务器，可以在nginx作为静态服务器的情况下提高缓存效率。同样要注意Nginx默认不支持这种调度算法，要使用的话需要安装nginx的hash软件包。缺点（同ip_hash）：如果初始hash值相同，则会一直代理到同一台服务器上。
• 虚拟主机
  同一台服务器上可配置多个网站。
• WEB缓存方式
  利用反向代理服务器对访问频率较多的内容进行缓存，有利于节省后端服务器的资源。Nginx提供了两种Web缓存方式：永久性缓存和临时性缓存。
  永久性缓存：将内容源服务器响应的内容缓存到本地，若不手动删除，该缓存文件会一直生效。
  临时性缓存：采用md5算法将请求连接进行哈希后，根据具体配置生成缓存文件目录，保存响应的数据。
  Web缓存服务器位于内容源Web服务器和客户端之间，当客户端用户访问一个URL时，Web缓存服务器就会请求相应的内容源Web服务器，并将响应的信息缓存至内存或磁盘；然后，当下一个请求到来时，如果访问的是相同URL，Web缓存服务器会直接将已缓存的内容输出给客户端，而不用再次向内容源Web服务器发送请求。
  
  几种常用web服务器对比
  

Dubbo

• 概念
  Dubbo是一种分布式服务框架，它除了可以提供服务之外，还可以实现软负载均衡。它还提供了两个功能Monitor 监控中心和调用中心。这两个是可选的，需要单独配置。
  
  Consumer服务消费者，Provider服务提供者。Container服务容器。消费当然是invoke提供者了，invoke这条实线按照图上的说明当然同步的意思了，多说一句，在实际调用过程中，Provider的位置对于Consumer来说是透明的，上一次调用服务的位置（IP地址）和下一次调用服务的位置，是不确定的。这个地方就是实现了软负载。
  服务提供者先启动start，然后注册register服务。
  消费订阅subscribe服务，如果没有订阅到自己想获得的服务，它会不断的尝试订阅。新的服务注册到注册中心以后，注册中心会将这些服务通过notify到消费者。
  Monitor这是一个监控，图中虚线表明Consumer 和Provider通过异步的方式发送消息至Monitor，Consumer和Provider会将信息存放在本地磁盘，平均1min会发送一次信息。Monitor在整个架构中是可选的（图中的虚线并不是可选的意思），Monitor功能需要单独配置，不配置或者配置以后，Monitor挂掉并不会影响服务的调用。
  结合Dubbo官方文档，我们分别理解一下框架分层架构中，各个层次的设计要点：
  1.服务接口层（Service）：该层是与实际业务逻辑相关的，根据服务提供方和服务消费方的业务设计对应的接口和实现。
  2.配置层（Config）：对外配置接口，以ServiceConfig和ReferenceConfig为中心，可以直接new配置类，也可以通过spring解析配置生成配置类。
  3.服务代理层（Proxy）：服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory。
  4.服务注册层（Registry）：封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory、Registry和RegistryService。可能没有服务注册中心，此时服务提供方直接暴露服务。
  5.集群层（Cluster）：封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster、Directory、Router和LoadBalance。将多个服务提供方组合为一个服务提供方，实现对服务消费方来透明，只需要与一个服务提供方进行交互。
  6.监控层（Monitor）：RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory、Monitor和MonitorService。
  7.远程调用层（Protocol）：封将RPC调用，以Invocation和Result为中心，扩展接口为Protocol、Invoker和Exporter。Protocol是服务域，它是Invoker暴露和引用的主功能入口，它负责Invoker的生命周期管理。Invoker是实体域，它是Dubbo的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。
  8.信息交换层（Exchange）：封装请求响应模式，同步转异步，以Request和Response为中心，扩展接口为Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。
  9.网络传输层（Transport）：抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel、Transporter、Client、Server和Codec。
  10.数据序列化层（Serialize）：可复用的一些工具，扩展接口为Serialization、 ObjectInput、ObjectOutput和ThreadPool。
• 原理
  I、初始化过程细节：
  上图中的第一步start，就是将服务装载容器中，然后准备注册服务。和Spring中启动过程类似，spring启动时，将bean装载进容器中的时候，首先要解析bean。所以dubbo也是先读配置文件解析服务。
  解析服务：
  1）、基于dubbo.jar内的Meta-inf/spring.handlers配置，spring在遇到dubbo名称空间时，会回调DubboNamespaceHandler类。
  2）、所有的dubbo标签，都统一用DubboBeanDefinitionParser进行解析，基于一对一属性映射，将XML标签解析为Bean对象。
  源码截图：
  在ServiceConfig.export 或者ReferenceConfig.get 初始化时，将Bean对象转会为url格式，将所以Bean属性转成url的参数。
  然后将URL传给Protocol扩展点，基于扩展点的Adaptive机制，根据URL的协议头，进行不同协议的服务暴露和引用。
• Zookeeper实现服务注册与发现
  zookeeper的实际运用场景：
  场景一：统一命名服务

有一组服务器向客户端提供某种服务，我们希望客户端每次请求服务端都可以找到服务端集群中某一台服务器，这样服务端就可以向客户端提供客户端所需的服务。对于这种场景，我们的程序中一定有一份这组服务器的列表，每次客户端请求时候，都是从这份列表里读取这份服务器列表。那么这份列表显然不能存储在一台单节点的服务器上，否则这个节点挂掉了，整个集群都会发生故障，我们希望这份列表时高可用的。

高可用的解决方案是：这份列表是分布式存储的，它是由存储这份列表的服务器共同管理的，如果存储列表里的某台服务器坏掉了，其他服务器马上可以替代坏掉的服务器，并且可以把坏掉的服务器从列表里删除掉，让故障服务器退出整个集群的运行，而这一切的操作又不会由故障的服务器来操作，而是集群里正常的服务器来完成。这是一种主动的分布式数据结构，能够在外部情况发生变化时候主动修改数据项状态的数据机构。Zookeeper框架提供了这种服务。这种服务名字就是：统一命名服务，它和JavaEE里的JNDI服务很像。

场景二：分布式锁服务

当分布式系统操作数据，例如：读取数据、分析数据、最后修改数据。在分布式系统里这些操作可能会分散到集群里不同的节点上，那么这时候就存在数据操作过程中一致性的问题，如果不一致，我们将会得到一个错误的运算结果，在单一进程的程序里，一致性的问题很好解决，但是到了分布式系统就比较困难，因为分布式系统里不同服务器的运算都是在独立的进程里，运算的中间结果和过程还要通过网络进行传递，那么想做到数据操作一致性要困难的多。Zookeeper提供了一个锁服务解决了这样的问题，能让我们在做分布式数据运算时候，保证数据操作的一致性。

场景三：配置管理

在分布式系统里，我们会把一个服务应用分别部署到n台服务器上，这些服务器的配置文件是相同的(例如：我设计的分布式网站框架里，服务端就有4台服务器，4台服务器上的程序都是一样，配置文件都是一样)，如果配置文件的配置选项发生变化，那么我们就得一个个去改这些配置文件，如果我们需要改的服务器比较少，这些操作还不是太麻烦，如果我们分布式的服务器特别多，比如某些大型互联网公司的hadoop集群有数千台服务器，那么更改配置选项就是一件麻烦而且危险的事情。

这时候zookeeper就可以派上用场了，我们可以把zookeeper当成一个高可用的配置存储器，把这样的事情交给zookeeper进行管理，我们将集群的配置文件拷贝到zookeeper的文件系统的某个节点上，然后用zookeeper监控所有分布式系统里配置文件的状态，一旦发现有配置文件发生了变化，每台服务器都会收到zookeeper的通知，让每台服务器同步zookeeper里的配置文件，zookeeper服务也会保证同步操作原子性，确保每个服务器的配置文件都能被正确的更新。

场景四：为分布式系统提供故障修复的功能

集群管理是很困难的，在分布式系统里加入了zookeeper服务，能让我们很容易的对集群进行管理。集群管理最麻烦的事情就是节点故障管理，zookeeper可以让集群选出一个健康的节点作为master，master节点会知道当前集群的每台服务器的运行状况，一旦某个节点发生故障，master会把这个情况通知给集群其他服务器，从而重新分配不同节点的计算任务。Zookeeper不仅可以发现故障，也会对有故障的服务器进行甄别，看故障服务器是什么样的故障，如果该故障可以修复，zookeeper可以自动修复或者告诉系统管理员错误的原因让管理员迅速定位问题，修复节点的故障。大家也许还会有个疑问，master故障了，那怎么办了？zookeeper也考虑到了这点，zookeeper内部有一个“选举领导者的算法”，master可以动态选择，当master故障时候，zookeeper能马上选出新的master对集群进行管理。

• zookeeper的特点
  zookeeper是一个精简的文件系统。zookeeper这个文件系统是管理小文件的。
  　　zookeeper提供了丰富的“构件”，这些构件可以实现很多协调数据结构和协议的操作。例如：分布式队列、分布式锁以及一组同级节点的“领导者选举”算法。
  　　zookeeper是高可用的，它本身的稳定性是相当之好，分布式集群完全可以依赖zookeeper集群的管理，利用zookeeper避免分布式系统的单点故障的问题。
  　　zookeeper采用了松耦合的交互模式。这点在zookeeper提供分布式锁上表现最为明显，zookeeper可以被用作一个约会机制，让参入的进程不在了解其他进程的(或网络)的情况下能够彼此发现并进行交互，参入的各方甚至不必同时存在，只要在zookeeper留下一条消息，在该进程结束后，另外一个进程还可以读取这条信息，从而解耦了各个节点之间的关系。
  　　zookeeper为集群提供了一个共享存储库，集群可以从这里集中读写共享的信息，避免了每个节点的共享操作编程，减轻了分布式系统的开发难度。

zookeeper的设计采用的是观察者的设计模式，zookeeper主要是负责存储和管理大家关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper 就将负责通知已经在 Zookeeper 上注册的那些观察者做出相应的反应，从而实现集群中类似 Master/Slave 管理模式。

• zookeeper集群机制
  半数机制：集群中半数以上机器存活，集群可用。
  zookeeper集群适合搭建在奇数台机器上。
• zookeeper特性
  Zookeeper：一个leader，多个follower组成的集群
  全局数据一致：每个server保存一份相同的数据副本，client无论连接到哪个server，数据都是一致的
  分布式读写，更新请求转发，由leader实施
  更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行
  数据更新原子性，一次数据更新要么成功，要么失败
  实时性，在一定时间范围内，client能读到最新数据
• zookeeper原理及内部选举机制
  原理：zookeeper在配置文件中并没有指定master和slave，但是，zookeeper在工作时，只有一个节点为leader，其余节点为follower，leader是通过内部的选举机制临时产生的。
  选举机制：（两种情况）

（1）全新集群paxos

假设有五台服务器组成的zookeeper集群,它们的id从1-5,同时它们都是最新启动的,也就是没有历史数据,在存放数据量这一点上,都是一样的.假设这些服务器依序启动,来看看会发生什么.
　　1) 服务器1启动,此时只有它一台服务器启动了,它发出去的报没有任何响应,所以它的选举状态一直是LOOKING状态
　　2) 服务器2启动,它与最开始启动的服务器1进行通信,互相交换自己的选举结果,由于两者都没有历史数据,所以id值较大的服务器2胜出,但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3),所以服务器1,2还是继续保持LOOKING状态.
　　3) 服务器3启动,根据前面的理论分析,服务器3成为服务器1,2,3中的老大,而与上面不同的是,此时有三台服务器选举了它,所以它成为了这次选举的leader.
　　4) 服务器4启动,根据前面的分析,理论上服务器4应该是服务器1,2,3,4中最大的,但是由于前面已经有半数以上的服务器选举了服务器3,所以它只能接收当小弟的命了.
　　5) 服务器5启动,同4一样,当小弟.

（2）非全新集群（数据恢复）
初始化的时候，是按照上述的说明进行选举的，但是当zookeeper运行了一段时间之后，有机器down掉，重新选举时，选举过程就相对复杂了。

需要加入数据id、leader id和逻辑时钟。

数据id：数据新的id就大，数据每次更新都会更新id。

Leader id：就是我们配置的myid中的值，每个机器一个。

逻辑时钟：这个值从0开始递增,每次选举对应一个值,也就是说: 如果在同一次选举中,那么这个值应该是一致的 ; 逻辑时钟值越大,说明这一次选举leader的进程更新.

选举的标准就变成：

1、逻辑时钟小的选举结果被忽略，重新投票

2、统一逻辑时钟后，数据id大的胜出

3、数据id相同的情况下，leader id大的胜出
根据这个规则选出leader。