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
集群管理
评论