mq

本文主要是记录我的工作流程，开启性能测试之旅~ 一、了解mq 主要搞懂中间件、队列、交换机、发送者、消费者以及发送的机制。 二、学习jmeter的使用 由于本次测试是通过在mq后台管理界面的队列中手动publish JSON数据来完成的，所以需要了解以下知识: 线程组 设置并发数、启动时间、循环次数、持续时间的意义和关系 HTTP请求 页面数据填写格式、使用代理服务器录制脚本，并获取接口地址 监听器 通过结果树看具体响应结果（跑脚本时关掉）、聚合报告分析吞吐量和发送速率等、了解聚合报告中各项指标的含义，并通过控制变量法进行对比，找出系统使用的最佳场景或者性能瓶颈。 贴一下我执行测试的示例： 1.录制 2.HTTP请求 mq性能测试参考： https://www.cnblogs.com/xpp142857/p/8457068.html jmeter参考书： 《全栈性能测试修炼宝典JMeter实战》 《零成本实现WEB性能测试++基于APACHE+JMETER》 来源： CSDN 作者： emmm... 链接： https://blog.csdn.net/qq_38249250/article/details/104805417

工作中经常用到rabbitmq,而用的语言主要是python，所以也就经常会用到python中的pika模块，但是这个模块的使用，也给我带了很多问题，这里整理一下关于这个模块我在使用过程的改变历程已经中间碰到一些问题 的解决方法 刚开写代码的小菜鸟 在最开始使用这个rabbitmq的时候，因为本身业务需求，我的程序既需要从rabbitmq消费消息，也需要给rabbitmq发布消息，代码的逻辑图为如下： 下面是我的模拟代码： #! /usr/bin/env python3 # .-*- coding:utf-8 .-*- import pika import time import threading import os import json import datetime from multiprocessing import Process # rabbitmq 配置信息 MQ_CONFIG = { "host": "192.168.90.11", "port": 5672, "vhost": "/", "user": "guest", "passwd": "guest", "exchange": "ex_change", "serverid": "eslservice", "serverid2": "airservice" } class RabbitMQServer

1. 消息中间件的核心设计思想 ： 采用 异步 通讯、自动 补偿与重试 、 分布式事务 、解决 流量削峰 问题、系统的 解耦 2. 消息中间件常用名词 : Broker 消息转发端，消息中间件Server端； Message 发送的消息内容 roducer 生产者，向Server端投递消息； Consumer 消费者，向Server端获取消息 MessageId 消息全局id 解决消息幂等性问题 3. 主流的MQ对比分析 ActiveMQ: 基本淘汰(老项目使用) 够轻巧（源代码比RocketMQ多）,支持持久化到数据库， 对队列数较多的情况支持不好。 RabbitMQ: 结合erlang语言本身的并发优势，支持很多的协议：AMQP，XMPP, SMTP, STOMP， 也正是如此，使的它变的非常重量级，更适合于企业级的开发。 RocketMQ: 阿里系下开源的一款分布式、队列模型的消息中间件，原名Metaq，3.0版本名称改为RocketMQ， 是阿里参照kafka设计思想使用java实现的一套mq,同时将阿里系内部多款mq产品 （Notify、metaq）进行整合，只维护核心功能，去除了所有其他运行时依赖， 保证核心功能最简化，在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构， 目前主要多用于订单交易系统。 Kafka: Apache下的一个子项目

