Fanout

发布/订阅，使用扇型交换机（fanout） composer.json ### composer.json { "require": { "php-amqplib/php-amqplib": ">=2.9.0" } } 发布端（Publish） /** * rabbitmq * 发布／订阅 * Publish * https://github.com/rabbitmq/rabbitmq-tutorials * https://www.rabbitmq.com/tutorials/tutorial-three-php.html */ defined('DS') or define('DS', DIRECTORY_SEPARATOR); require_once __DIR__. DS . 'vendor' .DS.'autoload.php'; use PhpAmqpLib\Connection\AMQPStreamConnection; use PhpAmqpLib\Message\AMQPMessage; $connection = new AMQPStreamConnection('192.168.0.83', 5672, 'admin', 'admin'); $channel = $connection->channel(); // 创建一个fanout类型的交换机

1. 消息可靠性 RabbitMQ 的消息可靠性，一般是业务系统接入消息中间件时首要考虑的问题，一般通过三个方面保障： 发送可靠性：确保消息成功发送到 Broker。 存储可靠性：Broker 对消息持久化，确保消息不会丢失。 消费可靠性：确保消息成功被消费。 1. 发送可靠性 一般消息发送可靠性分为 3 个层级： At most once：最多一次，消息可能会丢失，但绝不会重复传输。 At least once：最少一次，消息绝不会丢失，但可能会重复传输。 Exactly once：恰好一次，每条消息肯定会被传输一次且仅传输一次。 RabbitMQ 支持其中的“最多一次”和“最少一次”。 其中“最少一次”投递实现需要考虑以下这几个方面的内容： 消息生产者需要开启事务机制或者 publisher confirm 机制，以确保消息可以可靠地传输到 RabbitMQ 中。 消息生产者需要配合使用 mandatory 参数或者备份交换器来确保消息能够从交换器路由到队列中，进而能够保存下来而不被丢弃。 “最多一次”的方式无需考虑以上那些方面，生产者随意发送，不过这样很难确保消息会成功发送。 2. 消费可靠性 消费者在消费消息的同时，需要将 autoAck 设置为 false，然后通过手动确认的方式去确认已经正确消费的消息，以免在消费端引起不必要的消息丢失。 3. 代码示例 // 可靠生产

RabbitMQ是目前非常热门的一款消息中间件，不管是互联网大厂还是中小企业都在大量使用。作为一名合格的开发者，有必要对RabbitMQ有所了解，本文是RabbitMQ快速入门文章，主要内容包括RabbitMQ是什么、RabbitMQ核心概念、常用交换器类型、用Docker安装RabbitMQ等。 RabbitMQ简介 以熟悉的电商场景为例，如果商品服务和订单服务是两个不同的微服务，在下单的过程中订单服务需要调用商品服务进行扣库存操作。按照传统的方式，下单过程要等到调用完毕之后才能返回下单成功，如果网络产生波动等原因使得商品服务扣库存延迟或者失败，会带来较差的用户体验，如果在高并发的场景下，这样的处理显然是不合适的，那怎么进行优化呢？这就需要消息队列登场了。 消息队列提供一个异步通信机制，消息的发送者不必一直等待到消息被成功处理才返回，而是立即返回。消息中间件负责处理网络通信，如果网络连接不可用，消息被暂存于队列当中，当网络畅通的时候在将消息转发给相应的应用程序或者服务，当然前提是这些服务订阅了该队列。如果在商品服务和订单服务之间使用消息中间件，既可以提高并发量，又降低服务之间的耦合度。 RabbitMQ就是这样一款我们苦苦追寻的消息队列。RabbitMQ是一个开源的消息代理的队列服务器，用来通过普通协议在完全不同的应用之间共享数据。 RabbitMQ是使用Erlang语言来编写的

