消息队列

9.1 spring cloud stream 简介 spring cloud stream 是一个用来为微服务应用提供消息驱动能力的框架. 它可以基于 springboot 来单独的创建独立的,可用于生产的 spring 的应用程序. 它通过使用 spring integration 来连接消息代理中间件以实现消息事件驱动. 它为一些一些供应商的消息中间件产品提供了个性化的自动化配置,并且引入了发布-订阅,消费组以及分区这三个核心概念. 快速入门 下面我们通过构建一个简单的示例来对Spring Cloud Stream有一个初步认识。该示例主要目标是构建一个基于Spring Boot的微服务应用，这个微服务应用将通过使用消息中间件RabbitMQ来接收消息并将消息打印到日志中。所以，在进行下面步骤之前请先确认已经在本地安装了RabbitMQ 构建一个Spring Cloud Stream消费者 创建一个基础的Spring Boot工程，命名为：stream-hello 编辑 build.gradle 中的依赖关系，引入Spring Cloud Stream对RabbitMQ的支持，具体如下： dependencies { implementation 'org.springframework.boot:spring-boot-starter-web' implementation

1.消息中间件\消息系统 将数据从一个系统传递给另一个系统 如果只是单纯的传递数据的方法，有很多，http，rpc，webservice，定时任务 如果接收方，一下子接收不过来那么多数据怎么办？ 2.消息系统的分类：点对点，发布-订阅 点对点：主要采用队列的方式，如A->B， 当B消费掉队列中的数据，队列中的数据就会被删除，如果B一直不消费，队列中就会有很多脏数据。 发布-订阅：必须要有主题的概念，主题：一个消息分类 发布者：一般情况下是将消息以推的方式，发送给消息系统。 订阅者：可以采用拉和推的方式从消息系统中拿数据 3.kafka的说明：开发语言是scala，kakafka_2.11-2.2.0 其中，2.11是scala的版本，2.2.0是kafka的版本 4.kafka的架构： broker服务：一般情况下一台主机就一个broker服务，也可以一台主机中有多个broker服务，只要端口不一样，存储路径不一样可以，但是不推荐。 zookeepr服务：管理broker集群，管理元数据。 producer：生产者，发布消息的，这个消息，需要指定主题。 consumer：消费者，当多个消费者订阅同一个主题，那这个主题的同一条消息，会被重复消费。 consumer group：消费组，在同一个消费组中的消费者，对同一条消息，只能消费一次。 offset：某一个消费组

作者：陈肃 整理：周奇，Apache Flink 社区志愿者 本文根据陈肃老师在 Apache Kafka x Flink Meetup 深圳站的分享整理而成，文章首先将从数据融合角度，谈一下 DataPipeline 对批流一体架构的看法，以及如何设计和使用一个基础框架。其次，数据的一致性是进行数据融合时最基础的问题。如果数据无法实现一致，即使同步再快，支持的功能再丰富，都没有意义。 另外，DataPipeline 目前使用的基础框架为 Kafka Connect。为实现一致性的语义保证，我们做了一些额外工作，希望对大家有一定的参考意义。 最后，会提一些我们在应用 Kafka Connect 框架时，遇到的一些现实的工程问题，以及应对方法。尽管大家的场景、环境和数据量级不同，但也有可能会遇到这些问题。希望对大家的工作有所帮助。 一、批流一体架构 批和流是数据融合的两种应用形态 下图来自 Flink 官网。传统的数据融合通常基于批模式。在批的模式下，我们会通过一些周期性运行的 ETL JOB，将数据从关系型数据库、文件存储向下游的目标数据库进行同步，中间可能有各种类型的转换。 另一种是 Data Pipeline 模式。与批模式相比相比， 其最核心的区别是将批量变为实时：输入的数据不再是周期性的去获取，而是源源不断的来自于数据库的日志、消息队列的消息。进而通过一个实时计算引擎

介绍 RabbitMQ 前，有必须先了解一下 AMQP 协议。 AMQP 协议是一个高级抽象层消息通信协议， RabbitMQ 是 AMQP 协议的实现。它主要包括以下组件： 1. Server(broker): 接受客户端连接，实现 AMQP 消息队列和路由功能的进程。 2. Virtual Host:其实是一个虚拟概念，类似于权限控制组，一个Virtual Host里面可以有若干个Exchange和Queue，但是权限控制的最小粒度是Virtual Host 3.Exchange:接受生产者发送的消息，并根据Binding规则将消息路由给服务器中的队列。ExchangeType决定了Exchange路由消息的行为，例如，在RabbitMQ中，ExchangeType有direct、Fanout和Topic三种，不同类型的Exchange路由的行为是不一样的。 4. Message Queue ：消息队列，用于存储还未被消费者消费的消息。 5.Message: 由Header和Body组成，Header是由生产者添加的各种属性的集合，包括Message是否被持久化、由哪个Message Queue接受、优先级是多少等。而Body是真正需要传输的APP数据。 6. Binding:Binding 联系了 Exchange 与 Message Queue 。 Exchange

在kafka/config/目录下面有3个配置文件： producer.properties consumer.properties server.properties (1).producer.properties:生产端的配置文件 #指定kafka节点列表，用于获取metadata，不必全部指定 #需要kafka的服务器地址，来获取每一个topic的分片数等元数据信息。 metadata.broker.list=kafka01:9092,kafka02:9092,kafka03:9092 #生产者生产的消息被发送到哪个block，需要一个分组策略。 #指定分区处理类。默认kafka.producer.DefaultPartitioner，表通过key哈希到对应分区 #partitioner.class=kafka.producer.DefaultPartitioner #生产者生产的消息可以通过一定的压缩策略（或者说压缩算法）来压缩。消息被压缩后发送到broker集群， #而broker集群是不会进行解压缩的，broker集群只会把消息发送到消费者集群，然后由消费者来解压缩。 #是否压缩，默认0表示不压缩，1表示用gzip压缩，2表示用snappy压缩。 #压缩后消息中会有头来指明消息压缩类型，故在消费者端消息解压是透明的无需指定。

拉模式： 点对点消费，如果没有消费者在监听队列，消息将保留在队列中，直至消费者连接到队列，在这种模型中，消息不是自动推动给消费者的，而是要由消费者从队列中请求活动（拉模式）。 优点： 1.保证每条消息都被接收。 2.消息不会丢失。 推模式 消息会自动广播，消息消费者无需主动请求或轮询主题的方法来获得新消息。 对比： 1.不保证每条消息都会被消费， 2.发布消息时，只有正在监听该topic的能够接收，如果没人监听，则会消息丢失。 MetaQ Client 订阅消息，因其是Pull的模型。MetaQ Server收到Pull消息的请求，会从磁盘上读取出消息，然后返回给MetaQ Client。这一步有大量的read系统调用。 消息中间件MetaQ高性能原因分析-转自阿里中间件 https://www.cnblogs.com/felixzh/p/6197707.html 来源： oschina 链接： https://my.oschina.net/u/3421984/blog/1633582

https://my.oschina.net/itshare/blog/775466 http://blog.51cto.com/467754239/1700828 日志系统 日志就是程序产生的，遵循一定格式（通常包含时间戳）的文本数据 通常日志由服务器生成，输出到不同的文件中，一般会有系统日志、 应用日志、安全日志。这些日志分散地存储在不同的机器上。 通常当系统发生故障时，工程师需要登录到各个服务器上，使用 grep / sed / awk 等 Linux 脚本工具去日志里查找故障原因。在没有日志系统的情况下，首先需要定位处理请求的服务器，如果这台服务器部署了多个实例，则需要去每个应用实例的日志目录下去找日志文件。每个应用实例还会设置日志滚动策略（如：每天生成一个文件），还有日志压缩归档策略等。 这样一系列流程下来，对于我们排查故障以及及时找到故障原因，造成了比较大的麻烦。因此，如果我们能把这些日志集中管理，并提供集中检索功能，不仅可以提高诊断的效率，同时对系统情况有个全面的理解，避免事后救火的被动。 日志数据在以下几方面具有非常重要的作用： 数据查找：通过检索日志信息，定位相应的 bug ，找出解决方案 服务诊断：通过对日志信息进行统计、分析，了解服务器的负荷和服务运行状态 数据分析：可以做进一步的数据分析，比如根据请求中的课程 id ，找出 TOP10 用户感兴趣课程。

博文大纲： 一、Kafka概述 1）消息队列 2）为什么要使用消息队列？ 3）什么是Kafka？ 4）Kafka的特性 5）Kafka架构 6）Topic和Partition的区别 7）kafka流程图 8）Kafka的文件存储机制 9）数据的可靠性和持久性保证 10）leader选举 二、部署单机Kafka 1）部署Kafka 2）测试Kafka 三、部署Kafka群集 1）环境准备 2）部署zookeeper群集 3）部署Kafka群集 一、Kafka概述 1）消息队列 1）点对点模式 （一对一，消费者主动拉取数据，消息收到后消息清除） 点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此； 2）发布/订阅模式 （一对多，数据生产后，推送给所有订阅者） 发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即使当前订阅者不可用，处于离线状态。 2）为什么要使用消息队列？ 1）解耦 允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 2）冗余 消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险

（一）概述 rabbitmq在使用过程中会遇到一个问题：生产者将消息发送出去后，消息有没有达到rabbitmq，默认是不知道的。 有两种解决方式：1.AMQP实现事务机制；2.Confirm模式 （二）事务机制 事务机制通过三段代码控制事务的执行： 1 channel.txSelect(); 将当前channel设置成transaction 2 channel.txCommit(); 提交事务 3 channel.txRollback(); 事务回滚 如果生产者因为一些错误没有将事务发送出去，那就会触发事务回滚机制，以达到消息确认的目的。 通过简单队列实现事务机制： 生产者 public class Sent { private static final String QUEUE_NAME="tx_queue"; public static void main(String[] args) throws IOException, TimeoutException { Connection connection = ConnectionUtil.getConnection(); Channel channel = connection.createChannel(); channel.queueDeclare(QUEUE_NAME,false,false,false,null);

为了实现分布式系统可扩展、可伸缩性的关键组件，需要具有高吞吐量、高可用等特点。我们很多时候都会考虑将消息系统纳入我们的选择中；比如我一个登录事件，有可能我登录之后需要做很多东西，比如日志，比如发布消息，比如推送，再比如发送代金券等等；这些事件与登录息息相关，但是本质上它们与登录这个事件没有直接的关系，只是在登录事件后，系统按照需求需要去初始化一些东西，或者去记录一些东西等等；如果把所有的东西都纳入到登录这个事件中（同一个事物中），那登录的事件内处理的逻辑更多，会造成什么后果？登录时间很长，让用户无法忍受，另外，假如登录过程中出现了未发现异常，那是不是导致用户直接无法登录？为了解决这样的问题，我们引入了消息系统，比如我这台机登录过后，我将登录的一些信息，通过远程方式发送到另外一台机器上（或者同一台机），让它们去处理相应的后续逻辑实现； 目的是：1、用户登录更快，体验上更好， 2、只要保证登录部分完整，即便后续出错，并不影响用户正常使用，即容错性更强！ 谈到消息系统，首先想到的第一个问题肯定会是： 消息的顺序性 本来很想说一下关于消息顺序性的一些问题，不过由于我也是借鉴了一些其他的帖子，以及官方的文档，所以这里就不会去赘述这些了，稍后我会分享一些很不错的链接，留给自己以后看，也希望可以给一些刚好要入门rocketmq的网友提供一些资料； rocketmq是阿里云的一套开源产品