前言 该文章为系列型文章，对IBMMQ的操作大部分在linux系统中进行，若还未进行软件安装，请移步 （一）linux中IBM MQ8.0版本的安装 ,若刚接触IBMMQ，并对其一无所知的话，请移步 （二）IBM MQ基本知识 ,进行基础知识的了解，若为大神，请忽略 使用到的命令 dspmq # 显示当前机器上的队列管理器 crtmqm qmgrName #创建新的队列管理器 strmqm qmgrName #启动队列管理器 runmqsc qmgrName #进入MQSC命令界面 DEFINE qlocal ( Q1 ) #定义本地队列 amqsput queueName qmgrName #向队列中保存消息 amqsgbr queueName qmgrName #查看队列中的消息 amqsget queueName qmgrName #从队列中取出消息 1. 使用账户mqm或组mqm下的账户登录系统 2. 使用dspmq命令查看当前机器上的队列管理器 使用命令后无任何输出表示当前机器不存在队列管理器 3. 使用crtmqm命令创建队列管理器QM1，并用dspmqm命令进行验证 如图，名为QM1的队列管理器已创建完成，并且当前状态为(Ended immediately) 4. 使用strmqm命令启动队列管理器QM1，再次用dspmqm进行验证 如图，名为QM1的队列管理器已启动

1.LRU 1.1. 原理 LRU（Least recently used，最近最少使用）算法根据数据的历史访问记录来进行淘汰数据，其核心思想是“如果数据最近被访问过，那么将来被访问的几率也更高”。 1.2. 实现 最常见的实现是使用一个链表保存缓存数据，详细算法实现如下： 1. 新数据插入到链表头部； 2. 每当缓存命中（即缓存数据被访问），则将数据移到链表头部； 3. 当链表满的时候，将链表尾部的数据丢弃。 1.3. 分析 【命中率】 当存在热点数据时，LRU的效率很好，但偶发性的、周期性的批量操作会导致LRU命中率急剧下降，缓存污染情况比较严重。 【复杂度】 实现简单。 【代价】 命中时需要遍历链表，找到命中的数据块索引，然后需要将数据移到头部。 2. LRU-K 2.1. 原理 LRU-K中的K代表最近使用的次数，因此LRU可以认为是LRU-1。LRU-K的主要目的是为了解决LRU算法“缓存污染”的问题，其核心思想是将“最近使用过1次”的判断标准扩展为“最近使用过K次”。 2.2. 实现 相比LRU，LRU-K需要多维护一个队列，用于记录所有缓存数据被访问的历史。只有当数据的访问次数达到K次的时候，才将数据放入缓存。当需要淘汰数据时，LRU-K会淘汰第K次访问时间距当前时间最大的数据。详细实现如下： 1. 数据第一次被访问，加入到访问历史列表； 2.

1.找不到交换机exchange Channel shutdown: channel error; protocol method: # method<channel.close>(reply-code=404, reply-text=NOT_FOUND - no exchange ' amq.direct ' in vhost 'testhost', class-id=60, method-id=40) 原因：查看下图红框中是否有exchange ‘ amq.direct’，没有则会报错，添加即可 2.同一个Vhost下不可添加相同类型（Type）的exchange channel is already closed due to channel error; protocol method: # method(reply-code=406, reply-text=PRECONDITION_FAILED - cannot switch from tx to confirm mode, class-id=85, method-id=10) 原因：添加相同类型（Type）的exchange 来源： CSDN 作者： Mark_ZP 链接： https://blog.csdn.net/weixin_40160361/article/details/96429446

概述 MQ全称为Message Queue, 消息队列（MQ）是一种应用程序对应用程序的通信方法。应用程序通过读写出入队列的消息（针对应用程序的数据）来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过 队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。其中较为成熟的MQ产品有IBM WEBSPHERE MQ等等。 安装Erlang 1.安装基础包:gcc ncurses-devel yum install gcc yum install ncurses-devel 2.去官网下载对应版本的Erlang (1)编译安装erlang (2)rpm包安装 由于本次安装erlang是为了支持rabbitmq的安装,并非为了Erlang的开发使用 所以选择rpm包安装 下载地址: http://www.rabbitmq.com/releases/erlang/ 根据环境不同选择不同版本 本机选用版本: erlang-19.0.4-1.el6.x86_64.rpm 3.安装Erlang rpm -ivh erlang-19.0.4-1.el6.x86_64.rpm 4.安装完后输入“erl”以下提示即为安装成功： [root@localhost ~]#

