分布式系列十四: 分库分表
分库分表是为了应对业务系统在高并发,大数据量背景下而对数据存储进行的优化.
关于分表, 本人使用过SQLSERVER数据库有分区表, 表分区比起人为按一定策略分表有一定优势, 而且生产环境中表分区也一直运行良好. sqlserver2000有分区视图的概念, 而分区视图实际就是建立在分表基础上的, 为遵循分表策略的一系列表提供了一个统一的入口.
使用表分区或分表方案各有利弊, 具体还需视情况做权衡.
为什么要分库分表
- 提高查询性能
- 容量提升
分库分表的方法
-
垂直切分
- 垂直分库: 按照业务领域拆分, 每个库都存储了该业务领域内的数据. 这解决了表过多的问题
- 垂直分表: 解决了表中列过多的问题. 避免表过宽导致的查询性能问题.
-
水平切分
防止表的数据量过大, 拆分的表结构完全相同, 也就是将数据分布到不同的表中, 可以是同一个库, 也可以是不同库.
拆分策略
-
垂直拆分: ER(Entity Relationship)分片, 需要注意相关的表拆分到同一个库, 防止join问题.
-
水平拆分
- 一致性hash(注意节点变化导致的问题)
- 范围 一般按自增id
- 日期
拆分带来的问题
-
跨库join;
解决方案: 设计前尽量考虑; 服务层调用; 使用全局表; 字段冗余;
-
跨表排序
-
唯一主键
自增id导致的重复.
UUID: 性能较低
snowflake: 雪花算法
zookeeper,redis,mongoDB
数据库表 -
分布式事务
互联网很少使用强一致性分布式事务, 但使用时就必须考虑.
分库分表的难度在于业务
如何权衡当前公司存储需要优化
- 提前规划 (主键, join问题提前解决)
- 单表数据超过1000w, 且还在增长
表分区的缺点
- 分区字段不灵活, 可能导致表锁
- 关联查询的性能可能不高
- 自己分库分表有更大灵活性, 表分区将查询执行计划交给mysql, 对开发人员透明, 可能不好优化.
MySql 主从
可参看这篇文章
针对写少读多的情况. 可以配置多个只读从库, 使用HaProxy做负载均衡.
安装MySql
apt-get install mysql-server 安装最新版本的mysql
service mysql start 服务方式启动 或者转到目录/usr/bin使用 ./mysqld_safe &启动
service mysql stop 关闭, 或者使用mysqladmin -u root shutdown
GRANT ALL PRIVILEAGES ON *.* TO 'root'@'%' INDENTIFIED BY 'root' WITH GRANT OPTION 授权外网访问
主从配置
从节点创建用户 create user repl identified by 'repl'
从节点授权 grant replication slave on *.* to 'repl'@'%' identified by 'repl'
mysql的数据文件和二进制文件: /var/lib/mysql/
mysql配置文件: /etc/mysql/my.cnf
mysql的日志文件: /var/log/mysql/mysql.log
配置文件中my.cnf中:
主配置:
log-bin=mysql-bin //开启日志文件
server.id=123 //唯一id
show master status; 可以查看文件名称
从配置:
server.id=124
relay-log=slave-relay-bin //打开中继日志
relay-log-index=slave-relay-bin.index
read-only=1 //只读
从节点指定主服务器节点:
change master to master_host='192.168.11.123',master_port=3306,master_user='repl',master_password='repl',master_log_file='mysql.bin.000001',master_log_pos=154;
master_log_file='mysql.bin.000001',master_log_pos=154;就是使用show master status;查询到的信息.
从节点启动slave: start slave;
从节点查看状态: show slave status;
主从同步原理
Slave 中有两个线程, IO和SQL, 分别用来同步日志文件和执行sql.
master -> 写binlog -> slave IO/Thread -> replylog -> SQL/Thread -> slave DB
mysqlbinlog --base64-output=decode-rows -v mysql-bin.00001用来查看binlog日志文件内容
日志文件的存储与kafka的日志优点类似, 顺序存储, 分文件存储.
binlog文件的格式:
- statement 基于sql语句, 如
update A set name=name+'-'; effect row 1000 - row 基于行模式, 存在1000条数据变更, 记录变化的值 默认为row
- mixed 混合模式, mysql自行处理.
show binlog events in 'mysql-bin.00001' 查看日志文件的事件
show variablees like '%log%' //查看日志模式 statement row mixed
set global binlog_format='minxed' //设置模式 或者在配置文件中指定binlog_format=minxed
双主
都可以写数据, 可能存在数据不一致.
主从同步的问题
- 数据同步延时, 大量数据同步, 网络问题, IO阻塞
- 延时监控: Nagios, mk-heartbeat
redis可以提供应用层解决方案
