hbn1326317071

rocketmq总结(消息的顺序、重复、事务、消费模式)

转自：
https://www.cnblogs.com/xuwc/p/9034352.htm

RocketMQ消息重复消费（同一条消息2毫秒内分别在两台机器上被消费）
https://yq.aliyun.com/ask/325536

参考：

http://www.cnblogs.com/wxd0108/p/6038543.html

https://www.cnblogs.com/520playboy/p/6750023.html

https://blog.csdn.net/chunlongyu/article/details/53977819

https://blog.csdn.net/zhanglianhai555/article/details/77604582?ref=myrecommend#

https://blog.csdn.net/dancheren/article/details/71323936

分布式开放消息系统(RocketMQ)的原理与实践

分布式消息系统作为实现分布式系统可扩展、可伸缩性的关键组件，需要具有高吞吐量、高可用等特点。而谈到消息系统的设计，就回避不了两个问题：

消息的顺序问题

消息的重复问题

RocketMQ作为阿里开源的一款高性能、高吞吐量的消息中间件，它是怎样来解决这两个问题的？RocketMQ 有哪些关键特性？其实现原理是怎样的？

关键特性以及其实现原理

一、顺序消息

消息有序指的是一类消息消费时，能按照发送的顺序来消费。例如：一个订单产生了 3 条消息，分别是订单创建、订单付款、订单完成。消费时，要按照这个顺序消费才有意义。但同时订单之间又是可以并行消费的。

假如生产者产生了2条消息：M1、M2，要保证这两条消息的顺序，应该怎样做？你脑中想到的可能是这样：

你可能会采用这种方式保证消息顺序

M1发送到S1后，M2发送到S2，如果要保证M1先于M2被消费，那么需要M1到达消费端后，通知S2，然后S2再将M2发送到消费端。

这个模型存在的问题是，如果M1和M2分别发送到两台Server上，就不能保证M1先达到，也就不能保证M1被先消费，那么就需要在MQ Server集群维护消息的顺序。那么如何解决？一种简单的方式就是将M1、M2发送到同一个Server上：

保证消息顺序，你改进后的方法

这样可以保证M1先于M2到达MQServer（客户端等待M1成功后再发送M2），根据先达到先被消费的原则，M1会先于M2被消费，这样就保证了消息的顺序。

这个模型，理论上可以保证消息的顺序，但在实际运用中你应该会遇到下面的问题：

网络延迟问题

只要将消息从一台服务器发往另一台服务器，就会存在网络延迟问题。如上图所示，如果发送M1耗时大于发送M2的耗时，那么M2就先被消费，仍然不能保证消息的顺序。即使M1和M2同时到达消费端，由于不清楚消费端1和消费端2的负载情况，仍然有可能出现M2先于M1被消费。如何解决这个问题？将M1和M2发往同一个消费者即可，且发送M1后，需要消费端响应成功后才能发送M2。

但又会引入另外一个问题，如果发送M1后，消费端1没有响应，那是继续发送M2呢，还是重新发送M1？一般为了保证消息一定被消费，肯定会选择重发M1到另外一个消费端2，就如下图所示。

保证消息顺序的正确姿势

这样的模型就严格保证消息的顺序，细心的你仍然会发现问题，消费端1没有响应Server时有两种情况，一种是M1确实没有到达，另外一种情况是消费端1已经响应，但是Server端没有收到。如果是第二种情况，重发M1，就会造成M1被重复消费。也就是我们后面要说的第二个问题，消息重复问题。

回过头来看消息顺序问题，严格的顺序消息非常容易理解，而且处理问题也比较容易，要实现严格的顺序消息，简单且可行的办法就是：

保证生产者 - MQServer - 消费者是一对一对一的关系

但是这样设计，并行度就成为了消息系统的瓶颈（吞吐量不够），也会导致更多的异常处理，比如：只要消费端出现问题，就会导致整个处理流程阻塞，我们不得不花费更多的精力来解决阻塞的问题。

但我们的最终目标是要集群的高容错性和高吞吐量。这似乎是一对不可调和的矛盾，那么阿里是如何解决的？

世界上解决一个计算机问题最简单的方法：“恰好”不需要解决它！

有些问题，看起来很重要，但实际上我们可以通过合理的设计或者将问题分解来规避。如果硬要把时间花在解决它们身上，实际上是浪费的，效率低下的。从这个角度来看消息的顺序问题，我们可以得出两个结论：

1、不关注乱序的应用实际大量存在
2、队列无序并不意味着消息无序

最后我们从源码角度分析RocketMQ怎么实现发送顺序消息。

一般消息是通过轮询所有队列来发送的（负载均衡策略），顺序消息可以根据业务，比如说订单号相同的消息发送到同一个队列。下面的示例中，OrderId相同的消息，会发送到同一个队列：

// RocketMQ默认提供了两种MessageQueueSelector实现：随机/Hash
SendResult sendResult = producer.send(msg, new MessageQueueSelector() {
    @Override
    public MessageQueue select(List mqs, Message msg, Object arg) {
        Integer id = (Integer) arg;
        int index = id % mqs.size();
        return mqs.get(index);
    }
}, orderId);

在获取到路由信息以后，会根据MessageQueueSelector实现的算法来选择一个队列，同一个OrderId获取到的队列是同一个队列。

private SendResult send()  {
    // 获取topic路由信息
    TopicPublishInfo topicPublishInfo = this.tryToFindTopicPublishInfo(msg.getTopic());
    if (topicPublishInfo != null && topicPublishInfo.ok()) {
        MessageQueue mq = null;
        // 根据我们的算法，选择一个发送队列
        // 这里的arg = orderId
        mq = selector.select(topicPublishInfo.getMessageQueueList(), msg, arg);
        if (mq != null) {
            return this.sendKernelImpl(msg, mq, communicationMode, sendCallback, timeout);
        }
    }
}

二、消息重复

上面在解决消息顺序问题时，引入了一个新的问题，就是消息重复。那么RocketMQ是怎样解决消息重复的问题呢？还是“恰好”不解决。

造成消息的重复的根本原因是：网络不可达。只要通过网络交换数据，就无法避免这个问题。所以解决这个问题的办法就是不解决，转而绕过这个问题。那么问题就变成了：如果消费端收到两条一样的消息，应该怎样处理？

1、消费端处理消息的业务逻辑保持幂等性
2、保证每条消息都有唯一编号且保证消息处理成功与去重表的日志同时出现

第1条很好理解，只要保持幂等性，不管来多少条重复消息，最后处理的结果都一样。第2条原理就是利用一张日志表来记录已经处理成功的消息的ID，如果新到的消息ID已经在日志表中，那么就不再处理这条消息。

我们可以看到第1条的解决方式，很明显应该在消费端实现，不属于消息系统要实现的功能。第2条可以消息系统实现，也可以业务端实现。正常情况下出现重复消息的概率不一定大，且由消息系统实现的话，肯定会对消息系统的吞吐量和高可用有影响，所以最好还是由业务端自己处理消息重复的问题，这也是RocketMQ不解决消息重复的问题的原因。

RocketMQ不保证消息不重复，如果你的业务需要保证严格的不重复消息，需要你自己在业务端去重。

三、事务消息

RocketMQ除了支持普通消息，顺序消息，另外还支持事务消息。首先讨论一下什么是事务消息以及支持事务消息的必要性。我们以一个转帐的场景为例来说明这个问题：Bob向Smith转账100块。

在单机环境下，执行事务的情况，大概是下面这个样子：

单机环境下转账事务示意图

当用户增长到一定程度，Bob和Smith的账户及余额信息已经不在同一台服务器上了，那么上面的流程就变成了这样：

集群环境下转账事务示意图

这时候你会发现，同样是一个转账的业务，在集群环境下，耗时居然成倍的增长，这显然是不能够接受的。那我们如何来规避这个问题？

大事务 = 小事务 + 异步

将大事务拆分成多个小事务异步执行。这样基本上能够将跨机事务的执行效率优化到与单机一致。转账的事务就可以分解成如下两个小事务：

小事务+异步消息

图中执行本地事务（Bob账户扣款）和发送异步消息应该保持同时成功或者失败中，也就是扣款成功了，发送消息一定要成功，如果扣款失败了，就不能再发送消息。那问题是：我们是先扣款还是先发送消息呢？

首先我们看下，先发送消息，大致的示意图如下：

事务消息：先发送消息

存在的问题是：如果消息发送成功，但是扣款失败，消费端就会消费此消息，进而向Smith账户加钱。

先发消息不行，那我们就先扣款呗，大致的示意图如下：

事务消息-先扣款

存在的问题跟上面类似：如果扣款成功，发送消息失败，就会出现Bob扣钱了，但是Smith账户未加钱。

可能大家会有很多的方法来解决这个问题，比如：直接将发消息放到Bob扣款的事务中去，如果发送失败，抛出异常，事务回滚。这样的处理方式也符合“恰好”不需要解决的原则。RocketMQ支持事务消息，下面我们来看看RocketMQ是怎样来实现的。

RocketMQ实现发送事务消息

RocketMQ第一阶段发送Prepared消息时，会拿到消息的地址，第二阶段执行本地事物，第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。细心的你可能又发现问题了，如果确认消息发送失败了怎么办？RocketMQ会定期扫描消息集群中的事物消息，这时候发现了Prepared消息，它会向消息发送者确认，Bob的钱到底是减了还是没减呢？如果减了是回滚还是继续发送确认消息呢？RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。

那我们来看下RocketMQ源码，是不是这样来处理事务消息的。客户端发送事务消息的部分（完整代码请查看：rocketmq-example工程下的com.alibaba.rocketmq.example.transaction.TransactionProducer）：

// 未决事务，MQ服务器回查客户端
// 也就是上文所说的，当RocketMQ发现`Prepared消息`时，会根据这个Listener实现的策略来决断事务
TransactionCheckListener transactionCheckListener = new TransactionCheckListenerImpl();
// 构造事务消息的生产者
TransactionMQProducer producer = new TransactionMQProducer("groupName");
// 设置事务决断处理类
producer.setTransactionCheckListener(transactionCheckListener);
// 本地事务的处理逻辑，相当于示例中检查Bob账户并扣钱的逻辑
TransactionExecuterImpl tranExecuter = new TransactionExecuterImpl();
producer.start()
// 构造MSG，省略构造参数
Message msg = new Message(......);
// 发送消息
SendResult sendResult = producer.sendMessageInTransaction(msg, tranExecuter, null);
producer.shutdown();

