آشنایی با معماری ActiveMQ

به نرم‌افزار یا سخت‌افزاری که برای ارسال یا دریافت پیام در سیستم‌های توزیع شده استفاده می‌شود میان‌افزار پیام محور(Message-oriented middleware - MOM) می‌گویند. این امکان به طور معمول به صورت افزونه‌ای در سیستم‌های سخت‌افزاری یا نرم‌افزاری، برای جلوگیری از پیچیدگی استفاده می‌شود. از این میان‌افزار می‌توان مستقل از سیستم عامل یا زبان برنامه‌نویسی بهره برد.

Apache ActiveMQ یک میان افزار پیام محور(MOM) و جزء دسته‌ای از نرم افزارها است که پیام‌ها را بین برنامه‌ها ارسال می‎کند. با استفاده از ارتباطات نامتقارن استاندارد، ActiveMQ امکان loose coupling (اتصال سست) بین سرویس‌های یک برنامه را می‌دهد، که بیشتر این امکان برای پیام‌رسانی سازمانی و برنامه‌های توزیع شده الزامی است.

ActiveMQ یک پروژه‌ی منبع بازِ نوشته شده با جاواست که توسط بنیاد نرم افزار آپاچی توسعه یافته. آپاچی در حال حاضر دو نسخه از ActiveMQ را ارائه می‎دهد: Classic و Artemis که پس از تکامل Artemis و  گنجاندن تمام ویژگی‌های نسخه ی کلاسیک در آن، آپاچی تنها از Artemis پشتیبانی می‎کند.

ActiveMQ قابل مقایسه با سایر سیستم‌های پیام رسانی مانند Apache Kafka ، RabbitMQ و Amazon Simple Queue Service است. همچنین آمازون Amazon MQ را ارائه می‎دهد که یک پیاده سازی مدیریت شده از ActiveMQ Classic است. هر یک از این فناوری‌ها از پیام‌رسان سازمانی از طریق زیرساخت‌های loose coupling پشتیبانی می‌کنند.

در این پست، نحوه‌ی عملکرد ActiveMQ و برخی از معیارهای کلیدی آن را بررسی خواهیم کرد که می‎توانید برای درک عملکرد زیرساخت پیام رسانی خود، این معیار‌ها را مونیتور کنید.

ActiveMQ چگونه کار می‎کند؟

ActiveMQ پیام‌ها را بین برنامه‌های کلاینت ارسال می‌کند به این صورت که:

• Producers (تولیدکنندگان)، که پیام‌ها را ایجاد می‌کنند و برای تحویل ارسال می‌کنند.
• Consumers (مصرف‌کنندگانی) که پیام‌ها را دریافت و پردازش می‌کنند.
• Broker (کارگزار) ActiveMQ هر پیام را از طریق یک endpoint پیام رسانی به نام destination (مقصد) در ActiveMQ Classic یا یک آدرس در Artemis هدایت می‎کند.

 هر دو نسخه‌ی ActiveMQ قادر به پیام‌رسانی point-to-point هستند-که در آن broker هر پیام را به یکی از مصرف‌کنندگان موجود در یک الگوی چرخشی هدایت می‎کند- و هم‌چنین میتوانند به صورت "pub/sub" (publish/subscribe)  پیام‌رسانی کنند -که در آن broker هر پیامی را به هر مصرف‌کننده‌ای که در موضوع (در ActiveMQ Classic) یا آدرس (در ActiveMQ Artemis) مشترک است، تحویل می‎دهد-. نمودار زیر اجزای موجود در استقرار ActiveMQ Classic را نشان می‌‎دهد.

همان‌طور که در بالا نشان داده شد، کلاسیک پیام‌های point-to-point را از طریق QUEUE (صف)‌ و پیام‌های pub/sub را از طریق TOPIC (موضوع) ارسال می‌کند. ولی Artemis از صف برای پشتیبانی از هر دو نوع پیام و از انواع مسیریابی برای اعمال رفتار مورد نظر استفاده می‎کند. 

