数据库中间件浅谈

一. 优缺点：

---

1. 优点：

• 架构相对简单
• 单机事务延迟低，应用充分适配后（全单机事务）可以在位置原有延迟低基础上获得TPS的线性提升
• 对底层的关系型数据库改动不大，运维经验可以复用

2. 缺点：

• 只适用于简单业务，同时对业务有侵入性，需要改造
• 很难支持跨分片的高性能复杂查询

    如果业务进行了垂直拆分，例如user表在A服务器上，product表在B服务器上。那么如果涉及到连表查询时就会有性能瓶颈。
    so，一般都进行表的水平拆分，再做一主多从，读写分离。
  

• 分布式事务性能损失（扩展问题：为什么会有性能牺牲）

  传统的解决方案：如果一个事务中同时包含了读请求(如select)和写请求(如insert)，如果读请求走从库，写请求走主库，由于跨了多个库，那么本地事务已经无法控制，属于分布式事务的范畴。而分布式事务非常复杂且效率较低。因此对于读写分离，目前主流的做法是，事务中的所有sql统一都走主库，由于只涉及到一个库，本地事务就可以搞定。
  

• 水平扩展能力差，只能按照选定的分片规则横向扩展
• 大型集群运维困难
  1. 表结构变更（DDL）操作困难，容易出现失误
2. 只能按照分片进行维护（备份，恢复操作）
• 主从数据同步延迟问题

  因为数据是从master节点通过网络同步给多个slave节点，因此必然存在延迟。
  因此有可能出现我们在master节点中已经插入了数据，但是从slave节点却读取不到的问题。
  对于一些强一致性的业务场景，要求插入后必须能读取到，因此对于这种情况，我们需要提供一种方式，让读请求也可以走主库，而主库上的数据必然是最新的。
  

二. 水平拆分和垂直拆分

---

• 挑战1：基本的数据库增删改功能

sql解析：首先对sql进行解析，得到需要插入的四条记录的id字段的值分别为1,2,3,4

sql路由：sql路由包括库路由和表路由。库路由用于确定这条记录应该插入哪个库，表路由用于确定这条记录应该插入哪个表。

sql改写：因为一条记录只能插入到一个库中，而上述批量插入的语法将会在 每个库中都插入四条记录，明显是不合适的，因此需要对sql进行改写，每个库只插入一条记录。

sql执行：一条sql经过改写后变成了多条sql，为了提升效率应该并发的到不同的库上去执行，而不是按照顺序逐一执行

结果集合并：每个sql执行之后，都会有一个执行结果，我们需要对分库分表的结果集进行合并，从而得到一个完整的结果。

• 挑战2：分布式id

需要有一个全局的id生成器。目前分布式id有很多中方案，其中一个比较轻量级的方案是twitter的snowflake算法。

• 挑战3：分布式事务

mysql支持XA事务，但是效率较低。柔性事务是目前比较主流的方案，柔性事务包括：最大努力通知型、可靠消息最终一致性方案以及TCC两阶段提交。但是无论XA事务还是柔性事务，实现起来都是非常复杂的。
总结方案如下：
1.XA 方案
2.TCC 方案
3.本地消息表
4.可靠消息最终一致性方案
5.最大努力通知方案

• 挑战4：动态扩容

动态扩容指的是增加分库分表的数量。