云原生系列 - Docker(高级篇)

前言

1. 学习视频：尚硅谷Docker实战教程（docker教程天花板）
2. 本内容仅用于个人学习笔记，如有侵扰，联系删
3. 学习文档：
   • 云原生系列 - Docker(基础篇)
   • 云原生系列 - Docker(高级篇)
   • 云原生系列 - Docker搭建私有仓库
4. 云原生项目实战文档：
   • 谷粒商城 - 个人笔记(集群部署篇一)
   • 谷粒商城 - 个人笔记(集群部署篇二)
   • 谷粒商城 - 个人笔记(集群部署篇三)

1、Docker复杂安装详说

1.1、安装mysql主从复制

1.1.1、集群原理

以上可以作为企业中常用的数据库解决方案；

• MySQL-MMM 是 Master-Master Replication Manager for MySQL（mysql 主主复制管理器）的简称，是 Google 的开源项目（Perl 脚本）。MMM 基于 MySQL Replication 做的扩展架构，主要用来监控 mysql 主主复制并做失败转移。其原理是将真实数据库节点的IP（RIP）映射为虚拟 IP（VIP）集。
  mysql-mmm 的监管端会提供多个虚拟 IP（VIP），包括一个可写 VIP，多个可读 VIP，通过监管的管理，这些 IP 会绑定在可用 mysql 之上，当某一台 mysql 宕机时，监管会将 VIP迁移至其他 mysql。在整个监管过程中，需要在 mysql 中添加相关授权用户，以便让 mysql 可以支持监理机的维护。授权的用户包括一个mmm_monitor 用户和一个 mmm_agent 用户，如果想使用 mmm 的备份工具则还要添加一个 mmm_tools 用户。
  
• MHA（Master High Availability）目前在 MySQL 高可用方面是一个相对成熟的解决方案, 由日本 DeNA 公司 youshimaton（现就职于 Facebook 公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA 能做到在 0~30 秒之内自动完成数据库的故障切换操作（以 2019 年的眼光来说太慢了），并且在进行故障切换的过程中，MHA 能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
• InnoDB Cluster 支持自动 Failover、强一致性、读写分离、读库高可用、读请求负载均衡，横向扩展的特性，是比较完备的一套方案。但是部署起来复杂，想要解决 router单点问题好需要新增组件，如没有其他更好的方案可考虑该方案。 InnoDB Cluster 主要由 MySQL Shell、MySQL Router 和 MySQL 服务器集群组成，三者协同工作，共同为MySQL 提供完整的高可用性解决方案。MySQL Shell 对管理人员提供管理接口，可以很方便的对集群进行配置和管理,MySQL Router 可以根据部署的集群状况自动的初始化，是客户端连接实例。如果有节点 down 机，集群会自动更新配置。集群包含单点写入和多点写入两种模式。在单主模式下，如果主节点 down 掉，从节点自动替换上来，MySQL Router 会自动探测，并将客户端连接到新节点。
  

1.1.2、主从搭建步骤

1)、新建主服务器容器实例3307

1. 下载 mysql 镜像

   docker pull mysql:5.7
   

2. 创建 Master 实例并启动

   docker run -p 3307:3306 --name mysql-master \
   -v /mydata/mysql/mysql-master/log:/var/log/mysql \
   -v /mydata/mysql/mysql-master/data:/var/lib/mysql \
   -v /mydata/mysql/mysql-master/conf:/etc/mysql \
   -e MYSQL_ROOT_PASSWORD=root \
   -d mysql:5.7
   

   参数说明：

   • -p 3307:3306：将容器的 3306 端口映射到主机的 3307 端口
   • -v /mydata/mysql/mysql-master/conf:/etc/mysql：将配置文件夹挂在到主机
   • -v /mydata/mysql/mysql-master/log:/var/log/mysql：将日志文件夹挂载到主机
   • -v /mydata/mysql/mysql-master/data:/var/lib/mysql/：将配置文件夹挂载到主机
   • -e MYSQL_ROOT_PASSWORD=root：初始化 root 用户的密码

