关系型数据库的优势
通用性和高性能
- 保持数据的一致性（事务处理）
- 最小冗余
- 复杂查询如 JOIN
- 成熟的技术
关系型数据库的不足
- 大量数据的写入处理
- 表结构变更及建立索引
- 字段不固定的应用
- 对简单查询需要快速返回结果的处理
非关系型数据库的优势
- 易于数据的分散
- 提升性能和增大规模
- 模式自由
- 扩展性好
非关系型数据库的种类
| 存储类型 | 代表解决方案 | 特点 |
|---|---|---|
| 列存储 | Hbase | 按列存储，适用于数据压缩，对一个或几个字段进行查询的效率很高 |
| 文档存储 | MongoDB | 保证海量数据存储的同时，具有良好的查询性能。用类 JSON 格式进行存储 |
| key-value 存储 | Redis | 具有极高的并发读写性能。通过 key 迅速查找到 value，但只能通过 key 查询 |
| 图数据库 | Neo4j | 图形关系的最佳存储模式 |
CAP 理论
- 可用性： 一直可以正常的做读写操作。简单而言就是客户端一直可以正常访问并得到系统的正常响应。用户角度来看就是不会出现系统操作失败或者访问超时等问题。
- 一致性：在分布式系统完成某写操作后任何读操作，都应该获取到该写操作写入的那个最新的值。相当于要求分布式系统中的各节点时时刻刻保持数据的一致性。
- 分区容错性：指的分布式系统中的某个节点或者网络分区出现了故障的时候，整个系统仍然能对外提供满足一致性和可用性的服务，也就是说部分故障不影响整体使用。
CAP 三者如何取舍
- CA: 优先保证一致性和可用性，放弃分区容错。 这也意味着放弃系统的扩展性，系统不再是分布式的，有违设计的初衷。
- CP: 优先保证一致性和分区容错性，放弃可用性。在数据一致性要求比较高的场合(譬如：zookeeper，Hbase) 是比较常见的做法，一旦发生网络故障或者消息丢失，就会牺牲用户体验，等恢复之后用户才逐渐能访问。
- AP: 优先保证可用性和分区容错性，放弃一致性。放弃一致性不是说一致性就不保证了，而是逐渐的变得一致。
强一致性
- 也叫即时一致性。
- 假如 A 先写入了一个值到存储系统，存储系统保证后续 A、B、C 的读取操作都将返回最新值。
- 单副本数据容易保证强一致性。
- 多副本数据需要使用分布式事务协议。
弱一致性
- 假如A先写入了一个值到存储系统，存储系统不能保证后续 A、B、C 的读取操作能读取到最新值。
- 不一致性窗口：从 A 写入到后续操作 A、B、C 读取到最新值这一段时间。
最终一致性
- 最终一致性是弱一致性的一种特例。
- 假如 A 首先 write 了一个值到存储系统，存储系统保证如果在 A、B、C 后续读取之前没有其它写操作更新同样的值的话，最终所有的读取操作都会读取到 A 写入的最新值。
BASE 模型
- Basically Availble：基本可用。
- Soft-state：软状态/柔性事务。
- Eventual Consistency：最终一致性。
- 完全不同于ACID模型，牺牲高一致性，获得可用性或可靠性。
NWR 模型
- N：复制的节点数量。
- R：成功读操作的最小节点数。
- W：成功写操作的最小节点数。
- 只需 W + R > N，就可以保证强一致性，因为读取数据的节点和被同步写入的节点是有重叠的。
两阶段提交协议
投票阶段：
- 在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。
- 在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。
提交阶段：
- 协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。
两阶段提交协议的缺点
- 同步阻塞问题：执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
- 单点故障：由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）。
- 数据不一致：在二阶段提交的阶段二中，当协调者向参与者发送 commit 请求之后，发生了局部网络异常或者在发送 commit 请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了 commit 请求。而在这部分参与者接到 commit 请求之后就会执行 commit 操作。但是其他部分未接到 commit 请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。
- 二阶段无法解决的问题：协调者再发出 commit 消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。