消息队列

分布式消息系统 作为多种类型的数据管道和消息系统使用。 Kafka原本开发自LinkedIn，用作LinkedIn的活动流和运营数据处理管道（Pipeline）的基础。 活动流数据是几乎所有站点在对其网站使用情况做报表时都要用到的数据中最常规的部分。 活动数据 包括页面访问量（Page View）、被查看内容方面的信息以及搜索情况等内容。 这种数据通常的 处理方式 是先把各种活动以日志的形式写入某种文件，然后周期性地对这些文件进行统计分析。 运营数据 指的是服务器的性能数据（CPU、IO使用率、请求时间、服务日志等等数据)。运营数据的统计方法种类繁多。 近年来，活动和运营数据处理已经成为了网站软件产品特性中一个至关重要的组成部分，这就需要一套稍微更加复杂的基础设施对其提供支持。 2.3 为何使用消息系统 解耦 在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 冗余 有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前

什么是消息队列？ 为什么要用消息队列？ 即，应用场景是什么，也就是用了有什么好处 解耦 多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败 异步 多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间 削峰／限流 避免流量过大导致应用系统挂掉的情况 使用消息队列需要注意什么？ 系统复杂性增加 如何保证消息队列是高可用，即做到集群高可用 如何保证消费的可靠性传输，即不丢消息 如何保证消息不被重复消费，即保证消费的幂等性 如何保证消息的顺序性，即保证数据的逻辑正确性 简单分析RocketMQ的原理 高可用 上架构 NameServer ： 维持心跳和提供Topic-Broker的关系数据，多个Namesrv之间相互没有通信，单台Namesrv宕机不影响其他Namesrv与集群；即使整个Namesrv集群宕机，已经正常工作的Producer，Consumer，Broker仍然能正常工作，但新起的Producer, Consumer，Broker就无法工作，nameserver不会有频繁的读写，所以性能开销非常小，稳定性很高 Broker ： Broker与Namesrv的心跳机制：单个Broker跟所有Namesrv保持心跳请求，心跳间隔为30秒，心跳请求中包括当前Broker所有的Topic信息 高可靠并发读写服务

客户端connection、channels、queues、consumers和系统其它部分自动生成的事件。例如，当一个connection被接受，虚拟主机通过了验证授权，将会发送一个connection_created事件，当一个connection关闭或者由于其它原因失败，将会发送一个connection_closed事件。RabbitMQ提供了一个最小的事件通知机制向RabbitMQ客户端公开。 rabbitmq-event-exchange插件 rabbitmq-event-exchange是一个消费内部事件并且重新发送到一个topic exchange的插件，因此可以展示事件给客户端应用程序。 为了消费事件，应用程序需要声明一个队列，并绑定到一个系统指定的交换器去消费消息。 插件在默认的虚拟主机上声明了一个topic类型的exchange(交换器)amq.rabbitmq.event。所有的事件都会发送到这个exchange上并绑定一个路由键，比如，exchange.created、binding.deleted。所以你可以只订阅你关注的事件。 交换器的行为类似amq.rabbitmq.log，所有的信息都发布到这里，如果用户没有经过授权，你可以拒绝它们访问。 每个事件都有与之关联的各种属性，它们被转换成AMQP 0-9-1数据编码并插入到消息头中。消息的正文始终为空。

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1、 Kafka是一种分布式的，基于发布/订阅的消息系统。 2、 常用Message Queue对比 RabbitMQ RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。 Redis Redis是一个基于Key-Value对的NoSQL数据库，开发维护很活跃。虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。 ZeroMQ ZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景

2019年12月10日09:54:28 原文： https://www.rabbitmq.com/tutorials/tutorial-one-php.html 介绍 先决条件 本教程假定RabbitMQ 已 在标准端口（ 5672 ）的 本地主机 上 安装 并运行 。 如果您使用其他主机，端口或凭据，则连接设置需要进行调整。 在哪里获得帮助 如果您在阅读本教程时遇到困难，可以 通过邮件列表 与我们 联系。 RabbitMQ是消息代理：它接受并转发消息。 您可以将其视为邮局：将要发布的邮件放在邮箱中时，可以确保Mailperson先生或女士最终将邮件传递给收件人。 以此类推，RabbitMQ是一个邮箱，一个邮局和一个邮递员。 RabbitMQ与邮局之间的主要区别在于，它不处理纸张，而是接收，存储和转发数据 消息的 二进制斑点 。 RabbitMQ和一般的消息传递使用一些术语。 生产仅 意味着发送。 发送消息的程序是 生产者 ： 队列 是RabbitMQ内部的邮箱的名称。 尽管消息流经RabbitMQ和您的应用程序，但它们只能存储在 队列中 。 甲 队列 仅由主机的存储器＆磁盘限制约束，它本质上是一个大的消息缓冲器。 许多 生产者 可以发送进入一个队列的消息，许多 消费者 可以尝试从一个 队列 接收数据 。 这就是我们表示队列的方式： 消费 与接收具有相似的含义。 一个 消费者

