目录
2.1 问题引入-1~2亿条数据需要缓存,如何设计这个存储案例
1.新建主服务器实例3307
- docker run -p 3307:3306 --name mysql-master
- -v /volumes/mysql-master/log:/var/log/mysql
- -v /volumes/mysql-master/data:/var/lib/mysql
- -v /volumes/mysql-master/conf:/etc/mysql
- -e MYSQL_ROOT_PASSWORD=123456
- -d mysql:5.7
2. 进入/volumes/mysql-master/conf目录下新建my.cnf
- [client]
- default_character_set=utf8
- [mysqld]
- collation_server = utf8_general_ci
- character_set_server = utf8
- ## 设置server_id,同一局域网中需要唯一
- server_id=101
- ## 指定不需要同步的数据库名称
- binlog-ignore-db=mysql
- ## 开启二进制日志功能
- log-bin=mall-mysql-bin
- ## 设置二进制日志使用内存大小(事务)
- binlog_cache_size=1M
- ## 设置使用的二进制日志格式(mixed,statement,row)
- binlog_format=mixed
- ## 二进制日志过期清理时间。默认值为0,表示不自动清理。
- expire_logs_days=7
- ## 跳过主从复制中遇到的所有错误或指定类型的错误,避免slave端复制中断。
- ## 如:1062错误是指一些主键重复,1032错误是因为主从数据库数据不一致
- slave_skip_errors=1062
3.设置完后重启
docker restart mysql-master
4.进入mysql-master容器
- docker exec -it mysql-master /bin/bash
- mysql -uroot -p123456
5. master容器实例内创建数据同步用户
- CREATE USER 'slave'@'%' IDENTIFIED BY '123456';
- GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'%';
1.新建从服务器容器实例3308
- docker run -p 3308:3306 --name mysql-slave
- -v /volumes/mysql-slave/log:/var/log/mysql
- -v /volumes/mysql-slave/data:/var/lib/mysql
- -v /volumes/mysql-slave/conf:/etc/mysql
- -e MYSQL_ROOT_PASSWORD=123456
- -d mysql:5.7
2. 进入/volumes/mysql-slave/conf目录下新建my.cnf
- [client]
- default_character_set=utf8
- [mysqld]
- collation_server = utf8_general_ci
- character_set_server = utf8
- ## 设置server_id,同一局域网中需要唯一
- server_id=102
- ## 指定不需要同步的数据库名称
- binlog-ignore-db=mysql
- ## 开启二进制日志功能
- log-bin=mall-mysql-bin
- ## 设置二进制日志使用内存大小(事务)
- binlog_cache_size=1M
- ## 设置使用的二进制日志格式(mixed,statement,row)
- binlog_format=mixed
- ## 二进制日志过期清理时间。默认值为0,表示不自动清理。
- expire_logs_days=7
- ## 跳过主从复制中遇到的所有错误或指定类型的错误,避免slave端复制中断。
- ## 如:1062错误是指一些主键重复,1032错误是因为主从数据库数据不一致
- slave_skip_errors=1062
- ## relay_log配置中继日志
- relay_log=mall-mysql-relay-bin
- ## log_slave_updates表示slave将复制事件写进自己的二进制日志
- log_slave_updates=1
- ## slave设置为只读(具有super权限的用户除外)
- read_only=1
3.修改完配置后重启slave实例
docker restart mysql-slave
4.在主数据库中查看主从同步状态,有些参数后面要用
show master status;
5. 进入从服务器
- docker exec -it mysql-slave /bin/bash
- mysql -uroot -p123456
6. 在从数据库中配置主从复制
- change master to master_host='宿主机ip', master_user='slave', master_password='123456', master_port=3307, master_log_file='mall-mysql-bin.000001', master_log_pos=617, master_connect_retry=30;
-
- #master_host:主数据库的IP地址;
- #master_port:主数据库的运行端口;
- #master_user:在主数据库创建的用于同步数据的用户账号;
- #master_password:在主数据库创建的用于同步数据的用户密码;
- #master_log_file:指定从数据库要复制数据的日志文件,通过查看主数据的状态,获取File参数;
- #master_log_pos:指定从数据库从哪个位置开始复制数据,通过查看主数据的状态,获取Position参数;
- #master_connect_retry:连接失败重试的时间间隔,单位为秒。
7. 在从数据库中查看主从同步状态
show slave status \G;
8. 在从数据库中开启主从同步,再重复执行7,查看是否成功开启主从同步
start slave
单机单台100%不可能,肯定是分布式存储,用redis如何落地?
2亿条记录就是2亿个k,v,我们单机不行必须要分布式多机,假设有3台机器构成一个集群,用户每次读写操作都是根据公式:hash(key) % N个机器台数,计算出哈希值,用来决定数据映射到哪一个节点上。
优点:
简单粗暴,直接有效,只需要预估好数据规划好节点,例如3台、8台、10台,就能保证一段时间的数据支撑。使用Hash算法让固定的一部分请求落到同一台服务器上,这样每台服务器固定处理一部分请求(并维护这些请求的信息),起到负载均衡+分而治之的作用。缺点:
原来规划好的节点,进行扩容或者缩容就比较麻烦了,不管扩缩,每次数据变动导致节点有变动,映射关系需要重新计算,在服务器个数固定不变时没有问题,如果需要弹性扩容或故障停机的情况下,原来的取模公式就会发生变化:Hash(key)/3会变成Hash(key) /?。此时地址经过取余运算的结果将发生很大变化,根据公式获取的服务器也会变得不可控。某个redis机器宕机了,由于台数数量变化,会导致hash取余全部数据重新洗牌。
一致性Hash解决方案的目的是当服务器个数发生变动时,尽量减少影响客户端到服务器的映射关系。通过构建一致性哈希环实现:
简单来说,一致性Hash算法是对2^32取模,将整个哈希值空间组织成一个虚拟的圆环,如假设某哈希函数H的值空间为0-2^32-1(即哈希值是一个32位无符号整形),整个哈希环如下图:整个空间按顺时针方向组织,圆环的正上方的点代表0,0点右侧的第一个点代表1,以此类推,2、3、4、……直到2^32-1,也就是说0点左侧的第一个点代表2^32-1, 0和2^32-1在零点中方向重合,我们把这个由2^32个点组成的圆环称为Hash环。
将集群中各个IP节点映射到环上的某一个位置。
将各个服务器使用Hash进行一个哈希,具体可以选择服务器的IP或主机名作为关键字进行哈希,这样每台机器就能确定其在哈希环上的位置。假如4个节点NodeA、B、C、D,经过IP地址的哈希函数计算(hash(ip)),使用IP地址哈希后在环空间的位置如下:
当我们需要存储一个kv键值对时,首先计算key的hash值,hash(key),将这个key使用相同的函数Hash计算出哈希值并确定此数据在环上的位置,从此位置沿环顺时针“行走”,第一台遇到的服务器就是其应该定位到的服务器,并将该键值对存储在该节点上。
优点:
1.容错性
假设Node C宕机,可以看到此时对象A、B、D不会受到影响,只有C对象被重定位到Node D。一般的,在一致性Hash算法中,如果一台服务器不可用,则受影响的数据仅仅是此服务器到其环空间中前一台服务器(即沿着逆时针方向行走遇到的第一台服务器)之间数据,其它不会受到影响。简单说,就是C挂了,受到影响的只是B、C之间的数据,并且这些数据会转移到D进行存储。2.扩展性
假如数据量增加了,需要增加一台节点NodeX,X的位置在A和B之间,那受影响的也就是A到X之间的数据,重新把A到X的数据录入到X上即可,不会导致hash取余全部数据重新洗牌。
缺点:
数据倾斜
一致性Hash算法在服务节点太少时,容易因为节点分布不均匀而造成数据倾斜(被缓存的对象大部分集中缓存在某一台服务器上)问题,例如系统中只有两台服务器:
哈希槽实质就是一个数组,数组[0,2^14 -1]形成hash slot空间。可以解决均匀分配的问题,在数据和节点之间又加入了一层,把这层称为哈希槽(slot),用于管理数据和节点之间的关系,现在就相当于节点上放的是槽,槽里放的是数据。
一个集群只能有16384个槽,编号0-16383(0-2^14-1)。这些槽会分配给集群中的所有主节点,分配策略没有要求。可以指定哪些编号的槽分配给哪个主节点。Redis 集群中内置了 16384 个哈希槽,redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。当需要在 Redis 集群中放置一个 key-value时,redis 先对 key 使用 crc16 算法算出一个结果,然后把结果对 16384 求余数,这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽,也就是映射到某个节点上。如下代码,key之A 、B在Node2, key之C落在Node3上。以槽为单位移动数据,因为槽的数目是固定的,处理起来比较容易,这样数据移动问题就解决了。
假如我们想插入一个新的节点,哈希槽如何分配?
观察得知,新插入节点的哈希槽是由其他节点各自匀出来一部分组成的。也就是不一定连续。
1. 新建6个docker容器redis实例
- #--net host 使用宿主机的IP和端口,默认
- #--cluster-enabled yes 开启redis集群
- #--appendonly yes 开启持久化
-
- docker run -d --name redis-node-1 --net host --privileged=true -v /volumes/redis_cluster/share/redis-node-1:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6381
-
- docker run -d --name redis-node-2 --net host --privileged=true -v /volumes/redis_cluster/share/redis-node-2:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6382
-
- docker run -d --name redis-node-3 --net host --privileged=true -v/volumes/redis_cluster/share/redis-node-3:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6383
-
- docker run -d --name redis-node-4 --net host --privileged=true -v /volumes/redis_cluster/share/redis-node-4:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6384
-
- docker run -d --name redis-node-5 --net host --privileged=true -v /volumes/redis_cluster/share/redis-node-5:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6385
-
- docker run -d --name redis-node-6 --net host --privileged=true -v /volumes/redis_cluster/share/redis-node-6:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6386
2.进入容器redis-node-1并为6台机器构建集群关系
docker exec -it redis-node-1 /bin/bash
- redis-cli --cluster create
- 192.168.111.147:6381
- 192.168.111.147:6382
- 192.168.111.147:6383
- 192.168.111.147:6384
- 192.168.111.147:6385
- 192.168.111.147:6386
- --cluster-replicas 1
-
- #IP根据自己的实际情况设置
- #--cluster-replicas 1 表示为每个master创建一个slave节点,这样就是三主三从
3.进入6381查看节点状态
- redis-cli -p 6381
- cluster info
- cluster nodes
1.在6381中写数据
- 127.0.0.1:6381> set 1 A
- (error) MOVED 9842 192.168.80.128:6382
- 127.0.0.1:6381> set 2 B
- (error) MOVED 5649 192.168.80.128:6382
什么情况?写不进去!我们应该在开启客户端时加参数-c,优化路由
- redis-cli -p 6381 -c
-
- 127.0.0.1:6381> set 1 A
- -> Redirected to slot [9842] located at 192.168.80.128:6382
- OK
- 192.168.80.128:6382> set 2 B
- OK
2.查看当前集群信息
redis-cli --cluster check 192.168.80.128:6381
懒得再演示了,直接说结果:
假如主机挂了,从机会顶替主机,哪怕主机重新上线,它也会降为从机。(反客为主)
1.新启动两个节点6387、6388
- docker run -d --name redis-node-7 --net host --privileged=true -v /volumes/redis_cluster/share/redis-node-7:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6387
-
- docker run -d --name redis-node-8 --net host --privileged=true -v /volumes/redis_cluster/share/redis-node-8:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6388
2.进入6387内部,加入原节点集群(拜访下队长)
- docker exec -it redis-node-7 /bin/bash
- redis-cli --cluster add-node 192.168.80.128:6387 192.168.80.128:6381
3.这时6387还没有分配槽号,重新分配(队长负责)
- redis-cli --cluster reshard 192.168.80.128:6381
-
- #下面会提示分配多少槽?给谁?填入6387的ID即可
4.查看集群情况,记住6387的ID
redis-cli --cluster check 192.168.80.128:6381
5.为6387分配从服务器6388,id根据自己情况填写
- redis-cli --cluster add-node 192.168.80.128:6388 192.168.80.128:6387
- --cluster-slave --cluster-master-id e4781f644d4a4e4d4b4d107157b9ba8144631451
6.再次执行4,看是否完成了扩容
1.检查集群情况获取6388的ID
redis-cli --cluster check 192.168.80.128:6381
2.删除6388节点,ID根据自己情况
redis-cli --cluster del-node 192.168.80.128:6388 5d149074b7e57b802287d1797a874ed7a1a284a8
3.清空6387的槽位,重新分配
- redis-cli --cluster reshard 192.168.80.128:6381 #申请重新分配
- 根据提示:
- 输入用于接手槽位的ID(6381的)
- 输入用于删除槽位的ID(6387的)
- done(执行)
4.删除6387,ID根据自己情况
redis-cli --cluster del-node 192.168.80.128:6387 e4781f644d4a4e4d4b4d107157b9ba8144631451
5.检查集群情况
redis-cli --cluster check 192.168.80.128:6381