metaq杂记

Name Server：维护broker的地址列表，以及topic和topic对应的队列的地址列表。每个broker与每个Name Server之间使用长连接来保持心跳，并向其定时注册topic信息。可以从两个维度来理解Name Server的能力： 1）Name Server可以提供一个特定的topic对应的broker地址列表；2）Name Server可以提供一台broker上包含的所有topic列表。轻量级的名称服务。几乎无状态的节点，相互之间不会有数据同步。 主要提供topic路由信息的注册及查询。（MetaQ 1.x和MetaQ 2.x是依赖ZooKeeper的，由于ZooKeeper功能过重，RMetaQ 3.x去掉了对ZooKeeper依赖，采用自己的NameServer）

Producer和集群中某一个Name Server间采用长连接，Producer定期从Name Server中获取到Topic对应的broker地址列表，即Topic路由信息，并缓存在本地，然后选择一台合适的master broker发布消息。 注意producer发布消息是将消息发布到与对应的master broker上，再由master broker同步到slave broker上。

Consumer和集群中某一个Name Server间采用长连接，并定期从Name Server中获取到Topic路由信息，然后选择合适的broker拉取消息进行消费。

在 Metaq2.x 之前版本，队列也称为“分区”，两者描述的是一个概念。 但是按照 2.x 的实现，使用队列描 述更合适。

数据存储分为两级，物理队列+逻辑队列。
物理队列：一个broker只有一个物理队列，所有发到broker的数据都会顺序写入该队列，当一个文件被写满时（默认为1G），会新建文件继续写入。
逻辑队列：当consumer消费数据时，consumer先根据nameServer提供的路由信息定位到broker，再从broker的消费队列读取index，从而定位到物理队列的位置。一个topic有多个分区，每个分区对应一个消费队列，而消费队列由index组成。

commitlog消息文件：broker在接收到生产者发送来的消息后，是如何对其进行存储的呢？在MetaQ中，真正的消息本身实际上是存放在broker本地一个名为commitlog的文件中的，并且这个commitlog的写入是不区分Topic的，即不论什么Topic的消息，都会在接收到之后顺序写入commitlog文件中，commitlog的文件名就是起始字节位置 写满后，产生一个新的文件。

索引文件：读取的时候又是怎么从commitlog中找到消息的呢？的确，仅仅只存储消息本身是无法做到这个的（因为在仅有commitlog文件的前提下，消息的长度、类型等信息都是无法确定的），所以MetaQ还有索引文件（在一些文档中也称为Message Queue）。broker将消息存储到commitlog文件后，会将该消息在文件的物理位置（offset），消息大小，消息类型等信息封装成一个固定大小的数据结构，称为索引单元。其中，offset是java long型，有64位，从理论上讲，offset在100年内都不会发生溢出，所以可以认为message queue长度无限。从而简单地，可以把message queue理解为是一个长度无限的数组，offset就是下标。多个索引单元组成一个索引文件，和commitlog文件一样，文件名是起始字节位置，写满后，产生一个新的文件。

broker 将消息存储到文件后,会将该消息在文件的物理位置,消息大小,消息类型封装成一个固定大 小的数据结构,暂且称这个数据结构为索引单元吧,大小固定为 16k,消息在物理文件的位置称为 offset。
多个索引单元组成了一个索引文件,索引文件默认固定大小为 20M,和消息文件一样,文件名是 起始字节位置,写满后,产生一个新的文件。

metaq的消息存储由commit log和逻辑队列consume queue配合完成。 首先会将所有的消息分topic存在commit log文件中，commit log文件最大为1G，超过1G会生成新文件，文件以起始字节大小命名。consume queue逻辑队列相当于是commit log文件的索引，记录offset偏移量，size长度，消息的hashcode等信息。物理队列只有一个(也就是commit log文件)，采用固定大小的文件顺序存储消息。逻辑队列有多个(每个对应一个topic)，每个逻辑队列有多个分区(topicA_1分区，topicA_2分区，topicA_3分区)，每个分区有多个索引单元。MetaQ中将每一个Topic分为了几个区，每个区对应了一个消费队列，这些消费队列就由各个索引文件组成。消费端在拉取消息时，只要知道自己是订阅的Topic从nameserver获取broker地址建立连接后，就能根据消费队列中的索引文件，去物理队列中获取订阅的消息。如下图所示，topicA在broker1 和 broker2分别有topicA_1分区, topicA_2分区；topicA_3 分区，topicA_4 分区。每个分区里存是的commit log文件的索引信息。消费信息时，需要通过索引信息，到commit log文件中获取真正的数据信息进行消费。仔细观察图metaq_arch_1/2/3.png