接着查看sendMessageInTransaction方法的源码，总共分为3个阶段：发送Prepared消息、执行本地事务、发送确认消息。

public TransactionSendResult sendMessageInTransaction(.....)  {
    // 逻辑代码，非实际代码
    // 1.发送消息
    sendResult = this.send(msg);
    // sendResult.getSendStatus() == SEND_OK
    // 2.如果消息发送成功，处理与消息关联的本地事务单元
    LocalTransactionState localTransactionState = tranExecuter.executeLocalTransactionBranch(msg, arg);
    // 3.结束事务
    this.endTransaction(sendResult, localTransactionState, localException);
}

endTransaction方法会将请求发往broker(mq server)去更新事物消息的最终状态：

根据sendResult找到Prepared消息
根据localTransaction更新消息的最终状态

如果endTransaction方法执行失败，导致数据没有发送到broker，broker会有回查线程定时（默认1分钟）扫描每个存储事务状态的表格文件，如果是已经提交或者回滚的消息直接跳过，如果是prepared状态则会向Producer发起CheckTransaction请求，Producer会调用DefaultMQProducerImpl.checkTransactionState()方法来处理broker的定时回调请求，而checkTransactionState会调用我们的事务设置的决断方法，最后调用endTransactionOneway让broker来更新消息的最终状态。

再回到转账的例子，如果Bob的账户的余额已经减少，且消息已经发送成功，Smith端开始消费这条消息，这个时候就会出现消费失败和消费超时两个问题？解决超时问题的思路就是一直重试，直到消费端消费消息成功，整个过程中有可能会出现消息重复的问题，按照前面的思路解决即可。

消费事务消息

这样基本上可以解决超时问题，但是如果消费失败怎么办？阿里提供给我们的解决方法是：人工解决。大家可以考虑一下，按照事务的流程，因为某种原因Smith加款失败，需要回滚整个流程。如果消息系统要实现这个回滚流程的话，系统复杂度将大大提升，且很容易出现Bug，估计出现Bug的概率会比消费失败的概率大很多。我们需要衡量是否值得花这么大的代价来解决这样一个出现概率非常小的问题，这也是大家在解决疑难问题时需要多多思考的地方。

20160321补充：在3.2.6版本中移除了事务消息的实现，所以此版本不支持事务消息，具体情况请参考rocketmq的issues：
https://github.com/alibaba/RocketMQ/issues/65
https://github.com/alibaba/RocketMQ/issues/138
https://github.com/alibaba/RocketMQ/issues/156

四、Producer如何发送消息

Producer轮询某topic下的所有队列的方式来实现发送方的负载均衡，如下图所示：

producer发送消息负载均衡

首先分析一下RocketMQ的客户端发送消息的源码：

// 构造Producer
DefaultMQProducer producer = new DefaultMQProducer("ProducerGroupName");
// 初始化Producer，整个应用生命周期内，只需要初始化1次
producer.start();
// 构造Message
Message msg = new Message("TopicTest1",// topic
                        "TagA",// tag：给消息打标签,用于区分一类消息，可为null
                        "OrderID188",// key：自定义Key，可以用于去重，可为null
                        ("Hello MetaQ").getBytes());// body：消息内容
// 发送消息并返回结果
SendResult sendResult = producer.send(msg);
// 清理资源，关闭网络连接，注销自己
producer.shutdown();

在整个应用生命周期内，生产者需要调用一次start方法来初始化，初始化主要完成的任务有：

如果没有指定namesrv地址，将会自动寻址

启动定时任务：更新namesrv地址、从namsrv更新topic路由信息、清理已经挂掉的broker、向所有broker发送心跳...

启动负载均衡的服务

初始化完成后，开始发送消息，发送消息的主要代码如下：

private SendResult sendDefaultImpl(Message msg,......) {
    // 检查Producer的状态是否是RUNNING
    this.makeSureStateOK();
    // 检查msg是否合法：是否为null、topic,body是否为空、body是否超长
    Validators.checkMessage(msg, this.defaultMQProducer);
    // 获取topic路由信息
    TopicPublishInfo topicPublishInfo = this.tryToFindTopicPublishInfo(msg.getTopic());
    // 从路由信息中选择一个消息队列
    MessageQueue mq = topicPublishInfo.selectOneMessageQueue(lastBrokerName);
    // 将消息发送到该队列上去
    sendResult = this.sendKernelImpl(msg, mq, communicationMode, sendCallback, timeout);
}

代码中需要关注的两个方法tryToFindTopicPublishInfo和selectOneMessageQueue。前面说过在producer初始化时，会启动定时任务获取路由信息并更新到本地缓存，所以tryToFindTopicPublishInfo会首先从缓存中获取topic路由信息，如果没有获取到，则会自己去namesrv获取路由信息。selectOneMessageQueue方法通过轮询的方式，返回一个队列，以达到负载均衡的目的。

如果Producer发送消息失败，会自动重试，重试的策略：

重试次数 < retryTimesWhenSendFailed（可配置）
总的耗时（包含重试n次的耗时） < sendMsgTimeout（发送消息时传入的参数）
同时满足上面两个条件后，Producer会选择另外一个队列发送消息

五、消息存储

RocketMQ的消息存储是由consume queue和commit log配合完成的。

1、Consume Queue

consume queue是消息的逻辑队列，相当于字典的目录，用来指定消息在物理文件`commit log`上的位置。

我们可以在配置中指定consume queue与commitlog存储的目录
每个topic下的每个queue都有一个对应的consumequeue文件，比如：

${rocketmq.home}/store/consumequeue/${topicName}/${queueId}/${fileName}

Consume Queue文件组织，如图所示：

Consume Queue文件组织示意图

根据topic和queueId来组织文件，图中TopicA有两个队列0,1，那么TopicA和QueueId=0组成一个ConsumeQueue，TopicA和QueueId=1组成另一个ConsumeQueue。
按照消费端的GroupName来分组重试队列，如果消费端消费失败，消息将被发往重试队列中，比如图中的%RETRY%ConsumerGroupA。
按照消费端的GroupName来分组死信队列，如果消费端消费失败，并重试指定次数后，仍然失败，则发往死信队列，比如图中的%DLQ%ConsumerGroupA。

死信队列（Dead Letter Queue）一般用于存放由于某种原因无法传递的消息，比如处理失败或者已经过期的消息。

Consume Queue中存储单元是一个20字节定长的二进制数据，顺序写顺序读，如下图所示：

consumequeue文件存储单元格式

CommitLog Offset是指这条消息在Commit Log文件中的实际偏移量
Size存储中消息的大小
Message Tag HashCode存储消息的Tag的哈希值：主要用于订阅时消息过滤（订阅时如果指定了Tag，会根据HashCode来快速查找到订阅的消息）

2、Commit Log

CommitLog：消息存放的物理文件，每台broker上的commitlog被本机所有的queue共享，不做任何区分。
文件的默认位置如下，仍然可通过配置文件修改：

${user.home} \store\${commitlog}\${fileName}

CommitLog的消息存储单元长度不固定，文件顺序写，随机读。消息的存储结构如下表所示，按照编号顺序以及编号对应的内容依次存储。

Commit Log存储单元结构图

3、消息存储实现

消息存储实现，比较复杂，也值得大家深入了解，后面会单独成文来分析，这小节只以代码说明一下具体的流程。