در پیام‌رسانی point-to-point، broker هر پیام را به یک آدرس که با مسیریابی anycast پیکربندی شده ارسال می‌کند و پیام در یک صف قرار می‌گیرد که توسط یک مصرف‌کننده بازیابی می‌شود. (هر آدرس anycast به طور معمول یک صف دارد، اما در صورت لزوم می‌تواند شامل چندین صف باشد، به عنوان مثال برای پشتیبانی از دسته‌ای از سرورهای ActiveMQ از چند صف استفاده میشود.) در مورد پیام‌رسانی pub/sub، آدرس حاوی یک صف برای هر اشتراک موضوع است و broker از نوع مسیریابی multicast برای ارسال یک کپی از هر پیام به هر صف استفاده می‎کند.

ActiveMQ عملکردی مخصوص در APIی Java Message Service (JMS)( سیستم پیام رسان جاوا) پیاده‌سازی می‎کند که استانداردی را برای ایجاد، ارسال و دریافت پیام‌ها تعریف می‎کند. برنامه‌های کلاینت ActiveMQ (تولیدکنندگان و مصرف‌کنندگان) نوشته شده در جاوا می‎توانند از JMS API برای ارسال و دریافت پیام استفاده کنند. علاوه بر این، هر دو نوع کلاسیک و آرتمیس از کلاینت‌های غیرJMS نوشته شده در Node.js، Ruby، PHP، Python و زبان‌های دیگر پشتیبانی می‌کنند که می‌توانند از طریق پروتکل‌های AMQP، MQTT و STOMP به بروکر ActiveMQ متصل شوند.

ActiveMQ پیام‌ها را به صورت نامتقارن ارسال می‎کند، بنابراین مصرف‌کنندگان لزوماً پیام‌ها را بلافاصله دریافت نمی‎کنند. وظیفه‌ی تولیدکننده برای نوشتن و ارسال پیام، با وظیفه‌ی مصرف‌کننده برای واکشی آن ارتباط ندارد. از آنجایی که ActiveMQ از یک broker به عنوان واسطه استفاده می‌کند، تولیدکنندگان و مصرف‌کنندگان از یکدیگر مستقل (و حتی بی‌اطلاع) هستند. به محض اینکه یک تولیدکننده پیامی را برای یک broker ارسال می‌کند، بدون توجه به اینکه مصرف‌کننده پیام را دریافت می‌کند یا نه، وظیفه آن کامل می‌شود. برعکس، هنگامی که یک مصرف‌کننده پیامی را از یک broker دریافت می‌کند، بدون اطلاع تولید کننده‌ای که پیام را ایجاد کرده است، این کار را انجام می‎دهد.

این نوع چیدمان، که در آن مصرف‌کنندگان بدون اطلاع از یکدیگر کار می‎کنند، به عنوان loose coupling شناخته می‌شود. مزایای loose coupling عبارتند از:

• توان عملیاتی بالا: از آنجایی که تولیدکنندگان نیازی به انتظار برای تایید مصرف‌کننده یا broker ندارند، می‎توانند به سرعت پیام ارسال کنند-ActiveMQ می‌تواند به هزاران پیام در ثانیه دست یابد.
• انعطاف پذیری: کلاینت‌ها می‌توانند به طور موقت در دسترس نباشند، به صورت پویا به محیط اضافه شوند، و حتی به زبانی جدید بازنویسی شوند، بدون اینکه روی کلاینت‌های دیگر تأثیر بگذارند یا باعث ایجاد خطا در فرآیند پیام‌رسانی شوند.
• ناهمگونی: کلاینت‌ها به طور مستقل عمل می‌کنند و با بروکر ActiveMQ ارتباط برقرار می‌کنند اما مستقیماً با یکدیگر ارتباط برقرار نمی‌کنند. در نتیجه، ممکن است به هر یک از زبان‌هایی که ActiveMQ پشتیبانی می‌کند نوشته شوند.