offset：这个概念其实放在这里讲略微有些早了，可以在了解完MetaQ 的消息生产模型之后再来了解。两个“offset”，刚开始还是有点迷惑的，梳理之后才理出了头绪，于是这里把这两种offset拿出来专门加以区分。

  1. 消息存储过程中的offset： 这个offset就是指索引单元中的offset，它标志着消息在commitlog文件中的物理位置。这个offset的存在也是MetaQ能正确在commitlog文件中定位消息的前提和保障。
  2. 消息消费时的offset： 这个offset是指当前消息被消费到的位置（接下来从哪个位置开始消费），这个offset是消费者顺序消费消息的依据和保障。这个offset被存储在消费者本地、数据库，还会定时更新到broker中。消费者每次拉取请求就需要offset这个参数，如果没有这个offset，MetaQ就不能实现顺序读了。MetaQ文件目录下有两个文件用于持久化消费进度，每次将offset写入consumerOffset.json文件，然后备份到 consumerOffset.json.bak文件中。在代码实现上，offset的持久化实际上是存储进一个以Topic和groupId的组合字符串为key，以ConcurrentMap为value的ConcurrentMap，而这个value上的ConcurrentMap又是以queueId为key，以offset为value的。

对于某一特定Topic而言，brokerId和分区号组合起来就是一个有序的分区列表， 如Topic “hello”对应的有序分区列表为{A-0，A-1，B-0，B-1，B-2}，生产者生产消息实际上可以理解为是以topic下的分区为单位进行的，即生产者按照一定规则向“brokerId-分区号”组成的有序分区列表对应的分区发送消息。发送的规则可以定制，一般采用轮询的方式。
消息的存储就是借助之前介绍过的commitlog文件和索引文件来实现的。

消费者消费消息也是以topic下的分区为单位，分组内一个消费者对应消耗一个分区的消息。这样一来就出现以下两种情况：

  1. 一个Group中的消费者个数大于总的分区数目：在这种情况下，多出来的消费者空闲，不参与消费；
  2. 一个Group中的消费者个数小于总的分区数目：在这种情况下，有部分消费者需要承担额外的消费任务。

当Topic下的分区数足够大的时候，可以认为消费者负载是平均分配的。
于是，消息的拉取过程描述如下：
(1) 根据Topic和分区号找到对应的逻辑消费队列，记为A；
(2) 根据A和offset找到对应的待消费的索引位置，记为B；
(3) 从B开始，读取B所对应的commitlog文件中的消息放入消费者队列中，直到读取到的消息长度等于给定的maxSize。在这个过程中，offset同时后移更新。
(4) 返回结果，结果中包含更新后的offset值，并将offset保存下来作为下一次消费开始的位置标志。

首先，从以上截图可以验证：
(1) 一个broker上可以发布多个Topic（图中有TopicA、TopicB）
(2) 一个Topic下可以对应多个分区（图中TopicA下有0和1两个分区，TopicB下有0,1,2三个分区）
(3) commitlog文件是不区分Topic的消息存储文件，所有Topic下的消息都会顺序写到同一个commitlog文件中
(3) 不同的ConsumerGroup之间独立进行消息的消费，消费过程组间互不影响。不同的消费者分组有自己独有的消费队列。
可以看到，针对每一个ConsumerGroup，都维护有一个重试队列（RETRY Queue）和一个死信队列（DLQ Queue）。 其中，重试队列用于消费失败后的重试，并且设置有最大重试次数（默认是16次），死信队列存放多次重试后依旧无法消费的消息。消费者在消费消息的过程中，如果消费失败，则将这条消息加入到重试队列中，由重试线程继续进行重试消费，如果重试最大次数后还是消费失败，则将消息加入到死信队列中，加入到死信队列中的消息需要进行人工干预。在这个过程中，主线程继续往后推进，从而实现消息的乱序消费和相对顺序消费。

当前例子是PushConsumer用法，使用方式给用户感觉是消息从MetaQ服务器推到了应用客户端。 但是实际PushConsumer内部是使用长轮询Pull方式从MetaQ服务器拉消息，然后再回调用户Listener方法

RocketMQ消息有有序保证实例：

