消息队列

基本用法 topic_name = 'my_topic_name' consumer = KafkaConsumer(topic_name, bootstrap_servers=['172.16.89.80:9092']) # consumer是一个消息队列，当后台有消息时，这个消息队列就会自动增加．所以遍历也总是会有数据，当消息队列中没有数据时，就会堵塞等待消息到来 for msg in consumer: recv = "%s:%d:%d: key=%s value=%s" % (msg.topic, msg.partition, msg.offset, msg.key, msg.value) print recv 指定分区、offset、消费组 #encoding:utf8 from kafka import KafkaConsumer, TopicPartition my_topic = "my_topic_name" # 指定需要消费的主题 consumer = KafkaConsumer( bootstrap_servers = "192.168.70.221:19092,192.168.70.222:19092,192.168.70.223:19092", # kafka集群地址 group_id = "my_group_a", # 消费组id enable_auto

RabbitMQ的安装 注意：需要匹配elang 和rabbitmq-server的版本，版本不对会有问题 # Erlang安装 sudo apt install erlang erlang - nox # 安装rabbitmq服务器 sudo apt install rabbitmq - server # 启动、停止、重启rabbitmq服务 service rabbitmq - server start / stop / restart # 创建普通用户 sudo rabbitmqctl add_user your_username your_password # 设置用户为管理员 sudo rabbitmqctl set_user_tags your_username administrator # 用户添加管理权限 rabbitmqctl set_permissions - p / python ".*" ".*" ".*" # 查看状态 sudo rabbitmqctl status # 查看队列 sudo rabbitmqctl list_queues 消息确认机制 处理完消息后会有一个回执，避免中途挂掉 消息调度 循环调度，你一个任务我一个任务，没做完就等着(默认) auto_ack=True ch.basic_ack(delivery_tag=method

为什么需要消息队列 　　周末无聊刷着手机，某宝网APP突然蹦出来一条消息“为了回馈老客户，女朋友买一送一，活动仅限今天！”。买一送一还有这种好事，那我可不能错过！忍不住立马点了去。于是选了两个最新款，下单、支付一气呵成！满足的躺在床上，想着马上有女朋友了，竟然幸福的失眠了…… 　　第二天正常上着班，突然接到快递小哥的电话： 　　小哥：“你是xx吗？你的女朋友到了，我现在在你楼下，你来拿一下吧！”。 　　我：“这……我在上班呢，可以晚上送过来吗？“。 　　小哥：“晚上可不行哦，晚上我也下班了呢！”。 　　于是两个人僵持了很久…… 　　最后小哥说，要不我帮你放到楼下小芳便利店吧，你晚上下班了过来拿，尴尬的局面这才得以缓解！ 　　回到正题，如果没有小芳便利店，那快递小哥和我的交互图就应该如下： 　　 　　 　　会出现什么情况呢？ 　　1、为了这个女朋友，我请假回去拿（老板不批）。 　　2、小哥一直在你楼下等（小哥还有其他的快递要送）。 　　3、周末再送（显然等不及）。 　　4、这个女朋友我不要了（绝对不可能）！ 　　小芳便利店出现后，交互图就应如下： 　　 　　 　　在上面例子中，“快递小哥”和“买女朋友的我”就是需要交互的两个系统，小芳便利店就是我们本文要讲的-“消息中间件”。总结下来小芳便利店（消息中间件）出现后有如下好处： 　　 1、 解耦 　　快递小哥手上有很多快递需要送

Kafka概述 1、什么是Kafka 在流式计算中，Kafka一般用来缓存数据，Storm通过消费Kafka的数据进行计算。 1）Apache Kafka是一个开源消息系统，由Scala写成。是由Apache软件基金会开发的一个开源消息系统项目。 2）Kafka最初是由LinkedIn公司开发，并于2011年初开源。2012年10月从Apache Incubator毕业。该项目的目标是为处理实时数据提供一个统一、高通量、低等待的平台。 3）Kafka是一个分布式消息队列。Kafka对消息保存时根据Topic进行归类，发送消息者称为Producer，消息接受者称为Consumer，此外kafka集群有多个kafka实例组成，每个实例(server)称为broker。 4）无论是kafka集群，还是consumer都依赖于zookeeper集群保存一些meta信息，来保证系统可用性。 2、为什么需要消息队列 1）解耦： 　　允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 2）冗余： 消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。 3）扩展性：

1、交换机属性 交换机有以下属性： Name ：交换机名称 Type ：交换机类型 direct、topic、fanout、headers Durability ：是否需要持久化，true为持久化 Auto Delete ：当最后一个绑定到Exchange上的队列删除后，自动删除该Exchange Internal ：当前Exchange是否用于RabbitMQ内部使用，默认为False Arguments ：扩展参数，用于扩展AMQP协议，定制化使用 2、直连交换机Direct Exchange（完全匹配路由key） 所有发送到Direct Exchange的消息会被转发到RouteKey中指定的Queue 注意：Direct模式可以使用RabbitMQ自带的Exchange：default Exchange，所以不需要将Exchange进行任何绑定（binding）操作，消息传递时，RouteKey必须完全匹配才会被队列接收，否则该消息会被抛弃； 消费端代码： package com.ue.exchange.direct; import com.rabbitmq.client.Channel; import com.rabbitmq.client.Connection; import com.rabbitmq.client.ConnectionFactory; import

