最近在做一个公司的日志组件时有一个问题难住了我.今天问题终于解决了.由于在解决问题中,在网上也查了很多资料都没有一个完整的实例可以参考.所以本着无私分享的目的记录一下完整的解决过程和实例. 需求:做一个统一日志系统可以查看日志列表和一个可以订阅最新日志的页面.通过提供一个封装好日志记录方法的sdk文件将日志统一收集. 通过上面的需求进行我们使用RabbitMQ+Mongodb来实现系统. 使用C#封装一个SDK大家都会这里就不说了.C#连接RabbitMQ示例代码也是一堆堆的也没什么好说的.下面

项目是一个数据同步项目,线下Android客户端把本地sqllite数据提交到云端队列,php做守护进程消费队列,以同步数据.初测没有问题,可是时不时出现诡异的崩溃,因为设置了错误邮件报警,发现错误代码如下: PHP Warning 'yii\base\ErrorException' with message 'Error while sending QUERY packet. PID=45905' in /home/muffycat_takeout/vendor/yiisoft/yii2/db

背景现象 1.20晚上8点业务线开始切换LBS相关流量,在之后的1个小时时间内,积压量呈上升趋势,一路到达50W左右,第二天的图没贴出具体是50W数字,以下是第一天晚上的贴图部分. 现象一: 现象二: 当时现场图后来就找不回来了,凭印象说明了一下数字. 简要说明一下上述两个图 图一:其实很明显,明显看出,消费者消费速度明显跟不上生产者的发送速度,导致出现积压情况. 图二:图二就有点意思了,因为上游通过Kafka消息队列发送消息给我,分区数是20个.由于消费组内消费者实例是17个,所以从宏观上分析

什么是幂等 幂等本来是数学上的概念,它的定义是这样的: 如果一个函数 f(x) 满足:f(f(x)) = f(x),则函数 f(x) 满足幂等性. 在计算机领域用来描述一个操作.方法或者服务.一个幂等操作的特点是,其任意多次执行所产生的影响均与一次执行的影响相同. 场景 将林志玲账户的余额加 100 元 方法一:利用数据库的唯一约束实现幂等 我们在数据库中建一张转账流水表,这个表有三个字段:转账单 ID.账户 ID 和变更金额,然后给转账单 ID 和账户 ID 这两个字段联合起来创建一个唯一约束

使用rabbitmqctl 管理 mq -n 指定节点 [root@logging-master zabbix]# rabbitmqctl -n rabbit@localhost list_queues Timeout: 60.0 seconds ... Listing queues for vhost / ... name messages q_game_bilog 6822 q_withdraw_record 0 q_commission_hourly_text 0 q_user_login

一.kafka自带的消费机制 kafka有个offset的概念,当每个消息被写进去后,都有一个offset,代表他的序号,然后consumer消费该数据之后,隔一段时间,会把自己消费过的消息的offset提交一下,代表我已经消费过了.下次我要是重启,就会继续从上次消费到的offset来继续消费. 但是当我们直接kill进程了,再重启.这会导致consumer有些消息处理了,但是没来得及提交offset.等重启之后,少数消息就会再次消费一次. 其他MQ也会有这种重复消费的问题,那么针对这种问题,我

Rabbitmq 重消费处理 一 处理流程图: 业务交换机:正常接收发送者,发送过来的消息,交换机类型topic AE交换机: 当业务交换机无法根据指定的routingkey去路由到队列的时候,会全部发送到AE交换机.发送到此队列的消息属于,业务垃圾消息,或者攻击消息类型,交换机类型fanout 死信交换机:用于处理消费者,消费失败回退的消息,根据死信交换机的routingkey发送到死信队列,交换机类型 topic EXAMPLE: 业务routingkey: hello/task_queue

消息无序产生的原因 消息队列,既然是队列就能保证消息在进入队列,以及出队列的时候保证消息的有序性,显然这是在消息的生产端(Producer),但是往往在生产环境中有多个消息的消费端(Consumer),尽管消费端在拉取消息时是有序的,但各个消息由于网络等方面原因无法保证在各个消费端中处理时有序. 场景分析 先后两次修改了商品信息,消息A和消息B先后同步写入MySQL,接着异步写入消息队列中发送消息,此时消息队列生产端(Producer)按时序先后发出了A和B两条消息(消息A先发出,消息B后发出)

使用场景 消费端ACK和重回队列 消费端ACK使用场景: 1.消费端进行消费的时候,如果由于业务异常我们可以进行日志记录,然后进行补偿. 2.由于服务器宕机等严重问题,那我们就需要手工进行ACK保障消费端消费成功. 消费端的重回队列 消费端的重回队列是为了对没有处理成功的消息,把消息重新投递给broker 一般在实际应用中,都会关闭重回队列,也就是设置为false 创建生产者 package com.dwz.rabbitmq.ack; import java.io.IOException; im

