走入分布式系统的世界

    一直想总结一下自己对分布式系统的理解。不过一直不知从哪里入手，因为我也是个新手，对分布式系统的理解还是停留在很多名词上面。看了很多文章，了解了很多知识点，但是一直都没法构建一个全方位的理解，现在我就打算从分布式系统的各个点来分别阐述，看看能不能把这些点串联起来，形成一个对分布式系统的全面认识。

   分布式系统也是一个计算机系统（只不过定语是分布式），凡是计算机系统，那么一般来说都需要完成两类事情：计算和存储（这里的存储应该包括内存存储和硬盘存储）。那么自然分布式系统也要完成这两类事情。那又有什么不一样的呢？根源在于问题的规模（size），当一个问题在规模上逐渐增大时，一台计算机已经无法完成了（比如一台计算机的硬盘已经无法存储下所有数据了），就要扩大到两台，那就是分布式了。当一台服务器的吞吐量已经无法满足用户的接入了，那就需要扩大到两台，这也就成为分布式了。

    更具体的定义是

    1）在多个独立的节点上同时运行
    2）通过网络连接，网络有一些不确定性和消息丢失(如果不存在丢失，那岂不是可以当成一台超级计算机来看了)
    3）没有共享内存或共享时钟

    隐含的特征是
    1）每个节点运行一个并发程序
    2）知识是本地化的：各个节点只能快速访问本地的状态，关于全局的状态可能是过期的。
    3）节点可以独立的失败和恢复
    4）没有跨节点的同步时钟（本地的时间戳和全局的实际时间不一致）

    我们把单台服务器（或者说计算机）称为一个节点（node），那么分布式系统就是由多个node构成的，可能采用某种方式连接结合在一起，对外提供服务的一个大的计算机系统。这个看似很简单，实际上会有很多的潜在问题。比如硬盘是有一定的概率损坏的，计算机有一定的概率宕机的，当node增大时，这些概率会增大。另外，单台计算发生故障，它对外提供的服务（计算或存储任务）就停止了，这个很容易解释，就一台计算机并且还故障了，这是个很好的托词了。但是人们对分布式系统提出了更高的要求，比如因为你node比较多嘛，那么就不能那么容易停止服务了，而且既然node多了，那你的速度得快。于是人们对分布式系统提出了几个标准：

  1）性能： 期望有高的吞吐量（throughput）和低的延迟（latency）

  2）可用性：Availability = uptime / (uptime + downtime).

  3）可靠性（Reliability）：计算要正确，存储要永久不丢失

  4）容错性（fault tolerance）：系统一旦发生错误（当然是部分错误）依旧表现正常行为。

       容错不是任意什么错误都容忍（这是不可能做到的），而是容忍一些特定类型的错误。
       注意fault（错误）和failure（失败）的区别。fault指系统中的某些模块违反了它的规范，而失败是指整个系统对用户停止提供服务。不可能把系统的错误率减少为0，因此要找到方法让发生错误时，减少失败的发生。
    错误类型：
    硬件错误（Hardware fault）：比如硬盘的寿命为10到50年，那么10000个硬盘的故障每天会发生一次。不过硬件错误是独立发生的，单机服务的硬件fault可能导致对外服务failure，所以很多硬盘都有RAID，内部提供冗余。
   软件错误（Hardware error）：比如软件bug，可能导致一大批服务器崩溃。比如2012年6月30日的润秒问题（linux kernel的bug）。运行中的进程用尽了系统某些资源（cpu时间，内存，硬盘空间，网络带宽等）
           服务所依赖的其他服务变慢，或者无响应。
           级联失败。一个模块的失败导致了上游所有服务的失败。
   人为错误（Human error）：人是会犯错误的。如何减少：
       用最小犯错的方法来设计系统。比如更好的抽象，
       环境隔离，比如先在非生成环境上使用
       测试充分，从单元测试到整体继承测试
       快速恢复机制，比如回滚机制
       建立监控系统
       管理（不讨论）
      容错做的好才有系统的可靠性（Reliability）。可靠性很重要，至少存储的数据别给丢了。

  5）可扩展性（Scalability）：系统能处理多少额外的流量，增加更多的存储容量是否容易，可以处理多少额外的事务。

  6）可管理性：维护，升级。出现问题能否容易定位和理解。系统操作是否容易。

  7）监控：因为系统大了，模块多了，监控和告警系统是必不可少的。

    性能（performance）和可用性（availablity）是系统对外的一个保证（guarentee），从更高层看，可以把这个保证看作： SLA（service level agreement）。这些都是可以用数字量化的，比如可用性99.99%，那就是一年内的服务停服时间小于1小时。 比如吞吐量可以用系统支持多少并发连接或者每秒处理多少请求来衡量。latency可以用top pecentil来衡量，比如99%的响应时间小于100ms，平均响应时间为100ms。注意不要用单纯的平均时间来衡量，因为一个1s加9个10ms的平均时间是110ms，但是显然不能反映这个系统的能力。

    分布式系统中有一些模型：

    系统模型（同步/异步）
    失败模型（崩溃，分区，拜占庭错误）
    一致性模型（强一致，最终一致）

    还有一些常见设计技巧：

    分区（Partition）和复制（Replicate）

    分区就是把数据的大集合划分成若干小集合（分区），然后可以放到一台机器上，也可以分散到多台机器上，当需要扩展时，方便以分区为单位进行数据搬迁转移。分区可以提高性能，因为一个分区的数据少了，单个分区里做的遍历操作也会快一些。分区也可以提供可用性，因为可以把失败限制在一个分区中，不影响其他分区， 这样总体故障的概率也降低了。

   复制就是把同一份数据放到不同的节点上（比如放到3个不同的机器node），这有四个目的，一个就是提高可靠性，毕竟如果数据放到一个机器的硬盘上，万一该机器的硬盘故障了且不能修复，那就数据丢失了，那系统的可靠性就降低了；另一个就是提高容错，当有多份复制备份时，只要不全部故障，那么都能对外提供服务，也提高了可用性；第三个目的是类似计算机体系中的cache缓存作用，在web里就是CDN。让数据在物理位置上接近用户；还有一个目的就是可以分摊计算力，分摊带宽压力，比如原本有两个用户对某一份数据进行读操作，那么现在有了两份，用户可以到两个不同的机器上访问，每台计算机承受的访问压力就小一半。

   分区没有带来太多的副作用，但是如果一个分区故障了，还是需要做故障转移，所以往往在一个分区里 还是要使用复制技术，即每个分区里又同时保持多个复制副本。复制看似美好，但是分布式系统因此也引入了很多的问题。因为有同一份数据的不同copy在不同机器上，如何保持数据的同步是个问题。 确保复制遵循一定的一致性模型（consistency model），只有一种一致性模型（强一致性模型）会让你编程的时候觉得数据没有被复制，但是也导致了系统的响应慢，其他一致性模型下都要考虑复制。而弱的一致性模型可以提供低的延迟和高的可用性。如何取舍，是设计中的矛盾。

    CAP原则

    CA和CP的系统设计都提供了相同的一致性模型：强一致性。
     不同的是CA系统不能容忍任何节点失败；
     CP容忍f个节点失败（假设在一个非拜占庭系统中存在在2f+1个节点），只要还有f+1个节点存活
     原因很简单：
     a） 一个CA系统不区分网络失败和节点失败，必须立即停止所有地方的写操作从而避免多份数据发生冲突。它无法得知是一个节点故障了还是仅仅网络连接失败了，
      最安全的做法就是停止写操作。
     b）一个CP系统通过强迫分区的两侧进行不对称的行为来避免数据冲突。它只保留多数派，而使得少数派变得不可用（比如不再接受写操作）。

   我们尝试对分布式系统建立模型

   我们的系统模型：对系统运行的环境和设备做出一些假设。假设点不同，模型则不同。
   1）我们的系统模型中的节点
     有执行程序的能力
     有存储数据到内存和硬盘的能力
     有个时钟
     每个节点的错误也有错误模型：大多数系统都会假设一个故障-恢复模型（crash-recovery），就是说节点会因为崩溃而失败，然后过一段时间又会恢复。另一个假设是节点失败时会发送错误信息，这叫拜占庭容错。实际中很少使用拜占庭错误，因为太复杂了。
   2）我们系统模型中的通信连接
     当网络失败时，网络分区（partition）会发生。这时消息可能会丢失或延迟，直到网络分区被修好恢复。分区的节点会被部分客户端访问到，所以分区不同于节点故障。我们大部分情况都假设节点间可以双向通信的。
   3）时间/顺序的假设
     节点到节点之间的消息传递是需要时间的。
      两个主要模型：
       同步系统模型
       异步系统模型：你不能依靠时间。现实中大部分都是异步系统
    4）共识问题（consensus problem）
      错误模型中是否引入网络分区
      同步时间和异步时间假设
      共识问题是指多个计算机（或者说节点），假如它们都同意一个值，就达成一个共识。
      共识问题是许多商业分布式系统的核心。

  