1. redis各种应⽤场景 2. redis持久化机制 3.有没了解Docker，Docker和虚拟机有什么区别？ 4.说说rabbitmq的结构。 四种交换机： 直连交换机，Direct exchange：带路由功能的交换机，根据routing_key（消息发送的时候需要指定）直接绑定到队列， ⼀个交换机也可以通过过个routing_key绑定多个队列。 扇形交换机，Fanout exchange：⼴播消息。 主题交换机，Topic exchange：发送到主题交换机上的消息需要携带指定规则的routing_key，主题交换机会根据这个规 则将数据发送到对应的(多个)队列上。 ⾸部交换机，Headers exchange：⾸部交换机是忽略routing_key的⼀种路由⽅式。路由器和交换机路由的规则是通过 Headers信息来交换的，这个有点像HTTP的Headers。 将⼀个交换机声明成⾸部交换机，绑定⼀个队列的时候，定义⼀ 个Hash的数据结构，消息发送的时候，会携带⼀组hash数据结构的信息，当Hash的内容匹配上的时候，消息就会被写⼊队 列。 5.项⽬中哪⾥⽤到了kafka，kafka特性？ 6. 介绍springcloud核⼼组件及其作⽤，以及springcloud⼯作流程。 7.介绍springcloud⼼跳机制，以及消费端如何发现服务端（Ribbon）？ 8

RabbitMQ基础知识 一、背景 RabbitMQ是一个由erlang开发的AMQP（Advanced Message Queue ）的开源实现。AMQP 的出现其实也是应了广大人民群众的需求，虽然在同步消息通讯的世界里有很多公开标准（如 COBAR的 IIOP ，或者是 SOAP 等），但是在异步消息处理中却不是这样，只有大企业有一些商业实现（如微软的 MSMQ ，IBM 的 Websphere MQ 等），因此，在 2006 年的 6 月，Cisco 、Redhat、iMatix 等联合制定了 AMQP 的公开标准。 　　RabbitMQ是由RabbitMQ Technologies Ltd开发并且提供商业支持的。该公司在2010年4月被SpringSource（VMWare的一个部门）收购。在2013年5月被并入Pivotal。其实VMWare，Pivotal和EMC本质上是一家的。不同的是VMWare是独立上市子公司，而Pivotal是整合了EMC的某些资源，现在并没有上市。 　　RabbitMQ的官网是http://www.rabbitmq.com 花絮：本篇文章是一个系列的文章，本片是开篇，后续会陆陆续续的整理出来，我会现在我自己个人博客发表出来(www.battleheart.cn)，因为在自己的博客里面可以先修改了完善有些不对的地方，等完善后再发到博客园

1. 前言 RabbitMQ 是一个消息队列，说到消息队列，大家可能多多少少有听过，它主要的功能是用来实现应用服务的异步与解耦，同时也能起到削峰填谷、消息分发的作用。（了解源码可+求求: 1791743380） 消息队列在比较主要的一个作用是用来做应用服务的解耦，消息从消息的生产者传递到消息队列，消费者从消息队列中获取消息并进行消费，生产者不需要管是谁在消费消息，消费者也无需关注消息是由谁来生产的。在分布式的系统中，消息队列也会被用在其他地方，比如分布式事务的支持，代表如阿里开源的 RocketMQ 。 当然，我们本篇文章的主角还是 RabbitMQ 。 2. RabbitMQ 介绍 RabbitMQ 是实现 AMQP（高级消息队列协议）的消息中间件的一种，最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。 RabbitMQ 主要是为了实现系统之间的双向解耦而实现的。当生产者大量产生数据时，消费者无法快速消费，那么需要一个中间层。保存这个数据。 AMQP，即 Advanced Message Queuing Protocol，高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。AMQP 的主要特征是面向消息、队列、路由（包括点对点和发布