// Set the storage time
msg.setStoreTimestamp(System.currentTimeMillis());
// Set the message body BODY CRC (consider the most appropriate setting
msg.setBodyCRC(UtilAll.crc32(msg.getBody()));
StoreStatsService storeStatsService = this.defaultMessageStore.getStoreStatsService();
synchronized (this) {
    long beginLockTimestamp = this.defaultMessageStore.getSystemClock().now();
    // Here settings are stored timestamp, in order to ensure an orderly global
    msg.setStoreTimestamp(beginLockTimestamp);
    // MapedFile：操作物理文件在内存中的映射以及将内存数据持久化到物理文件中
    MapedFile mapedFile = this.mapedFileQueue.getLastMapedFile();
    // 将Message追加到文件commitlog
    result = mapedFile.appendMessage(msg, this.appendMessageCallback);
    switch (result.getStatus()) {
    case PUT_OK:break;
    case END_OF_FILE:
         // Create a new file, re-write the message
         mapedFile = this.mapedFileQueue.getLastMapedFile();
         result = mapedFile.appendMessage(msg, this.appendMessageCallback);
     break;
     DispatchRequest dispatchRequest = new DispatchRequest(
                topic,// 1
                queueId,// 2
                result.getWroteOffset(),// 3
                result.getWroteBytes(),// 4
                tagsCode,// 5
                msg.getStoreTimestamp(),// 6
                result.getLogicsOffset(),// 7
                msg.getKeys(),// 8
                /**
                 * Transaction
                 */
                msg.getSysFlag(),// 9
                msg.getPreparedTransactionOffset());// 10
    // 1.分发消息位置到ConsumeQueue
    // 2.分发到IndexService建立索引
    this.defaultMessageStore.putDispatchRequest(dispatchRequest);
}

4、消息的索引文件

如果一个消息包含key值的话，会使用IndexFile存储消息索引，文件的内容结构如图：

消息索引

索引文件主要用于根据key来查询消息的，流程主要是：

根据查询的 key 的 hashcode%slotNum 得到具体的槽的位置(slotNum 是一个索引文件里面包含的最大槽的数目，例如图中所示 slotNum=5000000)
根据 slotValue(slot 位置对应的值)查找到索引项列表的最后一项(倒序排列,slotValue 总是指向最新的一个索引项)
遍历索引项列表返回查询时间范围内的结果集(默认一次最大返回的 32 条记录)

六、消息订阅

RocketMQ消息订阅有两种模式，一种是Push模式，即MQServer主动向消费端推送；另外一种是Pull模式，即消费端在需要时，主动到MQServer拉取。但在具体实现时，Push和Pull模式都是采用消费端主动拉取的方式。

首先看下消费端的负载均衡：

消费端负载均衡

消费端会通过RebalanceService线程，10秒钟做一次基于topic下的所有队列负载：

遍历Consumer下的所有topic，然后根据topic订阅所有的消息
获取同一topic和Consumer Group下的所有Consumer
然后根据具体的分配策略来分配消费队列，分配的策略包含：平均分配、消费端配置等

如同上图所示：如果有 5 个队列，2 个 consumer，那么第一个 Consumer 消费 3 个队列，第二 consumer 消费 2 个队列。这里采用的就是平均分配策略，它类似于我们的分页，TOPIC下面的所有queue就是记录，Consumer的个数就相当于总的页数，那么每页有多少条记录，就类似于某个Consumer会消费哪些队列。

通过这样的策略来达到大体上的平均消费，这样的设计也可以很方面的水平扩展Consumer来提高消费能力。

消费端的Push模式是通过长轮询的模式来实现的，就如同下图：

Push模式示意图

Consumer端每隔一段时间主动向broker发送拉消息请求，broker在收到Pull请求后，如果有消息就立即返回数据，Consumer端收到返回的消息后，再回调消费者设置的Listener方法。如果broker在收到Pull请求时，消息队列里没有数据，broker端会阻塞请求直到有数据传递或超时才返回。

当然，Consumer端是通过一个线程将阻塞队列LinkedBlockingQueue中的PullRequest发送到broker拉取消息，以防止Consumer一致被阻塞。而Broker端，在接收到Consumer的PullRequest时，如果发现没有消息，就会把PullRequest扔到ConcurrentHashMap中缓存起来。broker在启动时，会启动一个线程不停的从ConcurrentHashMap取出PullRequest检查，直到有数据返回。

七、RocketMQ的其他特性

前面的6个特性都是基本上都是点到为止，想要深入了解，还需要大家多多查看源码，多多在实际中运用。当然除了已经提到的特性外，RocketMQ还支持：

定时消息
消息的刷盘策略
主动同步策略：同步双写、异步复制
海量消息堆积能力
高效通信
.......

其中涉及到的很多设计思路和解决方法都值得我们深入研究：

消息的存储设计：既要满足海量消息的堆积能力，又要满足极快的查询效率，还要保证写入的效率。
高效的通信组件设计：高吞吐量，毫秒级的消息投递能力都离不开高效的通信。
.......

RocketMQ最佳实践

一、Producer最佳实践

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

二、Consumer最佳实践

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

三、其他配置

线上应该关闭autoCreateTopicEnable，即在配置文件中将其设置为false。

RocketMQ在发送消息时，会首先获取路由信息。如果是新的消息，由于MQServer上面还没有创建对应的Topic，这个时候，如果上面的配置打开的话，会返回默认TOPIC的（RocketMQ会在每台broker上面创建名为TBW102的TOPIC）路由信息，然后Producer会选择一台Broker发送消息，选中的broker在存储消息时，发现消息的topic还没有创建，就会自动创建topic。后果就是：以后所有该TOPIC的消息，都将发送到这台broker上，达不到负载均衡的目的。

所以基于目前RocketMQ的设计，建议关闭自动创建TOPIC的功能，然后根据消息量的大小，手动创建TOPIC。

RocketMQ设计相关

RocketMQ的设计假定：

每台PC机器都可能宕机不可服务
任意集群都有可能处理能力不足
最坏的情况一定会发生
内网环境需要低延迟来提供最佳用户体验

RocketMQ的关键设计：

分布式集群化
强数据安全
海量数据堆积
毫秒级投递延迟（推拉模式）

这是RocketMQ在设计时的假定前提以及需要到达的效果。我想这些假定适用于所有的系统设计。随着我们系统的服务的增多，每位开发者都要注意自己的程序是否存在单点故障，如果挂了应该怎么恢复、能不能很好的水平扩展、对外的接口是否足够高效、自己管理的数据是否足够安全...... 多多规范自己的设计，才能开发出高效健壮的程序。

附录：RocketMQ涉及到的几个专业术语和整体架构介绍

一、RocketMQ中的专业术语

Topic
topic表示消息的第一级类型，比如一个电商系统的消息可以分为：交易消息、物流消息...... 一条消息必须有一个Topic。

Tag
Tag表示消息的第二级类型，比如交易消息又可以分为：交易创建消息，交易完成消息..... 一条消息可以没有Tag。RocketMQ提供2级消息分类，方便大家灵活控制。

Queue
一个topic下，我们可以设置多个queue(消息队列)。当我们发送消息时，需要要指定该消息的topic。RocketMQ会轮询该topic下的所有队列，将消息发送出去。

Producer 与 Producer Group
Producer表示消息队列的生产者。消息队列的本质就是实现了publish-subscribe模式，生产者生产消息，消费者消费消息。所以这里的Producer就是用来生产和发送消息的，一般指业务系统。

Producer Group是一类Producer的集合名称，这类Producer通常发送一类消息，且发送逻辑一致。

Consumer 与 Consumer Group
消息消费者，一般由后台系统异步消费消息。

Push Consumer
Consumer 的一种，应用通常向 Consumer 对象注册一个 Listener 接口，一旦收到消息，Consumer 对象立刻回调 Listener 接口方法。
Pull Consumer
Consumer 的一种，应用通常主动调用 Consumer 的拉消息方法从 Broker 拉消息，主动权由应用控制。

Consumer Group是一类Consumer的集合名称，这类Consumer通常消费一类消息，且消费逻辑一致。

Broker
消息的中转者，负责存储和转发消息。可以理解为消息队列服务器，提供了消息的接收、存储、拉取和转发服务。broker是RocketMQ的核心，它不不能挂的，所以需要保证broker的高可用。

广播消费
一条消息被多个Consumer消费，即使这些Consumer属于同一个Consumer Group，消息也会被Consumer Group中的每个Consumer都消费一次。在广播消费中的Consumer Group概念可以认为在消息划分方面无意义。

集群消费
一个Consumer Group中的Consumer实例平均分摊消费消息。例如某个Topic有 9 条消息，其中一个Consumer Group有 3 个实例(可能是 3 个进程,或者 3 台机器)，那么每个实例只消费其中的 3 条消息。

NameServer
NameServer即名称服务，两个功能：

接收broker的请求，注册broker的路由信息
接口client的请求，根据某个topic获取其到broker的路由信息
NameServer没有状态，可以横向扩展。每个broker在启动的时候会到NameServer注册；Producer在发送消息前会根据topic到NameServer获取路由(到broker)信息；Consumer也会定时获取topic路由信息。

二、RocketMQ Overview

rocketmq overview

Producer向一些队列轮流发送消息，队列集合称为Topic，Consumer如果做广播消费，则一个consumer实例消费这个Topic对应的所有队列；如果做集群消费，则多个Consumer实例平均消费这个Topic对应的队列集合。

再看下RocketMQ物理部署结构图：

RocketMQ网络部署图

RocketMQ网络部署特点：

Name Server 是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId=0表示Master，非0表示Slave。Master也可以部署多个。每个Broker与Name Server集群中的所有节点建立长连接，定时注册Topic信息到所有Name Server。
Producer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息，并向提供Topic 服务的Master建立长连接，且定时向Master发送心跳。Producer 完全无状态，可集群部署。
Consumer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic 路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。

RocketMQ事务消费和顺序消费详解

一、RocketMq有3中消息类型

1.普通消费

2. 顺序消费

3.事务消费

顺序消费场景

在网购的时候，我们需要下单，那么下单需要假如有三个顺序，第一、创建订单，第二：订单付款，第三：订单完成。也就是这个三个环节要有顺序，这个订单才有意义。RocketMQ可以保证顺序消费。

rocketMq实现顺序消费的原理

produce在发送消息的时候，把消息发到同一个队列（queue）中,消费者注册消息监听器为MessageListenerOrderly，这样就可以保证消费端只有一个线程去消费消息

注意：是把把消息发到同一个队列（queue），不是同一个topic，默认情况下一个topic包括4个queue

单个节点（Producer端1个、Consumer端1个）

1、Producer.java

package order;

import java.util.List;

import com.alibaba.rocketmq.client.exception.MQBrokerException;
import com.alibaba.rocketmq.client.exception.MQClientException;
import com.alibaba.rocketmq.client.producer.DefaultMQProducer;
import com.alibaba.rocketmq.client.producer.MessageQueueSelector;
import com.alibaba.rocketmq.client.producer.SendResult;
import com.alibaba.rocketmq.common.message.Message;
import com.alibaba.rocketmq.common.message.MessageQueue;
import com.alibaba.rocketmq.remoting.exception.RemotingException;

/**

Producer，发送顺序消息
*/
public class Producer {
public static void main(String[] args) {
try {
DefaultMQProducer producer = new DefaultMQProducer(“order_Producer”);
producer.setNamesrvAddr(“192.168.100.145:9876;192.168.100.146:9876;192.168.100.149:9876;192.168.100.239:9876”);

     producer.start();  

     // String[] tags = new String[] { "TagA", "TagB", "TagC", "TagD",  
     // "TagE" };  

     for (int i = 1; i <= 5; i++) {  

         Message msg = new Message("TopicOrderTest", "order_1", "KEY" + i, ("order_1 " + i).getBytes());  

         SendResult sendResult = producer.send(msg, new MessageQueueSelector() {  
             public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) {  
                 Integer id = (Integer) arg;  
                 int index = id % mqs.size();  
                 return mqs.get(index);  
             }  
         }, 0);  

         System.out.println(sendResult);  
     }  

     producer.shutdown();  
 } catch (MQClientException e) {  
     e.printStackTrace();  
 } catch (RemotingException e) {  
     e.printStackTrace();  
 } catch (MQBrokerException e) {  
     e.printStackTrace();  
 } catch (InterruptedException e) {  
     e.printStackTrace();  
 }

}
}

2、Consumer.java

package order;   
import java.util.List;  
import java.util.concurrent.TimeUnit;  
import java.util.concurrent.atomic.AtomicLong;   
import com.alibaba.rocketmq.client.consumer.DefaultMQPushConsumer;  
import com.alibaba.rocketmq.client.consumer.listener.ConsumeOrderlyContext;  
import com.alibaba.rocketmq.client.consumer.listener.ConsumeOrderlyStatus;  
import com.alibaba.rocketmq.client.consumer.listener.MessageListenerOrderly;  
import com.alibaba.rocketmq.client.exception.MQClientException;  
import com.alibaba.rocketmq.common.consumer.ConsumeFromWhere;  
import com.alibaba.rocketmq.common.message.MessageExt;

/**

顺序消息消费，带事务方式（应用可控制Offset什么时候提交）
*/
public class Consumer1 {

public static void main(String[] args) throws MQClientException {
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer(“order_Consumer”);
consumer.setNamesrvAddr(“192.168.100.145:9876;192.168.100.146:9876;192.168.100.149:9876;192.168.100.239:9876”);

 /** 
  * 设置Consumer第一次启动是从队列头部开始消费还是队列尾部开始消费<br> 
  * 如果非第一次启动，那么按照上次消费的位置继续消费 
  */  
 consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_FIRST_OFFSET);  

