一、分布式系统
随着互联网的高速发展，业务规模和数据量的不断增大，系统架构也在不断的演变。从单机集中式架构到集群部署架构，再到分布式架构，乃至分布式集群。
分布式和集群既能放在一起讲，也可以相互独立，它们的含义却是不同。
- 分布式
把一个大任务拆分成多个小的任务(或者说业务)，部署在不同的物理机或者不同的服务。 - 集群
同一个业务，部署在不同的服务器上。
比如：一个工作任务需要8个小时才能完成。
分布式：8台机器，把任务分隔，同时跑起来，1个小时就能完成。
集群：8台机器，每个机器都跑相同的任务，最后完成还是需要8小时。
下面我们以JavaWeb系统为例，来搭建一个电商平台系统，随着业务的快速发展，以这个系统来更加清晰的观察系统架构的演变。
假设我们的系统分为下面几个模块：
| 序号 | 模块 | 功能 |
|---|---|---|
| 1 | 用户模块 | 用户注册和信息管理 |
| 2 | 商品模块 | 商品展示和信息管理 |
| 3 | 交易模块 | 交易以及支付结算 |
1、单机集中式
项目前期，产品知名度不高，访问量较小的情况下，通常会花钱买一台相对性能不错的服务器，将所有的软件和应用都部署在一台服务器上，这样就完成了系统的搭建。
2、集群
随着用户的增多，访问量的逐步上升，服务器负载会渐渐提高。这时候，通常先会把数据库和应用分离，释放单台服务器的压力。但是，在形势大好的情况下，产品的知名度越来越高，访问量也越来越大，很快也许单台应用服务器也承受不住压力。这时候，我们就要做集群部署。
3、分布式
上面是一个很简单的集群架构，只是把WEB应用独立部署，但随着时间的推移，数据库压力早晚也遭不住。那么，数据库的集群也在所难免，当然主从模式下的读写分离往往是第一选择。再往下发展，根据业务特点可以考虑缓存、搜索引擎、分库分表...
随着业务的发展，应用的压力越来越大，代码量也越来越庞大。往往一次小的改动，就要集成发布很久，相关联的覆盖测试也难以控制。这时候，就考虑将应用拆分，将核心业务抽取出来，作为独立的服务。每个服务都独立开发和部署，服务之间采用RPC调用、消息队列、数据同步等机制传输数据。
我们看到，分布式系统就是一个硬件或软件组件，分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。它所有的计算和数据传递都依靠网络完成，在大型分布式系统中，如何同步节点状态、如何保证节点高可用、如何保证数据一致性、通信异常、网络分区等就是亟需解决的问题。
二、方法论
1、CAP理论
分布式系统有三个指标，在2000年的分布式计算原则研讨会上，由柏克莱加州大学的计算机科学家埃里克·布鲁尔提出。
| 英文 | 中文 | 含义 |
|---|---|---|
| Consistency | 一致性 | 数据在分布式环境下的多个副本之间保持一致性 |
| Availability | 可用性 | 分布式系统一直处于可用状态，对于请求总是能在有限的时间内返回结果 |
| Partition tolerance | 分区容错性 | 除非整个网络故障，分布式系统在任何网络或者单点故障时，仍能对外提供满足一致性和可用性的服务 |
CAP理论：一个分布式系统不可能同时满足一致性、可用性和分区容错性这三个基本需求，最多只能同时满足其中的两项；
| 满足 | 说明 |
|---|---|
| 满足AC，放弃P | 将数据和服务都放在同一节点，避免因网络故障引起负面影响，可以保证系统的可用性和一致性 |
| 满足PC，放弃A | 当节点故障时，受影响的服务需要等待一定的时间，在此时间内，系统无法正常对外提供服务 |
| 满足AP，放弃C | 无法保证数据的实时一致性，但最终会保持一致性。 |
2、BASE理论
BASE理论是CAP理论的延伸，它主要是说，如果无法做到数据的强一致性，也可以根据自己的业务特点，采用合适的方式使系统达到最终一致性。
Basically Avaliable 基本可用
当分布式系统出现故障时，允许损失部分可用性，保证系统的基本可用。比如双十一期间的，页面卡顿、服务降级等。Soft State 软状态
允许系统中的数据存在中间状态，既系统的不同节点的数据副本之间的数据同步过程存在延时，并认为这种延时不会影响系统可用性。Eventually consistent 最终一致性
所有的数据在经过一段时间的数据同步后，最终能够达到一致的状态。
