对分布式系统的理解

为了解决传统单体服务架构带来的各种问题，代码数量庞大，迭代测试维护困难，可能因为一处改动测试不到位造成整个服务瘫痪等问题，分布式系统就是将一个大的服务拆分成几十个甚至上百个微小的服务。如果把单体架构服务器比做篮子，那代码就是鸡蛋，不要让所有鸡蛋别装在一个篮子里，也方便大家分工开发，代码不在一个项目里，也不会冲突，最主要的是项目自己维护

分布式系统优缺点

优点

1 系统可用性提升 一个系统全年可用时间在 99.999%，5 个 9 的服务可用率在设计合理的分布式系统中并不是一个触不可及的数字。 传统的集中式计算或集中式存储在遇见单点故障时很容易造成整个服务不可用，分布式下的服务体系，单台机器有故障，不致于造成整个服务不可用。 2 系统并发能力提升 请求通过 Nginx 负载均衡被分发到不同的服务器上，运行同样代码的服务器可以有 1 台或 N 台，通常情况下会根据实际用户访问量随时增加机器，无论是数据库或者服务，都可以做到随时水平扩展。 比如双 11 活动，平时订单少 50 台机器就够了，到了 11 订单量剧增，服务器增加到 100 台，每台机器之间相互独立，互不影响。 3 系统容错能力提升

同一组服务分别部署在北京上海杭州，杭州的机房突发断电或者火灾，杭州机房的流量会被自动分发到北京和上海的机房，不影响用户使用。

4 低延迟 参考上一个图，北京的用户请求自动分发到北京，上海的用户请求被分发到上海，服务器会根据用户的 IP 选择距离自己最近的机房，降低网络延迟。

缺点

1 分布式服务依赖网络 服务器间通讯依赖网络，不可靠网络包括网络延时，丢包、中断、异步，一个完整的服务请求依赖一连串服务调用，任意一个服务节点网络出现问题，都可能造成本次请求失败。 2 维护成本高 传统单体式服务只需要维护一个站点就可以。 分布式服务系统被拆分成若干个小服务，服务从 1 变为几十个上百个服务后，增加运维成本。 3 一致性，可用性，分区容错性无法同时满足 这个是最主要的，这三种特性就是平时说的 CAP 定理，在分布式系统中，这三种特性最多只能满足两种，无法同时满足，需要根据实际情况去调整牺牲掉其中哪个。

CAP定理和BASE理论、

CAP是Consistency、Availablity、Partition-tolerance的缩写，指出对于一个分布式计算系统来说，不可能同时满足以下三点。

Consistency（一致性）：如果对任意一个节点的数据就行修改成功后，所有其他节点都能读取到最新的值，那么这个系统就被认为具有严格的一致性。 Availability（可用性）：每次请求都能获取到非错的响应，即单节点宕机可从其他节点获取到响应，但是不能保障获取到的数据为最新的数据，即和一致性互斥 Partition tolerance（分区容错性）：当节点间出现网络分区（不同节点处于不同的子网络，子网络之间是联通的，但是子网络之间是无法联通的，也就是被切分成了孤立的集群网络），照样可以提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。 任何一个分布式系统只能满足三选二，即只能AP或 CP，必须要有P 。为什么是如此，我们来作简单的分析。 由于我们是分布式系统，所以我们必须要将系统部署在多节点，多网络分区，这才是分布式系统，而存在网络分区，我们就必须要保证P，，分区容错性

BASE BASE 是由 Basically Available（基本可用）、Soft state（软状态）、Eventually consistent（最终一致性）缩写而来的。BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性，让CAP三者同时基本实现。

Basically Available：基本可用， 就是在某个节点宕机或者发生网络分区的情况，可以让所有请求都强制走主节点，这样保证了数据的一致性可可用性，如果主节点压力比较大可以触发降级熔断机制等，或者限流等，让原先0.5秒响应的请求以更长的时间去相应 Soft state：软状态 相对原子性来说各个要求都有所降低，原子性（硬状态），要求多个节点的数据副本都是一致的,这是一种"硬状态"。软状态（弱状态）允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延迟 Eventually consistent：最终一致性， 一致性也分强一致性和弱一致性，而最终一致性属于弱一致性，就是系统并不保证连续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。但会尽可能保证在某个时间级别（比如秒级别）之后，可以让数据达到一致性状态。

分布式深入分析

关于分布式系统，通俗点讲就把整个业务系统拆分成很多的服务，每个服务责任到人，服务之间代码都没有冲突，服务可以自治，每个服务到技术也可以自己选型，只要遵循统一的服务调用协议就可以了。每次发布如果就改动一个服务那就上线一个服务，不用所有人一起联调，这样每次发布牵扯到的改动影响也是可控的。不像传统单体架构服务，动辄几百万行代码融在一起。

分布式系统并不是某一门具体的技术，也不是具体的框架。用大白话理解就是将计算能力和数据存储能力分散在不同服务器上，通过网络连接组成的一个整体的服务，不同服务器可能是物理机，也可能是虚拟机，分布式的概念可以理解成一种解决方案。

分布式系统总结来说是将数据存储能力和计算能力分布到不同的服务器上，作为一个整体对外服务。目的在于解决单台机器的故障问题，单机计算和 IO 性能问题，以及单机存储空间不足的问题。虽然单机故障的概率比较小，但是随着集群规模大了之后，集群宕机和磁盘损坏基本上是常态，分布式系统主要解决的是各种故障带来的问题。

分布式和微服务的关系

关于分布式系统和微服务，两者都只是一种概念。如果你采用微服务，就意味着系统一定是分布式的，分布式系统具有的优缺点在微服务理都会体现，个人理解微服务是分布式系统的一种具体落地方案。

分布式和集群的区别

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

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

负载均衡：决定将任务以某种规则分给谁做。 （看谁任务不重就以某种规则把任务分配给谁）