消息队列

RabbitMQ-C客户端使用说明 rabbitmq-c是一个用于C语言的，与AMQP server进行交互的client库，AMQP协议为版本0-9-1。rabbitmq-c与server进行交互前需要首先进行login操作，在操作后，可以根据AMQP协议规范，执行一系列操作。 这里，根据项目需求，只进行部分接口说明，文后附demo的github地址。 接口描述： amqp_connection_state_t amqp_new_connection(void); 接口说明：声明一个新的amqp connection int amqp_open_socket(char const *hostname, int portnumber); 接口说明：获取socket. 参数说明：hostname RabbitMQ server所在主机 portnumber RabbitMQ server监听端口 void amqp_set_sockfd(amqp_connection_state_t state,int sockfd); 接口说明：将amqp connection和sockfd进行绑定 amqp_rpc_reply_t amqp_login(amqp_connection_state_t state, char const *vhost,int channel_max,int

本文主要介绍什么是消息队列（MQ）,为什么使用消息队列，以及MQ的异步操作。 什么是消息队列？ “消息队列”是在消息的传输过程中保存消息的容器。主要是用来实现应用程序的异步和解耦，同时也能起到消息缓冲，消息分发的作用。消息中间件最主要的作用是解耦，中间件最标准的用法是生产者生产消息传送到队列，消费者从队列中拿取消息并处理，生产者不用关心是谁来消费，消费者不用关心谁在生产消息，从而达到解耦的目的。主要有ActiveMQ，RabbitMQ，Kafka，RocketMQ。 为什么要使用消息队列？ 主要原因是由于在高并发环境下，由于来不及同步处理，请求往往会发生堵塞，比如说，大量的insert，update之类的请求同时到达 MySQL ，直接导致无数的行锁表锁，甚至最后请求会堆积过多，从而触发too many connections错误。通过使用消息队列，我们可以异步处理请求，从而缓解系统的压力。 MQ的异步操作 使用消息队列将调用异步化，可改善网站的扩展性，使用消息队列将调用异步化，可改善网站的扩展性，还可改善网站系统的性能。 不使用消息队列： 使用消息队列： 在不使用消息队列的情况下，用户的请求数据直接写入数据库，在高并发的情况下，会对数据库造成巨大的压力， 同时也使得响应延迟加剧。在使用消息队列后，用户请求的数据发送给消息队列后立即返回，再由消息队列的消费者进程(通常情况下，

工作队列中，每个任务之分发给一个工作者。如果需要分发一个消息给多个消费者，这种模式被称为“发布/订阅” 交换器(Exchanges) RabbitMQ完整的消息模型 发布者（producer）是发布消息的应用程序 队列(queue)用于消息存储的缓冲 消费者（consumer）是接收消息的应用程序 RabbitMQ消息模型的核心理念是： 发布者(producer)不会直接发送任何消息给队列。事实上，发布者（producer）甚至不知道消息是否已经被投递到队列。 发布者（producer）只需要把消息发送给一个交换器（exchage），然后由它一边从发布者接收消息，一边把消息推入队列。交换器必须知道如何处理它接收到的消息，是应该推送到指定的队列还是多个队列，或者直接忽略消息。这些规则通过exchange type来定义。 交换器类型 1、direct 处理路由键，需要将一个队列绑定到交换机上，要求该消息与一个特定的路由键完全匹配。 是完整的匹配，与routing_key对应。 2、topic 将路由键和某模式进行匹配。此时队列需要绑定在一个模式上。 符号#匹配一个或多个词，符号*匹配不多不少一个词。 例如audit.#能够匹配到audit.irs.corportate,但是audit.*只会匹配audit.irs 类似消息归类 注：多台服务器访问同一个队列时

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 我们有兴趣听听ActiveMQ与RabbitMQ和ZeroMQ的优缺点。 还欢迎有关任何其他有趣的消息队列的信息。 #1楼 还有的RabbitMQ和ActiveMQ的之间的比较 在这里 。 开箱即用，ActiveMQ配置为保证消息传递 - 与不太可靠的消息传递系统相比，这会给人留下缓慢的印象。 如果您愿意，您可以随时更改性能配置，并获得至少与其他任何邮件系统一样的性能。 至少你有这个选择。 有关论坛和ActiveMQ常见问题解答的大量信息，用于配置扩展，性能和高可用性。 此外，ActiveMQ将在规范最终确定时支持AMQP 1.0，以及其他有线格式，如STOMP。 ActiveMQ的另一个好处是它的Apache项目，因此开发人员社区存在多样性 - 而且它与一家公司无关。 #2楼 我只能加上关于ActiveMQ的2美分，但因为这是最流行的一个： 您想要写的语言可能很重要。 尽管ActiveMQ确实拥有大多数客户端，但与Java库相比，它们的C＃实现远非完整。 这意味着一些基本功能是片状的（故障转移协议......好吧......在某些情况下失败，没有重新传递支持）而其他根本就不存在。 由于.NET似乎对项目来说并不是那么重要，因此开发速度相当慢，并且似乎没有任何发布计划。 Trunk经常被破坏

文章目录 Kafka 架构 常见术语 Kafka 作为一个消息引擎中间件，越来越多的被国内各个厂商使用。本篇主要介绍一下其系统架构及常用术语。 Kafka 架构 从上图可以看出，和其他消息引擎类似，主要由生产者、Kafka 集群、消费者构成。但是其中有一点需要注意的是，Kafka 集群和消费者依赖了ZooKeeper 集群。上图中的每个Broker 对应的就是一个一个的Kafka 实例，每个Broker 上面可能会有多个 Partition，也就是所谓的分区副本。如上面的Producer A 生产了 Topic A 的消息，然后存放的时候分为了 Partition 0 和 Partition 1 两个数据分区存储。Producer 生产出来的数据只会直接发给每个 Partition 的 Leader 来接收。然后每个 Partition 对应的 Follower 会复制Leader 上面的数据做冗余备份，Follower 本身不对外提供服务。 从上面的消费者可以看出，Consumer A1 和 Consumer A2 是一个消费者组。它们共同消费了 Topic A，此时对于同一个消费者组而言，同一个 Topic 不会重复消费。也就是 Topic A 的消息，在同一个消费者组内只会被一个消费者消费。 常见术语 Topic：消息主题，Kafka 会对消息进行归类，发布到Kafka

基于 RabbitMQ 的实时消息推送 俞 超 2016 年 4 月 11 日发布 Weibo Google+ 用电子邮件发送本页面 2 实现服务器端推送的几种方式 Web 应用都是基于 HTTP 协议的请求/响应模式，无法像 TCP 协议那样保持长连接，因此 Web 应用就很难像手机那样实现实时的消息推送。就目前来看，Web 应用的消息推送方式主要有以下几种： 1.Ajax 短轮询 Ajax 轮询主要通过页面端的 JS 定时异步刷新任务来实现数据的加载，但这种方式实时效果较差，而且对服务端的压力也较大。 2. 长轮询 长轮询主要也是通过 Ajax 机制，但区别于传统的 Ajax 应用，长轮询的服务器端会在没有数据时阻塞请求直到有新的数据产生或者请求超时才返回，之后客户端再重新建立连接获取数据，具体实现方式见图 1 所示。但长轮询服务端会长时间地占用资源，如果消息频繁发送的话会给服务端带来较大的压力。 图 1. 长轮询实现方式 3.WebSocket 双向通信 WebSocket 是 HTML5 中一种新的通信协议，能够实现浏览器与服务器之间全双工通信。如果浏览器和服务端都支持 WebSocket 协议的话，该方式实现的消息推送无疑是最高效、简洁的。并且最新版本的 IE、Firefox、Chrome 等浏览器都已经支持 WebSocket 协议，Apache Tomcat 7.0

　　rabbitmq作为企业级的消息队列，功能很齐全，既可以作为单一的部署模式，又可以做集群的部署模式 　　单一部署就不说了，就是在一台服务器上部署rabbitmq消息队列，可以参考我的博客： Ubuntu16.04下，erlang安装和rabbitmq安装步骤 去安装部署 　　集群部署有好几种方式，具体使用哪一种，要根据自己的需求而定，这里主要介绍一下普通集群和镜像集群 　　普通模式 　　普通模式是集群的默认模式，集群中各个节点拥有相同的队列结构，但是队列的消息实体已保存在其中一个节点，当消费者consumer连接集群中的某个节点时，会通过集群内部通信，将消息传到当前节点，再防御给消费者consumer，举个例子： 　　假设集群中有两个节点（A和B），当生产者producer将消息发布在A上，且消息实体保存在A上 时 ，但是A和B有相同的队列结构，当消费者 consumer 连接到B时，B会临时的从A拉去消息，然后再返回给消费者。 　　普通集群模式的部署，我们准备了三台测试服务器，IP分别是192.168.209.133， 192.168.209.134， 192.168.209.135，它们的hostname分别是test1，test2，test3， 　　然后分别安装rabbitmq，可以参考我的博客： Ubuntu16.04下，erlang安装和rabbitmq安装步骤

sendMessage方式：根据以上表格中三个关键类，下面分别从源码角度解释其作用 步骤： 1.Handler（创建handler对象时，主要做了两件事，1.指定looper对象；2.指定messageQueue对象） //流程：创建handler对象——>Handler构造方法——>指定当前线程的looper对象 =绑定当前线程——>指定looper对象中保存的消息队列对象MessageQueue /** * a.使用 */ private Handler mhandler = new Handler(){ // 通过复写handlerMessage()从而确定更新UI的操作 @Override public void handleMessage(Message msg) { ...// 需执行的UI操作 } }; /** *b.源码 */ public Handler(Callback callback, boolean async) { // 1. 指定Looper对象 mLooper = Looper.myLooper(); if (mLooper == null) { throw new RuntimeException( "Can't create handler inside thread that has not called Looper.prepare()");

Kafka安装： 下载kafka_2.10-0.8.2.1 1.关闭防火墙 2.修改配置文件 server.properties broker.id=1 log.dirs= /usr/kafka_2.10-0.8.2.1/data //最后不要写log zookeeper.connect=master:2181,slave01:2181,slave02:2181 delete.topic.enable = true //删除话题的时候需要设置其为true num.partitions=3//建议默认3个分区，如果AIP里面你的分区数大于系统规定的则抛出异常 //分发给其他两台服务器，每台机器的broker.id必须唯一 3.配置环境变量 常用操作命令： //启动。指定启动的配置文件， 输出到run_data目录， 2>&1所有正确错误的都输出， &后台运行 kafka-server-start.sh $KAFKA_HOME/config/server.properties >>$KAFKA_HOME/run_data 2>&1 & //创建话题 指定zookeeper集群中任意一个主机都可以 kafka-topics.sh --create --zookeeper master:2181 --replication-factor 3 --partitions 1 --topic

消息队列 消息队列内部实现原理： （1）点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除） 点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息， 而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者 接收处理，即使有多个消息监听者也是如此。 （2）发布/订阅模式（一对多，数据生产后，推送给所有订阅者） 发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅 者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即 使当前订阅者不可用，处于离线状态。 为什么需要消息队列？ （1）解耦： 允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 （2）冗余： 消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风 险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需 要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你 使用完毕。 （3）扩展性： 因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要 另外增加处理过程即可。 (4）灵活性 & 峰值处理能力： 在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。