mq

在分布式系统中，为了保证数据一致性是必须使用分布式事务。分布式事务实现方式就很多种，今天主要介绍一下使用 RocketMQ 事务消息，实现分布事务。 文末有彩蛋，看完再走 为什么需要事务消息？ 很多同学可能不知道事务消息是什么，没关系，举一个真实业务场景，先来带你了解一下普通的消息存在问题。 上面业务场景中，当用户支付成功，将会更新支付订单，然后发送 MQ 消息。手续费系统将会通过拉取消息，计算手续费然后保存到另外一个手续费数据库中。 由于计算手续费这个步骤可以离线计算，所以这里采用 MQ 解耦支付与计算手续费的流程。 流程主要涉及三个步骤： 更新订单数据 发送消息给 MQ 手续费系统拉取消息 上面提到的步骤，任何一个都会失败，如果我们没有处理，就会使两边数据不一致，将会造成下面两种情况： 订单数据更新了，手续费数据没有生成 手续费数据生成，订单数据却没有更新 这可是涉及到真正的钱，一旦少计算，就会造成 资损 ，真的赔不起！ 对于最后一步来讲，比较简单。如果消费消息失败，只要没有提交消息确认，MQ 服务端将会自动重试。 最大的问题 在于我们无法保证更新操作与发送消息一致性。无论我们采用先更新订单数据，再发送消息，还是先发送消息，再更新订单数据，都在存在一个成功，一个失败的可能。 如下所示，采用先发送消息，然后再更新数据库的方式。 上面流程消息发送成功之后，再进行本地事务的提交

RabbitMQ集群架构模式 那么对于Rabbitmq是单点应用来说，如果rabbitmq整个消息mq都会摊掉，所有在mq的消息高可用部分，就显得尤为重要了，那么在mq中提供了四种集群架构方案： 1、主备模式 （Warren) 2、镜像模式 （Mirror) 3、远程模式 (Shovel) 4、多活模式 （Federation) 在我们开发中最直接的模式就是主备模式：主要实现RabbitMQ的高可用集群，一般在并发和数据量不高的情况下，这种模型非常的好用且简单，主备模式也称为Warren模式 也就是一主一备，对于集群来说至少有两台服务器，那么这两台服务器一台在工作，一台在闲置，注意，这个的主备和我们之前的主从是不一样的，主从的话是一台作为主服务器，一台作为从服务器，虽然这两台是数据同步，主负责读写，而从只负责只读，而主备是一台工作一台闲着，如果一台服务器宕机了，那么备服务器切换过来，可能的话，这种对于负载均衡的话一台只忙着干活，一台只闲着，这种的生产中用的也很少，这种会造成我们资源的一个浪费。 镜像模式：集群模式非常经典的就是Mirror镜像模式，保证100%数据不丢失，在实际工作中也是用的最多的，而且实现集群也非常简单，一般互联网大厂都会构建这种镜像集群模式，原理主要是在主备的基础上进行了扩展，集群中所有的节点设备都是同步的，每一个队列，交换机里面的配置信息和我们的数据都是同步的

3 月，跳不动了？>>> ActiveMQ简介： https://my.oschina.net/u/4284277/blog/3212385 ActiveMQ安装与使用： https://my.oschina.net/u/4284277/blog/3212386 SpringBoot整合ActiveMQ： https://my.oschina.net/u/4284277/blog/3212387 1.消息队列应用场景 异步处理、应用解耦、流量削峰和信息通讯四个场景 1.1 异步处理 场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种: 1.串行方式；2.并行方式 1.串行方式：将注册信息写入 数据库 成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端 2.并行方式: 将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间 假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒， 并行的时间可能是100毫秒。 因为CPU在单位时间内处理的请求数是一定的，假设CPU在1秒内吞吐量是100次。则串行方式1秒 内CPU可处理的请求量是7次（1000/150）。并行方式处理的请求量是10次（1000/100） 小结：如以上案例描述

现公司选择RocketMQ作为消息队列服务器，用于异步处理，应用解耦，流量削锋和消息通讯四个场景。RocketMQ特性参见： Rocketmq整体分析 。 PS: http://blog.csdn.net/konglongaa/article/details/52208273 http://www.coin163.com/good/blog/mq.html 来源： https://www.cnblogs.com/phpdragon/p/6741526.html

一 网络原因导致MQ脑裂： 问题重现： Network partition detected Mnesia reports that this RabbitMQ cluster has experienced a network partition. There is a risk of losing data. Please read RabbitMQ documentation about network partitions and the possible solutions. 当出现网络分区时，不同分区里的节点会认为不属于自身所在分区的节点都已经挂了，对 queue、exchange、binding 的操作仅对当前分区有效。在 RabbitMQ 的默认配置下，即使网络恢复了也不会自动处理网络分区带来的问题从而恢复集群。RabbitMQ（3.1+）会自动探测网络分区，并且提供了配置来解决这个问题。 [ {rabbit, [{tcp_listeners,[5672]}, {cluster_partition_handling, ignore}] } ]. RabbitMQ 提供了三种配置： 1、ignore：默认配置，发生网络分区时不作处理，当认为网络是可靠时选用该配置 2、autoheal：各分区协商后重启客户端连接最少的分区节点，恢复集群（CAP 中保证 AP，有状态丢失

