week6 学习总结

Mysql 主主复制：

• 主主不可并发写入

• 只解决高可用，不解决高性能

• 不要同步表结构

数据分片

• 硬编码分片

• 映射分片

• 无法多片联合查询

• 不方便扩容

分布式数据库中间件

• 在数据库与业务请求之间的一层服务，专业管理和实现分布式数据库。

• 分片，主从，主主，扩容

NoSQL

CAP 原理

C：一致性

A：可用性

P：分区耐受性

CAP 是对分布式系统的三项要求，但是这三项要求是无法同时完全满足的。只能根据业务需要尽可能的设计和优先满足最关键的两项，而 P 做为可扩展的要求，是分布式的必选项，所以只能在 C 和 A 中做选择，选择一致性，可用性就会降低，选择高可用，那保证一致性就非常困难。

所以有了 BASE 原则

BA：基本可用：出现不可预知故障时，允许损失部分可用性（如：时间，功能）但是不会崩

S：软状态：允许数据不一致的中间状态

E：最终一致性

BASE 是对 CAP 的的一种实践，选择了高可用，而将一致性的要求变为“最终一致”，即执行过程中，有一段时间是不一致的，但最终会保证一致。

但是 BASE 并非适用所有场合，具体的还是要根据场景来做选择

最终一致致性方案：

• 更新策略：时间戳最后写入覆盖

• 客户端合并冲突

• 投票解决

ACAD

A：原子性：事务要么全部完成，要么全部取消

C：一致性：只有合法的数据才能写入数据库

I：隔离性：多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。

D：持久性：一个事务一旦被提交，它对数据库中数据的改变就是永久性的

ZooKeeper

分布式系统脑裂：不同服务器数据不致，使集群陷入混乱。

解决方案：需要一个仲裁者

ZooKeeper 就提供了这样的功能，分布式一致性解决方案

分布式一致性算法 Paxos

早期用来解决分布式环境下锁的获得

三个角色

Proposer

Acceptor

Learner

Zab 协议：是 ZooKeeper 对 Paxos 的简化版实现

两个角色

Leader：宕机时需要选举

Follower

ZooKeeper 解决方案：

• 分布式锁

• 配置管理

• 选 Master

• 集群管理