目录
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万)时,不建议使用数据库中间件。而数据量大时,根据自己需求选择合适中间件即可。
来源:oschina
链接:https://my.oschina.net/u/4361381/blog/4456420