RabbitMQ

　　现今业界分布式服务跟踪的理论基础主要来自于 Google 的一篇论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，使用最为广泛的开源实现是 Twitter 的 Zipkin，为了实现平台无关、厂商无关的分布式服务跟踪，CNCF 发布了布式服务跟踪标准 Open Tracing。国内，淘宝的 “鹰眼”、京东的 “Hydra”、大众点评的 “CAT”、新浪的 “Watchman”、唯品会的 “Microscope”、窝窝网的 “Tracing” 都是这样的系统。 　　一个分布式服务跟踪系统主要由三部分构成：数据收集、数据存储、数据展示。根据系统大小不同，每一部分的结构又有一定变化。譬如，对于大规模分布式系统，数据存储可分为实时数据和全量数据两部分，实时数据用于故障排查（Trouble Shooting），全量数据用于系统优化；数据收集除了支持平台无关和开发语言无关系统的数据收集，还包括异步数据收集（需要跟踪队列中的消息，保证调用的连贯性），以及确保更小的侵入性；数据展示又涉及到数据挖掘和分析。虽然每一部分都可能变得很复杂，但基本原理都类似。 　　服务追踪的追踪单元是从客户发起请求（request）抵达被追踪系统的边界开始，到被追踪系统向客户返回响应（response）为止的过程，称为一个

消息队列之rabbitmq学习使用 1、RabbitMQ简介 1.1、什么是RabbitMQ？ RabbitMQ是一个开源的消息代理和队列服务器，用来通过普通协议在完全不同的应用之间共享数据，RabbitMQ是使用Erlang语言来编写的，并且RabbitMQ是基于 AMQP协议的。 1.2、RabbitMQ有哪些特点？ 目前大多数互联网都在使用RabbitMQ RabbitMQ底层采用Erlang语言进行编写 开源、性能优秀，稳定 与SpringAMQP完美的整合、API丰富，只要是你能想到的编程语言几乎都有与其相适配的RabbitMQ客户端。 集群模式丰富，表达式配置，HA模式，镜像队列模型 保证数据不丢失的前提做到高可靠、可用性 RabbitMQ附带了一个易于使用的可视化管理工具，它可以帮助你监控消息代理的每一个环节。 如果你的消息系统有异常行为，RabbitMQ还提供了追踪的支持，让你能够发现问题所在。 RabbitMQ附带了各种各样的插件来对自己进行扩展。你甚至也可以写自己的插件来使用。 1.3、AMQP协议模型 2、RabbitMQ安装使用 2.1 安装rabbitmq，配置好阿里云的yum源，epel源 yum -y install erlang rabbitmq-server 2.2 启动rabbitmq服务端 systemctl start rabbitmq

