mq

参考-- http://activemq.apache.org/javalangoutofmemory.html 对于MQ的内容实用是可管理和可配置的。首先需要判断的是MQ的哪部分系统因内存不足而导致泄漏，是JVM，broker还是消费者、生产者？ 一、内存管理 JVM内存管理： 1. 用bin/activemq命令在独立JVM中运行broker。用-Xmx和-Xss命令即可（activemq.bat文件中修改ACTIVEMQ_OPTS选项参数即可）； 2. 默认情况下，MQ用512M的JVM； broker内存管理： 1. broker使用的内存并不是由JVM的内存决定的。虽然受到JVM的限制，但broker确实独立管理器内存； 2. systemUsage和destination的内存限制与broker内存息息相关； 3. MQ中内存的关系是：JVM->Broker->broker features; 4. 所有destination的内存总量不能超过broker的总内存； 消费者： 1. 由于消息大小可以配置，prefetch limit往往是导致内存溢出的主要原因； 2. 减少prefetch limit的大小，会减少消费者内存中存储的消息数量； 生产者： 1. 除非消息数量超过了broker资源的限制，否则生产者不会导致内存溢出； 2. 当内存溢出后

一、背景 书接 手写MQ框架（二）-服务端实现 ，前面介绍了服务端的实现。但是具体使用框架过程中，用户肯定是以客户端的形式跟服务端打交道的。客户端的好坏直接影响了框架使用的便利性。 虽然框架目前是通过web的形式提供功能的，但是某的目标其实是通过socket实现，所以不仅需要有客户端，还要包装一下，让用户在使用过程中不需要关心服务端是如何实现的。 简单来说，就是客户端使用必须方便。 二、客户端实现 1、HttpUtil 目前客户端的核心功能是HttpUtil这个类，使用httpClient实现的，主要是为了请求服务端。 具体实现如下： package com.shuimutong.gmq.client.util; import java.io.IOException; import java.net.URISyntaxException; import java.util.ArrayList; import java.util.List; import java.util.Map; import org.apache.http.HttpEntity; import org.apache.http.NameValuePair; import org.apache.http.client.entity.UrlEncodedFormEntity; import org.apache

一、起航 本着从无到有，从有到优的原则，所以计划先通过web实现功能，然后再优化改写为socket的形式。 1、关于技术选型 web框架使用了之前写的gmvc框架（ 手写MVC框架（一）-再出发 ），消息存储采用存在数据库的方式，使用的框架也是前段时间写的gdao（ 手写DAO框架（一）-从“1”开始 ）。 2、项目搭建 项目本来是单项目的形式，但是考虑到将服务端、客户端分开不是很友好，所以采用了maven父子模块的形式。 其中，父pom配置如下： <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.shuimutong</groupId> <artifactId>gmq</artifactId> <version>${global.version}<

什么是 MQ Message Queue（MQ），消息队列中间件。很多人都说：MQ 通过将消息的发送和接收分离来实现应用程序的异步和解偶，这个给人的直觉是——MQ 是异步的，用来解耦的，但是这个只是 MQ 的效果而不是目的。MQ 真正的目的是为了通讯，屏蔽底层复杂的通讯协议，定义了一套应用层的、更加简单的通讯协议。一个分布式系统中两个模块之间通讯要么是 HTTP，要么是自己开发的 TCP，但是这两种协议其实都是原始的协议。HTTP 协议很难实现两端通讯——模块 A 可以调用 B，B 也可以主动调用 A，如果要做到这个两端都要背上 WebServer，而且还不支持长连接（HTTP 2.0 的库根本找不到）。TCP 就更加原始了，粘包、心跳、私有的协议，想一想头皮就发麻。MQ 所要做的就是在这些协议之上构建一个简单的“协议”——生产者/消费者模型。MQ 带给我的“协议”不是具体的通讯协议，而是更高层次通讯模型。它定义了两个对象——发送数据的叫生产者；接收数据的叫消费者， 提供一个 SDK 让我们可以定义自己的生产者和消费者实现消息通讯而无视底层通讯协议 有 Broker 的 MQ 这个流派通常有一台服务器作为 Broker，所有的消息都通过它中转。生产者把消息发送给它就结束自己的任务了，Broker 则把消息主动推送给消费者（或者消费者主动轮询） 重 Topic kafka、JMS

目录： 1.什么是事务？ 2.换个角度看事务 3.Java中的事务 4.啥又是分布式事务？ 5.分布式事务的几种实现思路 6.总结 写在前面 在分布式、微服务大行其道的今天，相信大家对这些名词都不会陌生。而说到使用分布式，或者拆分微服务的好处，你肯定能想到一大堆。 比如每个人只需要维护自己单独的服务，没有了以前的各种代码冲突。自己想测试、想发布、想升级，只需要care自己写的代码就OK了，很方便很贴心！ 然而事物都有两面性，但是它也同时也会带来的一些问题，今天的文章谈的就是分布式系统架构带来的其中一个棘手的问题： 分布式事务 1、什么是事务？ 首先抛出来一个问题：什么是事务？ 有人会说事务就是一系列操作，要么同时成功，要么同时失败；然后会从事务的ACID特性（原子性、一致性、隔离性、持久性）展开叙述。 确实如此，事务就是为了保证一系列操作可以正常执行，它必须同时满足ACID特性。 但是今天我们 换个角度思考下，我们不仅要知道what（比如什么是事务），更要知道事务的why（比如为什么会有事务这个概念？事务是为了解决什么问题）。 有时候，换个角度说不定有不一样的收获。 2、换个角度看事务 就像经典的文学作品均来自于生活，却又高于生活，事务的概念同样来自于生活，引入“事务”肯定是为了解决某种问题，不然，谁又愿意干这么无聊的事情呢？ 最简单最经典的例子： 银行转账

