topic

首先请确保你的rabbitmq服务已经打开，或者百度搜索安装 Exchange 类型 Exchange分发消息时根据类型的不同分发策略有区别，目前共四种类型：direct、fanout、topic、headers 。只说前三种模式。 1.Direct模式 消息中的路由键（routing key）如果和 Binding 中的 binding key 一致， 交换器就将消息发到对应的队列中。路由键与队列名完全匹配 2.Topic模式 topic 交换器通过模式匹配分配消息的路由键属性，将路由键和某个模式进行匹配，此时队列需要绑定到一个模式上。它将路由键和绑定键的字符串切分成单词，这些单词之间用点隔开。它同样也会识别两个通配符：符号“#”和符号“*”。#匹配0个或多个单词，*匹配一个单词。 3.Fanout模式 每个发到 fanout 类型交换器的消息都会分到所有绑定的队列上去。fanout 交换器不处理路由键，只是简单的将队列绑定到交换器上，每个发送到交换器的消息都会被转发到与该交换器绑定的所有队列上。很像子网广播，每台子网内的主机都获得了一份复制的消息。fanout 类型转发消息是最快的。 项目结构 pom <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0"

交换器介绍   RabbitMQ中有三种主要的交互器分别如下 交换器 说明 direct 发布与订阅 完全匹配 topic 主体，规则匹配 fanout 广播 topic介绍   TopicExchange 是比较复杂也比较灵活的 种路由策略,在TopicExchange 中,Queue 通过routingkey 绑定到 TopicExchange 上,当消息到达 TopicExchange 后,TopicExchange 根据消息的routingkey 消息路由到一个或者多 Queue上，相比direct模式topic会更加的灵活些。   本案例通过两个项目来实现，一个consumer项目和一个provider项目。 1.创建消费者 项目结构 配置文件 spring.application.name=springcloud-mq spring.rabbitmq.host=192.168.88.150 spring.rabbitmq.port=5672 spring.rabbitmq.username=dpb spring.rabbitmq.password=123 #设置交换器的名称 mq.config.exchange=log.topic #info 队列名称 mq.config.queue.info=log.info #error 队列名称 mq.config.queue

一、前言 在消息中间件中有 2 个重要的概念：消息代理和目的地。当消息发送者发送消息后，消息就被消息代理接管，消息代理保证消息传递到指定目的地。 我们常用的消息代理有 JMS 和 AMQP 规范。对应地，它们常见的实现分别是 ActiveMQ 和 RabbitMQ。 上篇文章 《Spring Boot 入门之缓存和 NoSQL 篇（四）》 。 二、整合 ActiveMQ 2.1 添加依赖 1 2 3 4 5 6 7 8 9 10 < dependency > < groupId > org.springframework.boot </ groupId > < artifactId > spring-boot-starter-activemq </ artifactId > </ dependency > <!-- 如果需要配置连接池，添加如下依赖 --> < dependency > < groupId > org.apache.activemq </ groupId > < artifactId > activemq-pool </ artifactId > </ dependency > 2.2 添加配置 1 2 3 4 5 6 7 8 # activemq 配置 spring.activemq.broker-url=tcp://192.168.2.12:61616

目录 初识RabbitMQ AMQP 3.RabbitMQ的极速入门 Exchange(交换机)详解 4.1 Direct Exchange 4.2 Topic Exchange 4.3 Fanout Exchange Message 消息 初识RabbitMQ RabbitMQ 是一个开源的消息代理和队列服务器，用来通过普通协议在完全不同的应用之间共享数据，RabbitMQ是使用 Erlang语言来编写的，并且RabbitMQ是基于AMQP协议的 RabbitMQ的优点: 开源、性能优秀、稳定性保障 提供可靠性消息投递模式(confirm)、返回模式(return) 与SpringAMQP完美的整合、API丰富 集群模式丰富，表达式配置，HA模式，镜像队列模型 保证数据不丢失的前提下做到高可靠性、可用性 RabbitMQ官网 RabbitMQ的整体架构: RabbitMQ的消息流转: AMQP AMQP全称: Advanced Message Queuing Protocol AMQP翻译: 高级消息队列协议 AMQP定义: 是具有现代特征的二进制协议。是一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计 AMQP核心概念： Server:又称Broker，接受客户端的连接，实现AMQP实体服务 Connection:连接

一、activemq 虽然是java写的消息队列，但是提供Java, C, C++, C#, Ruby, Perl, Python, PHP各种客户端，所以语言上是没什么问题的。配置和使用，基本上是java xml这一套。同时对jms、spring之类的支持很友好。 而且因为是Java写的，所以可以作为一个jar包，放到java项目里，用代码启动和配置，这个对于java开发者而言是不是相当爽？毕竟还是有些场景，需要我们把队列放到自己项目内部，随项目启动而启动的。而且，还可以类似拓展tomcat一样，自己写java的plugin来拓展activemq。比如说，我有10万硬件连到mq上，这10万设备每个都有用户名密码，这个时候我们可以用java写个权限验证，从数据库里查这10万用户名密码。 activemq支持主从复制、集群。但是集群功能看起来很弱，只有failover功能，即我连一个失败了，可以切换到其他的broker上。这一点貌似不太科学。假设有三个broker，其中一个上面没有consumer，但另外两个挂了，消息会转到这个上面来，堆积起来。看样子activemq还在升级中。 activemq工作模型比较简单。只有两种模式 queue,topics 。 queue就多对一，producer往queue里发送消息，消费者从queue里取，消费一条，就从queue里移除一条

