分布式理论

=======本文转载至拉钩训练营--第三阶段模块一分布式原理========

分布式系统概念：

    分布式系统是一个硬件活软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统

分布式与集群的区别：

    集群：多个人在一起做同样的事

    分布式：多个人在一起做不同的事

分布式系统的特点：

   分布性、对等性、并发性、缺乏全局时钟、故障总会发生

分布式架构的演变：

 

 

 

分布式系统面临的问题

    1、通信问题

          因为网络本身的不可靠性，每次网络通信都会伴随着网络不可用的风险，可能会导致分布式系统无法顺利进行网络通信

    2、网络分区

          如果网络之间出现不连通，但各个子网络的内部网络是正常的，导致整个系统的网络环境被切分成若干个孤立的区域，分布式系统就会出现局部小集群，这些小集群有可能会独立完成原本需要整个分布式系统才能完成的功能，包括数据的事务处理，这就对分布式一致性提出非常大的挑战

    3、节点故障

          分布式系统的服务器节点出现宕机或“僵死”现象

    4、三态

          分布式系统每次请求与响应存在特有的“三态”概念，成功、失败、超时。

 

分布式理论：一致性

    分布式数据一致性，指的是数据在多份副本中存储时，各副本中的数据是一致的。

       暂时没有找到一种能够满足分布式系统所有系统属性的分布式一致性解决方案。因此，如何既保证数据 的一致性，同时又不影响系统运行的性能，是每一个分布式系统都需要重点考虑和权衡的。

 

一致性分类

     1、强一致性

           这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往 对系统的性能影响大。但是强一致性很难实现

     2、弱一致性

           这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致， 但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态

     3、读写一致性

           用户读取自己写入结果的一致性，保证用户永远能够第一时间看到自己更新的内容

           解决方案:

           方案1：一种方案是对于一些特定的内容我们每次都去主库读取。 （问题主库压力大）

           方案2：我们设置一个更新时间窗口，在刚刚更新的一段时间内，我们默认都从主库读取，过了这个窗口之后，我们会挑 选最近有过更新的从库进行读取

           方案3：我们直接记录用户更新的时间戳，在请求的时候把这个时间戳带上，凡是最后更新时间小于这个时间戳的从库都 不予以响应。

     4、单调一致性

           本次读到的数据不能比上次读到的旧

           解决方案:就是根据用户ID计算一个hash值，再通过hash值映射到机器。同一个用户不管怎么刷新，都只会被映射到同 一台机器上。这样就保证了不会读到其他从库的内容，带来用户体验不好的影响

     5、因果一致性

     6、最终一致性

           最终一致性是所有分布式一致性模型当中最弱的。可以认为是没有任何优化的“最”弱一致性，它的意思是说，我不考虑 所有的中间状态的影响，只保证当没有新的更新之后，经过一段时间之后，最终系统内所有副本的数据是正确的。 它最大程度上保证了系统的并发能力，也因此，在高并发的场景下，它也是使用最广的一致性模型

 

分布式理论：CAP定理

     CAP定理：

        一个分布式系统不可能同事满足一致性、可用性和分区容错性这三个基本需求，最多只能同时满足其中的2个

        C - Consistency 一致性是值写操作后读操作可以读到最新的数据状态,当数据分布在多个节点上时,从任意节点读取到的数据都是最新的.

        A - Availability 可用性是指任何操作都可以得到响应的结果,且不会出现响应超时或响应错误

        P - Partition tolerance 分布式系统的各个节点部署在不同的子网中, 不可避免的会出现由于网络问题导致节点之间通信失败,此时仍可以对 外提供服务, 这个就是分区容错性 (分区容忍性).

 

分布式理论：BASE 理论

       BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（终一致性）三个 短语的缩写

       BASE理论的核心思想：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的放松来使系统达到最终一致性

 

分布式事务

    分布式事务实质上与数据库事务的概念是一致的，也需要满足事务的基本特性（ACID），分布式事务相对于本地事务而言其表现形式又很大的不同

 

分布式理论：一致性协议 2PC 

      2PC （ Two-Phase Commit缩写）即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2是指两个阶段，P是指准备阶段，C是指提交阶段

       两个阶段过程：
       1. 准备阶段（Prepare phase）：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事 务，并写本地的Undo/Redo日志，此时事务没有提交。 （Undo日志是记录修改前的数据，用于数据库回 滚，Redo日志是记录修改后的数据，用于提交事务后写入数 据文件）

       2. 提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者 发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据事务管理器的指令执行提交或者回滚操 
作，并释放事务处理过程中使用的锁资源。注意:必须在后阶段释放锁资源。

 

分布式理论：一致性协议 3PC

        3PC，全称 “three phase commit”，是 2PC 的改进版，将 2PC 的 “提交事务请求” 过程一分为二，共形成了由 CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议。

 