3. 修改 master 基本配置
   进入/mydata/mysql/mysql-master/conf目录下新建my.cnf

   vim /mydata/mysql/mysql-master/conf/my.cnf
   

   [mysqld]
   ## 设置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
   

4. 修改完配置后重启master实例

   docker restart mysql-master
   

5. 进入mysql-master容器

   docker exec -it mysql-master /bin/bash
   

   mysql -uroot -proot
   

6. master容器实例内创建数据同步用户
   创建一个具有连接数据库权限的用户 ‘slave’，并设置了密码为 ‘123456’，允许从任何主机连接到MySQL数据库

   CREATE USER 'slave'@'%' IDENTIFIED BY '123456';
   

   授予了用户 ‘slave’ 在任何主机上执行MySQL数据库复制操作和查看复制状态的权限。这是配置MySQL主从复制所必需的权限之一

   GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'%';
   

2)、新建从服务器容器实例3308

1. 创建 slave实例并启动

   docker run -p 3308:3306 --name mysql-slave \
   -v /mydata/mysql/mysql-slave/log:/var/log/mysql \
   -v /mydata/mysql/mysql-slave/data:/var/lib/mysql \
   -v /mydata/mysql/mysql-slave/conf:/etc/mysql \
   -e MYSQL_ROOT_PASSWORD=root  \
   -d mysql:5.7
   

2. 修改 slave基本配置
   进入/mydata/mysql/mysql-slave/conf目录下新建my.cnf

   vim /mydata/mysql/mysql-slave/conf/my.cnf
   

   [mysqld]
   ## 设置server_id，同一局域网中需要唯一
   server_id=102
   ## 指定不需要同步的数据库名称
   binlog-ignore-db=mysql  
   ## 开启二进制日志功能，以备Slave作为其它数据库实例的Master时使用
   log-bin=mall-mysql-slave1-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. 进入mysql-slave容器

   docker exec -it mysql-slave /bin/bash
   

   mysql -uroot -proot
   

6. 在从数据库中配置主从复制

   change master to master_host='192.168.119.128', master_user='slave', master_password='123456', master_port=3307, master_log_file='mall-mysql-bin.000001', master_log_pos=154, 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. 在从数据库中开启主从同步

   start slave;
   

9. 查看从数据库状态发现已经同步

   show slave status \G;
   

   

10. 主从复制测试

    • 主机新建库-使用库-新建表-插入数据，ok
      
    • 从机使用库-查看记录，ok
      

1.2、安装redis集群(大厂面试题第4季-分布式存储案例真题)

1.2.1、cluster(集群)模式-docker版 哈希槽分区进行亿级数据存储

面试题

1~2亿条数据需要缓存，请问如何设计这个存储案例

回答

1. 单机单台100%不可能，肯定是分布式存储，用redis如何落地？