 consumer.subscribe("TopicOrderTest", "*");  

 consumer.registerMessageListener(new MessageListenerOrderly() {  
     AtomicLong consumeTimes = new AtomicLong(0);  

     public ConsumeOrderlyStatus consumeMessage(List<MessageExt> msgs, ConsumeOrderlyContext context) {  
         // 设置自动提交  
         context.setAutoCommit(true);  
         for (MessageExt msg : msgs) {  
             System.out.println(msg + ",内容：" + new String(msg.getBody()));  
         }  

         try {  
             TimeUnit.SECONDS.sleep(5L);  
         } catch (InterruptedException e) {  

             e.printStackTrace();  
         }  
         ;  

         return ConsumeOrderlyStatus.SUCCESS;  
     }  
 });  

 consumer.start();  

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

}

结果如下图所示：

这个五条数据被顺序消费了

多个节点（Producer端1个、Consumer端2个）

Producer.java

package order;

import java.util.List;

/**

     producer.start();  

     // String[] tags = new String[] { "TagA", "TagB", "TagC", "TagD",  
     // "TagE" };  

     for (int i = 1; i <= 5; i++) {  

         Message msg = new Message("TopicOrderTest", "order_1", "KEY" + i, ("order_1 " + i).getBytes());  

         SendResult sendResult = producer.send(msg, new MessageQueueSelector() {  
             public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) {  
                 Integer id = (Integer) arg;  
                 int index = id % mqs.size();  
                 return mqs.get(index);  
             }  
         }, 0);  

         System.out.println(sendResult);  
     }  
     for (int i = 1; i <= 5; i++) {  

         Message msg = new Message("TopicOrderTest", "order_2", "KEY" + i, ("order_2 " + i).getBytes());  

         SendResult sendResult = producer.send(msg, new MessageQueueSelector() {  
             public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) {  
                 Integer id = (Integer) arg;  
                 int index = id % mqs.size();  
                 return mqs.get(index);  
             }  
         }, 1);  

         System.out.println(sendResult);  
     }  
     for (int i = 1; i <= 5; i++) {  

         Message msg = new Message("TopicOrderTest", "order_3", "KEY" + i, ("order_3 " + i).getBytes());  

         SendResult sendResult = producer.send(msg, new MessageQueueSelector() {  
             public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) {  
                 Integer id = (Integer) arg;  
                 int index = id % mqs.size();  
                 return mqs.get(index);  
             }  
         }, 2);  

         System.out.println(sendResult);  
     }  

     producer.shutdown();  
 } catch (MQClientException e) {  
     e.printStackTrace();  
 } catch (RemotingException e) {  
     e.printStackTrace();  
 } catch (MQBrokerException e) {  
     e.printStackTrace();  
 } catch (InterruptedException e) {  
     e.printStackTrace();  
 }

}
}

Consumer1.java

/** 
 * 顺序消息消费，带事务方式（应用可控制Offset什么时候提交） 
 */  
public class Consumer1 {  
public static void main(String[] args) throws MQClientException {  
    DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("order_Consumer");  
    consumer.setNamesrvAddr("192.168.100.145:9876;192.168.100.146:9876;192.168.100.149:9876;192.168.100.239:9876");  

    /** 
     * 设置Consumer第一次启动是从队列头部开始消费还是队列尾部开始消费<br> 
     * 如果非第一次启动，那么按照上次消费的位置继续消费 
     */  
    consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_FIRST_OFFSET);  

    consumer.subscribe("TopicOrderTest", "*");  
      
    /** 
     * 实现了MessageListenerOrderly表示一个队列只会被一个线程取到  
     *，第二个线程无法访问这个队列 
     */  
    consumer.registerMessageListener(new MessageListenerOrderly() {  
        AtomicLong consumeTimes = new AtomicLong(0);  

        public ConsumeOrderlyStatus consumeMessage(List<MessageExt> msgs, ConsumeOrderlyContext context) {  
            // 设置自动提交  
            context.setAutoCommit(true);  
            for (MessageExt msg : msgs) {  
                System.out.println(msg + ",内容：" + new String(msg.getBody()));  
            }  

            try {  
                TimeUnit.SECONDS.sleep(5L);  
            } catch (InterruptedException e) {  

                e.printStackTrace();  
            }  
            ;  

            return ConsumeOrderlyStatus.SUCCESS;  
        }  
    });  

    consumer.start();  

    System.out.println("Consumer1 Started.");  
}

}

Consumer2.java

/** 
 * 顺序消息消费，带事务方式（应用可控制Offset什么时候提交） 
 */  
public class Consumer2 {  
public static void main(String[] args) throws MQClientException {  
    DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("order_Consumer");  
    consumer.setNamesrvAddr("192.168.100.145:9876;192.168.100.146:9876;192.168.100.149:9876;192.168.100.239:9876");  

    /** 
     * 设置Consumer第一次启动是从队列头部开始消费还是队列尾部开始消费<br> 
     * 如果非第一次启动，那么按照上次消费的位置继续消费 
     */  
    consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_FIRST_OFFSET);  

    consumer.subscribe("TopicOrderTest", "*");  
      
    /** 
     * 实现了MessageListenerOrderly表示一个队列只会被一个线程取到  
     *，第二个线程无法访问这个队列 
     */  
    consumer.registerMessageListener(new MessageListenerOrderly() {  
        AtomicLong consumeTimes = new AtomicLong(0);  

        public ConsumeOrderlyStatus consumeMessage(List<MessageExt> msgs, ConsumeOrderlyContext context) {  
            // 设置自动提交  
            context.setAutoCommit(true);  
            for (MessageExt msg : msgs) {  
                System.out.println(msg + ",内容：" + new String(msg.getBody()));  
            }  

            try {  
                TimeUnit.SECONDS.sleep(5L);  
            } catch (InterruptedException e) {  

                e.printStackTrace();  
            }  
            ;  

            return ConsumeOrderlyStatus.SUCCESS;  
        }  
    });  

    consumer.start();  

    System.out.println("Consumer2 Started.");  
}

}

先启动Consumer1和Consumer2，然后启动Producer，Producer会发送15条消息
Consumer1消费情况如图，都按照顺序执行了

Consumer2消费情况如图，都按照顺序执行了

二、事务消费

这里说的主要是分布式事物。下面的例子的数据库分别安装在不同的节点上。

事物消费需要先说说什么是事务。比如说：我们跨行转账，从工商银行转到建设银行，也就是我从工商银行扣除1000元之后，我的建设银行也必须加1000元。这样才能保证数据的一致性。假如工商银行转1000元之后，建设银行的服务器突然宕机，那么我扣除了1000，但是并没有在建设银行给我加1000，就出现了数据的不一致。因此加1000和减1000才行，减1000和减1000必须一起成功，一起失败。

再比如，我们进行网购的时候，我们下单之后，订单提交成功，仓库商品的数量必须减一。但是订单可能是一个数据库，仓库数量可能又是在另个数据库里面。有可能订单提交成功之后，仓库数量服务器突然宕机。这样也出现了数据不一致的问题。

使用消息队列来解决分布式事物：

现在我们去外面饭店吃饭，很多时候都不会直接给了钱之后直接在付款的窗口递饭菜，而是付款之后他会给你一张小票，你拿着这个小票去出饭的窗口取饭。这里和我们的系统类似，提高了吞吐量。即使你到第二个窗口，师傅告诉你已经没饭了，你可以拿着这个凭证去退款，即使中途由于出了意外你无法到达窗口进行取饭，但是只要凭证还在，可以将钱退给你。这样就保证了数据的一致性。

如何保证凭证（消息）有2种方法：

1、在工商银行扣款的时候，余额表扣除1000，同时记录日志，而且这2个表是在同一个数据库实例中，可以使用本地事物解决。然后我们通知建设银行需要加1000给该用户，建设银行收到之后给我返回已经加了1000给用户的确认信息之后，我再标记日志表里面的日志为已经完成。

2、通过消息中间件

原文地址：http://www.jianshu.com/p/453c6e7ff81c

RocketMQ第一阶段发送Prepared消息时，会拿到消息的地址，第二阶段执行本地事物，第三阶段通过第一阶段拿到的地址去访问消息，并修改消息的状态。

细心的你可能又发现问题了，如果确认消息发送失败了怎么办？RocketMQ会定期扫描消息集群中的事物消息，如果发现了Prepared消息，它会向消息发送端(生产者)确认，Bob的钱到底是减了还是没减呢？如果减了是回滚还是继续发送确认消息呢？RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。

例子：

Consumer.java

package transaction;

import java.util.List;

import com.alibaba.rocketmq.client.consumer.DefaultMQPushConsumer;
import com.alibaba.rocketmq.client.consumer.listener.ConsumeConcurrentlyContext;
import com.alibaba.rocketmq.client.consumer.listener.ConsumeConcurrentlyStatus;
import com.alibaba.rocketmq.client.consumer.listener.MessageListenerConcurrently;
import com.alibaba.rocketmq.client.exception.MQClientException;
import com.alibaba.rocketmq.common.consumer.ConsumeFromWhere;
import com.alibaba.rocketmq.common.message.MessageExt;

/**

Consumer，订阅消息
*/
public class Consumer {

public static void main(String[] args) throws InterruptedException, MQClientException {
DefaultMQPushConsumer consumer = new DefaultMQPushConsumer(“transaction_Consumer”);
consumer.setNamesrvAddr(“192.168.100.145:9876;192.168.100.146:9876;192.168.100.149:9876;192.168.100.239:9876”);
consumer.setConsumeMessageBatchMaxSize(10);
/**
* 设置Consumer第一次启动是从队列头部开始消费还是队列尾部开始消费

* 如果非第一次启动，那么按照上次消费的位置继续消费
*/
consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_FIRST_OFFSET);

 consumer.subscribe("TopicTransactionTest", "*");  

 consumer.registerMessageListener(new MessageListenerConcurrently() {  

     public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {  

         try {  

             for (MessageExt msg : msgs) {  
                 System.out.println(msg + ",内容：" + new String(msg.getBody()));  
             }  

         } catch (Exception e) {  
             e.printStackTrace();  

             return ConsumeConcurrentlyStatus.RECONSUME_LATER;// 重试  

         }  

         return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;// 成功  
     }  
 });  

 consumer.start();  

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

}
}

Producer.java

package transaction;

