标签：工具 错误 发展 修改 协议分析 了解 mmu 一个 数据结构
随着移动互联网的发展智能终端的普及，计算机系统早就从单机独立工作过渡到多机器协作工作。计算机以集群的方式存在，按照分布式理论的指导构建出庞大复杂的应用服务，也已经深入人心。本文力求从分布式基础理论，架构设计模式，工程应用，部署运维，业界方案这几大方面，介绍基于MSA(微服务架构)的分布式的知识体系大纲。从而对SOA到MSA进化有个立体的认识，从概念上和工具应用上更近一步了解微服务分布式的本质，身临其境的感受如何搭建全套微服务架构的过程。
由于业务发展到一定层度后，需要对服务进行解耦，进而把一个单一的大系统按逻辑拆分成不同的子系统，通过服务接口来通讯，面向服务的设计模式，最终需要总线集成服务，而且大部分时候还共享数据库，出现单点故障的时候会导致总线层面的故障，更进一步可能会把数据库拖垮，所以才有了更加独立的设计方案的出现。
微服务是真正意义上的独立服务，从服务入口到数据持久层，逻辑上都是独立隔离的，无需服务总线来接入，但同时增加了整个分布式系统的搭建和管理难度，需要对服务进行编排和管理，所以伴随着微服务的兴起，微服务生态的整套技术栈也需要无缝接入，才能支撑起微服务的治理理念。
传统的节点也就是一台单体的物理机，所有的服务都揉进去包括服务和数据库；随着虚拟化的发展，单台物理机往往可以分成多台虚拟机，实现资源利用的最大化，节点的概念也变成单台虚拟机上面服务；近几年容器技术逐渐成熟后，服务已经彻底容器化，也就是节点只是轻量级的容器服务。总体来说，节点就是能提供单位服务的逻辑计算资源的集合。
分布式架构的根基就是网络，不管是局域网还是公网，没有网络就无法把计算机联合在一起工作，但是网络也带来了一系列的问题。网络消息的传播有先后,消息丢失和延迟是经常发生的事情，我们定义了三种网络工作模式：
同步网络
节点同步执行
消息延迟有限
高效全局锁
半同步网络
锁范围放宽
异步网络
节点独立执行
消息延迟无上限
无全局锁
部分算法不可行
常用网络传输层有两大协议的特点简介：
TCP协议
首先tcp尽管其他可以更快
tcp解决重复和乱序问题
UDP协议
常量数据流
丢包不致命
慢速物理时空中，时间独自在流淌着，对于串行的事务来说，很简单的就是跟着时间的脚步走就可以，先来后到的发生。而后我们发明了时钟来刻画以往发生的时间点，时钟让这个世界尽然有序。但是对于分布式世界来说，跟时间打交道着实是一件痛苦的事情。分布式世界里面，我们要协调不同节点之间的先来后到关系，但是不同节点本身承认的时间又各执己见，于是我们创造了网络时间协议（NTP）试图来解决不同节点之间的标准时间，但是NTP本身表现并不如人意，所以我们又构造除了逻辑时钟，最后改进为向量时钟：
NTP的一些缺点，无法完全满足分布式下并发任务的协调问题
节点间时间不同步
硬件时钟漂移
线程可能休眠
操作系统休眠
硬件休眠
有了衡量时间的工具，解决顺序问题自然就是水到渠成了。因为整个分布式的理论基础就是如何协商不同节点的一致性问题，而顺序则是一致性理论的基本概念，所以前文我们才需要花时间介绍衡量时间的刻度和工具。
单机环境下我们对传统关系型数据库有苛刻的要求，由于存在网络的延迟和消息丢失，ACID便是保证事务的原则，这四大原则甚至我们都不需要解释出来就耳熟能详了：
Atomicity：原子性，一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。
Consistency：一致性，在事务开始之前和事务结束以后，数据库的完整性没有被破坏。
Isolation：隔离性，数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
Durabilit：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
分布式环境下，我们无法保证网络的正常连接和信息的传送，于是发展出了CAP/FLP/DLS这三个重要的理论：
CAP:分布式计算系统不可能同时确保一致性（Consistency）、可用性（Availablity）和分区容忍性（Partition）。
FLP：在异步环境中，如果节点间的网络延迟没有上限，只要有一个恶意的节点存在，就没有算法能在有限的时间内达成共识。
DLS:
（1）在一个部分同步网络的模型（也就是说：网络延时有界限但是我们并不知道在哪里）下运行的协议可以容忍1/3任意（换句话说，拜占庭）错误；
（2）在一个异步模型中的确定性的协议（没有网络延时上限）不能容错（不过这个论文没有提起随机化算法可以容忍1/3的错误）；
（3）同步模型中的协议（网络延时可以保证小于已知d时间）可以，令人吃惊的，达到100%容错，虽然对1/2的节点出错可以发生的情况有所限制
多数情况下，其实我们也并非一定要求强一致性，部分业务可以容忍一定程度的延迟一致，所以为了兼顾效率，发展出来了最终一致性理论BASE，BASE是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）
基本可用(Basically Available)：基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。
软状态(Soft State)：软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。
最终一致性(Eventual Consistency)：最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。
分布式架构的核心就在一致性的实现和妥协，那么如何设计一套算法来保证不同节点之间的通信和数据达到无限趋向一致性，就非常重要了。保证不同节点在充满不确定性网络环境下能达成相同副本的一致性是非常困难的，业界对该课题也做了大量的研究。
首先我们要了解一致性的大前提原则(CALM):
CALM原则的全称是 Consistency and Logical Monotonicity ，主要描述的是分布式系统中单调逻辑与一致性的关系，它的内容如下，参考consistency as logical monotonicity
在分布式系统中，单调的逻辑都能保证 “最终一致性”，这个过程中不需要依赖中心节点的调度
任意分布式系统，如果所有的非单调逻辑都有中心节点调度，那么这个分布式系统就可以实现最终“一致性”
然后再关注分布式系统的数据结构CRDT(Conflict-Free Replicated Data Types)：
我们了解到分布式一些规律原则之后，就要着手考虑如何来实现解决方案，一致性算法的前提是数据结构，或者说一切算法的根基都是数据结构，设计良好的数据结构加上精妙的算法可以高效的解决现实的问题。经过前人不断的探索，我们得知分布式系统被广泛采用的数据结构CRDT。
参考《谈谈CRDT》,A comprehensive study of Convergent and Commutative Replicated Data Types
基于状态(state-based)：即将各个节点之间的CRDT数据直接进行合并，所有节点都能最终合并到同一个状态，数据合并的顺序不会影响到最终的结果。
基于操作(operation-based)：将每一次对数据的操作通知给其他节点。只要节点知道了对数据的所有操作（收到操作的顺序可以是任意的），就能合并到同一个状态。
了解数据结构后，我们需要来关注一下分布式系统的一些重要的协议HATs(Highly Available Transactions)，ZAB(Zookeeper Atomic Broadcast)：
参考《高可用事务》，《ZAB协议分析》
最后要学习的是业界主流的一致性算法：
说实话具体的算法我也还没完全搞懂，一致性算法是分布式系统最核心本质的内容，这部分的发展也会影响架构的革新，不同场景的应用也催生不同的算法
Paxos：《优雅的Paxos算法》
Raft ：《Raft 一致性算法》
Gossip：《Gossip Visualization》
这一节我们说完分布式系统里面核心理论基础，如何达成不同节点之间的数据一致性，下面我们将会讲到目前都有哪些主流的分布式系统。
标签：工具 错误 发展 修改 协议分析 了解 mmu 一个 数据结构
原文地址：https://www.cnblogs.com/chch157/p/11050377.html
