消息队列

背景： RabbitMQ是一个由erlang开发的AMQP（Advanced Message Queue ）的开源实现。AMQP 的出现其实也是应了广大人民群众的需求，虽然在同步消息通讯的世界里有很多公开标准（如 COBAR的 IIOP ，或者是 SOAP 等），但是在异步消息处理中却不是这样，只有大企业有一些商业实现（如微软的 MSMQ ，IBM 的 Websphere MQ 等），因此，在 2006 年的 6 月，Cisco 、Redhat、iMatix 等联合制定了 AMQP 的公开标准。 　　RabbitMQ是由RabbitMQ Technologies Ltd开发并且提供商业支持的。该公司在2010年4月被SpringSource（VMWare的一个部门）收购。在2013年5月被并入Pivotal。其实VMWare，Pivotal和EMC本质上是一家的。不同的是VMWare是独立上市子公司，而Pivotal是整合了EMC的某些资源，现在并没有上市。 工作原理： 组成部分说明如下： Broker：消息队列服务进程，此进程包括两个部分：Exchange和Queue。 Exchange：消息队列交换机，按一定的规则将消息路由转发到某个队列，对消息进行过虑。 Queue：消息队列，存储消息的队列，消息到达队列并转发给指定的消费方。 Producer：消息生产者，即生产方客户端

1. 安装Kafka 1. 下载JDK 、kafka(自带Zookeeper) http://mirrors.hust.edu.cn/apache/kafka/1.0.0/kafka_2.11-1.0.0.tgz 下载 ，解压到 D:\STS_ENV\kafka_2.11-1.0.0 （执行 bin 下的脚本，此处使用 windows 所以使用 windows/ 下的 bat 脚本） 2. 下载 SecureCRT 连接 查看服务器系统版本 cat /proc/version [root@T-mysql ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.4 (Maipo) 1. 安装jdk 1.8.0_121 ： =》上传到/opt目录 =》解压jdk （ tar-zxvf jdk-8u121-linux-x64.tar ） =》配置环境变量：vi /etc/profile添 加如下参数： export JAVA_HOME=/opt/jdk1.8.0_121 export PATH=$JAVA_HOME/bin:$PATH export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar =》生效 source/etc

在进行定时获取代理ip， 黑名单ip，以及进行ip校验，相关信息及特征获取时，需要用到定时任务，常见的使用 linux 的crontab 来实现定时任务。但是为了在使用django，保持设计的一致性，就采用 celery 消息队列的定时任务来做。 开发环境： centos 7 python3.5 Name: celery Version: 4.0.2 mongodb, django d都是最新的 有关celery ［直接摘自参考的博客，懒得写］ Celery 是一个强大的分布式任务队列，它可以让任务的执行完全脱离主程序，甚至可以被分配到其他主机上运行。我们通常使用它来实现异步任务（ async task ）和定时任务（ crontab ）。它的架构组成如下图： 可以看到， Celery 主要包含以下几个模块： 任务模块 包含异步任务和定时任务。其中，异步任务通常在业务逻辑中被触发并发往任务队列，而定时任务由 Celery Beat 进程周期性地将任务发往任务队列。 消息中间件 Broker Broker ，即为任务调度队列，接收任务生产者发来的消息（即任务），将任务存入队列。 Celery 本身不提供队列服务，官方推荐使用 RabbitMQ 和 Redis 等。 任务执行单元 Worker Worker 是执行任务的处理单元，它实时监控消息队列，获取队列中调度的任务，并执行它。

