Chinaunix首页 | 论坛 | 博客
  • 博客访问: 90787
  • 博文数量: 70
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 743
  • 用 户 组: 普通用户
  • 注册时间: 2016-09-22 09:50
  • 认证徽章:
个人简介

一个守望数据库的老菜鸟

文章分类

全部博文(70)

文章存档

2018年(9)

2017年(37)

2016年(24)

我的朋友

分类: Mysql/postgreSQL

2018-01-01 09:36:03

博客文章除注明转载外,均为原创。转载请注明出处。
本文链接地址:http://blog.chinaunix.net/uid-31396856-id-5781751.html

       本文是mycat笔记整理:
       Mycat是一个开源的数据库中间件。在业务和数据库中间提供的代理层,介于数据库与应用之间,进行数据处理与交互的中间服务,其核心功能分库分表。
1.mycat原理
       Mycat接收前段对数据库对访问请求,是通过模拟MySQL协议的接口实现的。在前端同Mycat建立会话连接后,将请求的SQL发给Mycat后,mycat并不是直接交由数据库处理。而是对sql进行拦截后,进行解析优化、分片分析、读写分离分析、缓存分析,根据解析的结果进行路由处理。把sql发给复合规则的后端数据库群执行。
     Mycat同后端数据库使用基于MySQL实例的连接池方式进行通信,mycat接收后端数据库返回的执行结果,对结果进行处理,比如分页处理,排序处理、聚合处理、结果集合并等等,然后返回前端业务层。Mycat实现实现读写分离和分片分库,甚至备份容灾等功能。
架构如下图
      


图1:架构图(出自官方)
      Mycat实现了MySQL协议,前端用户可以把它看作是一个数据库代理,用MySQL客户端工具和命令行访问,而其后端可以用MySQL原生协议与多个MySQL服务器通信,也可以用JDBC协议与大多数主流数据库服务器通信,其核心功能是分表分库,即将一个大表水平分割为N个小表,存储在后端MySQL服务器里或者其他数据库里。


2.Mycat SQL机制

下图说明Mycat的SQL拦截机制