为什么使用 Rabbit mq？ 1.Rabbit mq 是一个高级消息队列，在分布式的场景下，拥有高性能。，对负载均衡也有很好的支持。 2.拥有持久化的机制，进程消息，队列中的信息也可以保存下来。 3.实现消费者和生产者之间的解耦。 4.对于高并发场景下，利用消息队列可以使得同步访问变为串行访问达到一定量的限流，利于数据库的操作。 5.可以使用消息队列达到异步下单的效果，排队中，后台进行逻辑下单。 AMQP，即Advanced Message Queuing Protocol，高级消息队列协议，是应用层协议的一 个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在 1.1、rabbitMQ的优点（适用范围） 1. 基于erlang语言开发具有高可用高并发的优点，适合集群服务器。 2. 健壮、稳定、易用、跨平台、支持多种语言、文档齐全。 3. 有消息确认机制和持久化机制，可靠性高。 4. 开源 其他MQ的优势： 1. Apache ActiveMQ曝光率最高，但是可能会丢消息。 2. ZeroMQ延迟很低、支持灵活拓扑，但是不支持消息持久化和崩溃恢复。 其他消息队列，Kafka 定位是日志消息队列。吞吐量最大。 相比阿里的Rocket MQ ,Rabbit 来源： https://www.cnblogs.com

在服务化之前，业务通常都是本地API调用，本地方法调用性能损耗较小。服务化之后，服务提供者和消费者之间采用远程网络通信，增加了额外的性能损耗，业务调用的时延将增大，同时由于网络闪断等原因，分布式调用失败的风险也增大。如果服务框架没有足够的容错能力，业务失败率将会大幅提升。 除了性能、可靠性等问题，跨节点的事务一致性问题、分布式调用带来的故障定界困难、海量微服务运维成本增加等也是分布式服务框架必须要解决的难题。本章节我们将对服务化之后面临的挑战进行分析，并给出解决方案和业务最佳实践。 1. 性能和时延问题 在服务化之前，业务通常都是本地API调用，本地方法调用性能损耗较小。服务化之后，服务提供者和消费者之间采用远程网络通信，增加了额外的性能损耗： 1） 客户端需要对消息进行序列化，主要占用CPU计算资源。 2） 序列化时需要创建二进制数组，耗费JVM堆内存或者堆外内存。 3） 客户端需要将序列化之后的二进制数组发送给服务端，占用网络带宽资源。 4） 服务端读取到码流之后，需要将请求数据报反序列化成请求对象，占用CPU计算资源。 5） 服务端通过反射的方式调用服务提供者实现类，反射本身对性能影响就比较大。 6） 服务端将响应结果序列化，占用CPU计算资源。 7） 服务端将应答码流发送给客户端，占用网络带宽资源。 8） 客户端读取应答码流，反序列化成响应消息，占用CPU资源。

FROM： https://www.cnblogs.com/jajian/p/10014145.html 之前网上看到很多写分布式事务的文章，不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。 所以这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是 TCC 分布式事务。 首先说一下，这里可能会牵扯到一些 Spring Cloud 的原理，如果有不太清楚的同学，可以参考之前的文章： 《拜托，面试请不要再问我Spring Cloud底层原理！》 。 1 | 0 业务场景介绍 咱们先来看看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。 那对一个订单支付之后，我们需要做下面的步骤： 更改订单的状态为“已支付” 扣减商品库存 给会员增加积分 创建销售出库单通知仓库发货 这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。 2 | 0 进一步思考 好，业务场景有了，现在我们要更进一步，实现一个 TCC 分布式事务的效果。 什么意思呢？也就是说，[1] 订单服务-修改订单状态，[2] 库存服务-扣减库存，[3] 积分服务-增加积分，[4] 仓储服务-创建销售出库单。 上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。 举个例子

Rabbit MQ 的初步使用 一、先来说说 Java 代码中的初步集成吧 0. 业务场景模拟 在默认的虚拟主机（virtual-host） / 下，创建一个名为 test 的 Topic 类型的交换机（exchange），并设置其属性为不持久化（durable）、不自动删除（autoDelete）。 同时创建了一个名为 hello 的队列（Queue），并且设置不持久化（durable）、不排外的（exclusive）、不自动删除（autoDelete）。 将这个 Queue 与 exchange 绑定（binding）起来。并同时指定一个 routingKey 。这个key的作用就是让流进Exchange的消息流进指定的Queue。topic类型的exchange使用全名routingKey的话，就相当于点对点的发送接收了（初步认识rabbit mq感觉是这样子，后续继续深入学习时，发现这个观点不对的话，会改正的）。 1. 项目依赖 Maven pom文件里添加坐标。 <!-- Rabbit MQ 依赖--> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-amqp</artifactId> </dependency> 2. 在

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