CSDN_LiMingfly的博客

在 AMQP 中，Producer 将消息发送到 Exchange ，再由 Exchange 将消息路由到一个或多个 Queue 中（或者丢弃）。Exchange 根据 Routing Key 和 Binding Key 将消息路由到 Queue ，目前提供了四种类型。A. QueueQueue: Queue（队列）是RabbitMQ的内部对象，用于存储消息,RabbitMQ 中的消息都只能存储在 Queue 中,生产消息并最终投递到Queue中, 消费者可以从Queue中获取消息并消费。

因为进入公司后，就不只是你一个人在一个工程上写代码，而是所有这个项目组的伙伴都需要在这个工程上写代码，大家要在统一的Git的规范完成代码开发和提交。只要你的代码是通过 Git 检出的，那么通过配置 Git 的 IntelliJ IDEA 打开工程，就会自动的被 Git 管理。zip 下载的代码，只是当前分支的，下载后用 IntelliJ IDEA 打开也没有 Git 标识，不能进行仓库的pull、push、checkout等操作。因为我们所有的都是合并到 test 分支，所以 test 分支丢失也没问题。

使用yum在linux下安装ngin遇到的一些问题 总结。

事实上Redisson并没有不止步于此，在分布式锁的基础上还提供了联锁（MultiLock），读写锁（ReadWriteLock），公平锁（Fair Lock），红锁（RedLock），信号量（Semaphore），可过期性信号量（PermitExpirableSemaphore）和闭锁（CountDownLatch）这些实际当中对多线程高并发应用至关重要的基本部件。Redisson内部提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期。

Zookeeper的集群模式安装非常简单，首先按照上面所说的zookeeper遵从只要有半数以上节点存活，Zookeeper集群就能正常服务的原则，所以Zookeeper适合安装奇数台服务器，偶数台机器并不会加强集群的高可用性，反而白白浪费一台机器资源，3台和4台服务器是一样滴，由此我们选择使用3台服务器构建集群，这也是在生产环境中比较合适常见的集群配比了。假设ZooKeeper由5台服务器组成，SID分别为1、2、3、4、5，ZXID分别为8、8、8、7、7，并且此时SID为3的服务器是Leader。

Spring Cloud 为开发人员提供了一系列工具，用于快速构建分布式系统中的一些常见模式（例如配置管理、服务发现、断路器、智能路由、微代理、控制总线、微服务和契约测试）。Feign 提供了可插拔的编码器和解码器，支持多种数据格式，并且可以与 Spring Cloud 集成，方便地实现负载均衡和服务发现。其简洁的 API 和高度的可扩展性，使得 Feign 成为微服务架构中常用的工具之一。它允许各个服务在启动时注册自己的信息，并能够动态地发现其他服务的位置和状态，从而实现负载均衡和故障转移。

1：domain 是领域层，提供一个个领域服务。如果一个工程有多个领域，则有不同的 a、b、c 领域包，每个包下有一套【event、model、repository、service】。点击 + 添加一个本地环境，之后配置你的 IP kafka 这样就能找这个地址了。3：最后是 trigger 触发器层，所有的 http、rpc、job、mq 都是一种触发行为。2：在领域层定义的 event 事件，里面涵盖了事件消息。使用docker-compose.yml进行一键部署安装。脚本在代码中提供了完整的语句。

在Java中，提供了一些关于使用IO的API，可以供开发者来读写外部数据和文件，我们称这些API为Java IO。IO是Java中比较重要知识点，且比较难学习的知识点。并且随着Java的发展为提供更好的数据传输性能，目前有三种IO共存；分别是BIO、NIO和AIO。同步阻塞I/O模式是一个比较传统的通信方式，模式简单，使用方便。但并发处理能力低，通信耗时，依赖网速。同步非阻塞模式NIO 与原来的 I/O 有同样的作用和目的, 他们之间最重要的区别是数据打包和传输的方式。