2. 上述问题阿里P6~P7工程案例和场景设计类必考题目， 一般业界有3种解决方案

   1. 哈希取余分区
      
      2亿条记录就是2亿个k,v，我们单机不行必须要分布式多机，假设有3台机器构成一个集群，用户每次读写操作都是根据公式：
      hash(key) % N个机器台数，计算出哈希值，用来决定数据映射到哪一个节点上。

   • 优点：
     简单粗暴，直接有效，只需要预估好数据规划好节点，例如3台、8台、10台，就能保证一段时间的数据支撑。使用Hash算法让固定的一部分请求落到同一台服务器上，这样每台服务器固定处理一部分请求（并维护这些请求的信息），起到负载均衡+分而治之的作用。

   • 缺点：
     原来规划好的节点，进行扩容或者缩容就比较麻烦了额，不管扩缩，每次数据变动导致节点有变动，映射关系需要重新进行计算，在服务器个数固定不变时没有问题，如果需要弹性扩容或故障停机的情况下，原来的取模公式就会发生变化：Hash(key)/3会变成Hash(key) /?。此时地址经过取余运算的结果将发生很大变化，根据公式获取的服务器也会变得不可控。
     某个redis机器宕机了，由于台数数量变化，会导致hash取余全部数据重新洗牌。

   2. 一致性哈希算法分区

   • 是什么
     一致性Hash算法背景
     一致性哈希算法在1997年由麻省理工学院中提出的，设计目标是为了解决分布式缓存数据变动和映射问题，某个机器宕机了，分母数量改变了，自然取余数不OK了。

   • 能干嘛
     提出一致性Hash解决方案。 目的是当服务器个数发生变动时， 尽量减少影响客户端到服务器的映射关系

   • 3大步骤

     • 算法构建一致性哈希环
       一致性哈希环
       一致性哈希算法必然有个hash函数并按照算法产生hash值，这个算法的所有可能哈希值会构成一个全量集，这个集合可以成为一个hash空间[0,$2^{32-1}$]，这个是一个线性空间，但是在算法中，我们通过适当的逻辑控制将它首尾相连(0 = $2^{32}$),这样让它逻辑上形成了一个环形空间。
       它也是按照使用取模的方法，前面笔记介绍的节点取模法是对节点（服务器）的数量进行取模。而一致性Hash算法是对$2^{32}$取模，简单来说，一致性Hash算法将整个哈希值空间组织成一个虚拟的圆环，如假设某哈希函数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节点映射
       将集群中各个IP节点映射到环上的某一个位置。
       将各个服务器使用Hash进行一个哈希，具体可以选择服务器的IP或主机名作为关键字进行哈希，这样每台机器就能确定其在哈希环上的位置。假如4个节点NodeA、B、C、D，经过IP地址的哈希函数计算(hash(ip))，使用IP地址哈希后在环空间的位置如下：
     • key落到服务器的落键规则
       当我们需要存储一个kv键值对时，首先计算key的hash值，hash(key)，将这个key使用相同的函数Hash计算出哈希值并确定此数据在环上的位置，从此位置沿环顺时针“行走”，第一台遇到的服务器就是其应该定位到的服务器，并将该键值对存储在该节点上。
       如我们有Object A、Object B、Object C、Object D四个数据对象，经过哈希计算后，在环空间上的位置如下：根据一致性Hash算法，数据A会被定为到Node A上，B被定为到Node B上，C被定为到Node C上，D被定为到Node D上。
       

   • 优点

     • 一致性哈希算法的容错性
       容错性
       假设Node C宕机，可以看到此时对象A、B、D不会受到影响，只有C对象被重定位到Node D。一般的，在一致性Hash算法中，如果一台服务器不可用，则受影响的数据仅仅是此服务器到其环空间中前一台服务器（即沿着逆时针方向行走遇到的第一台服务器）之间数据，其它不会受到影响。简单说，就是C挂了，受到影响的只是B、C之间的数据，并且这些数据会转移到D进行存储。
       
     • 一致性哈希算法的扩展性
       扩展性
       数据量增加了，需要增加一台节点NodeX，X的位置在A和B之间，那收到影响的也就是A到X之间的数据，重新把A到X的数据录入到X上即可，
       不会导致hash取余全部数据重新洗牌。
       

   • 缺点

     • 一致性哈希算法的数据倾斜问题
       Hash环的数据倾斜问题
       一致性Hash算法在服务节点太少时，容易因为节点分布不均匀而造成数据倾斜（被缓存的对象大部分集中缓存在某一台服务器上）问题，
       例如系统中只有两台服务器：
       

   • 小总结
     为了在节点数目发生改变时尽可能少的迁移数据

     将所有的存储节点排列在收尾相接的Hash环上，每个key在计算Hash后会顺时针找到临近的存储节点存放。
     而当有节点加入或退出时仅影响该节点在Hash环上顺时针相邻的后续节点。

     优点
     加入和删除节点只影响哈希环中顺时针方向的相邻的节点，对其他节点无影响。

     缺点
     数据的分布和节点的位置有关，因为这些节点不是均匀的分布在哈希环上的，所以数据在进行存储时达不到均匀分布的效果。

   3. 哈希槽分区
   • 是什么

     1. 为什么出现
        
        哈希槽实质就是一个数组，数组[0,$2^{14-1}$]形成hash slot空间。

     2. 能干什么
        解决均匀分配的问题，在数据和节点之间又加入了一层，把这层称为哈希槽（slot），用于管理数据和节点之间的关系，现在就相当于节点上放的是槽，槽里放的是数据。

        槽解决的是粒度问题，相当于把粒度变大了，这样便于数据移动。
        哈希解决的是映射问题，使用key的哈希值来计算所在的槽，便于数据分配。

     3. 多少个hash槽
        一个集群只能有16384个槽，编号0-16383（0-2^14-1）。这些槽会分配给集群中的所有主节点，分配策略没有要求。可以指定哪些编号的槽分配给哪个主节点。集群会记录节点和槽的对应关系。解决了节点和槽的关系后，接下来就需要对key求哈希值，然后对16384取余，余数是几key就落入对应的槽里。slot = CRC16(key) % 16384。以槽为单位移动数据，因为槽的数目是固定的，处理起来比较容易，这样数据移动问题就解决了。

   • 哈希槽计算
     Redis 集群中内置了 16384 个哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。当需要在 Redis 集群中放置一个 key-value时，redis 先对 key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，也就是映射到某个节点上。如下代码，key之A 、B在Node2， key之C落在Node3上
     