@Test
public void testQueueProducer() {
    try {
        MetaProducer producer = new MetaProducer(GROUP_NAME);
        //队列的并行度是15个
        producer.setDefaultTopicQueueNums(15);
        producer.start();
        // 设置tag是为了让消费端过滤不想要的tag
        String[] tags = new String[]{"TagA", "TagB", "TagC", "TagD", "TagE"};
        //do {
            for (int i = 0; i < 50000; i++) {
                // 保证订单ID相同的消息放在同一个队列中
                int orderId = i % 10;
                Message msg = new Message(TOPIC, tags[i % tags.length], "KEY" + i, ("Hello MetaQ " + i).getBytes());
                SendResult sendResult = producer.send(msg, new MessageQueueSelector() {
                    @Override
                    public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) {
                        //arg就是orderId
                        Integer id = (Integer) arg;
                        System.out.println(String.format("mq size=%d,arg=%d", mqs.size(), id));
                        // id即orderId取队列大小的模 目的就是设置订单相同放在一个队列中
                        int index = id % mqs.size();
                        System.out.println("index=" + index);
                        return mqs.get(index);
                    }
                }, orderId);
                System.out.println(sendResult);
            }
            Thread.sleep(10000l);
        //} while (true);

         producer.shutdown();
    } catch (Exception e) {
        e.printStackTrace();
    }
    // SendResult [sendStatus=SEND_OK, msgId=0A6549250000277400000AC0059D66F9, messageQueue=MessageQueue [topic=orderTestTopic, brokerName=taobaodaily-f, queueId=3], queueOffset=653]

}

@Test
public void testOrderConsumerQueue() throws MQClientException, InterruptedException {
    MetaPushConsumer consumer = new MetaPushConsumer(GROUP_NAME);

    consumer.subscribe(TOPIC, "TagB");

    consumer.registerMessageListener(new MessageListenerOrderly() {

        @Override
        public ConsumeOrderlyStatus consumeMessage(List<MessageExt> msgs, ConsumeOrderlyContext context) {
            context.setAutoCommit(true);
            try {
                System.out.println(Thread.currentThread().getName() + " Receive New Messages: " + new String(msgs.get(0).getBody(), "UTF-8"));
            } catch (Exception e) {
                e.printStackTrace();
            }

            return ConsumeOrderlyStatus.SUCCESS;
        }
    });

    consumer.start();

    System.out.println("Consumer Started.");

    Thread.sleep(10000l);
    // ConsumeMessageThread_7 Receive New Messages: Hello MetaQ 67

}

从输出结果可以看出mq size=8, 分布在两台机器上，brokerName=taobaodaily-05-tx, queueId=0/1/2/3, brokerName=taobaodaily-04-timer, queueId=0/1/2/3
总结
发送顺序消息无法利用集群FailOver特性
消费顺序消息的并行度依赖于队列数量
队列热点问题，个别队列由于哈希不均导致消息过多，消费速度跟不上，产生消息堆积问题
遇到消息失败的消息，无法跳过，当前队列消费暂停

发送消息负载均衡：发送消息通过轮询队列的方式 发送，每个队列接收平均的消息量。通过增加机器，可以水平扩展队列容量。 另外也可以自定义方式选择发往哪个队列。

订阅消息负载均衡：如果有 5 个队列，2 个 consumer，那么第一个 Consumer 消费 3 个队列，第二 consumer 消费 2 个队列。 这样即可达到平均消费的目的，可以水平扩展 Consumer 来提高消费能力。但是 Consumer 数量要小于等于队列数 量，如果 Consumer 超过队列数量，那么多余的 Consumer 将不能消费消息。

事务消息：
图transaction

  1. 发送方向 MQ 服务端发送消息；
  2. MQ Server 将消息持久化成功之后，向发送方 ACK 确认消息已经发送成功，此时消息为半消息。
  3. 发送方开始执行本地事务逻辑。
  4. 发送方根据本地事务执行结果向 MQ Server 提交二次确认（Commit 或是 Rollback），MQ Server 收到 Commit 状态则将半消息标记为可投递，订阅方最终将收到该消息；MQ Server 收到 Rollback 状态则删除半消息，订阅方将不会接受该消息。
  5. 在断网或者是应用重启的特殊情况下，上述步骤4提交的二次确认最终未到达 MQ Server，经过固定时间后 MQ Server 将对该消息发起消息回查。
  6. 发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
  7. 发送方根据检查得到的本地事务的最终状态再次提交二次确认，MQ Server 仍按照步骤4对半消息进行操作。
    事务消息发送对应步骤1、2、3、4，事务消息回查对应步骤5、6、7。

