CAP和BASE理论

CAP

定义

• 一致性(Consistency)：多副本之间保证一致。对一个数据更新操作后，所有用户都可以获取最新值。
• 可用性(Availability)：服务一直可用。用户的每一个操作请求总能在有限时间内返回处理结果。
• 分区容错性(Partition tolerance)：可在网络网络分区故障时提供服务。
• 分布式系统只能同时满足以上三个需求中的两个。

侧重点

• 放弃C。
  • 大型网站通常会牺牲强一致性，保证数据最终达到一致的状态。
• 放弃A。
  • 某些存储如hbase在单点故障时会牺牲该节点数据的可用性，待副本节点同步后再提供服务。
• 放弃P。
  • redis锁存在一个节点，如mysql获取数据，从而避免网络分区的影响，数据层无法也不需要扩展。

BASE

• 面向大型高可用可扩展的分布式系统，追求AP，无法做到强一致，当可以用适当的方式做到最终一致。

定义

• 基本可用（Basically Available）：分布式系统故障时，允许损失部分可用性。
  • 响应时间上：rt从0.1s延长到1s，比如实时dts和兜底的check任务。
  • 功能上：服务的降级，部分低优先级功能如素材等不提供。
• 软状态（Soft state）：数据存在中间态，即数据副本之间同步存在延时。
• 最终一致性（Eventually consistent）：所有数据副本最终能够一致而不需要实时一致。

最终一致分类

1. 因果一致（Causal consistency）：进程A修改数据后，进程B需要基于A的最新值修改，不能出现更新丢失。
2. 读己之所写（Read your writes）：进程A修改数据后，自己能够访问到最新的值。特殊的因果一致性。
3. 会话一致（Session consistency）：保证一个有效会话中实现读己之所写。
4. 单调读一致（Monotonic read consistency）：进程A读取数据后，进程A读取该数据都不会得到旧值。
5. 单调写一致（Monotonic write consistency）：来自进程A的写操作顺序执行。

一致性方案

• 参考：https://cloud.tencent.com/developer/article/1041507