消息机制

转： https://www.toutiao.com/a6583957771840913934/?tt_from=mobile_qq&utm_campaign=client_share&timestamp=1532999387&app=news_article&utm_source=mobile_qq&iid=39062783162&utm_medium=toutiao_android 一：确认种类 RabbitMQ的消息确认有两种。 一种是消息发送确认 。这种是用来确认生产者将消息发送给交换器，交换器传递给队列的过程中，消息是否成功投递。发送确认分为两步，一是确认是否到达交换器，二是确认是否到达队列。 第二种是消费接收确认 。这种是确认消费者是否成功消费了队列中的消息。 二：消息发送确认 （1） ConfirmCallback 通过实现ConfirmCallBack接口，消息发送到交换器 Exchange 后触发回调。 使用该功能需要开启确认，spring-boot中配置如下： spring.rabbitmq.publisher-confirms = true （2） ReturnCallback 通过实现ReturnCallback接口，如果消息从交换器发送到对应队列失败时触发（比如根据发送消息时指定的routingKey找不到队列时会触发） 使用该功能需要开启确认

一、什么是Netlink通信机制 　 Netlink套接字是用以实现 用户进程与内核进程 通信的一种特殊的进程间通信(IPC) ,也是网络应用程序与内核通信的最常用的接口。 Netlink 是一种特殊的 socket，它是 Linux 所特有的，类似于 BSD 中的AF_ROUTE 但又远比它的功能强大，目前在Linux 内核中 使用netlink 进行应用与内核通信的应用很多; 包括：路由 daemon（NETLINK_ROUTE），用户态 socket 协议（NETLINK_USERSOCK）， 防火墙（NETLINK_FIREWALL），netfilter 子系统（NETLINK_NETFILTER），内核事件向用户态通知（NETLINK_KOBJECT_UEVENT）， 通用 netlink（NETLINK_GENERIC）等。 Netlink 是一种在内核与用户应用间进行双向数据传输的非常好的方式，用户态应用使用标准的 socket API 就可以使用 netlink 提供的强大功能， 内核态需要使用专门的内核 API 来使用 netlink。 Netlink 相对于 系统调用 ， ioctl 以及 /proc文件系统 而言具有以下优点： 1，netlink使用简单，只需要在include/linux/netlink.h中增加一个新类型的 netlink 协议定义即可,

关于Android消息机制的源码分析 1.应用程序入口分析 应用程序入口是在 ActivityThread 类里 main 方法，（当应用启动后，底层通过C/C++调用main方法）。 核心代码： 1234567891011 public static void (String[] args) { Environment.initForCurrentUser(); EventLogger.setReporter(new EventLoggingReporter()); Looper.prepareMainLooper(); ActivityThread thread = new ActivityThread(); thread.attach(false); if (sMainThreadHandler == null) { sMainThreadHandler = thread.getHandler(); } Looper.loop(); } 1.1 初始化了Environment对象，然后创建了Lopper，然后开始消息循环。如果程序没有死循环，执行完main函数就会立马退出。之所以App可以一直运行是因为 Looper.loop() 是一个死循环。 1234 public static void loop() { for (;;) { }} 这里用 for(;;) 而不是

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接：https://blog.csdn.net/zlt995768025/article/details/81938449 消息什么情况下会丢失？配合mandatory参数或备份交换器来提高程序的健壮性 发送消息的交换器并没有绑定任何队列，消息将会丢失 交换器绑定了某个队列，但是发送消息时的路由键无法与现存的队列匹配 预估队列的使用情况？ 在后期运行过程中超过预定的阈值，可以根据实际情况对当前集群进行扩容或者将相应的队列迁移到其他集群。 消费消息？ 推模式，拉模式 保证消息的可靠性？ RabbitMQ 提供了消息确认机制( message acknowledgement)。 消费者在订阅队列时，可以指定 autoAck 参数，当 autoAck 等于 false 时， RabbitMQ 会等待消费者显式地回复确认信号后才从内存(或者磁盘)中移去消息(实质上 是先打上删除标记，之后再删除)。当 autoAck 等于 true 时， RabbitMQ 会自动把发送出去的 消息置为确认，然后从内存(或者磁盘)中删除，而不管消费者是否真正地消费到了这些消息。 在ack为false的情况下，消费者获取消息迟迟没有发送消费者确认消息的信号或者消费者断开，怎么办？ 当 autoAck

目录 前言 正文 消息队列概述 消息队列的特点 2.1. 采用异步处理模式 2.2. 应用系统之间解耦合 消息队列的传递服务模型 消息队列的的传输模式 4.1. 点对点模型 4.2. 发布/订阅模型（Pub/Sub） 消息队列应用场景 5.1. 异步处理 5.2. 系统解耦 5.3. 最终一致性 5.4. 广播 5.5. 流量削峰和流控 5.6. 日志处理 5.7. 消息通讯 消息队列的推拉模型 6.1. Push推消息模型 6.2. Pull拉消息模型 6.3. 两种类型的区别 消息队列技术对比 7.1. ActiveMQ 7.2. RabbitMQ 7.3. RocketMQ 7.4. Kafka 7.5. 几种消息队列对比 小结 前言 消息队列 已经逐渐成为企业应用系统 内部通信 的核心手段。它具有 低耦合 、 可靠投递 、 广播 、 流量控制 、 最终一致性 等一系列功能。 当前使用较多的 消息队列 有 RabbitMQ 、 RocketMQ 、 ActiveMQ 、 Kafka 、 ZeroMQ 、 MetaMQ 等，而部分 数据库 如 Redis 、 MySQL 以及 phxsql 也可实现消息队列的功能。 正文 1. 消息队列概述 消息队列 是指利用 高效可靠 的 消息传递机制 进行与平台无关的 数据交流 ，并基于 数据通信 来进行分布式系统的集成。 通过提供

