mq

脱离了业务的系统架构都是在纸上谈兵，真正在复杂业务场景而且还高并发的时候，那系统架构一定不是那么简单的，用个 redis，用 mq 就能搞定？当然不是，真实的系统架构搭配上业务之后，会比这种简单的所谓“高并发架构”要复杂很多倍。 可以分为以下 6 点： 系统拆分 缓存 MQ 分库分表 读写分离 ElasticSearch 系统拆分 将一个系统拆分为多个子系统，用 dubbo 来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，不也可以扛高并发么。 缓存 缓存，必须得用缓存。大部分的高并发场景，都是 读多写少 ，那你完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。毕竟人家 redis 轻轻松松单机几万的并发。所以你可以考虑考虑你的项目里，那些承载主要请求的 读场景，怎么用缓存来抗高并发 。 MQ MQ，必须得用 MQ。可能你还是会出现高并发写的场景，比如说一个业务操作里要频繁搞数据库几十次，增删改增删改，疯了。那高并发绝对搞挂你的系统，你要是用 redis 来承载写那肯定不行，人家是缓存，数据随时就被 LRU 了，数据格式还无比简单，没有事务支持。所以该用 mysql 还得用 mysql 啊。那你咋办？用 MQ 吧，大量的写请求灌入 MQ 里，排队慢慢玩儿， 后边系统消费后慢慢写 ，控制在 mysql 承载范围之内。所以你得考虑考虑你的项目里

MQ消息中间件，这几年逐渐火爆起来，用处越来越多， 消息、削峰限流等 。MQ一般遵循AMQP协议。AMQP，即Advanced Message Queuing Protocol，一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。 基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。 当前市面上常见的MQ有，ActiveMQ、RabbitMQ、Kafka、RocketMQ等。她们中有标准的MQ（遵循AMQP协议，如RabbitMQ），也有非标准的MQ（如Kafka）。 一、RabbitMQ 简介 RabbitMQ是一个开源的AMQP实现，服务器端用Erlang语言编写，支持多种客户端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。RabbitMQ有如下特点， 可靠性 （Reliability），RabbitMQ 使用一些机制来保证可靠性，如 持久化、传输确认、发布确认 。 灵活的路由 （Flexible Routing），在消息进入队列之前，通过 Exchange 来路由消息的。 消息集群 （Clustering），多个

之前网上看到很多写分布式事务的文章，不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。 所以这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是 TCC 分布式事务 一、业务场景介绍 咱们先来看看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。 那对一个订单支付之后，我们需要做下面的步骤： 更改订单的状态为“已支付” 扣减商品库存 给会员增加积分 创建销售出库单通知仓库发货 这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。 二、进一步思考 好，业务场景有了，现在我们要更进一步，实现一个 TCC 分布式事务的效果。 什么意思呢？也就是说，[1] 订单服务-修改订单状态，[2] 库存服务-扣减库存，[3] 积分服务-增加积分，[4] 仓储服务-创建销售出库单。 上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。 举个例子，现在订单的状态都修改为“已支付”了，结果库存服务扣减库存失败。那个商品的库存原来是 100 件，现在卖掉了 2 件，本来应该是 98 件了。 结果呢？由于库存服务操作数据库异常，导致库存数量还是 100。这不是在坑人么，当然不能允许这种情况发生了！ 但是如果你不用 TCC 分布式事务方案的话，就用个 Spring

RocketMQ 保证其高可用 RocketMQ 分布式集群是通过Master和Slave的配合达到高可用性的，Master 角色的 Broker 支持读和写，Slave 角色的 Broker 仅支持读，也就是 Producer 只能和 Master 角色的 Broker 连接写人消息；Consumer 可以连接 Master 角色的 Broker，也可以连接 Slave 角色的 Broker 来读取消息 消费端的高可用性 Master 不可用或者繁忙的时候，Consumer 会被自动切换到从 Slave 读。有了自动切换Consumer这种机制，当一个 Master 角色的机器出现故障后，Consumer 仍然可以从 Slave 读取消息，不影响Consumer 程序。这就达到了消费端的高可用性。 发送端的高可用性 在创建 Topic 的时候，把 Topic 的 MessageQueue 创建在多个 Broker 组上（相同Broker名称，不同brokerId的机器组成一个Broker组），这样当一个 Broker 组的 Master 不可用后，其他组的 Master 仍然可用，Producer 仍然可以发送消息。 Kafka 保证其高可用 Kafka 有多个 broker，每个broker 就是一个节点 KafKa每创建一个Topic，这个Topic

