共计 2291 个字符,预计需要花费 6 分钟才能阅读完成。
一、Atlas 介绍
Atlas 是 360 开源的一个 Mysql Proxy,以下是官网介绍:
Atlas 是由 Qihoo 360 公司 Web 平台部基础架构团队开发保护的一个基于 MySQL 协定的数据中间层我的项目。它在 MySQL 官网推出的 MySQL-Proxy 0.8.2 版本的根底上,批改了大量 bug,增加了很多性能个性。目前该我的项目在 360 公司外部失去了广泛应用,很多 MySQL 业务曾经接入了 Atlas 平台,每天承载的读写申请数达几十亿条。同时,有超过 50 家公司在生产环境中部署了 Atlas,超过 800 人已退出了咱们的开发者交换群,并且这些数字还在一直减少。
https://github.com/Qihoo360/A…_ZH.md
以下是其 github 代码库:https://github.com/Qihoo360/A…
次要性能:
1. 读写拆散
2. 从库负载平衡
3.IP 过滤
4. 主动分表
5.DBA 可平滑高低线 DB
6. 主动摘除宕机的 DB
“主动分表”须要打引号,对于新表是没问题的;
如果是一张有历史数据的表须要拆分,Atlas 是不会帮咱们拆分的,就须要本人写工具迁徙。
二、装置
1、从官网下载相应版本,咱们抉择的是 2.2.1;
https://github.com/Qihoo360/A…
分表的形式有 2 种,1 是单机分表,另 1 种是反对跨机器分表,能够依据状况抉择,咱们抉择的是单机分表的,即一张总表拆成多张子表,子表和总表都在一个 Mysql 实例上。
2、装置
因为是 rpm 装置,间接用 rpm 命令装置就能够了:
rpm -i Atlas-2.2.1.el6.x86_64.rpm
默认装置目录为 /usr/local/mysql-proxy。
启动命令
/usr/local/mysql-proxy/bin/mysql-proxyd test start
test 示意哪个实例
配置文件在 usr/local/mysql-proxy/conf 下,每个配置文件示意一个实例;
3、配置阐明
以下是罕用的配置项:
配置项 | 阐明 |
---|---|
admin-username | 后盾管理员账号 |
admin-password | 后盾管理员明码 |
proxy-backend-addresses | Mysql 实例,多项以,(逗号) 分隔 |
pwds | 明码,必须和 Mysql 实例的明码一样,用装置目录 bin 目录下的加密程序 encrypt 加密 |
event-threads | 工作线程数,对性能影响大 |
sql-log | SQL 日志的开关,可设置为 OFF、ON、REALTIME,OFF 代表不记录 SQL 日志,ON 代表记录 SQL 日志,REALTIME 代表记录 SQL 日志且实时写入磁盘 |
proxy-address | Atlas 监听的工作接口 IP 和端口 |
tables | tables |
要害参数:
proxy-backend-addresses:后端 Mysql 实例地址
tables:分表参数,格局:
数据库名. 表名. 分表字段. 子表数量
举 1 个栗子,如果咱们在做社区,社区次要性能是发帖和回帖,那次要是 2 张表(只是为了演示,不会把实在理论场景所有字段加上):
帖子表 (posts)
字段名 | 类型 | 阐明 |
---|---|---|
tid | int | 帖子 id |
title | varchar(200) | 帖子题目 |
content | text | 帖子内容 |
回复表 (replies)
字段名 | 类型 | 阐明 |
---|---|---|
pid | int | 回复 id |
tid | int | 帖子 id |
uid | int | 用户 id |
content | text | 回复内容 |
create_time | datetime | 插入工夫 |
假如这些表都在数据库 forums 中,
如果咱们要对 replies 进行分表,则 tables 这样设置
forums.replies.tid.64
下面示意对 replies 进行分表,分表字段为 tid,即所有 tid 雷同的回复会在同一张表,总共分 64 张表。
三、踩过的坑
1、Atlas 不反对压缩选项,以下连贯是不行的
mysql_connect($dbhost, $dbuser, $dbpw, 1, MYSQL_CLIENT_COMPRESS);
正确的写法
mysql_connect($dbhost, $dbuser, $dbpw, 1);
2. Count 语句问题
分表后,count 返回的后果会是针对多个表查问的多个值(count 后果为 0 的不返回),具体示例如下(以后分表为 4 张):
3. 分表后,如果删掉主表,则不带分表字段的查问会报错(如下图);如果保留主表,则查问的是主表数据。
4. 分页问题
以下面举例的场景来说,如果要从回复表查问 uid 为 123,并且 tid 为 100-200 之间的记录的第 2 页(Discuz 里就是这样查用户的回复的),每页显示 10 条,按工夫倒序,就有可能返回为空了;
为什么这样呢,构想这样一个场景,用户一共有 40 条回复,假如散布在 4 张表中,并且散布很平均,每张表 10 条记录,因为从每张子表取偏移 10-20 的记录,子表返回为空了,理论是用户是有数据的,正确的做法是从每张表取出前 20 条记录,再合并而后进行分页。
对于这个问题,我曾经在另一篇文章具体阐明了,Mysql 中间件 360 Atlas 踩坑
四、总结
1、如果你是新表,并且预感当前数据很大,能够用上 Atlas 来解决数据量的问题;
2、旧表的话,你还得本人写脚本导数据,核查数据;
3、如果有些分页查问的话,还须要本人重写;
4、确定你的所有场景的查问是否都有分表字段作为 where,没有的话,须要本人再写工具将子表的数据同步到总表;
能够看到 Atlas 如果须要产品化还要做很多的事件,如果确定下面都不是问题,就大胆的用吧~
往期精彩文章:
FastDFS 不同步怎么破
Dubbo2.7 试用
redis-port 反对前缀迁徙
扩大 Redis:减少 Redis 命令