我們將要簡要介紹
Topic(主題)、Subsription(訂閱)和Cursors(游標)的基本概念
不會包含深層次的訊息傳遞方式
Topic和Subscription如下
訊息存盤在Topic中，
邏輯上一個Topic是日志結構，每個訊息都在這個日志結構中有一個偏移量，
Apache Pulsar使用游標來跟蹤偏移量，
生產者將訊息發送到一個指定的Topic，Apache Pulsar保證訊息一旦被確認就不會丟失(正確的配置和非整個集群故障的情況下)，
消費者通過訂閱來消費Topic中的訊息，訂閱是游標(跟蹤偏移量)的邏輯物體，并且還根據不同的訂閱型別提供一些額外的保證
-
Exclusive(獨享) - 一個訂閱只能有一個訊息者消費訊息
-
Shared(共享) - 一個訂閱中同時可以有多個消費者，多個消費者共享Topic中的訊息
-
Fail-Over(災備) - 一個訂閱同時只有一個消費者，可以有多個備份消費者，一旦主消費者故障則備份消費者接管，不會出現同時有兩個活躍的消費者，
一個Topic可以添加多個訂閱，訂閱不包含訊息的資料，只包含元資料和游標，
Apache Pulsar通過允許消費者將Topic看做在消費者消費確認后洗掉訊息的佇列，或者消費者可以根據游標的回放來提供佇列和日志的語意，在底層都使用日志作為存盤模型，
如果沒有對Topic設定資料保留策略（目前通過其命名空間，后面會提供Topic級別的設定），一旦一個Topic的所有訂閱的游標都已經成功消費到一個偏移量時，此偏移量前面的訊息就會被自動洗掉，也就是說需要該Topic的所有訂閱上得到消費確認，
但是，如果Topic設定了資料保留策略，已經消費確認的訊息超過保留策略閾值(Topic的訊息存盤大小、Topic中訊息保留的時間)后會被洗掉，
消費者可以以單潭訓者累積的方式確認訊息，累積確認會有更好的吞吐量，但是在訊息消費失敗后會引入重復的訊息處理，注意，累積消費不適用于共享模式的訂閱，因為累積確認是基于偏移量的，但是在客戶端API中支持批量確認，這樣會減少RPC呼叫次數來提高在共享模式下訂閱競爭消費的吞吐量，
最后，有一些類似于kafka Topic的磁區(Partition)，區別在于Apache Pulsar中的磁區也是Topic，就像kafka一樣，生產者可以輪詢、hash或者明確指定磁區來發送訊息，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/271549.html
標籤：其他