از آنجایی که اجزای معماری ActiveMQ مجزا از همند، شما باید بر تولیدکنندگان، مصرف‌کنندگان، مقصدها، آدرس‌ها و brokerها به‌طور کلی مونیتور کنید تا بتوانید متوجه علت هر مشکل احتمالی بشوید. به عنوان مثال، اگر متوجه شوید که خروجی تولیدکننده متوقف شده‌است، اینطور نیست که حتما مشکلی وجود دارد اما اگر با افزایش مصرف حافظه مقصد مرتبط باشد، می‌تواند یک تنگنا را در سیستم بزرگ‌تر نشان دهد. بعداً، ما به برخی از معیارهای خاص که به مونیتور کردن کلی ActiveMQ کمک می‎کند نگاه خواهیم کرد. اما ابتدا، واحد اساسی کار ActiveMQ (پیام) را بررسی می‎‌کنیم.

پیام‌ها

هر پیامی که ActiveMQ ارسال می‌کند بر اساس مشخصات JMS است و از هدرها، properties (خصوصیات) اختیاری و بدنه تشکیل شده است.

هدر‌ها

هدرهای پیام JMS حاوی فراداده (Meta Data) در مورد پیام است. هدرها در مشخصات JMS تعریف می‌شوند و مقادیر آنها یا در زمانی که سازنده پیام را ایجاد می‌کند یا در زمانی که ActiveMQ آن را ارسال می‌کند تنظیم می‌‎شود.

هدرها کیفیت‌هایی از پیام را منتقل می‎کنند که بر نحوه‌ی رفتار broker و کلاینت تأثیر می‌گذارد. بیایید به دو ویژگی کلیدی که ActiveMQ هنگام ارسال پیام‌ در نظر می‌گیرد نگاهی بیندازیم: 1-انقضا و 2-ماندگاری.

1-انقضای پیام

بسته به محتوا و هدف، یک پیام ممکن است پس از مدت زمان معینی ارزش خود را از دست بدهد. هنگامی که یک تولید کننده پیامی را ایجاد می‎کند، می‌تواند یک مقدار انقضا را در هدر پیام تنظیم کند. اگر اینطور نباشد، مقدار هدر خالی می‎ماند و پیام هرگز منقضی نمی‎شود.

ActiveMQ هر پیام منقضی شده‌ای را به جای ارائه‌ی آن، از صف‌ها و موضوعات خود دور می‌اندازد و انتظار می‌رود که مصرف‌کننده هر پیامی را که پس از انقضا، پردازش نشده باقی بماند نادیده بگیرد.

2-ماندگاری پیام

پیام‌های ActiveMQ به‌طور پیش‌فرض پایدار هستند، اما می‌توانید ماندگاری را بر اساس هر پیام یا تولیدکننده، پیکربندی کنید. هنگامی که یک persistent message (پیام دائمی) ارسال می‎کنید، broker پیام را قبل از تحویل گرفتن در دیسک ذخیره می کند. اگر broker در آن نقطه از کار بیفتد، یک کپی از پیام باقی می‌ماند و فرآیند ارسال پیام می‌تواند با راه اندازی مجدد broker بازیابی شود. از طرف دیگر، یک non-persistent message (پیام غیر‌دائمی) به طور معمول فقط در حافظه‌ی broker وجود دارد و در اتفاقی که باعث راه اندازی مجدد broker شود از بین می‌رود.

ارسال پیام‌های غیر دائمی به طور معول سریع‌تر است زیرا broker نیازی به اجرای عملیات نوشتن ندارد. پیام‌های غیر دائمی برای داده‌های کوتاه‌مدتی که در فواصل زمانی مکرر جایگزین می‌شوند، مانند به‌روزرسانی یک‌بار در دقیقه به ازای مکان هر آیتم، مناسب است.

Properties (ویژگی‌ها)

