分布式系列十四: 分库分表

Posted 2021-02-17 walkinhalo

分库分表是为了应对业务系统在高并发,大数据量背景下而对数据存储进行的优化.

关于分表, 本人使用过SQLSERVER数据库有分区表, 表分区比起人为按一定策略分表有一定优势, 而且生产环境中表分区也一直运行良好. sqlserver2000有分区视图的概念, 而分区视图实际就是建立在分表基础上的, 为遵循分表策略的一系列表提供了一个统一的入口.

使用表分区或分表方案各有利弊, 具体还需视情况做权衡.

为什么要分库分表

• 提高查询性能
• 容量提升

分库分表的方法

• 垂直切分

  1. 垂直分库: 按照业务领域拆分, 每个库都存储了该业务领域内的数据. 这解决了表过多的问题
  2. 垂直分表: 解决了表中列过多的问题. 避免表过宽导致的查询性能问题.

• 水平切分

  防止表的数据量过大, 拆分的表结构完全相同, 也就是将数据分布到不同的表中, 可以是同一个库, 也可以是不同库.

拆分策略

• 垂直拆分: ER(Entity Relationship)分片, 需要注意相关的表拆分到同一个库, 防止join问题.

• 水平拆分

  1. 一致性hash(注意节点变化导致的问题)
  2. 范围 一般按自增id
  3. 日期

拆分带来的问题

1. 跨库join;

   解决方案: 设计前尽量考虑; 服务层调用; 使用全局表; 字段冗余;

2. 跨表排序

3. 唯一主键

   自增id导致的重复.
   UUID: 性能较低
   snowflake: 雪花算法
   zookeeper,redis,mongoDB
   数据库表

4. 分布式事务

   互联网很少使用强一致性分布式事务, 但使用时就必须考虑.

分库分表的难度在于业务

如何权衡当前公司存储需要优化

• 提前规划 (主键, 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可以提供应用层解决方案