消息队列

一、消息队列的特点 1.消息队列是消息的链表,具有特定的格式,存放在内存中并由消息队列标识符标识. 2.消息队列允许一个或多个进程向它写入与读取消息. 3.管道和命名管道都是通信数据都是先进先出的原则。 4.消息队列可以实现消息的随机查询,消息不一定要以先进先出的次序读取,也可以按消息的类型读取.比FIFO更有优势。 目前主要有两种类型的消息队列：POSIX消息队列以及系统V消息队列，系统V消息队列目前被大量使用。系统V消息队列是随内核持续的，只有在内核重起或者人工删除时，该消息队列才会被删除。 二、相关函数 1. 获得key值 key_t ftok(char *pathname, int projid) #include <sys/types.h> #include <sys/ipc.h> 参数: pathname：文件名（含路径）,通常设置为当前目录“.” projid：项目ID，必须为非0整数（0-255）. 2. 创建消息队列 int msgget(key_t key, int msgflag) #include <sys/types.h> #include <sys/ipc.h> #include <sys/msg.h> 功能： 用于创建一个新的或打开一个已经存在的消息队列，此消息队列与key相对应。 参数： key：函数ftok的返回值或IPC_PRIVATE。

FAQ Q: 如何确保消息不丢失？ Q: mq 的缺点 Q: 如何避免消息重复投递或重复消费？ 在消息 生产 时，MQ 内部针对每条生产者发送的消息生成一个 inner-msg-id，作为去重的依据（消息投递失败并重传），避免重复的消息进入队列； 在消息 消费 时，要求消息体中必须要有一个 bizId（对于同一业务全局唯一，如支付 ID、订单 ID、帖子 ID 等）作为去重的依据，避免同一条消息被重复消费 Q: rabbitmq 怎么避免消息丢失？ 消息持久化 ACK确认机制 设置集群镜像模式 消息补偿机制 Q: 要保证消息持久化成功的条件有哪些？ 参考资料 https://zhuanlan.zhihu.com/p/62087283 https://juejin.im/post/5dfc93a5f265da339b500273#heading-7 来源： https://www.cnblogs.com/yudidi/p/12188722.html

一、消息队列的特点 1.消息队列是消息的链表,具有特定的格式,存放在内存中并由消息队列标识符标识. 2.消息队列允许一个或多个进程向它写入与读取消息. 3.管道和命名管道都是通信数据都是先进先出的原则。 4.消息队列可以实现消息的随机查询,消息不一定要以先进先出的次序读取,也可以按消息的类型读取.比FIFO更有优势。 目前主要有两种类型的消息队列： POSIX消息队列以及系统V消息队列，系统V消息队列目前被大量使用。系统V消息队列是随内核持续的，只有在内核重起或者人工删除时，该消息队列才会被删除。 二、相关函数 1. 获得key值 key_t ftok(char *pathname, int projid) #include <sys/types.h> #include <sys/ipc.h> 参数: pathname：文件名（含路径）, 通常设置为当前目录“.” 比如projid为'a',则为"./a"文件 projid：项目ID，必须为非0整数（0-255）. 2. 创建消息队列 int msgget(key_t key, int msgflag) #include <sys/types.h> #include <sys/ipc.h> #include <sys/msg.h> 功能： 用于创建一个新的或打开一个已经存在的消息队列，此消息队列与key相对应。 参数： key