一、为什么要用celery celery是一个简单、灵活、可靠的，处理大量消息的分布式系统，并且提供维护这样一个系统的必须工具。他是一个专注于实时处理的任务队列，同时也支持任务调度。 celery是异步任务队列/基于分布式消息传递的作业队列。它侧重于实时操作，但对调度支持也很好。celery用于生产系统每天处理数以百万计的任务。 【注：何为任务队列？任务队列是一种在线程或机器间分发任务的机制。消息队列的输入是工作的一个单元，称为任务，独立的职程（Worker）进程持续监视队列中是否有需要处理的新任务。）】。 Celery 用消息通信，通常使用中间人（Broker）在客户端和职程间斡旋。这个过程从客户端向队列添加消息开始，之后中间人把消息派送给职程。Celery 系统可包含多个职程和中间人，以此获得高可用性和横向扩展能力。 Celery 需要一个发送和接受消息的传输者。RabbitMQ 和 Redis 中间人的消息传输支持所有特性，但也提供大量其他实验性方案的支持，包括用 SQLite 进行本地开发。 Celery 可以单机运行，也可以在多台机器上运行，甚至可以跨越数据中心运行。 二、celery适用于那些场景 应用场景一：我们知道大型网站的性能非常重要，然而有时不得不做一些相当耗时的操作。 比如SNS网站的“新鲜事儿”系统，我发帖之后，会给所有关注我的人推送一条通知

1，管道,FIFO 2, 信号 3，消息队列 4，共享类存 5.文件映射 6.socket （ 1 ）管道（Pipe）：管道可用于具有亲缘关系进程间的通信，允许一个进程和另一个与它有共同祖先的进程之间进行通信。 　　（ 2 ）命名管道（named pipe）：命名管道克服了管道没有名字的限制，因此，除具有管道所具有的功能外，它还允许无亲缘关系进程间的通信。命名管道在文件系统中有对应的文件名。命名管道通过命令mkfifo或系统调用mkfifo来创建。 　　（ 3 ）信号（Signal）：信号是比较复杂的通信方式，用于通知接受进程有某种事件发生，除了用于进程间通信外，进程还可以发送信号给进程本身；linux除了支持Unix早期信号语义函数sigal外，还支持语义符合Posix.1标准的信号函数sigaction（实际上，该函数是基于BSD的，BSD为了实现可靠信号机制，又能够统一对外接口，用sigaction函数重新实现了signal函数）。 　　（ 4 ）消息（Message）队列：消息队列是消息的链接表，包括Posix消息队列system V消息队列。有足够权限的进程可以向队列中添加消息，被赋予读权限的进程则可以读走队列中的消息。消息队列克服了信号承载信息量少，管道只能承载无格式字节流以及缓冲区大小受限等缺 　　（ 5 ）共享内存：使得多个进程可以访问同一块内存空间

工作日志，go get -v -x github.com/pebbe/zmq4 失败问题 笔者 因为工作需要使用ZeroMQ，但是在执行 go get -v -x github.com/pebbe/zmq4 命令时一直提示 auth.go:19:17: fatal error: zmq.h: No such file or directory 的错误，这里记录踩坑 日志 。 ZeroMQ简介 ZeroMQ（也称为ØMQ，0MQ或ZMQ）是一种高性能的异步消息传递库，旨在用于分布式或并行应用程序中。它提供了一个消息队列，但是与常见的RabbitMQ，ActiveMQ消息中间件不同。ZeroMQ就像一个工具包直接嵌入到项目中，具有很高的吞吐量。但也存在很多局限性。 ZeroMQ 优点 一）、吞吐量远高与其他消息中间件，号称是“史上最快的消息队列”。 二）、扩展性强，可以对原生的方法进行封装，丰富其功能。 ZeroMQ缺点 一）、消息的不可靠性。ZeroMQ并不能保证可靠的消息传输，算的上致命缺点吧。 二）、原生不支持消息的持久化，仅支持本地缓存。当本地缓存塞满后，可能存在消息丢失的情况。 三）、没有很好的调试工具。代码虽然提示发送成功，但订阅方却收不到消息。 解决思路 第一步：下载Windows版的zeromq，官网下载地址：https://dl.bintray.com/zeromq

