mq

1、 IBM MQ 服务端配置（模拟服务端） a ）打开“ WebSphere MQ 资源管理器”，新建队列管理器，名称为 fwd_dlgl_name( 服务器端 mq 队列管理器名称 ) ，其余采用默认设置 ; b ）在 fwd_dlgl_name( 服务器端 mq 队列管理器名称 ) 队列管理器中创建本地队列，名称为 fwd_bddl_name( 服务器端 mq 本地队列名称 ); c ）创建传输队列，名称为 fwd_csdl_name( 服务器端 mq 本地传输队列名称 ) （新建时选择“本地队列”，将“用法”设置为“传输”） ; d ）创建远程队列定义，名称为 fwd_ycdl_name( 服务器端 mq 远程队列名称 ) ，指定远程队列名称为 khd_bddl_name( 客户端端 mq 本地队列名称 ) ，远程队列管理器名称为 khd_dlgl_name( 客户端 mq 队列管理器名称 ) ，传输队列名称为 fwd_csdl_name( 服务器端 mq 本地传输队列名称 ); e ）创建发送方通道，名称为 yc_kh( 服务端发送到客户端的通道名称 ) ，传输协议为 TCP/IP ，连接名称为客户端 ip 地址 ( 客户端 mq 的端口 ) ，传输队列为 fwd_csdl_name( 服务器端 mq 本地传输队列名称 ); f ）创建服务器连接通道，名称为 DC

本文主要通过实际编码来对 《MQ: 一张图读懂kafka工作原理》 提到的部分原理进行验证与实现。 相关文章参考: MQ: 消息队列常见应用场景及主流消息队列ActiveMQ、RabbitMQ、RocketMQ和Kafka的简单对比 MQ: 一张图读懂kafka工作原理 1.版本说明 后续代码依赖于以下版本，其他版本不保证代码可用： kafka 服务版本：2.11-1.0.1 kafka-clients.jar 版本：2.2.0 spring-kafka.jar 版本：1.3.5.RELEASE spring-boot 版本：1.5.10.RELEASE 2.kafka接入 pom.xml 先引入kafka的spring依赖包，这个包提供Producer和Consumer相关的操作。 < dependency > < groupId > org.springframework.kafka </ groupId > < artifactId > spring-kafka </ artifactId > < version > 1.3.5.RELEASE </ version > </ dependency > 如果想进行Topic、Partition相关的操作，则引入下面的包： < dependency > < groupId > org.apache.kafka </

一、为什么要使用MQ 1. 异步：快速返回 2. 解耦：解除依赖 3. 削峰填谷 二、MQ的缺点 1. 系统可用性降低，因为MQ可能会挂 2. 系统复杂性提高，要考虑消息重复、丢失、顺序等问题 3. 数据一致性问题，生产者并不知道消费者是否真正消费了 三、怎么保证MQ消息不丢失 1. 生产者丢失数据，confirm机制 2. MQ丢失数据，持久化到磁盘 3. 消费者丢失数据，确认机制 四、怎么保证MQ高可用性 1. 单机模式 2. 普通集群模式，无法做到真正的高可用 3. 镜像集群模式，高可用但是性能低 来源： https://www.cnblogs.com/june0816/p/11343238.html

一、前言部分 1.MQ的产品种类 二、入门概述 1.为什么引入MQ 2..MQ的作用定义 3.ActiveMQ官网介绍和下载 二、ActiveMQ安装和控制台 1.官网下载 2.Linux的安装 a.普通启动 b.普通关闭 c.带日志的启动方式 3.ActiveMQ控制台访问 三、Java编码实现ActiveMQ通讯 1.POM文件 2.JMS编码总体架构 3.队列 a.消息生产者编码 b.消息消费者编码 c.总结 a.JMS的基本开发步骤 b.两种消费方式 4.topic 5.队列和topic对比 四、JMS规范和落地产品 1.是什么 a.JavaEE是什么 b.JMS 2.MQ中间件的其他落地产品 3.JMS的组成结构和特点——四大元素 a.消息头 b.消息体 c.消息属性 4.JMS的可靠性 （1）持久性 （2）事务 （3）签收 5.JMS的点对点总结 6.JMS的发布订阅总结 五.ActiveMQ的Broker 1.是什么 六、Spring整合ActiveMQ 1.pom文件 2.Spring配置文件 3.队列 4.主题 5.在Spring里面实现消费者不启动，直接通过配置监听完成 七.SpringBoot整合ActiveMQ 1.队列 2.主题 两个主题消费者都同时消费生产者消息 八、ActiveMQ的传输协议 1.是什么 2.有哪些 a.tcp协议 b.NIO协议 3

I have the requirement like connecting MQ with userid instead of channel. I have tried with setting user id and password without chanel to MQEnvironment class but got the below exception. " com.ibm.mq.jmqi.JmqiException: CC=2;RC=2540;AMQ9520: Channel not defined remotely. [3=]." Please guide me, is it possible to write java client to connect MQ with user id instead of channel. There are 2 ways for an MQ application to connect to a queue manager: bindings and client mode. Bindings mode means that your MQ application is running on the SAME server as the queue manager. Hence, the MQI calls will

