1. MySQL

1.1 MySQL主从复制

主从复制



1.2 MySQL一主多从复制

一主多从复制



1.3 一主多从的优点

1.3.1 分摊负载

1.3.2 专机专用

1.3.3 便于冷备

1.3.4 高可用

1.4 MySQL主主复制

mysql主主复制



mysql主主复制失效恢复



mysql主主失效的维护过程

1.5 MySQL复制注意事项

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

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

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

1.6 数据分片

1.6.1 分片目标

1.6.2 分片特点

1.6.3 分片原理

1.6.3.1 硬编码实现数据分片

硬编码实现数据分片



1.6.3.2 映射表外部存储

映射表外部存储

1.6.4 数据分片的挑战

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

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

• 无法使用数据库的事务

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

1.6.5 分布式数据库中间件

分布式数据库中间件

1.6.6 Amoeba/Cobar架构

Amoeba/Cobar架构



Cobar系统组件模型



路由配置示例



如何做集群的伸缩



实践中的扩容策略

1.6.7 数据库部署方案

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



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



数据库部署方案—两个Web服务器及两个数据库



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

2 NoSQL

2.1 CAP原理

Consistency一致性

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

Available 可用性

每次请求都能得到一个响应，而不是返回一个错误或者失去响应，不过这个响应不需要保证数据是最近写入的，也就是说系统需要一直都是可以使用的，不会引起调用者的异常，但是并不保证响应的数据是最新的

Partition tolerance 分区耐受性

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



CAP原理

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

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

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

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

2.2 ACID

2.2.1 原子性Atomicity

事务要么全部完成，要么全部取消。如果事务崩溃，状态回到事务之前(事务回滚)

2.2.2 隔离性Isolation

如果两个事务T1和T2同时运行，事务T1和T2最终的结果是相互独立的，不管T1和T2谁先结束，隔离性主要依靠锁实现。

2.2.3 持久性Duration

一旦事务提交，不管发生什么(崩溃或出错)，数据要保存在数据库中。

2.2.4 一致性Consistency

只有合法的数据(依照关系约束和函数约束)才能写入数据库。

2.3 BASE

基本可用(Basically Available)

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

Soft state(弱状态)软状态

指允许系统中的数据存在中间状态，并认为中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延迟。

Eventually consistent 最终一致性

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