有上图可知,mycat模拟MySQL的socket协议或者jdbc协议同业务端(application)连接,在接收到SQL后,并不是直接发给MySQL数据库,而是在SQL解析器组件对SQL进行解析优化,通过SQL Router中对SQL进行路由分析,进行匹配路由规则匹配,然后交给SQL执行组件,发送到响应的写、读数据库的分片节点,执行SQL。SQL执行简单过程如下所示:    


      当Mycat收到前端发送的一个SQL时,首先会先解析这个SQL,查找涉及到的表,然后看此表的定义,如果有分片规则,则获取到SQL里分片字段的值,并匹配分片函数,得到该SQL对应的分片列表,然后将SQL发往这些分片去执行,最后收集和处理所有分片返回的结果数据,并输出到客户端。以select * from orders where area='xxx'语句为例,查到area='beijing',按照分片函数,beijing返回dn1,于是SQL就发给了MySQL1,去取DB1上的查询结果,并返回给用户。




     如果上述SQL改为select * from orders where area in ('shanghai','beijing),那么,SQL就会发给MySQL1与MySQL2去执行,然后将Dn1和Dn2返回的结果集进行合并(merge)处理后输出给用户。


3.Mycat主要线程说明
(1)Timer线程:调度线程,是一个单线程,负责调度,任务的具体动作交给 timerExecutor。
(2) TimerExecutor(线程池)
默认大小 N=2,任务通过 timer 单线程和 timerExecutor 线程池这种1+N模式共同完成。但是 timerExecutor 跟 aioExecutor 大小默认一样,不太合理,定时任务没有那么大的运算量。
(3) NIOConnect: 主动连接事件分离器,负责作为客户端连接 MySQL 的主动连接事件
(4)Server 被动连接事件分离器,负责作为服务端接收来自业务系统的连接事件
(5) Manager线程:被动连接事件分离器,负责作为服务端接收来自管理系统的连接事件
(6)NIOReactor 读写事件分离器
默认个数 N=processor size,通道建立连接后处理 NIO 读写事件。
由于写是采用通道空闲时其它线程直接写,只有写繁忙时才会注册写事件,再由 NIOReactor 分发。NIOReactor 主要是处理读操作
(7)BusinessExecutor 线程池
默认大小 N=processor size,任务队列采用的 LinkedTransferQueue
所有的 NIOReactor 把读出的数据交给 BusinessExecutor 做下一步的业务操作
全局只有一个 BusinessExecutor 线程池,所有链接通道随机分成多个组,然后每组的多个通道共享一Reactor,所有的 Reactor 读取且解码后的数据下一步处理操作,又共享一个 BusinessExecutor 线程池

4.Mycat使用的原则
(1)分库分表原则:
原则一:能不分就不分。
        分表是为了解决的问题,但是也会带来性能上的损失。 所以分片第一原则是:能不分就不分。对于1000 万以内的表,不建议分片,通过合适的索引,读写分离等方式,可以很好的解决性能问题。
原则二:分片数量尽量少,分片尽量均匀分布在多个 DataHost 上
        因为一个查询 SQL 跨分片越多,则总体性能越差,虽然要好于所有数据在一个分片的结果,只在必要的时候进行扩容,增加分片数量。
原则三:分片规则需要慎重选择。    
       分片规则的选择,需要考虑数据的增长模式,数据的访问模式,分片关联性问题,以及分片扩容问题,最近的分片策略为范围分片,枚举分片,一致性 Hash 分片,这几种分片都有利于扩容
原则四:尽量不要在一个事务中的 SQL 跨越多个分片,分布式事务一直是个不好处理的问题
原则五:查询条件尽量优化,尽量避免 Select * 的方式,大量数据结果集下,会消耗大量带宽和 CPU 资源,查询尽量避免返回大量结果集,并且尽量为频繁使用的查询语句建立索引。

(2)数据拆分原则
1. 达到一定数量级才拆分( 800 万左右)。
2. 不到 800 万但跟大表(超 800 万的表)有关联查询的表也要拆分,在此称为大表关联表。
3. 大表关联表如何拆:
     小于 100 万的使用全局表;
     大于 100 万小于 800 万跟大表使用同样的拆分策略;
     无法跟大表使用相同规则的,可以考虑从 java 代码上分步骤查询,不用关联查询,或者采用特例使用全局表。
4. 使用全局表。
       全局表的作用:可充当数据字典表,这张数据表会在所有的数据库中存在,但对外而言,只是一个逻辑数据库存在的数据表,当对该表进行变更操作时,所有数据库的该表都会发生相应的变化。

       满足于global表的条件是:很少对表进行并发 update,如多线程同时 update 同一条 id=1 的记录(多线程 update,但不是操作同一行记录是可以的,多线程 update 全局表的同一行记录会死锁)。批量 insert没问题。
符合使用全局表的特征:
   变动不频繁,很少对表进行并发update
   数据量总体变化不大
   数据规模不大,很少有超过数十万条记录。

5. 拆分字段是不可修改的
6. 拆分字段只能是一个字段,如果想按照两个字段拆分,必须新建一个冗余字段,冗余字段的值使用两个字段的值拼接而成(如大区+年月拼成 zone_yyyymm 字段)。
7.拆分算法的选择和合理性评判:按照选定的算法拆分后每个库中单表不得超过 800 万
8. 能不拆的就尽量不拆。如果某个表不跟其他表关联查询,数据量又少,直接不拆分,使用单库即可。

(3)DataNode 的分布问题
DataNode 代表 MySQL 数据库上的一个 Database,因此一个分片表的 DataNode 的分布可能有以下3种:
1.都在一个 DataHost 上.
2. 在几个 DataHost 上,但有连续性,比如 dn1 到 dn5 在 Server1 上, dn6 到 dn10 在 Server2上,依次类推.
3. 在几个 DataHost 上,但均匀分布,比如 dn1,dn2,d3 分别在 Server1,Server2,Server3 上, dn4 到 dn6 又重复如此.
第一种情况不大推荐。至于是采用数据连续性分布还是数据均匀分布要看具体情况。如果是要考虑高并发的IO的分布、热数据处理、尽可能提高sql响应时间,采取数据均匀分布;如果是考虑业务数据冷热分布,方便进行数据归档,则考虑数据连续分布。

5、分片规则
分片规则用于定义数据与分片的路由关系,也就是 insert, delete, update, select的基本 sql 操作中,如何将 sql 路由到对应的分片执行。
在分片之前,应该考虑以下因素:
分片要考虑数据的增长情况,是实时大量增长还是缓慢增长,数据和数据之间的关联关系。
通过抓取系统中实际执行的SQL,分析SQL的运行规律,频率、响应时间、对系统性能和功能的影响程度。
要保证系统中不同数据表的可靠性,以及操作模式。
业务的特点:系统中哪些业务操作是严格事务的,哪些是普通事务或可以无事务的。
要考虑数据的备份模式,对系统的影响。

分片后,SQL性能的损耗,据测算大约20%左右,因此在作分片处理的时候需要考虑
分片数据如何插入,在插入数据的时候,应考虑到数据分布多节点的特点,根据分片规则定位数据对应到相应的节点,分解SQL进行插入。
分片数据如何关联查询,应尽量避免大的关联查询,尽量使用小的事务,尽量使用简单的查询,尽量在前端进行一些数据处理操作。
分片数据删除。由于数据是分布在各个数据节点,进行数据删除的时候,尽量避免join操作。应该对数据进行分析,根据分片规则定位数据,在对应分片删除相应数据。
分片数据修改。把查询条件识别出来,然后执行一下分片函数即可定位到节点,再执行对应的SQL即可,对了提高执行效率,尽量避免join操操作,必须避免对分片键进行修改的操作。

分片键的选择需要考虑
尽可能将数据均匀的分布到各个节点
该业务字段是最频繁的或者最重要的查询条件
尽量避免跨库join操作;
尽量减少表join操作,可以考虑全局表,可以考虑适当的冗余字段等。

常用分片规则算法:
取模分库:mod-long
范围分库:auto-sharding-long
Hash分库:hash-int
分片枚举:hash-int
截取数字 hash :sharding-by-stringhash
自然月分库:sharding-by-month
按日期(天):sharding-by-date
日期范围hash:range-date-hash
冷热数据:sharding-by-hotdate
ER模型分库:childTable
自定义分库:CustomRule(该方式需要自己实现分库算法)

6.配置文件:
conf目录下面的三个配置文件:
schema.xml中定义逻辑库,表、分片节点等内容,逻辑库标签、datanode标签、datahost标签;
rule.xml中定义分片规则,包括分片规则标签和分片函数标签;
server.xml中定义用户以及系统相关变量,包括system标签、用户标签、防火墙标签等;

---The end
阅读(3372) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

vcdtwo2018-01-03 09:52:06

多谢分享。

评论热议
请登录后评论。

登录 注册