一、消息队列 　　消息队列提供了一种从一个进程向另一个进程发送一个数据块的方法。 　　每个数据块都被认为含有一个类型，接收进程可以独立地接收含有不同类型的数据结构。我们可以通过发送消息来避免命名管道的同步和阻塞问题。 　　但是消息队列与命名管道一样，每个数据块都有一个最大长度的限制。 　　消息队列是系统内核地址空间中的一个内部的链表。消息可以按照顺序发送到队列中，也可以以几种不同的方式从队列中读取。每一个消息队列用一个唯一的IPC标识符表示。 二、 　　在<sys/msg.h>中，消息队列的数据结构是这样定义的： struct msgbuf｛ long mtype; /*type of message, must＞0*/ char mtext[1]; /*message text*/ ｝； 在数据结构msgbuf中共有两个元素： mtype指消息的类型，它由一个整数来代表，并且它只能是大于0的整数。 mtext是消息数据本身。 mtext字段不但可以存储字符，还可以存储任何其他的数据类型。此字段可以说是完全任意的，因为程序员自己可以重新定义此数据结构。请看下面重新定义的例子： struct my_msgbuf{ long mtype; /*Message type*/ char request_id; /*Request identifier*/ struct client

rabbitmq 重复确认导致消息丢失 背景 rabbitmq 在应用场景中，大多采用工作队列 work-queue的模式。 在一个常见的工作队列模式中，消费者 worker 将不断的轮询从队列中拉取最新消息，当队列负载压力增大时允许添加多个worker 进行处理。 然而执行一个任务可能需要相当的时长，这是由业务特性所决定的；如果 worker执行任务过程中出现异常甚至宕机，此时消息便会丢失，这是简单消息队列难以解决的问题。 rabbitmq 采用了消息确认机制来防止此类问题，在该机制中，worker需要向 MQ Server 返回 ACK响应以表示消息已确认处理； 在以下情况下，rabbitmq 会对消息进行重新投递： 1 client 未响应ACK, 主动关闭 Channel； 2 client 未响应ACk, 网络异常断开； 消息的重发机制没有超时限制，只要client 不响应ACK，那么会一直投递； 如果启用了消息持久化机制，那么消息将有进一步的保障。 问题描述及分析 1 客户端为简化应答处理，可以设置自动应答选项，如： boolean autoAck = false; channel.basicConsume(TASK_QUEUE_NAME, autoAck, consumer); 2 如果不启用自动应答，需要应用代码手动进行应答： try { doWork

文章目录 RabbitMQ 1 基本概念 2 安装 3 核心概念 交换器类型 4 入门demo 客户端开发相关说明 1 exchangeDeclare方法 2 queueDeclare方法 3 消费消息 4 消费的确认与拒绝 5 消息的可靠性投递 消息可靠性投递解决方案 RabbitMQ 1 基本概念 消息 (Message) 是指在应用间传送的数据。消息可以非常简单，比如只包含文本字符串、JSON 等，也可以很复杂，比如内嵌对象。 消息队列中间件 (Message Queue Middleware，简称为 MQ) （消息队列或者消息中间件）是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。 两种传递模式：点对点(P2P, Point-to-Point) 模式和发布/订阅 (Pub/Sub) 模式 比较主流的有 RabbitMQ,Kafka,ActiveMQ, RocketMQ等。 面向消息的中间件(简称为 MOM ， Message Oriented Middleware) 提供了以松散藕合的灵活方式集成应用程序的一种机制。它们提供了基于存储和转发的应用程序之间的异步数据发送，即应用程序彼此不直接通信，而是与作为中介的消息中间件通信 。

RabbitMQ一般情况很少丢失，但是不能排除意外，为了保证我们自己系统高可用，我们必须作出更好完善措施，保证系统的稳定性。 下面来介绍下，如何保证消息的绝对不丢失的问题，下面分享的绝对干货，都是在知名互联网产品的产线中使用。 1.消息持久化 2.ACK确认机制 3.设置集群镜像模式 4.消息补偿机制 第一种：消息持久化 RabbitMQ 的消息默认存放在内存上面，如果不特别声明设置，消息不会持久化保存到硬盘上面的，如果节点重启或者意外crash掉，消息就会丢失。 所以就要对消息进行持久化处理。如何持久化，下面具体说明下： 要想做到消息持久化，必须满足以下三个条件，缺一不可。 1） Exchange 设置持久化 2）Queue 设置持久化 3）Message持久化发送：发送消息设置发送模式deliveryMode=2，代表持久化消息 第二种：ACK确认机制 多个消费者同时收取消息，比如消息接收到一半的时候，一个消费者死掉了(逻辑复杂时间太长，超时了或者消费被停机或者网络断开链接)，如何保证消息不丢？ 这个使用就要使用Message acknowledgment 机制，就是消费端消费完成要通知服务端，服务端才把消息从内存删除。 这样就解决了，及时一个消费者出了问题，没有同步消息给服务端，还有其他的消费端去消费，保证了消息不丢的case。 第三种：设置集群镜像模式

Linux基础入门--进程间通信--消息队列 1.概述 2.key值和ID值 3.消息队列IPC原理 1.概述 System V提供的IPC机制主要有消息队列，信号量和共享内存3种机制。和文件一样，IPC在使用前必须先创建，每种IPC都有特定的生产者，所有者和访问权限。使用ipcs命令可以查看当前系统正在使用的IPC工具： [root@localhost swz] # ipcs ------- Shared MemorY Segments --------- //共享内存 key shmid ower perms bytes nattch status ------- Semaphore Arrays --------- //信号量 key shmid ower perms nsems ------- Message Queues ----------- //消息队列 key shmid ower perms used-bytes messages 由以上可以看出，一个IPC工具至少包含key值,ID值，拥有者，权限和使用的大小等关键信息。如果需要手动删除某个IPC机制，可以使用ipcrm命令。 2.key值和ID值 Linux系统为每个IPC机制都分配了唯一的ID，所有针对该IPC机制的操作都使用该ID值。因此，通信的双方都需要通过某个方法来获取ID值

rabbitmq /** * 连接工具类 */ public class ConnectionUtil { /** * 建立与RabbitMQ的连接 * @return * @throws Exception */ public static Connection getConnection ( ) throws Exception { //定义连接工厂 ConnectionFactory factory = new ConnectionFactory ( ) ; //设置服务地址 factory . setHost ( "127.0.0.1" ) ; //端口 factory . setPort ( 5672 ) ; //设置账号信息，用户名、密码、vhost //Virtual代表虚拟消息服务器,每个服务器相对独立 factory . setVirtualHost ( "/" ) ; factory . setUsername ( "guest" ) ; factory . setPassword ( "guest" ) ; // 通过工程获取连接 Connection connection = factory . newConnection ( ) ; return connection ; } } 1.hello world 简单的说就是 一个消息发送者，一个队列

目录 整体架构 消息加载器 生产者客户端可靠性保证 整体架构 生产过程由两个线程协调运行，分别为主线程和sender线程（发送线程）。 主线程中，由KafkaProducer创建消息，然后通过可能的拦截器、序列化器和分区器的作用，缓存消息到消息加载器（RecordAccumulator，也称为消息收集器）中，Sender线程负责从消息加载器（RecordAccumulator）中获取消息并将其发送到Kafka中。 消息加载器 消息加载器（RecordAccumulator）主要用来缓存消息以便Sender线程可以批量发送，进而减少网络传输的资源消耗以提升性能。 消息加载器（RecordAccumulator）缓存的大小可以通过生产者参数buffer.memory配置，默认值为33444432b，即32mb。 如果生产者发送消息的速度大于发送到服务器的速度，也就是RecordAccumulator缓存不够，此时kafkaproducer的send方法调用要被被阻塞，要么抛出异常，这个取决于参数max.block.ms参数，此参数的默认值为60000ms，60s。 主线程发送过来的消息会被追加到RecordAccumulator的某个双端队列中，在RecordAccumulator内部为每个分区都维护了一个双端队列，队列中的内容就是ProducerBatch，即Deque