ویژگی ها راهی برای افزودن Meta Data اختیاری به پیام ارائه می‎دهند. ActiveMQ از برخی ویژگی هایی که در مشخصات JMS تعریف شده‌اند پشتیبانی می‌کند، تولیدکنندگان همچنین می‌توانند ویژگی ها را (به طور دلخواه و خارج از مشخصات JMS ) تعریف کرده و آنها را برای هر پیام اعمال کنند. مصرف‌کنندگان می‎توانند انتخابگرها را برای فیلتر کردن پیام‌ها بر اساس مقادیر موجود در ویژگی های پیام پیاده سازی کنند. به عنوان مثال، می‌توانید یک سازنده‌ی ActiveMQ را پیکربندی کنید تا یک ویژگی coin را به هر پیام، با مقدار heads یا tails ، متصل کند و همه آنها را به یک موضوع ارسال کند. شما می‎توانید دو مصرف‌کننده بنویسید - یک مصرف‌کننده‌ی heads و یک مصرف‌کننده‌ی tails - که در آن موضوع مشترک هستند اما فقط پیام‌هایی را با مقدار انتخابی ویژگی coin دریافت می‎‌کنند.

بدنه

محتوای یک پیام ActiveMQ بدنه‌ی آن است. بدنه‌ی یک پیام می‎تواند به صورت متنی یا داده‌های باینری باشد. (همچنین خالی بودن بدنه پیام قابل قبول است.) مقدار هدر پیام JMSType که به صراحت توسط سازنده هنگام ایجاد پیام تنظیم می‎‌شود، تعیین می‎‌کند که چه چیزی می‎تواند در بدنه‌ی پیام حمل شود: یک فایل، یک byte stream، یک شی جاوا، یک stream اولیه‌ی جاوا، مجموعه‌ای از جفت نام-مقدار، یا یک رشته‌ی متن.

برای اطلاعات بیشتر در مورد انواع پیام، به مستندات JMS مراجعه کنید.

حافظه و ذخیره سازی

ActiveMQ از حافظه برای ذخیره‌ی پیام هایی که در انتظار ارسال به مصرف‌کنندگان هستند استفاده می‎کند. هر پیام مقداری از حافظه را اشغال می‎کند (این مقدار بستگی به اندازه ی پیام دارد) تا زمانی که از صف خارج شود و به مصرف‌کننده تحویل داده شود. در آن مرحله، ActiveMQ حافظه‌ای را که برای آن پیام استفاده شده بود آزاد می‎کند. وقتی تولیدکنندگان سریع‌تر از مصرف‌کنندگان هستند (در یک بازه‌ی زمانی معین، نوبت‌بندی بیشتر از نوبت‌دهی وجود دارد) استفاده ActiveMQ از حافظه افزایش می‌یابد.

ActiveMQ همچنین پیام‌هایی را برای ذخیره‌سازی روی دیسک می‎نویسد. Classic و Artemis هر دو از paging (صفحه‌بندی) برای انتقال پیام‌ها به دیسک در صورت اتمام حافظه استفاده می‌کنند. هنگامی که ActiveMQ نیاز به ارسال آن پیام‌ها دارد، آنها از دیسک به حافظه بازگردانده می شوند. صفحه‌بندی پیام‌ها به دیسک و از دیسک باعث تأخیر می‌شود، اما به ActiveMQ اجازه می‌دهد تا حجم زیادی از پیام‌ها را بدون نیاز به حافظه‌ی کافی برای نگهداری همه آنها پردازش کند. صفحه‌بندی به‌طور پیش‌فرض فعال است، اما اختیاری است (شما می‌توانید آدرسی را پیکربندی کنید تا زمانی که هیچ حافظه‌ای برای ذخیره کردن پیام‌ها وجود ندارد، آن‌ها را کنار بگذارید).

در این بخش، نحوه‌ی استفاده‌ی ActiveMQ از حافظه و دیسک برای ذخیره‌ی پیام‌ها را بررسی خواهیم کرد.

حافظه

