消息队列

1. 部署Erlang 1.1 RabbitMQ依赖于Erlang，版本对应请查看 https://www.rabbitmq.com/which-erlang.html 1.2 下载安装Erlang # 添加epel扩展源 yum install epel-release # 先删除可能存在的erlang（非必须） yum list erlang yum remove erl* # 清空和更新安装源（非必须） yum clean yum update # 参考 https://github.com/rabbitmq/erlang-rpm -> Erlang 21.x -> o use Erlang 21.x on CentOS 6 # 配置安装源 vim /etc/yum.repos.d/rabbitmq-erlang.repo [rabbitmq-erlang] name=rabbitmq-erlang baseurl=https://dl.bintray.com/rabbitmq-erlang/rpm/erlang/21/el/6 gpgcheck=1 gpgkey=https://dl.bintray.com/rabbitmq/Keys/rabbitmq-release-signing-key.asc repo_gpgcheck=0 enabled=0 # 安装 yum

kafka 相关术语： 术语 含义 producer，产生消息 消息生产者，发布消息到 kafka 集群的终端或服务。 consumer，消费消息 从 kafka 集群中消费消息的终端或服务。 topic，主题，在主题里分布消息 每条发布到 kafka 集群的消息属于的类别，即 kafka 是面向 topic 的。 broker，服务器 kafka 集群中包含的服务器。 Consumer group high-level consumer API 中，每个 consumer 都属于一个 consumer group，每条消息只能被 consumer group 中的一个 Consumer 消费，但可以被多个 consumer group 消费。 partition partition 是物理上的概念，每个 topic 包含一个或多个 partition。kafka 分配的单位是 partition。 replica partition 的副本，保障 partition 的高可用。 leader replica 中的一个角色， producer 和 consumer 只跟 leader 交互。 follower replica 中的一个角色，从 leader 中复制数据。 controller kafka 集群中的其中一个服务器，用来进行 leader election 以及 各种

两张图读懂kafka应用： Kafka 中的术语 broker：中间的kafka cluster，存储消息，是由多个server组成的集群。 topic：kafka给消息提供的分类方式。broker用来存储不同topic的消息数据。 producer：往broker中某个topic里面生产数据。 consumer：从broker中某个topic获取数据。 Kafka 中的术语设计： 1、Broker 中间的kafka cluster，存储消息，是由多个server组成的集群。 2、topic与消息 kafka将所有消息组织成多个topic的形式存储，而每个topic又可以拆分成多个partition，每个partition又由一个一个消息组成。每个消息都被标识了一个递增序列号代表其进来的先后顺序，并按顺序存储在partition中。 这样，消息就以一个个id的方式，组织起来。 producer选择一个topic，生产消息，消息会通过分配策略append到某个partition末尾。 consumer选择一个topic，通过id指定从哪个位置开始消费消息。消费完成之后保留id，下次可以从这个位置开始继续消费，也可以从其他任意位置开始消费。 上面的id在kafka中称为offset，这种组织和处理策略提供了如下好处： 消费者可以根据需求，灵活指定offset消费。 保证了消息不变性

什么是kafka？ kafka在进入apache之前是LinkedIn开源的，LinkedIn在开源界有着很多的 贡献，比如分布式数据同步系统Databus，高性能计算引擎Cubert，Java异步处理框架ParSeq，Kafka流处理平台；kafka在2011年开源之后就加入了apache基金会。 官方定义有如下三个特性： 1、Publish and subscribe to streams of records,similar to a message queue or enterprise messaging system. 2、Store streams of records in a fault-tolerant durable way. 3、Process streams of records as they occur. kakfa通常应用两类应用： 1、构建实时数据流管道； 2、构建实时的传输或响应的流数据的应用。 总结：Kafka是一个消息队列但不仅仅是一个消息队列。 来源： https://www.cnblogs.com/niuyg928/p/11143635.html

背景 作为中国最大的在线教育站点，目前沪江日志服务的用户包含网校，交易，金融，CCTalk 等多个部门的多个产品的日志搜索分析业务，每日产生的各类日志有好十几种，每天处理约10亿条（1TB）日志，热数据保留最近7天数据，冷数据永久保存。 为什么做日志系统 首先，什么是日志？ 日志就是程序产生的，遵循一定格式（通常包含时间戳）的文本数据 通常日志由服务器生成，输出到不同的文件中，一般会有系统日志、 应用日志、安全日志。这些日志分散地存储在不同的机器上。 通常当系统发生故障时，工程师需要登录到各个服务器上，使用 grep / sed / awk 等 Linux 脚本工具去日志里查找故障原因。在没有日志系统的情况下，首先需要定位处理请求的服务器，如果这台服务器部署了多个实例，则需要去每个应用实例的日志目录下去找日志文件。每个应用实例还会设置日志滚动策略（如：每天生成一个文件），还有日志压缩归档策略等。 这样一系列流程下来，对于我们排查故障以及及时找到故障原因，造成了比较大的麻烦。因此，如果我们能把这些日志集中管理，并提供集中检索功能，不仅可以提高诊断的效率，同时对系统情况有个全面的理解，避免事后救火的被动。 我认为，日志数据在以下几方面具有非常重要的作用： 数据查找 ：通过检索日志信息，定位相应的 bug ，找出解决方案 服务诊断 ：通过对日志信息进行统计、分析

