消息队列

延迟队列的需求各位应该在日常开发的场景中经常碰到。比如： 用户登录之后5分钟给用户做分类推送； 用户多少天未登录给用户做召回推送； 定期检查用户当前退款账单是否被商家处理等等场景。 一般这种场景和定时任务还是有很大的区别，定时任务是你知道任务多久该跑一次或者什么时候只跑一次，这个时间是确定的。延迟队列是当某个事件发生的时候需要延迟多久触发配套事件，引子事件发生的时间不是固定的。 业界目前也有很多实现方案，单机版的方案就不说了，现在也没有哪个公司还是单机版的服务，今天我们一一探讨各种方案的大致实现。 1. Redis zset 老幺网 m.laoyao.org 这个方案比较常用，简单有效。利用 Redis 的 sorted set 结构，使用 timeStamp 作为 score，比如你的任务是要延迟5分钟，那么就在当前时间上加5分钟作为 score ，轮询任务每秒只轮询 score 大于当前时间的 key即可，如果任务支持有误差，那么当没有扫描到有效数据的时候可以休眠对应时间再继续轮询。 方案优劣 ： 优点： 简单实用，一针见血。 缺点： 单个 zset 肯定支持不了太大的数据量，如果你有几百万的延迟任务需求，大哥我还是劝你换一个方案； 定时器轮询方案可能会有异常终止的情况需要自己处理，同时消息处理失败的回滚方案，您也要自己处理。 所以，sorted set

Apache Kafka 概述 在大数据中，使用了大量的数据。 关于数据，我们有两个主要挑战。第一个挑战是如何收集大量的数据，第二个挑战是分析收集的数据。 为了克服这些挑战，您必须需要一个消息系统。 Kafka专为分布式高吞吐量系统而设计。 Kafka往往工作得很好，作为一个更传统的消息代理的替代品。 与其他消息传递系统相比，Kafka具有更好的吞吐量，内置分区，复制和固有的容错能力，这使得它非常适合大规模消息处理应用程序。 什么是消息系统？ 消息系统负责将数据从一个应用程序传输到另一个应用程序，因此应用程序可以专注于数据，但不担心如何共享它。 分布式消息传递基于可靠消息队列的概念。 消息在客户端应用程序和消息传递系统之间异步排队。 有两种类型的消息模式可用 - 一种是点对点，另一种是发布 - 订阅(pub-sub)消息系统。 大多数消息模式遵循 pub-sub kafka官网： http://kafka.apache.org/ 使用安装包版本： kafka_2.11-1.0.0 下载地址 https://mvnrepository.com/artifact/org.apache.kafka/kafka_2.11/1.0.0 已经安装 hadoop-2.6.0.tar ，zookeeper-3.4.5.tar 虚拟机 IP master 192.168.176.41 slave1

Spring实战4介绍了AMQP消息高级协议。进而提到了AMQP协议的实现——RabbitMQ。 RabbitMQ作为一个消息代理中间件。非常的流行，exchange的使用，让消息生产者和消息队列实现了解耦。提供了多种消息路由的方式。 本文不谈原理，只谈集成 1 .引入依赖 2 .RabbitMQ配置文件 3 .占位符配置 4 .使用RabbitMQ 1 .引入依赖 <dependency> <groupId>org.springframework.amqp</groupId> <artifactId>spring-rabbit</artifactId> <version>1.5.0.RELEASE</version> </dependency> 2 .RabbitMQ配置文件 <?xml version="1.0" encoding="UTF-8"?> <beans:beans xmlns="http://www.springframework.org/schema/rabbit" xmlns:beans="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www

前言 本文将系统的介绍一下RabbitMQ集群架构的特点、异常处理、搭建和使用中要注意的一些细节。 知识点 一、为什么使用集群？ 二、集群的特点 三、集群异常处理 四、集群节点类型 五、集群搭建方法 六、镜像队列 一、为什么使用集群？ 内建集群作为RabbitMQ最优秀的功能之一，它的作用有两个： 允许消费者和生产者在Rabbit节点崩溃的情况下继续运行； 通过增加节点来扩展Rabbit处理更多的消息，承载更多的业务量； 二、集群的特点 RabbitMQ的集群是由多个节点组成的，但我们发现不是每个节点都有所有队列的完全拷贝。 RabbitMQ节点不完全拷贝特性 为什么默认情况下RabbitMQ不将所有队列内容和状态复制到所有节点？ 有两个原因： 存储空间——如果每个节点都拥有所有队列的完全拷贝，这样新增节点不但没有新增存储空间，反而增加了更多的冗余数据。 性能——如果消息的发布需安全拷贝到每一个集群节点，那么新增节点对网络和磁盘负载都会有增加，这样违背了建立集群的初衷，新增节点并没有提升处理消息的能力，最多是保持和单节点相同的性能甚至是更糟。 所以其他非所有者节点只知道队列的元数据，和指向该队列节点的指针。 三、集群异常处理 根据节点不无安全拷贝的特性，当集群节点崩溃时，该节点队列和关联的绑定就都丢失了，附加在该队列的消费者丢失了其订阅的信息，那么怎么处理这个问题呢？

本文转发自 技术世界 ， 原文链接 　 http://www.jasongj.com/2015/01/02/Kafka深度解析 背景介绍 Kafka简介 　　Kafka是一种分布式的，基于发布/订阅的消息系统。主要设计目标如下： 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输 同时支持离线数据处理和实时数据处理 为什么要用消息系统 解耦 在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息队列在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束 冗余 有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。在被许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理过程明确的指出该消息已经被处理完毕，确保你的数据被安全的保存直到你使用完毕。 扩展性 因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的

