消息中间件学习-摘抄 _消息

2.02018.08.05 15:48*字数 3451阅读 22742评论 4喜欢 34
一、 MQ背景&选型
消息队列作为高并发系统的核心组件之一，能够帮助业务系统解构提升开发效率和系统稳定性。主要具有以下优势：
目前主流的MQ主要是、kafka、，相比于、kafka具有主要优势特性有：
? 支持事务型消息（消息发送和DB操作保持两方的最终一致性，和kafka不支持）
? 支持结合的多个系统之间数据最终一致性（多方事务，二方事务是前提）
? 支持18个级别的延迟消息（和kafka不支持）
? 支持指定次数和时间间隔的失败消息重发（kafka不支持，需要手动确认）
? 支持端tag过滤，减少不必要的网络传输（和kafka不支持）
? 支持重复消费（不支持，kafka支持）
、kafka、的详细对比，请参照下表格：
image.png
二、集群概述1. 集群部署结构
image.png
1) Name
Name 是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
2)
部署相对复杂，分为与Slave，一个可以对应多个Slave，但是一个Slave只能对应一个，与Slave的对应关系通过指定相同的 Name，不同的 Id来定义，为0表示，非0表示Slave 。也可以部署多个。
每个与Name 集群中的所有节点建立长连接，定时(每隔30s)注册Topic信息到所有Name。Name 定时(每隔10s)扫描所有存活的连接，如果Name 超过2分钟没有收到心跳，则Name 断开与的连接。
3)
与Name 集群中的其中一个节点(随机选择)建立长连接，定期从Name 取Topic路由信息，并向提供Topic服务的建立长连接，且定时向发送心跳。完全无状态，可集群部署。
每隔30s（由的al）从Name 获取所有topic队列的最新情况，这意味着如果不可用，最多30s能够感知，在此期间内发往的所有消息都会失败。
每隔30s（由中val决定）向所有关联的发送心跳，每隔10s中扫描所有存活的连接，如果在2分钟内没有收到心跳数据，则关闭与的连接。
4)
与Name 集群中的其中一个节点(随机选择)建立长连接，定期从Name 取Topic路由信息，并向提供Topic服务的、Slave建立长连接，且定时向、Slave发送心跳。既可以从订阅消息，也可以从Slave订阅消息，订阅规则由配置决定。
每隔30s从Name 获取topic的最新队列情况，这意味着不可用时，最多最需要30s才能感知。
每隔30s（由中val决定）向所有关联的发送心跳，每隔10s扫描所有存活的连接，若某个连接2分钟内没有发送心跳数据，则关闭连接；并向该 Group的所有发出通知，Group内的重新分配队列，然后继续消费。
当得到宕机通知后，转向slave消费，slave不能保证的消息100%都同步过来了，因此会有少量的消息丢失。但是一旦恢复，未同步过去的消息会被最终消费掉。
消费者对列是消费者连接之后（或者之前有连接过）才创建的。我们将原生的消费者标识由 {IP}@{消费者group}扩展为 {IP}@{消费者group}{topic}{tag}，（例如xxx.xxx.xxx.xxx@--zyk）。任何一个元素不同，都认为是不同的消费端，每个消费端会拥有一份自己消费对列（默认是对列数量*数量）。新挂载的消费者对列中拥有中的所有数据。
如果有需要，可以查看更多源码解析
三、如何支持分布式事务消息场景
A（存在DB操作）、B（存在DB操作）两方需要保证分布式事务一致性，通过引入中间层MQ，A和MQ保持事务一致性（异常情况下通过MQ反查A接口实现check），B和MQ保证事务一致（通过重试），从而达到最终事务一致性。
原理：大事务 = 小事务 + 异步
1. MQ与DB一致性原理（两方事务）
流程图
image.png