一 数据库读写分离

适应场景：互联网读多写少。

原理：主机负责写，从机可以多个负责读取。数据主从做同步。

业务的写发给主机，读操作发给从机。

条件：1业务量增长 2 其他优化条件已处理（索引优化、缓存）等再重构。

代价：1 复制延迟 2 任务分解

任务分解本身是 为了引入读写分离做的改造。为了避免复制延迟影响业务不一致。

 通常方式，关键业务（比如订单、支付）读写全部指向主机，非关键业务采取读写分离。

这是一种折中，定了软件架构规范后，开发、测试会关注到这个点，后续的代码review也可以二次校验。

落地的模式：代码封装模式与中间件proxy模式

 二数据库的分库分表

适应场景：主机节点写入性能瓶颈

分库带来的挑战： join 查询，要么冗余数据，要么在代码实现join 功能（内存做关联）

事务问题：使用分布式事务。如库存与订单

分表：垂直拆分

这种通常是字段多的表，抛去大字段，有的大表100来个字段，这种明显比常见的10来个 字段要慢。

水平拆分：提示系统的性能。

大表1000w条可以考虑拆分。这个经验数据。也有是2000w的。

水平拆分难度在于拆分规则的确定，也就是路由。因为其他的框架shardingsphere都帮你实现好了

常见的用户的维度、商家的维度异构方式。常见的采取冗余策略。双写啊，消息等都可以。

 还有个挑战：怎么进行数据迁移。还有弹性扩容的问题

数据库分布式事务

简单的提了下2pc,3pc