سیستم هاست مقداری از حافظه‌ی خود را به عنوان حافظه‌ی heap(پشته) برای JVM که ActiveMQ در آن اجرا می شود اختصاص می دهد. حداکثر اندازه ی پشته ی پیش فرض ActiveMQ در نسخه‌های متفاوت ActiveMQ و JVM متفاوت است. برای تعیین حداکثر درصد حافظه‌ی پشته‌ی JVM که ActiveMQ Classic می تواند استفاده کند، فرزندِ memoryUsage عنصرِ systemUsage را در فایل پیکربندی brokerِ (activemq.xml) تنظیم کنید. می‌توانید این را به عنوان درصدی از حافظه‌ی پشته‌ی JVM (به عنوان مثال <memoryUsage percentOfJvmHeap="60" />)، یا به صورت تعدادی بایت بیان کنید، همان‌طور که در زیر نشان داده شده است. (توجه داشته باشید که بسته به پیکربندی شما، عنصر broker شما ممکن است متفاوت از نمونه‌ی موجود در این مثال به نظر برسد.)

activemq.xml

<broker xmlns="http://activemq.apache.org/schema/core" brokerName="MY_BROKER">
[...]
    <systemUsage>
        <systemUsage>
            <memoryUsage>
                <memoryUsage limit="1 gb" />
            </memoryUsage>
        </systemUsage>
    </systemUsage>
[...]
</broker>

حافظه‌ی مشخص شده در عنصر memoryUsage باید در بین تمام صف‌ها و موضوعات broker به اشتراک گذاشته شود. همچنین هر مقصد ممکن است با یک محدودیت حافظه‌ی صریح، که در عنصر memoryLimit در داخل یک policyEntry اختیاری در فایل activemq.xml تعیین شده است، پیکربندی شود:

activemq.xml

<broker xmlns="http://activemq.apache.org/schema/core" brokerName="MY_BROKER">
[...]
    <destinationPolicy>
        <policyMap>
            <policyEntries>
                <policyEntry queue="MY_QUEUE" memoryLimit="100mb" />
                <policyEntry topic="MY_TOPIC" memoryLimit="50mb" />
            </policyEntries>
        </policyMap>
    </destinationPolicy>
[...]
</broker>

ActiveMQ Artemis از نیمی از حافظه‌ی موجود برای JVM استفاده می کند مگر اینکه این تخصیص حافظه را با تنظیم پارامتر global-max-size در فایل پیکربندی broker (broker.xml) مشخص کنید. اگر پیام‌هایی که در همه‌ی آدرس‌های broker نگهداری می‌شوند، به تمام فضای مشخص شده توسط global-max-size نیاز داشته باشند، Artemis پیام‌های جدید را به محض رسیدن در دیسک، صفحه‌بندی می‌کند. با تنظیم پارامتر max-size-bytes در عنصر address-setting در فایل broker.xml، می توانید حافظه‌ی موجود برای هر آدرس Artemis را به صورت اختیاری کنترل کنید. بدون مقدار max-size-bytes ، یک آدرس، منابع حافظه‌ی موجود در سطح broker را با تمام آدرس‌های دیگر، تا حد پیش‌فرض یا global-max-size تعریف‌شده، به اشتراک می‌گذارد.

قطعه کد زیر عنصر address-settings را از یک فایل نمونه در کد منبع ActiveMQ Artemis نشان می دهد. این عنصر، رفتار صفحه‌بندی دو آدرس (با نام‌های "pagingQueue" و "exampleQueue") را پیکربندی می‌کند و شامل یک پیکربندی catch-all است که برای همه ی آدرس‌های دیگر اعمال می‌شود (تعیین شده توسط match="#"). مقدار max-size-bytes در هر آدرس، حداکثر مقدار حافظه ای را که برای ذخیره ی پیام‌های آدرس استفاده می شود، تعیین می کند. Artemis از مقدار page-size-bytes برای تعیین اندازه‌ی هر فایل صفحه، روی دیسکی که پیام‌های صفحه‌بندی شده ی آدرس را ذخیره می کند، استفاده می کند. آرتمیس با صفحه‌بندی بیشتر پیام‌ها، فایل‌های صفحه دیگری با همان اندازه ایجاد می‌کند.

