metaq

metaq 笔记

MetaQ是一款分布式、队列模型的消息中间件

1.metaq的特点

支持严格的消息顺序
支持Topic与Queue两种模式
亿级消息堆积能力
比较友好的分布式特性
同时支持Push与Pull方式消费消息

2.几个概念

• Producer 产生消息，发送（push）到metaq服务器中。
  （ProducerGroup 生产者集群，一组group下的生产者生产一类信息，相同发送逻辑）
• Consumer 消费从服务器中pull来的消息。
  （ConsumerGroup 消费者集群，一组group下的消费者消费一类信息，消费逻辑相同）（同一个Consumer Group下的多个实例，订阅关系（相同Topic，相同Tag）必须相同）
• Broker metaq的服务器，来存储产生的消息，转发要消费的消息
• NameSever metaq的分布式是通过nameserver来支持的
• Message 消息实体，带有 topic，tag，key三个属性
  生产者将消息（message）发送到一个topic下，消费者集群消费同一类topic下的消息,消费指定topic下tags的消息。（一个Consumer可以订阅多个topic）
  
  • topic 消息的主题，标识了一类消息。
  • tag 用于消息过滤，订阅方可以根据tag来选择消费或是过滤
  • key 对消息的唯一标识，以便于看看队列中的消息接收状态

3.metaq架构

Broker分为master和slave。每个Broker与nameserver集群中的所有节点建立长连接，定时注册topic信息到所有的nameServer。一类消息以主题topic形式 存在broker当中。

Producer与nameServer集群中的一个节点（随机）建立长连接，定期从nameServer 取topic路由信息，并向提供topic服务的master broker建立长连接，且定时向master发送心跳。Producer发布消息是发布到master，在由master同步到所有broker。

Consumer与nameServer集群中的一个节点建立长连接，定期从nameServer取topic的路由信息，并向提供topic服务的master、slave broker建立长连接，并定时向master、slave发送心跳。因为发布的消息已经有master同步到slave，broker中都存有相关topic消息，Comsumer既可以从slave订阅消息，也可以从master订阅消息。

4.PushConsumere和PullConsumer

• PushConsumer内部是使用长轮询+Pull方式从MetaQ服务器拉消息，然后再回调用户Listener方法.其实质上还是pull方式,加上长轮询 实现了类似 可见的push的结果。

• PullConsumer 是主动去拉取队列中的消息，需要提供offset（消息存储在broker中，是以分区的形式存在的，一个topic下对应多个分区，每个分区组织成一个文件列表，offset就是用来表示数据在文件中的偏移量）。也可以认为 Message Queue 是一个长度无限的数组，offset 就是下标。

5.Topic与Queue两种模式

queue 模式，通过队列选择（queueSelector）是将不同规则的数据消息有序的放到不同队列当中，并且按照发送的顺序有序地消费。

6.发送普通消息

步骤：
1 创建一个Producer，由应用来维护此对象，可以设置为全局对象或者单例，在创建时需要指定 ProducerGroupName，它需要由应用来保证唯一。
2 Producer.start(). （Producer对象在使用之前必须要调用start初始化，初始化一次即可）
3 创建Message对象，指定 topic,tag,key body
4 producer.send(message)
5.producer.shutdown() （应用退出时，关闭资源）

7.订阅普通消息

1 创建一个PushConsumer，并设定它的ConsumerGroup
2 设置该consumer的订阅的topic和tag
3 设定接收到消息的回调方法
4 设定批量接收消息的数量，默认为1 。当设定超过1的数值，即为批量消费模式。这些消费要么全部成功，要么全部失败
5 启动consumer，如果有消息到达，则会调用回调方法

8.主动pull

1 创建MetaPullConsumer对象，并指定consumerGroup
2 启动consumer
3 设定topic，并拉取topic队列中的消息，这里需要指定读取的offset信息

metaq和notify

• metaq
  
  • 基于消息队列
  • metaq 保证消息的严格有序执行。
  • metaq采用pull模式(客户端主动去服务器拉取数据，给客户端有了很大的主动性，可以根据自己的情况选择去拉取消息的时机和速度)， 同时长轮询的方式保证消息消费的延迟在几毫秒到几秒之间 数据,保证了消息的实时性。
  • 消息队列都是持久化的，metaq收到消息后把消息写入磁盘里，写入成功后消费者再去消费（内存中的数据属于非持久化数据）
  • 消息堆积能力强，
  • 支持push和pull两种消费模式。

• notify

  • 基于JMS模型
  • 不能够保证消息有序执行
  • 采用push模式（服务器主动推送数据）这样做保证了消息较高的实时性
  • 支持分布式事务，适用于较复杂的交易业务。
  • notify可以选择持久化和非持久化。

• 两者相比下，notify采用 push模式服务器主动去推送数据，服务端保存向客户端push成功或失败的状态，保证事务能够正确执行、回滚，而metaq采用pull模式，客户端之间负载均衡、协调分配 主动去拉取消息，使用zookeeper作为协调分配机制，服务器的压力就很小，专注于消息堆积能力。

• 两者缺点：消息重复。metaq的消息重复包括：生产者重复发消息和消费者重复消费消息，它只能保证在正常情况下不重复，异常情况无法保证，notify也不能避免消息重复的问题，目前去重的方法有：1.在数据库使用“去重表”；2.业务方事先操作幂等，这种方案是最好的；

JMS模型：

JMS（JAVA Message Service,java消息服务）API是一个消息服务的标准或者说是规范，允许应用程序组件基于JavaEE平台创建、发送、接收和读取消息。它使分布式通信耦合度更低，消息服务更加可靠以及异步性。

2:JMS消息通常有两种类型：
A: 点对点（Point-to-Point）。
生产者 将生产的消放到队列中，消息一直保留在 队列 当中，直到被消费或是超时。一个消息只能被一个 消费者 消费，一旦被消费，消息将离开队列。消费成功后，需要向队列应答成功。
B:发布/订阅（Publish/Subscribe）。消息发布者发送到主题，一个或多个 订阅者 来消费相关的 主题topic 的信息。在发布者和订阅者之间存在时间依赖性。所谓依赖，必须创建了一个订阅者后，发布者发布的额消息才能被消费，同时 订阅者必须保持运行连接的状态才能接收到消息。为了缓解这样的时间依赖，JMS允许 订阅者建立了持久的订阅。在那种情况下，在订阅者未连接时发布的消息将在订阅者重新连接时重新发布。

长轮询：

客户端向服务器发送Ajax请求，服务器接到请求后hold住连接，直到有新消息才返回响应信息并关闭连接，客户端处理完响应信息后再向服务器发送新的请求。

Ext.Ajax.request({ 
                    url : ‘LongPoll’, 
                    timeout:360000,//延长超时 
                    success : function(response, opts) { 
                        console.log(‘finish’); 
                        dorq(); 
                    }, 
                    failure : function(response, opts) { 
                        console.log(‘server-side failure with status code ‘ 
                                + response.status); 
                    } 
                });