目录 简介Kafka架构Kafka存储策略Kafka删除策略Kafka brokerKafka DesignThe ProducerThe Consumer复制（Replication）日志压缩（Log Compaction）DistributionZookeeper协调控制开发环境搭建一些example参考 简介 Apache Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发，之后成为Apache项目的一部分。Kafka是一种快速、可扩展的、设计内在就是分布式的，分区的和可复制的提交日志服务。 Kafka架构 它的架构包括以下组件： 话题（Topic）：是特定类型的消息流。消息是字节的有效负载（Payload），话题是消息的分类名或种子（Feed）名。 生产者（Producer）：是能够发布消息到话题的任何对象。 服务代理（Broker）：已发布的消息保存在一组服务器中，它们被称为代理（Broker）或Kafka集群。 消费者（Consumer）：可以订阅一个或多个话题，并从Broker拉数据，从而消费这些已发布的消息。 https://images2015.cnblogs.com/blog/434101/201605/434101-20160514145613421-1488903046.png Kafka存储策略 1）kafka以topic来进行消息管理

目录 简介 Kafka架构 Kafka存储策略 Kafka删除策略 Kafka broker Kafka Design The Producer The Consumer 复制（Replication） 日志压缩（Log Compaction） Distribution Zookeeper协调控制 开发环境搭建 一些example 参考 简介 Apache Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发，之后成为Apache项目的一部分。Kafka是一种快速、可扩展的、设计内在就是分布式的，分区的和可复制的提交日志服务。 Kafka架构 它的架构包括以下组件： 话题（Topic）：是特定类型的消息流。消息是字节的有效负载（Payload），话题是消息的分类名或种子（Feed）名。 生产者（Producer）：是能够发布消息到话题的任何对象。 服务代理（Broker）：已发布的消息保存在一组服务器中，它们被称为代理（Broker）或Kafka集群。 消费者（Consumer）：可以订阅一个或多个话题，并从Broker拉数据，从而消费这些已发布的消息。 https://images2015.cnblogs.com/blog/434101/201605/434101-20160514145613421-1488903046.png Kafka存储策略 1

/*--> */ /*--> */ 消息服务 背景 ： 有时需与其它系统集成来完成相关业务功能 ，原始的做法是程序内部相互调用，除此之外，还可 用消息服务中间件来进行业务处理 ，使 用消息服务中间件处理业务能够提升系统的异步通信和扩展解耦的能力，个人有点面向切面的意思 。 一 . 为什么要使用消息服务 ？ 因为 它有很多好处，能解决很多问题； 1. 异步处理 2.流量消峰 3.提高效率和可靠性 二、RabbitMQ 消息中间件的原理和工作模式 RabbitMQ 消息中间件的原理： 1. 消息发布者 P 向 RabbitMQ 代理（ Broker ）指定虚拟主机服务器发送消息。 2. 虚拟主机服务器内部交换器接收消息，并将消息传递并存储到与之邦定的消息队列中。 3. 消息消费者通过网络连接与消息代理建立连接。并且为了简化开发，在连接内部使用了多路复用的信道进行消息的最终消费。 消息中间件的工作模式的分类、具体的实现步骤、适用场景 工作模式：Publish/Subscrib （发布订阅模式） step1. 先配置一个 fanout 类型的交换器。 step2. 不需指定对应的路由键，同时会将消息路由到每一个消息队列。 step3. 每个队列都可以对不同的消息进行接收存储，进而各自消息队列关联的消费者进行消费。 适用场景：相同业务功能处理的场合。如用户注册成功后

添加链接描述@ TOC 一、Kafka简介 1.1 什么是kafka kafka是一个分布式、高吞吐量、高扩展性的消息队列系统。kafka最初是由Linkedin公司开发的，后来在2010年贡献给了Apache基金会，成为了一个开源项目。主要应用在日志收集系统和消息系统，相信大家之前也听说过其他的消息队列中间件，比如RabbitMQ、AcitveMQ，其实kafka就是这么一个东西，也可以叫做KafkaMQ。总之，Kafka比其他消息队列要好一点，优点也比较多，稳定性和效率都比较高，大家都说好，那就是真的好。 1.2 Kafka中的相关概念 在理解Kafka的相关概念之前，我们先来看一张图，这张图基本上包括了Kafka所有的概念，对于我们理解Kafka十分有帮助。 上图中包含了2个Producer（生产者），一个Topic（主题），3个Partition（分区），3个Replica（副本），3个Broker（Kafka实例或节点），一个Consumer Group（消费者组），其中包含3个Consumer（消费者）。下面我们逐一介绍这些概念。 1.2.1 Producer（生产者） 生产者，顾名思义，就是生产东西的，也就是发送消息的，生产者每发送一个条消息必须有一个Topic（主题），也可以说是消息的类别，生产者源源不断的向kafka服务器发送消息。 1.2.2 Topic（主题）

在kafka的config目录下有3个文件:server.properties/consumer.properties/producer.properties 1.server.properties:服务端的配置文件 #broker的全局唯一编号，不能重复 broker.id=0 #用来监听链接的端口，producer或consumer将在此端口建立连接 port=9092 #处理网络请求的线程数量，也就是接收消息的线程数。 #接收线程会将接收到的消息放到内存中，然后再从内存中写入磁盘。 num.network.threads=3 #消息从内存中写入磁盘是时候使用的线程数量。 #用来处理磁盘IO的线程数量 num.io.threads=8 #发送套接字的缓冲区大小 socket.send.buffer.bytes=102400 #接受套接字的缓冲区大小 socket.receive.buffer.bytes=102400 #请求套接字的缓冲区大小 socket.request.max.bytes=104857600 #kafka运行日志存放的路径 log.dirs=/export/servers/logs/kafka #topic在当前broker上的分片个数 num.partitions=2 #我们知道segment文件默认会被保留7天的时间，超时的话就 #会被清理