消息队列

最近项目需要进行实时读取服务端信息，在网上看到kafka可以解决这个问题，开发完成后对kafka做一个简单的整理，希望可以帮助到刚开始学习kafka 的同学，给自己也做个笔记： 首先说一下kafka是个什么东西： kafka是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等 Kafka的特性: - 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。 - 可扩展性：kafka集群支持热扩展 - 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失 - 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败） - 高并发：支持数千个客户端同时读写 Kafka的使用场景： - 日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。 - 消息系统

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

MQ 全称为 Message Queue，消息队列（MQ）是一种应用程序对应用程序的通信方法，即我们常说的中间件之一，而 RabbitMQ 则是 MQ 的一种开源实现，遵循 AMQP（高级消息队列协议） 协议。 AMQP 相关概念 MQ 的模型从大体上看，都是类似的，如下： 而 RabbitMQ 由于是基于 AMQP 协议的开源实现，AMQP 协议比 MQ 模型有更加详细的模型概念，如下： 生产者发送消息给交换器，交换绑定消息队列，消息队列通过信道传送给消费者。 信道 如果项目需要发布消息，那么必须要链接到 RabbitMQ，而项目于 RabbitMQ之间使用 TCP 连接，加入每次发布消息都要连接TCP，这不仅会造成连接资源严重浪费，会造成服务器性能瓶颈，所以 RabbitMQ 为所有的线程只用一条 TCP 连接，怎么实现的呢？RabbitMQ 引入了信道的概念，所有需要发布消息的线程都包装成一条信道在 TCP 中传输，理论上 一条 TCP 连接支持无限多个信道，模型如下： 队列 消息队列，用来保存消息直到发送给消费者。它是消息的容器，也是消息的终点。一个消息可投入一个或多个队列。消息一直在队列里面，等待消费者连接到这个队列将其取走。 绑定 绑定，用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则

Kafka Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。 1.前言 消息队列的性能好坏，其文件存储机制设计是衡量一个消息队列服务技术水平和最关键指标之一。下面将从Kafka文件存储机制和物理结构角度，分析Kafka是如何实现高效文件存储，及实际应用效果。 1.1 Kafka的特性: - 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。 - 可扩展性：kafka集群支持热扩展 - 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失 - 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败） - 高并发：支持数千个客户端同时读写 1.2 Kafka的使用场景： - 日志收集

一、什么是Kafka？ 　　 Apache Kafka是一个社区分布式事件流平台，能够每天处理数万亿个事件。 Kafka最初被设想为消息传递队列，它基于分布式提交日志的抽象。自2011年由LinkedIn创建并开源以来，Kafka已迅速从消息队列发展成为一个成熟的事件流平台。 用作 LinkedIn 的活动流（Activity Stream）和运营数据处理管道（Pipeline）的基础。 活动数据 包括网站的页面访问量、被查看内容方面的信息以及搜索情况等。这类数据通常的处理方式是把各种活动以日志的形式存入某种文件，并周期性的将这些文件进行统计分析。 运营数据 指的是服务器的性能数据（CPU、IO 使用率、请求时间、服务日志等等数据) 二、Kafka的专用术语 　　 Broker ： Kafka集群包含一个或多个服务器，这种服务器被称为 Broker。 　　 Topic ： 每条发布到服务器上的信息都会有一个类别，这个类别被称为 Topic 。同一 Topic 下的信息在物理上是分开存储的，在逻辑上是在一个 Topic 的消息虽然是保存到一个或多个 Broker 上的，但是用户只需指定消息的 Topic 即可生产或消费数据而不必关心数据存于何处。 　　 Partition ： 每个 Topic 包含一个或多个 Partition , Partition 是物理概念上的分区。 　　

消息发送者 导入依赖 < parent > < groupId > org . springframework . boot < / groupId > < artifactId > spring - boot - starter - parent < / artifactId > < version > 2.0 .1 . RELEASE < / version > < / parent > < dependencies > < dependency > < groupId > org . springframework . boot < / groupId > < artifactId > spring - boot - starter - amqp < / artifactId > < / dependency > < dependency > < groupId > org . springframework . boot < / groupId > < artifactId > spring - boot - starter - test < / artifactId > < / dependency > < / dependencies > 配置文件 spring : application : name : test‐rabbitmq‐producer rabbitmq