分区容忍（P）必须要考虑 

    1）早期的分布式关系数据库系统的设计没有考虑分区容忍（它们是CA设计），分区容忍是一个现代系统的重要特征，因为网络分区变得越来越可能发生。
    2）在网络分区期间，强一致性和高可用性之间是有矛盾的（只能是AP或CP二选一）
       分布式系统由独立节点和连接它们的不可靠网络组成，这就导致了它的表现和非分布式完全不同
       如果要保证强一致性，那就需要我们在网络分区时放弃可用性。因为两个副本之间不能通信时还各自继续接受写操作，那是无法避免分歧的。但是我们可以弱化一致性，比如用最终一致性来代替强一致性。
    3）强一致性和普通操作的性能之间有矛盾
       强一致性要求对每个操作都必须所有节点通信并达成一致，这就导致了高延迟。
       建立弱化的一致性模型，允许有的节点存在老数据，
       但这样也会产生一些异常，你不再能获得最新的值了，或者错过一些更新。
   4）如果我们在发生网络分区时不想放弃可用性，我们需要探索一些适用我们目的弱一致性。
       比如，用户数据根据地理位置复制到了多个数据中心，连接数据中心的链路临时故障了，多数情况下我们仍旧希望给用户提供服务。
       这意味着我们要稍后再统一两个数据中心的不一致，这既是一个技术挑战，也有业务风险。但是都可控，因此我们更倾向于提供高可用性。
       如果不是必须限制强一致性，一致性和可用性也并非一定要二选一。 所以现代的分布式系统中，往往提供的是AP+弱C。

