分布式数据库

MySQL主从复制

MySQL一主多从复制

一主多从的优点

分摊负载

专机专用

便于冷备

高可用



MySQL主主复制

MySQL主主失效恢复

MySQL主主失效的维护过程

MySQL复制注意事项

主主复制的数据库不能并发写入

复制只是增加了数据的读并发处理能力，并没有增加写并发能力和存储能力

更新表结构会导致巨大的同步延迟



数据分片

挑战

需要大量的额外代码，处理逻辑因此变得更加复杂

无法执行多分片的联合查询

无法使用数据库的事务

随着数据的增长，如何增加更多的服务器

分布式数据库中间件

路由配置

扩容策略

NoSQL

CAP原理

一致性C、可用性A、分区耐受性P

一致性

每次读取的数据都应该是最近写入的数据或者返回一个错误，而不是过期数据

可用性

每次请求都应该得到一个响应，而不是返回一个错误或者失去响应，不过这个响应不需要保证数据是最近写入的

分区耐受性

即时因为网络原因，部分服务器节点之间消息丢失或者延迟了，系统依然是可操作的



CAP原理要点

当网络分区失效发生时，我们要么取消操作，这样数据就是一致的，但是系统却不可用；要么我们继续写入数据，但是数据一致性就得不到保证



对于分布式系统而言，网络失效一定会发生，也就是说，分区耐受性是一定要保证的，那么在可用性与一致性之间必须做二选一



当网络分区失效时，也就是网络不可用时，如果选择了一致性，系统就可能返回一个错误码或干脆超时，即系统不可用。如果选择了可用性，那么系统总是可以返回一个数据，但是并不能保证这个数据是最新的



所以，关于CAP原理，更准确的说法是，在分布式系统必须要满足分区耐受性的前提下，可用性与一致性无法同时满足。



ACID与BASE

ACID

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

• 隔离性：2个事务T1、T2同时运行，不管谁先结束，T1、T2的最终结果都是相同的，隔离性主要靠锁实现

• 持久性：一旦事务提交，不管发生什么，数据要保存到数据库中

• 一致性：只有合法的数据（依照关系约束和函数约束）才能写入数据库

BASE

• Basically Available 基本可用：系统在出现不可预知的故障时，允许损失部分可用性，如响应时间上的损失或功能上的损失

• Soft state 软状态：允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

• Eventually consistent 最终一致性：指系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态，因此最终一致性的本质是需要系统保证数据能够达到一致，而不需要实时保证系统数据的强一致性



分布式一致性ZooKeeper

分布式系统脑裂

不同服务器获得了互相冲突的数据或者指令，导致整个集群陷入混乱，数据损坏

分布式一致性算法Paxos

三个角色

Proposer

Acceptor

Learner



Zab协议