消息中间件(Kafka/RabbitMQ)收录集

本篇主要整理工作中遇到的一些消息中间件的相关知识,包括Kafka, RabbitMQ, RocketMQ, ActiveMQ等,不排除收录其他消息中间件的可能。
这里会持续收录相关知识,包括安装、部署、使用示例、监控、运维、原理等。
所有新撰写的与中间件有关的文章都会收录与此,注意保存本文链接。


RabbitMQ消息可靠性分析

Introduction

有很多人问过我这么一类问题:RabbitMQ如何确保消息可靠?很多时候,笔者的回答都是:说来话长的事情何来长话短说。的确,要确保消息可靠不只是单单几句就能够叙述明白的,包括Kafka也是如此。可靠并不是一个绝对的概念,曾经有人也留言说过类似全部磁盘损毁也会导致消息丢失,笔者戏答:还有机房被炸了也会导致消息丢失。可靠性是一个相对的概念,在条件合理的范围内系统所能确保的多少个9的可靠性。一切尽可能的趋于完美而无法企及于完美。


RabbitMQ管理(5)——集群管理

rabbitmqctl join_cluster {cluster_node} [–ram]

将节点加入指定集群中。在这个命令执行前需要停止RabbitMQ应用并重置节点。更多详细内容请参考RabbitMQ安装


RabbitMQ管理(4)——应用管理

本文主要阐述应用与集群相关的一些操作管理命令,包括关闭、重置、开启服务,还有建立集群的一些信息。有关集群搭建更多的信息可以参考RabbitMQ的安装及集群搭建方法


RabbitMQ管理(3)——Web端管理

前面讲述的都是使用rabbitmqctl工具来管理RabbitMQ,有些时候你是否会觉得这种方式是不是不太友好?而且为能够运行rabbitmqctl工具,当前的用户需要拥有访问Erlang cookie的权限,由于服务器可能是以guest或者rabbit用户身份来运行的,因此你需要获得这些文件的访问权限,这样就引申出来一些权限管理的问题。


RabbitMQ管理(2)——用户管理

在RabbitMQ中,用户是访问控制(Access Control)的基本单元,且单个用户可以跨越多个vhost进行授权。针对一至多个vhost,用户可以被赋予不同级别的访问权限,并使用标准的用户名和密码来认证用户。


RabbitMQ管理(1)——多租户与权限

每一个RabbitMQ服务器都能创建虚拟的消息服务器,我们称之为虚拟主机(virtual host),简称为vhost。每一个vhost本质上是一个独立的小型RabbitMQ服务器,拥有自己独立的队列、交换器以及绑定关系等待,并且它拥有自己独立的权限。vhost就像是虚拟机与物理服务器一样,它们在各个实例间提供逻辑上的分离,允许你为不同程序安全保密地运行数据,它既能将同一个RabbitMQ的中众多客户区分开,又可以避免队列和交换器等命令冲突。vhost之间是绝对隔离的,你无法将vhost1中的交换器与vhost2中的队列进行绑定,这样既保证了安全性,又可以确保可移植性。如果在使用RabbitMQ达到一定规模的时候,建议用户对业务功能、场景进行归类区分,并为之分配独立的vhost。


RabbitMQ之惰性队列(Lazy Queue)

RabbitMQ从3.6.0版本开始引入了惰性队列(Lazy Queue)的概念。惰性队列会尽可能的将消息存入磁盘中,而在消费者消费到相应的消息时才会被加载到内存中,它的一个重要的设计目标是能够支持更长的队列,即支持更多的消息存储。当消费者由于各种各样的原因(比如消费者下线、宕机亦或者是由于维护而关闭等)而致使长时间内不能消费消息造成堆积时,惰性队列就很有必要了。


RabbitMQ之监控(3)

确保RabbitMQ能够健康的运行还不足以让人放松警惕。考虑这样一种情况:小明为小张创建了一个队列并绑定了一个交换器,之后某人由于疏忽而阴差阳错的删除了这个队列而无人得知,最后小张在使用这个队列的时候就会报出“NOT FOUND”的错误。如果这些在测试环境中发生,那么还可以弥补。如果在实际生产环境中,如果误删了一个队列,那必然会造成不可估计的影响。此时业务方如果正在使用这个队列,正常情况下会立刻报出异常,相关人员迅可以迅速做出动作以尽可能的降低影响。试想如果是一个定时任务调用此队列,并在深夜3点执行相应的逻辑,此时报出异常想必也会对相关人员造成不小的精神骚扰。


RabbitMQ之监控(2)

本文接RabbitMQ之监控(1)

不管是通过HTTP API接口还是客户端,获取的数据都是为了提供监控视图之用,不过这一切都基于RabbitMQ服务运行完好的情况下。虽然可以通过某些其他工具或方法来检测RabbitMQ进程是否在运行(如:ps aux | grep rabbitmq),或者5672端口是否开启(如:telnet xxx.xxx.xxx.xxx 5672),但是这样依旧不能真正的评判RabbitMQ是否还具备服务外部请求的能力。这里就需要使用AMQP协议来构建一个Ping的检测程序,这个类似于TCP协议的Ping。当这个测试程序与RabbitMQ服务无法建立TCP协议层面的连接,或者无法构建AMQP协议层面的连接,亦或者构建连接超时时则可判定RabbitMQ服务处于异常状态而无法正常的为外部应用提供相应的服务。示例程序下:

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×