之前注册的jihulab仓库做图床，类似于GitHub，但是偶然登录时提示试用期已经结束，需要购买专业或者旗舰版使用，为了避免保留期结束后数据被清空，所以需要迁移图片，之前买的服务器还是腾讯云的，所以这次选择用腾讯云cos。

概念延时队列也是一个消息队列，和普通队列区别之处只是它带有延时功能。例如实际开发的某些场景中，需要让消息在指定时间才会被消费 订单下单后指定时间未付款就取消 用户注册后，指定时间内未登录或验证，发送消息提醒 某个业务操作失败后，间隔一段时间重试或进行其他操作 类似的场景其实很多。并且上述情况好像也可以通过定时任务轮询来处理，但是性能不高，并且业务数据量大&存在高并发的场景下，极易导致系

SpringBoot作为目前后端开发的主流框架，基本上系统都有应用，并且它对其他很多框架提供了非常优秀的集成。 新建一个springboot工程 在Messaging选项中勾选RabbitMQ，之后卡一看到mavenpom文件中依赖spring-boot-starter-amqp，它继承了amqp-client依赖实现了amqp协议 123456789101112131415161718192

过期时间TTL先介绍一下TTL概念 TTL即Time to Live的简称，表示过期时间。RabbitMQ可以对消息和队列设置对应TTL 0、消息TTL设置 通过队列属性设置，队列中所有消息都有相同的过期时间。 通过消息属性设置，可以实现每个消息都有自己的过期时间。 二者可以同时使用，此时则以TTL数值较小的为准 1、队列上设置在定义队列时，添加属性x-message-ttl，单位是毫秒，这里设

交换机概念之前的示例，都是按照生产者-->消息队列-->消费者的概念进行的 实际上RabbitMQ消息传递模型的核心思想是：生产者的消息从来不会直接发送到队列。事实上，生产者甚至不知道消息会被发到哪个队列 相反，生产者只能将消息发送到交换器。交换器工作内容非常简单：一方面它接收来自生产者的消息，另一方面它将它们推送到队列中。交换器必须确切地知道如何处理它收到的消息。是推送到特定队列还是

消息分发策略默认的消息分发策略是轮询，参照上面的消息应答可以看出会有一定问题——消息处理慢的 AckConsumer1 和消息处理快的 AckConsumer2 分配了同等数量的消息，导致2早就结束空闲了，而1还有好几条消息没开始处理！因此看似公平的轮询分发其实是并不公平的 因此需要引入公平分发策略（Fair Dispatch）——在消费者中引入设置了 prefetchCount=1 参数的 ba

消息应答1、问题引出 假设消费者处理某个业务功能需要100条消息，现在获取了50条，还没处理完进程就终止了。 按照入门示例写的代码，未处理的消息就会被直接丢弃，而剩余未发送的50条消息，也不会再发给它了，因为它是不可接收的状态了。即此时这100条消息还未实现对应功能便被丢失了！ 2、解决方案 为了保证消息能可靠的到达消费者并处理，RabbitMQ引入了消息应答机制（message acknowle

1、消息队列1.1 消息队列的基本概念消息（Message）是指在应用层之间传递的数据，比如文本字符串、JSON。现在的互联网系统中，前后端各个组件模块间传递数据信息，都可以称之为消息 而消息队列中间件（Message Queue Middleware，简称MQ）则是利用 可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过消息模型，它可以在分布式环境下扩展进程间

MySQL基础架构以一条查询语句为例，通过查询语句在 MySQL 中的执行流程，了解 MySQL 的基础架构以及各组件模块的基本作用。 1select * from user where ID=10； 图片引用自：小林coding：图解MySQL专栏 如图是MySQL的基本架构示意图，MySQL 可以大致分为 Server 层和存储引擎层两大部分。 Server层包括连接器、查询缓存、

概述主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点。 默认情况下，每台Redis服务器都是主节点，且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。 主从复制的作用： 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。 故