关于两阶段提交2PC

    2PC到底是解决分布式事务的问题呢，还是解决多个副本间的数据共识问题？

    我觉得两者都可以解决
    1.可以对分布式事务进行两阶段提交，以保证事务ACID中的原子性A。
    2.也可以在多个副本间的数据共识问题上使用2PC协议。
    二段提交的思路是，由于写操作要同时作用到所有机器上，而如果在coordinator机器的写操作命令发出后，其中某些参与者机器down了，导致写操作失败，就出现了不一致，那么我们就分两步来进行写操作：
     1）Ready请求，发到所有的机器上，如果该机器都能够接受该写请求，则返回成功；否则就返回失败。
     2）如果Ready阶段所有机器都回复成功，则再把接下来的写请求发到所有机器；否则，终止该写请求。
    初看上去二段提交似乎能够解决上面说到的机器down掉出现的数据不一致问题，但是如果机器down掉是在返回ready成功之后呢？
  那我们就又回到了没有二段提交的黑暗时代了。
  所以二段提交实际上只是将数据不一致的问题稍微缓解，而并没有完全解决。
  那么二段提交的加强版——三段提交呢？情况其实也是差不多，三段提交也只是缓解问题，并没有完全解决. 三段提交的核心理念是：在询问的时候并不锁定资源，除非所有人都同意了，才开始锁资源。

    2PC的另一个一个问题：
    协调者（coordinator）发起一个Prepare请求给两个参与者（participant）。两个都收到，也都ACK。然后coordinator发起了commit，结果participant-1收到且回复了。
  而此时coordinator还没收到ACK时crash了，对participant-2的commit自然也没有发起。这时怎么办呢？
  没办法，participant-1已经执行了，participant-2不能简单的commit或abort，即使在超时后。
  唯一的办法只能等coordinator恢复后，读transcation log来决定。所以两阶段提交也叫阻塞式的原子提交。

    那难道分布式数据共识问题就没有办法解决了吗？难道我们就没有银弹了吗？幸好，计算机科学家为我们想到了解决方案——Paxos和RAFT这两个分布式共识算法（我们这里暂时不讨论）。

事务（transcations）
    事务就是应用程序把若干读写操作合到一个逻辑单元中，事务中所有这些读和写就像一个操作一样被执行：或者整个被执行（commit），或者整个失败（abort，rollback），不会有部分失败（partial failure）。事务提供ACID特性，有时候ACID成为了一个商业口号，因为不同的数据库系统对ACID的实现不尽相同。
    不支持ACID的系统称为BASE（Basically，Available， Soft state，Eventually consistency），这个定义更模糊。

未完成。。。