　　　今天开会讨论日志处理为什么要同时使用Flume和Kafka，是否可以只用Kafka 不使用Flume？当时想到的就只用Flume的接口多，不管是输入接口(socket 和 文件)以及输出接口(Kafka/HDFS/HBase等)。 　　　考虑单一应用场景，从简化系统的角度考虑，在满足应用需求的情况下可能只使用一个比较好。但是考虑到现有系统业务发展，为了后面的灵活扩展，在系统设计时留有一定的扩展性感觉更重要。可能使用Flume+kafka架构相对只使用Kafka会多占用1-2台机器做Flume日志采集，但是为了方便以后日志数据处理方式的扩展，可以采用Flume+kafka架构。 　　Flume ：管道 ----个人认为比较适合有多个生产者场景，或者有写入Hbase、HDFS和kafka需求的场景。 　　Kafka ：消息队列-----由于Kafka是Pull模式，因此适合有多个消费者的场景。 　　目前应用场景，一台日志转发机负责产生日志。后端需要通过Strom消费日志信息，建议可以设置成log-->Kafka->Strom.如果以后有写入Hbase或者HDFS的需求可以，在Kafka后面再接上Strom，或者在日志转发机上直接日志落地，由Flume去读取日志消息。 参考： Kafka与Flume区别 Kafka与Flume对比 基于Flume的美团日志收集系统 Using

​ 个人理解在项目中使用消息队列一般是有如下几个原因： 把瞬间服务器的请求处理换成异步处理，缓解服务器的压力 实现数据顺序排列获取 ​redis实现消息队列步骤如下： 1）.redis函数rpush,lpop 2）.建议定时任务入队列 3）创建定时任务出队列 文件：demo.php插入数据到redis队列 <?php $redis = new Redis(); $redis->connect('127.0.0.1',6379); $password = '123456'; $redis->auth($password); $arr = array('h','e','l','l','o','w','o','r','l','d'); foreach($arr as $k=>$v){ $redis->rpush("mylist",$v); } 　　 执行后结果如下 ?> 文件：index.php定时扫描出队列 <?php $redis = new Redis(); $redis->connect('127.0.0.1',6379); $password = '123456'; $redis->auth($password); //list类型出队操作 $value = $redis->lpop('mylist'); if($value){ echo "出队的值".$value;

前言 　　RabbitMQ是基于AMQP协议(Advanced Message Queue Protocol)的消息中间件。 　　 什么是消息队列 　　消息队列属于进程间通信的一种方式，使用消息队列可以通过异步方式处理数据，借此可以提高系统性能。我们可以把消息当作存放数据的容器，消息的消费者可以从队列中获取数据，进行处理。常见的消息队列有：ActiveMQ，RabbitMQ，Kafka，RocketMQ等。 　　 RabbitMQ中用到基本概念 　　Broker：消息队列的服务器实体。 　　Exchange：消息交换机，它指定消息按什么规则，路由到哪个队列。 　　Queue：消息队列载体，每个消息都会被投入到一个或多个队列。 　　Binding：绑定，它主要是把exchange和queue按照路由规则绑定起来。 　　Routing Key：路由关键字，exchange根据这个关键字进行消息投递。 　　vhost：虚拟主机，一个broker里可以开设多个vhost，用作不同用户的权限分离。 　　producer：消息生产者，投递消息的程序。 　　consumer：消息消费者，接收消息的程序。 　　channel：消息通道，在客户端的每个连接里，可以建立多个channel，每个channel代表一个会话任务。 　　 RabbitMQ中消息模式 　　 1、简单队列 　

RabbitMQ实现集群高可用 前言 为什么搭建rabbitmq集群？ rabbitmq集群有那些模式？ 如何搭建Rabbitmq集群？ rabbitmq镜像高可用策略有那些？ RabbitMQ这款产品本身的优点众多，大家最看好的便是他的异步化提高系统抗峰值能力，然后便是系统及功能结构解耦，既然它如此重要，那么我们就需要考虑它的高可用性。 rabbitmq有3种模式 ： 单一模式：即单机情况不做集群，就单独运行一个rabbitmq而已，生产上肯定不能用。 普通模式：普通集群就是在多台机器上启动多个实例。每个队列只会存在其中的一个实例上，然后所有实例同步这些队列的元数据。消费者在进行消费的时候，如果连接的实例上恰好不是队列所在的实例，就会根据队列的元数据去队列所在实例上拉取数据 由此可知，集群模式并没做到分布式，如果队列所在的实例宕机了，会导致接下来其他实例就无法从那个实例拉取消息，所以集群主要是提高吞吐量的 镜像模式:把需要的队列做成镜像队列，存在与多个节点属于** RabbitMQ的HA方案 。**该模式解决了普通模式中的问题，其实质和普通模式不同之处在于，消息实体会主动在镜像节点间同步，而不是在客户端取数据时临时拉取。该模式带来的副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉

一、MQ产品的分类 1、RabbitMQ 　　是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了一个经纪人(Broker)构架，这意味着消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。 2、Redis 　　是一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。 入队 出队 128B 512B 1K 10K 128B 512B 1K 10K Redis 16088 15961 17094 25 15955 20449 18098 9355 RabbitMQ 10627