数据库优化之复制策略和分库分表

数据库优化 之 复制策略

复制策略

由于业务快速发展，访问量不断增加，拆分的某些数据库要越来越大，当达到能力的瓶颈时，数据库架构需再次进行变更，这时就需要复制策略对系统扩展。   复制策略通过异步复制机制，把数据复制到从库，这时我们就可以在从库分担一部分数据库的压力

复制策略工作流

mysql复制基础

• mysql复制为异步复制
• mysql复制基于binLog
• mysql复制可对整个实例进行复制，也可以指定某个库，某个表进行复制

异步复制

   由于mysql复制为异步复制，所带来的问题是主从数据同步延迟。延迟的时间由写入量决定。   延迟原因：由于mysql的写入、更新操作是并行的，而binLog的IO是单线程，relayLog的IO默认也是单线程，从而导致同步的延迟。

BinLog

BinLog日志格式：
statement：存储sql语句，日志量最小
row：记录每一行数据更改的细节，日志量大
mixed：根据执行的每条sql来区分对待日志记录形式

部分复制

Master端控制
binglog-do-db 选择数据库
binglog-ignore-db 忽略数据库

Slave端控制
replicate-do-db 选择数据库
replicate-ignore-db 忽略数据库
replicate-do-table 选择表
replicate-ignore-table 忽略表
replicate-wild-do-table 选择某些表
replicate-wild-ignore-table 忽略某些表

复制策略应用：读写分离

master-slave架构

master-master架构

数据库复制策略实践

环境准备

master与slave数据库版本要求一致
mysql版本：5.5
主节点ip：
从节点ip：
master与slave网络相通（配置防火墙）
测试环境下关闭防火墙：
centos7：sudo systemctl stop friewalld.service

安装mysql服务

centos7安装mysql服务
sudo yum install -y mariadb mariadb-server
node1 & node2进行同样操作
启动mysql服务
sudo systemctl start mariadb

yum :Yum（全称为 Yellow dog Updater, Modified）是一个在Fedora和RedHat以及CentOS中的Shell前端软件包管理器。基于RPM包管理，能够从指定的服务器自动下载RPM包并且安装，可以自动处理依赖性关系，并且一次安装所有依赖的软件包，无须繁琐地一次次下载、安装。[1]

配置主服务器

mysql服务配置文件目录 /etc/my.cnf
修改配置文件，设置server_id，开启二进制日志（log-bin）
sudo vim /etc/my.cnf
添加配置信息[mysqld]
server-id=101
log-bin=mysql-bin
binlog_format=mixed
重启mysql服务
sudo systemctl restart mariadb

创建同步账号

创建账号
GRANT REPLICATION SLAVE ON . TO ‘username’@’192.168.33.%’ IDENTIFIED BY ‘password’;
FLUSH PRIVILEGES;

查看主库状态

show master status\G

配置从服务器

修改配置文件，设置server_id
sudo vim /etc/my.cnf
添加配置信息[mysqld]
server-id=102

slave配置

slave连接maste
CHANGE MASTER TO MASTER_HOST=’192.168.33.101’,
MASTER_USER=’username’,
MASTER_PASSWORD=’password’,
MASTER_LOG_FILE=’mysql-bin.000003’,
MASTER_LOG_POS=669;
开启slave
start slave;
查看slave 状态
show slave status\G

slave状态

slave_IO_Running:Yes
slave_SQL_Running:Yes
当这两个状态为YES时，主从配置完成

哈哈，献上我配好的主从数据库

注意事项：
1、
主

GRANT REPLICATION SLAVE ON *.* TO '账户'@'ip' IDENTIFIED BY '密码';FLUSH PRIVILEGES;

2、
从

CHANGE MASTER TO MASTER_HOST='ip',     MASTER_USER='账户',     MASTER_PASSWORD='密码',     MASTER_LOG_FILE='File',     MASTER_LOG_POS=Position;

3、
每次重启都要分配IP：
sudo systemctl restart network
ifconfig
关闭防火墙
centos7：sudo systemctl stop friewalld.service

数据库优化 之 分库分表

垂直分表
根据业务逻辑，把数据表以垂直方式（列）进行分离，分为基础表和扩展表。减少大表检索引发的大量IO。垂直分表非常简单有效，但有时分表时为了提高数据库并发性能，会采用一些反范式手段（适当允许数据冗余）。

水平分表
垂直分表带来的性能优化以及扩展都是有限的，并且在千万级别以上的数据是无法支撑的，因此要利用到水平分表。水平的分表在遵循数据可用情况下，根据业务指定分表策略，按照一定规则把单表的数据平摊到各个扩展表以减少单表数据条数。

迁移表，在从库迁

水平分库分表
水平分库分表跟水平分表的思路一样，唯一不同是拆分出来的数据部署到不同的数据库中，分库分表能有效缓解单机和单库的性能瓶颈同时也保证海量数据存储，但是投入的成本很高，一般在大型互联网公司才会采用。分库分表同样面临很多技术挑战，要看自身团队水平选择解决方案。

（CAP定理）一个分布式系统不可能同时满足一致性Consistency、可用性Availability、分区容错性Partition tolerance这三个基本需求，最多只能同时满足其中的两项，一般舍弃一致性Consistency，保留最终一致性

在数据库优化技术选型上需结合业务发展，团队实力来衡量一个架构的执行可行度。在选择技术方案时要考虑准备你面临的技术挑战。

数据库优化之缓存机制

缓存机制

大型网站系统往往会有数据复杂的运算，这些数据的获取不仅增加数据库的IO，还消耗大量应用服务器资源。虽然通过拼硬件的方式可以解决燃眉之急，但是投入产出比并不理想。通常网站80%的访问集中在20%的数据上，这时我们可以对业务剖析，把高访问的数据缓存至内存，这样可以非常有效地提升系统性能。

常用缓存机制

memcache Slab内存分配

Memcached基于一个存储键/值对的hashmap

redis LRU内存管理
Redis是一个key-value存储系统，和Memcached类似。但是它支持存储的value类型相对更多

redis与memcached的分布式水平扩展以及性能都非常好，但是由于redis支持的数据类型很多，可以满足我们对后续架构的进一步优化，所以推荐选择redis

Redis

redis数据类型：Strings、Lists、Sets、Hashes、Sorted sets
redis性能：redis性能非常好，IO可达到1W/S，且支持主从异步复制，非常适合搭建分布式缓存

redis应用：缓存、发布订阅模式、生产消费模式

1. 缓存
   2.发布订阅模式
2. 生产消费模式

安装redis
源码安装包
https://redis.io/download
下载源码包：wget [download_url]
解压文件：tar -zxvf xx.tar.gz

编译安装
sudo make
编译完成后，redis安装目录下的src目录下会出现编译后的redis-server和测试客户终端redis-cli

启动redis服务
切换到src目录并启动redis-server
cd src
sudo ./redis-server &

cli端测试
sudo ./redis-cli -h 127.0.0.1