目录
CAP
一致性
高可用性
数量上的可用性：
并行与顺序可用性
ACID：
主从复制架构：
主主复制架构
联邦（联合）
分片
CAP
C: 一致性，每次访问都能获得最新数据但可能会收到错误响应
A: 可用性，即使获得的不是最新数据是不一致的，但是系统的可用性是存在的，是可用的
P: 分区容限。在某部分分区有网络故障时，整个系统仍旧可以使用
分布式系统中，只能够支持CAP中的两个特征。
AP：可用性相比一致性概率稍高
CP：选择一致性，可用性概率稍低
目前大部分分布式系统都是AP，但是不能说是完全AP，只能说偏向于AP或者CP
一致性
分为弱一致性、最终一致性、强一致性
弱一致性
适用于一些实时的系统，比如多人聊天，实时多人游戏，当重新连接时，断连期间接受的内容是听不到的，常用于memcached等系统
最终一致性
写入后，在一定时间后，读取最终会看到它，一般是在几个ms内，数据是异步复制的，常见于DNS和电子邮件等系统，并且最终一致性在高可用的系统内运行良好
强一致性
写入后，读取将会看到，数据是同步复制的，常用于文件系统，关系型DB，强一致性适用于在一些需要事务的系统中
高可用性
由故障转移和复制（见下文主主复制和主从复制）来实现
故障转移：
主从：主服务器接受流量，从服务器是备用状态：热备：可以接管主服务器 冷备：需要启动，才可以接管主服务器
主主：多个服务器都在管理流量，一个挂掉之后，剩下的服务器还可以提供服务。
故障转移缺点:
如果主节点宕机前几个ms接收到的数据还没来得及复制到从节点，那这个数据就是丢失了
数量上的可用性：
3个9和4个9，了解大概范围
并行与顺序可用性
如果一个服务由多个容易发生故障的组件组成，那么整个的组件的可用性是按照这些组件的排列顺序：
按顺序：整体的可用性会降低，因为每个组件可用性AVG<1,整个可用性等于每一个组件相乘即AVG1*AVG2。
按并行：即相互间可以替代，整体可用性会提高，整体可用性=1-（1-AVG1）*（1-AVG2）
ACID：
关系型数据库衡量是否满足事务的要求必须满足
A:原子性：每个事务内部要么完成，要么不完成
C：一致性 任何事务都使得数据库从一个有效状态转换为另一个有效状态
I：隔离性 并发事务和顺序执行的事务结果相同
D：持久性 事务提交之后，对系统的影响是永久的
主从复制架构：
主节点只接受写，从节点接收读请求
缺点：主节点宕机后，需要额外的逻辑来使得从节点成为新主节点，就是没有原生的支持，需要第三方的软件支持；
主主复制架构
两个主节点都可以接受读写操作，双主之间互相复制数据。一个宕机之后，不影响系统的读取和写入，
主主复制缺点：
1、需要在两个主节点前加入一个load banlancer或者在客户端应用层逻辑做改动，来选择写入的主库，是有一个路由选择的问题。
2、两个主节点的数据一致性问题，会有写入延迟，会有以下两个情况：
松散的一致，写入之后在一定时间内进行同步，即最终一致性
两个主节点都接受写入请求之后再进行写入，这样也就会有一个写入延迟
3、多主库之间的冲突解决问题，因此适用于多个数据中心的场景，单个数据中心的话，过于复杂。
两种复制都存在的缺点:
在主节点接收到新写入数据之前就宕机了，那么丢失的数据是没有办法恢复的。
读取的从库越多，主库需要复制的副本就越多，会造成很大的压力，影响性能
如果一下子给主库写入过多，从库读取的话可能会有负担
联邦（联合）
将数据库按功能分为多个库，比如商品库，订单库等，是适用于微服务场景之下的，即将一个大的库拆为多个微服务库。拆分之后会减小每个库读写的压力，每个数据库的读写流量会减小，复制的延迟就可以减小，并且较小的数据库意味着可以有更多的数据放入内存，会增加缓存命中率。
缺点：应用层的代码逻辑需要更改，您需知道访问的是哪一个库
如果经常需要连接来自两个数据库的数据会很复杂，因此应把更相关的数据放在一起。
分片
将一个表的数据拆成多个分片，比如用户表按照首字母A-C放在一个库,D-F放一个库，减少流量，减小读写压力这些有点和联邦是一样的，并且索引大小也会变小。
缺点：
应用层的代码逻辑需要更改，您需知道访问的是哪一个分片；
会出现数据不平衡，就是热点问题，再次平衡的话会很复杂，一致性哈希的分片会减少这样的问题；
需要尽量考虑访问接近的数据放在一个分片中，去减少跨数据库的连接。
参考：GitHub - donnemartin/system-design-primer: Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards.
