分布式理论基础
说到分布式系统离不开的话题 CAP理论 && BASE理论
分布式数据存储一般是指将数据以复制的方式存储在网络中的多个节点上。CAP的名称是分布式存储的几个关键点，也因此得名。
CAP
CAP理论就是针对分布式数据存储的一种理论，其想表达的含义是：当网络或节点发生故障的情况下，系统可以保证可用性、一致性和容错性中的两种，但不能三者同时保证。简单看一下CAP指的是什么：
What’s CAP
Consistency 一致性
Every read receives the most recent write or an error
从分布式数据库的任何节点查询数据，得到的都是相同的结果，即不会存在向某个节点提交数据了以后，在其他节点未同步更新的情况。如果在某个节点发生了数据的写入，系统必须同步至其他所有节点，因此无论系统连接到了哪个节点，获取到的也应该是相同的信息。但是在全球范围内维护一套绝对一致性的系统几乎不可能，因为数据传输的每一步都有可能出现问题（人们一直是在不稳定的环境中打造稳定的系统），因此我们的目标是让数据的传输同步尽可能的快（用户无感）。
银行系统就是一个需要强一致性的系统，毕竟没有人希望在ATM存完钱后，手机银行里查不到增加的的余额吧。
Availability 可用性
Every request receives a (non-error) response, without the guarantee that it contains the most recent write.
任何请求都必须得到响应。如果请求了没有烂掉的节点，那么节点必须给出回应，即使给的不是最新的数据、即使操作失败了。
朋友圈动态需要高可用，即使数据不是一致的或是最新的（空白的朋友圈会降低用户体验甚至失去用户）。在拉取动态的时候幸运选中了出现故障的节点，那么即使此节点无法同步最新的数据，它也应该返回过时数据。
Partition tolerance 分区容错性
**The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes.**如果两个节点之间通讯发生了中断，这时理解为他们之间产生了分区。如果我们无法成功从某一个节点查询到信息，这就说明此系统没有分区容错性。拥有分区容错性意味着，如果无法从某一节点拿到需要的数据，我们依旧能够在其他可用节点找到副本，并检索到相应数据。容错性是通过提高数据冗余度实现的，即将数据备份多个在不同节点上。不难想到，分区容错性对于任何分布式系统都是必须的。
CAP理论
CAP理论描述 C、A、P 三者只能同时满足两个，通过上面的介绍不难知道对于分布式存储系统，P是必须的，这就导致一致性和可用性不能同时拥有（放弃P的情况一般出现在单工作节点的系统中，因为这类系统不提供分布式，自然没有分区）。
CP 一致性和容错性
在某些分布式数据库中，如 MongoDB、Hbase，是强调一致性的。在 MongoDB中，每个主节点都有多个副本集，它们使用各自主节点的操作日志文件异步更新数据。每个节点间都会有心跳包确认存活，当节点离线时，需要选择新的 Leader，此时系统对用户是不可用的。
AP 可用性和容错性
以 Cassandra 为例，这是一个无主节点架构的的分布式点对点数据库，每个节点都接受读写请求。Cassandra 里有个概念叫复制因子，系统中所有节点环形相连，复制因子决定了副本数，如果复制因子为5，则意味着将顺时针在五个节点中保存副本。因此，Cassandra 容忍数据的不同版本存在，当用户查询数据的时候可以指定一致性级别，如果是 ONE 则系统会找到最近的一个副本返回（可能不是最新的），如果是 QUORUM 系统会查找所有副本确保返回最新的数据，在此过程中，Cassandra 内部会有另外一套流程确保副本同步。
CA之间的权衡
一致性和可用性并不是非黑即白的，往往是可调的。上文对 MongoDB 和 Cassandra 的例子是在默认配置情况下展现出的 CP 和 AP，我们可以通过调节配置，让系统以我们的期望运行，合适的才是最好的。
不过不管是AP还是CP，都会以特有方式达成BASE理论中的「最终一致性」
BASE
BASE 理论是对 CAP 理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）
What’s BASE
Basically-Available 基本可用
分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。在收到请求后，即使出现错误，可以使用不同策略，返回部分数据。如购物网站在拉取首页瀑布流的时候，个性推荐出现了问题，也应该返回一些基础的商品。
Soft-state 软状态
在接收到写入等操作请求后，允许一些中间状态存在，容忍不同节点间数据的 不一致，而此中间状态不会影响系统整体可用性。分布式数据库的数据同步过程就是 soft state 的体现。
Eventually-consistent 最终一致性
软状态是有期限的，随着时间的推移，最终能达到一致的状态，这个时间取决于网络、负载等诸多因素。
从一次支付举例
假设现在有两个服务：订单服务和支付服务，现在来描述一次用户下单过程：
- 客户下订单。
- Order 服务更新其本地数据库中的详细信息。它将付款状态标记为“payment_initiated”。
- Order 服务将消息发送到消息队列供 Payment 服务消费使用。
- Payment 服务收到消息，但由于某种原因，支付处理失败。它更新其本地数据库中的详细信息。它还会向 Order 服务发送一条带有详细信息的消息。
- Order 服务将其支付记录更新为“payment_failed”，并将备用支付链接发送给用户。
- 当用户重试支付时，再次执行第 3 步和第 4 步。成功完成支付后，Payment 服务将其详细信息更新为“payment_complete”，并向订单服务发送另一条包含更新的消息。
- Order 服务将其记录更新为“payment_complete”。
在此示例中，Payment 服务能够响应 Order 服务，尽管中间出现了支付失败的情况（基本可用）。Order 服务能够根据 Payment 服务发来的信息的更改其本地支付状态。并且 Order 和 Payment 服务会在某一刻存在不同的状态（软状态），但是最终状态会变为支付成功（最终一致性）。