Saya menyiapkan cluster Artemis di Kubernetes dengan 3 grup master/slave:

activemq-artemis-master-0                               1/1     Running
activemq-artemis-master-1                               1/1     Running
activemq-artemis-master-2                               1/1     Running
activemq-artemis-slave-0                                0/1     Running
activemq-artemis-slave-1                                0/1     Running
activemq-artemis-slave-2                                0/1     Running

Versi Artemis adalah 2.17.0. Ini adalah konfigurasi cluster saya di master-0 broker.xml. Konfigurasinya sama untuk broker lain kecuali connector-ref diubah agar sesuai dengan broker:

<?xml version="1.0"?>
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.
<configuration xmlns="urn:activemq" xmlns:xi="" xmlns:xsi="" xsi:schemaLocation="urn:activemq /schema/artemis-configuration.xsd">
  <core xmlns="urn:activemq:core" xsi:schemaLocation="urn:activemq:core ">
    <!-- this could be ASYNCIO, MAPPED, NIO
           ASYNCIO: Linux Libaio
           MAPPED: mmap files
           NIO: Plain Java Files
       This value was determined through a calculation.
       Your system could perform 1.1 writes per millisecond
       on the current journal configuration.
       That translates as a sync write every 911999 nanoseconds.

       Note: If you specify 0 the system will perform writes directly to the disk.
             We recommend this to be 0 if you are using journalType=MAPPED and journal-datasync=false.
        When using ASYNCIO, this will determine the writing queue depth for libaio.
        You can verify the network health of a particular NIC by specifying the <network-check-NIC> element.
        Use this to use an HTTP server to validate the network
         <network-check-URL-list></network-check-URL-list> -->
    <!-- <network-check-period>10000</network-check-period> -->
    <!-- <network-check-timeout>1000</network-check-timeout> -->
    <!-- this is a comma separated list, no spaces, just DNS or IPs
           it should accept IPV6

           Warning: Make sure you understand your network topology as this is meant to validate if your network is valid.
                    Using IPs that could eventually disappear or be partially visible may defeat the purpose.
                    You can use a list of multiple IPs, and if any successful ping will make the server OK to continue running -->
    <!-- <network-check-list></network-check-list> -->
    <!-- use this to customize the ping used for ipv4 addresses -->
    <!-- <network-check-ping-command>ping -c 1 -t %d %s</network-check-ping-command> -->
    <!-- use this to customize the ping used for ipv6 addresses -->
    <!-- <network-check-ping6-command>ping6 -c 1 %2$s</network-check-ping6-command> -->
    <!-- how often we are looking for how many bytes are being used on the disk in ms -->
    <!-- once the disk hits this limit the system will block, or close the connection in certain protocols
           that won't support flow control. -->
    <!-- should the broker detect dead locks and other issues -->
    <!-- the system will enter into page mode once you hit this limit.
           This is an estimate in bytes of how much the messages are using in memory

            The system will use half of the available memory (-Xmx) by default for the global-max-size.
            You may specify a different value here if you need to customize it to your needs.


      <!-- useEpoll means: it will use Netty epoll if you are on a system (Linux) that supports it -->
      <!-- amqpCredits: The number of credits sent to AMQP producers -->
      <!-- amqpLowCredits: The server will send the # credits specified at amqpCredits at this low mark -->
      <!-- amqpDuplicateDetection: If you are not using duplicate detection, set this to false
                                      as duplicate detection requires applicationProperties to be parsed on the server. -->
      <!-- amqpMinLargeMessageSize: Determines how many bytes are considered large, so we start using files to hold their data.
                                       default: 102400, -1 would mean to disable large mesasge control -->
      <!-- Note: If an acceptor needs to be compatible with HornetQ and/or Artemis 1.x clients add
                    "anycastPrefix=jms.queue.;multicastPrefix=jms.topic." to the acceptor url.
                    See for more information. -->
      <!-- Acceptor for every supported protocol -->
      <acceptor name="artemis">tcp://;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true</acceptor>
      <!-- AMQP Acceptor.  Listens on default AMQP port for AMQP traffic.-->
      <acceptor name="amqp">tcp://;tcpReceiveBufferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpMinLargeMessageSize=102400;amqpDuplicateDetection=true</acceptor>
      <!-- STOMP Acceptor. -->
      <acceptor name="stomp">tcp://;tcpReceiveBufferSize=1048576;protocols=STOMP;useEpoll=true</acceptor>
      <!-- HornetQ Compatibility Acceptor.  Enables HornetQ Core and STOMP for legacy HornetQ clients. -->
      <acceptor name="hornetq">tcp://;multicastPrefix=jms.topic.;protocols=HORNETQ,STOMP;useEpoll=true</acceptor>
      <!-- MQTT Acceptor -->
      <acceptor name="mqtt">tcp://;tcpReceiveBufferSize=1048576;protocols=MQTT;useEpoll=true</acceptor>
      <security-setting match="#">
        <permission type="createNonDurableQueue" roles="amq"/>
        <permission type="deleteNonDurableQueue" roles="amq"/>
        <permission type="createDurableQueue" roles="amq"/>
        <permission type="deleteDurableQueue" roles="amq"/>
        <permission type="createAddress" roles="amq"/>
        <permission type="deleteAddress" roles="amq"/>
        <permission type="consume" roles="amq"/>
        <permission type="browse" roles="amq"/>
        <permission type="send" roles="amq"/>
        <!-- we need this otherwise ./artemis data imp wouldn't work -->
        <permission type="manage" roles="amq"/>
      <!-- if you define auto-create on certain queues, management has to be auto-create -->
      <address-setting match="">
        <!-- with -1 only the global-max-size is in use for limiting -->
      <!--default for catch all-->
      <address-setting match="#">
        <!-- with -1 only the global-max-size is in use for limiting -->
      <address name="DLQ">
          <queue name="DLQ"/>
      <address name="ExpiryQueue">
          <queue name="ExpiryQueue"/>
    <!-- Uncomment the following if you want to use the Standard LoggingActiveMQServerPlugin pluging to log in events
         <broker-plugin class-name="org.apache.activemq.artemis.core.server.plugin.impl.LoggingActiveMQServerPlugin">
            <property key="LOG_ALL_EVENTS" value="true"/>
            <property key="LOG_CONNECTION_EVENTS" value="true"/>
            <property key="LOG_SESSION_EVENTS" value="true"/>
            <property key="LOG_CONSUMER_EVENTS" value="true"/>
            <property key="LOG_DELIVERING_EVENTS" value="true"/>
            <property key="LOG_SENDING_EVENTS" value="true"/>
            <property key="LOG_INTERNAL_EVENTS" value="true"/>
      <connector name="activemq-artemis-master-0">tcp://activemq-artemis-master-0.activemq-artemis-master.svc.cluster.local:61616</connector>
      <connector name="activemq-artemis-slave-0">tcp://activemq-artemis-slave-0.activemq-artemis-slave.svc.cluster.local:61616</connector>
      <connector name="activemq-artemis-master-1">tcp://activemq-artemis-master-1.activemq-artemis-master.svc.cluster.local:61616</connector>
      <connector name="activemq-artemis-slave-1">tcp://activemq-artemis-slave-1.activemq-artemis-slave.svc.cluster.local:61616</connector>
      <connector name="activemq-artemis-master-2">tcp://activemq-artemis-master-2.activemq-artemis-master.svc.cluster.local:61616</connector>
      <connector name="activemq-artemis-slave-2">tcp://activemq-artemis-slave-2.activemq-artemis-slave.svc.cluster.local:61616</connector>
      <cluster-connection name="activemq-artemis">
        <!-- scale-down>true</scale-down -->
          <!--we need this for auto failback-->
  <core xmlns="urn:activemq:core">