消息过滤：
(1). 在 Broker 端进行 Message Tag 比对，先遍历 Consume Queue，如果存储的 Message Tag 与订阅的 Message Tag 不符合，则跳过，继续比对下一个，符合则传输给 Consumer。注意：Message Tag 是字符串形式，ConsumeQueue 中存储的是其对应的 hashcode，比对时也是比对 hashcode。
(2). Consumer 收到过滤后的消息后，同样也要执行在 Broker 端的操作，但是比对的是真实的 Message Tag 字符串，而不是 Hashcode。

零拷贝原理：
图zero_copy_1,zero_copy_2
在broker向消费端发送消息时，若采用传统的IO方式b会从磁盘拷贝数据到页缓存->用户空间从页缓存读数据->用户空间再将数据写入socket缓存中->通过网络发送数据，显然这样做使得用户空间和内核空间产生了多余的读写。MetaQ采用零拷贝的方式，通过mmap的方式使得页缓存与用户空间缓存共享数据，之后直接将数据从页缓存中将数据传入socket缓存中加快效率。

metaq如何解决事务问题:一般分布式事务采用的kv存储方式，通过key寻找message,第二阶段的回滚或者提交需要修改消息状态；然而metaq第一阶段发送prepared消息，拿到offset,第二阶段通过offset访问消息，修改数据状态。通过offset访问更改数据的缺点是系统脏也过多。

消息无序性，如何保证其顺序性: 消息的有序消费是指按照消息发送的先后顺序消费。正常情况下，单线程下produder同一个topic（一个topic逻辑上是一个队列，物理上分为多个队列）下，metaq支持局部顺序消费。分两种顺序消费方式普通顺序消费和严格顺序消费。普通顺序消费，当一个broker宕机或者重启时，允许该部分消息延迟消费，其他broker照常消费；严格消费，当某broker宕机或者重启时，牺牲分布式的failover特性，整个集群都不能使用，大大降低服务可用性，目前使用场景中数据库binlog同步强依赖严格顺序消费，其他应用场景用普通顺序消费可满足。然而在平时的应用中，单线程producer几乎不可能，我们可以通过设计规避这个缺点。例如同一个订单需要发送的创建订单消息、订单付款消息、订单完成按消费顺序消费才有意义，按优先级发送消息（metaq按优先级发消息开销比较大，没有特意支持这个特性）同一个队列，优先级高的消息先发送，可以在消费端做异常情况的处理逻辑。

非顺序消息如何实现队列内并行:PullService根据rebalance结果从对应的队列中获取数据，并将其缓存到客户端本地内存，然后根据客户端设置规则（一次批量消费消息的数目）将数据分成多段派发给下游的消费线程。消费端一个队列只维护一个offset，消费成功后只提交最小的offset。将拉回来的数据分成了三段（0-10,10-20,20-30）分别派发给消费线程。 0-10,20-30这两部分数据消费完成，但10-20这段数据还未消费完成。提交服务端消费位点则为10(消费成功的是10和30)，知道这段数据消费完成提交位点才会为30。
PS：所以并发消费有可能出现重复消费的问题。如中间有部分数据一直没有被成功消费，此时重新负载，别的消费端拿到当前队列就会导致重复消费。

最佳实践
Producer最佳实践
1、每个消息在业务层面的唯一标识码，要设置到 keys 字段，方便将来定位消息丢失问题。由于是哈希索引，请务必保证 key 尽可能唯一，这样可以避免潜在的哈希冲突。
2、消息发送成功或者失败，要打印消息日志，务必要打印 sendresult 和 key 字段。
3、对于消息不可丢失应用，务必要有消息重发机制。例如：消息发送失败，存储到数据库，能有定时程序尝试重发或者人工触发重发。
4、某些应用如果不关注消息是否发送成功，请直接使用sendOneWay方法发送消息。

Consumer最佳实践
1、消费过程要做到幂等（即消费端去重）
2、尽量使用批量方式消费方式，可以很大程度上提高消费吞吐量。
3、优化每条消息消费过程

posted @ 2018-10-09 22:15  john8169  阅读(482)  评论(0)  编辑  收藏  举报