编辑数据库连接的地址，用于连接mysql数据库。注意此处的mysql.xxx.tech:3306/nacos nacos为此前创建的数据库名。方式二：由于端口号的问题，在第四步，编辑端口号，注意端口号需要大于5001。问题原因：没有找到数据源，一般情况是application.properties中，配置的mysq连接有问题。D:使用Navicat在mysql中创建名为nacos的数据库，注意数据库名后面会用上.解决问题：核对第4步中的数据库配置，注意域名、数据库、mysql的账号密码是否正确。

由于业务数据来源不同 需要配置多个数据源来进行数据的查询 编辑等操作 这一切换业务对数据的一致性要求很高那就要保证ACID啦 也就是数据的有效性 要么是成功的 要么是失败的。例如：方法可能继续在现有事务中运行，也可能开启一个新事务，并在自己的事务中运行。一定要明白事务的传播特性，开发中其实常用的就只有REQUIRED和REQUIRES_NEW，大家只要把这两个搞明白，就能应对绝大数的问题。多数据源失效，然后去掉事务发现切换正常 在于这样的切换失去了事务控制的行为。事务的传播行为可以由传播属性指定。

俗话说他就是看门狗，看门狗机制是一种用于保持Redis连接活跃性的方法，通常用于分布式锁的场景。看门狗的工作原理是：当客户端获取到锁之后，会对Redis中的一个特定的键设置一个有限的过期时间，然后每隔一段时间（默认是15秒），客户端会对这个键“续约”，即重新设置它的过期时间，以此来保持锁的持有状态，防止锁因为某些原因（如客户端崩溃或网络问题）而被释放。以上的是分布式锁之RedissonLock 若需完整代码 可识别二维码后 给您发代码。实现DistributedLock的实现类逻辑。

以上的是分布式锁之-mysql 若需完整代码 可识别二维码后 给您发代码。1:基于 MySQL 实现的乐观锁。2:基于 MySQL 实现的悲观锁。

即分布式系统中的锁。在单体应用中我们通过锁解决的是控制共享资源访问的问题，而分布式锁，就是解决了分布式系统中控制共享资源访问的问题。与单体应用不同的是，分布式系统中竞争共享资源的最小粒度从线程升级成了进程。以上的是分布式锁之-redis 若需完整代码 可识别二维码后 给您发代码。A:Redisson 实现的分布式锁使用演示。B：自己实现的 Redis 分布式锁使用演示。2：高可用的获取锁与释放锁。3：高性能的获取锁与释放锁。

timeout ：超过收集的时间的最大等待时长，单位：毫秒。不过要注意，这里的超时开始计时的时间，是以最后一次发送时间为起点。但是 RabbitMQ 并没有提供了批量发送消息的 API 接口,使用 spring-amqp 的 BatchingRabbitTemplate 实现批量能力。不过值得注意的是，我们一次发送十条消息到 RabbitMQ Broker 中去，在 RabbitMQ Broker 显示的也是 1 个消息。bufferLimit ：超过收集的消息占用的最大内存。

在一些业务场景下，我们希望使用 Consumer 批量消费消息，提高消费速度。可以通过对 SimpleRabbitListenerContainerFactory 进行配置实现批量消费能力。若需完整代码 可识别二维码后 给您发代码。

事务要么成功 要么失败 传统事务有4个主要特性:原子性、一致性、隔离性、持久性。◆ Eventually consistent (最终一致性)◆ 分区容忍性 (Partition tolerance)◆ 随着后端架构的微服务化，事务无法在本地完成。◆ 在传统单体应用中，事务在本地即可完成。◆ 可用性(Availability)◆ 一致性(Consistency)◆ 一致性(Consistency)◆ 持久性(Durability)◆ 原子性(Atomicity)◆ 隔离性(Isolation)

若 RabbitMQ 服务器端一直没有收到消费者的确认信号，并且消费此消息的消费者已经断开连接， 则服务器端会安排该消息重新进入队列，等待投递给下一个消费者（也可能还是原来的那个消费者）。可以看到当前队列中的 “Ready” 状态和 “Unacked” 状态的消息数，分别对应等待投递给消费者的消息数和已经投递给消费者但是未收到确认信号的消息数。对于手动确认的方式，RabbitMQ Broker 将消息发送给 Consumer 之后，由 Consumer 手动确认之后，才任务消息投递成功。