　　 其实Rocketmq的给第三方的插件已经全了，如果大家有兴趣的话请移步 https://github.com/apache/rocketmq-externals 。本文主要是结合笔者已有的rmq在spark中的应用经验对rocketmq做简单介绍以及经验总结，当然免不了会将rocketmq和如今特别火爆的kafka做一些对比（Ps：为了方便打字rmq后面会是rocketmq的缩写）。 　　 首先对rocktmq做一些流行的消息队列对比。 　　提到mq不得不提消息队列，对应于数据结构里面的“先进先出”的队列。而rocketmq就是应用于大数据时代拥有高吞吐低延迟特性的分布式消息拥有发布订阅功能的队列系统。这样的分布式消息系统主要提供应用解耦、流量消峰、消息分发等功能。本片不会对安装集群做过多的介绍，安装单机版本rmq的教程移步官方文档 http://rocketmq.apache.org/docs/quick-start/ 。 rocktmq是阿里研发主要作用于双十一这样的高峰期实时流数据处理，起初是基于activemq，但是随着对吞吐量的要求逐步提高，阿里的开发者们逐渐把眼光向kafka转移，但是kafka并不具备低延迟和高可靠性。因此阿里决定研究这样一个兼并传统的订阅消息系统的发布订阅场景与高并发零误差低延时的传输系统。 　　

什么是消息队列 消息队列（Message Queue，简称MQ），指保存消息的一个容器，本质是个队列。 消息（Message）是指在应用之间传送的数据，消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。 消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保信息的可靠专递，消息发布者只管把消息发布到MQ中而不管谁来取，消息使用者只管从MQ中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。 Producer：消息生产者，负责产生和发送消息到 Broker； Broker：消息处理中心。负责消息存储、确认、重试等，一般其中会包含多个 queue； Consumer：消息消费者，负责从 Broker 中获取消息，并进行相应处理； 现在常用的MQ组件有ActiveMQ、RabbitMQ、RocketMQ、ZeroMQ,当然近年来火热的Kafka,从某些场景来说，也是MQ，当然kafka的功能更加强大。 虽然不同的MQ都有自己的特点和优势，但是，不管是哪种MQ，都有MQ本身自带的一些特点，下面，咱们谈谈消息队列的的特点、优势、选型、以及应用场景。 为什么需要消息队列 在高并发分布式环境下，由于来不及同步处理，通过使用消息队列，可以异步处理请求，从而缓解系统的压力。 举一个订单系统的例子：用户点击下订单

什么是消息队列 消息队列（Message Queue，简称MQ），指保存消息的一个容器，本质是个队列。 消息（Message）是指在应用之间传送的数据，消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。 消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保信息的可靠专递，消息发布者只管把消息发布到MQ中而不管谁来取，消息使用者只管从MQ中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。 Producer：消息生产者，负责产生和发送消息到 Broker； Broker：消息处理中心。负责消息存储、确认、重试等，一般其中会包含多个 queue； Consumer：消息消费者，负责从 Broker 中获取消息，并进行相应处理； 现在常用的MQ组件有ActiveMQ、RabbitMQ、RocketMQ、ZeroMQ,当然近年来火热的Kafka,从某些场景来说，也是MQ，当然kafka的功能更加强大。 虽然不同的MQ都有自己的特点和优势，但是，不管是哪种MQ，都有MQ本身自带的一些特点，下面，咱们谈谈消息队列的的特点、优势、选型、以及应用场景。 为什么需要消息队列 在高并发分布式环境下，由于来不及同步处理，通过使用消息队列，可以异步处理请求，从而缓解系统的压力。 举一个订单系统的例子：用户点击下订单

目前主流的MQ产品 1.ZeroMQ 号称最快的消息队列系统，尤其针对大吞吐量的需求场景。 扩展性好，开发比较灵活，采用C语言实现，实际上只是一个socket库的重新封装，如果做为消息队列使用，需要开发大量的代码。ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。其中，Twitter的Storm中使用ZeroMQ作为数据流的传输。 2.RabbitMQ 结合erlang语言本身的并发优势，支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。 性能较好，但是不利于做二次开发和维护。 3.ActiveMQ 历史悠久的开源项目，是Apache下的一个子项目。已经在很多产品中得到应用，实现了JMS1.1规范，可以和spring-jms轻松融合，实现了多种协议，不够轻巧（源代码比RocketMQ多），支持持久化到数据库，对队列数较多的情况支持不好。 4.Redis 做为一个基于内存的K-V数据库，其提供了消息订阅的服务，可以当作MQ来使用，目前应用案例较少，且不方便扩展。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。 测试数据分为 128Bytes、512Bytes、1K和10K四个不同大小的数据。 实验表明：入队时