CYK_byte的博客

本文所讲的所有特性围绕此例展开2）实现服务端) {${~").build()3）服务启动配置.http(port) // 1.配置端口号.service(.addService(HelloServiceGrpcFacade()) // 2.添加服务示例.build().build()@JvmStatic@BeforeAll//这里启动不是异步的，所以不用 Thread.sleep 等待装饰器主要作用是为了给 服务 或 方法 添加切面逻辑。

配置 Armeria-gRPC 服务（这里没有使用 SpringBoot，默认构建 Bean）这里为了专注 Armeria-gRPC 的处理，使用 map 来替代数据库。Note：JDK 需要 11 及以上，Protobuf3.gradlew 跳过测试并构建，

试想一个问题：当 RabbitMQ 一个集群中有 3 个节点时，我们写代码时，因该访问哪个节点呢？当然时任意一个节点都可以~如果配置文件中写死访问的是 node1，但是 node1 挂了，不就是变相的等于 mq集群 整体不可用了吗，所以最好是有一个统一的入口，一个节点故障时，流量可以及时转移到其他节点.如果所有客户端都和 node1 建立连接，那么 node1 的负担会大大增加，而其他节点的负担不大导致资源浪费.2）使用 HAProxy 就可以实现流量的负载均衡.

1）RabbitMQ 普通队列在一个节点宕机之后，其他节点无法读写宕机节点的队列，为了解决这个问题，引入了仲裁队列.2）仲裁队列通过 Raft 协议，实现了不同节点间队列消息数据的复制，使得在 创建这个队列的节点 宕机时，其他节点仍然可以使用该队列进行服务.Ps：仲裁队列时 RabbitMQ3.8 版本的重要改动，是 镜像队列 的替代方案（设计上有缺陷）. 镜像队列已被弃用，并计划在将来的版本中移除.

1）普通模式中所有节点没有主从之分，所有节点的元数据（交换机、队列、绑定等）都是一致的.例如只要有任意一个节点上面 新增交换机， 那么这个交换机的元数据也会被复制到其他节点上.2）比较特殊的是队列，队列中的消息数据只保存在创建他的节点上，其他节点只保存元数据（队列名称、配置...）和指针（指向创建该队列的节点）例如 node1 创建 cyk.queue，那么 node2 只保存 队列的元数据 和 指向 node1 节点的指针，而 cyk.queue 中的消息，只会存在于 node1 节点中。

a）消息顺序性：消费者消费的消息的顺序 和 生产者发送消息的顺序是一致的.例如 生产者 发送消息顺序是 msg1、msg2、msg3，那么消费者也需要按照 msg1、msg2、msg3 的顺序进行消费.b）顺序不一致可能会导致哪些问题？消息1：修改 用户318 的昵称为 “白天”.消息2：修改 用户318 的昵称为 “黑夜”.那么，按正常的逻辑来讲，用户318 的名称最后因该为 “黑夜”，但如果 消息1 是最后一个被消费者消费的消息，那么 用户318 的名称就变成了 “白天”.

假设 key 不存在，那么通过 setnx 操作后，就会成功设置 key，并且在这之后无论多少次调用 setnx，都不会在影响第一次调用 setnx 操作后的结果.这个方案基本上就覆盖了 90% 的应用场景. 可能网上也还有很多其他资料描述其他的方法，但基本上都是围绕 全局唯一ID 的拓展（本质的思想都一样）.假设 i 初始为 0， 第一次调用后会 i = 1，并且后面每次调用都会影响第一调用后的结果（第二次 i++ ，i 就等于 2）.因此，对于可靠性要求高的场景，建议使用。

a）TTL（Time To Live 过期时间），RabbitMQ 可以对消息和队列设置 TTL. 当消息到达存活时间之后，还没有被消费，就会被自动清除.给消息设置TTL：MQ 扫描到队列头部消息（先进先出）过期了，就会剔除消息（这里会存在一个问题：当队列头部的消息还没过期，而队列头部之后的元素过期了却不会被清理，需要等到头部元素过期被清理后，才会依次扫描后面的元素）.给队列。

完成 redis 主从迁移：* `主节点` 从 10.200.16.75 迁移到 10.200.16.10* `从节点` 从 10.200.16.74 迁移到 10.200.16.11最后保证迁移后数据基本一致.

消息重试机制就是在消息处理失败之后重新发送，主要时为了解决消息发送过程可能会出现的问题，例如 网络故障、服务临时不可用 等.Ps：如果时程序逻辑引起的错误，那么即使重试多少次都是没有用的，但是可以通过配置重试次数来解决.

前面讲到了 生产者消息确认机制 和 消费者消息确认机制，保证了消息传输的可靠性，但是这还不够，试想如果 Broker 突然崩溃，那么所有的 交换机、队列、消息 不就全部都没了（RabbitMQ 以内存为主，硬盘为辅，默认交换机和队列都是非持久化的）. 因此需要持久化机制.a）交换机持久化如果交换机不设置持久化，那么在 rabbitmq 服务重启之后，相关的交换机元数据就会丢失，对一个长期使用的交换机来说，建议设置成持久化的.

为了保证信息 从生产者 发送到 队列，因此引入了生产者的消息确认机制.通过事务机制实现.通过发送确认机制（confirm 和 return）实现.因为事务机制比较消耗性能，在实际工作中用的也不多，因此这里主要介绍confirm 和 return机制来实现发送放的确认.a）confirm 确认模式如上图，confirm 确认模式主要保障于 生产者 到 交换机 的消息可靠性.如果 Exchange成功收到消息，那么 ConfirmCallback 这个回调 ack 参数就为true。

为了保证消息从 队列 到 消费者正确消费，那么就引入了消费者消息确认机制.a）消费者在订阅队列时，可以指定 autoAck 参数，根据这个参数设置，消息确认机制分为以下两种（以下讲到的方法和参数来自于 RabbitMQ 原生的 SDK，非 Spring 提供）.自动确认：当 autoAck = true 时，RabbitMQ 会自动把发送出去的消息置为确认，然后不管消费者是否真正的消费这些消息，都会从内存中删除.（适合对消息可靠性要求不高的场景）.

RabbitMQ 的队列在有多个消费者订阅时，默认会通过轮询的机制将消息分发给不同的消费者，但是有些消费者消费速度慢，有些消费者消费速度快，就会导致消费速度慢的消费者影响整个的任务的吞吐量下降例如，公司有1个正式员工和1个实习生，现在有 10 个任务分配平均给他们（各 5 个），而由于实习生干活比较慢，就会导致整个完成任务的吞吐量下降.消息分发机制给 “正式工” 多分一些任务，给 “实习生” 少分一些任务.

RabbitMQ 的 AMQP 协议实现了事务机制，允许开发者保证消息的发送和接收时原子性的，也就是说，要么消息全都发送成功，要么全都发送失败（只与发送方有关）.

Ps：这里的 ip 就是 VMnet8 的 ip，端口是代理的端口.b）通过 curl www.google.com 测验代理是否成功.a）打开此电脑，输入 “控制面板”，然后回车.b）记住你的代理端口。

b）使用 vim ~/.zshrc，找到 plugins，添加 zsh-syntax-highlighting 插件.b）在 ~/ 目录下，可以看到一个隐藏文件 .vimrc 文件（如果没有就创建），这里我给出一个最简单且够用的配置.b）使用 vim ~/.zshrc，找到 plugins，添加 zsh-augosuggestions 插件.b）点击菜单栏上的【编辑】->【虚拟网络编辑器】，打开下方的虚拟网络编辑器.alias 是 .zshrc 中的配置项（下载 zsh 时自带）.

b）找到如下这个路由，可以看到两次校验，可以肯定的是第一个校验是没有问题的（还有另一个 grafana.duitang.net 这个路由，我是直接可以访问的，他的鉴权逻辑只有 chkNormalPermissions ，因此肯定第一个是没问题的）那么想要让 roles 中添加 这个 SSO_SA_ROLE_NAME 这个东西，那么 SA 这个 List 中就必须要有指定的 id.这个 id 实际上就是员工 id，而 SA 中实际上是没有我的 员工的 id 的（上图是已经添加了我的员工 id 之后截的图）

我们知道在 Prometheus 配置文件中可以通过 static_configs 来配置静态地址来获取数据，但是在云环境下，特别是容器环境下，抓取的 地址 经常是变动的，也就是说，地址每次变动因此，我们不但需要去修改 prometheus.yml 文件，还需要重启 prometheus 来加载配置，十分麻烦.这个示例中，Prometheus 会每 10s 读取 '/root/prometheus/targets/' 目录下的所有以 .json 结尾的文件，获取最新的监控目标.

docker restart 重启 Prometheus，接着在 Prometheus 的 Targets 就可以观察到。docker restart 重启 Prometheus，接着在 Prometheus 的 Targets 就可以观察到。docker restart 重启 Prometheus，接着在 Prometheus 的 Targets 就可以观察到。docker restart 重启 Prometheus，接着在 Prometheus 的 Targets 就可以观察到。Ps：这里有点问题。