一. handler作用 包含线程队列和消息队列,实现异步的消息处理机制. 1.运行在某个线程上,共享线程的消息队列. 2.接受消息,调度消息,派发消息和处理消息. 3.实现消息的异步处理; Handler能够让你发送和处理消息，以及Runnable对象；每个Handler对象对应一个Thread和Thread的消息队列。当你创建一个Handler时，它就和Thread的消息队列绑定在一起，然后就可以传递消息和runnable对象到消息队列中，执行消息后就从消息队列中退出。 　　Handler的作用就是：调度消息和runnable对象去被执行；使动作在不同的线程中被执行。 https://blog.csdn.net/u012974916/article/details/24580405 https://blog.csdn.net/songfeihu0810232/article/details/78648706 来源： https://www.cnblogs.com/Lee-yl/p/11534505.html

原文： https://blog.csdn.net/u012439416/article/details/74277494 6 Modem消息接收 3.1 消息初始化 初始化：qmi_modem_taskàqmii_init()àqmux_init()。qmux_init方法完成对控制通道的初始化后， 通过函数qmuxi_process_rx_sig方法开始从共享内存接收数据。调用流程如如下, (void)qmi_set_sig_handler(QMI_QMUX_RX_SIGNAL, qmuxi_process_rx_sig, NULL); 在qmuxi_process_rx_sig方法中，首先通过dsm_dequeue（）读取在队列中等待的QMUX消息， 赋值给指针qmux_pdu表示QMUX消息的首地址。 mux_pdu = dsm_dequeue( &qmux_s->io.rx_wm ); 然后调用qmuxi_process_msg方法开始对AP侧发过来的QMUX消息解包。 qmuxi_process_msg( qmux_s, qmux_pdu ); qmuxi_process_msg方法首先拆分IF Type，通过函数dsm_pull8（）进行解包。然后判断IF Type类型， 然后把QMUX Message通过qmuxi_input()继续处理。 在qmuxi_input

原文： https://blog.csdn.net/u012439416/article/details/74276672?utm_source=blogxgwz0 2.QMUX QMI Multiplexing Protocol（QMUX）：QMI的复用协议 消息从控制点经过类似socket的线程传到QMI接口后，QMI负责对数据进行封装，加上QMUX消息的头，发送到QMUX层， 再通过QMUX层传到共享内存到BP侧。 2.1 QMUX消息的格式： 整个QMUX控制信道的结构如上图， I/FType：QMI将控制点数据封装后，发送到QMUX前，加的消息头，长度为一个byte，值通常为0x01，表示这个 消息为QMUX消息，如果是其他值，则为其他消息。 Length： QMUX消息的长度，不包括I/F Type。 ControlFlags:控制位，表示消息传输的方向。长度为1个byte，只有第7个bit是标志位，其他位为0，bit7=1说明 QMUX消息由服务端发送，bit7=0由控制点发送。 Clien ID: 控制点的标识，在控制点和服务端都需要赋值，当在服务端发出的消息Client ID的值为0xFF，表示该 消息为广播消息，由服务端主动发出，被所有控制点搜到。 QMUX SDU和TLV结构： 在整个控制信道的消息中，出去消息标识头I/F Type，和QMUX消息头

6 Modem消息接收 3.1 消息初始化 初始化：qmi_modem_taskàqmii_init()àqmux_init()。qmux_init方法完成对控制通道的初始化后， 通过函数qmuxi_process_rx_sig方法开始从共享内存接收数据。调用流程如如下, (void)qmi_set_sig_handler(QMI_QMUX_RX_SIGNAL, qmuxi_process_rx_sig, NULL); 在qmuxi_process_rx_sig方法中，首先通过dsm_dequeue（）读取在队列中等待的QMUX消息， 赋值给指针qmux_pdu表示QMUX消息的首地址。 qmux_pdu = dsm_dequeue( &qmux_s->io.rx_wm ); 然后调用qmuxi_process_msg方法开始对AP侧发过来的QMUX消息解包。 qmuxi_process_msg( qmux_s, qmux_pdu ); qmuxi_process_msg方法首先拆分IF Type，通过函数dsm_pull8（）进行解包。然后判断IF Type类型， 然后把QMUX Message通过qmuxi_input()继续处理。 在qmuxi_input()中，会拆分QMUX的消息头，将消息头大卸八块,包括length,control_flags,client_id

前言: Qualcomm MSM Interface,作用用于AP和BP侧的交互，通俗说法就是让设备终端TE（可以是手机，PDA，计算机） 对高通BP侧的AMSS系统进行操作，如调用函数，读取数据，设置其中的NV项等。 QMI的核心称之为QMI框架（QMI Framework），其主要功能包括以下3点： 1,连接MSM模块和设备终端，提供一个正交的控制和数据通道。在QMI的消息用有两种定义，一种是 QMIControl Message,另一种是QMI DataMessage，支持这两种消息并发，不会互相干扰导致出错。 2,列举一系列的枚举逻辑设备，提供给连接使用。QMI机制类似于一个服务器机制，有相应的client端 和services端，对应于QMI的control point和service。在AP向BP发送请求时，AP作为client端，当AP 接收BP侧返回的响应时，AP作为services端。QMI包含了一系列的QMI Service，例如nas,voice,wds等， 这些不同的services相当于不同逻辑设备，给不同的app调用。 3,QMI有相应的消息和消息的协议，设备终端就是通过这些消息来访问AMSS。对于不同的qmi消息， 消息长度不一样，可自己定义消息长度，不同的qmi消息，消息格式是相同的。 上图是QMIFramework的一个软件结构图。 从图中可以看出