CAP与BASE
CAP与BASE
CAP原则
CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。CAP原则是NOSQL数据库的基石。Consistency（一致性）。 Availability（可用性）。Partition tolerance（分区容错性）。分布式系统的CAP理论：理论首先把分布式系统中的三个特性进行了如下归纳：一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
BASE理论
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。接下来我们着重对BASE中的三要素进行详细讲解。
基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用，以下两个就是“基本可用”的典型例子。
- 响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，但由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。
- 功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
弱状态也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据听不的过程存在延时。
最终一致性
最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性
总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统事务的ACID特性使相反的，它完全不同于ACID的强一致性模型，而是提出通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性与BASE理论往往又会结合在一起使用。
数据分割
数据分割是指把逻辑上是统一整体的数据分割成较小的、可以独立管理的物理单元进行存储，以便于重构、重组和恢复，以提高创建索引和顺序扫描的效率。数据分割使数据仓库的开发人员和使用者具有更大的灵活性
优点
对当前细节数据进行分割的总体目的就是把数据划分成小的物理单元，为操作者和设计者在管理数据时提供更大的灵活性。小物理单元具有容易重构、自由索引、顺序扫描、容易重组、容易恢复和容易监控等优点。数据仓库的本质之一就是灵活地访问数据，大块数据达不到这个目的。
标准
数据分割的标准可以根据实际情况来确定，通常可选择按日期、地域、业务领域或组织单位等来进行分割，也可以按多个分割标准的组合来进行，但一般情况下，分割标准应包括日期项。
例如，数据分割的标准是由开发人员选择的，在数据仓库中按日期总是必需的。
层次
分割的层次一般分为系统层和应用层。系统层的分割由数据库管理系统和操作系统完成；应用层的分割由应用系统完成，在应用层上的分割更有意义。
分割方法
水平分割
水平分割(Horizontal Splitting)就是把全局关系的元组分割成一些子集，这些子集被称为数据分片或段(Fragment)。数据分片中的数据可能是由于某种共同的性质(如地理、归属)而需要聚集一起的。通常，一个关系中的数据分片是互不相交的，这些分片可以选择地放在一个站点上，也可以通过副本被重复放在不同的站点上。
垂直分割
垂直分割(Vertical Splitting)就是把全局关系按着属性组(纵向)分割成一些数据分片或段(Fragment)。数据分片中的数据可能是由于使用上的方便或访问的共同性而需要聚集一起的。通常，一个关系中的垂直数据分片问只在某些键值上重叠，其他属性是互不相交的。这些垂直分片可以放一个站点上，也可以通过副本被重复放在不同的站点上
副本策略
Primary-secondary协议
该协议是中心化副本控制协议中常常用到的，该协议将副本分为两类：其中仅有一个副本作为primary副本，其他副本都作为secondary副本。维护primary副本的节点作为中心节点，中心节点负责维护数据的更新、并发控制、协同副本的一致性。
（1）数据更新的基本流程：
1.数据更新都有Primary节点协调完成。
2.外部节点将更新操作发给Primary节点。
3.Primary节点进行并发控制即确定并发更新操作的先后顺序。
4.Primary节点将更新操作发送给secondary节点
5.primary根据secondary节点的完成情况决定更新是否成功并将结果返回外部节点
（2）数据读取方式
与数据更新流程类似，读取方式也与一致性高度相关。使用primary-secondary比较困难的是实现强一致性。实现强一致性一般有如下几个思路：
1.始终只读primary副本的数据
2.由primary控制节点secondary节点的可用性。
3.基于Quorum机制
（3）Primary副本的确定和切换
primary副本的确定通常由原信息管理，由专门的元数据服务器维护，执行更新操作时，首先查询元数据服务器获取副本的primary信息，从而进一步执行数据更新流程。 primary副本的切换通常可以使用lease机制来完成。
（4）数据同步
数据同步是因为primary副本可能会存在于secondary副本不一致的问题。通常有如下三种形式：
1.由于网络分化等异常，secondary上的数据落后于primary上的数据。—— redo primary副本上的操作日志。
2.在某些协议下，secondary上的数据有可能是脏数据，需要被丢弃。—— undo日志的方法删除脏数据
3.secondary是一个新增加的副本，完全没有数据，需要从其他副本上拷贝数据。—— 使用primary副本的snapshot（快照）功能
paxos协议
多个节点直接通过操作日志同步数据，如果只有一个节点称为主节点，就很容易在多个节点之间维护数据一致性。然后主节点可能出现故障，那么就需要选出主节点。Paxos协议就是用于解决多个节点之间的一致性问题
在paxos算法中，分为4种角色：
Proposer ：提议者
Acceptor：决策者
Client：产生议题者
Learner：最终决策学习者
4种角色中，提议者和决策者是很重要的，其他的2个角色在整个算法中较弱 Proposer就像Client的使者，由Proposer使者拿着Client的议题去向Acceptor提议，让Acceptor来决策。
最终决策的paxos算法行为:
1.Proposer提出议题
2.Acceptor初步接受或者Acceptor初步不接受
3.如果上一步Acceptor初步接受则Proposer再次向Acceptor确认是否最终接受
4.Acceptor最终接受或者Acceptor最终不接受