import com.alibaba.rocketmq.client.exception.MQClientException;
import com.alibaba.rocketmq.client.producer.SendResult;
import com.alibaba.rocketmq.client.producer.TransactionCheckListener;
import com.alibaba.rocketmq.client.producer.TransactionMQProducer;
import com.alibaba.rocketmq.common.message.Message;

/**

发送事务消息例子

*/
public class Producer {
public static void main(String[] args) throws MQClientException, InterruptedException {

    TransactionCheckListener transactionCheckListener = new TransactionCheckListenerImpl();  
    TransactionMQProducer producer = new TransactionMQProducer("transaction_Producer");  
    producer.setNamesrvAddr("192.168.100.145:9876;192.168.100.146:9876;192.168.100.149:9876;192.168.100.239:9876");  
    // 事务回查最小并发数  
    producer.setCheckThreadPoolMinSize(2);  
    // 事务回查最大并发数  
    producer.setCheckThreadPoolMaxSize(2);  
    // 队列数  
    producer.setCheckRequestHoldMax(2000);  
    producer.setTransactionCheckListener(transactionCheckListener);  
    producer.start();  

    // String[] tags = new String[] { "TagA", "TagB", "TagC", "TagD", "TagE"  
    // };  
    TransactionExecuterImpl tranExecuter = new TransactionExecuterImpl();  
    for (int i = 1; i <= 2; i++) {  
        try {  
            Message msg = new Message("TopicTransactionTest", "transaction" + i, "KEY" + i,  
                    ("Hello RocketMQ " + i).getBytes());  
            SendResult sendResult = producer.sendMessageInTransaction(msg, tranExecuter, null);  
            System.out.println(sendResult);  

            Thread.sleep(10);  
        } catch (MQClientException e) {  
            e.printStackTrace();  
        }  
    }  

    for (int i = 0; i < 100000; i++) {  
        Thread.sleep(1000);  
    }  

    producer.shutdown();  

}

}

TransactionExecuterImpl .java --执行本地事务

package transaction;

import com.alibaba.rocketmq.client.producer.LocalTransactionExecuter;
import com.alibaba.rocketmq.client.producer.LocalTransactionState;
import com.alibaba.rocketmq.common.message.Message;

/**

执行本地事务
*/
public class TransactionExecuterImpl implements LocalTransactionExecuter {
// private AtomicInteger transactionIndex = new AtomicInteger(1);

public LocalTransactionState executeLocalTransactionBranch(final Message msg, final Object arg) {

 System.out.println("执行本地事务msg = " + new String(msg.getBody()));  

 System.out.println("执行本地事务arg = " + arg);  

 String tags = msg.getTags();  

 if (tags.equals("transaction2")) {  
     System.out.println("======我的操作============，失败了  -进行ROLLBACK");  
     return LocalTransactionState.ROLLBACK_MESSAGE;  
 }  
 return LocalTransactionState.COMMIT_MESSAGE;  
 // return LocalTransactionState.UNKNOW;

}
}

TransactionCheckListenerImpl--未决事务，服务器回查客户端(目前已经被阉割啦)

package transaction;

import com.alibaba.rocketmq.client.producer.LocalTransactionState;
import com.alibaba.rocketmq.client.producer.TransactionCheckListener;
import com.alibaba.rocketmq.common.message.MessageExt;

/**

未决事务，服务器回查客户端
*/
public class TransactionCheckListenerImpl implements TransactionCheckListener {
// private AtomicInteger transactionIndex = new AtomicInteger(0);

//在这里，我们可以根据由MQ回传的key去数据库查询，这条数据到底是成功了还是失败了。
public LocalTransactionState checkLocalTransactionState(MessageExt msg) {
System.out.println(“未决事务，服务器回查客户端msg =” + new String(msg.getBody().toString()));
// return LocalTransactionState.ROLLBACK_MESSAGE;
```
 return LocalTransactionState.COMMIT_MESSAGE;  

 // return LocalTransactionState.UNKNOW;  
```
}
}

producer端：发送数据到MQ，并且处理本地事物。这里模拟了一个成功一个失败。Consumer只会接收到本地事物成功的数据。第二个数据失败了，不会被消费。

Consumer只会接收到一个，第二个数据不会被接收到

分布式消息队列RocketMQ&Kafka -- 消息的“顺序消费”

在说到消息中间件的时候，我们通常都会谈到一个特性：消息的顺序消费问题。这个问题看起来很简单：Producer发送消息1, 2, 3。。。 Consumer按1, 2, 3。。。顺序消费。

但实际情况却是：无论RocketMQ，还是Kafka，缺省都不保证消息的严格有序消费！

这个特性看起来很简单，但为什么缺省他们都不保证呢？

“严格的顺序消费”有多么困难

下面就从3个方面来分析一下，对于一个消息中间件来说，”严格的顺序消费”有多么困难，或者说不可能。

发送端

发送端不能异步发送，异步发送在发送失败的情况下，就没办法保证消息顺序。

比如你连续发了1，2，3。过了一会，返回结果1失败，2, 3成功。你把1再重新发送1遍，这个时候顺序就乱掉了。

存储端

对于存储端，要保证消息顺序，会有以下几个问题：
（1）消息不能分区。也就是1个topic，只能有1个队列。在Kafka中，它叫做partition；在RocketMQ中，它叫做queue。如果你有多个队列，那同1个topic的消息，会分散到多个分区里面，自然不能保证顺序。

（2）即使只有1个队列的情况下，会有第2个问题。该机器挂了之后，能否切换到其他机器？也就是高可用问题。

比如你当前的机器挂了，上面还有消息没有消费完。此时切换到其他机器，可用性保证了。但消息顺序就乱掉了。

要想保证，一方面要同步复制，不能异步复制；另1方面得保证，切机器之前，挂掉的机器上面，所有消息必须消费完了，不能有残留。很明显，这个很难！！！

接收端

对于接收端，不能并行消费，也即不能开多线程或者多个客户端消费同1个队列。

总结

从上面的分析可以看出，要保证消息的严格有序，有多么困难！

发送端和接收端的问题，还好解决一点，限制异步发送，限制并行消费。但对于存储端，机器挂了之后，切换的问题，就很难解决了。

你切换了，可能消息就会乱；你不切换，那就暂时不可用。这2者之间，就需要权衡了。

业务需要全局有序吗？

通过上面分析可以看出，要保证一个topic内部，消息严格的有序，是很困难的，或者说条件是很苛刻的。

那怎么办呢？我们一定要使出所有力气、用尽所有办法，来保证消息的严格有序吗？

这里就需要从另外一个角度去考虑这个问题：业务角度。正如在下面这篇博客中所说的：
http://www.jianshu.com/p/453c6e7ff81c

实际情况中：
（1）不关注顺序的业务大量存在；
（2）队列无序不代表消息无序。

第（2）条的意思是说：我们不保证队列的全局有序，但可以保证消息的局部有序。

举个例子：保证来自同1个order id的消息，是有序的！

下面就看一下在Kafka和RocketMQ中，分别是如何对待这个问题的：

Kafka中：发送1条消息的时候，可以指定(topic, partition, key) 3个参数。partiton和key是可选的。

如果你指定了partition，那就是所有消息发往同1个partition，就是有序的。并且在消费端，Kafka保证，1个partition只能被1个consumer消费。

或者你指定key（比如order id），具有同1个key的所有消息，会发往同1个partition。也是有序的。

RocketMQ： RocketMQ在Kafka的基础上，把这个限制更放宽了一步。只指定(topic, key)，不指定具体发往哪个队列。也就是说，它更加不希望业务方，非要去要一个全局的严格有序。

消费模式

一、集群消费

之前的博客中，启动的都是单个Consumer，如果启动多个呢？

RocketMQ-集群消费

其实，对于RocketMQ而言，通过ConsumeGroup的机制，实现了天然的消息负载均衡！通俗点来说，RocketMQ中的消息通过ConsumeGroup实现了将消息分发到C1/C2/C3/……的机制，这意味着我们将非常方便的通过加机器来实现水平扩展！

我们考虑一下这种情况：比如C2发生了重启，一条消息发往C3进行消费，但是这条消息的处理需要0.1S，而此时C2刚好完成重启，那么C2是否可能会收到这条消息呢？答案是肯定的，也就是consume broker的重启，或者水平扩容，或者不遵守先订阅后生产消息，都可能导致消息的重复消费！关于去重的话题会在后续中予以介绍！

至于消息分发到C1/C2/C3，其实也是可以设置策略的：

RocketMQ-消息负载策略

使用哪种策略，只需要实例化对应的对象即可，如：

AllocateMessageQueueStrategy aqs = new AllocateMessageQueueAveragelyByCircle();
consumer.setAllocateMessageQueueStrategy(aqs);

上面内容，其实是一种消费模式——集群消费。
RocketMQ的消费模式有2种，查看一下源码：

public enum MessageModel {
    /**
     * broadcast
     */
    BROADCASTING,
    /** * clustering */
    CLUSTERING;
}

在默认情况下，就是集群消费（CLUSTERING），也就是上面提及的消息的负载均衡消费。另一种消费模式，是广播消费（BROADCASTING）。

二、广播消费

广播消费，类似于ActiveMQ中的发布订阅模式，消息会发给Consume Group中的每一个消费者进行消费。

RocketMQ-广播消费模式设置

/**
 * Consumer，订阅消息
 */
public class Consumer2 { public static void main(String[] args) throws InterruptedException, MQClientException { DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("group_name"); consumer.setNamesrvAddr("192.168.2.222:9876;192.168.2.223:9876"); consumer.setConsumeMessageBatchMaxSize(10);     // 设置为广播消费模式
    consumer.setMessageModel(MessageModel.BROADCASTING);

    consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_FIRST_OFFSET);
    consumer.subscribe("TopicTest", "*");

    consumer.registerMessageListener(new MessageListenerConcurrently() {
        public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {
            try {
                for (MessageExt msg : msgs) {
                    System.out.println(" Receive New Messages: " + msg);
                }
            } catch (Exception e) {
                e.printStackTrace();
                return ConsumeConcurrentlyStatus.RECONSUME_LATER;   // 重试
            }
            return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;       // 成功
        }
    });

    consumer.start();
    System.out.println("Consumer Started.");
}

}

内容补充