基本概念 1.Producer：消息生产者，就是向 kafka broker 发消息的客户端 2.Consumer：消息消费者，向 kafka broker 取消息的客户端 3.Consumer Group（CG ）：消费者组，由多个 consumer 组成。 消费者组内每个消费者负责消费不同分区的数据， 一个分区只能由一个 组内 消费者消费； 消费者组之间互不影响。 所有的消费者都属于某个消费者组，即 消费者组是逻辑上的一个订阅者。 4.Broker：一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker可以容纳多个 topic。 5.Topic：可以理解为一个队列， 生产者和消费者面向的都是一个 topic 6.Partition：为了实现扩展性， 一个非常大的 topic 可以分布到多个 broker （即服务器） 上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列； 7.Replica： 副本， 为保证集群中的某个节点发生故障时， 该节点上的 partition 数据不丢失，且 kafka 仍然能够继续工作， kafka 提供了副本机制， 一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower。 8.leader：每个分区多个副本的“主”

概述 本文介绍使用ELK（elasticsearch、logstash、kibana） +　kafka来搭建一个日志系统。主要演示使用spring aop进行日志收集，然后通过kafka将日志发送给logstash，logstash再将日志写入elasticsearch，这样elasticsearch就有了日志数据了，最后，则使用kibana将存放在elasticsearch中的日志数据显示出来，并且可以做实时的数据图表分析等等。 详细 代码下载： http://www.demodashi.com/demo/10181.html 本文介绍使用ELK（elasticsearch、logstash、kibana） +　kafka来搭建一个日志系统。主要演示使用spring aop进行日志收集，然后通过kafka将日志发送给logstash，logstash再将日志写入elasticsearch，这样elasticsearch就有了日志数据了，最后，则使用kibana将存放在elasticsearch中的日志数据显示出来，并且可以做实时的数据图表分析等等。 为什么用ELK 以前不用ELK的做法 最开始我些项目的时候，都习惯用log4j来把日志写到log文件中，后来项目有了高可用的要求，我们就进行了分布式部署web，这样我们还是用log4j这样的方式来记录log的话

1. kafka介绍 1.1. 主要功能 根据官网的介绍，ApacheKafka®是一个分布式流媒体平台，它主要有3种功能： 　　1：It lets you publish and subscribe to streams of records.发布和订阅消息流，这个功能类似于消息队列，这也是kafka归类为消息队列框架的原因 　　2：It lets you store streams of records in a fault-tolerant way.以容错的方式记录消息流，kafka以文件的方式来存储消息流 　　3：It lets you process streams of records as they occur.可以再消息发布的时候进行处理 1.2. 使用场景 1：Building real-time streaming data pipelines that reliably get data between systems or applications.在系统或应用程序之间构建可靠的用于传输实时数据的管道，消息队列功能 2：Building real-time streaming applications that transform or react to the streams of data。构建实时的流数据处理程序来变换或处理数据流，数据处理功能 1.3

MQ背景&选型 消息队列作为高并发系统的核心组件之一，能够帮助业务系统解构提升开发效率和系统稳定性。主要具有以下优势： 削峰填谷（主要解决瞬时写压力大于应用服务能力导致消息丢失、系统奔溃等问题） 系统解耦（解决不同重要程度、不同能力级别系统之间依赖导致一死全死） 提升性能（当存在一对多调用时，可以发一条消息给消息系统，让消息系统通知相关系统） 蓄流压测（线上有些链路不好压测，可以通过堆积一定量消息再放开来压测） 目前主流的MQ主要是Rocketmq、kafka、Rabbitmq，Rocketmq相比于Rabbitmq、kafka具有主要优势特性有： • 支持事务型消息（消息发送和DB操作保持两方的最终一致性，rabbitmq和kafka不支持） • 支持结合rocketmq的多个系统之间数据最终一致性（多方事务，二方事务是前提） • 支持18个级别的延迟消息（rabbitmq和kafka不支持） • 支持指定次数和时间间隔的失败消息重发（kafka不支持，rabbitmq需要手动确认） • 支持consumer端tag过滤，减少不必要的网络传输（rabbitmq和kafka不支持） • 支持重复消费（rabbitmq不支持，kafka支持） Rocketmq、kafka、Rabbitmq的详细对比，请参照下表格： RocketMQ集群概述 RocketMQ集群部署结构 image

看过Kafka关于消费者的join Group的代码以后，我们可以知道，每一个Consumer的代理对象ConsumerCoordinator代表这个Consumer进行join Group操作，实际上是向GroupCoordinator发起JoinGroup请求。GroupCoordinator只负责告知Consumer其角色信息，即成为Leader还是Follower，并不负责分区分配，即管理Consumer和TopicPartition的对应关系。这种管理是被选举为Leader 的ConsumerCoordinator根据配置的分区分派规则来决定的。我们一起来从代码层面分析Kafka内置的分区分派算法RangeAssigner和RoundRobinAssigner。 为了不让读者感觉突兀，我们从ConsumerCoordinator收到JoinGroupResponse开始分析代码，即我们创建了一个消费者对象，开始消费消息的时候，底层会向远程的GroupCoordinator发起joinGroup请求，GroupCoordinator会进行处理并响应： private class JoinGroupResponseHandler extends CoordinatorResponseHandler < JoinGroupResponse , ByteBuffer > {