深圳做网站公司有那些,网站开发超链接点击后变色,免费网络翻外墙软件,做网站推广微信叫什么网名好目录 一、MySQL集群1、mysql集群原理2、Docker安装模拟MySQL主从复制集群1、下载mysql镜像2、创建Master实例并启动3、创建 Slave 实例并启动4、为 master 授权用户来同步数据1、进入 master 容器2、进入 mysql 内部 #xff08;mysql –uroot -p#xff09;3、查看 master 状… 目录 一、MySQL集群1、mysql集群原理2、Docker安装模拟MySQL主从复制集群1、下载mysql镜像2、创建Master实例并启动3、创建 Slave 实例并启动4、为 master 授权用户来同步数据1、进入 master 容器2、进入 mysql 内部 mysql –uroot -p3、查看 master 状态 5、配置 slaver 同步 master 数据1、进入 slaver 容器2、进入 mysql 内部mysql –uroot -p 3、MyCat 或者 ShardingSphere1、下载安装 Sharding-Proxy2、配置数据分片读写分离3、server.yaml 文件4、k8s 有状态服务部署 六、Redis 集群1、redis 集群形式2、高可用方式3、部署 Cluster4、k8s 部署 redis 七、Elasticsearch 集群1、集群原理2、集群健康3、分片4、新增节点5、水平扩容-启动第三个节点6、应对故障7、问题与解决8、集群结构1、集群结构2、集群搭建0、准备 docker 网络1、3-Master 节点创建2、3-Data-Node 创建3、测试集群 3、k8s 上部署 八、RabbitMQ 集群1、集群形式1、搭建集群2、节点加入集群3、实现镜像集群 2、集群测试3、k8s 上部署 九、Jenkins1、Jenkins2、Jenkins 流水线3、k8s 部署 nacos4、k8s 部署 sentinel5、k8s 部署 zipkin 十、K8S部署应用1、k8s部署应用流程2、生产环境配置抽取3、创建微服务Dockerfile4、创建微服务k8s部署描述文件5、理解targetPort、port、nodePort6、流水线第一步拉取gitee代码参数化构建环境变量7、流水线第二步Sonar代码质量分析8、流水线第三步构建推送镜像9、流水线第四步编写完成10、部署-移植数据库11、流水线部署所有微服务12、部署整合阿里云镜像仓库13、Jenkins修改阿里云镜像仓库14、流水线部署gateway15、流水线部署auth-server16、部署cart17、部署coupon18、修改为共有仓库19、部署前置nginx20、创建网关与应用路由21、部署前端vue项目22、滚动更新部署admin-vue-app23、线上预警和监控 一、MySQL集群
1、mysql集群原理 MySQL-MMM是Master-MasterReplicationManagerforMySQLmysql主主复制管理器的简称是Google的开源项目。
Perl脚本。MMM基于MySQL Replication做的扩展架构主要用来监控mysql主主复制并做失败转移。其原理是将真实数据库节点的IPRIP映射为虚拟IPVIP集。mysql-mmm的监管端会提供多个虚拟IPVIP包括一个可写VIP多个可读VIP通过监管的管理这些IP会绑定在可用mysql之上当某一台mysql宕机时监管会将VIP 迁移至其他mysql。在整个监管过程中需要在mysql中添加相关授权用户以便让mysql可以支持监理机的维护。授权的用户包括一个mmm_monitor用户和一个mmm_agent用户如果想使用mmm的备份工具则还要添加一个mmm_tools用户。 MHAMasterHighAvailability目前在MySQL高可用方面是一个相对成熟的解决方案,由日本DeNA公司youshimaton现就职于Facebook公司开发是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中MHA能做到在0~30秒之内自动完成数据库的故障切换操作以2019年的眼光来说太慢了并且在进行故障切换的过程中MHA能在最大程度上保证数据的一致性以达到真正意义上的高可用。 InnoDBCluster支持自动Failover、强一致性、读写分离、读库高可用、读请求负载均衡横向扩展的特性是比较完备的一套方案。但是部署起来复杂想要解决router 单点问题好需要新增组件如没有其他更好的方案可考虑该方案。InnoDBCluster主要由MySQLShell、MySQLRouter和MySQL服务器集群组成三者协同工作共同为MySQL提供完整的高可用性解决方案。MySQLShell对管理人员提供管理接口可以很方便的对集群进行配置和管理,MySQLRouter可以根据部署的集群状况自动的初始化是客户端连接实例。如果有节点down机集群会自动更新配置。集群包含单点写入和多点写入两种模式。在单主模式下如果主节点down掉从节点自动替换上来MySQLRouter会自动探测并将客户端连接到新节点。
2、Docker安装模拟MySQL主从复制集群
1、下载mysql镜像
2、创建Master实例并启动
dockerrun-p3307:3306--namemysql-master\-v/mydata/mysql/master/log:/var/log/mysql\
-v/mydata/mysql/master/data:/var/lib/mysql\
-v/mydata/mysql/master/conf:/etc/mysql\
-eMYSQL_ROOT_PASSWORDroot\
-dmysql:5.7
参数说明
-p3307: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/将配置文件夹挂载到主机-eMYSQL_ROOT_PASSWORDroot初始化root用户的密码修改master基本配置 vim/mydata/mysql/master/conf/my.cnf
[client]
default-character-setutf8[mysql]
default-character-setutf8[mysqld]
init_connectSETcollation_connectionutf8_unicode_ci
init_connectSETNAMESutf8
character-set-serverutf8
collation-serverutf8_unicode_ci
skip-character-set-client-handshake
skip-name-resolve
注意skip-name-resolve一定要加不然连接mysql会超级慢添加master主从复制部分配置server_id1
log-binmysql-bin
read-only0
binlog-do-dbzhenyanmall_ums
binlog-do-dbzhenyanmall_pms
binlog-do-dbzhenyanmall_oms
binlog-do-dbzhenyanmall_sms
binlog-do-dbzhenyanmall_wms
binlog-do-dbzhenyanmall_adminreplicate-ignore-dbmysql
replicate-ignore-dbsys
replicate-ignore-dbinformation_schema
replicate-ignore-dbperformance_schema
重启 master
3、创建 Slave 实例并启动
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_PASSWORDroot \ -d mysql:5.7修改 slave 基本配置
vim /mydata/mysql/slaver/conf/my.cnf
[client]
default-character-setutf8
[mysql]
default-character-setutf8
[mysqld]
init_connectSET collation_connection utf8_unicode_ci init_connectSET NAMES utf8 character-set-serverutf8
collation-serverutf8_unicode_ci
skip-character-set-client-handshake
skip-name-resolve
添加 master 主从复制部分配置
server_id2
log-binmysql-bin
read-only1
binlog-do-dbzhenyanmall_ums
binlog-do-dbzhenyanmall_pms
binlog-do-dbzhenyanmall_oms
binlog-do-dbzhenyanmall_sms
binlog-do-dbzhenyanmall_wms
binlog-do-dbzhenyanmall_admin
replicate-ignore-dbmysql
replicate-ignore-dbsys
replicate-ignore-dbinformation_schema
replicate-ignore-dbperformance_schema重启 slaver
4、为 master 授权用户来同步数据
1、进入 master 容器
docker exec -it mysql /bin/bash2、进入 mysql 内部 mysql –uroot -p
1、授权 root 可以远程访问 主从无关为了方便我们远程连接 mysqlgrant all privileges on *.* to root% identified by root with grant option;flush privileges;
2、添加用来同步的用户GRANT REPLICATION SLAVE ON *.* to backup% identified by 123456;3、查看 master 状态
show master status\G;
5、配置 slaver 同步 master 数据
1、进入 slaver 容器
docker exec -it mysql-slaver-01 /bin/bash
2、进入 mysql 内部mysql –uroot -p
1、授权 root 可以远程访问 主从无关为了方便我们远程连接 mysqlgrant all privileges on *.* to root% identified by root with grant option;flush privileges;
2、设置主库连接
change master to master_hostmysql-master.zhenyanmall,master_userbackup,master_password123456,master_log_filemysql-bin.000003,master_log_pos0,master_port3306;
3、启动从库同步start slave;
4、查看从库状态show slave status\G;至此主从配置完成 总结 1、主从数据库在自己配置文件中声明需要同步哪个数据库忽略哪个数据库等信息。并且 server-id 不能一样 2、主库授权某个账号密码来同步自己的数据 3、从库使用这个账号密码连接主库来同步数据
测试 在主库里面创建表添加、修改、删除数据 从库同步主库的操作
3、MyCat 或者 ShardingSphere
前面测试了数据库的主从同步问题但是不能解决单表性能问题所以要对数据进行分片存储,每个mysql只存一片数据进行分库分表. 设置一个自增主键第一个服务器设置自增id开始是1每次步长是2第二个服务器是从2增长每次步长也是2所以服务器1存的是135所有的数据都是奇数列服务器2存的是246所有的数据都是偶数列以后要查哪个去相应的节点里面进行查询即可。但是这种方式不好维护最终也没有人使用这种方式。 使用分库分表需要使用一些中间件,比如mycat和 ShardingSphere.
shardingSphere: http://shardingsphere.apache.org/index_zh.html auto_increment_offset: 1 从几开始增长 auto_increment_increment: 2 每次的步长
1、下载安装 Sharding-Proxy 镜像方式 docker pull apache/sharding-proxy docker run -d -v /mydata/sharding-proxy/conf:/opt/sharding-proxy/conf -v /mydata/sharding-proxy/lib:/opt/sharding-proxy/lib --env PORT3308 -p13308:3308 apache/sharding-proxy:latest
压缩包下载 https://shardingsphere.apache.org/document/current/cn/downloads/
2、配置数据分片读写分离
config-mallshard.yaml
schemaName: sharding_db
dataSources:
ds0:
url: jdbc:mysql://192.168.56.10:3307/ds0
username: root
password: root
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 65
ds0_slave0:
url: jdbc:mysql://192.168.56.10:3317/ds0
username: root
password: root
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 65
ds1:
url: jdbc:mysql://192.168.56.10:3307/ds1
username: root
password: root
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 65
ds1_slave0:
url: jdbc:mysql://192.168.56.10:3317/ds1
username: root
password: root
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 65
shardingRule:
tables:
t_order:
actualDataNodes: ds${0..1}.t_order${0..1}
databaseStrategy:
inline:
shardingColumn: user_id
algorithmExpression: ds${user_id % 2}
tableStrategy:
inline:
shardingColumn: order_id
algorithmExpression: t_order${order_id % 2}
keyGenerator:
type: SNOWFLAKE
column: order_id
t_order_item:
actualDataNodes: ds${0..1}.t_order_item${0..1}
databaseStrategy:
inline:
shardingColumn: user_id
algorithmExpression: ds${user_id % 2}
tableStrategy:
inline:
shardingColumn: order_id
algorithmExpression: t_order_item${order_id % 2}
keyGenerator:
type: SNOWFLAKE
column: order_item_id
bindingTables: - t_order,t_order_item
broadcastTables: - t_config
defaultDataSourceName: ds0
defaultTableStrategy:
none:
masterSlaveRules:
ms_ds0:
masterDataSourceName: ds0
slaveDataSourceNames: - ds0_slave0
loadBalanceAlgorithmType: ROUND_ROBIN
ms_ds1:
masterDataSourceName: ds1
slaveDataSourceNames: - ds1_slave0
loadBalanceAlgorithmType: ROUND_ROBIN创建测试表
CREATE TABLE t_order (
order_id bigint(20) NOT NULL, user_id int(11) NOT NULL, status varchar(50) COLLATE utf8_bin DEFAULT NULL, PRIMARY KEY (order_id)
) ENGINEInnoDB DEFAULT CHARSETutf8 COLLATEutf8_bin;
CREATE TABLE t_order_item (
order_item_id bigint(20) NOT NULL, order_id bigint(20) NOT NULL, user_id int(11) NOT NULL, content varchar(255) COLLATE utf8_bin DEFAULT NULL, status varchar(50) COLLATE utf8_bin DEFAULT NULL, PRIMARY KEY (order_item_id)
) ENGINEInnoDB DEFAULT CHARSETutf8 COLLATEutf8_bin;3、server.yaml 文件
authentication:
users:
root:
password: root
sharding:
password: sharding
authorizedSchemas: sharding_db4、k8s 有状态服务部署
可以使用 kubesphere快速搭建 MySQL 环境。 有状态服务抽取配置为 ConfigMap 有状态服务必须使用 pvc 持久化数据 服务集群内访问使用 DNS 提供的稳定域名 六、Redis 集群
1、redis 集群形式
1、数据分区方案 1、客户端分区 客户端分区方案 的代表为 Redis ShardingRedis Sharding 是 Redis Cluster 出来之前业界普遍使用的 Redis 多实例集群 方法。Java 的 Redis 客户端驱动库 Jedis支持 RedisSharding 功能即 ShardedJedis 以及 结合缓存池 的 ShardedJedisPool。 优点 不使用 第三方中间件分区逻辑 可控配置 简单节点之间无关联容易 线性扩展灵活性强。 缺点 客户端 无法 动态增删 服务节点客户端需要自行维护 分发逻辑客户端之间 无连接共享会造成 连接浪费。
2、代理分区 代理分区常用方案有 Twemproxy 和 Codis。 3、redis-cluster
2、高可用方式
1、Sentinel 哨兵机制支持高可用 前面介绍了主从机制但是从运维角度来看主节点出现了问题我们还需要通过人工干预的方式把从节点设为主节点还要通知应用程序更新主节点地址这种方式非常繁琐笨重 而且主节点的读写能力都十分有限有没有较好的办法解决这两个问题哨兵机制就是针对第 一个问题的有效解决方案第二个问题则有赖于集群哨兵的作用就是监控 Redis 系统的运行状况其功能主要是包括以下三个
监控(Monitoring): 哨兵(sentinel) 会不断地检查你的 Master 和 Slave 是否运作正常。
提醒(Notification): 当被监控的某个 Redis 出现问题时, 哨兵(sentinel) 可以通过 API向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover): 当主数据库出现故障时自动将从数据库转换为主数据库。 哨兵的原理 Redis 哨兵的三个定时任务Redis 哨兵判定一个 Redis 节点故障不可达主要就是通过三个定时监控任务来完成的 每隔 10 秒每个哨兵节点会向主节点和从节点发送info replication 命令来获取最新的拓扑结构 每隔 2 秒每个哨兵节点会向 Redis 节点的_sentinel_:hello 频道发送自己对主节点是否故障的判断以及自身的节点信息并且其他的哨兵节点也会订阅这个频道来了解其他哨兵节点的信息以及对主节点的判断 每隔 1 秒每个哨兵会向主节点、从节点、其他的哨兵节点发送一个 “ping” 命令来做心跳检测
如果在定时 Job3 检测不到节点的心跳会判断为“主观下线”。如果该节点还是主节点那么还会通知到其他的哨兵对该主节点进行心跳检测这时主观下线的票数超过了数时那么这个主节点确实就可能是故障不可达了这时就由原来的主观下线变为了“客观下 线”。
故障转移和 Leader 选举 如果主节点被判定为客观下线之后就要选取一个哨兵节点来完成后面的故障转移工作选举出一个 leader这里面采用的选举算法为 Raft。选举出来的哨兵 leader 就要来完成故障转移工作也就是在从节点中选出一个节点来当新的主节点这部分的具体流程可参考引用. 《深入理解 Redis 哨兵搭建及原理》。
2、Redis-Cluster https://redis.io/topics/cluster-tutorial/ Redis 的官方多机部署方案Redis Cluster。一组 Redis Cluster 是由多个 Redis 实例组成官方推荐我们使用 6 实例其中 3 个为主节点3 个为从结点。一旦有主节点发生故障的时候Redis Cluster 可以选举出对应的从结点成为新的主节点继续对外服务从而保证服务的高可用性。那么对于客户端来说知道知道对应的 key 是要路由到哪一个节点呢Redis Cluster把所有的数据划分为 16384 个不同的槽位可以根据机器的性能把不同的槽位分配给不同的 Redis 实例对于 Redis 实例来说他们只会存储部分的 Redis 数据当然槽的数据是可以迁移的不同的实例之间可以通过一定的协议进行数据迁移。 1、槽 Redis 集群的功能限制Redis 集群相对 单机 在功能上存在一些限制需要 开发人员 提前了解在使用时做好规避。JAVA CRC16 校验算法 key 批量操作 支持有限。 类似 mset、mget 操作目前只支持对具有相同 slot 值的 key 执行 批量操作。对于 映射为不同 slot 值的 key 由于执行 mget、mget 等操作可能存在于多个节点上因此不被支持。 key 事务操作 支持有限。 只支持 多 key 在 同一节点上 的 事务操作当多个 key 分布在 不同 的节点上时 无法 使用事务功能。 key 作为 数据分区 的最小粒度 不能将一个 大的键值 对象如 hash、list 等映射到 不同的节点。 不支持 多数据库空间 单机 下的 Redis 可以支持 16 个数据库db0 ~ db15集群模式 下只能使用 一个 数据库空间即 db0。 复制结构 只支持一层 从节点 只能复制 主节点不支持 嵌套树状复制 结构。 命令大多会重定向耗时多 2、一致性 hash 一致性哈希 可以很好的解决 稳定性问题可以将所有的 存储节点 排列在 收尾相接 的Hash 环上每个 key 在计算 Hash 后会 顺时针 找到 临接 的 存储节点 存放。而当有节点 加入 或 退出 时仅影响该节点在 Hash 环上 顺时针相邻 的 后续节点。 Hash 倾斜 如果节点很少容易出现倾斜负载不均衡问题。一致性哈希算法引入了虚拟节点在整个环上均衡增加若干个节点。比如 a1a2b1b2c1c2a1 和 a2 都是属于 A 节点的。解决 hash 倾斜问题
3、部署 Cluster
1、创建 6 个 redis 节点 3 主 3 从方式从为了同步备份主进行 slot 数据分片
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.10
cluster-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 stop $(docker ps -a |grep redis-700 | awk { print $1})
docker rm $(docker ps -a |grep redis-700 | awk { print $1})2、使用 redis 建立集群
docker exec -it redis-7001 bashredis-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 13、测试集群效果
随便进入某个 redis 容器 docker exec -it redis-7002 /bin/bash 使用 redis-cli 的 cluster 方式进行连接 redis-cli -c -h 192.168.56.10 -p 7006 cluster info 获取集群信息 cluster nodes获取集群节点 Get/Set 命令测试将会重定向 节点宕机slave 会自动提升为 mastermaster 开启后变为 slave
4、k8s 部署 redis
参照有状态部署即可
七、Elasticsearch 集群
1、集群原理
https://www.elastic.co/guide/cn/elasticsearch/guide/current/index.html https://www.elastic.co/guide/cn/elasticsearch/guide/current/distributed-cluster.html elasticsearch 是天生支持集群的他不需要依赖其他的服务发现和注册的组件如 zookeeper这些因为他内置了一个名字叫ZenDiscovery 的模块是 elasticsearch 自己实现的一套用于节点发现和选主等功能的组件所以 elasticsearch 做起集群来非常简单不需要太多额外的配置和安装额外的第三方组件。
1、单节点 一个运行中的 Elasticsearch 实例称为一个节点而集群是由一个或者多个拥有相同cluster.name 配置的节点组成 它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时集群将会重新平均分布所有的数据。 当一个节点被选举成为 主节点时 它将负责管理集群范围内的所有变更例如增加、删除索引或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等操作所以当集群只拥有一个主节点的情况下即使流量的增加它也不会成为瓶颈。任何节点都可以成为主节点。我们的示例集群就只有一个节点所以它同时也成为了主节点。 作为用户我们可以将请求发送到 集群中的任何节点 包括主节点。 每个节点都知道任意文档所处的位置并且能够将我们的请求直接转发到存储我们所需文档的节点。无论我们将请求发送到哪个节点它都能负责从各个包含我们所需文档的节点收集回数据并将最终结果返回給客户端。 Elasticsearch 对这一切的管理都是透明的。
2、集群健康
Elasticsearch 的集群监控信息中包含了许多的统计数据其中最为重要的一项就是 集群健康 它在 status 字段中展示为 green 、 yellow 或者 red 。
GET /_cluster/health status 字段指示着当前集群在总体上是否工作正常。它的三种颜色含义如下 green所有的主分片和副本分片都正常运行。 yellow所有的主分片都正常运行但不是所有的副本分片都正常运行。 red有主分片没能正常运行。
3、分片
一个 分片 是一个底层的 工作单元 它仅保存了全部数据中的一部分。我们的文档被存储和索引到分片内但是应用程序是直接与索引而不是与分片进行交互。分片就认为是一个数据区 一个分片可以是 主 分片或者 副本 分片。索引内任意一个文档都归属于一个主分片所以主分片的数目决定着索引能够保存的最大数据量。 在索引建立的时候就已经确定了主分片数但是副本分片数可以随时修改。 让我们在包含一个空节点的集群内创建名为 blogs 的索引。 索引在默认情况下会被分配 5 个主分片 但是为了演示目的我们将分配 3 个主分片和一份副本每个主分片拥有一个副本分片
PUT /blogs{
settings : {
number_of_shards : 3,
number_of_replicas : 1
}}此时集群的健康状况为 yellow 则表示全部 主分片都正常运行集群可以正常服务所有请求但是 副本 分片没有全部处在正常状态。 实际上所有 3 个副本分片都是 unassigned —— 它们都没有被分配到任何节点。在同一个节点上既保存原始数据又保存副本是没有意义的因为一旦失去了那个节点我们也将丢失该节点上的所有副本数据。 当前我们的集群是正常运行的但是在硬件故障时有丢失数据的风险。
4、新增节点
当你在同一台机器上启动了第二个节点时只要它和第一个节点有同样的 cluster.name 配置它就会自动发现集群并加入到其中。 但是在不同机器上启动节点的时候为了加入到同一集群你需要配置一个可连接到的单播主机列表。 详细信息请查看最好使用单播代替组播 此时cluster-health 现在展示的状态为 green 这表示所有 6 个分片包括 3 个主分片和3 个副本分片都在正常运行。我们的集群现在不仅仅是正常运行的并且还处于 始终可用 的状态。
5、水平扩容-启动第三个节点 Node 1 和 Node 2 上各有一个分片被迁移到了新的 Node 3 节点现在每个节点上都拥有 2 个分片而不是之前的 3 个。 这表示每个节点的硬件资源CPU, RAM, I/O将被更少的分片所共享每个分片的性能将会得到提升。
在运行中的集群上是可以动态调整副本分片数目的我们可以按需伸缩集群。让我们把副本数从默认的 1 增加到 2
PUT /blogs/_settings
{
number_of_replicas : 2
}blogs 索引现在拥有 9 个分片3 个主分片和 6 个副本分片。 这意味着我们可以将集群扩容到 9 个节点每个节点上一个分片。相比原来 3 个节点时集群搜索性能可以提升 3 倍。 6、应对故障 我们关闭的节点是一个主节点。而集群必须拥有一个主节点来保证正常工作所以发生的第一件事情就是选举一个新的主节点 Node 2 。 在我们关闭 Node 1 的同时也失去了主分片 1 和 2 并且在缺失主分片的时候索引也不能正常工作。 如果此时来检查集群的状况我们看到的状态将会为 red 不是所有主分片都在正常工作。 幸运的是在其它节点上存在着这两个主分片的完整副本 所以新的主节点立即将这些分片在 Node 2 和 Node 3 上对应的副本分片提升为主分片 此时集群的状态将会为 yellow 。 这个提升主分片的过程是瞬间发生的如同按下一个开关一般。 为什么我们集群状态是 yellow 而不是 green 呢 虽然我们拥有所有的三个主分片但是同时设置了每个主分片需要对应 2 份副本分片而此时只存在一份副本分片。 所以集群不能为 green 的状态不过我们不必过于担心如果我们同样关闭了 Node 2 我们的程序 依然 可以保持在不丢任何数据的情况下运行因为 Node 3 为每一个分片都保留着一份副本。 如果我们重新启动 Node 1 集群可以将缺失的副本分片再次进行分配。如果 Node 1依然拥有着之前的分片它将尝试去重用它们同时仅从主分片复制发生了修改的数据文件。
7、问题与解决
1、主节点 主节点负责创建索引、删除索引、分配分片、追踪集群中的节点状态等工作。Elasticsearch中的主节点的工作量相对较轻用户的请求可以发往集群中任何一个节点由该节点负责分发和返回结果而不需要经过主节点转发。而主节点是由候选主节点通过 ZenDiscovery 机 制选举出来的所以要想成为主节点首先要先成为候选主节点。 2、候选主节点 在 elasticsearch 集群初始化或者主节点宕机的情况下由候选主节点中选举其中一个作为主节点。指定候选主节点的配置为node.master: true。
当主节点负载压力过大或者集中环境中的网络问题导致其他节点与主节点通讯的时候主节点没来的及响应这样的话某些节点就认为主节点宕机重新选择新的主节点这样的话整个集群的工作就有问题了比如我们集群中有 10 个节点其中 7 个候选主节点1个候选主节点成为了主节点这种情况是正常的情况。但是如果现在出现了我们上面所说的主节点响应不及时导致其他某些节点认为主节点宕机而重选主节点那就有问题了这剩下的 6 个候选主节点可能有 3 个候选主节点去重选主节点最后集群中就出现了两个主节点的情况这种情况官方成为“脑裂现象”
集群中不同的节点对于 master 的选择出现了分歧出现了多个master 竞争导致主分片和副本的识别也发生了分歧对一些分歧中的分片标识为了坏片。 3、数据节点 数据节点负责数据的存储和相关具体操作比如 CRUD、搜索、聚合。所以数据节点对机器配置要求比较高首先需要有足够的磁盘空间来存储数据其次数据操作对系统 CPU、Memory 和 IO 的性能消耗都很大。通常随着集群的扩大需要增加更多的数据节点来提高可用性。指定数据节点的配置node.data: true。
elasticsearch 是允许一个节点既做候选主节点也做数据节点的但是数据节点的负载较重所以需要考虑将二者分离开设置专用的候选主节点和数据节点避免因数据节点负载重导致主节点不响应。
4、客户端节点 客户端节点就是既不做候选主节点也不做数据节点的节点只负责请求的分发、汇总等等但是这样的工作其实任何一个节点都可以完成因为在 elasticsearch 中一个集群内的节点都可以执行任何请求其会负责将请求转发给对应的节点进行处理。所以单独增加这样的节 点更多是为了负载均衡。指定该节点的配置为 node.master: false node.data: false 5、脑裂”问题可能的成因 1.网络问题集群间的网络延迟导致一些节点访问不到 master认为 master 挂掉了从而选举出新的 master并对 master 上的分片和副本标红分配新的主分片 2.节点负载主节点的角色既为 master 又为 data访问量较大时可能会导致 ES 停止响应造成大面积延迟此时其他节点得不到主节点的响应认为主节点挂掉了会重新选取主节点。 3.内存回收data 节点上的 ES 进程占用的内存较大引发 JVM 的大规模内存回收造成 ES进程失去响应。
脑裂问题解决方案 角色分离即 master 节点与 data 节点分离限制角色数据节点是需要承担存储和搜索的工作的压力会很大。所以如果该节点同时作为候选主节点和数据节点 那么一旦选上它作为主节点了这时主节点的工作压力将会非常大出现脑裂现象的概率就增加了。 减少误判配置主节点的响应时间在默认情况下主节点 3 秒没有响应其他节 点就认为主节点宕机了那我们可以把该时间设置的长一点该配置是 discovery.zen.ping_timeout: 5 选举触发discovery.zen.minimum_master_nodes:1默认是 1该属性定义的是为了形成一个集群有主节点资格并互相连接的节点的最小数目。 一 个 有 10 节 点 的 集 群 且 每 个 节 点 都 有 成 为 主 节 点 的 资 格 discovery.zen.minimum_master_nodes 参数设置为 6。 正常情况下10 个节点互相连接大于 6就可以形成一个集群。 若某个时刻其中有 3 个节点断开连接。剩下 7 个节点大于 6继续运行之前的集群。而断开的 3 个节点小于 6不能形成一个集群。 该参数就是为了防止”脑裂”的产生。 建议设置为(候选主节点数 / 2) 1,
8、集群结构
1、集群结构
以三台物理机为例。在这三台物理机上搭建了 6 个 ES 的节点三个 data 节点三个 master节点每台物理机分别起了一个 data 和一个 master3 个 master 节点目的是达到n/21 等于 2 的要求这样挂掉一台 master 后不考虑 datan 等于 2满足参数其他两个 master 节点都认为 master 挂掉之后开始重新选举
master 节点上 node.master true node.data false discovery.zen.minimum_master_nodes 2 data 节点上 node.master false node.data true 2、集群搭建
所有之前先运行sysctl -w vm.max_map_count262144 我们只是测试所以临时修改。永久修改使用下面 #防止 JVM 报错 echo vm.max_map_count262144 /etc/sysctl.conf sysctl -p 0、准备 docker 网络
Docker 创建容器时默认采用 bridge 网络自行分配 ip不允许自己指定。 在实际部署中我们需要指定容器 ip不允许其自行分配 ip尤其是搭建集群时固定 ip是必须的。 我们可以创建自己的 bridge 网络 mynet创建容器的时候指定网络为 mynet 并指定 ip即可。 查看网络模式 docker network ls 创建一个新的 bridge 网络
docker network create --driver bridge --subnet172.18.12.0/16 --gateway172.18.1.1 mynet
查看网络信息 docker network inspect mynet
以后使用–networkmynet --ip 172.18.12.x 指定 ip 1、3-Master 节点创建
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/21
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} \ --networkmynet --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
donedocker stop $(docker ps -a |grep elasticsearch-node-* | awk { print $1})
docker rm $(docker ps -a |grep elasticsearch-node-* | awk { print $1})2、3-Data-Node 创建
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 #互相通信 ip要设置为本机可被外界访问的 ip否则
无法通信
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/21
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} \ --networkmynet --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
done3、测试集群
http://192.168.56.10:9201/_nodes/process?pretty 查看节点状况 http://192.168.56.10:9201/_cluster/stats?pretty 查看集群状态 http://192.168.56.10:9201/_cluster/health?pretty 查看集群健康状况 http://192.168.56.10:9202/_cat/nodes 查看各个节点信息 $ curl localhost:9200/_cat /_cat/allocation /_cat/shards /_cat/shards/{index} /_cat/master /_cat/nodes /_cat/indices /_cat/indices/{index} /_cat/segments /_cat/segments/{index} /_cat/count /_cat/count/{index} /_cat/recovery /_cat/recovery/{index} /_cat/health /_cat/pending_tasks /_cat/aliases /_cat/aliases/{alias} /_cat/thread_pool /_cat/plugins /_cat/fielddata /_cat/fielddata/{fields} /_cat/nodeattrs /_cat/repositories /_cat/snapshots/{repository}
3、k8s 上部署
有状态服务 jvm.options -Xms100m -Xmx512m
八、RabbitMQ 集群
1、集群形式
RabbiMQ 是用 Erlang 开发的集群非常方便因为 Erlang 天生就是一门分布式语言但其本身并不支持负载均衡。
RabbitMQ 集群中节点包括内存节点(RAM)、磁盘节点(Disk消息持久化)集群中至少有一个 Disk 节点。
普通模式(默认) 对于普通模式集群中各节点有相同的队列结构但消息只会存在于集群中的一个节点。对于消费者来说若消息进入 A 节点的 Queue 中当从 B 节点拉取时RabbitMQ 会将消息从 A 中取出并经过 B 发送给消费者。 应用场景该模式各适合于消息无需持久化的场合如日志队列。当队列非持久化且创建该队列的节点宕机客户端才可以重连集群其他节点并重新创建队列。若为持久化只能等故障节点恢复。
镜像模式 与普通模式不同之处是消息实体会主动在镜像节点间同步而不是在取数据时临时拉取高可用该模式下mirror queue 有一套选举算法即 1 个 master、n 个 slaver生产者、消费者的请求都会转至 master。 应用场景可靠性要求较高场合如下单、库存队列。 缺点若镜像队列过多且消息体量大集群内部网络带宽将会被此种同步通讯所消耗。 1镜像集群也是基于普通集群即只有先搭建普通集群然后才能设置镜像队列。 2若消费过程中master 挂掉则选举新 master若未来得及确认则可能会重复消费
1、搭建集群
mkdir /mydata/rabbitmqcd rabbitmq/mkdir rabbitmq01 rabbitmq02 rabbitmq03docker run -d --hostname rabbitmq01 --name rabbitmq01 -v
/mydata/rabbitmq/rabbitmq01:/var/lib/rabbitmq -p 15673:15672 -p 5673:5672 -e
RABBITMQ_ERLANG_COOKIEwxn rabbitmq:managementdocker run -d --hostname rabbitmq02 --name rabbitmq02 -v
/mydata/rabbitmq/rabbitmq02:/var/lib/rabbitmq -p 15674:15672 -p 5674:5672 -e
RABBITMQ_ERLANG_COOKIEwxn --link rabbitmq01:rabbitmq01
rabbitmq:managementdocker run -d --hostname rabbitmq03 --name rabbitmq03 -v
/mydata/rabbitmq/rabbitmq03:/var/lib/rabbitmq -p 15675:15672 -p 5675:5672 -e
RABBITMQ_ERLANG_COOKIEwxn --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
Exit
进入第二个节点
docker exec -it rabbitmq02 /bin/bash
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster --ram rabbitrabbitmq01
rabbitmqctl start_app
exit
进入第三个节点
docker exec -it rabbitmq03 bash
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster --ram rabbitrabbitmq01
rabbitmqctl start_app
exit3、实现镜像集群
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 开始的队列2、集群测试
随便在 mq 上创建一个队列发送一个消息保证整个集群其他节点都有这个消息。如果 master 宕机其他节点也能成为新的 master
3、k8s 上部署
九、Jenkins
1、Jenkins
官方文档 https://jenkins.io/zh/doc/pipeline/tour/getting-started/ Jenkins 是开源 CICD 软件领导者 提供超过 1000 个插件来支持构建、部署、自动化 满足任何项目的需要。
2、Jenkins 流水线
https://jenkins.io/zh/doc/book/pipeline
3、k8s 部署 nacos
docker run --env MODEstandalone --name nacos \ -v /mydata/nacos/conf:/home/nacos/conf -d -p 8848:8848 nacos/nacos-server:1.1.4
4、k8s 部署 sentinel
可以制作一个镜像并启动它暴露访问 docker run --name sentinel -d -p 8858:8858 -d bladex/sentinel-dashboard:1.6.3
5、k8s 部署 zipkin
docker run -d -p 9411:9411 openzipkin/zipkin 或者 docker run --env STORAGE_TYPEelasticsearch --env ES_HOSTS192.168.56.10:9200 openzipkin/zipkin
十、K8S部署应用
1、k8s部署应用流程 2、生产环境配置抽取
3、创建微服务Dockerfile
4、创建微服务k8s部署描述文件
5、理解targetPort、port、nodePort
6、流水线第一步拉取gitee代码参数化构建环境变量
7、流水线第二步Sonar代码质量分析
8、流水线第三步构建推送镜像
9、流水线第四步编写完成
10、部署-移植数据库
11、流水线部署所有微服务
12、部署整合阿里云镜像仓库
13、Jenkins修改阿里云镜像仓库
14、流水线部署gateway
15、流水线部署auth-server
16、部署cart
17、部署coupon
18、修改为共有仓库
19、部署前置nginx
20、创建网关与应用路由
21、部署前端vue项目
22、滚动更新部署admin-vue-app
23、线上预警和监控
