东境物语

脑裂问题RabbitMQ集群的网络分区容错性并不高，在网络质量较差的环境中会比较容易出现问题，其中最明显的就是脑裂问题所谓的脑裂问题，就是在多机热备的高可用HA系统中，当两个节点心跳突然断开，就分裂为了两个独立的个体，由于互相失去联系，都认为对方出现了故障，因此都会去争抢对方的资源，争抢启动，由此就会发生严重的后果举个形象的例子，A和B作为一个双机热备集群的两个节点，各...

RabbitMQ分布式集群架构和高可用性（HA）(一） 功能和原理设计集群的目的允许消费者和生产者在RabbitMQ节点崩溃的情况下继续运行 通过增加更多的节点来扩展消息通信的吞吐量1 集群配置方式RabbitMQ可以通过三种方法来部署分布式集群系统，分别是：cluster,federation,shovel cluster: 不支持跨网段，用于同一个网段内的局域网...

数据丢失为大事，针对数据丢失的问题我们排查结果如下。第一：是否存在数据丢失的问题？存在，且已重现。第二：是在什么地方丢失的数据，是否是YDB的问题？数据丢失是在导入阶段，数据并没有写入到Kafka里面，所以YDB也就不会从Kafka里面消费到缺失的数据，数据丢失与延云YDB无关。第三：是如何发现有数据丢失？1.测试数据会一共创建365个分区，每个分区均是9亿...

背景早期，阿里巴巴B2B公司因为存在杭州和美国双机房部署，存在跨机房同步的业务需求。不过早期的数据库同步业务，主要是基于trigger的方式获取增量变更，不过从2010年开始，阿里系公司开始逐步的尝试基于数据库的日志解析，获取增量变更进行同步，由此衍生出了增量订阅&消费的业务，从此开启了一段新纪元。ps. 目前内部使用的同步，已经支持mysql5.x和oracle部分版本的日志解析...

RabbitMQ基础知识一、背景 RabbitMQ是使用erlang开发的开源消息队列，通过erlang的Actor模型实现了数据的稳定可靠传输，支持AMQP、XMQP、SMTP等多种协议，因此也比较重量级。由于采用broker代理架构，发送给客户端时，先在阻塞队列进行排队，rabbitMQ的单机吞吐量在万级。　　RabbitMQ的官网是http://www.rabbitm...

适应场景异步处理，应用解耦，流量削锋和消息通讯RabbitMQ：使用erlang开发的开源消息队列，通过erlang的actor模型实现了数据的稳定可靠传输，支持AMQP、XMQP、SMTP等多种协议，因此也比较重量级。由于采用broker代理架构，发送给客户端时，先在阻塞队列进行排队，rabbitMQ的单机吞吐量在万级。kafka：由scala开发的高性能、跨语言、分布式消息队列，单...

DLX也是一个正常的 Exchange，和一般的 Exchange 没有区别，它能在任何的队列上被指定，实际上就是设置某个队列的属性。当这个队列中有死信时，RabbitMQ 就会自动的将这个消息重新发布到设置的 Exchange 上去，进而被路由到另一个队列。可以监听这个队列中消息做相应的处理。

在 RabbitMQ 3.6.x 开始，RabbitMQ 官方提供了延迟队列的插件，可以下载放置到 RabbitMQ 根目录下的 plugins 下。来开启延迟队列，也可以设置为以下内容传入交换机声明的方法中，因为第一种方式的底层就是通过这种方式来实现的。底层代码，也是在 header 中设置 x-delay。等同于我们手动设置 header。发送消息时我们需要指定延迟推送的时间，我们这里在发送消息的方法中传入参数。我们在 Exchange 的声明中可以设置。对象的api 来设置延迟时间。

场景一：物联网系统经常会遇到向终端下发命令，如果命令一段时间没有应答，就需要设置成超时。场景二：订单下单之后30分钟后，如果用户没有付钱，则系统自动取消订单、库存回滚。上述类似的需求是我们经常会遇见的问题。最常用的方法是定期轮训数据库，设置状态。在数据量小的时候并没有什么大的问题，但是数据量一大轮训数据库的方式就会变得特别耗资源。当面对千万级、上亿级数据量时，本身写入的IO就比较高，导致长时间查询或者根本就查不出来，更别说分库分表以后了。

比如prefetchCount=1，则在同一时间下，每个Consumer在同一个时间点最多处理1个Message，同时在收到Consumer的ack前，它不会将新的Message分发给它。比如：现在有2个消费者，所有的奇数的消息都是繁忙的，而偶数则是轻松的。按照轮询的方式，奇数的任务交给了第一个消费者，所以一直在忙个不停。，即使其中有的消费者闲置有的消费者高负荷。RabbitMQ会逐个发送消息到在序列中的下一个消费者(而不考虑每个任务的时长等等，且是提前一次性分配，并非一个一个分配)。

首先需要思考一个问题：我们为什么要MQ？通过使用消息队列，我们可以异步处理请求，从而缓解系统的压力。 MQ提供松耦合的应用架构。Consumer可能需要一段时间才能处理完收到的数据。如果在这个过程中，Consumer出错了，异常退出了，而数据还没有处理完成，这段数据就丢失了。如果我们采用no-ack的方式进行确认，也就是说，每次Consumer接到数据后，而不管是否处理完成，Rabb...

消息producer在发送消息的时候，对于同一个broker连接是存在多个未确认的消息在同时发送的，也就是存在上面场景说到的情况，虽然A和B消息是顺序的，但是由于存在未知的确认关系，有可能存在A发送失败，B发送成功，A需要重试的时候顺序关系就变成了BA。对于一个有着先后顺序的消息A、B，正常情况下应该是A先发送完成后再发送B，但是在异常情况下，在A发送失败的情况下，B发送成功，而A由于重试机制在B发送完成之后重试发送成功了。所以我们应该将其设置为1，保证在后一条消息发送前，前一条的消息状态已经是可知的。

业界对于消息的传递有多种方案和产品，本文就比较有代表性的两个MQ（rabbitMQ，kafka）进行阐述和做简单的对比，

Confirm模式最大的好处在于它是异步的，一旦发布一条消息，生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息，当消息最终得到确认之后，生产者应用便可以通过回调方法来处理该确认消息，如果RabbitMQ因为自身内部错误导致消息丢失，就会发送一条basic.nack来代替basic.ack的消息，在这个情形下，basic.nack中各域值的含义与basic.ack中相应各域含义是相同的，同时requeue域的值应该被忽略。在自动确认模式下，消息在发送后立即被认为是发送成功。

我们知道可以通过持久化（交换机、队列和消息持久化）来保障我们在服务器崩溃时，重启服务器消息数据不会丢失。但是我们无法确认当消息的发布者在将消息发送出去之后，消息到底有没有正确到达Broker代理服务器呢？如果不进行特殊配置的话，默认情况下发布操作是不会返回任何信息给生产者的，也就是默认情况下我们的生产者是不知道消息有没有正确到达Broker的。如果在消息到达Broker之前已经丢失的话，持久化操作...

在message到达Exchange后，Exchange会根据route规则进入对应的Queue中，message可能进入一个Queue也可能进入对应多个Queue，至于进入哪个Queue或者是说哪个Queue都不进入，这要依据ExChange的ExchangeType和Exchange所绑定的路由规则，实现AMQP0.9.1协议的RabbitMQ Broker提供了四种ExChangeType。...

简介由于项目中需要使用kafka作为消息队列，并且项目是基于spring-boot来进行构建的，所以项目采用了spring-kafka作为原生kafka的一个扩展库进行使用。先说明一下版本：spring-boot 的版本是1.4.0.RELEASEkafka 的版本是0.9.0.x 版本spring-kafka 的版本是1.0.3.RELEASE用过kafka的人都知道，对于使用k

问题描述采用kafka读取消息进行处理时，consumer会重复读取afka队列中的数据。问题原因kafka的consumer消费数据时首先会从broker里读取一批消息数据进行处理，处理完成后再提交offset。而我们项目中的consumer消费能力比较低，导致取出的一批数据在session.timeout.ms时间内没有处理完成，自动提交offset失败，然后kafka会重

Step 1: 下载代码http://kafka.apache.org/downloads.html0.10.0.0是最新版本。 当前的稳定版本是0.10.0.0。下载0.10.0.0版本并且解压它。> tar -zxvf kafka_2.10-0.10.0.0.tgz  > cd kafka_2.11-0.10.0.0Step 2: 启动服务运行k

1、安装kafka web console软件前先安装sbt(安装步骤：http://blog.youkuaiyun.com/wwd0501/article/details/79267672)2、我们从https://github.com/claudemamo/kafka-web-console上面将源码下载下来，并执行命令解压： unzip kafka-web-console-master.zi

以下是消息队列以下的大纲，本文主要介绍消息队列概述，消息队列应用场景和消息中间件示例（电商，日志系统）。本次分享大纲消息队列概述消息队列应用场景消息中间件示例JMS消息服务常用消息队列参考（推荐）资料本次分享总结一、消息队列概述消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式

简单的说，Kafka是由Linkedin开发的一个分布式的消息队列系统(Message Queue)目标Scope（解决什么问题）kafka开发的主要初衷目标是构建一个用来处理海量日志，用户行为和网站运营统计等的数据处理框架。在结合了数据挖掘，行为分析，运营监控等需求的情况下，需要能够满足各种实时在线和批量离线处理应用场合对低延迟和批量吞吐性能的要求。从需求