1.架构 主项 子项 rabbitMQ rocketMQ Kafka Hippo Tube 高可用 1：镜像队列。 2：集群。master/slave机制。 HA 同步双写和异步复制均支持 （同mafka） 1、中心节点：HA 高吞吐 性能 跟cpu 密切相关，5000是4核，5000左右。具体见 rabbitmq基准性能测试 异步刷盘 单机7万qps， 三台机器12万（网测） （同mafka） 未提及 单个Tube集群可稳定承载5w以上的客户端（生产者/消费者）数量，单台broker并发写入量可达10w TPS，使用1k大小的消息测试（机器配置：12核2.1GHz CPU带超线程、64G内存，Raid 5级磁盘阵列）时，可跑满千兆网卡带宽；Tube在绝大多数场景下可以将消息的延迟限制在毫秒级。 多机房部署 公司内无，shovel等插件支持 待确认 无 支持多 DC 部署 无 多机房容灾 公司内无，shovel等插件支持无 无 mirror maker 未提及 无 高可靠 事务性， 1：producer->broker，producer 回ack的时候会在刷到盘或者消费者消费到回ack。并且会持久化 2：broker->consumer, 有确认机制。也会持久化，但是消费完会删除数据。 异步复制可保证99%的消息不丢失，通过同步双写技术可以完全避免单点，同步双写会对性能有一定的影响

消息队列（MQ）是目前系统架构中主流方式，在大型系统及大数据中广泛采用。对任何架构或应用来说， MQ都是一个至关重要的组件。今天我们就来细数MQ那些不得不说的好处。 好处一：解耦 在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 比如我们的货款抵扣业务场景，用户生成订单发送MQ后立即返回，结算系统去消费该MQ进行用户账户金额的扣款。这样订单系统只需要关注把订单创建成功，最大可能的提高订单量，并且生成订单后立即返回用户。而结算系统重点关心的是账户金额的扣减，保证账户金额最终一致。 好处二：冗余 有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。MQ把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多MQ所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。 好处三：扩展性 因为MQ解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。就比如DMS分布式消息服务，不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。 好处四

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消息服务，常用消息中间件（Active MQ，Rabbit MQ，Zero MQ，Kafka）。【第二篇的内容大部分为网络资源的整理和汇总，供大家学习总结使用，最后有文章来源】 本次分享大纲 消息队列概述（见第一篇： 大型网站架构系列：分布式消息队列（一） ） 消息队列应用场景（见第一篇： 大型网站架构系列：分布式消息队列（一） ） 消息中间件示例（见第一篇： 大型网站架构系列：分布式消息队列（一） ） JMS消息服务 常用消息队列 参考（推荐）资料 本次分享总结 四、JMS消息服务 讲消息队列就不得不提JMS 。JMS（JAVA Message Service,java消息服务）API是一个消息服务的标准/规范，允许应用程序组件基于JavaEE平台创建、发送、接收和读取消息。它使分布式通信耦合度更低，消息服务更加可靠以及异步性。 在EJB架构中，有消息bean可以无缝的与JM消息服务集成。在J2EE架构模式中，有消息服务者模式，用于实现消息与应用直接的解耦。 4.1消息模型 在JMS标准中，有两种消息模型P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。 4.1.1 P2P模式 P2P模式包含三个角色：消息队列（Queue），发送者(Sender)，接收者(Receiver)

之前写过关于ActiveMQ的学习笔记,然后面试时被问到MQ时依然不知道从哪开始说起,并且我发现即使写了ActiveMQ相关的学习笔记,然后并没什么卵用,依然忘的比较彻底. 然后我就意识到我的学习方法不太对,因为我对于MQ的认识只是停留在了很浅的一个层面,只是简单的认为它是一个存储消息的容器,需要用到的时候对MQ进行存取操作就行了. 然而如果我先从MQ开始入手学习,在学习ActiveMQ或者RabbitMQ时,我只需要记住他们的一些特点即可,这样会轻松很多并且更容易理解,所以这篇文章也是学习MQ的笔记. 参考链接 关于MQ的几件小事 MQ(message queue)的概念: 消息的传输过程中的保存消息的容器. MQ的优势: 1.解耦: 可以举个例子,例如当用户下单后,同时需要进行的步骤有在库存系统中将库存减一,客户系统中该用户的信息更新,订单系统需要生成一个订单等等, 假设没有MQ的话,需要分别调用库存系统,客户系统,订单系统中的方法,将数据作为参数传入,这就造成了比较强的依赖性,三个系统中也有大量的业务逻辑代码,**多个不相关系统因为需要同一个参数聚集到了一起,**只要出现一个问题就会导致其他系统都受影响. 而通过MQ则只需要1步,将消息发送到MQ中即可,这样的话大大降低了代码的耦合度,即使库存系统出现错误也不会影响到其他模块. 2.异步: 还是上面的例子,如果没有MQ