1.2.2、3主3从redis集群配置

1. 新建6个docker容器redis实例

   docker run -d --name redis-node-1 --net host --privileged=true -v /mydata/redis/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 /mydata/redis/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 /mydata/redis/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 /mydata/redis/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 /mydata/redis/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 /mydata/redis/redis-node-6:/data redis:6.0.8 --cluster-enabled yes --appendonly yes --port 6386
   

   

   命令分步解释:

   • docker run: 创建并运行docker容器实例
   • –name redis-node-6: 容器名字
   • –net host: 使用宿主机的IP和端口，默认
   • –privileged=true: 获取宿主机root用户权限
   • -v /data/redis/share/redis-node-6:/data: 容器卷，宿主机地址:docker内部地址
   • redis:6.0.8: redis镜像和版本号
   • –cluster-enabled yes: 开启redis集群
   • –appendonly yes: 开启持久化
   • –port 6386: redis端口号

2. 进入容器redis-node-1并为6台机器构建集群关系

   • 进入容器

     docker exec -it redis-node-1 /bin/bash
     

   • 构建主从关系
     注意，进入docker容器后才能执行一下命令，且注意自己的真实IP地址

     redis-cli --cluster create 192.168.119.128:6381 192.168.119.128:6382 192.168.119.128:6383 192.168.119.128:6384 192.168.119.128:6385 192.168.119.128:6386 --cluster-replicas 1
     

     –cluster-replicas 1 表示为每个master创建一个slave节点
     
     一切OK的话，3主3从搞定

3. 链接进入6381作为切入点，查看集群状态

   redis-cli -p 6381
   

   cluster info
   

   

4. 链接进入6381作为切入点，查看节点状态

   cluster nodes
   

   

1.2.3、主从容错切换迁移案例

• 对6381新增两个key

  redis-cli -p 6381
  

  
  这种方式登录我们是进入的单节点6381，因为我们新增的k1的槽点是12706，不属于6381的范围，应该属于6383的节点，所以这种新增是有问题的。

  防止路由失效加参数-c并新增两个key
  加入参数-c，优化路由
  
  我们使用集群方式连接，我们新增key时，根据这个key的槽点，会重定向对应的节点

• 查看集群信息

  redis-cli --cluster check 192.168.119.128:6381
  

  

• 容错切换迁移
  

  1. 主6381和从机切换，先停止主机6381
     

  2. 再次查看集群信息
     6381主机停了，对应的真实从机上位
     
     6381宕机了，6385上位成为了新的master。

  3. 查询原先新增的两个key：k1、k2。数据都存在
     

  4. 先还原之前的3主3从

     1. 先启6381

        docker start redis-node-1
        

        
     2. 再停6385

        docker stop redis-node-5
        

        
     3. 再启6385

        docker start redis-node-5
        

        
     4. 查看集群状态
        bash redis-cli --cluster check 192.168.119.128:6381
        

1.2.4、主从扩容案例

1. 新建6387、6388两个节点+新建后启动+查看是否8节点

   docker run -d --name redis-node-7 --net host --privileged=true -v /mydata/redis/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 /mydata/redis/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