broker.xml

      <address-settings>
         <address-setting match="pagingQueue">
           <max-size-bytes>100000</max-size-bytes>
           <page-size-bytes>20000</page-size-bytes>
         </address-setting>

         <address-setting match="exampleQueue">
           <max-size-bytes>10Mb</max-size-bytes>
            <page-size-bytes>1Mb</page-size-bytes>
         </address-setting>

         <address-setting match="#">
           <max-size-bytes>10Mb</max-size-bytes>
           <page-size-bytes>1Mb</page-size-bytes>
         </address-setting>
      </address-settings>

هر دو نوع ActiveMQ (Classic و Artemis) به طور متفاوتی از حافظه برای پیام‌های غیر دائمی و پیام‌های دائمی استفاده می‌کنند. هر پیام غیر دائمی به محض رسیدن در حافظه ذخیره می شود. وقتی حافظه‌ی موجود پر شد، کلاسیک همه پیام‌ها را به دیسک منتقل می‌کند، اما آرتمیس پیام‌های موجود را در حافظه می‌گذارد و پیام‌های جدید را روی دیسک صفحه‌بندی می‌کند. هر پیام دائمی نیز به محض رسیدن در حافظه ذخیره می‌شود و همچنین در محل ذخیره ی پیام روی دیسک نوشته می‌شود. اگر حافظه دیگری در دسترس نباشد، پیام‌های دائمی ورودی مستقیماً در محل ذخیره‌ی پیام نوشته می‌شوند.

تا زمانی که حافظه‌ی موجود در مقصد یا آدرس تمام نشده باشد، پیام‌های دریافتی را می‌توان مستقیم از حافظه ارسال کرد، بدون اینکه هیچ گونه تأخیر مرتبط با فعالیت دیسک ایجاد شود. اگر پیام در حافظه موجود نباشد (یا به این دلیل که از حافظه به محل ذخیره‌ی  موقت منتقل شده است یا به این دلیل که زمانی که حافظه موجود پر شده است بر روی محل ذخیره‌ی  پیام نوشته شده است)، broker باید داده‌های پیام را از دیسک صفحه‌بندی کند تا آن را به یک مصرف‌کننده ارسال کند.

ذخیره سازی

می‌توانید مقدار فضای ذخیره‌سازی را که broker های کلاسیک شما برای پیام‌های دائمی در عنصر storeUsage فایل activemq.xml استفاده می‌کنند، مانند مثال زیر مشخص کنید:

activemq.xml

<systemUsage>
    <systemUsage>
        <storeUsage>
            <storeUsage limit="100 mb"/>
        </storeUsage>
    </systemUsage>
</systemUsage>

فضای ذخیره سازی پیام‌های غیر دائمی ActiveMQ Classic به طور جداگانه مشخص شده است. پیام‌های غیر دائمی تنها پس از اتمام حافظه در دسترس در حافظه نوشته می‌شوند. می‌توانید مقدار فضای ذخیره‌سازی مورد استفاده برای پیام‌های غیر دائمی را در عنصر tempUsage فایل activemq.xml مشخص کنید، که پیش‌فرض 50 گیگابایت است. می‎توانید این را به صورت درصدی از فضای دیسک موجود (percentLimit) یا به صورت مقداری بایت (مانند شکل زیر) پیکربندی کنید:

activemq.xml

<systemUsage>
    <systemUsage>
        <tempUsage>
            <tempUsage limit="100 mb"/>
        </tempUsage>
    </systemUsage>
</systemUsage>

ActiveMQ Classic از KahaDB به عنوان مکانیزم پیش فرض ذخیره‌ی پیام خود استفاده می‎کند و هم پیام‌های دائمی و هم پیام‌های غیر دائمی را ذخیره می‎کند.

منبع اصلی پیام آرتمیس، file journal است. برای اینکه ActiveMQ بتواند پیام‌ها را به طور موثر مدیریت کند، file journal طوری طراحی شده است که حرکت مورد نیاز head دیسک را هنگام استفاده از حافظه HDD به حداقل برساند (اگرچه ActiveMQ از ذخیره سازی SSD نیز پشتیبانی می‎کند). همان‌طور که در مستندات Artemis توضیح داده شده است، می‎توانید file journal را از طریق فایل broker.xml پیکربندی کنید.

