数据库中间件

为什么要使用数据库中间件

数据库存储的数据量不是很大，但是并发读写的操作都很大，超过数据库服务器的处理能力。
第一：加缓存，但是缓存也会出现不会命中的情况，这样还是会有大量的读写操作进入数据库。
第二：读写分离，通过主从的方式，把读操作和写操作分离开，然后同步主服务器和从服务器的数据。但是读写要分别操作不同的库，对DAO层的代码有影响吗？如何隔离这种变化呢？
因此，我们需要增加数据库访问模块-----数据库中间件，专门来负责sql语句的分发

但是如果应用业务的模块很多，总的数据量很大，并发读写操作均超过单个数据库服务器的处理能力该怎么办？
1、对于读压力，我们可以想什么办法？
集群，多个从库，需要数据库中间件能够把多个请求均匀分发到多个从服务器，负载均衡的能力。
2、对于写压力呢？
不能多个相同的主库。
原因:
多个主库间数据同步，难保证数据一致性。
数据量大单库存不下来。
解决：分库，因此在数据量很大而且并发压力很大的情况下，我们需要分库+读写分离。
如果单表的数据量很大，超出了单表的上限，怎么办？
分表：根据一定的规则将数据库分到多个表中存储

阿里云-RDS版本的mysql性能测试结果

数据库中间件的设计要点

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

数据库拆分-垂直拆分
按业务模块垂直拆分

优点：
拆分后业务清晰，拆分规则明确
系统之间整合或扩展容易
数据维护简单
缺点:
部分业务表无法join，只能通过接口方式解决，提高了系统复杂度
受每种业务不同的限制存在单库性能瓶颈，不易数据扩展和性能提高
事务处理复杂

数据库拆分-水平拆分

优点：
拆分规则抽象，join操作基本可以数据库做
不存在单库大数据，高并发的性能瓶颈
应用端改造较少
缺点：
拆分规则难以抽象
分片事务一致性难以解决
数据多次扩展难度跟维护量极大
跨库join性能较差

拆分规则有：
范围：时间、数值
列表：按地域、组织、分类
散列：hash(某个字段)%分片数、一致性hash
符合多种方式

分库分表的技术难点：
无论是垂直拆分、水平拆分，都有共同的技术难点
1、引入分布式事务问题
2、跨结点join问题
3、跨结点合并排序分页问题
4、多数据源管理问题

数据库中间的2种实现模式
客户端模式

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

服务端(代理)模式：

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

常见的数据库中间件简介

Mycat

Mycat是什么？
Mycat数据库分库分表中间件，国内最活跃、性能最好的开源数据库中间件！
1、一个彻底开源的，面向企业应用开发的大数据库集群
2、支持事务、ACID、可以题带MySQL的加强版数据库
3、一个可以视为MySQL集群的企业级数据库，用来替代昂贵的Oracle集群
4、一个融合内存缓存技术、NoSQL技术、HDFS大数据的新型SQL Server
5、结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品
6、一个新颖的数据库中间产品

Mycat应用场景
1、单纯的读写分离、配置最为简单，支持读写分离，主从切换
2、分表分库，对于超过1000万的表进行分片，最大支持1000亿的单表分片
3、多租户应用，每个应用一个库，但应用程序只连接Mycat,从而不改造程序本身，实现多租户化。
4、报表系统，借助于Mycat的分表能力，处理大规模报表的统计
5、替代Hbase，分析大数据
6、作为海量数据实时查询的一种简单有效方案，比如100亿条频繁查询的记录需要在3秒内查询出结果，除了基于主键的查询，还可能存在范围内查询或属性查询，此时Mycat可能是最简单有效的选择

Mycat的工作原理

“拦截”，它拦截了用户发送过来的SQL语句，首先解析SQL语句，做一些特定的分析，如何分片分析、路由分析、读写分离分析、缓存分析等；然后将此SQL发往后端的真实数据库，并将返回的结果做适当的应用，最终再返回给用户

Mycat架构

Mycat高可用方案

mycat1.6架构