数据库中间件设计分析

1.为什么需要中间件

不分库篇

（1）普通的应用程序

• 数据库访问
  
  数据库存储的数据量不是很大，但并发的读写操作都很大，超过数据库服务器的处理能力。

阿里云-RDS版MySQL性能测试结果（MySQL 5.6）
TPS：每秒钟处理事务数量
QPS：每秒钟SQL语句执行条数（并发请求数）

（2）并发读写大–缓存

业务场景：数据量不是很大，仅并发读写超过数据库服务器的处理能力
解决办法： 加缓存

（3）缓存过期问题–读写分离+缓存

业务场景：缓存会有过期命不中，还是会有大量的读和全部的写操作将请求数据库，如果数据库支持不起，怎么办？
解决办法：读写分离+缓存

（4）隔离对DAO层影响–数据库中间件+读写分离+缓存

业务场景：读写要分别操作不同的库，对DAO层的代码有什么影响吗？如何隔离这种变化？
数据量不是很大，仅并发读写超过数据库服务器的处理能力的
解决办法：数据库中间件+读写分离+缓存

（5）业务模块多–集群+数据库中间件+读写分离+缓存

业务场景：应用的业务模块很多，总的数据量很大，并发读写操作均超过单个数据库服务器的处理能力。
解决办法：集群+数据库中间件+读写分离+缓存
1.对于读压力，我们可以想什么办法?
集群，多个从库
思考：此时数据库中间件需要具备什么能力?负载均衡

2.对于写压力呢?
能集群，多个主库吗?
不能多个相同的主库

分库篇

（1）业务模块多，数据总量大–分库+缓存

业务场景：应用的业务模块很多，总的数据量很大，并发读写操作均超过单个数据库服务器的处理能力。

思路分析
不能多个相同主库的原因?

• 多个主库间数据同步，难保证数据一致性
  数据量大单库存不下来。

那咋办?

• 分库
  如何分库?
  按业务模块分成多个数据库

解决方案 分库+读写分离+缓存

（2）分库对Dao层代码影响–分库+数据库中间件+缓存

业务场景：可能要操作多个库，对DAO层的代码有影响吗?如果要跨库关联查询，怎么办?
需要数据库中间件来处理
解决方案：分库+数据库中间件+读写分离+缓存

（3）读写压力大–分库+读写分离+数据库中间件+缓存

如果某业务数据库的读写压力大，怎么办？

业务场景：如果单表的数据量很大，超出了单表上线，如电商网站的商品列表、订单表等。
解决方案：数据量很大，并发压力很大：分库+读写分离+数据库中间件+缓存

分区表、分表

1.如何分?
根据一定规则将数据分到多个表中存储
可以有怎样的分表规则?

2.分表的情况下，对DAO层数据访问有影响吗?
如何决定数据存储到哪个表?
如何查询多个表?
如何做到对DAO层透明?
对数据库中间件的能力要求很高

高并发、海量数据的情况下：

数据库存储的数据量不是很大，但并发的读写操作都很大，超过数据库服务器的处理能力。
应用的业务模块很多，总的数据量很大，并发读写操作均超过单个数据库服务器的处理能力。
如果单个表的数量很大，超出了单表的存储上限，如电商网站的商品表、订单表等。

为解决数据存储、访问性能问题我们需要数据库中间件。
数据库中间件让我们可以在应用程序中快速应用读写分离、分库分表!

2.数据库中间价设计要点

数据库中间件设计要点：

1要能解析SQL
2能支持读写分离
3能支持从库读的负载均衡
4支持分库操作
5支持分表操作
6支持跨库关联查询
7对事务处理的支持
8主键ID生成
9数据源管理

数据库拆分：垂直拆分、水平拆分

（1）垂直拆分

垂直拆分-分片规则
按照业务逻辑拆分

优点：
拆分后业务清晰，拆分规则明确；系统之间整合或扩展容易；
数据维护简单。

缺点：
部分业务表无法join，只能通过接口方式解决，提高了系统复杂度；
受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高；
事务处理复杂

（2）水平拆分

水平拆分-分片规则

水平对数据进行拆分最重要的是分片规则一拆分规则

可以如何来拆分?
范围：时间、数值；
列表：按地域、按组织、分类；
散列：hash(某个字段)%分片数、一致性hash；
复合多种方式。

优点：
拆分规则抽象好，join操作基本可以数据库做；
不不存在单库大数据，高并发的性能瓶颈；
应用端改造较少；
提高了系统的稳定性跟负载能力。

缺点：
拆分规则难以抽象；
分片事务一致性难以解决；
数据多次扩展难度跟维护量极大；
跨库join性能较差。

（3）无论是垂直拆分、水平拆分，都有共同的技术难点

引入分布式事务的问题；
跨节点Join的问题；
跨节点合并排序分页问题；
多数据源管理问题。

（4）数据库中间件的两种实现模式

客户端模式

客户端模式，在应用程序中集成数据库中间件模块，通过该模块来配置管理应用需要的一个(或者多个)数据源，以及访问各个数据源，在模块内完成数据的整合。

服务端(代理)模式，通过中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程序透明，同时易于数据库扩展。独立的服务能提供更强的处理能力。适用于大型复杂系统。

（5）常用数据库中间件简介

客户端模式
当当 sharding-jdbc
阿里 TDDL

proxy
社区 Mycat - cobar
数字 Atlas
百度 heinsberge
youtube vitess
金山 kingshard
商业版Oneproxy

数据库中间件对比

	Cobar	TDDL	ShardingJDBC（客户端常用）	MyCat（服务端常用）
分库支持	Yes	Yes	Yes	Yes
分表支持	No	Yes	Yes	Yes
类型	Proxy	客户端集成	客户端集成	Proxy
中间层	Yes	No	No	Yes
ORM支持	任意	多种	多种	多种
数据库支持	mysql	多种	多种	多种
外部依赖	No	Diamond	No	No
社区活跃度	停滞	停滞	较活跃	活跃
文档丰富	Yes	N/A	Yes	Yes
持续更新	No	N/A	Yes	Yes

• 通过对比常用数据库中间件，在客户端常用的是：ShardingJDBC，服务端常用的是：MyCat。

小结

无论是什么样的数据库中间件，解决业务需求，带来便利的同时，都可能引发数据不一致等问题，因此在数据量不大（少于1000万）时，不建议使用数据库中间件。而数据量大时，根据自己需求选择合适中间件即可。