最近在看消息系统方面的东西。作为一个实践主义者，在看消息系统的各种实现时，不妨先粗略思考一下如何设计一个消息系统。我总觉出来有这么几个点(比较粗陋，以后继续补充)： 队列的存储和管理 用什么方式存储消息决定了这个消息系统的最终表现。 push还是pull producer没啥好说的，肯定是push，这里主要说consumer，pull的好处是可以根据consumer消费能力来处理消息，而push的好处则是实时性 服务横向扩展 是否存在单点？如何进行横向扩展的？failover如何做？ 保证一次消费 消息不丢失；不会重复消费。 topic模式 是否支持单条message多个comsumer同时消费？用什么机制保证其工作？ 监控 有没有监控手段？ 好了，现在先来看Kafka。Kafka是LinkedIn的一个消息系统。主要用来处理日志并进行实时分析。 Kafka有一篇翻译好的文章 http://www.oschina.net/translate/kafka-design 。 Kafka要解决的是大吞吐量下的消息队列问题。 队列过长时，很多消息系统都不给力 Kafka使用文件系统来进行存储，基本没有什么限制。文件都是立刻flush。 将消息打包成 MessageSet ，本身是Buffer的思想，例如nagle算法 消息压缩 支持GZIP 将消息强制排序，并用“最高水位标记”（high

1、为什么要使用消息队列? 分析:一个用消息队列的人，不知道为啥用，有点尴尬。没有复习这点，很容易被问蒙，然后就开始胡扯了。 回答:这个问题,咱只答三个最主要的应用场景(不可否认还有其他的，但是只答三个主要的),即以下六个字:解耦、异步、削峰 (1)解耦 传统模式: 传统模式的缺点： 系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！ 中间件模式: 中间件模式的的优点： 将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。 (2)异步 传统模式: 传统模式的缺点： 一些非必要的业务逻辑以同步的方式运行，太耗费时间。 中间件模式: 中间件模式的的优点： 将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度 (3)削峰 传统模式 传统模式的缺点： 并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常 中间件模式: 中间件模式的的优点： 系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。 2、使用了消息队列会有什么缺点? 分析:一个使用了MQ的项目，如果连这个问题都没有考虑过，就把MQ引进去了，那就给自己的项目带来了风险。 我们引入一个技术，要对这个技术的弊端有充分的认识，才能做好预防。要记住

微服务系统 事务 事务的原则 事务：是一种可靠，一致的方式，访问和操作数据库中数据的程序单元 原则特性： 原子性， 一致性 ，隔离性：事务之间互不干扰，持久性： 没提交事务之前，系统挂了，数据还是之前的数据，并没有被改变 mysql 查询事务的隔离级别 SELECT @@GLOBAL.tx_isolation,@@tx_isolation; 默认是 REPEATABLE-READ 可重复读 什么是 可重复读？ 比如 开启一个 事务，这个事务只读某一个表的 某条 的取数据。 但是这时候并没有提交 ， 但是 这时候另一个事务 修改了 该条数据，并提交了事务。 此时 之前的 的那个为 提交的事务，再次查询数据，这时候的数据是 未改变之前的数据，并不会因为 其他事务修改了数据提交了事务， 而显示出来 修改的值。 mysql 可重复读 修复 因为mysql 的事务隔离级别是 可重复读，另一个事务a 在执行更新数据，但是未提交， 这时候 一个事务 读取到 值之后， 另一个事务a更新了数据， 那么这时候 之前读取的值就不对了，怎么解决呢？ 1， 要么改 数据隔离级别是 序列化的, 可以修改当前 连接 session的 事务隔离级别 2. 使用 FOR UPDATE 这时候 比如 SELECT * FROM T_USER FOR UPDATE 此时 如果该表有未 提交事务，将等待 事务提交完成

1. 分布式事务原理解析 1.1. TCC分布式事务 了解过TCC分布式事务的都知道它有三个阶段：try，confirm，cancel，但很多文章就只有原理图，和对原理图的解释，看一遍也留不下印象，这里用实际场景举个例子，说明TCC分布式事务原理 try阶段：假设我们又订单系统，它需要调用库存和积分系统，try阶段我们进行的是 预处理 ，比如下单1个商品，在try操作中，我们在库存表设置个冻结字段，表示冻结1个商品，商品的存量先不扣除，而积分表同样添加个预增加积分字段，添加个预积分比如10 confirm阶段： 我们为什么要经历try阶段？ ，为了尽可能的保证各个系统都是正常工作的，数据库，服务都没有挂掉，资源没有不足，则可以最大程度上保证confirm阶段能正确执行， confirm阶段也就是正式的扣除库存和增加积分 cancel阶段： 若try阶段执行错误 ，则会对前面已经执行的try阶段的系统执行cancel操作，也就是反向SQL回滚，冻结的商品-1，预积分-10。到这里有没有疑问？我首先想到的是 若confirm或cancel操作再执行失败怎么办 ？这里就要由TCC分布式事务框架保证了，它会 记录事务活动日志 ，再confirm或cancel失败后不断尝试调用confirm和cancel的逻辑，所以这里需要开发者自己保证，你的SQL是正确的 TCC分布式框架推荐