对软件命名并不是一件容易的事情，名字要朗朗上口，易于记忆，既不能天马行空，又要代表软件本身的功能和创新。本文将历数几款大数据框架及其创始背后的故事。 Hadoop：最具童心 2004年，Apache Hadoop（以下简称Hadoop）的创始人Doug Cutting和Mike Cafarella受MapReduce编程模型和Google File System等论文的启发，对论文中提及的思想进行了编程实现，Hadoop的名字来源于Doug Cutting儿子的玩具大象。当时Cutting的儿子刚刚两岁，正处在咿呀学语的阶段，经常将自己的黄色玩具大象叫做"Hadoop"，Cutting灵机一动，将自己的大数据项目以此来命名。 Cutting称，软件的名字有时候要听起来“毫无意义”，因为软件会随着时间不断迭代演进，一开始就使用一个与其初始功能紧密相关的名字，日后有可能比较尴尬。 由于Doug Cutting后来加入了雅虎，并在雅虎工作期间支持了大量Hadoop的研发工作，因此Hadoop也经常被认为是雅虎开源的一款大数据框架。时至今日，Hadoop不仅仅是整个大数据领域的先行者和领导者，更形成了一套围绕Hadoop的生态系统，Hadoop和它的生态是绝大多数企业首选的大数据解决方案。 目前，Hadoop的核心组件主要有三个： Hadoop MapReduce

什么是消息队列 MQ全称为Message Queue 消息队列（MQ）是一种应用程序对应用程序的通信方法。MQ是消费-生产者模型的一个典型的代表，一端往消息队列中不断写入消息，而另一端则可以读取队列中的消息。消息发布者只管把消息发布到 MQ 中而不用管谁来取，消息使用者只管从 MQ 中取消息而不管是谁发布的。这样发布者和使用者都不用知道对方的存在。 你可以想想在生活中的一种场景：当你把信件的投进邮筒，邮递员肯定最终会将信件送给收件人。我们可以把MQ比作 邮局和邮递员。 MQ和邮局的主要区别是,它不处理消息,但是,它会接受数据、存储消息数据、转发消息 为什么使用消息队列 其实就是问问你消息队列都有哪些使用场景，然后你项目里具体是什么场景，说说你在这个场景里用消息队列是什么？ 如果有人问你这个问题，期望的一个回答 是说，你们公司有个什么业务场景 ，这个业务场景有个什么技术挑战，如果不用 MQ 可能会很麻烦，但是你现在用了 MQ 之后带给了你很多的好处。 先说一下消息队列常见的使用场景吧，其实场景有很多，但是比较核心的有 3 个： 解耦 、 异步 、 削峰 。 解耦 看这么个场景。A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃...... 在这个场景中，A 系统跟其它各种乱七八糟的系统严重耦合

消息驱动： 事件驱动架构（Event Driven Architecture）EDA 消息驱动架构（Message Driven Architecture）MDA 我们日常生活就是消息驱动的 springCloud stream使得构建基于消息传递的解决方案变得轻而易举，springCloud stream的目的是隔离具体的消息中间件，而使得各种消息中间件可以保持统一的编码 用许可证服务和组织服务举例： 许可证服务会调用组织服务的接口，为了加快程序响应速度，我们需要在许可证服务缓存组织服务的一部分数据，但是也需要在组织服务的这部分数据发生改变的时候，及时同步新的数据 使用消息驱动，意味着许可证服务和组织服务之间加入了一个消息队列，当组织服务的数据发生改变的时候，会向消息对垒发布一个消息，许可证服务监听队列中由组织服务发布的所有消息，并且根据需要使本地缓存数据失效 消息队列充当中介： 这种使用消息队列充当许可证服务和组织服务之间中介的方法有以下好处： 松耦合，两个服务都不知道彼此 耐久性，即使服务的消费者已经关闭，也可以发送消息 可伸缩性，可以启动更多的消息消费者来处理队列中的嘻嘻 灵活性，消息的发送者不知道谁将消费它，这意味着可以轻松添加新的消费者 缺点是： 消息处理语义，如果要求消息按照时间顺序消费怎么处理，如果消息结构发生变化怎么处理，如果消息处理失败怎么办 消息可见性

作者 | 元毅 阿里云智能事业群高级开发工程师 导读： 当前在 Knative 中已经提供了对 Kafka 事件源的支持，那么如何基于 Kafka 实现消息推送呢？本文作者将以阿里云 Kafka 产品为例，给大家解锁这一新的姿势。 背景 消息队列 for Apache Kafka 是阿里云提供的分布式、高吞吐、可扩展的消息队列服务。消息队列 for Apache Kafka 广泛用于日志收集、监控数据聚合、流式数据处理、在线和离线分析等大数据领域，已成为大数据生态中不可或缺的部分。 结合 Knative 中提供了 KafkaSource 事件源的支持， 可以方便的对接 Kafka 消息服务。 另外也可以安装社区 Kafka 2.0.0 及以上版本使用。 在阿里云上创建 Kafka 实例 创建 Kafka 实例 登录 消息队列 Kafka 控制台 , 选择【购买实例】。由于当前 Knative 中 Kafka 事件源支持 2.0.0 及以上版本，在阿里云上创建 Kafka 实例需要选择包年包月、专业版本进行购买，购买之后升级到 2.0.0 即可。 部署实例并绑定 VPC 购买完成之后，进行部署，部署时设置 Knative 集群所在的 VPC 即可： 创建 Topic 和 Consumer Group 接下来我们创建 Topic 和消费组。 进入【Topic 管理】，点击 创建