Kubesphere Kubesphere官网：https://kubesphere.io/zh/
KubeSphere 是一款面向云原生设计的开源项目，在目前主流容器调度平台 Kubernetes 之上构建的分布式多租户容器管理平台，提供简单易用的操作界面以及向导式操作方式，在降低用户使用容器调度平台学习成本的同时，极大降低开发、测试、运维的日常工作的复杂度。
部署 1、安装helm（master节点）
2、安装 Tiller（master 执行）
3、安装 OpenEBS（master 执行）
4、最小化、完整化安装Kubesphere
多租户管理 包括集群(Cluster)、企业空间(Workspace)、项目(Project)和DevOps Project(DevOps 工程)的层级关系
架构
集群 概述 集群的目标
1 2 3 4 5 6 7 + 集群目标 + 高可用HA + 突破数据量限制 + 多节点存储 + 多节点备份 + 数据备份容灾 + 压力分担
1 2 3 4 5 6 7 8 9 10 + 基础形式 + 主从 + 同步：主从复制 + 主从调度 + 分片 + 分片存储 + 分片备份 + 选主 + 选主容灾 + 选主调度
MySQL集群 集群原理
企业中常用的数据库解决方案
集群方式 1、MMM
MySQL-MMM 是 Master-Master Replication Manager for MySQL（mysql 主主复制管理器）的简称，是 Google 的开源项目（Perl 脚本）。MMM 基于 MySQLReplication 做的扩展架构，主要用来监控 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 用户。
2、MHA
MHA（Master High Availability）目前在 MySQL 高可用方面是一个相对成熟的解决方案, 由日本 DeNA 公司 youshimaton（现就职于 Facebook 公司）开发，是一套优秀的作为 MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中， MHA 能做到在 0~30 秒之内自动完成数据库的故障切换操作（以 2019 年的眼光来说太 慢了），并且在进行故障切换的过程中，MHA 能在最大程度上保证数据的一致性，以 达到真正意义上的高可用。
3、InnoDB Cluster
InnoDB Cluster 支持自动 Failover、强一致性、读写分离、读库高可用、读请求负载均衡，横向扩展的特性，是比较完备的一套方案。但是部署起来复杂，想要解决 router单点问题好需要新增组件，如没有其他更好的方案可考虑该方案。 InnoDB Cluster 主要由 MySQL Shell、MySQL Router 和 MySQL 服务器集群组成，三者协同工作，共同为MySQL 提供完整的高可用性解决方案。MySQL Shell 对管理人员提供管理接口，可以很方便的对集群进行配置和管理,MySQL Router 可以根据部署的集群状况自动的初始化，是客户端连接实例。如果有节点 down 机，集群会自动更新配置。集群包含单点写入和多点写入两种模式。在单主模式下，如果主节点 down 掉，从节点自动替换上来，MySQL Router 会自动探测，并将客户端连接到新节点。
1 2 3 4 5 6 7 8 9 + MMM + MHA + InnoDB Cluster + 自动故障转移 + 强一致性 + 读写分离 + 高可用 + 负载均衡 + 横向拓展
Cluster 集群 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 master： docker run -p 3307:3306 --name mysql-master \ -v /mydata/mysql/master/log:/var/log/mysql \ -v /mydata/mysql/master/data:/var/lib/mysql \ -v /mydata/mysql/master/conf:/etc/mysql \ -e MYSQL_ROOT_PASSWORD=root \ -d mysql:5.7 参数说明 -p 3307:3306：将容器的 3306 端口映射到主机的 3307 端口 -v /mydata/mysql/master/conf:/etc/mysql：将配置文件夹挂在到主机 -v /mydata/mysql/master/log:/var/log/mysql：将日志文件夹挂载到主机 -v /mydata/mysql/master/data:/var/lib/mysql/：将配置文件夹挂载到主机 -e MYSQL_ROOT_PASSWORD=root：初始化 root 用户的密码 slaver： docker run -p 3317:3306 --name mysql-slaver-01 \ -v /mydata/mysql/slaver/log:/var/log/mysql \ -v /mydata/mysql/slaver/data:/var/lib/mysql \ -v /mydata/mysql/slaver/conf:/etc/mysql \ -e MYSQL_ROOT_PASSWORD=root \ -d mysql:5.7 修改配置Master、slaver [client] default-character-set=utf8 [mysql] default-character-set=utf8 [mysqld] init_connect='SET collation_connection = utf8_unicode_ci' init_connect='SET NAMES utf8' character-set-server=utf8 collation-server=utf8_unicode_ci skip-character-set-client-handshake skip-name-resolve 添加 master 主从复制部分配置 server_id=1 log-bin=mysql-bin read-only=0 binlog-do-db=gulimall_ums binlog-do-db=gulimall_pms binlog-do-db=gulimall_oms binlog-do-db=gulimall_sms binlog-do-db=gulimall_wms binlog-do-db=gulimall_admin replicate-ignore-db=mysql replicate-ignore-db=sys replicate-ignore-db=information_schema replicate-ignore-db=performance_schema 添加 slaver主从复制部分配置 server_id=2 log-bin=mysql-bin read-only=1binlog-do-db=gulimall_ums binlog-do-db=gulimall_pms binlog-do-db=gulimall_oms binlog-do-db=gulimall_sms binlog-do-db=gulimall_wms binlog-do-db=gulimall_admin replicate-ignore-db=mysql replicate-ignore-db=sys replicate-ignore-db=information_schema replicate-ignore-db=performance_schema Master授权用户 GRANT REPLICATION SLAVE ON *.* to 'backup'@'%' identified by '123456'; Master授权用户 GRANT REPLICATION SLAVE ON *.* to 'backup'@'%' identified by '123456'; Slaver设置主库连接 change master to master_host='192.168.124.135',master_user='backup',master_password='123456',mas ter_log_file='mysql-bin.000001',master_log_pos=0,master_port=3307;
1）、主从数据库在自己配置文件中声明需要同步哪个数据库，忽略哪个数据库等信息。并且 server-id 不能一样
2）、主库授权某个账号密码来同步自己的数据
3）、从库使用这个账号密码连接主库来同步数据
ShardingSphere ShardingSphere-Proxy
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 docker： docker run -d -v /mydata/sharding-proxy/conf:/opt/sharding-proxy/conf -v /mydata/sharding-proxy/lib:/opt/sharding-proxy/lib --env PORT=3308 -p13308:3308 apache/sharding-proxy:latest 配置数据分片+读写分离: schemaName: sharding_db_0 dataSources: write_0_ds: url: jdbc:mysql://192.168.124.135:3307/demo_ds_0?serverTimezone=UTC&useSSL=false username: root password: root connectionTimeoutMilliseconds: 30000 idleTimeoutMilliseconds: 60000 maxLifetimeMilliseconds: 1800000 maxPoolSize: 50 minPoolSize: 1 read_ds_0: url: jdbc:mysql://192.168.124.135:3317/demo_ds_0?serverTimezone=UTC&useSSL=false username: root password: root connectionTimeoutMilliseconds: 30000 idleTimeoutMilliseconds: 60000 maxLifetimeMilliseconds: 1800000 maxPoolSize: 50 minPoolSize: 1 # schemaName: sharding_db_1 dataSources: write_1_ds: url: jdbc:mysql://192.168.124.135:3307/demo_ds_1?serverTimezone=UTC&useSSL=false username: root password: root connectionTimeoutMilliseconds: 30000 idleTimeoutMilliseconds: 60000 maxLifetimeMilliseconds: 1800000 maxPoolSize: 50 minPoolSize: 1 read_ds_1: url: jdbc:mysql://192.168.124.135:3317/demo_ds_1?serverTimezone=UTC&useSSL=false username: root password: root connectionTimeoutMilliseconds: 30000 idleTimeoutMilliseconds: 60000 maxLifetimeMilliseconds: 1800000 maxPoolSize: 50 minPoolSize: 1
分库分表
Redis集群 数据分区方案 1、客户端分区
客户端分区方案 的代表为 Redis Sharding，Redis Sharding 是 Redis Cluster 出来之前，业界普遍使用的 Redis 多实例集群 方法。Java 的 Redis 客户端驱动库 Jedis，支持 Redis Sharding 功能，即 ShardedJedis 以及 结合缓存池 的 ShardedJedisPool。
优点：不使用 第三方中间件，分区逻辑可控，配置 简单，节点之间无关联，容易 线性扩展，灵活性强。
缺点：客户端无法动态增删服务节点，客户端需要自行维护分发逻辑，客户端之间 无连接共享，会造成连接浪费。
2、代理分区
代理分区常用方案有 Twemproxy 和 Codis。
3、redis-cluster
redis官方推荐
高可用方式 1、Sentinel（ 哨兵机制）支持高可用
前面介绍了主从机制，但是从运维角度来看，主节点出现了问题我们还需要通过人工干预的方式把从节点设为主节点，还要通知应用程序更新主节点地址，这种方式非常繁琐笨重， 而 且主节点的读写能力都十分有限，有没有较好的办法解决这两个问题，哨兵机制就是针对第 一个问题的有效解决方案，第二个问题则有赖于集群！哨兵的作用就是监控 Redis 系统的运行状况，其功能主要是包括以下三个：
监控(Monitoring): 哨兵(sentinel) 会不断地检查你的 Master 和 Slave 是否运作常。
提醒(Notification): 当被监控的某个 Redis 出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover): 当主数据库出现故障时自动将从数据库转换为主数 据库。
哨兵的原理
1 2 3 4 5 6 7 8 9 10 11 12 + Redis Sentinel + 三个定时监控任务 + 向主节点发送请求获取最新拓扑结构 + 向redis节点的哨兵频道发送故障判断及自身节点信息 + 哨兵之间订阅哨兵频道，了解集群信息 + 向全部节点（包括哨兵）发送心跳检测 + 心跳检测异常，判断下线 + 主节点判断下线 + 需要多个哨兵检测下线票数 + 故障检测和leader选举 + 主节点判断下线 + 采用Raft算法选举leader（详见前几次博客：Raft原理）
2、redis-cluster
1 2 3 4 5 6 7 + Redis Cluster + 3主3从 + 故障转移 + 选举从节点上位 + key路由 + 哈希槽分区：16384槽位 + 数据迁移
分区算法 1、哈希槽分区（CRC16校验算法）
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 + 哈希槽分区 + 问题限制 + key批量操作 + mset、mget只支持相同slot值的key批量操作 + 映射为不同slot分布在不同节点 + key事务操作 + 只支持key在同一节点事务 + key作为分区最小粒度 + 不能将大的键值对象，如hash、list映射不同节点 + 不支持多数据库空间 + 集群模式只有一个数据库db0 + 复制结构只支持一层 + 从节点 只能复制 主节点，不支持 嵌套树状复制 结构 + 命令大多会重定向，耗时多 + 非本节点数据
2、一致性哈希
1 2 3 4 5 + 一致性哈希 + 稳定性 + 哈希倾斜问题 + 引入虚拟节点 + 将虚拟节点数据划分到其真实数据节点，保证负载均衡
部署 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 for port in $(seq 7001 7006); \ do \ mkdir -p /mydata/redis/node-${port}/conf touch /mydata/redis/node-${port}/conf/redis.conf cat << EOF >/mydata/redis/node-${port}/conf/redis.conf port ${port} cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 cluster-announce-ip 192.168.56.10cluster-announce-port ${port} cluster-announce-bus-port 1${port} appendonly yes EOF docker run -p ${port}:${port} -p 1${port}:1${port} --name redis-${port} \ -v /mydata/redis/node-${port}/data:/data \ -v /mydata/redis/node-${port}/conf/redis.conf:/etc/redis/redis.conf \ -d redis:5.0.7 redis-server /etc/redis/redis.conf; \ done docker exec -it redis-7001 bash redis-cli --cluster create 192.168.56.10:7001 192.168.56.10:7002 192.168.56.10:7003 192.168.56.10:7004 192.168.56.10:7005 192.168.56.10:7006 --cluster-replicas 1
Elasticsearch集群 elasticsearch 是天生支持集群 的，他不需要依赖其他的服务发现和注册的组件，如 zookeeper 这些，因为他内置了一个名字叫 ZenDiscovery 的模块，是 elasticsearch 自己实现的一套用于节点发现和选主等功能的组件，所以 elasticsearch 做起集群来非常简单，不需要太多额外的配置和安装额外的第三方组件。
集群原理 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 + 节点 + 主节点 + 管理集群变更 + 任意节点知道任意文档位置 + 请求转发到存储文档的节点 + 集群健康 + yellow + 主分片正常运行，副本分片不正常 + green + red + 分片 + 全部数据的一部分 + 主分片 + 决定索引保存的最大数据量 + 副本分片 + 随时可以修改 + 索引建立时确定主分片、副本分片数量 + 新增节点 + 自动发现、加入集群 + 节点相同clustre.name + 配置可连接到的主机列表 + 水平扩容 + 自动迁移分片 + 动态扩大副本数量 + 提高集群搜索性能 + 应对故障 + 节点宕机 + 集群选主 + 副本分片提升为主分片 + 节点恢复 + 缺失副本分片重新分配 + 问题与解决 + 主节点 + 创建索引、删除索引、分配分片、追踪集群状态 + 负责分发和返回结果 + 首先成为候选主节点 + 候选主节点 + 选举其中一个作为主节点 + 问题 + master选择分歧，导致主分片、副本分歧 + 数据节点 + 负责数据存储、聚合等 + 集群需要设置专用候选主节点和数据节点 + 避免因数据节点负载重导 致主节点不响应 + 客户端节点 + 非主节点、数据节点 + 只负责请求的分发、汇总 + 为了负载均衡 + 脑裂问题可能的原因 + 网络问题 + 一些节点访问不到master + 选举新master + 节点负载 + 主节点既为master又为data + 访问过大，es延迟响应等 + 其他节点选举新master + 内存回收 + data节点占用内存较大 + JVM大规模内存回收 + es失去响应 + 脑裂问题解决方案 + 角色分离 + master节点与data节点分离，限制角色 + 减少master节点工作压力 + 减少误判 + 配置主节点响应时间延长 + 减少宕机误判 + 选举触发 + 设置选举触发资格 + 集群大于一半的节点相互连接才能进行选举 + 防止少部分节点失联独自选举
集群结构 以三台物理机为例。在这三台物理机上，搭建了 6 个 ES 的节点，三个 data 节点，三个 master 节点（每台物理机分别起了一个 data 和一个 master），3 个 master 节点，目的是达到（n/2） +1 等于 2 的要求，这样挂掉一台 master 后（不考虑 data），n 等于 2，满足参数，其他两个 master 节点都认为 master 挂掉之后开始重新选举
集群搭建 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 1、防止 JVM 报错 echo vm.max_map_count=262144 >> /etc/sysctl.conf sysctl -p 2、准备docker网络（创建自己的 bridge 网络） docker network create --driver bridge --subnet=172.18.12.0/16 --gateway=172.18.1.1 mynet 3、master*3节点创建 for port in $(seq 1 3); \ do \ mkdir -p /mydata/elasticsearch/master-${port}/config mkdir -p /mydata/elasticsearch/master-${port}/data chmod -R 777 /mydata/elasticsearch/master-${port} cat << EOF >/mydata/elasticsearch/master-${port}/config/elasticsearch.yml cluster.name: my-es #集群的名称，同一个集群该值必须设置成相同的 node.name: es-master-${port} #该节点的名字 node.master: true #该节点有机会成为 master 节点 node.data: false #该节点可以存储数据 network.host: 0.0.0.0 http.host: 0.0.0.0 #所有 http 均可访问 http.port: 920${port} transport.tcp.port: 930${port} # discovery.zen.minimum_master_nodes: 2 它 N 个有 master 资格的节点。官方推荐（N/2）+1 discovery.zen.ping_timeout: 10s #设置集群中自动发现其他节点时 ping 连接的超时时间 discovery.seed_hosts: ["172.18.12.21:9301", "172.18.12.22:9302", "172.18.12.23:9303"] #设置集 群中的 Master 节点的初始列表，可以通过这些节点来自动发现其他新加入集群的节点，es7 的新增配置 cluster.initial_master_nodes: ["172.18.12.21"] #新集群初始时的候选主节点，es7 的新增配置 EOF docker run --name elasticsearch-node-${port} \ -p 920${port}:920${port} -p 930${port}:930${port} \ --network=mynet --ip 172.18.12.2${port} \-e ES_JAVA_OPTS="-Xms300m -Xmx300m" \ -v /mydata/elasticsearch/master-$ {port}/config/elasticsearch.yml:/usr/share/elasticsearch/config/el asticsearch.yml \ -v /mydata/elasticsearch/master-${port}/data:/usr/share/elasticsearch/data \ -v /mydata/elasticsearch/master-${port}/plugins:/usr/share/elasticsearch/plugins \ -d elasticsearch:7.4.2 done 4、data-node*3节点创建 for port in $(seq 4 6); \ do \ mkdir -p /mydata/elasticsearch/node-${port}/config mkdir -p /mydata/elasticsearch/node-${port}/data chmod -R 777 /mydata/elasticsearch/node-${port} cat << EOF >/mydata/elasticsearch/node-${port}/config/elasticsearch.yml cluster.name: my-es #集群的名称，同一个集群该值必须设置成相同的 node.name: es-node-${port} #该节点的名字 node.master: false #该节点有机会成为 master 节点 node.data: true #该节点可以存储数据 network.host: 0.0.0.0 # network.publish_host: 192.168.56.10 无法通信 http.host: 0.0.0.0 #所有 http 均可访问 http.port: 920${port} transport.tcp.port: 930${port} # discovery.zen.minimum_master_nodes: 2 它 N 个有 master 资格的节点。官方推荐（N/2）+1 discovery.zen.ping_timeout: 10s #设置集群中自动发现其他节点时 ping 连接的超时时间 discovery.seed_hosts: ["172.18.12.21:9301", "172.18.12.22:9302", "172.18.12.23:9303"] #设置集 群中的 Master 节点的初始列表，可以通过这些节点来自动发现其他新加入集群的节点，es7 的新增配置 cluster.initial_master_nodes: ["172.18.12.21"] #新集群初始时的候选主节点，es7 的新增配置 EOF docker run --name elasticsearch-node-${port} \ -p 920${port}:920${port} -p 930${port}:930${port} \ --network=mynet --ip 172.18.12.2${port} \ -e ES_JAVA_OPTS="-Xms300m -Xmx300m" \ -v/mydata/elasticsearch/node-$ {port}/config/elasticsearch.yml:/usr/share/elasticsearch/config/ela sticsearch.yml \ -v /mydata/elasticsearch/node-${port}/data:/usr/share/elasticsearch/data \ -v /mydata/elasticsearch/node-${port}/plugins:/usr/share/elasticsearch/plugins \ -d elasticsearch:7.4.2 done
RabbitMQ集群 RabbiMQ 是用 Erlang 开发的，集群非常方便，因为 Erlang 天生就是一门分布式语言，但其本身并不支持负载均衡。
RabbitMQ 集群中节点包括**内存节点(RAM)、 磁盘节点(Disk，消息持久化)**，集群中至少有 一个 Disk 节点。
集群原理 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 + 集群形式 + 普通模式 + 集群特点 + 各节点相同队列结构 + 消息只存在于一个节点 + 消费者消费，需要通过节点直接转发 + 应用场景 + 适合消息无需持久化场景，日志队列等 + 宕机时可直接连接其他节点，只需重新创建队列 + 镜像模式 + 集群特点 + 消息实体会主动在镜像节点间同步（消息到队列时） + mirror queue选举算法 + 1个master，n个slaver + 生产者、消费者请求转至master + 镜像集群基于普通集群 + 先搭建普通集群，再设置镜像队列 + 缺点 + 镜像队列过多，且消息体量大 + 集群内部网络带宽将会被此种同步通讯所消耗 + 应用场景 + 可靠性要求较高场合，如下单、库存队列 + 若消费过程中，master 挂掉，则选举新 master + 若未来得及确认，则可能会重复消费
集群搭建 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 1、启动容器 mkdir /mydata/rabbitmq cd rabbitmq/ mkdir rabbitmq01 rabbitmq02 rabbitmq03 docker run -d --hostname rabbitmq01 --name rabbitmq01 -v /mydata/rabbitmq/rabbitmq01:/var/lib/rabbitmq -p 15673:15672 -p 5673:5672 -e RABBITMQ_ERLANG_COOKIE='atguigu' rabbitmq:management docker run -d --hostname rabbitmq02 --name rabbitmq02 -v /mydata/rabbitmq/rabbitmq02:/var/lib/rabbitmq -p 15674:15672 -p 5674:5672 -e RABBITMQ_ERLANG_COOKIE='atguigu' --link rabbitmq01:rabbitmq01 rabbitmq:management docker run -d --hostname rabbitmq03 --name rabbitmq03 -v /mydata/rabbitmq/rabbitmq03:/var/lib/rabbitmq -p 15675:15672 -p 5675:5672 -e RABBITMQ_ERLANG_COOKIE='atguigu' --link rabbitmq01:rabbitmq01 --link rabbitmq02:rabbitmq02 rabbitmq:management --hostname 设置容器的主机名 RABBITMQ_ERLANG_COOKIE 节点认证作用，部署集成时 需要同步该值 2、节点加入集群 docker exec -it rabbitmq01 /bin/bash rabbitmqctl stop_app rabbitmqctl reset rabbitmqctl start_app 进入第二个节点 docker exec -it rabbitmq02 /bin/bash rabbitmqctl stop_app rabbitmqctl reset rabbitmqctl join_cluster --ram rabbit@rabbitmq01 rabbitmqctl start_app exit 进入第三个节点 docker exec -it rabbitmq03 bash rabbitmqctl stop_app rabbitmqctl reset rabbitmqctl join_cluster --ram rabbit@rabbitmq01 rabbitmqctl start_app exit 3、实现镜像集群 docker exec -it rabbitmq01 bash rabbitmqctl set_policy -p / ha "^" '{"ha-mode":"all","ha-sync-mode":"automatic"}' 可以使用 rabbitmqctl list_policies -p /；查看 vhost/下面的所有 policy 在 cluster 中任意节点启用策略，策略会自动同步到集群节点 rabbitmqctl set_policy-p/ha-all"^"’{“ha-mode”:“all”}’ 策略模式 all 即复制到所有节点，包含新增节点，策略正则表达式为 “^” 表示所有匹配所有队列名称。“^hello”表示只匹配名为 hello 开始的队列
改为镜像集群：同步