分布式理论：一致性算法Paxos

       Paxos算法分为两个阶段

         阶段一： (a) Proposer选择一个提案编号N，然后向半数以上的Acceptor发送编号为N的Prepare请求。 (b) 如果一个Acceptor收到一个编号为N的Prepare请求，且N大于该Acceptor已经响应过的所有Prepare请求 的编号，那么它就会将它已经接受过的编号大的提案（如果有的话）作为响应反馈给Proposer，同时该 Acceptor承诺不再接受任何编号小于N的提案。

         阶段二： (a) 如果Proposer收到半数以上Acceptor对其发出的编号为N的Prepare请求的响应，那么它就会发送一个针 对[N,V]提案的Accept请求给半数以上的Acceptor。注意：V就是收到的响应中编号大的提案的value，如果 响应中不包含任何提案，那么V就由Proposer自己决定。 (b) 如果Acceptor收到一个针对编号为N的提案的Accept请求，只要该Acceptor没有对编号大于N的Prepare 请求做出过响应，它就接受该提案。

 

分布式系统设计策略 

       心跳检测、高可用设计、容错性、负载均衡

 

分布式架构网络通信 

     基本原理：基于传输协议和网络IO来实现，其中传输协议比较出名的有tcp、 udp等等，tcp、udp都是在基于Socket概念上为某类应用场景而扩展出的传输协议，网络IO，主要有bio、nio、 aio三种方式

     RPC全称为remote procedure call，即远程过程调用

     一个完整的RPC架构里面包含了四个核心的组件，分别是Client，Client Stub，Server以及Server Stub

        RPC调用过程

 

 

    RMI

       Java RMI 指的是远程方法调用 (Remote Method Invocation),是java原生支持的远程调用 ,采用JRMP（Java Remote Messageing protocol）作为通信协议，是纯java版本的分布式远程调用解决方, RMI主要用 于不同虚拟机之间的通信

    BIO、NIO、AIO

     同步：用户进程触发IO操作等待或者轮询的方式查看IO操作是否就绪

     异步：触发异步调用后，调用者不会立即得到结果，被调用者通过状态、通知、回调函数来处理这个调用

     阻塞和非阻塞：

       阻塞和非阻塞是针对于进程访问数据的时候,根据IO操作的就绪状态来采取不同的方式

       阻塞方式下读取和写入将一直等待, 而非阻塞方式下,读取和写入方法 会理解返回一个状态值.

    BIO：同步阻塞IO

    NIO：同步非阻塞IO，JDK1.4以上版本

         服务器实现模式为一个请求一个通道，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接 有IO请求时才启动一个线程进行处理

    AIO：异步非阻塞IO，Java7开始支持

         当有流可以读时,操作系统会将可以读的流传入read方法的缓冲区,并通知应用程序,对于写操作,OS将write方法的流 写入完毕是操作系统会主动通知应用程序。因此read和write都是异步 的，完成后会调用回调函数

    Netty：异步的、基于事件驱动的网络编程框架

       NIO缺点：

           NIO的类库和API繁杂，使用麻烦，需要熟练掌握Serector、ServerSocketChannel、SocketChannel、ByteBuffer等

           可靠性不强，开发工作量和难度大

           NIO的BUG

      Netty优点

           对各种传输协议提供统一的API

           高度可定制的线程模型----单线程、一个或多个线程池

           更好的吞吐量，更低的等待延迟

           更少的资源消耗

           更小不必要的内存拷贝

     Netty模型

            Netty 抽象出两组线程池， BossGroup 专门负责接收客 户端连接， WorkerGroup 专门负责网络读写操作。 NioEventLoop 表示一个不断循环执行处理 任务的线程， 每个 NioEventLoop 都有一个 selector， 用于监听绑定 在其上的 socket 网络通道。 NioEventLoop 内部采用串行化设计， 从消息的读取->解码->处理->编码->发送， 始 终由 IO 线 程 NioEventLoop 负责

 

     Netty核心组件 

         ChannelHandler 接口定义了许多事件处理的方法， 我们可以通过重写这些方法去实现具 体的业务逻辑

         ChannelPipeline 是一个 Handler 的集合， 它负责处理和拦截 inbound 或者 outbound 的事 件和操作， 相当于 一个贯穿 Netty 的链

         ChannelHandlerContext：这 是 事 件 处 理 器 上 下 文 对 象 ， Pipeline 链 中 的 实 际 处 理 节 点

         ChannelFuture：表示 Channel 中异步 I/O 操作的结果， 在 Netty 中所有的 I/O 操作都是异步的， I/O 的调 用会直接返回， 调用者 并不能立刻获得结果， 但是可以通过 ChannelFuture 来获取 I/O 操作 的处理状态

         EventLoopGroup 是一组 EventLoop 的抽象， Netty 为了更好的利用多核 CPU 资源， 一般 会有多个 EventLoop 同时工作， 每个 EventLoop 维护着一个 Selector 实例

         ServerBootstrap 和 Bootstrap ：ServerBootstrap 是 Netty 中的服务器端启动助手，通过它可以完成服务器端的各种配置； Bootstrap 是 Netty 中 的客户端启动助手， 通过它可以完成客户端的各种配置