接下来需要再介绍生产者的confirm机制；核心作用在与能确保生产者将消息发送到mq的channel中，这一过程需要确保消息不丢失就需要生产者给予mq一个确认发送消息的机制。confirm 模式最大的好处在于是异步的，一旦发布一条消息，生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息，当消息最终得到确认之后，生产者应用便可以通过回调方法来处理该确认消息，如果RabbitMQ 因为自身内部错误导致消息丢失，就会发送一条 nack 消息， 生产者应用程序同样可以在回调方法中处理该 nack 消息。

消息发送端的顺序，大部分业务不做要求，谁先发消息无所谓，如果遇到业务一定要发送消息也确保顺序，那意味着，只能全局加锁一个个的操作，一个个的发消息，不能并发发送消息。虽然消息队列的消息是顺序的，但是多个消费者并发消费消息，获取的消息的速度、执行业务逻辑的速度快慢、执行异常等等原因都会导致消息顺序不一致。我们说如何保证消息顺序性，通常说的就是消费者消费消息的顺序，在多个消费者消费同一个消息队列的场景，通常是无法保证消息顺序的，一般我们讨论如何保证消息的顺序性，会从下面三个方面考虑。2：队列中消息的顺序。

当生产者的推送速度是远远超过消费者的能力的，可以提高消费者的消费速度。比如在java中我们可以启动多个 JVM 进程，实现多进程的并发消费，从而加速消费的速度，在mq中也可以通过设置配置。Consumer 线程，负责从 RabbitMQ Broker 获取 Queue 中的消息，存储到内存中的 BlockingQueue 阻塞队列中。@RabbitListener 注解中，有 concurrency 属性，它可以指定并发消费的线程数。若需完整代码 可识别二维码后 给您发代码。

RabbitMQ 提供了过期时间 TTL 机制，可以设置消息在队列中的存活时长。在消息到达过期时间时，会从当前队列中删除，并被 RabbitMQ 自动转发到对应的死信队列中。延迟消息就是指当消息被发送以后，并不想让消费者立即拿到消息，而是等待指定时间后，消费者才拿到这个消息进行消费。2:利用 RabbitMQ 中的插件 x-delay-message。然后再来消费该死信队列，这样就可以实现一个延迟队列的效果。失败重试：业务操作失败后，间隔一定的时间进行失败重试。此种方式需要安装mq的延迟第一列插件。

找到 rabbitmq_delayed_message_exchange 去进行下载，注意要和你的 RabbitMQ 版本一致 比如我的 RabbitMQ 是 3.10.1 的， 就可以使用 3.10.x 的 插件。我们可以看到 是有 /plugins 路径的，复制插件到容器内部，复制的话我们可以借助 docker cp 指令来完成。到管理后台的页面上，去创建交换机的页面看一下，如果多了一种 x-delayed-message,就说明安装成功。使用docker安装mq的延迟插件。1：上传到 docker。

docker-ce docker-ce-cli: 这是要安装的软件包的名称。docker-ce 是 Docker CE 软件的主要组件，docker-ce-cli 是用于与 Docker 进行交互的命令行工具。3：通过sudo yum install -y docker-ce docker-ce-cli 安装 Docker CE (Community Edition) 软件。-add-repo: 该选项告诉 yum-config-manager 命令要添加一个新的仓库。

ELK是包含但不限于Elasticsearch（简称es）、Logstash、Kibana 三个开源软件的组成的一个整体。这三个软件合成ELK。是用于数据抽取（Logstash）、搜索分析（Elasticsearch）、数据展现（Kibana）的一整套解决方案，所以也称作ELK stack。本课程从分别对三个组件经行详细介绍，尤其是Elasticsearch，因为它是elk的核心。本课程从es底层对文档、索引、搜索、聚合、集群经行介绍，从搜索和聚合分析实例来展现es的魅力。Logstash从内部如何采集数据