消息队列是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保消息的可靠传递。消息发布者只管把消息发布到MQ中而不用管谁来取，消息使用者只管从MQ中取消息而不管是谁发布的。这样发布者和使用者都不用知道对方的存在。 Redis Redis就是一个内存数据库，具有丰富的数据类型，当然也支持队列queue，redis支持数据持久化，主从集群。 Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。 Redis不仅仅支持简单的key-value类型的数据，同时还提供list,set,zset,hash等数据结构的存储。 Redis支持数据的备份，即master-slave模式的数据备份。 rabbitMQ 是一个专门做队列的框架，在队列方面要比redis队列性能要好，支持的功能会更多，消息的可靠性更强，可以根据路由规则去选择进入哪一个队列，做到更加细致的消息分发 所有MQ产品从模型抽象上来说都是一样的过程： 消费者订阅某个队列。生产者创建消息，然后发布到队列中，最后将消息发送到监听的消费者。 RabbitMQ架构 组件: Message(消息):RabbitMQ转发的二进制对象，包括Headers(头)、Properties(属性)和Data(数据),其中数据部分不是必要的； Producer(生产者):消息的生产者

git https://github.com/rabbitmq/erlang-rpm 通过yum安装很方便。 安装rabbitmq # In /etc/yum.repos.d/rabbitmq_erlang.repo [rabbitmq_erlang] name=rabbitmq_erlang baseurl=https://packagecloud.io/rabbitmq/erlang/el/7/$basearch repo_gpgcheck=1 gpgcheck=1 enabled=1 # PackageCloud's repository key and RabbitMQ package signing key gpgkey=https://packagecloud.io/rabbitmq/erlang/gpgkey https://dl.bintray.com/rabbitmq/Keys/rabbitmq-release-signing-key.asc sslverify=1 sslcacert=/etc/pki/tls/certs/ca-bundle.crt metadata_expire=300 [rabbitmq_erlang-source] name=rabbitmq_erlang-source baseurl=https://packagecloud.io

一、缘起 一切脱离业务的架构设计与新技术引入都是耍流氓。 引入一个技术之前，首先应该解答的问题是，这个技术解决什么问题。 就像微服务分层架构之前，应该首先回答，为什么要引入微服务，微服务究竟解决什么问题（详见《互联网架构为什么要做微服务？》）。 最近分享了几篇MQ相关的文章： 《MQ如何实现延时消息》 《MQ如何实现消息必达》 《MQ如何实现幂等性》 不少网友询问，究竟什么时候使用MQ，MQ究竟适合什么场景，故有了此文。 二、MQ是干嘛的 消息总线（Message Queue），后文称MQ，是一种跨进程的通信机制，用于上下游传递消息。 在互联网架构中，MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。 使用了MQ之后，消息发送上游只需要依赖MQ，逻辑上和物理上都不用依赖其他服务。 三、什么时候不使用消息总线 既然MQ是互联网分层架构中的解耦利器，那所有通讯都使用MQ岂不是很好？这是一个严重的误区，调用与被调用的关系，是无法被MQ取代的。 MQ的不足是： 1）系统更复杂，多了一个MQ组件 2）消息传递路径更长，延时会增加 3）消息可靠性和重复性互为矛盾，消息不丢不重难以同时保证 4）上游无法知道下游的执行结果，这一点是很致命的 举个栗子：用户登录场景，登录页面调用passport服务，passport服务的执行结果直接影响登录结果，此处的“登录页面”与

文章目录 一、概述 1. 什么是消息队列 2. 为什么要使用消息队列 3. RabbitMQ特点 二、安装 1. 安装Erlang 2. 安装RabbitMQ 三、RabbitMQ 1. 启动和关闭 2. 插件管理 3. 用户管理 4. 权限管理 5. vhost管理 6. 设置管理员权限 四、消息发送和接收 1. RabbitMQ消息发送和接收机制 2. AMQP 中的消息路由 3. Exchange与Queue关联绑定 4. Exchange 类型 （1）direct （2）fanout （3）topic 5. Client与Brocker进行连接 五、RabbitMQ镜像集群 1. 准备 2. 配置Cookie文件 3. 配置hosts文件 4. 组建集群 5. 节点类型 一、概述 1. 什么是消息队列 消息（Message）是指在应用间传送的数据。消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。 消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，由消息系统来确保消息的可靠传递。消息发布者只管把消息发布到 MQ 中而不用管谁来取，消息使用者只管从 MQ 中取消息而不管是谁发布的。这样发布者和使用者都不用知道对方的存在。 2. 为什么要使用消息队列 从上面的描述中可以看出消息队列是一种应用间的 异步协作机制

同步发送，最多发送 3 次 这里指的是发送成功，等待 broker 的响应时发生超时，客户端有理由认为是网络不好，数据没有到达 broker，因此重复发送消息，也就是这种情况会导致 broker 存在重复消息。当发生 RemotingException 或 MQClientException 时，会重复发送。 // org.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl#sendDefaultImpl int timesTotal = communicationMode == CommunicationMode.SYNC ? 1 + this.defaultMQProducer.getRetryTimesWhenSendFailed() : 1; for (; times < timesTotal; times++) { try { SendResult sendResult = this.sendKernelImpl(msg, mq, communicationMode, sendCallback, topicPublishInfo, timeout - costTime); } catch (RemotingException e) { endTimestamp = System