《RocketMQ（三）——HelloWorld》那篇博客的最后提到了单批次消息消费数量，本文既然提到了集群消费，那就针对这两个内容再进行一次补充吧。
如果我们有2台节点，Producerw往MQ上写入20条数据其中Consumer1中拉取了12条。Consumer2中拉取了8 条，这种情况下，假如Consumer1宕机，那么我们消费数据的时候，只能消费到Consumer2中的8条，Consumer1中的12条已经持久化了。需要Consumer1恢复之后这12条数据才能继续被消费。其实这种先启动producer往MQ上写数据，然后再启动Consumer的情况本来就是违规操作，正确的情况应该是先启动Consumer后再启动producer。

集群消费和广播消费

基本概念

MQ 是基于发布订阅模型的消息系统。在 MQ 消息系统中消息的订阅方订阅关注的 Topic，以获取并消费消息。由于订阅方应用一般是分布式系统，以集群方式部署有多台机器。因此 MQ 约定以下概念。

集群：MQ 约定使用相同 Consumer ID 的订阅者属于同一个集群，同一个集群下的订阅者消费逻辑必须完全一致（包括 Tag 的使用），这些订阅者在逻辑上可以认为是一个消费节点。

集群消费：当使用集群消费模式时，MQ 认为任意一条消息只需要被集群内的任意一个消费者处理即可。

广播消费：当使用广播消费模式时，MQ 会将每条消息推送给集群内所有注册过的客户端，保证消息至少被每台机器消费一次。

场景对比

集群消费模式：

适用场景&注意事项

消费端集群化部署，每条消息只需要被处理一次。
由于消费进度在服务端维护，可靠性更高。
集群消费模式下，每一条消息都只会被分发到一台机器上处理，如果需要被集群下的每一台机器都处理，请使用广播模式。
集群消费模式下，不保证消息的每一次失败重投等逻辑都能路由到同一台机器上，因此处理消息时不应该做任何确定性假设。

广播消费模式：

适用场景&注意事项

每条消息都需要被相同逻辑的多台机器处理。
消费进度在客户端维护，出现重复的概率稍大于集群模式。
广播模式下，MQ 保证每条消息至少被每台客户端消费一次，但是并不会对消费失败的消息进行失败重投，因此业务方需要关注消费失败的情况。
广播模式下，第一次启动时默认从最新消息消费，客户端的消费进度是被持久化在客户端本地的隐藏文件中，因此不建议删除该隐藏文件，否则会丢失部分消息。
广播模式下，每条消息都会被大量的客户端重复处理，因此推荐尽可能使用集群模式。
目前仅 Java 客户端支持广播模式。
广播模式下服务端不维护消费进度，所以服务端不提供堆积查询和报警功能。

使用集群模式模拟广播：

适用场景&注意事项

每条消息都需要被多台机器处理，每台机器的逻辑可以相同也可以不一样。
消费进度在服务端维护，可靠性高于广播模式。

你可能感兴趣的:(mq)