工作中经常用到消息中间件来解决系统间的解耦问题或者高并发消峰问题，但是消息的可靠性如何保证一直是个很大的问题，什么情况下消息就不见了？如何防止消息丢失？下面通过这篇文章，我们就聊聊RabbitMQ 消息可靠性如何解决的？ 本文分三部分说明 RabbitMQ 消息丢失场景有哪些？ 如何避免消息丢失？ 如何设计部署消息中间件保证消息可靠性？ RabbitMQ 消息丢失场景有哪些？ 首先我们看下消息周期投递过程： 我们把该图分三部分，左中右，每部分都会导致消息丢失情况,下面就详细聊聊每个阶段消息是如何丢的： 1.生产者生产消息到RabbitMQ Server 消息丢失场景 1） 外界环境问题导致：发生网络丢包、网络故障等造成RabbitMQ Server端收不到消息，因为生产环境的网络是很复杂的，网络抖动，丢包现象很常见，下面会讲到针对这个问题是如何解决的。 2） 代码层面，配置层面，考虑不全导致消息丢失 事例1: 一般情况下，生产者使用Confirm模式投递消息，如果方案不够严谨，比如RabbitMQ Server 接收消息失败后会发送nack消息通知生产者，生产者监听消息失败或者没做任何事情，消息存在丢失风险； 事例2: 生产者发送消息到exchange后，发送的路由和queue没有绑定，消息会存在丢失情况，下面会讲到具体的例子，保证意外情况的发生，即使发生，也在可控范围内。 2

以为rabbitmq会折腾很久，但没有想到就这么多点内容，主要是服务端的懒得去折腾，比如docker的转移啊，发布啊，部署啥的 今天写了一些代码，用的c#弄的，新建两个项目，一个sender，一个rec，需要说的都在代码里了 就说一下在vs里安装rabbitmq的client，如果看不懂，也懒得说了 以下是发送端的代码，就一个窗体 using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; using RabbitMQ.Client; using RabbitMQ.Client.Events; namespace rabbitmq_example_sender { public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void button1_Click( object sender, EventArgs e) { // 简单队列模式 var factory =

本文将系统分享 Git 底层知识：对象生命周期变化，底层数据结构，数据包文件结构，数据包文件索引，以及详细分析对象查询流程和算法。 状态模型 上图描述了 git 对象的在不同的生命周期中不同的存储位置，通过不同的 git 命令改变 git 对象的存储生命周期。 工作区 (workspace) 就是我们当前工作空间，也就是我们当前能在本地文件夹下面看到的文件结构。初始化工作空间或者工作空间 clean 的时候，文件内容和 index 暂存区是一致的，随着修改，工作区文件在没有 add 到暂存区时候，工作区将和暂存区是不一致的。 暂存区 (index) 老版本概念也叫 Cache 区，就是文件暂时存放的地方，所有暂时存放在暂存区中的文件将随着一个 commit 一起提交到 local repository 此时 local repository 里面文件将完全被暂存区所取代。暂存区是 git 架构设计中非常重要和难理解的一部分。 本地仓库 (local repository) git 是分布式版本控制系统，和其他版本控制系统不同的是他可以完全去中心化工作，你可以不用和中央服务器 (remote server) 进行通信，在本地即可进行全部离线操作，包括 log，history，commit，diff 等等。完成离线操作最核心是因为 git 有一个几乎和远程一样的本地仓库

什么是MQ？ 消息总线(Message Queue)，是一种跨进程、异步的通信机制，用于上下游传递消息。 由消息系统来确保消息的可靠传递。 MQ是干什么用的？ 应用解耦、异步、流量削锋、数据分发、错峰流控、日志收集等等... MQ衡量标准 服务性能、数据存储、集群架构 ActiveMQ ActiveMQ是apache出品，最流行的，能力强劲的开源消息总线，并且它一个完全支持JMS规范的消息中间件。其丰富的API、多种集群构建模式使得它成为业界老牌消息中间件，在中小型企业中应用广泛。 是其性能稍差，在面对高并发的情况下，会出现消息阻塞、堆积、延迟等问题。 默认采用了基于内存的kahaDB进行存储，如果需要保证消息的可靠性，也可以选择关系行数据库进行存储。 集群架构模式如下： Master-Slave模式：通过zookeeper对主从进行管理，正常情况下，从节点不会提供服务。当主节点出现问题后，zookeeper会高效的将主节点下掉，从节点来提供服务。 NetWork模式：两套主从Master-Slave节点。由网络联通，将其变为分布式的集群架构。 Kafka Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache顶级项目。Kafka主要特点就是 基于Pull的模式来处理消息消费 ， 追求高吞吐量 ，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制