Konsumen saya didefinisikan sebagai JmsListener di aplikasi Spring Boot. Selama konsumsi pesan dalam antrian, aplikasi Spring Boot mogok yang mengakibatkan kubernet menghapus pod dan membuat ulang pod baru. Namun, saya perhatikan bahwa pod baru tidak terhubung ke node Artemis yang sama, sehingga pesan yang tersisa dari koneksi sebelumnya tidak pernah digunakan.

Saya pikir inti dari penggunaan cluster adalah agar semua node Artemis bertindak sebagai satu unit untuk mengirimkan pesan ke konsumen terlepas dari node mana yang terhubung. Apakah aku salah? Jika cluster tidak dapat mengubah rute koneksi konsumen ke node yang benar (yang menyimpan pesan yang tersisa dari konsumen sebelumnya), lalu apa cara yang disarankan untuk menangani situasi ini?

user3304122 11 Mei 2021, 19:28

1 menjawab

Jawaban Terbaik

Pertama, penting untuk dicatat bahwa tidak ada fitur untuk membuat klien terhubung kembali ke broker yang terputus setelah klien crash/restart. Secara umum, klien seharusnya tidak terlalu peduli dengan broker yang terhubung dengannya; itulah salah satu tujuan utama skalabilitas horizontal.

Perlu juga dicatat bahwa jika jumlah pesan pada broker dan jumlah klien yang terhubung cukup rendah sehingga kondisi ini sering muncul, hampir pasti berarti Anda memiliki terlalu banyak broker di cluster Anda.

Karena itu, saya yakin alasan klien Anda tidak mendapatkan pesan yang diharapkan adalah karena Anda menggunakan redistribution-delay default (yaitu -1) yang berarti pesan tidak didistribusikan kembali ke node lain dalam cluster. Jika Anda ingin mengaktifkan redistribusi (seperti yang Anda lakukan) maka Anda harus mengaturnya ke >= 0, mis .:

      <address-setting match="#">

Anda dapat membaca lebih lanjut tentang redistribusi di dokumentasi.

Selain itu Anda mungkin ingin mempertimbangkan kembali topologi Anda secara umum. Biasanya jika Anda berada di lingkungan seperti cloud (misalnya yang menggunakan Kubernetes) di mana infrastruktur itu sendiri akan memulai ulang pod yang gagal, maka Anda tidak akan menggunakan konfigurasi master/slave. Anda cukup memasang jurnal pada pod yang terpisah (misalnya menggunakan NFSv4) sehingga ketika sebuah node gagal, ia akan di-restart dan kemudian terhubung kembali ke penyimpanan persistennya. Ini secara efektif memberikan ketersediaan tinggi kepada broker (yang dirancang untuk master/slave di luar lingkungan cloud).

Selain itu, satu instance ActiveMQ Artemis dapat menangani jutaan pesan per detik tergantung pada kasus penggunaan sehingga Anda mungkin tidak benar-benar membutuhkan 3 node langsung untuk beban yang diharapkan.

Catatan, ini adalah rekomendasi umum tentang keseluruhan arsitektur Anda dan tidak terkait langsung dengan pertanyaan Anda.

Justin Bertram 11 Mei 2021, 23:49