1.引入maven依赖 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-amqp</artifactId> </dependency>2.在application.yml的配置: spring: rabbitmq: host: 106.52.82.241 port: 5672 username: yang

1.引入依赖 pom.xml 1 <!-- activemq --> 2 <dependency> 3 <groupId>org.springframework</groupId> 4 <artifactId>spring-jms</artifactId> 5 <version>4.3.23.RELEASE</version> 6 </dependency> 7 8 <dependency&g

前言 最近花了我几个月的业余时间,对EQueue做了一个重大的改造,消息持久化采用本地写文件的方式.到现在为止,总算完成了,所以第一时间写文章分享给大家这段时间我所积累的一些成果. EQueue开源地址:https://github.com/tangxuehua/equeue EQueue相关文档:http://www.cnblogs.com/netfocus/category/598000.html EQueue Nuget地址:http://www.nuget.org/packages/eq

  一.本文章包含的内容 1.列举了ActiveMQ中通过Queue方式发送.消费队列的代码(普通文本.json/xml字符串.对象数据) 2.spring+activemq方式   二.配置信息 1.activemq的pom.xml信息 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 <!--activemq  Begin-->        <dependency>            <groupId>org.springfr

在开发过程中,遇到一个bug,产生bug的原因是spring事务提交晚于消息队列的生产消息,导致消息队列消费消息时获取到的数据不正确.这篇文章介绍问题的产生和一步步的解决过程. 一.问题的产生: 场景还原:接口中的一个方法,首先修改订单状态,然后向消息队列中生产消息,消息队列的消费者获取到消息检测订单状态,发现订单状态未更改. 代码: @Service(orderApi) public class OrderApiImpl implements OrderApi { @Resource MqSe

看了https://www.jianshu.com/p/453c6e7ff81c这篇博客,得出顺序消费的结论."要实现严格的顺序消息,简单且可行的办法就是:保证生产者 - MQServer - 消费者是一对一的关系". 我们下面通过几个实例来学习RocketMQ的顺序消费. 一.单节点,也就是一个Producer一个Consumer. 操作步骤: 1.先启动ConsumerQueue1 2.再启动ProducerQueue Producer端: package org.hope.lee

一.摘要 BlockingQueue通常用于一个线程在生产对象,而另外一个线程在消费这些对象的场景,例如在线程池中,当运行的线程数目大于核心的线程数目时候,经常就会把新来的线程对象放到BlockingQueue中去. 二.阻塞队列原理 原理简单的来讲:就是一个线程往队列里面放,而另外的一个线程从里面取 当线程持续的产生新对象并放入到队列中,直到队列达到它所能容纳的临界点.注意,队列的容量是有限的,不可能一直往里面插入对象.如果队列到达了临界点时,这个时候再想往队列中插入元素则会产生阻塞,直到另一

介绍 MQ全称为Message Queue, 是一种分布式应用程序的的通信方法,它是消费-生产者模型的一个典型的代表,producer往消息队列中不断写入消息,而另一端consumer则可以读取或者订阅队列中的消息.RabbitMQ是MQ产品的典型代表,是一款基于AMQP协议可复用的企业消息系统 系统架构 Rabbitmq系统最核心的组件是Exchange和Queue,Exchange和Queue是在rabbitmq server(又叫做broker)端,producer和consumer在应用

前面第六章我们使用的是direct直连模式来进行消息投递和分发.本章将介绍如何使用fanout模式将消息推送到多个队列. 有时我们会遇到这样的情况,多个功能模块都希望得到完整的消息数据.例如一个log的消息,一个我们希望输出在屏幕上实时监控,另外一个用户持久化日志.这时就可以使用fanout模式.fanout模式模式不像direct模式通过routingkey来进行匹配,而是会把消息发送到所以的已经绑定的队列中. 新建FanoutProduct用来发布消息.FanoutCustomerA和Fan

参考上篇博文:https://www.cnblogs.com/niutao/p/10547718.html 同样的逻辑,不同的封装 package offsetInZookeeper /** * Created by angel */ import java.lang.Object import kafka.utils.{ZKGroupTopicDirs, ZkUtils} import org.apache.kafka.clients.consumer.{ConsumerRecord, Kaf

版本声明: kafka:1.0.1 spark:2.1.0 注意:在使用过程中可能会出现servlet版本不兼容的问题,因此在导入maven的pom文件的时候,需要做适当的排除操作 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2

RabbitMQ消息处理失败,我们会让失败消息进入重试队列等待执行,因为在重试队列距离真正执行还需要定义的时间间隔,因此,我们可以将重试队列设置成延时处理.今天参考网上其他人的实现,简单梳理下消息延时重试执行的思路. 消费失败后,自动延时将消息重新投递,当达到一定的重试次数后,将消息投递到失败消息队列,等待人工介入处理.在这里我们一步一步实现一个带有失败重试功能的发布订阅组件,使用该组件后可以非常简单的实现消息的发布订阅. 业务背景 结合RabbitMQ的Topic模式和Work Queue模式