RabbitMQ,ActiveMq,ZeroMq比较 ==结论==：ZeroMq 最好，RabbitMq 次之， ActiveMq 最差。 ==来源==： http://blog.x-aeon.com/2013/04/10/a-quick-message-queue-benchmark-activemq-rabbitmq-hornetq-qpid-apollo/ ==测试环境==： Model: Dell Studio 1749 CPU: Intel Core i3 @ 2.40 GHz RAM: 4 GB OS: Windows 7 64 bits 测试都是采用软件的 默认配置 。 ==测试结果==： 横轴为各个MQ，纵轴为时间，单位秒(s)， 时间越少越好 。 ==比较==： 持久性 zeroMq不支持，activeMq和rabbitMq都支持 技术点：可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、problem tracker、可视化管理工具、插件系统、社区 RabbitMq最好，ActiveMq次之，ZeroMq最差。当然ZeroMq也可以做到，不过自己必须手动写代码实现，代码量不小。++可靠性中的： 持久性 、 投递确认 、 发布者证实 和 高可用性 ++。 高并发 从实现语言来看，RabbitMQ最高，原因是它的实现语言是天生具备高并发高可用的erlang语言

DLX Dead Letter Exchange 的缩写 DLX也叫死信邮箱（网上的译法），死信交换机（字面翻译）。归根结底就是一个交换机，当队列中出现死信时，通过这个交换机将死信重新发送到死信队列中（指定好rabbitmq会自动发送）。 什么是死信 什么是死信呢？官方给出三个说法： 消息被拒绝（basic.reject或basic.nack）并且requeue=false. 消息TTL过期 队列达到最大长度（队列满了，无法再添加数据到mq中） 什么是死信交换机 在定义业务队列的时候，要考虑指定一个死信交换机，死信交换机可以和任何一个普通的队列进行绑定，然后在业务队列出现死信的时候就会将数据发送到死信队列。 什么是死信队列 死信队列实际上就是一个普通的队列，只是这个队列跟死信交换机进行了绑定，用来存放死信而已。 如何使用死信交换机 #####定义业务（普通）队列的时候指定参数 x-dead-letter-exchange : 用来设置死信后发送的交换机 x-dead-letter-routing-key ：用来设置死信的routingKey 死信交换机图解 ![![ ] 创建业务队列 @Bean public Queue mailQueue() { Map<String, Object> map = new HashMap<String, Object>(); map.put("x

在分布式系统中，实现强一致性并不容易。即使2PC、3PC阶段提交，也无法保证绝对的强一致性。 我们也不能因为极小的不一致性概率，导致系统整体性能低下，或者扩展性受到影响，并且架构也变得极其复杂。因此，在2PC/3PC提交缺乏大规模应用的情况下，最终一致性是一个较好的方案，在业界得到了大量使用。 一、重试机制 如下图所示，Service Consumer 同时调用 Service A 和 Service B，如果Service A 调用成功，Service B 调用识别，为了保证最终一致性，最简单的办法是重试。 重试的时候，要注意设置Service Consumer 的超时时间， 避免长时间等待或卡死，耗尽资源。 Consumer 重试时，需要注意如下几个方面： 超时时间； 重试的次数； 重试的间隔时间； 重试间隔时间的衰减度； 具体实现细节，可以参考《 基于Spring-tryer 优雅的重试方案》。 二、本地记录日志 通过本地记录日志，然后收集到分布式监控系统或者其他后端系统中，启动一个定期检查的工具。根据实际情况，可以选择人工处理。 日志格式：TranID-A-B-Detail TransID为事务ID，可以生成一个随机序列号； Detail 为数据的详细内容； 如果调用A成功，则记录 A success； 如果调用B失败，或者出现故障，没有记录等等，也就是日志中没有B