07- 数据库存储架构

一、数据库读写分离

【实现原理】 

1. 数据库服务器搭建主从集群，一主一从、一主多从都 可以。 

2. 数据库主机负责读写操作，从机只负责读操作。 

3. 数据库主机通过复制将数据同步到从机，每台数据 库服务器都存储了所有的业务数据。 

3. 业务服务器将写操作发给数据库主机，将读操作发 给数据库从机。 

【如何判断什么时候要读写分离？】 

 随着业务量的持续增长，看系统的瓶颈问题。

1. 一开始的时候要先优化(优化索引，加入缓存)，考虑数据冷热分离

2. 如果上面的方法都不行，这个时候就应该考虑数据库的读写分离了

数据库读写分离复杂度分析

1. 复制延迟； 2. 任务分解

数据库读写分离复制延迟

通常使用方法 3，一开始要定义清楚了关键业务有哪些。不容易代码留坑，把关的人会比较多。

数据库读写分离任务分解

数据库分库分表

读写分离的主机写入毕竟还是有性能限制的，当主机的写入成为瓶颈的时候。就要考虑加机器(叠加法则)，来进行分库，

分表了。

加了机器之后应该怎么写，就带来了新的复杂度。

数据分库

这里也就是模块 2 的 任务分解，不同的商品时间写入到不同的数据库。

这里是要把这些数据库放到了不同的机器上去。

数据分表

当一个表有 200 个字段的时候，也就是列很多的时候，就要考虑垂直拆分。

水平拆分的意思是表行数特别多的进行拆分。

MySQL B+数存储的结构，以及它每一页上存储的行数，3 层算出来的时候就是 2000 万。

InnoDB 所有的读写请求都是先在缓存里做的，然后再走磁盘。

水平分表复杂度和应对方法

现在都可以用 Sharding-JDBC 封装了

水平分表伸缩瓶颈

分布式事务算法 - 2PC

(

  如果想让分布式部署的多台机器中的数据保持一致性，那么就要保证在所有节点的数据写操作，要不全部都执行，要么全部的都不执行。

  但是，一台机器在执行本地事务的时候无法知道其他机器中的本地事务的执行结果。所以他也就不知道本次事务到底应该 commit 还是 roolback。所以，常规的解决办法就是引入一个“协调者”的组件来统一调度所有分布式  节点的执行。

  为了解决这种分布式一致性问题，前人在性能和数据一致性的反反复复权衡过程中总结了许多典型的协议和算法。其中比较著名的有二阶提交协议（Two Phase Commitment Protocol）、三阶提交协议（Three Phase Commitment Protocol）和 Paxos 算法)

分布式事务算法 - 3PC

这里就是简单原则的具体场景，2PC 应用的更广。

MySQL XA 2PC 算法案例

在这里所谓的事物协调者就是代码。