数据库读写分离

读写分离解决了读的问题。读被分离出去了，写性能的提升还是会有的。

数据库慢不需要直接上读写分离，先尝试优化索引，加入缓存等操作。

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

任务分解：读请求打到从机，写请求打到主机，要分清读和写

数据库读写分离复制延迟

读取失败是指，insert而不是update，因为update的时候，你无法确定更新失败了，因为从是有数据的。

以上方法中，方法3相对好一些，简单很多。

数据库读写分离任务分解

程序代码封装模式：对于Java语言，maven直接引入jar包就可以了

程序代码封装模式不需要考虑高可用、高性能，因为程序代码封装模式嵌入到应用程序中，而应用程序已经考虑了高性能高可用了。

数据库分库分表

拿什么作为分表键：

如果ID是自增的，那么就可以直接用ID进行分段

如果ID不是自增的，那么可以用ID进行hash

按照时间进行分表，比如按照一天一个表

分库

之前用户数据、商品数据、订单数据都在同一个库里面，现在分为三个库（部署到不同的物理机器上），当操作用户数据的时候操作用户数据库，当操作商品数据的时候操作商品数据库，当操作订单数据的时候操作订单数据库。

分表

mysql InnoDB Buffer Pool 如果装不下表数据，那么性能就会急剧下降到原来的1/10。缓存如果不能缓存下来整个表数据，那么就会频繁的进行磁盘的读取，性能就会降低。

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

路由问题，需要知道哪个数据在哪个机器上（分片上）

count只能一个数据库一个数据库的count（手动）

现在sharding JDBC已经将如上问题给封装了。

水平分表能够通过加服务器来不断提升性能么?分表一定度是可以提升的，但是分的太细在某种场景下效果反而不好，比如计算总count，同时分的过多，服务器的连接数也会更多，此时性能会逐渐下降。

水平分表伸缩瓶颈

对于应用而言，Sharding-JDBC只有一个，分表越多，这里也会成为瓶颈

200连接是只活跃连接数，每个连接都有大量的请求

数据库分布式事务

分布式事务算法-2PC

分布式事务算法-3PC

这里的脑裂是指有的提交者提交了事务，有的提交者没有提交事务

2PC比3PC用的更多，3PC的交互更多，网络消耗更大，3PC更复杂，异常处理更难

XA

要想支持分布式事务，需要数据库层面的支持。事务协调者就是我们自己的代码。下面是一个简单例子。

思维导图