本文是 OpenStack 中的 RabbitMQ 使用研究 两部分中的第一部分，将介绍 RabbitMQ 的基本概念，即 RabbitMQ 是什么。 第二部分 将介绍其在 OpenStack 中的使用。 1 RabbitMQ 的基本概念 RabbitMQ 是实现了高级消息队列协议（AMQP）的开源消息代理软件（亦称面向消息的中间件）。 AMQP 是一个定义了在应用或者组织之间传送消息的协议的开放标准 （an open standard for passing business messages between applications or organizations），它最新的版本是 1.0。AMQP 目标在于解决在两个应用之间传送消息存在的下列问题： 网络是不可靠的 =>消息需要保存后再转发并有出错处理机制 与本地调用相比，网络速度慢 =>得异步调用 应用之间是不同的（比如不同语言实现、不同操作系统等） =>得与应用无关 应用会经常变化 =>同上 AMQP 使用异步的、应用对应用的、二进制数据通信来解决这些问题。 RabbitMQ 是 AMQP 的一种实现，它包括Server （服务器端）、Client （客户端） 和 Plugins （插件）。RabbitMQ 服务器是用 Erlang 语言编写的，其最新版本是刚刚（2015/02/11）发布的 3.4.4 ，而

摘要：实际生产应用中都会采用消息队列的集群方案，如果选择RabbitMQ那么有必要了解下它的集群方案原理 一般来说，如果只是为了学习RabbitMQ或者验证业务工程的正确性那么在本地环境或者测试环境上使用其单实例部署就可以了，但是出于MQ中间件本身的可靠性、并发性、吞吐量和消息堆积能力等问题的考虑，在生产环境上一般都会考虑使用RabbitMQ的集群方案。 对于RabbitMQ这么成熟的消息队列产品来说，搭建它并不难并且也有不少童鞋写过如何搭建RabbitMQ消息队列集群的博文，但可能仍然有童鞋并不了解其背后的原理，这会导致其遇到性能问题时无法对集群进行进一步的调优。本篇主要介绍RabbitMQ集群方案的原理，如何搭建具备负载均衡能力的中小规模RabbitMQ集群，并最后给出生产环境构建一个能够具备高可用、高可靠和高吞吐量的中小规模RabbitMQ集群设计方案。 一、RabbitMQ集群方案的原理 RabbitMQ这款消息队列中间件产品本身是基于Erlang编写，Erlang语言天生具备分布式特性（通过同步Erlang集群各节点的magic cookie来实现）。因此，RabbitMQ天然支持Clustering。这使得RabbitMQ本身不需要像ActiveMQ、Kafka那样通过ZooKeeper分别来实现HA方案和保存集群的元数据。集群是保证可靠性的一种方式

某厂面试归来，发现自己落伍了！>>> 一、简介 消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。实现高性能、高可用 、 可伸缩和最终一致性架构。使用较多的消息队列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ。 二、消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景：异步处理，应用解耦，流量削锋和消息通讯四个场景。 1、异步处理 场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种：串行的方式和并行方式。 串行方式 ：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户。 并行方式 ：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间。 假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒，并行的时间可能是100毫秒。 因为CPU在单位时间内处理的请求数是一定的，假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次（1000/150）。并行方式处理的请求量是10次（1000/100）。 小结 ：如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题呢？

Maven配置 <dependency> <groupId>com.rabbitmq</groupId> <artifactId>amqp-client</artifactId> <version>3.6.0</version> </dependency> <dependency> <groupId>org.springframework.amqp</groupId> <artifactId>spring-rabbit</artifactId> <version>1.6.0.RELEASE</version> </dependency> 增加rabbitmq.properties文件并引入到spring中 mq.host=127.0.0.1 mq.username=zns mq.password=123456 mq.port=5672 用户名和密码可以访问http://localhost:15672登录后台设置， 注意：5672是连接端口，15672是管理界面的端口 增加spring-rabbitmq.xml <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001

以下是消息队列以下的大纲，本文主要介绍消息队列概述，消息队列应用场景和消息中间件示例（电商，日志系统）。 本次分享大纲 消息队列概述 消息队列应用场景 消息中间件示例 JMS消息服务 常用消息队列 参考（推荐）资料 本次分享总结 一、消息队列概述 消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。 目前在生产环境，使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。 二、消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景。 2.1异步处理 场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种1.串行的方式；2.并行方式。 （1）串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端。（架构KKQ：466097527，欢迎加入） （2）并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间。 假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