`
y806839048
  • 浏览: 1141064 次
  • 性别: Icon_minigender_1
  • 来自: 上海
文章分类
社区版块
存档分类
最新评论

ActiveMQ消息传送机制以及ACK机制详解

阅读更多

 AcitveMQ是作为一种消息存储和分发组件,涉及到client与broker端数据交互的方方面面,它不仅要担保消息的存储安全性,还要提供额外的手段来确保消息的分发是可靠的。

 

一. ActiveMQ消息传送机制

    Producer客户端使用来发送消息的, Consumer客户端用来消费消息;它们的协同中心就是ActiveMQ broker,broker也是让producer和consumer调用过程解耦的工具,最终实现了异步RPC/数据交换的功能。随着ActiveMQ的不断发展,支持了越来越多的特性,也解决开发者在各种场景下使用ActiveMQ的需求。比如producer支持异步调用;使用flow control机制让broker协同consumer的消费速率;consumer端可以使用prefetchACK来最大化消息消费的速率;提供"重发策略"等来提高消息的安全性等。在此我们不详细介绍。

 

    一条消息的生命周期如下:



  

     图片中简单的描述了一条消息的生命周期,不过在不同的架构环境中,message的流动行可能更加复杂.将在稍后有关broker的架构中详解..一条消息从producer端发出之后,一旦被broker正确保存,那么它将会被consumer消费,然后ACK,broker端才会删除;不过当消息过期或者存储设备溢出时,也会终结它。



 

 

     这是一张很复杂,而且有些凌乱的图片;这张图片中简单的描述了:1)producer端如何发送消息 2) consumer端如何消费消息 3) broker端如何调度。如果用文字来描述图示中的概念,恐怕一言难尽。图示中,提及到prefetchAck,以及消息同步、异步发送的基本逻辑;这对你了解下文中的ACK机制将有很大的帮助。

 

二. optimizeACK

    "可优化的ACK",这是ActiveMQ对于consumer在消息消费时,对消息ACK的优化选项,也是consumer端最重要的优化参数之一,你可以通过如下方式开启:

    1) 在brokerUrl中增加如下查询字符串: 

 

Java代码  收藏代码
  1. String brokerUrl = "tcp://localhost:61616?" +   
  2.                    "jms.optimizeAcknowledge=true" +   
  3.                    "&jms.optimizeAcknowledgeTimeOut=30000" +   
  4.                    "&jms.redeliveryPolicy.maximumRedeliveries=6";  
  5. ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory(brokerUrl);  

 

    2) 在destinationUri中,增加如下查询字符串:

 

Java代码  收藏代码
  1. String queueName = "test-queue?customer.prefetchSize=100";  
  2. Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);  
  3. Destination queue = session.createQueue(queueName);  

     

    我们需要在brokerUrl指定optimizeACK选项,在destinationUri中指定prefetchSize(预获取)选项,其中brokerUrl参数选项是全局的,即当前factory下所有的connection/session/consumer都会默认使用这些值;而destinationUri中的选项,只会在使用此destination的consumer实例中有效;如果同时指定,brokerUrl中的参数选项值将会被覆盖。optimizeAck表示是否开启“优化ACK”,只有在为true的情况下,prefetchSize(下文中将会简写成prefetch)以及optimizeAcknowledgeTimeout参数才会有意义。此处需要注意"optimizeAcknowledgeTimeout"选项只能在brokerUrl中配置。

    prefetch值建议在destinationUri中指定,因为在brokerUrl中指定比较繁琐;在brokerUrl中,queuePrefetchSize和topicPrefetchSize都需要单独设定:"&jms.prefetchPolicy.queuePrefetch=12&jms.prefetchPolicy.topicPrefetch=12"等来逐个指定。

 

    如果prefetchACK为true,那么prefetch必须大于0;当prefetchACK为false时,你可以指定prefetch为0以及任意大小的正数。不过,当prefetch=0是,表示consumer将使用PULL(拉取)的方式从broker端获取消息,broker端将不会主动push消息给client端,直到client端发送PullCommand时;当prefetch>0时,就开启了broker push模式,此后只要当client端消费且ACK了一定的消息之后,会立即push给client端多条消息。

 

    当consumer端使用receive()方法同步获取消息时,prefetch可以为0和任意正值;当prefetch=0时,那么receive()方法将会首先发送一个PULL指令并阻塞,直到broker端返回消息为止,这也意味着消息只能逐个获取(类似于Request<->Response),这也是Activemq中PULL消息模式;当prefetch > 0时,broker端将会批量push给client 一定数量的消息(<= prefetch),client端会把这些消息(unconsumedMessage)放入到本地的队列中,只要此队列有消息,那么receive方法将会立即返回,当一定量的消息ACK之后,broker端会继续批量push消息给client端。

 

    当consumer端使用MessageListener异步获取消息时,这就需要开发设定的prefetch值必须 >=1,即至少为1;在异步消费消息模式中,设定prefetch=0,是相悖的,也将获得一个Exception。

 

    此外,我们还可以brokerUrl中配置“redelivery”策略,比如当一条消息处理异常时,broker端可以重发的最大次数;和下文中提到REDELIVERED_ACK_TYPE互相协同。当消息需要broker端重发时,consumer会首先在本地的“deliveredMessage队列”(Consumer已经接收但还未确认的消息队列)删除它,然后向broker发送“REDELIVERED_ACK_TYPE”类型的确认指令,broker将会把指令中指定的消息重新添加到pendingQueue(亟待发送给consumer的消息队列)中,直到合适的时机,再次push给client。

 

    到目前为止,或许你知道了optimizeACK和prefeth的大概意义,不过我们可能还会有些疑惑!!optimizeACK和prefetch配合,将会达成一个高效的消息消费模型:批量获取消息,并“延迟”确认(ACK)prefetch表达了“批量获取”消息的语义,broker端主动的批量push多条消息给client端,总比client多次发送PULL指令然后broker返回一条消息的方式要优秀很多,它不仅减少了client端在获取消息时阻塞的次数和阻塞的时间,还能够大大的减少网络开支。optimizeACK表达了“延迟确认”的语义(ACK时机),client端在消费消息后暂且不发送ACK,而是把它缓存下来(pendingACK),等到这些消息的条数达到一定阀值时,只需要通过一个ACK指令把它们全部确认;这比对每条消息都逐个确认,在性能上要提高很多。由此可见,prefetch优化了消息传送的性能,optimizeACK优化了消息确认的性能。

 

    当consumer端消息消费的速率很高(相对于producer生产消息),而且消息的数量也很大时(比如消息源源不断的生产),我们使用optimizeACK + prefetch将会极大的提升consumer的性能。不过反过来:

    1) 如果consumer端消费速度很慢(对消息的处理是耗时的),过大的prefetchSize,并不能有效的提升性能,反而不利于consumer端的负载均衡(只针对queue);按照良好的设计准则,当consumer消费速度很慢时,我们通常会部署多个consumer客户端,并使用较小的prefetch,同时关闭optimizeACK,可以让消息在多个consumer间“负载均衡”(即均匀的发送给每个consumer);如果较大的prefetchSize,将会导致broker一次性push给client大量的消息,但是这些消息需要很久才能ACK(消息积压),而且在client故障时,还会导致这些消息的重发。

 

    2) 如果consumer端消费速度很快,但是producer端生成消息的速率较慢,比如生产者10秒钟生成10条消息,但是consumer一秒就能消费完毕,而且我们还部署了多个consumer!!这种场景下,建议开启optimizeACK,但是需要设置的prefetchSize不能过大;这样可以保证每个consumer都能有"活干",否则将会出现一个consumer非常忙碌,但是其他consumer几乎收不到消息。

 

    3) 如果消息很重要,特别是不愿意接收到”redelivery“的消息,那么我们需要将optimizeACK=false,prefetchSize=1

 

    既然optimizeACK是”延迟“确认,那么就引入一种潜在的风险:在消息被消费之后还没有来得及确认时,client端发生故障,那么这些消息就有可能会被重新发送给其他consumer,那么这种风险就需要client端能够容忍“重复”消息。

 

    prefetch值默认为1000,当然这个值可能在很多场景下是偏大的;我们暂且不考虑ACK模式(参见下文),通常情况下,我们只需要简单的统计出单个consumer每秒的最大消费消息数即可,比如一个consumer每秒可以处理100个消息,我们期望consumer端每2秒确认一次,那么我们的prefetchSize可以设置为100 * 2 /0.65大概为300。无论如何设定此值,client持有的消息条数最大为:prefetch + “DELIVERED_ACK_TYPE消息条数”(DELIVERED_ACK_TYPE参见下文)

 

     即使当optimizeACK为true,也只会当session的ACK模式为AUTO_ACKNOWLEDGE时才会生效,即在其他类型的ACK模式时consumer端仍然不会“延迟确认”,即:

Java代码  收藏代码
  1. consumer.optimizeAck = connection.optimizeACK && session.isAutoAcknowledge()  

 

    当consumer.optimizeACK有效时,如果客户端已经消费但尚未确认的消息(deliveredMessage)达到prefetch * 0.65,consumer端将会自动进行ACK;同时如果离上一次ACK的时间间隔,已经超过"optimizeAcknowledgeTimout"毫秒,也会导致自动进行ACK。

 

    此外简单的补充一下,批量确认消息时,只需要在ACK指令中指明“firstMessageId”和“lastMessageId”即可,即消息区间,那么broker端就知道此consumer(根据consumerId识别)需要确认哪些消息。

 
三. ACK模式与类型介绍


    JMS API中约定了Client端可以使用四种ACK模式,在javax.jms.Session接口中:

 

  • AUTO_ACKNOWLEDGE = 1    自动确认
  • CLIENT_ACKNOWLEDGE = 2    客户端手动确认   
  • DUPS_OK_ACKNOWLEDGE = 3    自动批量确认
  • SESSION_TRANSACTED = 0    事务提交并确认

    此外AcitveMQ补充了一个自定义的ACK模式:

  • INDIVIDUAL_ACKNOWLEDGE = 4    单条消息确认

    我们在开发JMS应用程序的时候,会经常使用到上述ACK模式,其中"INDIVIDUAL_ACKNOWLEDGE "只有ActiveMQ支持,当然开发者也可以使用它. ACK模式描述了Consumer与broker确认消息的方式(时机),比如当消息被Consumer接收之后,Consumer将在何时确认消息。对于broker而言,只有接收到ACK指令,才会认为消息被正确的接收或者处理成功了,通过ACK,可以在consumer(/producer)与Broker之间建立一种简单的“担保”机制. 

   

    Client端指定了ACK模式,但是在Client与broker在交换ACK指令的时候,还需要告知ACK_TYPE,ACK_TYPE表示此确认指令的类型,不同的ACK_TYPE将传递着消息的状态,broker可以根据不同的ACK_TYPE对消息进行不同的操作。

 

    比如Consumer消费消息时出现异常,就需要向broker发送ACK指令,ACK_TYPE为"REDELIVERED_ACK_TYPE",那么broker就会重新发送此消息。在JMS API中并没有定义ACT_TYPE,因为它通常是一种内部机制,并不会面向开发者。ActiveMQ中定义了如下几种ACK_TYPE(参看MessageAck类):

 

  • DELIVERED_ACK_TYPE = 0    消息"已接收",但尚未处理结束
  • STANDARD_ACK_TYPE = 2    "标准"类型,通常表示为消息"处理成功",broker端可以删除消息了
  • POSION_ACK_TYPE = 1    消息"错误",通常表示"抛弃"此消息,比如消息重发多次后,都无法正确处理时,消息将会被删除或者DLQ(死信队列)
  • REDELIVERED_ACK_TYPE = 3    消息需"重发",比如consumer处理消息时抛出了异常,broker稍后会重新发送此消息
  • INDIVIDUAL_ACK_TYPE = 4    表示只确认"单条消息",无论在任何ACK_MODE下    
  • UNMATCHED_ACK_TYPE = 5    在Topic中,如果一条消息在转发给“订阅者”时,发现此消息不符合Selector过滤条件,那么此消息将 不会转发给订阅者,消息将会被存储引擎删除(相当于在Broker上确认了消息)。

    到目前为止,我们已经清楚了大概的原理: Client端在不同的ACK模式时,将意味着在不同的时机发送ACK指令,每个ACK Command中会包含ACK_TYPE,那么broker端就可以根据ACK_TYPE来决定此消息的后续操作. 接下来,我们详细的分析ACK模式与ACK_TYPE.

Java代码  收藏代码
  1. Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);   

 

    我们需要在创建Session时指定ACK模式,由此可见,ACK模式将是session共享的,意味着一个session下所有的 consumer都使用同一种ACK模式。在创建Session时,开发者不能指定除ACK模式列表之外的其他值.如果此session为事务类型,用户指定的ACK模式将被忽略,而强制使用"SESSION_TRANSACTED"类型;如果session非事务类型时,也将不能将 ACK模式设定为"SESSION_TRANSACTED",毕竟这是相悖的.   



 

 

    Consumer消费消息的风格有2种: 同步/异步..使用consumer.receive()就是同步,使用messageListener就是异步;在同一个consumer中,我们不能同时使用这2种风格,比如在使用listener的情况下,当调用receive()方法将会获得一个Exception。两种风格下,消息确认时机有所不同。

    "同步"伪代码:

 

Java代码  收藏代码
  1. //receive伪代码---过程  
  2. Message message = sessionMessageQueue.dequeue();  
  3. if(message != null){  
  4.     ack(message);  
  5. }  
  6. return message  

 

    同步调用时,在消息从receive方法返回之前,就已经调用了ACK;因此如果Client端没有处理成功,此消息将丢失(可能重发,与ACK模式有关)。

    "异步"伪代码:

 

Java代码  收藏代码
  1. //基于listener  
  2. Session session = connection.getSession(consumerId);  
  3. sessionQueueBuffer.enqueue(message);  
  4. Runnable runnable = new Ruannale(){  
  5.     run(){  
  6.         Consumer consumer = session.getConsumer(consumerId);  
  7.         Message md = sessionQueueBuffer.dequeue();  
  8.         try{  
  9.             consumer.messageListener.onMessage(md);  
  10.             ack(md);//  
  11.         }catch(Exception e){  
  12.             redelivery();//sometime,not all the time;  
  13.     }  
  14. }  
  15. //session中将采取线程池的方式,分发异步消息  
  16. //因此同一个session中多个consumer可以并行消费  
  17. threadPool.execute(runnable);  

 

    基于异步调用时,消息的确认是在onMessage方法返回之后,如果onMessage方法异常,会导致消息不能被ACK,会触发重发。

 

四. ACK模式详解

 

    AUTO_ACKNOWLEDGE : 自动确认,这就意味着消息的确认时机将有consumer择机确认."择机确认"似乎充满了不确定性,这也意味着,开发者必须明确知道"择机确认"的具体时机,否则将有可能导致消息的丢失,或者消息的重复接收.那么在ActiveMQ中,AUTO_ACKNOWLEDGE是如何运作的呢?

    1) 对于consumer而言,optimizeAcknowledge属性只会在AUTO_ACK模式下有效。

 

    2) 其中DUPS_ACKNOWLEGE也是一种潜在的AUTO_ACK,只是确认消息的条数和时间上有所不同。

 

    3) 在“同步”(receive)方法返回message之前,会检测optimizeACK选项是否开启,如果没有开启,此单条消息将立即确认,所以在这种情况下,message返回之后,如果开发者在处理message过程中出现异常,会导致此消息也不会redelivery,即"潜在的消息丢失";如果开启了optimizeACK,则会在unAck数量达到prefetch * 0.65时确认,当然我们可以指定prefetchSize = 1来实现逐条消息确认。

 

    4) 在"异步"(messageListener)方式中,将会首先调用listener.onMessage(message),此后再ACK,如果onMessage方法异常,将导致client端补充发送一个ACK_TYPE为REDELIVERED_ACK_TYPE确认指令;如果onMessage方法正常,消息将会正常确认(STANDARD_ACK_TYPE)。此外需要注意,消息的重发次数是有限制的,每条消息中都会包含“redeliveryCounter”计数器,用来表示此消息已经被重发的次数,如果重发次数达到阀值,将会导致发送一个ACK_TYPE为POSION_ACK_TYPE确认指令,这就导致broker端认为此消息无法消费,此消息将会被删除或者迁移到"dead letter"通道中。

    

    因此当我们使用messageListener方式消费消息时,通常建议在onMessage方法中使用try-catch,这样可以在处理消息出错时记录一些信息,而不是让consumer不断去重发消息;如果你没有使用try-catch,就有可能会因为异常而导致消息重复接收的问题,需要注意你的onMessage方法中逻辑是否能够兼容对重复消息的判断。

 



 
 
 
 

    CLIENT_ACKNOWLEDGE : 客户端手动确认,这就意味着AcitveMQ将不会“自作主张”的为你ACK任何消息,开发者需要自己择机确认。在此模式下,开发者需要需要关注几个方法:1) message.acknowledge(),2) ActiveMQMessageConsumer.acknowledege(),3) ActiveMQSession.acknowledge();其1)和3)是等效的,将当前session中所有consumer中尚未ACK的消息都一起确认,2)只会对当前consumer中那些尚未确认的消息进行确认。开发者可以在合适的时机必须调用一次上述方法。为了避免混乱,对于这种ACK模式下,建议一个session下只有一个consumer。

 

    我们通常会在基于Group(消息分组)情况下会使用CLIENT_ACKNOWLEDGE,我们将在一个group的消息序列接受完毕之后确认消息(组);不过当你认为消息很重要,只有当消息被正确处理之后才能确认时,也可以使用此模式  。

 

    如果开发者忘记调用acknowledge方法,将会导致当consumer重启后,会接受到重复消息,因为对于broker而言,那些尚未真正ACK的消息被视为“未消费”。

    开发者可以在当前消息处理成功之后,立即调用message.acknowledge()方法来"逐个"确认消息,这样可以尽可能的减少因网络故障而导致消息重发的个数;当然也可以处理多条消息之后,间歇性的调用acknowledge方法来一次确认多条消息,减少ack的次数来提升consumer的效率,不过这仍然是一个利弊权衡的问题。

 

    除了message.acknowledge()方法之外,ActiveMQMessageConumser.acknowledge()和ActiveMQSession.acknowledge()也可以确认消息,只不过前者只会确认当前consumer中的消息。其中sesson.acknowledge()和message.acknowledge()是等效的。

 

    无论是“同步”/“异步”,ActiveMQ都不会发送STANDARD_ACK_TYPE,直到message.acknowledge()调用。如果在client端未确认的消息个数达到prefetchSize * 0.5时,会补充发送一个ACK_TYPE为DELIVERED_ACK_TYPE的确认指令,这会触发broker端可以继续push消息到client端。(参看PrefetchSubscription.acknwoledge方法)

 

    在broker端,针对每个Consumer,都会保存一个因为"DELIVERED_ACK_TYPE"而“拖延”的消息个数,这个参数为prefetchExtension,事实上这个值不会大于prefetchSize * 0.5,因为Consumer端会严格控制DELIVERED_ACK_TYPE指令发送的时机(参见ActiveMQMessageConsumer.ackLater方法),broker端通过“prefetchExtension”与prefetchSize互相配合,来决定即将push给client端的消息个数,count = prefetchExtension + prefetchSize - dispatched.size(),其中dispatched表示已经发送给client端但是还没有“STANDARD_ACK_TYPE”的消息总量;由此可见,在CLIENT_ACK模式下,足够快速的调用acknowledge()方法是决定consumer端消费消息的速率;如果client端因为某种原因导致acknowledge方法未被执行,将导致大量消息不能被确认,broker端将不会push消息,事实上client端将处于“假死”状态,而无法继续消费消息。我们要求client端在消费1.5*prefetchSize个消息之前,必须acknowledge()一次;通常我们总是每消费一个消息调用一次,这是一种良好的设计。

 

    此外需要额外的补充一下:所有ACK指令都是依次发送给broker端,在CLIET_ACK模式下,消息在交付给listener之前,都会首先创建一个DELIVERED_ACK_TYPE的ACK指令,直到client端未确认的消息达到"prefetchSize * 0.5"时才会发送此ACK指令,如果在此之前,开发者调用了acknowledge()方法,会导致消息直接被确认(STANDARD_ACK_TYPE)。broker端通常会认为“DELIVERED_ACK_TYPE”确认指令是一种“slow consumer”信号,如果consumer不能及时的对消息进行acknowledge而导致broker端阻塞,那么此consumer将会被标记为“slow”,此后queue中的消息将会转发给其他Consumer。

 

    DUPS_OK_ACKNOWLEDGE : "消息可重复"确认,意思是此模式下,可能会出现重复消息,并不是一条消息需要发送多次ACK才行。它是一种潜在的"AUTO_ACK"确认机制,为批量确认而生,而且具有“延迟”确认的特点。对于开发者而言,这种模式下的代码结构和AUTO_ACKNOWLEDGE一样,不需要像CLIENT_ACKNOWLEDGE那样调用acknowledge()方法来确认消息。

 

    1) 在ActiveMQ中,如果在Destination是Queue通道,我们真的可以认为DUPS_OK_ACK就是“AUTO_ACK + optimizeACK + (prefetch > 0)”这种情况,在确认时机上几乎完全一致;此外在此模式下,如果prefetchSize =1 或者没有开启optimizeACK,也会导致消息逐条确认,从而失去批量确认的特性。

 

    2) 如果Destination为Topic,DUPS_OK_ACKNOWLEDGE才会产生JMS规范中诠释的意义,即无论optimizeACK是否开启,都会在消费的消息个数>=prefetch * 0.5时,批量确认(STANDARD_ACK_TYPE),在此过程中,不会发送DELIVERED_ACK_TYPE的确认指令,这是1)和AUTO_ACK的最大的区别。

 

    这也意味着,当consumer故障重启后,那些尚未ACK的消息会重新发送过来。

 

    SESSION_TRANSACTED : 当session使用事务时,就是使用此模式。在事务开启之后,和session.commit()之前,所有消费的消息,要么全部正常确认,要么全部redelivery。这种严谨性,通常在基于GROUP(消息分组)或者其他场景下特别适合。在SESSION_TRANSACTED模式下,optimizeACK并不能发挥任何效果,因为在此模式下,optimizeACK会被强制设定为false,不过prefetch仍然可以决定DELIVERED_ACK_TYPE的发送时机。

 

    因为Session非线程安全,那么当前session下所有的consumer都会共享同一个transactionContext;同时建议,一个事务类型的Session中只有一个Consumer,以避免rollback()或者commit()方法被多个consumer调用而造成的消息混乱。

    

    当consumer接受到消息之后,首先检测TransactionContext是否已经开启,如果没有,就会开启并生成新的transactionId,并把信息发送给broker;此后将检测事务中已经消费的消息个数是否 >= prefetch * 0.5,如果大于则补充发送一个“DELIVERED_ACK_TYPE”的确认指令;这时就开始调用onMessage()方法,如果是同步(receive),那么即返回message。上述过程,和其他确认模式没有任何特殊的地方。

   

    当开发者决定事务可以提交时,必须调用session.commit()方法,commit方法将会导致当前session的事务中所有消息立即被确认;事务的确认过程中,首先把本地的deliveredMessage队列中尚未确认的消息全部确认(STANDARD_ACK_TYPE);此后向broker发送transaction提交指令并等待broker反馈,如果broker端事务操作成功,那么将会把本地deliveredMessage队列清空,新的事务开始;如果broker端事务操作失败(此时broker已经rollback),那么对于session而言,将执行inner-rollback,这个rollback所做的事情,就是将当前事务中的消息清空并要求broker重发(REDELIVERED_ACK_TYPE),同时commit方法将抛出异常。

 

    当session.commit方法异常时,对于开发者而言通常是调用session.rollback()回滚事务(事实上开发者不调用也没有问题),当然你可以在事务开始之后的任何时机调用rollback(),rollback意味着当前事务的结束,事务中所有的消息都将被重发。需要注意,无论是inner-rollback还是调用session.rollback()而导致消息重发,都会导致message.redeliveryCounter计数器增加,最终都会受限于brokerUrl中配置的"jms.redeliveryPolicy.maximumRedeliveries",如果rollback的次数过多,而达到重发次数的上限时,消息将会被DLQ(dead letter)。

 

    INDIVIDUAL_ACKNOWLEDGE : 单条消息确认,这种确认模式,我们很少使用,它的确认时机和CLIENT_ACKNOWLEDGE几乎一样,当消息消费成功之后,需要调用message.acknowledege来确认此消息(单条),而CLIENT_ACKNOWLEDGE模式先message.acknowledge()方法将导致整个session中所有消息被确认(批量确认)。

 

    结语:到目前为止,我们已经已经简单的了解了ActiveMQ中消息传送机制,还有JMS中ACK策略,重点分析了optimizeACK的策略,希望开发者能够在使用activeMQ中避免一些不必要的错误。本文如有疏漏和错误之处,请各位不吝赐教,特此感谢。

分享到:
评论

相关推荐

    基于FPGA的四相八拍步进电机控制系统设计:集成交付、正反转、加速减速及调速功能

    内容概要:本文详细介绍了基于FPGA的四相八拍步进电机控制系统的开发过程。主要内容包括:1. 使用VHDL和Verilog编写LED显示屏驱动代码,用于显示角度、学号和姓名等信息;2. 实现步进电机的正反转控制,通过状态机管理相序变化;3. 开发加速减速控制模块,确保电机启动和停止时的平稳性;4. 设计调速功能,通过调节脉冲频率实现速度控制。此外,文中还讨论了调试过程中遇到的问题及其解决方案。 适合人群:对FPGA开发和步进电机控制感兴趣的电子工程师、嵌入式系统开发者以及相关专业的学生。 使用场景及目标:适用于需要高精度运动控制的应用场合,如工业自动化、机器人技术和精密仪器等领域。目标是帮助读者掌握FPGA控制步进电机的基本原理和技术细节。 其他说明:文中提供了详细的代码片段和调试经验分享,有助于读者更好地理解和应用所学知识。同时,作者还提到了一些实用技巧,如通过PWM调节实现多级变速,以及如何避免步进电机的共振问题。

    Android开发:基于SQLite的日历备忘录记事本项目详解与实现

    内容概要:本文详细介绍了基于Android Studio开发的日历备忘录记事本项目,涵盖日历查看、添加备忘录、闹钟提醒和删除备忘录等功能。项目使用SQLite数据库进行数据存储,通过CalendarView、EditText、Button等控件实现用户交互,并利用AlarmManager和PendingIntent实现闹钟提醒功能。此外,项目还包括数据库的设计与管理,如创建DatabaseHelper类来管理数据库操作,确保数据的安全性和完整性。文章还探讨了一些常见的开发技巧和注意事项,如时间戳的使用、手势监听的实现等。 适用人群:适用于初学者和有一定经验的Android开发者,尤其是希望深入了解Android开发基础知识和技术细节的人群。 使用场景及目标:该项目旨在帮助开发者掌握Android开发的基本技能,包括UI设计、数据库操作、闹钟提醒机制等。通过实际项目练习,开发者能够更好地理解和应用这些技术,提升自己的开发能力。 其他说明:文中提到一些进阶任务,如用Room替换SQLite、增加分类标签、实现云端同步等,鼓励开发者进一步扩展和优化项目。同时,项目源码公开,便于学习和参考。

    Matlab实现基于SVM-Adaboost支持向量机结合Adaboost集成学习时间序列预测的详细项目实例(含完整的程序,GUI设计和代码详解)

    内容概要:本文档详细介绍了一个基于SVM(支持向量机)和Adaboost集成学习的时间序列预测项目。该项目旨在通过结合这两种强大算法,提升时间序列预测的准确性和稳定性。文档涵盖了项目的背景、目标、挑战及其解决方案,重点介绍了模型架构、数据预处理、特征选择、SVM训练、Adaboost集成、预测与误差修正等环节。此外,文档还探讨了模型在金融市场、气象、能源需求、交通流量和医疗健康等多个领域的应用潜力,并提出了未来改进的方向,如引入深度学习、多任务学习、联邦学习等先进技术。 适合人群:具备一定机器学习基础的研究人员和工程师,特别是那些从事时间序列预测工作的专业人士。 使用场景及目标:①用于金融市场、气象、能源需求、交通流量和医疗健康等领域的复杂时间序列数据预测;②通过结合SVM和Adaboost,提升预测模型的准确性和稳定性;③处理噪声数据,降低计算复杂度,提高模型的泛化能力和实时预测能力。 其他说明:文档不仅提供了详细的理论解释,还附有完整的Matlab代码示例和GUI设计指导,帮助读者理解和实践。此外,文档还讨论了模型的部署与应用,包括系统架构设计、实时数据流处理、可视化界面、GPU加速推理等方面的技术细节。

    #游戏之追逐奶酪123

    #游戏之追逐奶酪123

    威纶通触摸屏配方管理系统解析:宏程序、数据结构与UI设计

    内容概要:本文详细介绍了威纶通触摸屏配方管理系统的实现方法及其应用场景。首先,文章讲解了配方管理的基本概念和技术背景,强调了配方管理在工业自动化中的重要性。接着,通过具体的宏程序代码示例,展示了如何实现配方的保存、加载以及安全校验等功能。文中还提到配方数据结构的设计,如使用寄存器地址偏移来确保数据不冲突,并通过CSV文件格式方便地管理和维护配方数据。此外,文章深入探讨了UI设计方面的内容,包括动态图层技术和按钮交互效果的应用,使得用户界面更加友好和直观。最后,作者分享了一些实际项目中的经验和技巧,如文件操作的异常处理和宏指令调试方法。 适合人群:从事工业自动化领域的工程师和技术人员,尤其是对触摸屏配方管理系统感兴趣的读者。 使用场景及目标:适用于需要频繁切换设备参数的生产环境,如食品加工、注塑成型等行业。通过使用威纶通触摸屏配方管理系统,可以提高工作效率,减少人为错误,同时简化设备调试和维护流程。 其他说明:附带的工具包提供了完整的宏指令注释版、图库资源和调试工具,帮助用户更好地理解和应用该系统。

    张彩明-图形学简明教程 配书资源

    张彩明-图形学简明教程 PPT课件

    计算机术语.pdf

    计算机术语.pdf

    基于改进粒子群算法的微电网多目标优化调度模型与算法分析

    内容概要:本文详细介绍了利用改进粒子群算法(IPSO)进行微电网多目标优化调度的方法和技术。首先指出了传统粒子群算法(PSO)存在的局限性,如初始化随机性和易陷入局部最优等问题。接着提出了多种改进措施,包括混沌映射初始化、动态权重调整、自适应变异以及引入帕累托前沿机制等。文中通过具体的代码实例展示了这些改进的具体实现,并通过实验验证了改进后的算法在处理微电网优化调度问题时的有效性,尤其是在应对风光发电不确定性方面表现突出。此外,文章还讨论了实际应用场景中的约束处理方法,如功率平衡约束的修复策略,确保理论与实践相结合。 适合人群:对智能优化算法及其在电力系统特别是微电网中的应用感兴趣的科研人员、工程师及研究生。 使用场景及目标:适用于需要对微电网进行多目标优化调度的研究和工程项目,旨在提高微电网运行效率,降低成本并减少环境污染。通过学习本文提供的改进算法和技术手段,能够更好地理解和掌握如何针对特定业务场景定制化地改进经典优化算法。 其他说明:文章不仅提供了详细的理论分析和算法改进思路,还包括了大量的代码片段和实验结果,有助于读者深入理解并快速应用于实际项目中。

    S7-1200 PLC与组态王实现7车位3x3立体车库控制系统

    内容概要:本文详细介绍了基于西门子S7-1200 PLC和组态王的7车位3x3升降横移立体车库控制系统的设计与实现。主要内容涵盖IO分配、梯形图程序、接线图、组态画面设计以及安全防护逻辑等方面。文中强调了硬件互锁、软件互锁、模块化编程、精确控制和平移控制等关键技术点,并分享了一些调试经验和注意事项。此外,还讨论了光电传感器误触发、急停按钮处理、故障记录等实际应用中的挑战及其解决方案。 适合人群:从事工业自动化领域的工程师和技术人员,特别是熟悉PLC编程和组态软件使用的专业人员。 使用场景及目标:适用于需要设计和实施立体车库控制系统的工程项目。目标是帮助读者掌握S7-1200 PLC与组态王的具体应用方法,提高系统可靠性和安全性。 其他说明:文中提供了详细的代码片段和配置示例,有助于读者更好地理解和实践相关技术。同时,作者分享了许多宝贵的实战经验,对于初学者和有一定经验的技术人员都非常有价值。

    数据结构解析:线性表顺序表示的原理、操作及应用

    内容概要:本文详细介绍了线性表及其顺序表示的概念、原理和操作。线性表作为一种基础数据结构,通过顺序表示将元素按顺序存储在连续的内存空间中。文中解释了顺序表示的定义与原理,探讨了顺序表与数组的关系,并详细描述了顺序表的基本操作,包括初始化、插入、删除和查找。此外,文章分析了顺序表的优点和局限性,并讨论了其在数据库索引、图像处理和嵌入式系统中的实际应用。最后,对比了顺序表和链表的性能特点,帮助读者根据具体需求选择合适的数据结构。 适合人群:计算机科学专业的学生、软件开发人员以及对数据结构感兴趣的自学者。 使用场景及目标:①理解线性表顺序表示的原理和实现;②掌握顺序表的基本操作及其时间复杂度;③了解顺序表在实际应用中的优势和局限性;④学会根据应用场景选择合适的数据结构。 其他说明:本文不仅提供了理论知识,还附带了具体的代码实现,有助于读者更好地理解和实践线性表的相关概念和技术。

    计算机数学1 -5 重言式与蕴含式.pdf

    计算机数学1 -5 重言式与蕴含式.pdf

    风电永磁直驱发电并网系统的控制策略与仿真建模

    内容概要:本文详细介绍了风电永磁直驱发电并网系统的构成及其关键控制部分。首先探讨了真实的风速模型构建方法,利用MATLAB生成带有随机扰动和突风成分的风速曲线,用于模拟自然界的风况。接着深入解析了永磁电机的转速控制机制,特别是最大功率点跟踪(MPPT)算法的具体实现方式,以及如何通过PI控制器调节电磁转矩。随后讨论了并网过程中LCL滤波器的设计要点,确保谐波失真小于3%的同时保持系统稳定性。此外,还涉及到了网侧变流器的锁相环(PLL)设计,增强了其在电网电压跌落情况下的快速跟踪能力。最后讲述了整套系统联调时遇到的问题及解决方案,如协同惯量控制策略应对电网扰动等。 适合人群:从事风力发电研究的技术人员、高校相关专业师生、对新能源发电感兴趣的工程爱好者。 使用场景及目标:适用于希望深入了解永磁直驱风力发电系统的工作原理和技术细节的人群。目标是掌握从风速建模到最终并网控制的完整流程,能够独立进行系统仿真和优化。 其他说明:文中提供了大量具体的代码示例,涵盖MATLAB、Python、C等多种编程语言,有助于读者更好地理解和实践所介绍的内容。

    《基于yolov8的昆虫检测识别检测项目》(包含源码、完整数据集、部署教程)简单部署即可运行。功能完善、操作简单,适合毕设或课程设计.zip

    资源内项目源码是均来自个人的课程设计、毕业设计或者具体项目,代码都测试ok,包含核心指标曲线图、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果、标签分布图。都是运行成功后才上传资源,答辩评审绝对信服的,拿来就能用。放心下载使用!源码、数据集、部署说明一站式服务,拿来就能用的绝对好资源!!! 项目备注 1、该资源内项目代码都经过测试运行成功,功能ok的情况下才上传的,请放心下载使用! 2、本项目适合计算机相关专业(如计科、人工智能、通信工程、自动化、电子信息等)的在校学生、老师或者企业员工下载学习,也适合小白学习进阶,当然也可作为毕设项目、课程设计、大作业、项目初期立项演示等。 3、如果基础还行,也可在此代码基础上进行修改,以实现其他功能,也可用于毕设、课设、作业等。 下载后请首先打开README.dataset.txt文件,仅供学习参考, 切勿用于商业用途。

    辞郁报表设计器(2025-03-30)

    本程序使用于:思迅软件、科脉软件、百威软件、泰格软件、嬴通软件等。 安装配置完连接参数后,用默认管理员账号:辞郁,密码:ciyu登录,主界面左上角,双击输入管理员辞郁密码:ciyu 进入设计模式。下载内容中有详细示例截图。 辞郁POP打印工具是一款专业的打印解决方案,主要针对零售行业的商品POP促销单。它支持多种零售软件系统,包括但不限于思迅软件、科脉软件、百威软件、泰格软件和嬴通软件。这种工具的出现极大地便利了零售业者在商品推广和营销方面的操作,通过快速生成并打印商品促销单,帮助商家更好地吸引顾客、提升销售业绩。

    基于蒙特卡洛法的电动汽车负荷预测模型及其MATLAB实现与分析

    内容概要:本文详细介绍了利用蒙特卡洛法对电动汽车负荷进行预测的方法。首先解释了基本原理,即通过建立电动汽车出行时间、行驶里程和充电时间的概率模型,采用蒙特卡洛法进行抽样并累加每辆车的充电负荷,从而得出负荷预测结果。随后展示了具体的MATLAB代码实现,包括初始化参数设置、蒙特卡洛仿真循环、结果处理和可视化。代码中涉及到随机数生成、概率分布、数组操作等关键技术点。通过对不同类型的电动汽车(如私家车和出租车)进行建模,模拟了它们的充电行为,并分析了充电负荷的时间分布特点。最后讨论了模型的可扩展性和改进方向,如引入智能充电策略等。 适合人群:对电力系统、电动汽车技术和蒙特卡洛仿真方法感兴趣的科研人员、工程师和技术爱好者。 使用场景及目标:适用于研究和评估电动汽车对电网的影响,帮助规划和设计充电基础设施,确保电网稳定运行。同时,也为进一步优化充电策略提供了理论支持。 其他说明:文中提供的MATLAB代码可以作为学习和研究的基础,用户可以根据具体情况进行修改和完善。此外,还提到了一些常见的编程技巧和注意事项,有助于提高代码质量和效率。

    基于Python的电网故障仿真:序分量分析与应用

    内容概要:本文详细介绍了如何利用Python进行电网故障仿真,重点在于不同类型故障(单相接地、相间短路、相间短路接地)下的序分量分析。文中首先准备了必要的工具包,定义了系统参数,并通过具体的代码实例展示了如何计算和可视化各种故障状态下的正序、负序和零序分量。此外,还讨论了不同类型的故障对序分量的具体影响及其在继电保护中的应用。通过这些仿真,能够更好地理解和预测保护装置的动作特性。 适合人群:从事电力系统分析、继电保护设计以及相关领域的工程师和技术人员。 使用场景及目标:适用于研究和开发电力系统的故障检测和保护机制,帮助工程师们优化继电保护装置的参数设置,提高电力系统的稳定性和可靠性。 其他说明:文章强调了仿真过程中需要注意的关键点,如接地电阻设置、变压器接线方式、线路参数单位等,确保仿真结果的准确性。同时,提供了多个代码片段作为参考,便于读者快速上手实践。

    使用量子退火来优化6G网络中的路径选择-Quantum Annealing to optimize path selection in a 6G network-matlab

    6G中基于量子计算的路由 该代码使用量子退火来优化6G网络中的路径选择 基于图的网络,在考虑干扰和拥塞的同时,根据最短路径优化路由路径。

    S7-1200 PLC系统中Modbus RTU轮询、PLC间数据交互及流量PID控制的技术实现

    内容概要:本文详细介绍了基于西门子S7-1200 PLC系统的三个核心技术实现:Modbus RTU轮询、PLC间数据交互以及流量PID控制。对于Modbus RTU轮询,作者通过构建设备地址池并利用数组索引作为指针来高效管理39个不同类型设备的通信,确保了稳定的轮询机制。PLC间的S7通讯则通过精心规划DB块映射,实现了高效可靠的数据交换。而在流量PID控制方面,作者不仅解决了流量计信号毛刺的问题,还引入了前馈补偿以应对阀门间的耦合效应,最终达到了精确的流量控制。 适合人群:从事工业自动化领域的工程师和技术人员,尤其是那些正在使用或计划使用S7-1200 PLC进行复杂项目开发的人士。 使用场景及目标:适用于需要处理大量Modbus设备轮询、实现PLC间高效数据交互以及精准流量控制的工业自动化项目。目标是在提高系统稳定性的同时,优化各个功能模块的工作效率。 其他说明:文中提供了丰富的代码片段和实践经验分享,帮助读者更好地理解和应用相关技术。同时强调了一些容易忽视的关键细节,如设备地址池的设计、DB块的正确配置以及PID参数调整等。

    基于三菱PLC的注塑机控制系统设计:梯形图编程与触摸屏组态详解

    内容概要:本文详细介绍了基于三菱PLC的注塑机控制系统的设计方法,涵盖接线图与IO分配、梯形图程序设计以及触摸屏组态设计。首先明确了注塑机的基本控制需求如温度、压力和时间控制,然后具体讲解了PLC与注塑机各部件之间的连接方式,包括温度传感器、加热器等设备的接口配置。接着深入探讨了梯形图编程的具体实现,提供了多个实用的例子,如急停控制、温度控制等。对于触摸屏组态部分,则强调了如何利用三菱专用软件创建直观的操作界面,确保操作员可以方便地监控和调整各项参数。最后讨论了系统集成与测试的方法,确保所有组件协同工作无误。 适合人群:从事工业自动化领域的工程师和技术人员,尤其是对PLC编程和触摸屏应用有一定了解的人群。 使用场景及目标:适用于希望深入了解三菱PLC在注塑机控制中的应用,掌握从硬件选型、程序编写到最终调试全过程的专业人士。目标是帮助读者构建一个高效稳定的注塑机控制系统。 其他说明:文中提到许多实际操作经验和常见错误避免措施,有助于初学者快速入门并减少开发过程中遇到的问题。此外,还涉及到了一些高级特性,如通过Modbus TCP协议接入MES系统,为后续扩展提供了思路。

Global site tag (gtag.js) - Google Analytics