目录： 消息路由失败了会怎样 备份交换器 TTL与DLX 如何实现延迟队列 RabbitMQ的RPC实现 持久化 事务 发送方确认机制 消息路由失败了会怎样： 在RabbitMQ中，如果消息路由失败了，一般会有两种情况。要么是把消息回退给客户端处理，要么就把消息丢弃。 处理逻辑是根据basicPublish方法的 mandatory 和 immediate 两个参数来控制。 1、 mandatory ：当mandatory=true时，如果交换器无法根据自身类型和路由键匹配到符合条件的队列，便会调用Basic.Return命令将消息会推给生产者；当mandatory=false时，不满足条件则丢弃此条消息。 1 channel.addReturnListener( new ReturnListener() { 2 public void handleReturn( int replyCode, String replyText, String exchange, String routingKey, 3 AMQP.BasicProperties properties, byte [] body) throws IOException { 4 // 具体处理逻辑 5 } 6 }); 2、 immediate ：当immediate=true时，交换器将消息路由到队列后

一、消息为什么丢失 RabbitMQ默认情况下的交换机和队列以及消息是非持久化的，也就是说在服务器重启或者宕机恢复后，之前创建的交换机和队列都将不复存在，之前未消费的消息也就消失不见了。原因在于每个队列和交换机的durable属性。该属性默认情况是false，它决定了RabbitMQ是否需要在崩溃或者重启之后重新创建队列（或者交换机）。 二、持久化交换机和队列 将交换机和队列的durable属性设置为true，这样你就不需要在服务器断电后重新创建队列和交换机了。你也许会认为把队列和交换机的durable属性设置为true就足够可以让消息幸免于重启后丢失了，真的是这样吗？队列和交换机当然必须被设置为true，但光这样做还不够。 能从AMQP服务器崩溃中恢复的消息，我们称之为持久化消息。在消息发布前，通过把它的“投递默认”（ delivery mode）选项设置为2（AMQP客户端可能会使用人性化的常量来代替数值）来把消息标记成持久化。到目前为止，消息还只是被表示为持久化的，但是它还必须被发布到持久化的交换机中，并到达持久化的队列中才行。如果不是这样的话，则包含持久化消息的队列（或者交换机）会在Rabbit崩溃重启后不复存在，从而导致消息丢失。 三、持久化消息 因此， 如果消息想要从Rabbit崩溃中恢复，那么消息必须满足以下条件： 1. 把它的投递默认选项设置为持久化 2.

熟悉 RabbitMQ 的人肯定知道 no_ack 属性是在调用 Basic.Consume 方法时可以设置的一个重要参数。本文主要针对 no_ack 设置的两种情况，通过抓包分析的形式讲解下实际应用中的异同，并总结一下相关的处理经验。 ============ 我是分隔线 ============= no_ack 的用途 ：确保 message 被 consumer “成功”处理了。这里“成功”的意思是，（在设置了 no_ack=false 的情况下）只要 consumer 手动应答了 Basic.Ack ，就算其“成功”处理了。 情况一 ： no_ack=true （此时为 自动应答 ） 在这种情况下，consumer 会在接收到 Basic.Deliver + Content-Header + Content-Body 之后，立即回复 Ack 。而这个 Ack 是 TCP 协议中的 Ack 。此 Ack 的回复不关心 consumer 是否对接收到的数据进行了处理，当然也不关心处理数据所需要的耗时。 图1：（Producer+Consumer） 图2：（Consumer） 图3：（Producer） 情况二： no_ack=false （此时为 手动应答 ） 在这种情况下，要求 consumer 在处理完接收到的 Basic.Deliver + Content-Header

生产者代码，注意要设在将返回数据放入的队列； 通过这种方式可以实现同步阻塞，从而得到返回数据 package com.boot.springbootnew.component; import com.alibaba.fastjson.JSON; import com.boot.springbootnew.config.ReturnComponent; import com.boot.springbootnew.pojo.MqFailLog; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.amqp.core.Message; import org.springframework.amqp.core.MessageProperties; import org.springframework.amqp.rabbit.core.RabbitTemplate; import org.springframework.amqp.rabbit.support.CorrelationData; import org.springframework.beans.factory.annotation.Autowired; import org.springframework

概述 canal client将从canal server获取的binlog数据以json格式发送到各种MQ中(rabbitmq，redis，kafka)。 部署 第一步：下载解压项目，使用的是与canal-server 1.0.22版本对应的client（canal-client-1.0.22.tar.gz）： 项目git地址：https://github.com/BooksCup/canal-client 第二步：配置项目 conf/canal.properties # canal server的IP canal.server.host = 192.168.0.51 # canal server的port canal.server.port = 11111 # canal server的实例 canal.server.instance = example # canal binlog的地址 canal.binlog.dir = data # mq选项(rabbitmq,redis,kafka),这边使用的是rabbitmq canal.mq = rabbitmq #rabbitmq rabbitmq.host = 192.168.0.51 rabbitmq.port = 5672 rabbitmq.user = guest rabbitmq.pass = guest # 队列名

一丶简介 RabbitMQ消息确认ACK机制 1、什么是消息确认ACK。 　　答：如果在处理消息的过程中，消费者的服务器在处理消息的时候出现异常，那么可能这条正在处理的消息就没有完成消息消费，数据就会丢失。为了确保数据不会丢失，RabbitMQ支持消息确定-ACK。 2、ACK的消息确认机制。 　　答：ACK机制是消费者从RabbitMQ收到消息并处理完成后，反馈给RabbitMQ，RabbitMQ收到反馈后才将此消息从队列中删除。 　　　　如果一个消费者在处理消息出现了网络不稳定、服务器异常等现象，那么就不会有ACK反馈，RabbitMQ会认为这个消息没有正常消费，会将消息重新放入队列中。 　　　　如果在集群的情况下，RabbitMQ会立即将这个消息推送给这个在线的其他消费者。这种机制保证了在消费者服务端故障的时候，不丢失任何消息和任务。 　　　　消息永远不会从RabbitMQ中删除，只有当消费者正确发送ACK反馈，RabbitMQ确认收到后，消息才会从RabbitMQ服务器的数据中删除。 　　　　消息的ACK确认机制默认是打开的。 3、ACK机制的开发注意事项。 　　答：如果忘记了ACK，那么后果很严重。当Consumer退出时候，Message会一直重新分发。然后RabbitMQ会占用越来越多的内容，由于RabbitMQ会长时间运行，因此这个"内存泄漏"是致命的。

需求起因 在高并发的业务场景下，数据库大多数情况都是用户并发访问最薄弱的环节。所以，就需要使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问MySQL等数据库。 这个业务场景，主要是解决读数据从Redis缓存，一般都是按照下图的流程来进行业务 读取缓存步骤一般没有什么问题，但是一旦涉及到数据更新：数据库和缓存更新，就容易出现 缓存(Redis)和数据库（MySQL）间的数据一致性问题 。 不管是先写MySQL数据库，再删除Redis缓存；还是先删除缓存，再写库，都有可能出现数据不一致的情况。举一个例子： 1.如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。 2.如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况。 因为写和读是并发的，没法保证顺序,就会出现缓存和数据库的数据不一致的问题。 如来解决？这里给出两个解决方案，先易后难，结合业务和技术代价选择使用。 缓存和数据库一致性解决方案 1.第一种方案：采用延时双删策略 在写库前后都进行redis.del(key)操作，并且设定合理的超时时间。 伪代码如下 public void write( String key, Object data ) { redis.delKey( key );

读取缓存步骤一般没有什么问题，但是一旦涉及到数据更新：五分赛车源码出售【企鹅21717-93408】数据库和缓存更新，就容易出现缓存(Redis)和数据库（MySQL）间的数据一致性问题。 不管是先写MySQL数据库，再删除Redis缓存；还是先删除缓存，再写库，都有可能出现数据不一致的情况。举一个例子： 1.如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。 2.如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况。 因为写和读是并发的，没法保证顺序,就会出现缓存和数据库的数据不一致的问题。 如来解决？这里给出两个解决方案，先易后难，结合业务和技术代价选择使用。 缓存和数据库一致性解决方案 1.第一种方案：采用延时双删策略 在写库前后都进行redis.del(key)操作，并且设定合理的超时时间。 伪代码如下 public void write( String key, Object data ) { redis.delKey( key ); db.updateData( data ); Thread.sleep( 500 ); redis.delKey( key ); }复制代码 2.具体的步骤就是： 先删除缓存 再写数据库 休眠500毫秒 再次删除缓存