content/assets/js/8563703a.ac54c353.js

"use strict";(self.webpackChunkwebsite_next=self.webpackChunkwebsite_next||[]).push([[6870],{15680:(e,t,a)=>{a.d(t,{xA:()=>c,yg:()=>u});var n=a(96540);function s(e,t,a){return t in e?Object.defineProperty(e,t,{value:a,enumerable:!0,configurable:!0,writable:!0}):e[t]=a,e}function i(e,t){var a=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),a.push.apply(a,n)}return a}function r(e){for(var t=1;t<arguments.length;t++){var a=null!=arguments[t]?arguments[t]:{};t%2?i(Object(a),!0).forEach((function(t){s(e,t,a[t])})):Object.getOwnPropertyDescriptors?Object.defineProperties(e,Object.getOwnPropertyDescriptors(a)):i(Object(a)).forEach((function(t){Object.defineProperty(e,t,Object.getOwnPropertyDescriptor(a,t))}))}return e}function o(e,t){if(null==e)return{};var a,n,s=function(e,t){if(null==e)return{};var a,n,s={},i=Object.keys(e);for(n=0;n<i.length;n++)a=i[n],t.indexOf(a)>=0||(s[a]=e[a]);return s}(e,t);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(e);for(n=0;n<i.length;n++)a=i[n],t.indexOf(a)>=0||Object.prototype.propertyIsEnumerable.call(e,a)&&(s[a]=e[a])}return s}var l=n.createContext({}),p=function(e){var t=n.useContext(l),a=t;return e&&(a="function"==typeof e?e(t):r(r({},t),e)),a},c=function(e){var t=p(e.components);return n.createElement(l.Provider,{value:t},e.children)},d="mdxType",m={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},g=n.forwardRef((function(e,t){var a=e.components,s=e.mdxType,i=e.originalType,l=e.parentName,c=o(e,["components","mdxType","originalType","parentName"]),d=p(a),g=s,u=d["".concat(l,".").concat(g)]||d[g]||m[g]||i;return a?n.createElement(u,r(r({ref:t},c),{},{components:a})):n.createElement(u,r({ref:t},c))}));function u(e,t){var a=arguments,s=t&&t.mdxType;if("string"==typeof e||s){var i=a.length,r=new Array(i);r[0]=g;var o={};for(var l in t)hasOwnProperty.call(t,l)&&(o[l]=t[l]);o.originalType=e,o[d]="string"==typeof e?e:s,r[1]=o;for(var p=2;p<i;p++)r[p]=a[p];return n.createElement.apply(null,r)}return n.createElement.apply(null,a)}g.displayName="MDXCreateElement"},19365:(e,t,a)=>{a.d(t,{A:()=>r});var n=a(96540),s=a(20053);const i={tabItem:"tabItem_Ymn6"};function r(e){let{children:t,hidden:a,className:r}=e;return n.createElement("div",{role:"tabpanel",className:(0,s.A)(i.tabItem,r),hidden:a},t)}},11470:(e,t,a)=>{a.d(t,{A:()=>w});var n=a(58168),s=a(96540),i=a(20053),r=a(23104),o=a(56347),l=a(57485),p=a(31682),c=a(89466);function d(e){return function(e){return s.Children.map(e,(e=>{if(!e||(0,s.isValidElement)(e)&&function(e){const{props:t}=e;return!!t&&"object"==typeof t&&"value"in t}(e))return e;throw new Error(`Docusaurus error: Bad <Tabs> child <${"string"==typeof e.type?e.type:e.type.name}>: all children of the <Tabs> component should be <TabItem>, and every <TabItem> should have a unique "value" prop.`)}))?.filter(Boolean)??[]}(e).map((e=>{let{props:{value:t,label:a,attributes:n,default:s}}=e;return{value:t,label:a,attributes:n,default:s}}))}function m(e){const{values:t,children:a}=e;return(0,s.useMemo)((()=>{const e=t??d(a);return function(e){const t=(0,p.X)(e,((e,t)=>e.value===t.value));if(t.length>0)throw new Error(`Docusaurus error: Duplicate values "${t.map((e=>e.value)).join(", ")}" found in <Tabs>. Every value needs to be unique.`)}(e),e}),[t,a])}function g(e){let{value:t,tabValues:a}=e;return a.some((e=>e.value===t))}function u(e){let{queryString:t=!1,groupId:a}=e;const n=(0,o.W6)(),i=function(e){let{queryString:t=!1,groupId:a}=e;if("string"==typeof t)return t;if(!1===t)return null;if(!0===t&&!a)throw new Error('Docusaurus error: The <Tabs> component groupId prop is required if queryString=true, because this value is used as the search param name. You can also provide an explicit value such as queryString="my-search-param".');return a??null}({queryString:t,groupId:a});return[(0,l.aZ)(i),(0,s.useCallback)((e=>{if(!i)return;const t=new URLSearchParams(n.location.search);t.set(i,e),n.replace({...n.location,search:t.toString()})}),[i,n])]}function h(e){const{defaultValue:t,queryString:a=!1,groupId:n}=e,i=m(e),[r,o]=(0,s.useState)((()=>function(e){let{defaultValue:t,tabValues:a}=e;if(0===a.length)throw new Error("Docusaurus error: the <Tabs> component requires at least one <TabItem> children component");if(t){if(!g({value:t,tabValues:a}))throw new Error(`Docusaurus error: The <Tabs> has a defaultValue "${t}" but none of its children has the corresponding value. Available values are: ${a.map((e=>e.value)).join(", ")}. If you intend to show no default tab, use defaultValue={null} instead.`);return t}const n=a.find((e=>e.default))??a[0];if(!n)throw new Error("Unexpected error: 0 tabValues");return n.value}({defaultValue:t,tabValues:i}))),[l,p]=u({queryString:a,groupId:n}),[d,h]=function(e){let{groupId:t}=e;const a=function(e){return e?`docusaurus.tab.${e}`:null}(t),[n,i]=(0,c.Dv)(a);return[n,(0,s.useCallback)((e=>{a&&i.set(e)}),[a,i])]}({groupId:n}),y=(()=>{const e=l??d;return g({value:e,tabValues:i})?e:null})();(0,s.useLayoutEffect)((()=>{y&&o(y)}),[y]);return{selectedValue:r,selectValue:(0,s.useCallback)((e=>{if(!g({value:e,tabValues:i}))throw new Error(`Can't select invalid tab value=${e}`);o(e),p(e),h(e)}),[p,h,i]),tabValues:i}}var y=a(92303);const b={tabList:"tabList__CuJ",tabItem:"tabItem_LNqP"};function f(e){let{className:t,block:a,selectedValue:o,selectValue:l,tabValues:p}=e;const c=[],{blockElementScrollPositionUntilNextRender:d}=(0,r.a_)(),m=e=>{const t=e.currentTarget,a=c.indexOf(t),n=p[a].value;n!==o&&(d(t),l(n))},g=e=>{let t=null;switch(e.key){case"Enter":m(e);break;case"ArrowRight":{const a=c.indexOf(e.currentTarget)+1;t=c[a]??c[0];break}case"ArrowLeft":{const a=c.indexOf(e.currentTarget)-1;t=c[a]??c[c.length-1];break}}t?.focus()};return s.createElement("ul",{role:"tablist","aria-orientation":"horizontal",className:(0,i.A)("tabs",{"tabs--block":a},t)},p.map((e=>{let{value:t,label:a,attributes:r}=e;return s.createElement("li",(0,n.A)({role:"tab",tabIndex:o===t?0:-1,"aria-selected":o===t,key:t,ref:e=>c.push(e),onKeyDown:g,onClick:m},r,{className:(0,i.A)("tabs__item",b.tabItem,r?.className,{"tabs__item--active":o===t})}),a??t)})))}function N(e){let{lazy:t,children:a,selectedValue:n}=e;const i=(Array.isArray(a)?a:[a]).filter(Boolean);if(t){const e=i.find((e=>e.props.value===n));return e?(0,s.cloneElement)(e,{className:"margin-top--md"}):null}return s.createElement("div",{className:"margin-top--md"},i.map(((e,t)=>(0,s.cloneElement)(e,{key:t,hidden:e.props.value!==n}))))}function v(e){const t=h(e);return s.createElement("div",{className:(0,i.A)("tabs-container",b.tabList)},s.createElement(f,(0,n.A)({},e,t)),s.createElement(N,(0,n.A)({},e,t)))}function w(e){const t=(0,y.A)();return s.createElement(v,(0,n.A)({key:String(t)},e))}},51171:(e,t,a)=>{a.r(t),a.d(t,{assets:()=>c,contentTitle:()=>l,default:()=>u,frontMatter:()=>o,metadata:()=>p,toc:()=>d});var n=a(58168),s=(a(96540),a(15680)),i=a(11470),r=a(19365);const o={id:"concepts-messaging",title:"Messaging",sidebar_label:"Messaging"},l=void 0,p={unversionedId:"concepts-messaging",id:"version-3.0.x/concepts-messaging",title:"Messaging",description:"Pulsar is built on the publish-subscribe pattern (often abbreviated to pub-sub). In this pattern, producers publish messages to topics; consumers subscribe to those topics, process incoming messages, and send acknowledgments to the broker when processing is finished.",source:"@site/versioned_docs/version-3.0.x/concepts-messaging.md",sourceDirName:".",slug:"/concepts-messaging",permalink:"/docs/3.0.x/concepts-messaging",draft:!1,editUrl:"https://github.com/apache/pulsar-site/edit/main/versioned_docs/version-3.0.x/concepts-messaging.md",tags:[],version:"3.0.x",frontMatter:{id:"concepts-messaging",title:"Messaging",sidebar_label:"Messaging"},sidebar:"docsSidebar",previous:{title:"Overview",permalink:"/docs/3.0.x/concepts-overview"},next:{title:"Architecture",permalink:"/docs/3.0.x/concepts-architecture-overview"}},c={},d=[{value:"Messages",id:"messages",level:2},{value:"Acknowledgment",id:"acknowledgment",level:3},{value:"Negative acknowledgment",id:"negative-acknowledgment",level:3},{value:"Acknowledgment timeout",id:"acknowledgment-timeout",level:3},{value:"Retry letter topic",id:"retry-letter-topic",level:3},{value:"Dead letter topic",id:"dead-letter-topic",level:3},{value:"Compression",id:"compression",level:3},{value:"Batching",id:"batching",level:3},{value:"Chunking",id:"chunking",level:3},{value:"Handle consecutive chunked messages with one ordered consumer",id:"handle-consecutive-chunked-messages-with-one-ordered-consumer",level:4},{value:"Handle interwoven chunked messages with one ordered consumer",id:"handle-interwoven-chunked-messages-with-one-ordered-consumer",level:4},{value:"Enable Message Chunking",id:"enable-message-chunking",level:4},{value:"Topics",id:"topics",level:2},{value:"Namespaces",id:"namespaces",level:2},{value:"Subscriptions",id:"subscriptions",level:2},{value:"Subscription types",id:"subscription-types",level:3},{value:"Exclusive",id:"exclusive",level:4},{value:"Failover",id:"failover",level:4},{value:"Failover | Partitioned topics",id:"failover--partitioned-topics",level:5},{value:"Failover | Non-partitioned topics",id:"failover--non-partitioned-topics",level:5},{value:"Shared",id:"shared",level:4},{value:"Key_Shared",id:"key_shared",level:4},{value:"Auto-split Hash Range",id:"auto-split-hash-range",level:5},{value:"Auto-split Consistent Hashing",id:"auto-split-consistent-hashing",level:5},{value:"Sticky",id:"sticky",level:5},{value:"How to use them?",id:"how-to-use-them",level:5},{value:"Preserving order of processing",id:"preserving-order-of-processing",level:5},{value:"Batching for Key Shared Subscriptions",id:"batching-for-key-shared-subscriptions",level:5},{value:"Subscription modes",id:"subscription-modes",level:3},{value:"What is a subscription mode",id:"what-is-a-subscription-mode",level:4},{value:"When to use",id:"when-to-use",level:4},{value:"How to use",id:"how-to-use",level:4},{value:"Multi-topic subscriptions",id:"multi-topic-subscriptions",level:2},{value:"Partitioned topics",id:"partitioned-topics",level:2},{value:"Routing modes",id:"routing-modes",level:3},{value:"Ordering guarantee",id:"ordering-guarantee",level:3},{value:"Hashing scheme",id:"hashing-scheme",level:3},{value:"Non-persistent topics",id:"non-persistent-topics",level:2},{value:"Performance",id:"performance",level:3},{value:"Client API",id:"client-api",level:3},{value:"System topic",id:"system-topic",level:2},{value:"Message redelivery",id:"message-redelivery",level:2},{value:"Message retention and expiry",id:"message-retention-and-expiry",level:2},{value:"Message deduplication",id:"message-deduplication",level:2},{value:"Producer idempotency",id:"producer-idempotency",level:3},{value:"Deduplication and effectively-once semantics",id:"deduplication-and-effectively-once-semantics",level:3},{value:"Delayed message delivery",id:"delayed-message-delivery",level:2},{value:"Broker",id:"broker",level:3},{value:"Producer",id:"producer",level:3}],m={toc:d},g="wrapper";function u(e){let{components:t,...o}=e;return(0,s.yg)(g,(0,n.A)({},m,o,{components:t,mdxType:"MDXLayout"}),(0,s.yg)("p",null,"Pulsar is built on the ",(0,s.yg)("a",{parentName:"p",href:"https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern"},"publish-subscribe")," pattern (often abbreviated to pub-sub). In this pattern, ",(0,s.yg)("a",{parentName:"p",href:"#producers"},"producers")," publish messages to ",(0,s.yg)("a",{parentName:"p",href:"#topics"},"topics"),"; ",(0,s.yg)("a",{parentName:"p",href:"#consumers"},"consumers")," ",(0,s.yg)("a",{parentName:"p",href:"#subscription-types"},"subscribe")," to those topics, process incoming messages, and send ",(0,s.yg)("a",{parentName:"p",href:"#acknowledgment"},"acknowledgments")," to the broker when processing is finished."),(0,s.yg)("p",null,(0,s.yg)("img",{alt:"Pub-Sub",src:a(83611).A,width:"960",height:"540"})),(0,s.yg)("p",null,"When a subscription is created, Pulsar ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/concepts-architecture-overview#persistent-storage"},"retains")," all messages, even if the consumer is disconnected. The retained messages are discarded only when a consumer acknowledges that all these messages are processed successfully."),(0,s.yg)("p",null,"If the consumption of a message fails and you want this message to be consumed again, you can enable the ",(0,s.yg)("a",{parentName:"p",href:"#message-redelivery"},"message redelivery mechanism")," to request the broker to resend this message."),(0,s.yg)("h2",{id:"messages"},"Messages"),(0,s.yg)("p",null,'Messages are the basic "unit" of Pulsar. The following table lists the components of messages.'),(0,s.yg)("table",null,(0,s.yg)("thead",{parentName:"table"},(0,s.yg)("tr",{parentName:"thead"},(0,s.yg)("th",{parentName:"tr",align:"left"},"Component"),(0,s.yg)("th",{parentName:"tr",align:"left"},"Description"))),(0,s.yg)("tbody",{parentName:"table"},(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"Value / data payload"),(0,s.yg)("td",{parentName:"tr",align:"left"},"The data carried by the message. All Pulsar messages contain raw bytes, although message data can also conform to data ",(0,s.yg)("a",{parentName:"td",href:"/docs/3.0.x/schema-get-started"},"schemas"),".")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"Key"),(0,s.yg)("td",{parentName:"tr",align:"left"},"The key (string type) of the message. It is a short name of message key or partition key. Messages are optionally tagged with keys, which is useful for features like ",(0,s.yg)("a",{parentName:"td",href:"/docs/3.0.x/concepts-topic-compaction"},"topic compaction"),".")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"Properties"),(0,s.yg)("td",{parentName:"tr",align:"left"},"An optional key/value map of user-defined properties.")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"Producer name"),(0,s.yg)("td",{parentName:"tr",align:"left"},"The name of the producer who produces the message. If you do not specify a producer name, the default name is used.")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"Topic name"),(0,s.yg)("td",{parentName:"tr",align:"left"},"The name of the topic that the message is published to.")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"Schema version"),(0,s.yg)("td",{parentName:"tr",align:"left"},"The version number of the schema that the message is produced with.")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"Sequence ID"),(0,s.yg)("td",{parentName:"tr",align:"left"},"Each Pulsar message belongs to an ordered sequence on its topic. The sequence ID of a message is initially assigned by its producer, indicating its order in that sequence, and can also be customized.",(0,s.yg)("br",null),"Sequence ID can be used for message deduplication. If ",(0,s.yg)("inlineCode",{parentName:"td"},"brokerDeduplicationEnabled")," is set to ",(0,s.yg)("inlineCode",{parentName:"td"},"true"),", the sequence ID of each message is unique within a producer of a topic (non-partitioned) or a partition.")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"Message ID"),(0,s.yg)("td",{parentName:"tr",align:"left"},"The message ID of a message is assigned by bookies as soon as the message is persistently stored. Message ID indicates a message's specific position in a ledger and is unique within a Pulsar cluster.")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"Publish time"),(0,s.yg)("td",{parentName:"tr",align:"left"},"The timestamp of when the message is published. The timestamp is automatically applied by the producer.")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"Event time"),(0,s.yg)("td",{parentName:"tr",align:"left"},"An optional timestamp attached to a message by applications. For example, applications attach a timestamp on when the message is processed. If nothing is set to event time, the value is ",(0,s.yg)("inlineCode",{parentName:"td"},"0"),".")))),(0,s.yg)("p",null,"The default max size of a message is 5 MB. You can configure the max size of a message with the following configuration options."),(0,s.yg)("ul",null,(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("p",{parentName:"li"},"In the ",(0,s.yg)("inlineCode",{parentName:"p"},"broker.conf")," file."),(0,s.yg)("pre",{parentName:"li"},(0,s.yg)("code",{parentName:"pre",className:"language-bash"},"# The max size of a message (in bytes).\nmaxMessageSize=5242880\n"))),(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("p",{parentName:"li"},"In the ",(0,s.yg)("inlineCode",{parentName:"p"},"bookkeeper.conf")," file."),(0,s.yg)("pre",{parentName:"li"},(0,s.yg)("code",{parentName:"pre",className:"language-bash"},"# The max size of the netty frame (in bytes). Any messages received larger than this value are rejected. The default value is 5 MB.\nnettyMaxFrameSizeBytes=5253120\n")))),(0,s.yg)("blockquote",null,(0,s.yg)("p",{parentName:"blockquote"},"For more information on Pulsar messages, see Pulsar ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/developing-binary-protocol"},"binary protocol"),".")),(0,s.yg)("h3",{id:"acknowledgment"},"Acknowledgment"),(0,s.yg)("p",null,"The consumer sends an acknowledgment request to the broker after it consumes a message successfully. Then, this consumed message will be permanently stored, and deleted only after all the subscriptions have acknowledged it. If you want to store the messages that have been acknowledged by a consumer, you need to configure the ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/concepts-messaging#message-retention-and-expiry"},"message retention policy"),"."),(0,s.yg)("p",null,"For batch messages, you can enable batch index acknowledgment to avoid dispatching acknowledged messages to the consumer. For details about batch index acknowledgment, see ",(0,s.yg)("a",{parentName:"p",href:"#batching"},"batching"),"."),(0,s.yg)("p",null,"Messages can be acknowledged in one of the following two ways:"),(0,s.yg)("ul",null,(0,s.yg)("li",{parentName:"ul"},"Being acknowledged individually. With individual acknowledgment, the consumer acknowledges each message and sends an acknowledgment request to the broker."),(0,s.yg)("li",{parentName:"ul"},"Being acknowledged cumulatively. With cumulative acknowledgment, the consumer ",(0,s.yg)("strong",{parentName:"li"},"only")," acknowledges the last message it received. All messages in the stream up to (and including) the provided message are not redelivered to that consumer.")),(0,s.yg)("p",null,"If you want to acknowledge messages individually, you can use the following API."),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},"consumer.acknowledge(msg);\n")),(0,s.yg)("p",null,"If you want to acknowledge messages cumulatively, you can use the following API."),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},"consumer.acknowledgeCumulative(msg);\n")),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("p",{parentName:"admonition"},"Cumulative acknowledgment cannot be used in ",(0,s.yg)("a",{parentName:"p",href:"#subscription-types"},"Shared subscription type"),", because Shared subscription type involves multiple consumers which have access to the same subscription. In Shared subscription type, messages are acknowledged individually.")),(0,s.yg)("h3",{id:"negative-acknowledgment"},"Negative acknowledgment"),(0,s.yg)("p",null,"The ",(0,s.yg)("a",{parentName:"p",href:"#negative-acknowledgment"},"negative acknowledgment")," mechanism allows you to send a notification to the broker indicating the consumer did not process a message.  When a consumer fails to consume a message and needs to re-consume it, the consumer sends a negative acknowledgment (nack) to the broker, triggering the broker to redeliver this message to the consumer."),(0,s.yg)("p",null,"Messages are negatively acknowledged individually or cumulatively, depending on the consumption subscription type."),(0,s.yg)("p",null,"In Exclusive and Failover subscription types, consumers only negatively acknowledge the last message they receive."),(0,s.yg)("p",null,"In Shared and Key_Shared subscription types, consumers can negatively acknowledge messages individually."),(0,s.yg)("p",null,"Be aware that negative acknowledgments on ordered subscription types, such as Exclusive, Failover and Key_Shared, might cause failed messages being sent to consumers out of the original order."),(0,s.yg)("p",null,"If you are going to use negative acknowledgment on a message, make sure it is negatively acknowledged before the acknowledgment timeout."),(0,s.yg)("p",null,"Use the following API to negatively acknowledge message consumption."),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},'Consumer<byte[]> consumer = pulsarClient.newConsumer()\n                .topic(topic)\n                .subscriptionName("sub-negative-ack")\n                .subscriptionInitialPosition(SubscriptionInitialPosition.Earliest)\n                .negativeAckRedeliveryDelay(2, TimeUnit.SECONDS) // the default value is 1 min\n                .subscribe();\n\nMessage<byte[]> message = consumer.receive();\n\n// call the API to send negative acknowledgment\nconsumer.negativeAcknowledge(message);\n\nmessage = consumer.receive();\nconsumer.acknowledge(message);\n')),(0,s.yg)("p",null,"To redeliver messages with different delays, you can use the ",(0,s.yg)("strong",{parentName:"p"},"redelivery backoff mechanism")," by setting the number of retries to deliver the messages.\nUse the following API to enable ",(0,s.yg)("inlineCode",{parentName:"p"},"Negative Redelivery Backoff"),"."),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},'Consumer<byte[]> consumer = pulsarClient.newConsumer()\n        .topic(topic)\n        .subscriptionName("sub-negative-ack")\n        .subscriptionInitialPosition(SubscriptionInitialPosition.Earliest)\n        .negativeAckRedeliveryBackoff(MultiplierRedeliveryBackoff.builder()\n            .minDelayMs(1000)\n            .maxDelayMs(60 * 1000)\n            .multiplier(2)\n            .build())\n        .subscribe();\n')),(0,s.yg)("p",null,"The message redelivery behavior should be as follows."),(0,s.yg)("table",null,(0,s.yg)("thead",{parentName:"table"},(0,s.yg)("tr",{parentName:"thead"},(0,s.yg)("th",{parentName:"tr",align:"left"},"Redelivery count"),(0,s.yg)("th",{parentName:"tr",align:"left"},"Redelivery delay"))),(0,s.yg)("tbody",{parentName:"table"},(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"1"),(0,s.yg)("td",{parentName:"tr",align:"left"},"1 seconds")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"2"),(0,s.yg)("td",{parentName:"tr",align:"left"},"2 seconds")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"3"),(0,s.yg)("td",{parentName:"tr",align:"left"},"4 seconds")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"4"),(0,s.yg)("td",{parentName:"tr",align:"left"},"8 seconds")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"5"),(0,s.yg)("td",{parentName:"tr",align:"left"},"16 seconds")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"6"),(0,s.yg)("td",{parentName:"tr",align:"left"},"32 seconds")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"7"),(0,s.yg)("td",{parentName:"tr",align:"left"},"60 seconds")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"8"),(0,s.yg)("td",{parentName:"tr",align:"left"},"60 seconds")))),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("p",{parentName:"admonition"},"If batching is enabled, all messages in one batch are redelivered to the consumer.")),(0,s.yg)("h3",{id:"acknowledgment-timeout"},"Acknowledgment timeout"),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("p",{parentName:"admonition"},"By default, the acknowledge timeout is disabled and that means that messages delivered to a consumer will not be re-delivered unless the consumer crashes.")),(0,s.yg)("p",null,"The acknowledgment timeout mechanism allows you to set a time range during which the client tracks the unacknowledged messages. After this acknowledgment timeout (",(0,s.yg)("inlineCode",{parentName:"p"},"ackTimeout"),") period, the client sends ",(0,s.yg)("inlineCode",{parentName:"p"},"redeliver unacknowledged messages")," request to the broker, thus the broker resends the unacknowledged messages to the consumer."),(0,s.yg)("p",null,"You can configure the acknowledgment timeout mechanism to redeliver the message if it is not acknowledged after ",(0,s.yg)("inlineCode",{parentName:"p"},"ackTimeout")," or to execute a timer task to check the acknowledgment timeout messages during every ",(0,s.yg)("inlineCode",{parentName:"p"},"ackTimeoutTickTime")," period."),(0,s.yg)("p",null,"You can also use the redelivery backoff mechanism to redeliver messages with different delays by setting the number of times the messages are retried."),(0,s.yg)("p",null,"If you want to use redelivery backoff, you can use the following API."),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},"consumer.ackTimeout(10, TimeUnit.SECOND)\n        .ackTimeoutRedeliveryBackoff(MultiplierRedeliveryBackoff.builder()\n            .minDelayMs(1000)\n            .maxDelayMs(60 * 1000)\n            .multiplier(2)\n            .build());\n")),(0,s.yg)("p",null,"The message redelivery behavior should be as follows."),(0,s.yg)("table",null,(0,s.yg)("thead",{parentName:"table"},(0,s.yg)("tr",{parentName:"thead"},(0,s.yg)("th",{parentName:"tr",align:"left"},"Redelivery count"),(0,s.yg)("th",{parentName:"tr",align:"left"},"Redelivery delay"))),(0,s.yg)("tbody",{parentName:"table"},(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"1"),(0,s.yg)("td",{parentName:"tr",align:"left"},"10 + 1 seconds")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"2"),(0,s.yg)("td",{parentName:"tr",align:"left"},"10 + 2 seconds")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"3"),(0,s.yg)("td",{parentName:"tr",align:"left"},"10 + 4 seconds")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"4"),(0,s.yg)("td",{parentName:"tr",align:"left"},"10 + 8 seconds")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"5"),(0,s.yg)("td",{parentName:"tr",align:"left"},"10 + 16 seconds")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"6"),(0,s.yg)("td",{parentName:"tr",align:"left"},"10 + 32 seconds")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"7"),(0,s.yg)("td",{parentName:"tr",align:"left"},"10 + 60 seconds")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"8"),(0,s.yg)("td",{parentName:"tr",align:"left"},"10 + 60 seconds")))),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("ul",{parentName:"admonition"},(0,s.yg)("li",{parentName:"ul"},"If batching is enabled, all messages in one batch are redelivered to the consumer."),(0,s.yg)("li",{parentName:"ul"},"Compared with acknowledgment timeout, negative acknowledgment is preferred. First, it is difficult to set a timeout value. Second, a broker resends messages when the message processing time exceeds the acknowledgment timeout, but these messages might not need to be re-consumed."))),(0,s.yg)("p",null,"Use the following API to enable acknowledgment timeout."),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},'Consumer<byte[]> consumer = pulsarClient.newConsumer()\n                .topic(topic)\n                .ackTimeout(2, TimeUnit.SECONDS) // the default value is 0\n                .ackTimeoutTickTime(1, TimeUnit.SECONDS)\n                .subscriptionName("sub")\n                .subscriptionInitialPosition(SubscriptionInitialPosition.Earliest)\n                .subscribe();\n\nMessage<byte[]> message = consumer.receive();\n\n// wait at least 2 seconds\nmessage = consumer.receive();\nconsumer.acknowledge(message);\n')),(0,s.yg)("h3",{id:"retry-letter-topic"},"Retry letter topic"),(0,s.yg)("p",null,"Retry letter topic allows you to store the messages that failed to be consumed and retry consuming them later. With this method, you can customize the interval at which the messages are redelivered. Consumers on the original topic are automatically subscribed to the retry letter topic as well. Once the maximum number of retries has been reached, the unconsumed messages are moved to a ",(0,s.yg)("a",{parentName:"p",href:"#dead-letter-topic"},"dead letter topic")," for manual processing. The functionality of a retry letter topic is implemented by consumers."),(0,s.yg)("p",null,"The diagram below illustrates the concept of the retry letter topic.\n",(0,s.yg)("img",{src:a(63249).A,width:"959",height:"420"})),(0,s.yg)("p",null,"The intention of using retry letter topic is different from using ",(0,s.yg)("a",{parentName:"p",href:"#delayed-message-delivery"},"delayed message delivery"),", even though both are aiming to consume a message later. Retry letter topic serves failure handling through message redelivery to ensure critical data is not lost, while delayed message delivery is intended to deliver a message with a specified time delay."),(0,s.yg)("p",null,"By default, automatic retry is disabled. You can set ",(0,s.yg)("inlineCode",{parentName:"p"},"enableRetry")," to ",(0,s.yg)("inlineCode",{parentName:"p"},"true")," to enable automatic retry on the consumer."),(0,s.yg)("p",null,"Use the following API to consume messages from a retry letter topic. When the value of ",(0,s.yg)("inlineCode",{parentName:"p"},"maxRedeliverCount")," is reached, the unconsumed messages are moved to a dead letter topic."),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},'Consumer<byte[]> consumer = pulsarClient.newConsumer(Schema.BYTES)\n                .topic("my-topic")\n                .subscriptionName("my-subscription")\n                .subscriptionType(SubscriptionType.Shared)\n                .enableRetry(true)\n                .deadLetterPolicy(DeadLetterPolicy.builder()\n                        .maxRedeliverCount(maxRedeliveryCount)\n                        .build())\n                .subscribe();\n')),(0,s.yg)("p",null,"The default retry letter topic uses this format:"),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-text"},"<topicname>-<subscriptionname>-RETRY\n")),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("ul",{parentName:"admonition"},(0,s.yg)("li",{parentName:"ul"},"For Pulsar 2.6.x and 2.7.x, the default retry letter topic uses the format of ",(0,s.yg)("inlineCode",{parentName:"li"},"<subscriptionname>-RETRY"),". If you upgrade from 2.6.x~2.7.x to 2.8.x or later, you need to delete historical retry letter topics and retry letter partitioned topics. Otherwise, Pulsar continues to use original topics, which are formatted with ",(0,s.yg)("inlineCode",{parentName:"li"},"<subscriptionname>-RETRY"),"."),(0,s.yg)("li",{parentName:"ul"},"It is not recommended to use ",(0,s.yg)("inlineCode",{parentName:"li"},"<subscriptionname>-RETRY")," because if multiple topics under the same namespace have the same subscription, then retry message topic names for multiple topics might be the same, which will result in mutual consumptions."))),(0,s.yg)("p",null,"Use the Java client to specify the name of the retry letter topic."),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},'Consumer<byte[]> consumer = pulsarClient.newConsumer(Schema.BYTES)\n        .topic("my-topic")\n        .subscriptionName("my-subscription")\n        .subscriptionType(SubscriptionType.Shared)\n        .enableRetry(true)\n        .deadLetterPolicy(DeadLetterPolicy.builder()\n                .maxRedeliverCount(maxRedeliveryCount)\n                .retryLetterTopic("my-retry-letter-topic-name")\n                .build())\n        .subscribe();\n')),(0,s.yg)("p",null,"The messages in the retry letter topic contain some special properties that are automatically created by the client."),(0,s.yg)("table",null,(0,s.yg)("thead",{parentName:"table"},(0,s.yg)("tr",{parentName:"thead"},(0,s.yg)("th",{parentName:"tr",align:"left"},"Special property"),(0,s.yg)("th",{parentName:"tr",align:"left"},"Description"))),(0,s.yg)("tbody",{parentName:"table"},(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},(0,s.yg)("inlineCode",{parentName:"td"},"REAL_TOPIC")),(0,s.yg)("td",{parentName:"tr",align:"left"},"The real topic name.")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},(0,s.yg)("inlineCode",{parentName:"td"},"ORIGIN_MESSAGE_ID")),(0,s.yg)("td",{parentName:"tr",align:"left"},"The origin message ID. It is crucial for message tracking.")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},(0,s.yg)("inlineCode",{parentName:"td"},"RECONSUMETIMES")),(0,s.yg)("td",{parentName:"tr",align:"left"},"The number of retries to consume messages.")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},(0,s.yg)("inlineCode",{parentName:"td"},"DELAY_TIME")),(0,s.yg)("td",{parentName:"tr",align:"left"},"Message retry interval in milliseconds.")))),(0,s.yg)("p",null,(0,s.yg)("strong",{parentName:"p"},"Example")),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-conf"},"REAL_TOPIC = persistent://public/default/my-topic\nORIGIN_MESSAGE_ID = 1:0:-1:0\nRECONSUMETIMES = 6\nDELAY_TIME = 3000\n")),(0,s.yg)("p",null,"Use the following API to store the messages in a retrial queue."),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},"consumer.reconsumeLater(msg, 3, TimeUnit.SECONDS);\n")),(0,s.yg)("p",null,"Use the following API to add custom properties for the ",(0,s.yg)("inlineCode",{parentName:"p"},"reconsumeLater")," function. In the next attempt to consume, custom properties can be get from message#getProperty."),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},'Map<String, String> customProperties = new HashMap<String, String>();\ncustomProperties.put("custom-key-1", "custom-value-1");\ncustomProperties.put("custom-key-2", "custom-value-2");\nconsumer.reconsumeLater(msg, customProperties, 3, TimeUnit.SECONDS);\n')),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("ul",{parentName:"admonition"},(0,s.yg)("li",{parentName:"ul"},"Currently, retry letter topic is enabled in Shared subscription types."),(0,s.yg)("li",{parentName:"ul"},"Compared with negative acknowledgment, retry letter topic is more suitable for messages that require a large number of retries with a configurable retry interval. Because messages in the retry letter topic are persisted to BookKeeper, while messages that need to be retried due to negative acknowledgment are cached on the client side."))),(0,s.yg)("h3",{id:"dead-letter-topic"},"Dead letter topic"),(0,s.yg)("p",null,"Dead letter topic allows you to continue message consumption even when some messages are not consumed successfully. The messages that have failed to be consumed are stored in a specific topic, which is called the dead letter topic. The functionality of a dead letter topic is implemented by consumers. You can decide how to handle the messages in the dead letter topic."),(0,s.yg)("p",null,"Enable dead letter topic in a Java client using the default dead letter topic."),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},'Consumer<byte[]> consumer = pulsarClient.newConsumer(Schema.BYTES)\n                .topic("my-topic")\n                .subscriptionName("my-subscription")\n                .subscriptionType(SubscriptionType.Shared)\n                .deadLetterPolicy(DeadLetterPolicy.builder()\n                      .maxRedeliverCount(maxRedeliveryCount)\n                      .build())\n                .subscribe();\n')),(0,s.yg)("p",null,"The default dead letter topic uses this format:"),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre"},"<topicname>-<subscriptionname>-DLQ\n")),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("ul",{parentName:"admonition"},(0,s.yg)("li",{parentName:"ul"},"For Pulsar 2.6.x and 2.7.x, the default dead letter topic uses the format of ",(0,s.yg)("inlineCode",{parentName:"li"},"<subscriptionname>-DLQ"),". If you upgrade from 2.6.x~2.7.x to 2.8.x or later, you need to delete historical dead letter topics and retry letter partitioned topics. Otherwise, Pulsar continues to use original topics, which are formatted with ",(0,s.yg)("inlineCode",{parentName:"li"},"<subscriptionname>-DLQ"),"."),(0,s.yg)("li",{parentName:"ul"},"It is not recommended to use ",(0,s.yg)("inlineCode",{parentName:"li"},"<subscriptionname>-DLQ")," because if multiple topics under the same namespace have the same subscription, then dead message topic names for multiple topics might be the same, which will result in mutual consumptions."))),(0,s.yg)("p",null,"Use the Java client to specify the name of the dead letter topic."),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},'Consumer<byte[]> consumer = pulsarClient.newConsumer(Schema.BYTES)\n                .topic("my-topic")\n                .subscriptionName("my-subscription")\n                .subscriptionType(SubscriptionType.Shared)\n                .deadLetterPolicy(DeadLetterPolicy.builder()\n                      .maxRedeliverCount(maxRedeliveryCount)\n                      .deadLetterTopic("my-dead-letter-topic-name")\n                      .build())\n                .subscribe();\n')),(0,s.yg)("p",null,"By default, there is no subscription during DLQ topic creation. Without a just-in-time subscription to the DLQ topic, you may lose messages. To automatically create an initial subscription for the DLQ, you can specify the ",(0,s.yg)("inlineCode",{parentName:"p"},"initialSubscriptionName")," parameter. If this parameter is set but the broker's ",(0,s.yg)("inlineCode",{parentName:"p"},"allowAutoSubscriptionCreation")," is disabled, the DLQ producer will fail to be created."),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},'Consumer<byte[]> consumer = pulsarClient.newConsumer(Schema.BYTES)\n                .topic("my-topic")\n                .subscriptionName("my-subscription")\n                .subscriptionType(SubscriptionType.Shared)\n                .deadLetterPolicy(DeadLetterPolicy.builder()\n                      .maxRedeliverCount(maxRedeliveryCount)\n                      .deadLetterTopic("my-dead-letter-topic-name")\n                      .initialSubscriptionName("init-sub")\n                      .build())\n                .subscribe();\n')),(0,s.yg)("p",null,"Dead letter topic serves message redelivery, which is triggered by ",(0,s.yg)("a",{parentName:"p",href:"#acknowledgment-timeout"},"acknowledgment timeout")," or ",(0,s.yg)("a",{parentName:"p",href:"#negative-acknowledgment"},"negative acknowledgment")," or ",(0,s.yg)("a",{parentName:"p",href:"#retry-letter-topic"},"retry letter topic"),"."),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("p",{parentName:"admonition"},"Currently, dead letter topic is enabled in Shared and Key_Shared subscription types.")),(0,s.yg)("h3",{id:"compression"},"Compression"),(0,s.yg)("p",null,"Message compression can reduce message size by paying some CPU overhead. The Pulsar client supports the following compression types:"),(0,s.yg)("ul",null,(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("a",{parentName:"li",href:"https://github.com/lz4/lz4"},"LZ4")),(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("a",{parentName:"li",href:"https://zlib.net/"},"ZLIB")),(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("a",{parentName:"li",href:"https://facebook.github.io/zstd/"},"ZSTD")),(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("a",{parentName:"li",href:"https://google.github.io/snappy/"},"SNAPPY"))),(0,s.yg)("p",null,"Compression types are stored in the message metadata, so consumers can adopt different compression types automatically, as needed."),(0,s.yg)("p",null,"The sample code below shows how to enable compression type for a producer:"),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},'client.newProducer()\n    .topic("topic-name")\n    .compressionType(CompressionType.LZ4)\n    .create();\n')),(0,s.yg)("h3",{id:"batching"},"Batching"),(0,s.yg)("p",null,"When batching is enabled, the producer accumulates and sends a batch of messages in a single request. The batch size is defined by the maximum number of messages and the maximum publish latency. Therefore, the backlog size represents the total number of batches instead of the total number of messages."),(0,s.yg)("p",null,(0,s.yg)("img",{alt:"Batching",src:a(37340).A,width:"1720",height:"520"})),(0,s.yg)("p",null,"In Pulsar, batches are tracked and stored as single units rather than as individual messages. Consumers unbundle a batch into individual messages. However, scheduled messages (configured through the ",(0,s.yg)("inlineCode",{parentName:"p"},"deliverAt")," or the ",(0,s.yg)("inlineCode",{parentName:"p"},"deliverAfter")," parameter) are always sent as individual messages even when batching is enabled."),(0,s.yg)("p",null,"In general, a batch is acknowledged when all of its messages are acknowledged by a consumer. It means that when ",(0,s.yg)("strong",{parentName:"p"},"not all")," batch messages are acknowledged, then unexpected failures, negative acknowledgments, or acknowledgment timeouts can result in a redelivery of all messages in this batch."),(0,s.yg)("p",null,"To avoid redelivering acknowledged messages in a batch to the consumer, Pulsar introduces batch index acknowledgment since Pulsar 2.6.0. When batch index acknowledgment is enabled, the consumer filters out the batch index that has been acknowledged and sends the batch index acknowledgment request to the broker. The broker maintains the batch index acknowledgment status and tracks the acknowledgment status of each batch index to avoid dispatching acknowledged messages to the consumer. The batch is deleted when all indices of the messages in it are acknowledged."),(0,s.yg)("p",null,"By default, batch index acknowledgment is disabled (",(0,s.yg)("inlineCode",{parentName:"p"},"acknowledgmentAtBatchIndexLevelEnabled=false"),"). You can enable batch index acknowledgment by setting the ",(0,s.yg)("inlineCode",{parentName:"p"},"acknowledgmentAtBatchIndexLevelEnabled")," parameter to ",(0,s.yg)("inlineCode",{parentName:"p"},"true")," at the broker side. Enabling batch index acknowledgment results in more memory overheads."),(0,s.yg)("p",null,"Batch index acknowledgment must also be enabled in the consumer by calling ",(0,s.yg)("inlineCode",{parentName:"p"},".enableBatchIndexAcknowledgment(true);")),(0,s.yg)("p",null,"For example:"),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},"Consumer<byte[]> consumer = pulsarClient.newConsumer()\n        .topic(topicName)\n        .subscriptionName(subscriptionName)\n        .subscriptionType(subType)\n        .enableBatchIndexAcknowledgment(true)\n        .subscribe();\n")),(0,s.yg)("h3",{id:"chunking"},"Chunking"),(0,s.yg)("p",null,"Message chunking enables Pulsar to process large payload messages by splitting the message into chunks at the producer side and aggregating chunked messages at the consumer side."),(0,s.yg)("p",null,"With message chunking enabled, when the size of a message exceeds the allowed maximum payload size (the ",(0,s.yg)("inlineCode",{parentName:"p"},"maxMessageSize")," parameter of broker), the workflow of messaging is as follows:"),(0,s.yg)("ol",null,(0,s.yg)("li",{parentName:"ol"},"The producer splits the original message into chunked messages and publishes them with chunked metadata to the broker separately and in order."),(0,s.yg)("li",{parentName:"ol"},"The broker stores the chunked messages in one managed ledger in the same way as that of ordinary messages, and it uses the ",(0,s.yg)("inlineCode",{parentName:"li"},"chunkedMessageRate")," parameter to record chunked message rate on the topic."),(0,s.yg)("li",{parentName:"ol"},"The consumer buffers the chunked messages and aggregates them into the receiver queue when it receives all the chunks of a message."),(0,s.yg)("li",{parentName:"ol"},"The client consumes the aggregated message from the receiver queue.")),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("ul",{parentName:"admonition"},(0,s.yg)("li",{parentName:"ul"},"Chunking is only available for persistent topics."),(0,s.yg)("li",{parentName:"ul"},"Chunking cannot be enabled simultaneously with batching. Before enabling chunking, you need to disable batching."))),(0,s.yg)("h4",{id:"handle-consecutive-chunked-messages-with-one-ordered-consumer"},"Handle consecutive chunked messages with one ordered consumer"),(0,s.yg)("p",null,"The following figure shows a topic with one producer that publishes a large message payload in chunked messages along with regular non-chunked messages. The producer publishes message M1 in three chunks labeled M1-C1, M1-C2 and M1-C3. The broker stores all the three chunked messages in the ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/concepts-architecture-overview#managed-ledgers"},"managed ledger")," and dispatches them to the ordered (exclusive/failover) consumer in the same order. The consumer buffers all the chunked messages in memory until it receives all the chunked messages, aggregates them into one message and then hands over the original message M1 to the client."),(0,s.yg)("p",null,(0,s.yg)("img",{src:a(50540).A,width:"701",height:"181"})),(0,s.yg)("h4",{id:"handle-interwoven-chunked-messages-with-one-ordered-consumer"},"Handle interwoven chunked messages with one ordered consumer"),(0,s.yg)("p",null,"When multiple producers publish chunked messages into a single topic, the broker stores all the chunked messages coming from different producers in the same ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/concepts-architecture-overview#managed-ledgers"},"managed ledger"),". The chunked messages in the managed ledger can be interwoven with each other. As shown below, Producer 1 publishes message M1 in three chunks M1-C1, M1-C2 and M1-C3. Producer 2 publishes message M2 in three chunks M2-C1, M2-C2 and M2-C3. All chunked messages of the specific message are still in order but might not be consecutive in the managed ledger."),(0,s.yg)("p",null,(0,s.yg)("img",{src:a(70599).A,width:"691",height:"301"})),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("p",{parentName:"admonition"},"In this case, interwoven chunked messages may bring some memory pressure to the consumer because the consumer keeps a separate buffer for each large message to aggregate all its chunks in one message. You can limit the maximum number of chunked messages a consumer maintains concurrently by configuring the ",(0,s.yg)("inlineCode",{parentName:"p"},"maxPendingChunkedMessage")," parameter. When the threshold is reached, the consumer drops pending messages by silently acknowledging them or asking the broker to redeliver them later, optimizing memory utilization.")),(0,s.yg)("h4",{id:"enable-message-chunking"},"Enable Message Chunking"),(0,s.yg)("p",null,(0,s.yg)("strong",{parentName:"p"},"Prerequisite:")," Disable batching by setting the ",(0,s.yg)("inlineCode",{parentName:"p"},"enableBatching")," parameter to ",(0,s.yg)("inlineCode",{parentName:"p"},"false"),"."),(0,s.yg)("p",null,"The message chunking feature is OFF by default.\nTo enable message chunking, set the ",(0,s.yg)("inlineCode",{parentName:"p"},"chunkingEnabled")," parameter to ",(0,s.yg)("inlineCode",{parentName:"p"},"true")," when creating a producer."),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("p",{parentName:"admonition"},"If the consumer fails to receive all chunks of a message within a specified period, it expires incomplete chunks. The default value is 1 minute. For more information about the ",(0,s.yg)("inlineCode",{parentName:"p"},"expireTimeOfIncompleteChunkedMessage")," parameter, refer to ",(0,s.yg)("a",{parentName:"p",href:"https://pulsar.apache.org/api/client/3.0.x/"},"org.apache.pulsar.client.api"),".")),(0,s.yg)("h2",{id:"topics"},"Topics"),(0,s.yg)("p",null,"As in other pub-sub systems, topics in Pulsar are named channels for transmitting messages from producers to consumers. Topic names are URLs that have a well-defined structure:"),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-http"},"{persistent|non-persistent}://tenant/namespace/topic\n")),(0,s.yg)("table",null,(0,s.yg)("thead",{parentName:"table"},(0,s.yg)("tr",{parentName:"thead"},(0,s.yg)("th",{parentName:"tr",align:"left"},"Topic name component"),(0,s.yg)("th",{parentName:"tr",align:"left"},"Description"))),(0,s.yg)("tbody",{parentName:"table"},(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},(0,s.yg)("inlineCode",{parentName:"td"},"persistent")," / ",(0,s.yg)("inlineCode",{parentName:"td"},"non-persistent")),(0,s.yg)("td",{parentName:"tr",align:"left"},"This identifies the type of topic. Pulsar supports two kind of topics: ",(0,s.yg)("a",{parentName:"td",href:"/docs/3.0.x/concepts-architecture-overview#persistent-storage"},"persistent")," and ",(0,s.yg)("a",{parentName:"td",href:"#non-persistent-topics"},"non-persistent"),". The default is persistent, so if you do not specify a type, the topic is persistent. With persistent topics, all messages are durably persisted on disks (if the broker is not standalone, messages are durably persisted on multiple disks), whereas data for non-persistent topics is not persisted to storage disks.")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},(0,s.yg)("inlineCode",{parentName:"td"},"tenant")),(0,s.yg)("td",{parentName:"tr",align:"left"},"The topic tenant within the instance. Tenants are essential to multi-tenancy in Pulsar, and spread across clusters.")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},(0,s.yg)("inlineCode",{parentName:"td"},"namespace")),(0,s.yg)("td",{parentName:"tr",align:"left"},"The administrative unit of the topic, which acts as a grouping mechanism for related topics. Most topic configuration is performed at the ",(0,s.yg)("a",{parentName:"td",href:"#namespaces"},"namespace")," level. Each tenant has one or more namespaces.")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},(0,s.yg)("inlineCode",{parentName:"td"},"topic")),(0,s.yg)("td",{parentName:"tr",align:"left"},"The final part of the name. Topic names have no special meaning in a Pulsar instance.")))),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("p",{parentName:"admonition"},"You do not need to explicitly create topics in Pulsar. If a client attempts to write or receive messages to/from a topic that does not yet exist, Pulsar creates that topic under the namespace provided in the ",(0,s.yg)("a",{parentName:"p",href:"#topics"},"topic name")," automatically.\nIf no tenant or namespace is specified when a client creates a topic, the topic is created in the default tenant and namespace. You can also create a topic in a specified tenant and namespace, such as ",(0,s.yg)("inlineCode",{parentName:"p"},"persistent://my-tenant/my-namespace/my-topic"),". ",(0,s.yg)("inlineCode",{parentName:"p"},"persistent://my-tenant/my-namespace/my-topic")," means the ",(0,s.yg)("inlineCode",{parentName:"p"},"my-topic")," topic is created in the ",(0,s.yg)("inlineCode",{parentName:"p"},"my-namespace")," namespace of the ",(0,s.yg)("inlineCode",{parentName:"p"},"my-tenant")," tenant.")),(0,s.yg)("h2",{id:"namespaces"},"Namespaces"),(0,s.yg)("p",null,"A namespace is a logical nomenclature within a tenant. A tenant creates namespaces via the ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/admin-api-namespaces#create-namespaces"},"admin API"),". For instance, a tenant with different applications can create a separate namespace for each application. A namespace allows the application to create and manage a hierarchy of topics. The topic ",(0,s.yg)("inlineCode",{parentName:"p"},"my-tenant/app1")," is a namespace for the application ",(0,s.yg)("inlineCode",{parentName:"p"},"app1")," for ",(0,s.yg)("inlineCode",{parentName:"p"},"my-tenant"),". You can create any number of ",(0,s.yg)("a",{parentName:"p",href:"#topics"},"topics")," under the namespace."),(0,s.yg)("h2",{id:"subscriptions"},"Subscriptions"),(0,s.yg)("p",null,"A subscription is a named configuration rule that determines how messages are delivered to consumers. Four subscription types are available in Pulsar: ",(0,s.yg)("a",{parentName:"p",href:"#exclusive"},"exclusive"),", ",(0,s.yg)("a",{parentName:"p",href:"#shared"},"shared"),", ",(0,s.yg)("a",{parentName:"p",href:"#failover"},"failover"),", and ",(0,s.yg)("a",{parentName:"p",href:"#key_shared"},"key_shared"),". These types are illustrated in the figure below."),(0,s.yg)("p",null,(0,s.yg)("img",{alt:"Subscription types",src:a(69036).A,width:"1652",height:"1212"})),(0,s.yg)("admonition",{type:"tip"},(0,s.yg)("p",{parentName:"admonition"},(0,s.yg)("strong",{parentName:"p"},"Pub-Sub or Queuing"),"\nIn Pulsar, you can use different subscriptions flexibly."),(0,s.yg)("ul",{parentName:"admonition"},(0,s.yg)("li",{parentName:"ul"},'If you want to achieve traditional "fan-out pub-sub messaging" among consumers, specify a unique subscription name for each consumer. It is an exclusive subscription type.'),(0,s.yg)("li",{parentName:"ul"},'If you want to achieve "message queuing" among consumers, share the same subscription name among multiple consumers (shared, failover, key_shared).'),(0,s.yg)("li",{parentName:"ul"},"If you want to achieve both effects simultaneously, combine exclusive subscription types with other subscription types for consumers."))),(0,s.yg)("h3",{id:"subscription-types"},"Subscription types"),(0,s.yg)("p",null,"When a subscription has no consumers, its subscription type is undefined. The type of a subscription is defined when a consumer connects to it, and the type can be changed by restarting all consumers with a different configuration."),(0,s.yg)("h4",{id:"exclusive"},"Exclusive"),(0,s.yg)("p",null,"In the ",(0,s.yg)("em",{parentName:"p"},"Exclusive")," type, only a single consumer is allowed to attach to the subscription. If multiple consumers subscribe to a topic using the same subscription, an error occurs. Note that if the topic is partitioned, all partitions will be consumed by the single consumer allowed to be connected to the subscription."),(0,s.yg)("p",null,"In the diagram below, only ",(0,s.yg)("strong",{parentName:"p"},"Consumer A")," is allowed to consume messages."),(0,s.yg)("admonition",{type:"tip"},(0,s.yg)("p",{parentName:"admonition"},"Exclusive is the default subscription type.")),(0,s.yg)("p",null,(0,s.yg)("img",{alt:"Exclusive subscriptions",src:a(35405).A,width:"1760",height:"720"})),(0,s.yg)("h4",{id:"failover"},"Failover"),(0,s.yg)("p",null,"In the ",(0,s.yg)("em",{parentName:"p"},"Failover")," type, multiple consumers can attach to the same subscription. "),(0,s.yg)("p",null,"A master consumer is picked for a non-partitioned topic or each partition of a partitioned topic and receives messages. "),(0,s.yg)("p",null,"When the master consumer disconnects, all (non-acknowledged and subsequent) messages are delivered to the next consumer in line."),(0,s.yg)("h5",{id:"failover--partitioned-topics"},"Failover | Partitioned topics"),(0,s.yg)("p",null,"For partitioned topics, the broker sorts consumers by priority and lexicographical order of consumer name. "),(0,s.yg)("p",null,"The broker tries to evenly assign partitions to consumers with the highest priority. "),(0,s.yg)("p",null,"A consumer is selected by running a module operation ",(0,s.yg)("inlineCode",{parentName:"p"},"mod (partition index, consumer index)"),"."),(0,s.yg)("ul",null,(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("p",{parentName:"li"},"If the number of partitions in a partitioned topic is ",(0,s.yg)("strong",{parentName:"p"},"less")," than the number of consumers:"),(0,s.yg)("p",{parentName:"li"},"For example, in the diagram below, this partitioned topic has 2 partitions and there are 4 consumers. "),(0,s.yg)("p",{parentName:"li"},"Each partition has 1 active consumer and 1 stand-by consumer. "),(0,s.yg)("ul",{parentName:"li"},(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("p",{parentName:"li"},"For p0, consumer A is the master consumer, while consumer B would be the next consumer in line to receive messages if consumer A is disconnected.")),(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("p",{parentName:"li"},"For p1, consumer C is the master consumer, while consumer D would be the next consumer in line to receive messages if consumer C is disconnected."))),(0,s.yg)("p",{parentName:"li"},(0,s.yg)("img",{alt:"Failover subscriptions",src:a(22892).A,width:"1020",height:"934"}))),(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("p",{parentName:"li"},"If the number of partitions in a partitioned topic is ",(0,s.yg)("strong",{parentName:"p"},"greater")," than the number of consumers:"),(0,s.yg)("p",{parentName:"li"},"For example, in the diagram below, this partitioned topic has 9 partitions and 3 consumers. "),(0,s.yg)("ul",{parentName:"li"},(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("p",{parentName:"li"},"p0, p3, and p6 are assigned to consumer A.")),(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("p",{parentName:"li"},"p1, p4, and p7 are assigned to consumer B.")),(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("p",{parentName:"li"},"p2, p5, and p8 are assigned to consumer C."))),(0,s.yg)("p",{parentName:"li"},(0,s.yg)("img",{alt:"Failover subscriptions",src:a(98833).A,width:"1020",height:"934"})))),(0,s.yg)("h5",{id:"failover--non-partitioned-topics"},"Failover | Non-partitioned topics"),(0,s.yg)("ul",null,(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("p",{parentName:"li"},"If there is one non-partitioned topic. The broker picks consumers in the order they subscribe to non-partitioned topics. "),(0,s.yg)("p",{parentName:"li"},"For example, in the diagram below, this non-partitioned topic has 1 topic and there are 2 consumers. "),(0,s.yg)("p",{parentName:"li"},"The topic has 1 active consumer and 1 stand-by consumer. "),(0,s.yg)("p",{parentName:"li"},"Consumer A is the master consumer, while consumer B would be the next consumer in line to receive messages if consumer A is disconnected."),(0,s.yg)("p",{parentName:"li"},(0,s.yg)("img",{alt:"Failover subscriptions",src:a(58082).A,width:"938",height:"440"}))),(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("p",{parentName:"li"},"If there are multiple non-partitioned topics, a consumer is selected based on ",(0,s.yg)("strong",{parentName:"p"},"consumer name hash")," and ",(0,s.yg)("strong",{parentName:"p"},"topic name hash"),". The client uses the same consumer name to subscribe to all the topics."),(0,s.yg)("p",{parentName:"li"},"For example, in the diagram below, there are 4 non-partitioned topics and 2 consumers. "),(0,s.yg)("ul",{parentName:"li"},(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("p",{parentName:"li"},"The non-partitioned topic 1 and non-partitioned topic 4 are assigned to consumer A. ")),(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("p",{parentName:"li"},"The non-partitioned topic 2 and non-partitioned topic 3 are assigned to consumer B."))),(0,s.yg)("p",{parentName:"li"},(0,s.yg)("img",{alt:"Failover subscriptions",src:a(45459).A,width:"940",height:"700"})))),(0,s.yg)("h4",{id:"shared"},"Shared"),(0,s.yg)("p",null,"In ",(0,s.yg)("em",{parentName:"p"},"shared")," or ",(0,s.yg)("em",{parentName:"p"},"round robin")," type, multiple consumers can attach to the same subscription. Messages are delivered in a round-robin distribution across consumers, and any given message is delivered to only one consumer. When a consumer disconnects, all the messages that were sent to it and not acknowledged will be rescheduled for sending to the remaining consumers."),(0,s.yg)("p",null,"In the diagram below, ",(0,s.yg)("strong",{parentName:"p"},"Consumer A"),", ",(0,s.yg)("strong",{parentName:"p"},"Consumer B")," and ",(0,s.yg)("strong",{parentName:"p"},"Consumer C")," are all able to subscribe to the topic."),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("p",{parentName:"admonition"},"Shared subscriptions do not guarantee message ordering or support cumulative acknowledgment.")),(0,s.yg)("p",null,(0,s.yg)("img",{alt:"Shared subscriptions",src:a(91542).A,width:"1760",height:"720"})),(0,s.yg)("h4",{id:"key_shared"},"Key_Shared"),(0,s.yg)("p",null,"In the ",(0,s.yg)("em",{parentName:"p"},"Key_Shared")," type, multiple consumers can attach to the same subscription. Messages are delivered in distribution across consumers and messages with the same key or same ordering key are delivered to only one consumer. No matter how many times the message is re-delivered, it is delivered to the same consumer."),(0,s.yg)("p",null,(0,s.yg)("img",{alt:"Key_Shared subscriptions",src:a(29128).A,width:"1760",height:"720"})),(0,s.yg)("p",null,"There are three types of mapping algorithms dictating how to select a consumer for a given message key (or ordering key): Sticky, Auto-split Hash Range, and Auto-split Consistent Hashing. The steps for all algorithms are:"),(0,s.yg)("ol",null,(0,s.yg)("li",{parentName:"ol"},"The message key (or ordering key) is passed to a hash function (e.g., Murmur3 32-bit), yielding a 32-bit integer hash."),(0,s.yg)("li",{parentName:"ol"},"That hash number is fed to the algorithm to select a consumer from the existing connected consumers.")),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre"},"                      +--------------+                              +-----------+\nMessage Key -----\x3e  / Hash Function / ----- hash (32-bit) -------\x3e / Algorithm / ----\x3e Consumer\n                   +---------------+                               +----------+\n")),(0,s.yg)("p",null,"When a new consumer is connected and thus added to the list of connected consumers, the algorithm re-adjusts the mapping such that some keys currently mapped to existing consumers will be mapped to the newly added consumer. When a consumer is disconnected, thus removed from the list of connected consumers, keys mapped to it will be mapped to other consumers. The sections below will explain how a consumer is selected given the message hash and how the mapping is adjusted given a new consumer is connected or an existing consumer disconnects for each algorithm."),(0,s.yg)("h5",{id:"auto-split-hash-range"},"Auto-split Hash Range"),(0,s.yg)("p",null,"The algorithm assumes there is a range of numbers between 0 to 2^16 (65,536). Each consumer is mapped into a single region in this range, so all mapped regions cover the entire range, and no regions overlap. A consumer is selected for a given key by running a modulo operation on the message hash by the range size (65,536). The number received ( 0 <= i < 65,536) is contained within a single region. The consumer mapped to that region is the one selected."),(0,s.yg)("p",null,"Example:"),(0,s.yg)("p",null,"Suppose we have 4 consumers (C1, C2, C3 and C4), then:"),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre"}," 0               16,384            32,768           49,152             65,536\n |------- C3 ------|------- C2 ------|------- C1 ------|------- C4 ------|\n")),(0,s.yg)("p",null,"Given a message key ",(0,s.yg)("inlineCode",{parentName:"p"},"Order-3459134"),", its hash would be ",(0,s.yg)("inlineCode",{parentName:"p"},'murmur32("Order-3459134") = 3112179635'),", and its index in the range would be ",(0,s.yg)("inlineCode",{parentName:"p"},"3112179635 mod 65536 = 6067"),". That index is contained within region ",(0,s.yg)("inlineCode",{parentName:"p"},"[0, 16384)")," thus consumer C3 will be mapped to this message key."),(0,s.yg)("p",null,"When a new consumer is connected, the largest region is chosen and is then split in half - the lower half will be mapped to the newly added consumer and upper half will be mapped to the consumer owning that region. Here is how it looks like from 1 to 4 consumers:"),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre"},"C1 connected:\n|---------------------------------- C1 ---------------------------------|\n\nC2 connected:\n|--------------- C2 ----------------|---------------- C1 ---------------|\n\nC3 connected:\n|------- C3 ------|------- C2 ------|---------------- C1 ---------------|\n\nC4 connected:\n|------- C3 ------|------- C2 ------|------- C4 ------|------- C1 ------|\n")),(0,s.yg)("p",null,"When a consumer is disconnected its region will be merged into the region on its right. Examples:"),(0,s.yg)("p",null,"C4 is disconnected:"),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre"},"|------- C3 ------|------- C2 ------|---------------- C1 ---------------|\n")),(0,s.yg)("p",null,"C1 is disconnected:"),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre"},"|------- C3 ------|-------------------------- C2 -----------------------|\n")),(0,s.yg)("p",null,"The advantages of this algorithm is that it affects only a single existing consumer upon add/delete consumer, at the expense of regions not evenly sized. Thi means some consumers gets more keys that others. The next algorithm does the other way around."),(0,s.yg)("h5",{id:"auto-split-consistent-hashing"},"Auto-split Consistent Hashing"),(0,s.yg)("p",null,"This algorithm uses a Hash Ring. It's a range of number from 0 to MAX_INT (32-bit) in which if you traverse the range, when reaching MAX_INT, the next number would be zero. It is as if you took a line starting from 0 ending at MAX_INT and bent into a circle such that the end glues to the start:"),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre"}," MAX_INT -----++--------- 0\n              ||\n         , - ~ ~ ~ - ,\n     , '               ' ,\n   ,                       ,\n  ,                         ,\n ,                           ,\n ,                           ,\n ,                           ,\n  ,                         ,\n   ,                       ,\n     ,                  , '\n       ' - , _ _ _ ,  '\n")),(0,s.yg)("p",null,'When adding a consumer, we mark 100 points on that circle and associate them to the newly added consumer. For each number between 1 and 100, we concatenate the consumer name to that number and run the hash function on it to get the location of the point on the circle that will be marked. For Example, if the consumer name is "orders-aggregator-pod-2345-consumer" then we would mark 100 points on that circle:'),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre"},'    murmur32("orders-aggregator-pod-2345-consumer1") = 1003084738\n    murmur32("orders-aggregator-pod-2345-consumer2") = 373317202\n    ...\n    murmur32("orders-aggregator-pod-2345-consumer100") = 320276078\n')),(0,s.yg)("p",null,"Since the hash function has the uniform distribution attribute, those points would be uniformly distributed across the circle."),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre"},"    C1-100\n         , - ~ ~ ~ - ,   C1-1\n     , '               ' ,\n   ,                       ,\n  ,                         , C1-2\n ,                           ,\n ,                           ,\n ,                           ,\n  ,                         ,  C1-3\n   ,                       ,\n     ,                  , '\n       ' - , _ _ _ ,  '      ...\n\n")),(0,s.yg)("p",null,"A consumer is selected for a given message key by putting its hash on the circle then continue clock-wise on the circle until you reach a marking point. The point might have more than one consumer on it (hash function might have collisions) there for, we run the following operation to get a position within the list of consumers for that point, then we take the consumer in that position: ",(0,s.yg)("inlineCode",{parentName:"p"},"hash % consumer_list_size = index"),"."),(0,s.yg)("p",null,"When a consumer is added, we add 100 marking points to the circle as explained before. Due to the uniform distribution of the hash function, those 100 points act as if the new consumer takes a small slice of keys out of each existing consumer. It maintains the even distribution, on the trade-off that it impacts all existing consumers. ",(0,s.yg)("a",{parentName:"p",href:"https://www.youtube.com/watch?v=zaRkONvyGr8"},"This video")," explains the concept of Consistent Hashing quite well (the only difference is that in Pulsar's case we used K points instead of K hash functions as noted in the comments)"),(0,s.yg)("h5",{id:"sticky"},"Sticky"),(0,s.yg)("p",null,"The algorithm assumes there is a range of numbers between 0 to 2^16 (65,536). Each consumer is mapped to a multiple regions in this range and there is no overlap between regions. The consumer is selected by running a modulo operation on the message hash by the range size (65,536), the number received (0 <= i < 65,536), is contained within a single region. The consumer mapped to the region is the one selected.\nIn this algorithm you have full control. Every newly added consumer specifies the ranges it wishes to be mapped to by using Consumer API. When the consumer object is constructed, you can specify the list of ranges. It's your responsibility to make sure there are no overlaps and all the range is covered by regions."),(0,s.yg)("p",null,"Example:"),(0,s.yg)("p",null,"Suppose we have 2 consumers (C1 and C2) each specified their ranges, then:"),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre"},"C1 = [0, 16384), [32768, 49152)\nC2 = [16384, 32768), [49152, 65536)\n\n 0               16,384            32,768           49,152             65,536\n |------- C1 ------|------- C2 ------|------- C1 ------|------- C2 ------|\n")),(0,s.yg)("p",null,"Given a message key ",(0,s.yg)("inlineCode",{parentName:"p"},"Order-3459134"),", it's hash would be ",(0,s.yg)("inlineCode",{parentName:"p"},'murmur32("Order-3459134") = 3112179635'),", and it's index in the range would be ",(0,s.yg)("inlineCode",{parentName:"p"},"3112179635 mod 65536 = 6067"),". That index is contained within ",(0,s.yg)("inlineCode",{parentName:"p"},"[0, 16384)")," thus consumer C1 will map to this message key."),(0,s.yg)("p",null,"If the newly connected consumer didn't supply their ranges, or they overlap with existing consumer ranges, it's disconnected, removed from the consumers list and reverted as if it never tried to connect."),(0,s.yg)("h5",{id:"how-to-use-them"},"How to use them?"),(0,s.yg)("p",null,"When building the consumer, you can specify the Key Shared Mode:"),(0,s.yg)("ul",null,(0,s.yg)("li",{parentName:"ul"},"AUTO_SPLIT - Auto-split Hash Range"),(0,s.yg)("li",{parentName:"ul"},"STICKY - Sticky")),(0,s.yg)("p",null,"Consistent Hashing will be used instead of Hash Range for Auto-split if the broker configuration ",(0,s.yg)("inlineCode",{parentName:"p"},"subscriptionKeySharedUseConsistentHashing")," is enabled."),(0,s.yg)("h5",{id:"preserving-order-of-processing"},"Preserving order of processing"),(0,s.yg)("p",null,"Key Shared Subscription type guarantees a key will be processed by a ",(0,s.yg)("em",{parentName:"p"},"single")," consumer at any given time. When a new consumer is connected, some keys will change their mapping from existing consumers to the new consumer. Once the connection has been established, the broker will record the current read position and associate it with the new consumer. The read position is a marker indicating that messages have been dispatched to the consumers up to this point, and after it, no messages have been dispatched yet. The broker will start delivering messages to the new consumer ",(0,s.yg)("em",{parentName:"p"},"only")," when all messages up to the read position have been acknowledged. This will guarantee that a certain key is processed by a single consumer at any given time. The trade-off is that if one of the existing consumers is stuck and no time-out was defined (acknowledging for you), the new consumer won't receive any messages until the stuck consumer resumes or gets disconnected."),(0,s.yg)("p",null,"That requirement can be relaxed by enabling ",(0,s.yg)("inlineCode",{parentName:"p"},"allowOutOfOrderDelivery")," via the Consumer API. If set on the new consumer, then when it is connected, the broker will allow it to receive messages knowing some messages of that key may be still be processing in other consumers at the time, thus order may be affected for that short period of adding a new consumer."),(0,s.yg)("h5",{id:"batching-for-key-shared-subscriptions"},"Batching for Key Shared Subscriptions"),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("p",{parentName:"admonition"},"When the consumers are using the Key_Shared subscription type, you need to ",(0,s.yg)("strong",{parentName:"p"},"disable batching")," or ",(0,s.yg)("strong",{parentName:"p"},"use key-based batching")," for the producers.")),(0,s.yg)("p",null,"There are two reasons why the key-based batching is necessary for the Key_Shared subscription type:"),(0,s.yg)("ol",null,(0,s.yg)("li",{parentName:"ol"},"The broker dispatches messages according to the keys of the messages, but the default batching approach might fail to pack the messages with the same key to the same batch."),(0,s.yg)("li",{parentName:"ol"},"Since it is the consumers instead of the broker who dispatch the messages from the batches, the key of the first message in one batch is considered as the key to all messages in this batch, thereby leading to context errors.")),(0,s.yg)("p",null,"The key-based batching aims at resolving the above-mentioned issues. This batching method ensures that the producers pack the messages with the same key to the same batch. The messages without a key are packed into one batch and this batch has no key. When the broker dispatches messages from this batch, it uses ",(0,s.yg)("inlineCode",{parentName:"p"},"NON_KEY")," as the key. In addition, each consumer is associated with ",(0,s.yg)("strong",{parentName:"p"},"only one")," key and should receive ",(0,s.yg)("strong",{parentName:"p"},"only one message batch")," for the connected key. By default, you can limit batching by configuring the number of messages that producers are allowed to send."),(0,s.yg)("p",null,"Below are examples of enabling the key-based batching under the Key_Shared subscription type, with ",(0,s.yg)("inlineCode",{parentName:"p"},"client")," being the Pulsar client that you created."),(0,s.yg)(i.A,{groupId:"lang-choice",defaultValue:"Java",values:[{label:"Java",value:"Java"},{label:"C++",value:"C++"},{label:"Python",value:"Python"}],mdxType:"Tabs"},(0,s.yg)(r.A,{value:"Java",mdxType:"TabItem"},(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},'Producer<byte[]> producer = client.newProducer()\n        .topic("my-topic")\n        .batcherBuilder(BatcherBuilder.KEY_BASED)\n        .create();\n'))),(0,s.yg)(r.A,{value:"C++",mdxType:"TabItem"},(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-cpp"},'ProducerConfiguration producerConfig;\nproducerConfig.setBatchingType(ProducerConfiguration::BatchingType::KeyBasedBatching);\nProducer producer;\nclient.createProducer("my-topic", producerConfig, producer);\n'))),(0,s.yg)(r.A,{value:"Python",mdxType:"TabItem"},(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-python"},"producer = client.create_producer(topic='my-topic', batching_type=pulsar.BatchingType.KeyBased)\n")))),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("p",{parentName:"admonition"},"When you use Key_Shared subscriptions, be aware that:"),(0,s.yg)("ul",{parentName:"admonition"},(0,s.yg)("li",{parentName:"ul"},"You need to specify a key or ordering key for messages."),(0,s.yg)("li",{parentName:"ul"},"You cannot use cumulative acknowledgment."),(0,s.yg)("li",{parentName:"ul"},"When the position of the newest message in a topic is ",(0,s.yg)("inlineCode",{parentName:"li"},"X"),", a key_shared consumer that is newly attached to the same subscription and connected to the topic will ",(0,s.yg)("strong",{parentName:"li"},"not")," receive any messages until all the messages before ",(0,s.yg)("inlineCode",{parentName:"li"},"X")," have been acknowledged."))),(0,s.yg)("h3",{id:"subscription-modes"},"Subscription modes"),(0,s.yg)("h4",{id:"what-is-a-subscription-mode"},"What is a subscription mode"),(0,s.yg)("p",null,"The subscription mode indicates the cursor type."),(0,s.yg)("ul",null,(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("p",{parentName:"li"},"When a subscription is created, an associated cursor is created to record the last consumed position.")),(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("p",{parentName:"li"},"When a consumer of the subscription restarts, it can continue consuming from the last message it consumes."))),(0,s.yg)("table",null,(0,s.yg)("thead",{parentName:"table"},(0,s.yg)("tr",{parentName:"thead"},(0,s.yg)("th",{parentName:"tr",align:"left"},"Subscription mode"),(0,s.yg)("th",{parentName:"tr",align:"left"},"Description"),(0,s.yg)("th",{parentName:"tr",align:"left"},"Note"))),(0,s.yg)("tbody",{parentName:"table"},(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},(0,s.yg)("inlineCode",{parentName:"td"},"Durable")),(0,s.yg)("td",{parentName:"tr",align:"left"},"The cursor is durable, which retains messages and persists the current position. ",(0,s.yg)("br",null),"If a broker restarts from a failure, it can recover the cursor from the persistent storage (BookKeeper), so that messages can continue to be consumed from the last consumed position."),(0,s.yg)("td",{parentName:"tr",align:"left"},(0,s.yg)("inlineCode",{parentName:"td"},"Durable")," is the ",(0,s.yg)("strong",{parentName:"td"},"default")," subscription mode.")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},(0,s.yg)("inlineCode",{parentName:"td"},"NonDurable")),(0,s.yg)("td",{parentName:"tr",align:"left"},"The cursor is non-durable. ",(0,s.yg)("br",null),"Once a broker stops, the cursor is lost and can never be recovered, so that messages ",(0,s.yg)("strong",{parentName:"td"},"can not")," continue to be consumed from the last consumed position."),(0,s.yg)("td",{parentName:"tr",align:"left"},"Reader's subscription mode is ",(0,s.yg)("inlineCode",{parentName:"td"},"NonDurable")," in nature and it does not prevent data in a topic from being deleted. Reader's subscription mode ",(0,s.yg)("strong",{parentName:"td"},"can not")," be changed.")))),(0,s.yg)("p",null,"A ",(0,s.yg)("a",{parentName:"p",href:"#subscriptions"},"subscription")," can have one or more consumers. When a consumer subscribes to a topic, it must specify the subscription name. A durable subscription and a non-durable subscription can have the same name, they are independent of each other. If a consumer specifies a subscription that does not exist before, the subscription is automatically created."),(0,s.yg)("h4",{id:"when-to-use"},"When to use"),(0,s.yg)("p",null,"By default, messages of a topic without any durable subscriptions are marked as deleted. If you want to prevent the messages from being marked as deleted, you can create a durable subscription for this topic. In this case, only acknowledged messages are marked as deleted. For more information, see ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/cookbooks-retention-expiry"},"message retention and expiry"),"."),(0,s.yg)("h4",{id:"how-to-use"},"How to use"),(0,s.yg)("p",null,"After a consumer is created, the default subscription mode of the consumer is ",(0,s.yg)("inlineCode",{parentName:"p"},"Durable"),". You can change the subscription mode to ",(0,s.yg)("inlineCode",{parentName:"p"},"NonDurable")," by making changes to the consumer's configuration."),(0,s.yg)(i.A,{defaultValue:"Durable",values:[{label:"Durable",value:"Durable"},{label:"Non-durable",value:"Non-durable"}],mdxType:"Tabs"},(0,s.yg)(r.A,{value:"Durable",mdxType:"TabItem"},(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},'        Consumer<byte[]> consumer = pulsarClient.newConsumer()\n                .topic("my-topic")\n                .subscriptionName("my-sub")\n                .subscriptionMode(SubscriptionMode.Durable)\n                .subscribe();\n'))),(0,s.yg)(r.A,{value:"Non-durable",mdxType:"TabItem"},(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},'        Consumer<byte[]> consumer = pulsarClient.newConsumer()\n                .topic("my-topic")\n                .subscriptionName("my-sub")\n                .subscriptionMode(SubscriptionMode.NonDurable)\n                .subscribe();\n')))),(0,s.yg)("p",null,"For how to create, check, or delete a durable subscription, see ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/admin-api-topics#manage-subscriptions"},"manage subscriptions"),"."),(0,s.yg)("h2",{id:"multi-topic-subscriptions"},"Multi-topic subscriptions"),(0,s.yg)("p",null,"When a consumer subscribes to a Pulsar topic, by default it subscribes to one specific topic, such as ",(0,s.yg)("inlineCode",{parentName:"p"},"persistent://public/default/my-topic"),". As of Pulsar version 1.23.0-incubating, however, Pulsar consumers can simultaneously subscribe to multiple topics. You can define a list of topics in two ways:"),(0,s.yg)("ul",null,(0,s.yg)("li",{parentName:"ul"},"On the basis of a ",(0,s.yg)("a",{parentName:"li",href:"https://en.wikipedia.org/wiki/Regular_expression"},(0,s.yg)("strong",{parentName:"a"},"reg"),"ular ",(0,s.yg)("strong",{parentName:"a"},"ex"),"pression")," (regex), for example, ",(0,s.yg)("inlineCode",{parentName:"li"},"persistent://public/default/finance-.*")),(0,s.yg)("li",{parentName:"ul"},"By explicitly defining a list of topics")),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("p",{parentName:"admonition"},"When subscribing to multiple topics by regex, all topics must be in the same ",(0,s.yg)("a",{parentName:"p",href:"#namespaces"},"namespace"),".")),(0,s.yg)("p",null,"When subscribing to multiple topics, the Pulsar client automatically makes a call to the Pulsar API to discover the topics that match the regex pattern/list, and then subscribe to all of them. If any of the topics do not exist, the consumer auto-subscribes to them once the topics are created."),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("p",{parentName:"admonition"}," ",(0,s.yg)("strong",{parentName:"p"},"No ordering guarantees across multiple topics"),"\nWhen a producer sends messages to a single topic, all messages are guaranteed to be read from that topic in the same order. However, these guarantees do not hold across multiple topics. So when a producer sends messages to multiple topics, the order in which messages are read from those topics is not guaranteed to be the same.")),(0,s.yg)("p",null,"The following are multi-topic subscription examples for Java."),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},'import java.util.regex.Pattern;\n\nimport org.apache.pulsar.client.api.Consumer;\nimport org.apache.pulsar.client.api.PulsarClient;\n\nPulsarClient pulsarClient = // Instantiate Pulsar client object\n\n// Subscribe to all topics in a namespace\nPattern allTopicsInNamespace = Pattern.compile("persistent://public/default/.*");\nConsumer<byte[]> allTopicsConsumer = pulsarClient.newConsumer()\n                .topicsPattern(allTopicsInNamespace)\n                .subscriptionName("subscription-1")\n                .subscribe();\n\n// Subscribe to a subsets of topics in a namespace, based on regex\nPattern someTopicsInNamespace = Pattern.compile("persistent://public/default/foo.*");\nConsumer<byte[]> someTopicsConsumer = pulsarClient.newConsumer()\n                .topicsPattern(someTopicsInNamespace)\n                .subscriptionName("subscription-1")\n                .subscribe();\n')),(0,s.yg)("p",null,"For code examples, see ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/client-libraries-java#multi-topic-subscriptions"},"Java"),"."),(0,s.yg)("h2",{id:"partitioned-topics"},"Partitioned topics"),(0,s.yg)("p",null,"Normal topics are served only by a single broker, which limits the maximum throughput of the topic. ",(0,s.yg)("em",{parentName:"p"},"Partitioned topics")," are a special type of topic handled by multiple brokers, thus allowing for higher throughput."),(0,s.yg)("p",null,"A partitioned topic is implemented as N internal topics, where N is the number of partitions. When publishing messages to a partitioned topic, each message is routed to one of several brokers. The distribution of partitions across brokers is handled automatically by Pulsar."),(0,s.yg)("p",null,"The diagram below illustrates this:"),(0,s.yg)("p",null,(0,s.yg)("img",{src:a(83269).A,width:"1007",height:"1407"})),(0,s.yg)("p",null,"The ",(0,s.yg)("strong",{parentName:"p"},"Topic1")," topic has five partitions (",(0,s.yg)("strong",{parentName:"p"},"P0")," through ",(0,s.yg)("strong",{parentName:"p"},"P4"),") split across three brokers. Because there are more partitions than brokers, two brokers handle two partitions a piece, while the third handles only one (again, Pulsar handles this distribution of partitions automatically)."),(0,s.yg)("p",null,"Messages for this topic are broadcast to two consumers. The ",(0,s.yg)("a",{parentName:"p",href:"#routing-modes"},"routing mode")," determines each message should be published to which partition, while the ",(0,s.yg)("a",{parentName:"p",href:"#subscription-types"},"subscription type")," determines which messages go to which consumers."),(0,s.yg)("p",null,"Decisions about routing and subscription modes can be made separately in most cases. In general, throughput concerns should guide partitioning/routing decisions while subscription decisions should be guided by application semantics."),(0,s.yg)("p",null,"There is no difference between partitioned topics and normal topics in terms of how subscription types work, as partitioning only determines what happens between when a message is published by a producer and processed and acknowledged by a consumer."),(0,s.yg)("p",null,"Partitioned topics need to be explicitly created via the ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/admin-api-overview"},"admin API"),". The number of partitions can be specified when creating the topic."),(0,s.yg)("h3",{id:"routing-modes"},"Routing modes"),(0,s.yg)("p",null,"When publishing to partitioned topics, you must specify a ",(0,s.yg)("em",{parentName:"p"},"routing mode"),". The routing mode determines which partition---that is, which internal topic---each message should be published to."),(0,s.yg)("p",null,"There are three ",(0,s.yg)("a",{parentName:"p",href:"https://pulsar.apache.org/api/client/3.0.x/org/apache/pulsar/client/api/MessageRoutingMode"},"MessageRoutingMode")," available:"),(0,s.yg)("table",null,(0,s.yg)("thead",{parentName:"table"},(0,s.yg)("tr",{parentName:"thead"},(0,s.yg)("th",{parentName:"tr",align:"left"},"Mode"),(0,s.yg)("th",{parentName:"tr",align:"left"},"Description"))),(0,s.yg)("tbody",{parentName:"table"},(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},(0,s.yg)("inlineCode",{parentName:"td"},"RoundRobinPartition")),(0,s.yg)("td",{parentName:"tr",align:"left"},"If no key is provided, the producer will publish messages across all partitions in round-robin fashion to achieve maximum throughput. Please note that round-robin is not done per individual message but rather it's set to the same boundary of batching delay, to ensure batching is effective. While if a key is specified on the message, the partitioned producer will hash the key and assign message to a particular partition. This is the default mode.")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},(0,s.yg)("inlineCode",{parentName:"td"},"SinglePartition")),(0,s.yg)("td",{parentName:"tr",align:"left"},"If no key is provided, the producer will randomly pick one single partition and publish all the messages into that partition. While if a key is specified on the message, the partitioned producer will hash the key and assign message to a particular partition.")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},(0,s.yg)("inlineCode",{parentName:"td"},"CustomPartition")),(0,s.yg)("td",{parentName:"tr",align:"left"},"Use custom message router implementation that will be called to determine the partition for a particular message. User can create a custom routing mode by using the ",(0,s.yg)("a",{parentName:"td",href:"/docs/3.0.x/client-libraries-java"},"Java client")," and implementing the ",(0,s.yg)("a",{parentName:"td",href:"https://pulsar.apache.org/api/client/3.0.x/org/apache/pulsar/client/api/MessageRouter"},"MessageRouter")," interface.")))),(0,s.yg)("h3",{id:"ordering-guarantee"},"Ordering guarantee"),(0,s.yg)("p",null,"The ordering of messages is related to MessageRoutingMode and Message Key. Usually, user would want an ordering of Per-key-partition guarantee."),(0,s.yg)("p",null,"If there is a key attached to message, the messages will be routed to corresponding partitions based on the hashing scheme specified by ",(0,s.yg)("a",{parentName:"p",href:"https://pulsar.apache.org/api/client/3.0.x/org/apache/pulsar/client/api/HashingScheme"},"HashingScheme")," in ",(0,s.yg)("a",{parentName:"p",href:"https://pulsar.apache.org/api/client/3.0.x/org/apache/pulsar/client/api/ProducerBuilder"},"ProducerBuilder"),", when using either ",(0,s.yg)("inlineCode",{parentName:"p"},"SinglePartition")," or ",(0,s.yg)("inlineCode",{parentName:"p"},"RoundRobinPartition")," mode."),(0,s.yg)("table",null,(0,s.yg)("thead",{parentName:"table"},(0,s.yg)("tr",{parentName:"thead"},(0,s.yg)("th",{parentName:"tr",align:"left"},"Ordering guarantee"),(0,s.yg)("th",{parentName:"tr",align:"left"},"Description"),(0,s.yg)("th",{parentName:"tr",align:"left"},"Routing Mode and Key"))),(0,s.yg)("tbody",{parentName:"table"},(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"Per-key-partition"),(0,s.yg)("td",{parentName:"tr",align:"left"},"All the messages with the same key will be in order and be placed in same partition."),(0,s.yg)("td",{parentName:"tr",align:"left"},"Use either ",(0,s.yg)("inlineCode",{parentName:"td"},"SinglePartition")," or ",(0,s.yg)("inlineCode",{parentName:"td"},"RoundRobinPartition")," mode, and Key is provided by each message.")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:"left"},"Per-producer"),(0,s.yg)("td",{parentName:"tr",align:"left"},"All the messages from the same producer will be in order."),(0,s.yg)("td",{parentName:"tr",align:"left"},"Use ",(0,s.yg)("inlineCode",{parentName:"td"},"SinglePartition")," mode, and no Key is provided for each message.")))),(0,s.yg)("h3",{id:"hashing-scheme"},"Hashing scheme"),(0,s.yg)("p",null,(0,s.yg)("a",{parentName:"p",href:"https://pulsar.apache.org/api/client/3.0.x/org/apache/pulsar/client/api/HashingScheme"},"HashingScheme")," is an enum that represents sets of standard hashing functions available when choosing the partition to use for a particular message."),(0,s.yg)("p",null,"There are 2 types of standard hashing functions available: ",(0,s.yg)("inlineCode",{parentName:"p"},"JavaStringHash")," and ",(0,s.yg)("inlineCode",{parentName:"p"},"Murmur3_32Hash"),".\nThe default hashing function for producers is ",(0,s.yg)("inlineCode",{parentName:"p"},"JavaStringHash"),".\nPlease pay attention that ",(0,s.yg)("inlineCode",{parentName:"p"},"JavaStringHash")," is not useful when producers can be from different multiple language clients, under this use case, it is recommended to use ",(0,s.yg)("inlineCode",{parentName:"p"},"Murmur3_32Hash"),"."),(0,s.yg)("h2",{id:"non-persistent-topics"},"Non-persistent topics"),(0,s.yg)("p",null,"By default, Pulsar persistently stores ",(0,s.yg)("em",{parentName:"p"},"all")," unacknowledged messages on multiple ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/concepts-architecture-overview#persistent-storage"},"BookKeeper")," bookies (storage nodes). Data for messages on persistent topics can thus survive broker restarts and subscriber failover."),(0,s.yg)("p",null,"Pulsar also, however, supports ",(0,s.yg)("strong",{parentName:"p"},"non-persistent topics"),", which are topics on which messages are ",(0,s.yg)("em",{parentName:"p"},"never")," persisted to disk and live only in memory. When using non-persistent delivery, killing a Pulsar broker or disconnecting a subscriber to a topic means that all in-transit messages are lost on that (non-persistent) topic, meaning that clients may see message loss."),(0,s.yg)("p",null,"Non-persistent topics have names of this form (note the ",(0,s.yg)("inlineCode",{parentName:"p"},"non-persistent")," in the name):"),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-http"},"non-persistent://tenant/namespace/topic\n")),(0,s.yg)("p",null,"For more info on using non-persistent topics, see the ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/cookbooks-non-persistent"},"Non-persistent messaging cookbook"),"."),(0,s.yg)("p",null,"In non-persistent topics, brokers immediately deliver messages to all connected subscribers ",(0,s.yg)("em",{parentName:"p"},"without persisting them")," in ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/concepts-architecture-overview#persistent-storage"},"BookKeeper"),". If a subscriber is disconnected, the broker will not be able to deliver those in-transit messages, and subscribers will never be able to receive those messages again. Eliminating the persistent storage step makes messaging on non-persistent topics slightly faster than on persistent topics in some cases, but with the caveat that some core benefits of Pulsar are lost."),(0,s.yg)("blockquote",null,(0,s.yg)("p",{parentName:"blockquote"},"With non-persistent topics, message data lives only in memory, without a specific buffer - which means data ",(0,s.yg)("em",{parentName:"p"},"is not")," buffered in memory. The received messages are immediately transmitted to all ",(0,s.yg)("em",{parentName:"p"},"connected consumers"),". If a message broker fails or message data can otherwise not be retrieved from memory, your message data may be lost. Use non-persistent topics only if you're ",(0,s.yg)("em",{parentName:"p"},"certain")," that your use case requires it and can sustain it.")),(0,s.yg)("p",null,"By default, non-persistent topics are enabled on Pulsar brokers. You can disable them in the broker's ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/reference-configuration#broker-enableNonPersistentTopics"},"configuration"),". You can manage non-persistent topics using the ",(0,s.yg)("inlineCode",{parentName:"p"},"pulsar-admin topics")," command. For more information, see ",(0,s.yg)("a",{parentName:"p",href:"pathname:///reference/#/3.0.x/pulsar-admin/"},(0,s.yg)("inlineCode",{parentName:"a"},"pulsar-admin")),"."),(0,s.yg)("p",null,"Currently, non-persistent topics which are not partitioned are not persisted to ZooKeeper, which means if the broker owning them crashes, they do not get re-assigned to another broker because they only exist in the owner broker memory. The current workaround is to set the value of ",(0,s.yg)("inlineCode",{parentName:"p"},"allowAutoTopicCreation")," to ",(0,s.yg)("inlineCode",{parentName:"p"},"true")," and ",(0,s.yg)("inlineCode",{parentName:"p"},"allowAutoTopicCreationType")," to ",(0,s.yg)("inlineCode",{parentName:"p"},"non-partitioned")," (they are default values) in broker configuration."),(0,s.yg)("h3",{id:"performance"},"Performance"),(0,s.yg)("p",null,"Non-persistent messaging is usually faster than persistent messaging because brokers don't persist messages and immediately send acks back to the producer as soon as that message is delivered to connected brokers. Producers thus see comparatively low publish latency with non-persistent topic."),(0,s.yg)("h3",{id:"client-api"},"Client API"),(0,s.yg)("p",null,"Producers and consumers can connect to non-persistent topics in the same way as persistent topics, with the crucial difference that the topic name must start with ",(0,s.yg)("inlineCode",{parentName:"p"},"non-persistent"),". All the subscription types---",(0,s.yg)("a",{parentName:"p",href:"#exclusive"},"exclusive"),", ",(0,s.yg)("a",{parentName:"p",href:"#shared"},"shared"),", ",(0,s.yg)("a",{parentName:"p",href:"#key_shared"},"key_shared")," and ",(0,s.yg)("a",{parentName:"p",href:"#failover"},"failover"),"---are supported for non-persistent topics."),(0,s.yg)("p",null,"Here's an example ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/client-libraries-java-use#create-a-consumer"},"Java consumer")," for a non-persistent topic:"),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},'PulsarClient client = PulsarClient.builder()\n        .serviceUrl("pulsar://localhost:6650")\n        .build();\nString npTopic = "non-persistent://public/default/my-topic";\nString subscriptionName = "my-subscription-name";\n\nConsumer<byte[]> consumer = client.newConsumer()\n        .topic(npTopic)\n        .subscriptionName(subscriptionName)\n        .subscribe();\n')),(0,s.yg)("p",null,"Here's an example ",(0,s.yg)("a",{parentName:"p",href:"client-libraries-java-use/#create-a-producer"},"Java producer")," for the same non-persistent topic:"),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},"Producer<byte[]> producer = client.newProducer()\n                .topic(npTopic)\n                .create();\n")),(0,s.yg)("h2",{id:"system-topic"},"System topic"),(0,s.yg)("p",null,"System topic is a predefined topic for internal use within Pulsar. It can be either a persistent or non-persistent topic."),(0,s.yg)("p",null,"System topics serve to implement certain features and eliminate dependencies on third-party components, such as transactions, heartbeat detections, topic-level policies, and resource group services. System topics empower the implementation of these features to be simplified, dependent, and flexible. Take heartbeat detections for example, you can leverage the system topic for health check to internally enable producer/reader to produce/consume messages under the heartbeat namespace, which can detect whether the current service is still alive."),(0,s.yg)("p",null,"The following table outlines the available system topics for each specific namespace."),(0,s.yg)("table",null,(0,s.yg)("thead",{parentName:"table"},(0,s.yg)("tr",{parentName:"thead"},(0,s.yg)("th",{parentName:"tr",align:null},"Namespace"),(0,s.yg)("th",{parentName:"tr",align:null},"TopicName"),(0,s.yg)("th",{parentName:"tr",align:null},"Domain"),(0,s.yg)("th",{parentName:"tr",align:null},"Count"),(0,s.yg)("th",{parentName:"tr",align:null},"Usage"))),(0,s.yg)("tbody",{parentName:"table"},(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:null},"pulsar/system"),(0,s.yg)("td",{parentName:"tr",align:null},(0,s.yg)("inlineCode",{parentName:"td"},"transaction_coordinator_assign_${id}")),(0,s.yg)("td",{parentName:"tr",align:null},"Persistent"),(0,s.yg)("td",{parentName:"tr",align:null},"Default 16"),(0,s.yg)("td",{parentName:"tr",align:null},"Transaction coordinator")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:null},"pulsar/system"),(0,s.yg)("td",{parentName:"tr",align:null},(0,s.yg)("inlineCode",{parentName:"td"},"__transaction_log_${tc_id}")),(0,s.yg)("td",{parentName:"tr",align:null},"Persistent"),(0,s.yg)("td",{parentName:"tr",align:null},"Default 16"),(0,s.yg)("td",{parentName:"tr",align:null},"Transaction log")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:null},"pulsar/system"),(0,s.yg)("td",{parentName:"tr",align:null},(0,s.yg)("inlineCode",{parentName:"td"},"resource-usage")),(0,s.yg)("td",{parentName:"tr",align:null},"Non-persistent"),(0,s.yg)("td",{parentName:"tr",align:null},"Default 4"),(0,s.yg)("td",{parentName:"tr",align:null},"Resource group service")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:null},"host/port"),(0,s.yg)("td",{parentName:"tr",align:null},(0,s.yg)("inlineCode",{parentName:"td"},"heartbeat")),(0,s.yg)("td",{parentName:"tr",align:null},"Persistent"),(0,s.yg)("td",{parentName:"tr",align:null},"1"),(0,s.yg)("td",{parentName:"tr",align:null},"Heartbeat detection")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:null},"User-defined-ns"),(0,s.yg)("td",{parentName:"tr",align:null},(0,s.yg)("a",{parentName:"td",href:"/docs/3.0.x/concepts-multi-tenancy#namespace-change-events-and-topic-level-policies"},(0,s.yg)("inlineCode",{parentName:"a"},"__change_events"))),(0,s.yg)("td",{parentName:"tr",align:null},"Persistent"),(0,s.yg)("td",{parentName:"tr",align:null},"Default 4"),(0,s.yg)("td",{parentName:"tr",align:null},"Topic events")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:null},"User-defined-ns"),(0,s.yg)("td",{parentName:"tr",align:null},(0,s.yg)("inlineCode",{parentName:"td"},"__transaction_buffer_snapshot")),(0,s.yg)("td",{parentName:"tr",align:null},"Persistent"),(0,s.yg)("td",{parentName:"tr",align:null},"One per namespace"),(0,s.yg)("td",{parentName:"tr",align:null},"Transaction buffer snapshots")),(0,s.yg)("tr",{parentName:"tbody"},(0,s.yg)("td",{parentName:"tr",align:null},"User-defined-ns"),(0,s.yg)("td",{parentName:"tr",align:null},(0,s.yg)("inlineCode",{parentName:"td"},"${topicName}__transaction_pending_ack")),(0,s.yg)("td",{parentName:"tr",align:null},"Persistent"),(0,s.yg)("td",{parentName:"tr",align:null},"One per every topic subscription acknowledged with transactions"),(0,s.yg)("td",{parentName:"tr",align:null},"Acknowledgments with transactions")))),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("ul",{parentName:"admonition"},(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("p",{parentName:"li"},"You cannot create any system topics. To list system topics, you can add the option ",(0,s.yg)("inlineCode",{parentName:"p"},"--include-system-topic")," when you get the topic list by using ",(0,s.yg)("a",{parentName:"p",href:"pathname:///reference/#/3.0.x/pulsar-admin/"},"Pulsar admin API"),".")),(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("p",{parentName:"li"},"Since Pulsar version 2.11.0, system topics are enabled by default.\nIn earlier versions, you need to change the following configurations in the ",(0,s.yg)("inlineCode",{parentName:"p"},"conf/broker.conf")," or ",(0,s.yg)("inlineCode",{parentName:"p"},"conf/standalone.conf")," file to enable system topics."),(0,s.yg)("pre",{parentName:"li"},(0,s.yg)("code",{parentName:"pre",className:"language-properties"},"systemTopicEnabled=true\ntopicLevelPoliciesEnabled=true\n"))))),(0,s.yg)("h2",{id:"message-redelivery"},"Message redelivery"),(0,s.yg)("p",null,"Apache Pulsar supports graceful failure handling and ensures critical data is not lost. Software will always have unexpected conditions and at times messages may not be delivered successfully. Therefore, it is important to have a built-in mechanism that handles failure, particularly in asynchronous messaging as highlighted in the following examples."),(0,s.yg)("ul",null,(0,s.yg)("li",{parentName:"ul"},"Consumers get disconnected from the database or the HTTP server. When this happens, the database is temporarily offline while the consumer is writing the data to it and the external HTTP server that the consumer calls are momentarily unavailable."),(0,s.yg)("li",{parentName:"ul"},"Consumers get disconnected from a broker due to consumer crashes, broken connections, etc. As a consequence, unacknowledged messages are delivered to other available consumers.")),(0,s.yg)("p",null,"Apache Pulsar avoids these and other message delivery failures using at-least-once delivery semantics that ensure Pulsar processes a message more than once."),(0,s.yg)("p",null,"To utilize message redelivery, you need to enable this mechanism before the broker can resend the unacknowledged messages in Apache Pulsar client. You can activate the message redelivery mechanism in Apache Pulsar using three methods."),(0,s.yg)("ul",null,(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("a",{parentName:"li",href:"#negative-acknowledgment"},"Negative Acknowledgment")),(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("a",{parentName:"li",href:"#acknowledgment-timeout"},"Acknowledgment Timeout")),(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("a",{parentName:"li",href:"#retry-letter-topic"},"Retry letter topic"))),(0,s.yg)("h2",{id:"message-retention-and-expiry"},"Message retention and expiry"),(0,s.yg)("p",null,"By default, Pulsar message brokers:"),(0,s.yg)("ul",null,(0,s.yg)("li",{parentName:"ul"},"immediately delete ",(0,s.yg)("em",{parentName:"li"},"all")," messages that have been acknowledged by a consumer, and"),(0,s.yg)("li",{parentName:"ul"},(0,s.yg)("a",{parentName:"li",href:"/docs/3.0.x/concepts-architecture-overview#persistent-storage"},"persistently store")," all unacknowledged messages in a message backlog.")),(0,s.yg)("p",null,"Pulsar has two features, however, that enable you to override this default behavior:"),(0,s.yg)("ul",null,(0,s.yg)("li",{parentName:"ul"},"Message ",(0,s.yg)("strong",{parentName:"li"},"retention")," enables you to store messages that have been acknowledged by a consumer"),(0,s.yg)("li",{parentName:"ul"},"Message ",(0,s.yg)("strong",{parentName:"li"},"expiry")," enables you to set a time to live (TTL) for messages that have not yet been acknowledged")),(0,s.yg)("admonition",{type:"tip"},(0,s.yg)("p",{parentName:"admonition"},"Since Pulsar 2.7.0, all message retention and expiry can be managed at the ",(0,s.yg)("a",{parentName:"p",href:"#namespaces"},"namespace")," level or at the topic level. For example, you can set ",(0,s.yg)("inlineCode",{parentName:"p"},"topicLevelPoliciesEnabled=true")," at ",(0,s.yg)("inlineCode",{parentName:"p"},"broker.conf"),". "),(0,s.yg)("p",{parentName:"admonition"},"Since Pulsaer 2.11.0, the default value of  ",(0,s.yg)("inlineCode",{parentName:"p"},"topicLevelPoliciesEnabled")," is ",(0,s.yg)("inlineCode",{parentName:"p"},"true"),". "),(0,s.yg)("p",{parentName:"admonition"},"For how to set policies for message retention and expiry, see ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/cookbooks-retention-expiry"},"message retention and expiry"),".")),(0,s.yg)("p",null,(0,s.yg)("img",{alt:"Message retention and expiry",src:a(14222).A,width:"1797",height:"867"})),(0,s.yg)("p",null,"With message retention, shown at the top, a retention policy applied to all topics in a namespace dictates that some messages are durably stored in Pulsar even though they've already been acknowledged. Acknowledged messages that are not covered by the retention policy are deleted. Without a retention policy, all of the acknowledged messages would be deleted."),(0,s.yg)("p",null,"With message expiry, shown at the bottom, some messages are deleted, even though they haven't been acknowledged, because they've expired according to the TTL applied to the namespace (for example because a TTL of 5 minutes has been applied and the messages haven't been acknowledged but are 10 minutes old)."),(0,s.yg)("h2",{id:"message-deduplication"},"Message deduplication"),(0,s.yg)("p",null,"Message duplication occurs when a message is ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/concepts-architecture-overview#persistent-storage"},"persisted")," by Pulsar more than once. Message deduplication is an optional Pulsar feature that prevents unnecessary message duplication by processing each message only once, even if the message is received more than once."),(0,s.yg)("p",null,"The following diagram illustrates what happens when message deduplication is disabled vs. enabled:"),(0,s.yg)("p",null,(0,s.yg)("img",{alt:"Pulsar message deduplication",src:a(55961).A,width:"1720",height:"920"})),(0,s.yg)("p",null,"Message deduplication is disabled in the scenario shown at the top. Here, a producer publishes message 1 on a topic; the message reaches a Pulsar broker and is ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/concepts-architecture-overview#persistent-storage"},"persisted")," to BookKeeper. The producer then sends message 1 again (in this case due to some retry logic), and the message is received by the broker and stored in BookKeeper again, which means that duplication has occurred."),(0,s.yg)("p",null,"In the second scenario at the bottom, the producer publishes message 1, which is received by the broker and persisted, as in the first scenario. When the producer attempts to publish the message again, however, the broker knows that it has already seen message 1 and thus does not persist the message."),(0,s.yg)("admonition",{type:"tip"},(0,s.yg)("ul",{parentName:"admonition"},(0,s.yg)("li",{parentName:"ul"},"Message deduplication is handled at the namespace level or the topic level. For more instructions, see the ",(0,s.yg)("a",{parentName:"li",href:"/docs/3.0.x/cookbooks-deduplication"},"message deduplication cookbook"),"."),(0,s.yg)("li",{parentName:"ul"},"You can read the design of Message Deduplication in ",(0,s.yg)("a",{parentName:"li",href:"https://github.com/aahmed-se/pulsar-wiki/blob/master/PIP-6:-Guaranteed-Message-Deduplication.md"},"PIP-6"),"."))),(0,s.yg)("h3",{id:"producer-idempotency"},"Producer idempotency"),(0,s.yg)("p",null,"The other available approach to message deduplication is to ensure that each message is ",(0,s.yg)("em",{parentName:"p"},"only produced once"),". This approach is typically called ",(0,s.yg)("strong",{parentName:"p"},"producer idempotency"),". The drawback of this approach is that it defers the work of message deduplication to the application. In Pulsar, this is handled at the ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/reference-terminology#broker"},"broker")," level, so you do not need to modify your Pulsar client code. Instead, you only need to make administrative changes. For details, see ",(0,s.yg)("a",{parentName:"p",href:"/docs/3.0.x/cookbooks-deduplication"},"Managing message deduplication"),"."),(0,s.yg)("h3",{id:"deduplication-and-effectively-once-semantics"},"Deduplication and effectively-once semantics"),(0,s.yg)("p",null,"Message deduplication makes Pulsar an ideal messaging system to be used in conjunction with stream processing engines (SPEs) and other systems seeking to provide effectively-once processing semantics. Messaging systems that do not offer automatic message deduplication require the SPE or other system to guarantee deduplication, which means that strict message ordering comes at the cost of burdening the application with the responsibility of deduplication. With Pulsar, strict ordering guarantees come at no application-level cost."),(0,s.yg)("h2",{id:"delayed-message-delivery"},"Delayed message delivery"),(0,s.yg)("p",null,"Delayed message delivery enables you to consume a message later. In this mechanism, a message is stored in BookKeeper. The ",(0,s.yg)("inlineCode",{parentName:"p"},"DelayedDeliveryTracker")," maintains the time index (time -> messageId) in memory after the message is published to a broker. This message will be delivered to a consumer once the specified delay is over."),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("p",{parentName:"admonition"},"Only shared and key-shared subscriptions support delayed message delivery. In other subscriptions, delayed messages are dispatched immediately.")),(0,s.yg)("p",null,"The diagram below illustrates the concept of delayed message delivery:"),(0,s.yg)("p",null,(0,s.yg)("img",{alt:"Delayed Message Delivery",src:a(41111).A,width:"1640",height:"520"})),(0,s.yg)("p",null,"A broker saves a message without any check. When a consumer consumes a message, if the message is set to delay, then the message is added to ",(0,s.yg)("inlineCode",{parentName:"p"},"DelayedDeliveryTracker"),". A subscription checks and gets timeout messages from ",(0,s.yg)("inlineCode",{parentName:"p"},"DelayedDeliveryTracker"),"."),(0,s.yg)("admonition",{type:"note"},(0,s.yg)("p",{parentName:"admonition"},"Work with retention policy: In Pulsar, the ledger will be deleted automatically after the messages in this ledger have been consumed. Pulsar will delete the front ledgers of a topic but will not delete ledgers from the middle of a topic. It means that if you send a message that is delayed for a long time, the message will not be consumed until it reaches the delay time. This means all the ledgers on this topic could not be deleted until the delayed message is consumed, even if some subsequent ledgers are fully consumed."),(0,s.yg)("p",{parentName:"admonition"},"Work with backlog quota policy: After using delayed messages, it is advisable to exercise caution when using the Backlog Quota strategy. This is because delayed messages can result in not being consumed for an extended period, triggering the Backlog Quota strategy and causing subsequent message sends to be rejected."),(0,s.yg)("p",{parentName:"admonition"},"Work with backlog TTL policy: When the TTL expires, Pulsar automatically moves the message to the acknowledged state (and thus makes it ready for deletion) even if the messages are delayed messages and does not care about when the expected delayed time is.")),(0,s.yg)("h3",{id:"broker"},"Broker"),(0,s.yg)("p",null,"Delayed message delivery is enabled by default. You can change it in the broker configuration file as below:"),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-conf"},"# Whether to enable the delayed delivery for messages.\n# If disabled, messages are immediately delivered and there is no tracking overhead.\ndelayedDeliveryEnabled=true\n\n# Control the ticking time for the retry of delayed message delivery,\n# affecting the accuracy of the delivery time compared to the scheduled time.\n# Note that this time is used to configure the HashedWheelTimer's tick time for the\n# InMemoryDelayedDeliveryTrackerFactory (the default DelayedDeliverTrackerFactory).\n# Default is 1 second.\ndelayedDeliveryTickTimeMillis=1000\n\n# When using the InMemoryDelayedDeliveryTrackerFactory (the default DelayedDeliverTrackerFactory), whether\n# the deliverAt time is strictly followed. When false (default), messages may be sent to consumers before the deliverAt\n# time by as much as the tickTimeMillis. This can reduce the overhead on the broker of maintaining the delayed index\n# for a potentially very short time period. When true, messages will not be sent to consumer until the deliverAt time\n# has passed, and they may be as late as the deliverAt time plus the tickTimeMillis for the topic plus the\n# delayedDeliveryTickTimeMillis.\nisDelayedDeliveryDeliverAtTimeStrict=false\n")),(0,s.yg)("h3",{id:"producer"},"Producer"),(0,s.yg)("p",null,"The following is an example of delayed message delivery for a producer in Java:"),(0,s.yg)("pre",null,(0,s.yg)("code",{parentName:"pre",className:"language-java"},'// message to be delivered at the configured delay interval\nproducer.newMessage().deliverAfter(3L, TimeUnit.Minute).value("Hello Pulsar!").send();\n')))}u.isMDXComponent=!0},37340:(e,t,a)=>{a.d(t,{A:()=>n});const n=a.p+"assets/images/batching-a9d3dbabf97b2b6c504c6f353ccfda98.svg"},50540:(e,t,a)=>{a.d(t,{A:()=>n});const n=a.p+"assets/images/chunking-01-194c42c53633b89cb7f4653c537d4264.png"},70599:(e,t,a)=>{a.d(t,{A:()=>n});const n=a.p+"assets/images/chunking-02-50ca285dd380b4bbecc01774655ead49.png"},55961:(e,t,a)=>{a.d(t,{A:()=>n});const n=a.p+"assets/images/message-deduplication-854309d2abf6e9ba16d2a3f090e59ace.svg"},41111:(e,t,a)=>{a.d(t,{A:()=>n});const n=a.p+"assets/images/message-delay-bcb21c8762efb886a192ae9557096f5d.svg"},83269:(e,t,a)=>{a.d(t,{A:()=>n});const n=a.p+"assets/images/partitioning-622ea170dd771fd212d6b7378f2bd928.png"},83611:(e,t,a)=>{a.d(t,{A:()=>n});const n=a.p+"assets/images/pub-sub-border-f20912d3eb1385f083ce0406685ceab7.svg"},35405:(e,t,a)=>{a.d(t,{A:()=>n});const n=a.p+"assets/images/pulsar-exclusive-subscriptions-b3304e5b293d0a6da17637735fcb1650.svg"},98833:(e,t,a)=>{a.d(t,{A:()=>n});const n=a.p+"assets/images/pulsar-failover-subscriptions-1-bb15a6e2f6373dc1f20eecf1779ee0c7.svg"},58082:(e,t,a)=>{a.d(t,{A:()=>n});const n=a.p+"assets/images/pulsar-failover-subscriptions-2-1f72791597afa07fa987ae1f7bc5cd42.svg"},45459:(e,t,a)=>{a.d(t,{A:()=>n});const n=a.p+"assets/images/pulsar-failover-subscriptions-3-2b2e00ef5ee525ca7c1fd21dcd67e328.svg"},22892:(e,t,a)=>{a.d(t,{A:()=>n});const n=a.p+"assets/images/pulsar-failover-subscriptions-4-74e4b825d13ce1197c1281819fe14554.svg"},29128:(e,t,a)=>{a.d(t,{A:()=>n});const n=a.p+"assets/images/pulsar-key-shared-subscriptions-17bf12baab858b4ac0e66b9207bf4503.svg"},91542:(e,t,a)=>{a.d(t,{A:()=>n});const n=a.p+"assets/images/pulsar-shared-subscriptions-c368030415b85eb3ef96448f79e87a58.svg"},69036:(e,t,a)=>{a.d(t,{A:()=>n});const n=a.p+"assets/images/pulsar-subscription-types-664733b68c7124129ca7d0e04dedcb96.png"},14222:(e,t,a)=>{a.d(t,{A:()=>n});const n=a.p+"assets/images/retention-expiry-e45fc08fa68c18a8f1d4868ec2c022d7.svg"},63249:(e,t,a)=>{a.d(t,{A:()=>n});const n=a.p+"assets/images/retry-letter-topic-5304f63457e6c17da20d0de7b6897a5b.svg"}}]);