消息中间件有哪些常见类型 xmh-sxh-1314 java
消息中间件根据其设计理念和用途，可以大致分为以下几种常见类型：点对点消息队列（Point-to-PointMessagingQueues）：在这种模型中，消息被发送到特定的队列中，消费者从队列中取出并处理消息。队列中的消息只能被一个消费者消费，消费后即被删除。常见的实现包括IBM的MQSeries、RabbitMQ的部分使用场景等。适用于任务分发、负载均衡等场景。发布/订阅消息模型（Pub/Sub
esp32开发快速入门 8 : MQTT 的快速入门，基于esp32实现MQTT通信 z755924843 ESP32开发快速入门服务器网络运维
MQTT介绍简介MQTT（MessageQueuingTelemetryTransport，消息队列遥测传输协议），是一种基于发布/订阅（publish/subscribe）模式的"轻量级"通讯协议，该协议构建于TCP/IP协议上，由IBM在1999年发布。MQTT最大优点在于，可以以极少的代码和有限的带宽，为连接远程设备提供实时可靠的消息服务。作为一种低开销、低带宽占用的即时通讯协议，使其在物联
06选课支付模块之基于消息队列发送支付通知消息 echo 云清学成在线 java rabbitmq 消息队列支付通知学成在线
消息队列发送支付通知消息需求分析订单服务作为通用服务，在订单支付成功后需要将支付结果异步通知给其他对接的微服务，微服务收到支付结果根据订单的类型去更新自己的业务数据技术方案使用消息队列进行异步通知需要保证消息的可靠性即生产端将消息成功通知到服务端：消息发送到交换机-->由交换机发送到队列-->消费者监听队列，收到消息进行处理，参考文章02-使用Docker安装RabbitMQ-CSDN博客生产者确
在RabbitMQ中四种常见的消息路由模式 Xwzzz_ rabbitmq 分布式
1.Fanout模式Fanout模式的交换机是扇出交换机（FanoutExchange），它会将消息广播给所有绑定到它的队列，而不考虑消息的内容或路由键。工作原理：生产者发送消息到FanoutExchange。FanoutExchange会将消息广播给所有绑定到它的队列，所有绑定的队列都会收到这条消息。消费者监听绑定的队列，处理收到的消息。特点：没有路由键：消息不需要路由键，所有绑定的队列都会接收
ESP32-C3入门教程网络篇⑩——基于esp_https_ota和MQTT实现开机主动升级和被动触发升级的OTA功能小康师兄 ESP32-C3入门教程 https 服务器 esp32 OTA MQTT
文章目录一、前言二、软件流程三、部分源码四、运行演示一、前言本文基于VSCodeIDE进行编程、编译、下载、运行等操作基础入门章节请查阅：ESP32-C3入门教程基础篇①——基于VSCode构建HelloWorld教程目录大纲请查阅：ESP32-C3入门教程——导读ESP32-C3入门教程网络篇⑨——基于esp_https_ota实现史上最简单的ESP32OTA远程固件升级功能二、软件流程
【RabbitMQ 项目】服务端：数据管理模块之绑定管理月夜星辉雪 rabbitmq 分布式
文章目录一.编写思路二.代码实践一.编写思路定义绑定信息类交换机名称队列名称绑定关键字：交换机的路由交换算法中会用到没有是否持久化的标志，因为绑定是否持久化取决于交换机和队列是否持久化，只有它们都持久化时绑定才需要持久化。绑定就好像一根绳子，两端连接着交换机和队列，当一方不存在，它就没有存在的必要了定义绑定持久化类构造函数：如果数据库文件不存在则创建，打开数据库，创建binding_table插入
RabbitMQ生产者重复机制与确认机制 java炒饭小能手 java-rabbitmq rabbitmq java
重复机制生产者发送消息时，出现了网络故障，导致与MQ的连接中断。为了解决这个问题，SpringAMQP提供的消息发送时的重试机制。即：当RabbitTemplate与MQ连接超时后，多次重试。需要修该发送端模块的application.yaml文件，添加下面的内容：spring:rabbitmq:connection-timeout:1s#设置MQ的连接超时时间template:retry:ena
Kafka 基础与架构理解 StaticKing KAFKA kafka
目录前言Kafka基础概念消息队列简介：Kafka与传统消息队列（如RabbitMQ、ActiveMQ）的对比Kafka的组件Kafka的工作原理：消息的生产、分发、消费流程Kafka系统架构Kafka的分布式架构设计Leader-Follower机制与数据复制Log-basedStorage和持久化Broker间通信协议Zookeeper在Kafka中的角色总结前言Kafka是一个分布式的消息系
【RabbitMQ 项目】服务端数据管理模块之交换机管理月夜星辉雪 rabbitmq oracle 数据库
文章目录一.编写思路二.代码实践一.编写思路定义交换机类型直接交换广播交换主题交换定义交换机名字类型是否持久化定义交换机持久化类(持久化到sqlite3)构造函数(只能成功，不能失败)如果数据库(文件)不存在则创建打开数据库打开exchange_table数据库表插入交换机移除交换机将数据库中的交换机恢复到内存中传入一个哈希表，key为名字，value为交换机的智能指针，填充该哈希表定义交换机管理
【仿RabbitMQ消息队列项目day2】使用muduo库中基于protobuf的应用层协议进行通信月夜星辉雪 rabbitmq 网络分布式 c++后端服务器 linux
一.什么是muduo?muduo库是⼀个基于非阻塞IO和事件驱动的C++高并发TCP网络编程库。简单来理解，它就是对原生的TCP套接字的封装，是一个比socket编程接口更好用的编程库。二.使用muduo库完成一个英译汉翻译服务TranslateServer.hpp:#pragmaonce#include#include#include#include#include"muduo/net/TcpC
rabbitmq 楚楚ccc Java系列 rabbitmq 分布式
1.消息服务概述、rabbitmq核心概念消息服务概述：大多数应用中，可通过消息服务中间件来提升系统异步通信，扩展解耦能力两个重要概念：消息代理(messagebroker)和目的地(destination)。当消息发送者者发出消息后，将由消息代理接管，消息代理保证将消息传递至目的地两种形式的目的地：队列(queue):点对点的消息通信(point-to-point)主题(topic):发布(pu
使用 RabbitMQ 实现秒杀订单系统的异步消息处理 c137范特西 rabbitmq 分布式
使用RabbitMQ实现秒杀订单系统的异步消息处理在秒杀系统中，如何确保高并发环境下的订单处理稳定高效是个很大的挑战。为了解决这个问题，我们通常会引入消息队列，通过异步处理来削峰填谷。这篇文章将详细讲解如何使用RabbitMQ来设计一个秒杀订单系统的异步消息处理流程，重点是如何使用交换机（Exchange）、队列（Queue）、路由键（RoutingKey）以及死信队列（DeadLetterQue
Prometheus运维六 PromQL查询语言详解及操作安顾里 Prometheus 监控类大数据 kubernetes 运维 linux
海阔凭鱼跃，天高任鸟飞Prometheus官网：https://prometheus.io/文章目录1.什么是PromQL?2.PromQL的基本使用2.1时间序列选择器2.1.1瞬时向量选择器2.2区间向量选择器2.2.1范围向量选择器2.2.2时间位移操作2.2.3使用聚合操作2.3标量和字符串3.PromQL操作符4.内置常用函数5.HTTPAPI操作PromQL6.使用建议1.什么是Pro
单节点canal的介绍和搭建（对接mysql和rocketMQ）汀风中间件阿里云 mysql java
单节点canal-server+canal-admin的介绍和搭建（对接mysql和rocketMQ）一、简介1、Canal1、工作原理2、MySQL主从复制实现3、canal架构4、binarylog1、新增binlog2、更新binglog3、增加字段bin-log4、删除字段bin-log5、修改字段bin-log二、使用2.1安装1、本地安装2、docker安装canal-admincan
QMQTT在项目中的用法好学松鼠 c++qt
在一次项目实践中，需要使用MQTT协议向服务器发送数据，经过了解之后MQTT协议底层是基于TCP协议的。正好使用QT在开发项目，就在网上搜索了MQTT相关的开源三方库，因此就找到了基于QT的QMQTT的库。QMQTT库的源码可以再github或者gitee上获取到，具体的用法如下：1、初始化QMQTT#include"qmqtt.h"//服务器IP端口QMQTT::Client*client=ne
RocketMQ 架构简析，看这篇就够了！ V搜编程进阶路 Java程序员 java-rocketmq rocketmq 架构
生产者组（ProducerGroup）同一类Producer的集合，这类Producer发送同一类消息且发送逻辑一致。如果发送的是事务消息且原始生产者在发送之后崩溃，则Broker服务器会联系同一生产者组的其他生产者实例以提交或回溯消费。消费者组（ConsumerGroup）同一类Consumer的集合，这类Consumer通常消费同一类消息且消费逻辑一致。消费者组使得在消息消费方面，实现负载均衡
4G MQTT网关在物联网应用中的优势-天拓四方北京天拓四方边缘计算 iot 物联网其他
随着物联网（IoT）技术的飞速发展，各种设备和系统之间的互联互通变得日益重要。MQTT（MessageQueuingTelemetryTransport）作为一种轻量级的发布/订阅消息传输协议，因其高效、可靠、简单的特性，在物联网领域得到了广泛的应用。而4GMQTT网关，作为连接物联网设备和MQTT服务器的桥梁，其在物联网应用中的作用愈发凸显。本文将探讨4GMQTT网关在物联网应用中的优势。4GM
EG边缘计算网关连接中移ONENET物联网平台（MQTT协议）成都纵横智控科技官方账号边缘计算网关物联网工业网关边缘计算物联网 MQTT 中移ONENET
上文：EG边缘计算网关连接阿里云物联网平台（MQTT协议）需求概述本章节主要实现一个流程：EG8200mini采集ModbusRTU数据，通过MQTT协议连接中移ONENET物联网平台ModbusRTU采集此处不做过多赘述，可参考其他案例（串口读取Modbus传感器数据）介绍。下文默认已经采集到ModbusRTU数据。要采集的Modbus点位表：地址(Doc)数据类型属性名称00001Boolea
RabbitMQ 手册 - "Hello World" 乡间IT学者
英文原文链接介绍准备本手册假定RabbitMQ已经安装并且运行在本机，监听了标准的5672端口。如果你使用了不同的主机，端口或者凭证，连接设置也需要相应地调整。从哪里获取帮助如果你在阅读本手册有任何困惑，可以通过邮件列表联系我们RabbitMQ是一个消息代理：它接受并转发消息。你可以认为他是一个邮局：当你在邮箱放了一封你想邮送的信件，你可以确定某个邮递员最终会将邮件送达给收件人。在这个类比中，Ra
win10下Anaconda创建的环境中更新python版本后jupyter打不开问题 JimmyFun 环境配置
问题描述：解决方法：pipuninstalljupyterpipinstalljupyterpipinstall--force-reinstall--upgradepyzmq
RocketMQ消息重复消费--一起学习吧之架构吗喽一只 rocketmq 学习架构
一、定义RocketMQ中的消息重复消费（DuplicateConsumption）指的是在某些情况下，消息可能会被多次消费，从而导致业务逻辑的重复执行。重复消费是MQ中常见的问题，尤其在系统调用频繁的场景下，可能会因为超时重试等原因导致重复消费。在RocketMQ中，重复消费可能由多种原因造成，例如服务端重启后的数据恢复、主从同步offset失败，以及消息处理异常等。二、原因RocketMQ消息
规划大二上期白色的风扇学习
英语过四级。这个学期将java核心卷1看完。每天3道sql语句编程题。11月之前将ssmredis学完，过年之前mysql学完，MQ消息队列，ES学完。期末不挂科。问题争取自己解决，如何导入api，如何训练自己的ai,如何人脸识别之类的技术问题争取独立解决。养成一个好的生活习惯，每天争取2点之前就睡，减少油炸食品的摄入，坚持每两天跑一次步，争取这个学期减肥20斤。心态：顺其自然，尽力而为，少于人比
解决** (ArgumentError) argument error (stdlib) io_lib.erl:187: :io_lib.format(‘ * effective user\‘ 独角戏满天星 java
解决**(ArgumentError)argumenterror(stdlib)io_lib.erl:187::io_lib.format(’*effectiveuser’shomedirectory:sn’,[[67,58,92,85,115,101,114,115,92,24352,21344,35946]])的问题话不多上记录错误信息更改RabbitMQ的工作路径其中D:\RabbitMQ就
分布式中间件-几个常用的消息中间件问道飞鱼分布式技术分布式中间件
文章目录常见消息中间件1.RabbitMQ2.ApacheKafka3.RedisPub/Sub4.ActiveMQ5.AmazonSimpleNotificationService(SNS)和SimpleQueueService(SQS)6.RocketMQ差异总结消息协议1.AMQP(AdvancedMessageQueuingProtocol)2.STOMP(SimpleTextOrient
怎么连接服务器修改mq,如何连接远程RabbitMQ服务器 weixin_39602637 怎么连接服务器修改mq
我要建立一个应用程序(Asp.netC#)连接位于另一个国家/地区的RabbitMQ服务器。我已经从NuGet包安装了RabbitMQ客户端。在我的本地机器上运行RabbitMQ服务需要这个吗?需要在本地机器上安装RabbitMQ服务器吗?从客户那里得到的一些参数用户名、密码、主机名、带有私钥的证书。我很想知道从本地主机应用程序连接服务器的基本步骤是什么。有人能提供博客参考吗?我已经尝试了不同的步
Docker安装RabbitMQ【单机】时光不负所望 Linux rabbitmq docker
#RABBITMQ_DEFAULT_USER账号#RABBITMQ_DEFAULT_PASS密码#18090:15672管理端口18090改为15672#8090:5672数据端口8090改为5672dockerrun-d--namerabbitmq-eRABBITMQ_DEFAULT_USER=admin-eRABBITMQ_DEFAULT_PASS=123456,-p18090:15672-p
消息总线RabbitMQ Crystalqy 微服务消息队列 rabbitmq
RabbitMQ是实现了高级消息队列协议（AMQP）的开源消息代理软件，也称为面向消息的中间件，是一个在AMQP基础上完整的，可复用的企业消息系统。它可以用于大型软件系统各个模块之间的高效通信，支持高并发，支持可扩展。AMQP，即AdvancedMessageQueuingProtocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计，它定义
RocketMQ复习 slh别学了微服务 rocketmq 微服务 java
之前写的博客太杂，最近想把RocketMQ的知识点再系统的过一遍，带着自己的理解使用简短的话把一些问题总结一下，尤其是开发中和面试中的高频问题，基础知识点可以参考之前写的一些博客，这篇不再赘述。SpringCloud入门(3)RabbitMQRocketMQ学习(1)快速入门RocketMQ学习(2)深入学习RocketMQ学习(3)秒杀实战目录MQ技术对比基本概念(消费者组、订阅关系等)消费模式
RabbitMQ学习笔记我叫奈奈
RabbitMQ相关接受mq消息//接收//需要手动创建queueName的消息队列@RabbitListener(queues="queueName")发送mq消息//发送//@AutowiredprivateAmqpTemplateamqpTemplate//第一个参数时队列名称，剩下的是参数列表publicvoidsend(){ampqTemplate.convertAndSend("que
【SpringBoot MQ 系列】RabbitListener 消费基本使用姿势介绍一灰灰blog SpringBoot专题 SpringBoot RabbitMQ基础教程 rabbitmq spring java 队列
【MQ系列】RabbitListener消费基本使用姿势介绍之前介绍了rabbitmq的消息发送姿势，既然有发送，当然就得有消费者，在SpringBoot环境下，消费可以说比较简单了，借助@RabbitListener注解，基本上可以满足你90%以上的业务开发需求下面我们来看一下@RabbitListener的最最常用使用姿势I.配置首先创建一个SpringBoot项目，用于后续的演示spring
Java 并发包之线程池和原子计数 lijingyao8206 Java计数 ThreadPool 并发包 java线程池
对于大数据量关联的业务处理逻辑，比较直接的想法就是用JDK提供的并发包去解决多线程情况下的业务数据处理。线程池可以提供很好的管理线程的方式，并且可以提高线程利用率，并发包中的原子计数在多线程的情况下可以让我们避免去写一些同步代码。这里就先把jdk并发包中的线程池处理器ThreadPoolExecutor 以原子计数类AomicInteger 和倒数计时锁C
java编程思想抽象类和接口百合不是茶 java 抽象类接口
接口c++对接口和内部类只有简介的支持,但在java中有队这些类的直接支持 1 ,抽象类 : 如果一个类包含一个或多个抽象方法,该类必须限定为抽象类(否者编译器报错) 抽象方法 : 在方法中仅有声明而没有方法体 package com.wj.Interface;
[房地产与大数据]房地产数据挖掘系统 comsci 数据挖掘
随着一个关键核心技术的突破,我们已经是独立自主的开发某些先进模块,但是要完全实现,还需要一定的时间... 所以,除了代码工作以外,我们还需要关心一下非技术领域的事件..比如说房地产 &nb
数组队列总结沐刃青蛟数组队列
数组队列是一种大小可以改变，类型没有定死的类似数组的工具。不过与数组相比，它更具有灵活性。因为它不但不用担心越界问题，而且因为泛型（类似c++中模板的东西）的存在而支持各种类型。以下是数组队列的功能实现代码： import List.Student; public class
Oracle存储过程无法编译的解决方法 IT独行者 oracle 存储过程　
今天同事修改Oracle存储过程又导致2个过程无法被编译，流程规范上的东西，Dave 这里不多说，看看怎么解决问题。 1. 查看无效对象 XEZF@xezf(qs-xezf-db1)> select object_name,object_type,status from all_objects where status='IN
重装系统之后oracle恢复文强chu oracle
前几天正在使用电脑，没有暂停oracle的各种服务。突然win8.1系统奔溃，无法修复，开机时系统提示正在搜集错误信息，然后再开机，再提示的无限循环中。无耐我拿出系统u盘准备重装系统，没想到竟然无法从u盘引导成功。晚上到外面早了一家修电脑店，让人家给装了个系统，并且那哥们在我没反应过来的时候，直接把我的c盘给格式化了并且清理了注册表，再装系统。然后的结果就是我的oracl
python学习二（一些基础语法）小桔子 pthon 基础语法
紧接着把！昨天没看继续看django 官方教程，学了下python的基本语法与c类语言还是有些小差别： 1.ptyhon的源文件以UTF-8编码格式 2. / 除结果浮点型 // 除结果整形 % 除取余数 * 乘 ** 乘方 eg 5**2 结果是5的2次方25 _&
svn 常用命令 aichenglong SVN 版本回退
1 svn回退版本 1)在window中选择log,根据想要回退的内容,选择revert this version或revert chanages from this version 两者的区别: revert this version:表示回退到当前版本(该版本后的版本全部作废) revert chanages from this versio
某小公司面试归来 alafqq 面试
先填单子，还要写笔试题，我以时间为急，拒绝了它。。时间宝贵。老拿这些对付毕业生的东东来吓唬我。。面试官很刁难，问了几个问题，记录下； 1，包的范围。。。public,private,protect. --悲剧了 2，hashcode方法和equals方法的区别。谁覆盖谁.结果，他说我说反了。 3，最恶心的一道题，抽象类继承抽象类吗？（察，一般它都是被继承的啊） 4，stru
动态数组的存储速度比较集合框架百合不是茶集合框架
集合框架：自定义数据结构(增删改查等) package 数组; /** * 创建动态数组 * @author 百合 * */ public class ArrayDemo{ //定义一个数组来存放数据 String[] src = new String[0]; /** * 增加元素加入容器 * @param s要加入容器
用JS实现一个JS对象，对象里有两个属性一个方法 bijian1013 js对象
<html> <head> </head> <body> 用js代码实现一个js对象，对象里有两个属性，一个方法 </body> <script> var obj={a:'1234567',b:'bbbbbbbbbb',c:function(x){
探索JUnit4扩展：使用Rule bijian1013 java 单元测试 JUnit Rule
在上一篇文章中，讨论了使用Runner扩展JUnit4的方式，即直接修改Test Runner的实现(BlockJUnit4ClassRunner)。但这种方法显然不便于灵活地添加或删除扩展功能。下面将使用JUnit4.7才开始引入的扩展方式——Rule来实现相同的扩展功能。 1. Rule &n
[Gson一]非泛型POJO对象的反序列化 bit1129 POJO
当要将JSON数据串反序列化自身为非泛型的POJO时，使用Gson.fromJson(String, Class)方法。自身为非泛型的POJO的包括两种： 1. POJO对象不包含任何泛型的字段 2. POJO对象包含泛型字段，例如泛型集合或者泛型类 Data类 a.不是泛型类， b.Data中的集合List和Map都是泛型的 c.Data中不包含其它的POJO
【Kakfa五】Kafka Producer和Consumer基本使用 bit1129 kafka
0.Kafka服务器的配置一个Broker，一个Topic Topic中只有一个Partition（） 1. Producer： package kafka.examples.producers; import kafka.producer.KeyedMessage; import kafka.javaapi.producer.Producer; impor
lsyncd实时同步搭建指南——取代rsync+inotify ronin47
1. 几大实时同步工具比较 1.1 inotify + rsync 最近一直在寻求生产服务服务器上的同步替代方案，原先使用的是 inotify + rsync，但随着文件数量的增大到100W+，目录下的文件列表就达20M，在网络状况不佳或者限速的情况下，变更的文件可能10来个才几M，却因此要发送的文件列表就达20M，严重减低的带宽的使用效率以及同步效率；更为要紧的是，加入inotify
java-9. 判断整数序列是不是二元查找树的后序遍历结果 bylijinnan java
public class IsBinTreePostTraverse{ static boolean isBSTPostOrder(int[] a){ if(a==null){ return false; } /*1.只有一个结点时，肯定是查找树 *2.只有两个结点时，肯定是查找树。例如{5,6}对应的BST是 6 {6,5}对应的BST是
MySQL的sum函数返回的类型 bylijinnan java spring sql mysql jdbc
今天项目切换数据库时，出错访问数据库的代码大概是这样： String sql = "select sum(number) as sumNumberOfOneDay from tableName"; List<Map> rows = getJdbcTemplate().queryForList(sql); for (Map row : rows
java设计模式之单例模式 chicony java设计模式
在阎宏博士的《JAVA与模式》一书中开头是这样描述单例模式的：　　作为对象的创建模式，单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。这个类称为单例类。单例模式的结构　　单例模式的特点：单例类只能有一个实例。单例类必须自己创建自己的唯一实例。单例类必须给所有其他对象提供这一实例。　　饿汉式单例类 publ
javascript取当月最后一天 ctrain JavaScript
 <script language=javascript> var current = new Date(); var year = current.getYear(); var month = current.getMonth(); showMonthLastDay(year, mont
linux tune2fs命令详解 daizj linux tune2fs 查看系统文件块信息
一.简介： tune2fs是调整和查看ext2/ext3文件系统的文件系统参数，Windows下面如果出现意外断电死机情况，下次开机一般都会出现系统自检。Linux系统下面也有文件系统自检，而且是可以通过tune2fs命令，自行定义自检周期及方式。二.用法： Usage: tune2fs [-c max_mounts_count] [-e errors_behavior] [-g grou
做有中国特色的程序员 dcj3sjt126com 程序员
从出版业说起网络作品排到靠前的，都不会太难看，一般人不爱看某部作品也是因为不喜欢这个类型，而此人也不会全不喜欢这些网络作品。究其原因，是因为网络作品都是让人先白看的，看的好了才出了头。而纸质作品就不一定了，排行榜靠前的，有好作品，也有垃圾。许多大牛都是写了博客，后来出了书。这些书也都不次，可能有人让为不好，是因为技术书不像小说，小说在读故事，技术书是在学知识或温习知识，有
Android：TextView属性大全 dcj3sjt126com textview
android:autoLink 设置是否当文本为URL链接/email/电话号码/map时，文本显示为可点击的链接。可选值(none/web/email/phone/map/all) android:autoText 如果设置，将自动执行输入值的拼写纠正。此处无效果，在显示输入法并输
tomcat虚拟目录安装及其配置 eksliang tomcat配置说明 tomca部署web应用 tomcat虚拟目录安装
转载请出自出处：http://eksliang.iteye.com/blog/2097184 1.-------------------------------------------tomcat 目录结构 config：存放tomcat的配置文件 temp ：存放tomcat跑起来后存放临时文件用的 work ：当第一次访问应用中的jsp
浅谈：APP有哪些常被黑客利用的安全漏洞 gg163 APP
首先，说到APP的安全漏洞，身为程序猿的大家应该不陌生；如果抛开安卓自身开源的问题的话，其主要产生的原因就是开发过程中疏忽或者代码不严谨引起的。但这些责任也不能怪在程序猿头上，有时会因为BOSS时间催得紧等很多可观原因。由国内移动应用安全检测团队爱内测（ineice.com）的CTO给我们浅谈关于Android 系统的开源设计以及生态环境。 1. 应用反编译漏洞：APK 包非常容易被反编译成可读
C#根据网址生成静态页面 hvt Web .net C#asp.net hovertree
HoverTree开源项目中HoverTreeWeb.HVTPanel的Index.aspx文件是后台管理的首页。包含生成留言板首页，以及显示用户名，退出等功能。根据网址生成页面的方法： bool CreateHtmlFile(string url, string path) { //http://keleyi.com/a/bjae/3d10wfax.htm stri
SVG 教程（一）天梯梦 svg
SVG 简介 SVG 是使用 XML 来描述二维图形和绘图程序的语言。学习之前应具备的基础知识：继续学习之前，你应该对以下内容有基本的了解： HTML XML 基础如果希望首先学习这些内容，请在本站的首页选择相应的教程。什么是SVG？ SVG 指可伸缩矢量图形 (Scalable Vector Graphics) SVG 用来定义用于网络的基于矢量
一个简单的java栈 luyulong java 数据结构栈
public class MyStack { private long[] arr; private int top; public MyStack() { arr = new long[10]; top = -1; } public MyStack(int maxsize) { arr = new long[maxsize]; top
基础数据结构和算法八：Binary search sunwinner Algorithm Binary search
Binary search needs an ordered array so that it can use array indexing to dramatically reduce the number of compares required for each search, using the classic and venerable binary search algori
12个C语言面试题，涉及指针、进程、运算、结构体、函数、内存，看看你能做出几个！刘星宇 c 面试
12个C语言面试题，涉及指针、进程、运算、结构体、函数、内存，看看你能做出几个！ 1.gets()函数问：请找出下面代码里的问题： #include<stdio.h> int main(void) { char buff[10]; memset(buff,0,sizeof(buff));
ITeye 7月技术图书有奖试读获奖名单公布 ITeye管理员活动 ITeye 试读
ITeye携手人民邮电出版社图灵教育共同举办的7月技术图书有奖试读活动已圆满结束，非常感谢广大用户对本次活动的关注与参与。 7月试读活动回顾： http://webmaster.iteye.com/blog/2092746 本次技术图书试读活动的优秀奖获奖名单及相应作品如下（优秀文章有很多，但名额有限，没获奖并不代表不优秀）：《Java性能优化权威指南》

rocketmq总结(消息的顺序、重复、事务、消费模式)

分布式开放消息系统(RocketMQ)的原理与实践

关键特性以及其实现原理

一、顺序消息

二、消息重复

三、事务消息

四、Producer如何发送消息

五、消息存储

1、Consume Queue

consume queue是消息的逻辑队列，相当于字典的目录，用来指定消息在物理文件commit log上的位置。

2、Commit Log

3、消息存储实现

六、消息订阅

七、RocketMQ的其他特性

RocketMQ最佳实践

一、Producer最佳实践

二、Consumer最佳实践

三、其他配置

RocketMQ设计相关

附录：RocketMQ涉及到的几个专业术语和整体架构介绍

一、RocketMQ中的专业术语

二、RocketMQ Overview

RocketMQ事务消费和顺序消费详解

一、RocketMq有3中消息类型

二、事务消费

“严格的顺序消费”有多么困难

发送端

存储端

接收端

总结

业务需要全局有序吗？

一、集群消费

二、广播消费

内容补充

基本概念

场景对比

你可能感兴趣的:(mq)

consume queue是消息的逻辑队列，相当于字典的目录，用来指定消息在物理文件`commit log`上的位置。