MySQL 复制

MySQL 主从复制

MySQL 一主多从复制

一主多从复制的优点

• 分摊负载
• 专机专用
• 便于冷备
• 高可用

MySQL 主主复制

MySQL 主主失效恢复

MySQL 主主失效的维护过程

MySQL 复制注意事项：

• 主主复制的两个数据库不能并发写入。
• 复制只是增加了数据的读并发处理能力，没有增加写并发能力和存储能力。
• 更新表结构会导致巨大的同步延迟。

数据分片

• 分片目标
• 分片特点
• 分片原理

分片目标

映射表实践中使用不多，因为引入了数据存储的复杂度。

数据分片的挑战

• 需要大量的额外代码，处理逻辑隐藏变的更加复杂。
• 无法执行多分片的联合查询。
• 无法使用数据库的事务。
• 随着数据的增长，如何增加更多的服务器。

分布式数据库中间件

Amoeba/Cobar 架构

Cobar 系统组件模型

路由配置示例

如何做集群的伸缩

实践中的扩容策略

数据库部署方案-单一服务与单一数据库

数据库部署方案-主从复制实现伸缩

数据库部署方案-两个web服务及两个数据库

业务分库。读写能力提升一倍。

数据库部署方案-综合部署

先业务分库，后做数据分片。

NoSQL

CAP 原理

一致性（Consistency）：

• 每次读取的数据都是最近写入的数据或者返回一个错误，而不是过期数据，也就是，数据是一致的。

可用性（Availability）：

• 每次请求都应该得到一个响应，而不是返回一个错误或者失去响应，不过这个响应不需要保证数据是最近写入的（Every request receives a (non-error) response, without the guarantee that it contains the most recent write）。系统正常使用，不引起调用者异常，但不保证响应的数据是最新的。

分区耐受性（Partition tolerance）：

• 即使因为网络原因，部分服务器节点之间消息丢失或者延迟，系统依然可以操作（The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes）。

CAP 原理：

• 网络分区失效时，要么取消操作，这样数据一致但系统不可用，要么继续操作数据写入，这样系统可用但数据一致性得不到保证。
• 对于分布式系统而言，网络失效一定会发生，也就是说分区耐受性是必须要保证的，那么在可用性和一致性上就必须二选一。
• 当网络分区失效，也就是网络不可用时，如果选择一致性，系统就可能会返回一个错误码或者干脆超时，即系统不可用。如果选择了可用性，系统总是可以返回一个数据，但是并不能保证这个数据是最新的。
• CAP 准确说法：在分布式系统必须满足分区耐受性的前提下，可用性和一致性无法同时满足。

CAP 原理和数据存储冲突

最终一致性

最终一致性写冲突

简单冲突处理策略：根据时间戳，最后写入覆盖。

客户端冲突解决

投票解决冲突

Cassandra 分布式解决方案

Hbase 架构

Zookeeper 解决 HMaster 的高可用问题，进行集群管理。

Log Structed Merge Tree

ACID 与 BASE

ACID：

• 原子性(Atomicity)：事务要么全部完成，要么全部取消。如果事务崩溃，状态回到事务之前(事务回滚)。
• 隔离性(Isolation)：两个事务同时运行，事务 T1 和 T2 最终的结果是相同的，不过 T1 和 T2 谁先结束，隔离性主要依靠锁实现。
• 持久性(Durability)：一旦事务提交，不管发生什么（崩溃或者出错），数据要保存再数据库中。
• 一致性(Consistency)：只有合法的数据（依照关系约束和函数约束）才能写入数据库。

BASE：

• 基本可用（Basically Available）
  • 系统在出现不可预知故障时，允许损失部分可用性，如响应时间上的损失或功能上的损失。
• Soft state（弱状态）
  • 允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
• Eventually
  • 系统中的所有数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态，因此最终一致性的本质是需要系统保证数据能够达到一致，而不需要实时保证系统数据的强一致性。