2019年12月10日10:05:11 原文： https://www.rabbitmq.com/tutorials/tutorial-five-php.html 话题 （使用 php-amqplib ） 先决条件 本教程假定RabbitMQ 已 在标准端口（ 5672 ）的 本地主机 上 安装 并运行 。 如果您使用其他主机，端口或凭据，则连接设置需要进行调整。 在哪里获得帮助 如果您在阅读本教程时遇到困难，可以 通过邮件列表 与我们 联系。 在上 一教程中， 我们改进了日志记录系统。 我们没有使用只能进行虚拟广播 的 扇出 交换机，而是使用 直接 交换机 ，并有可能选择性地接收日志。 尽管使用 直接 交换改进了我们的系统，但它仍然存在局限性-它不能基于多个条件进行路由。 在我们的日志记录系统中，我们可能不仅要根据严重性订阅日志，还要根据发出日志的源订阅日志。 您可能从 syslog unix工具中 了解了这个概念，该 工具根据严重性（info / warn / crit ...）和工具（auth / cron / kern ...）路由日志。 这将为我们提供很大的灵活性-我们可能只想听来自“ cron”的严重错误，也可以听“ kern”的所有日志。 为了在日志系统中实现这一点，我们需要学习更复杂的 主题 交换。 话题交流 发送到 主题 交换的 消息 不能具有任意的

2019年12月10日10:05:54 原文： https://www.rabbitmq.com/tutorials/tutorial-six-php.html 远程过程调用（RPC） （使用 php-amqplib ） 先决条件 本教程假定RabbitMQ 已 在标准端口（ 5672 ）的 本地主机 上 安装 并运行 。 如果您使用其他主机，端口或凭据，则连接设置需要进行调整。 在哪里获得帮助 如果您在阅读本教程时遇到困难，可以 通过邮件列表 与我们 联系。 在 第二篇教程中， 我们学习了如何使用 工作队列 在多个工作人员之间分配耗时的任务。 但是，如果我们需要在远程计算机上运行功能并等待结果怎么办？ 好吧，那是一个不同的故事。 这种模式通常称为“ 远程过程调用” 或“ RPC” 。 在本教程中，我们将使用RabbitMQ构建RPC系统：客户端和可伸缩RPC服务器。 由于我们没有值得分配的耗时任务，因此我们将创建一个虚拟RPC服务，该服务返回斐波那契数。 客户端界面 为了说明如何使用RPC服务，我们将创建一个简单的客户端类。 它将公开一个名为 call 的方法，该方法 发送RPC请求并阻塞，直到收到答案为止： $ fibonacci_rpc = 新的 FibonacciRpcClient（）; $ response = $ fibonacci_rpc-> call（30）;

2019年12月10日10:07:12 原文： https://www.rabbitmq.com/tutorials/tutorial-seven-java.html 注意这里目前没有PHP版本只有java版本 发布者确认 发布者确认 是实现可靠发布的RabbitMQ扩展。 在通道上启用发布者确认后，代理将异步确认客户端发布的消息，这意味着它们已在服务器端处理。 （使用Java客户端） 先决条件 本教程假定RabbitMQ 已 在标准端口（ 5672 ）的 本地主机 上 安装 并运行 。 如果您使用其他主机，端口或凭据，则连接设置需要进行调整。 在哪里获得帮助 如果您在阅读本教程时遇到困难，可以 通过邮件列表 与我们 联系。 总览 在本教程中，我们将使用发布者确认来确保发布的消息已安全到达代理。 我们将介绍几种使用发布者确认并解释其优缺点的策略。 在频道上启用发布者确认 发布者确认是AMQP 0.9.1协议的RabbitMQ扩展，因此默认情况下未启用它们。 发布者确认在通道级别使用 confirmSelect 方法 启用 ： Channel channel = connection.createChannel（）; channel.confirmSelect（）; 必须在希望使用发布者确认的每个频道上调用此方法。 确认仅应启用一次，而不是对每个已发布的消息都启用。 策略1

rabbitmq 消息队列消息数量变化示例 rabbitmq 消息队列消息数量变化说明(后附go代码) 服务器和消费者之间的网络缓冲为1 服务器和消费者之间的网络缓冲为2 生产者代码 消费者代码 rabbitmq 消息队列消息数量变化说明(后附go代码) 预先给消息队列发布5条信息 服务器和消费者之间的网络缓冲为1 依次读取五条消息后，消息队列消息数量变化 服务器和消费者之间的网络缓冲为2 生产者代码 package main import ( "fmt" "log" "test1/amqp" "strconv" ) func failOnError(err error, msg string) { if err != nil { fmt.Printf("%s: %s\n", msg, err) } } func f6(){ conn, err := amqp.Dial("amqp://fm:1@192.168.7.29:5672/fm") failOnError(err, "Failed to connect to RabbitMQ") defer conn.Close() ch, err := conn.Channel() failOnError(err, "Failed to open a channel") defer ch.Close() q, err := ch

浅谈js运行机制(线程） 1.前言 从开始接触js时，我们便知道js是单线程的。单线程，异步，同步，互调，阻塞等。在实际写js的时候，我们都会用到ajax,不管是原生的实现，还是借助jQuery等工具库实现，我们都知道，ajax可以实现局部刷新，并且在请求处理时，任然可以响应用户的操作，比如点击事件。不是说js是单线程吗?这些都是怎么实现的？ 在阅读《深入理解Bootrap的源码》一书，在分析轮播组件(carousel.js)的源码时，作者对一句代码操作的注释引起了我的兴趣。 setTimeout(function(){ that.$element.trigger('slid'); },0);//触发slid事件,这里使用setTimeout是为了确保UI刷新线程不被阻塞。 1 2 3 4 后面我会一一解答这些疑惑。 2.浏览器线程 js运作在浏览器中,是单线程的，即js代码始终在一个线程上执行，这个线程称为js引擎线程。 浏览器是多线程的，除了js引擎线程，它还有： UI渲染线程 浏览器事件触发线程 http请求线程 EventLoop轮询的处理线程 …….. 这些线程的作用： UI线程用于渲染页面 js线程用于执行js任务 浏览器事件触发线程用于控制交互，响应用户 http线程用于处理请求，ajax是委托给浏览器新开一个http线程 EventLoop处理线程用于轮询消息队列