هر دو نسخه از ذخیره ی پیام‌ها بوسیله‌ی JDBC نیز پشتیبانی می‎کنند. با استفاده از این پیکربندی، می‌توانید از میان تعدادی پایگاه داده ی SQL، مکانیزم ذخیره‌سازی‌ را که به بهترین وجه نیازهای شما را برای مقیاس‌پذیری و پشتیبانی برآورده می‌کند، انتخاب کنید. برای اطلاعات بیشتر در مورد استفاده از محل ذخیره‌ی پیام JDBC به مستندات ActiveMQ Classic و ActiveMQ Artemis مراجعه کنید.

ما به برخی از ویژگی‌های پیام‌های JMS و روش‌های مختلفی که ActiveMQ آنها را ذخیره و ارسال می‌کند، نگاه کرده‌ایم. اما کار ActiveMQ تا زمانی که پیامی به مصرف‌کننده تحویل داده نشود، تکمیل نمی‎شود. در بخش بعدی به نحوه‌ی برخورد مصرف‌کنندگان با پیام‌ها خواهیم پرداخت.

مصرف‌کنندگان

مصرف‌کنندگان برنامه‌هایی هستند که پیام‌هایی را که ActiveMQ ارسال می‌کند دریافت می‎کنند. در این بخش، ما به برخی از ویژگی‌های کلیدی که بر رفتار مصرف‌کنندگان تأثیر می‌گذارند نگاه می‌کنیم: اشتراک‌ها و تأیید.

اشتراک‌های Durable (بادوام) در مقایسه با اشتراک‌های nondurable (بی‌دوام)

یک مصرف‌کننده می‎تواند در یک موضوع به عنوان بادوام یا بی‌دوام مشترک شود. (دوام فقط برای پیام‌های درون یک موضوع اعمال می‌شود، نه در یک صف.) در مورد اشتراک بادوام، اگر مشترک در دسترس نباشد، ActiveMQ پیام‌ها را حفظ می‌کند و هنگامی که آن مشترک دوباره وصل می‎شود، پیام‌های جدیدی را که در زمان قطع بودنش برایش ارسال شده، دریافت می‌کند ولی یک مشترک بی‌دوام هیچ پیامی در مورد موضوع منتشر شده در زمان قطع بودنش، دریافت نمی‌کند.

تأیید پیام

برای اطمینان از دریافت پیام‌ها و (در صورت لزوم) برای جلوگیری از ارسال بیش از یک بار پیام ، ActiveMQ از تأیید پیام پشتیبانی می‎کند. هر مصرف‌کننده طوری پیکربندی شده است که تعیین می‎کند چه زمانی و چگونه پیامی را تأیید کند (یا به صورت خودکار پس از دریافت یا با فراخوانی صریح متد acknowledge ). معیارهای ActiveMQ هم برای Classic و هم برای Artemis اطلاعاتی درباره‌ی تعداد پیام‌های تأیید شده و پیام‌هایی که هنوز تأیید نشده نشان می‌دهند، اما معنای آن معیارها به حالت تأیید مصرف‌کننده بستگی دارد. افزایش در پیام‌های تایید نشده می‌تواند به این معنی باشد که مصرف‌کننده آفلاین است و نمی‌تواند پیام‌ها را دریافت کند، یا اینکه مصرف‌کننده با موفقیت فراخوانی تأیید manual خود را انجام نمی‌دهد.

جمع‌بندی

تا این‌جا ما توضیح داده‌ایم که ActiveMQ چیست و چگونه کار می‌کند و سپس به بررسی انواع ActiveMQ و تفاوت‌ها و ویژگی‌های شاخص آنها پرداختیم. در بخش بعدی، چند معیار مفید را معرفی خواهیم کرد تا به شما در درک نحوه‌ی مونیتور ActiveMQ کمک کند.