Apache Kafka 中用于錯(cuò)誤處理的死信隊(duì)列：來自 Uber 和 Crowdstrike 的替代方案、最佳實(shí)踐和案例研究。
識(shí)別和處理錯(cuò)誤對(duì)于任何可靠的數(shù)據(jù)流管道都是必不可少的。這篇博文探討了 在 Apache Kafka 基礎(chǔ)架構(gòu)中使用死信隊(duì)列實(shí)現(xiàn)錯(cuò)誤處理的最佳實(shí)踐。這些選項(xiàng)包括自定義實(shí)現(xiàn)、Kafka Streams、Kafka Connect、Spring 框架和并行消費(fèi)者。真實(shí)案例研究展示了 Uber、CrowdStrike 和桑坦德銀行如何以極端規(guī)模構(gòu)建可靠的實(shí)時(shí)錯(cuò)誤處理。
Apache Kafka 成為許多企業(yè)架構(gòu)最喜歡的集成中間件。即使對(duì)于云優(yōu)先戰(zhàn)略，企業(yè)也可以利用 Kafka 的數(shù)據(jù)流作為云原生集成平臺(tái)即服務(wù) (iPaaS)。
Apache Kafka 數(shù)據(jù)流中的消息隊(duì)列模式
在我開始這篇文章之前，我想讓你知道這個(gè)內(nèi)容是關(guān)于“JMS、消息隊(duì)列和 Apache Kafka”的博客系列的一部分：
- JMS 消息代理與 Apache Kafka 數(shù)據(jù)流的10 個(gè)比較標(biāo)準(zhǔn)
- 這篇文章– 通過Apache Kafka 中的死信隊(duì)列 (DQL)進(jìn)行錯(cuò)誤處理的替代方法
- 使用 Apache Kafka實(shí)現(xiàn)請(qǐng)求-回復(fù)模式
- 即將推出——用于選擇正確消息系統(tǒng)的決策樹（JMS 與 Apache Kafka）
- 即將推出——從 JMS 消息代理到 Apache Kafka：集成、遷移和/或替換
死信隊(duì)列 (DLQ)是消息系統(tǒng)或數(shù)據(jù)流平臺(tái)內(nèi)的一種服務(wù)實(shí)現(xiàn)，用于存儲(chǔ)未成功處理的消息。系統(tǒng)不是被動(dòng)地轉(zhuǎn)儲(chǔ)消息，而是將其移動(dòng)到死信隊(duì)列。
企業(yè)集成模式 (EIP)改為調(diào)用設(shè)計(jì)模式死信通道。我們可以將兩者用作同義詞。
本文重點(diǎn)介紹數(shù)據(jù)流平臺(tái) Apache Kafka。在 Kafka 中將消息放入 DLQ 的主要原因通常是消息格式錯(cuò)誤或消息內(nèi)容無效/缺失。例如，如果預(yù)期值是整數(shù)，但生產(chǎn)者發(fā)送了字符串，則會(huì)發(fā)生應(yīng)用程序錯(cuò)誤。在更動(dòng)態(tài)的環(huán)境中，“主題不存在”異常可能是無法傳遞消息的另一個(gè)錯(cuò)誤。
因此，通常不要使用現(xiàn)有中間件經(jīng)驗(yàn)中的知識(shí)。Message Queue 中間件（如符合 JMS 的 IBM MQ、TIBCO EMS 或 RabbitMQ）與分布式提交日志（如 Kafka）的工作方式不同。由于許多其他原因，消息隊(duì)列中的 DLQ 用于消息隊(duì)列系統(tǒng)，這些原因不能一對(duì)一地映射到 Kafka。例如，MQ 系統(tǒng)中的消息由于每條消息的 TTL（生存時(shí)間）而過期。
因此，在 Kafka 中將消息放入 DLQ 的主要原因是消息格式錯(cuò)誤或消息內(nèi)容無效/缺失。
Apache Kafka 中死信隊(duì)列的替代方案
Kafka 中的死信隊(duì)列是一個(gè)或多個(gè) Kafka 主題，它們接收和存儲(chǔ)由于錯(cuò)誤而無法在另一個(gè)流管道中處理的消息。此概念允許使用以下傳入消息繼續(xù)消息流，而不會(huì)由于無效消息的錯(cuò)誤而停止工作流。
Kafka Broker 很笨——智能端點(diǎn)提供錯(cuò)誤處理
Kafka 架構(gòu)不支持 broker r 中的DLQ。有意地，Kafka 建立在與現(xiàn)代微服務(wù)相同的原則上，使用“啞管道和智能端點(diǎn)”原則。這就是為什么與傳統(tǒng)消息代理相比，Kafka 的擴(kuò)展性如此之好。過濾和錯(cuò)誤處理發(fā)生在客戶端應(yīng)用程序中。
數(shù)據(jù)流平臺(tái)的真正解耦可以實(shí)現(xiàn)更干凈的領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)。每個(gè)微服務(wù)或應(yīng)用程序都通過自己選擇的技術(shù)、通信范式和錯(cuò)誤處理來實(shí)現(xiàn)其邏輯。
在傳統(tǒng)的中間件和消息隊(duì)列中，代理提供了這種邏輯。結(jié)果是域中的可擴(kuò)展性和靈活性較差，因?yàn)橹挥兄虚g件團(tuán)隊(duì)才能實(shí)現(xiàn)集成邏輯。
用任何編程語(yǔ)言自定義實(shí)現(xiàn) Kafka 死信隊(duì)列
Kafka 中的死信隊(duì)列獨(dú)立于您使用的框架。一些組件為錯(cuò)誤處理和死信隊(duì)列提供了開箱即用的功能。但是，使用JAVA、Go、C++、Python/ target=_blank class=infotextkey>Python 等任何編程語(yǔ)言為 Kafka 應(yīng)用程序編寫死信隊(duì)列邏輯也很容易。
死信隊(duì)列實(shí)現(xiàn)的源代碼包含一個(gè) try-catch 塊來處理預(yù)期或意外異常。如果沒有發(fā)生錯(cuò)誤，則處理該消息。如果發(fā)生任何異常，請(qǐng)將消息發(fā)送到專用的 DLQ Kafka 主題。
失敗原因應(yīng)添加到 Kafka 消息的標(biāo)頭中。不應(yīng)更改鍵和值，以便將來對(duì)歷史事件進(jìn)行重新處理和故障分析。
死信隊(duì)列的開箱即用 Kafka 實(shí)現(xiàn)
你并不總是需要實(shí)現(xiàn)你的死信隊(duì)列。許多組件和框架已經(jīng)提供了它們的 DLQ 實(shí)現(xiàn)。
使用您自己的應(yīng)用程序，您通常可以控制錯(cuò)誤或在出現(xiàn)錯(cuò)誤時(shí)修復(fù)代碼。但是，與 3rd 方應(yīng)用程序的集成并不一定允許您處理可能跨集成障礙引入的錯(cuò)誤。因此，DLQ 變得更加重要，并被包含在某些框架中。
Kafka Connect 內(nèi)置死信隊(duì)列
Kafka Connect 是 Kafka 的集成框架。它包含在開源 Kafka 下載中。不需要其他依賴項(xiàng)（除了您部署到 Connect 集群中的連接器本身）。
默認(rèn)情況下，如果由于使用無效消息而發(fā)生錯(cuò)誤（例如使用錯(cuò)誤的 JSON 轉(zhuǎn)換器而不是正確的 AVRO 轉(zhuǎn)換器時(shí)），Kafka Connect 任務(wù)將停止。刪除無效消息是另一種選擇。后者容忍錯(cuò)誤。
Kafka Connect 中 DLQ 的配置很簡(jiǎn)單。只需將兩個(gè)配置選項(xiàng) ' errors.tolerance' 和 ' errors.deadletterqueue.topic.name' 的值設(shè)置為正確的值：
博客文章“ Kafka Connect Deep Dive – 錯(cuò)誤處理和死信隊(duì)列”顯示了使用 DLQ 的詳細(xì)動(dòng)手代碼示例。
Kafka Connect 甚至可以用于處理 DLQ 中的錯(cuò)誤消息。只需部署另一個(gè)使用 te DLQ 主題的連接器。例如，如果您的應(yīng)用程序處理 Avro 消息并且傳入消息是 JSON 格式。然后連接器使用 JSON 消息并將其轉(zhuǎn)換為 AVRO 消息以成功重新處理：
請(qǐng)注意，Kafka Connect 沒有用于源連接器的死信隊(duì)列。
Kafka Streams 應(yīng)用程序中的錯(cuò)誤處理
Kafka Streams 是 Kafka 的流處理庫(kù)。它可與其他流式傳輸框架相媲美，例如 Apache Flink、Storm、Beam 和類似工具。但是，它是 Kafka 原生的。這意味著您可以在單個(gè)可擴(kuò)展且可靠的基礎(chǔ)架構(gòu)中構(gòu)建完整的端到端數(shù)據(jù)流。
如果您分別使用 Java（JVM 生態(tài)系統(tǒng)）來構(gòu)建 Kafka 應(yīng)用程序，建議幾乎總是使用 Kafka Streams 而不是 Kafka 的標(biāo)準(zhǔn) Java 客戶端。為什么？
- Kafka Streams“只是”一個(gè)圍繞常規(guī) Java 生產(chǎn)者和消費(fèi)者 API 的包裝器，以及許多內(nèi)置的附加功能。
- 兩者都只是嵌入到 Java 應(yīng)用程序中的庫(kù)（JAR 文件）。
- 兩者都是開源 Kafka 下載的一部分 - 沒有額外的依賴項(xiàng)或許可證更改。
- 許多問題已經(jīng)開箱即用地解決，以構(gòu)建成熟的流處理服務(wù)（流功能、有狀態(tài)的嵌入式存儲(chǔ)、滑動(dòng)窗口、交互式查詢、錯(cuò)誤處理等等）。
Kafka Streams的內(nèi)置功能之一是默認(rèn)的反序列化異常處理程序。它允許您管理無法反序列化的記錄異常。損壞的數(shù)據(jù)、不正確的序列化邏輯或未處理的記錄類型都可能導(dǎo)致錯(cuò)誤。該功能不稱為死信隊(duì)列，但開箱即用地解決了相同的問題。
Spring Kafka 和 Spring Cloud Stream 的錯(cuò)誤處理
Spring 框架對(duì) Apache Kafka 有很好的支持。它提供了許多模板以避免自己編寫樣板代碼。Spring-Kafka 和 Spring Cloud Stream Kafka 支持各種重試和錯(cuò)誤處理選項(xiàng)，包括基于時(shí)間/計(jì)數(shù)的重試、死信隊(duì)列等。
盡管 Spring 框架功能非常豐富，但它有點(diǎn)重，并且有一個(gè)學(xué)習(xí)曲線。因此，它非常適合新建項(xiàng)目，或者如果您已經(jīng)將 Spring 用于其他場(chǎng)景的項(xiàng)目。
有很多很棒的博客文章展示了不同的示例和配置選項(xiàng)。還有用于死信隊(duì)列的官方 Spring Cloud Stream 示例。Spring 允許使用簡(jiǎn)單的注釋構(gòu)建邏輯，例如 DLQ。這種編程方法是一些開發(fā)人員鐘愛的范例，而另一些則不喜歡它。只需了解選項(xiàng)并為自己選擇合適的選項(xiàng)即可。
Apache Kafka 并行消費(fèi)者的可擴(kuò)展處理和錯(cuò)誤處理
在許多客戶對(duì)話中，事實(shí)證明，請(qǐng)求死信隊(duì)列的主要原因通常是處理連接到外部 Web 服務(wù)或數(shù)據(jù)庫(kù)的失敗。超時(shí)或 Kafka 無法并行發(fā)送各種請(qǐng)求會(huì)導(dǎo)致某些應(yīng)用程序癱瘓。這個(gè)問題有一個(gè)很好的解決方案：
Apache Kafka的并行消費(fèi)者是Apache 2.0 許可下的開源項(xiàng)目。它提供了一個(gè)帶有客戶端隊(duì)列的并行 Apache Kafka 客戶端包裝器、一個(gè)具有關(guān)鍵并發(fā)性的更簡(jiǎn)單的消費(fèi)者/生產(chǎn)者 API，以及可擴(kuò)展的非阻塞 IO處理。
該庫(kù)允許您通過單個(gè) Kafka Consumer 并行處理消息，這意味著您可以在不增加要處理的主題中的分區(qū)數(shù)量的情況下增加 Kafka Consumer 并行度。對(duì)于許多用例，這通過減少 Kafka 代理的負(fù)載來提高吞吐量和延遲。它還開辟了新的用例，例如極端并行性、外部數(shù)據(jù)豐富和排隊(duì)。
一個(gè)關(guān)鍵特性是在單個(gè) Kafka 消費(fèi)者應(yīng)用程序中處理/重復(fù) Web 服務(wù)和數(shù)據(jù)庫(kù)調(diào)用。并行化避免了一次發(fā)送單個(gè) Web 請(qǐng)求的需要：
Parallel Consumer 客戶端具有強(qiáng)大的重試邏輯。這包括可配置的延遲和動(dòng)態(tài)錯(cuò)誤或處理。錯(cuò)誤也可以發(fā)送到死信隊(duì)列。
使用死信隊(duì)列中的消息
將錯(cuò)誤發(fā)送到死信隊(duì)列后，您還沒有完成！壞消息需要被處理或至少被監(jiān)控！
死信隊(duì)列是從事件處理中帶外處理數(shù)據(jù)錯(cuò)誤處理的絕佳方式，這意味著錯(cuò)誤處理程序可以與事件處理代碼分開創(chuàng)建或演變。
存在大量使用死信隊(duì)列的錯(cuò)誤處理策略。DO 和 DONT 探索最佳實(shí)踐和經(jīng)驗(yàn)教訓(xùn)。
錯(cuò)誤處理策略
有幾個(gè)選項(xiàng)可用于處理存儲(chǔ)在死信隊(duì)列中的消息：
- 重新處理：DLQ中的一些消息需要重新處理。但是，首先，需要解決這個(gè)問題。解決方案可以是自動(dòng)腳本、編輯消息的人工交互，或向生產(chǎn)者返回錯(cuò)誤，要求重新發(fā)送（更正的）消息。
- 刪除錯(cuò)誤消息（經(jīng)過進(jìn)一步分析）：根據(jù)您的設(shè)置，可能會(huì)出現(xiàn)錯(cuò)誤消息。但是，在刪除它們之前，業(yè)務(wù)流程應(yīng)該檢查它們。例如，儀表板應(yīng)用程序可以使用錯(cuò)誤消息并將它們可視化。
- 高級(jí)分析：另一種選擇是分析傳入數(shù)據(jù)以獲取實(shí)時(shí)洞察或問題，而不是處理 DLQ 中的每條消息。例如，一個(gè)簡(jiǎn)單的 ksqlDB 應(yīng)用程序可以應(yīng)用流處理進(jìn)行計(jì)算，例如每小時(shí)錯(cuò)誤消息的平均數(shù)量或任何其他有助于確定 Kafka 應(yīng)用程序中的錯(cuò)誤的見解。
- 停止工作流：如果很少會(huì)出現(xiàn)壞消息，結(jié)果可能是停止整個(gè)業(yè)務(wù)流程。該動(dòng)作可以是自動(dòng)的，也可以由人決定。當(dāng)然，停止工作流也可以在拋出錯(cuò)誤的 Kafka 應(yīng)用程序中完成。如果需要，DLQ 將問題和決策外部化。
- 忽略：這聽起來可能是最糟糕的選擇。只是讓死信隊(duì)列填滿，什么都不做。然而，即使這樣在某些用例中也很好，比如監(jiān)控 Kafka 應(yīng)用程序的整體行為。請(qǐng)記住，Kafka 主題具有保留時(shí)間，并且在該時(shí)間之后從主題中刪除消息。只需為您設(shè)置正確的方式即可。并監(jiān)控 DQL 主題是否存在意外行為（例如填充太快）。
以下是在 Kafka 應(yīng)用程序中使用死信隊(duì)列進(jìn)行錯(cuò)誤處理的一些最佳實(shí)踐和經(jīng)驗(yàn)教訓(xùn)：
- 定義處理無效消息的業(yè)務(wù)流程（自動(dòng)與人工）
- 現(xiàn)實(shí)：通常，根本沒有人處理 DLQ 消息
- 備選方案 1：數(shù)據(jù)所有者需要接收警報(bào)，而不僅僅是基礎(chǔ)架構(gòu)團(tuán)隊(duì)
- 備選方案 2：警報(bào)應(yīng)通知記錄團(tuán)隊(duì)系統(tǒng)數(shù)據(jù)錯(cuò)誤，他們將需要從記錄系統(tǒng)重新發(fā)送/修復(fù)數(shù)據(jù)。
- 如果沒有人關(guān)心或抱怨，請(qǐng)考慮質(zhì)疑和審查 DLQ 存在的必要性。相反，這些消息也可以在初始 Kafka 應(yīng)用程序中被忽略。這節(jié)省了大量的網(wǎng)絡(luò)負(fù)載、基礎(chǔ)設(shè)施和資金。
- 構(gòu)建帶有適當(dāng)警報(bào)的儀表板并整合相關(guān)團(tuán)隊(duì)（例如，通過電子郵件或 Slack 警報(bào)）
- 定義每個(gè) Kafka 主題的錯(cuò)誤處理優(yōu)先級(jí)（停止、刪除和重新處理）
- 僅將不可重試的錯(cuò)誤消息推送到 DLQ - 連接問題是消費(fèi)者應(yīng)用程序的責(zé)任。
- 保留原始消息并將它們存儲(chǔ)在 DLQ 中（帶有額外的標(biāo)頭，例如錯(cuò)誤消息、錯(cuò)誤時(shí)間、發(fā)生錯(cuò)誤的應(yīng)用程序名稱等）——這使得重新處理和故障排除變得更加容易。
- 想想你需要多少 Dead Letter Queue Kafka 主題。總是有取舍。但是將所有錯(cuò)誤存儲(chǔ)在單個(gè) DLQ 中可能對(duì)進(jìn)一步分析和重新處理沒有意義。
請(qǐng)記住，DLQ 會(huì)以有保證的順序終止處理，并使任何類型的離線處理變得更加困難。因此，Kafka DQL 并不適合每個(gè)用例。
何時(shí)不在 Kafka 中使用死信隊(duì)列？
讓我們探討一下不應(yīng)該將哪些類型的消息放入 Kafka 的死信隊(duì)列中：
- DLQ 用于背壓處理？由于大量消息的峰值而使用 DLQ 進(jìn)行節(jié)流并不是一個(gè)好主意。Kafka 日志背后的存儲(chǔ)會(huì)自動(dòng)處理背壓。消費(fèi)者以它可以按自己的速度獲取數(shù)據(jù)的方式提取數(shù)據(jù)（或者配置錯(cuò)誤）。如果可能的話，彈性地?cái)U(kuò)展消費(fèi)者。即使您的存儲(chǔ)空間已滿，DLQ 也無濟(jì)于事。這是它的問題，與是否使用 DLQ 無關(guān)。
- 連接失敗的DLQ？由于連接失敗而將消息放入 DQL 無濟(jì)于事（即使在多次重試之后）。以下消息也無法連接到該系統(tǒng)。您需要解決連接問題。消息可以根據(jù)需要存儲(chǔ)在常規(guī)主題中（取決于保留時(shí)間）。
最后但同樣重要的是，讓我們探討在某些情況下減少甚至消除對(duì)死信隊(duì)列的需求的可能性。
卡夫卡的Schema Registry是一種確保數(shù)據(jù)清理以防止生產(chǎn)者在負(fù)載中出錯(cuò)的方法。它在 Kafka 生產(chǎn)者中強(qiáng)制執(zhí)行正確的消息結(jié)構(gòu)：
模式注冊(cè)表是模式的客戶端檢查。Confluent Server 等一些實(shí)現(xiàn)在代理端提供了額外的模式檢查，以拒絕來自未使用模式注冊(cè)表的生產(chǎn)者的無效或惡意消息。
Kafka 死信隊(duì)列的案例研究
讓我們看看Uber、CrowdStrike 和 Santander Bank 的三個(gè)案例研究，它們?cè)?Kafka 基礎(chǔ)設(shè)施中實(shí)際部署死信隊(duì)列。請(qǐng)記住，這些都是非常成熟的例子。不是每個(gè)項(xiàng)目都需要那么復(fù)雜。
Uber - 構(gòu)建可靠的再處理和死信隊(duì)列
在分布式系統(tǒng)中，重試是不可避免的。從網(wǎng)絡(luò)錯(cuò)誤到復(fù)制問題，甚至下游依賴關(guān)系的中斷，大規(guī)模運(yùn)行的服務(wù)必須準(zhǔn)備好盡可能優(yōu)雅地遇到、識(shí)別和處理故障。
鑒于 Uber 的運(yùn)營(yíng)范圍和速度，它的系統(tǒng)必須具有容錯(cuò)能力，并且在智能失敗時(shí)毫不妥協(xié)。Uber 將 Apache Kafka 用于各種極端規(guī)模的用例以實(shí)現(xiàn)這一目標(biāo)。
利用這些特性，Uber 保險(xiǎn)工程團(tuán)隊(duì)擴(kuò)展了 Kafka 在其現(xiàn)有事件驅(qū)動(dòng)架構(gòu)中的作用，通過使用 n個(gè)阻塞請(qǐng)求重新處理和死信隊(duì)列來實(shí)現(xiàn)解耦、可觀察的錯(cuò)誤處理，而不會(huì)中斷實(shí)時(shí)流量。該策略有助于他們選擇加入的駕駛員傷害保護(hù)計(jì)劃在 200 多個(gè)城市可靠運(yùn)行，并為注冊(cè)駕駛員扣除每次行程的每英里保費(fèi)。
這是 Uber 錯(cuò)誤處理的示例。錯(cuò)誤會(huì)降低重試主題的級(jí)別，直到登陸 DLQ：
有關(guān)更多信息，請(qǐng)閱讀 Uber 非常詳細(xì)的技術(shù)文章：“使用 Apache Kafka 構(gòu)建可靠的再處理和死信隊(duì)列”。
CrowdStrike - 處理數(shù)萬億事件的錯(cuò)誤
CrowdStrike 是一家位于德克薩斯州奧斯汀的網(wǎng)絡(luò)安全技術(shù)公司。它提供云工作負(fù)載和端點(diǎn)安全、威脅情報(bào)和網(wǎng)絡(luò)攻擊響應(yīng)服務(wù)。
CrowdStrike 的基礎(chǔ)設(shè)施 每天使用 Apache Kafka 處理數(shù)萬億個(gè)事件。在我的“ Apache Kaka 網(wǎng)絡(luò)安全博客系列”中，我介紹了以任何規(guī)模實(shí)時(shí)創(chuàng)建態(tài)勢(shì)感知和威脅情報(bào)的相關(guān)用例。
CrowdStrike 定義了三個(gè)最佳實(shí)踐 來成功實(shí)現(xiàn)死信隊(duì)列和錯(cuò)誤處理：
- 在正確的系統(tǒng)中存儲(chǔ)錯(cuò)誤消息：定義基礎(chǔ)設(shè)施和代碼以捕獲和檢索死信。CrowdStrike 使用 S3 對(duì)象存儲(chǔ)來存儲(chǔ)潛在的大量錯(cuò)誤消息。請(qǐng)注意，Kafka 的分層存儲(chǔ)開箱即用地解決了這個(gè)問題，無需其他存儲(chǔ)接口（例如，利用 Confluent Cloud 中的無限存儲(chǔ)）。
- 使用自動(dòng)化：放置工具以使修復(fù)萬無一失，因?yàn)槭謩?dòng)完成錯(cuò)誤處理可能非常容易出錯(cuò)。
- 記錄業(yè)務(wù)流程并聘請(qǐng)相關(guān)團(tuán)隊(duì)：標(biāo)準(zhǔn)化和記錄流程以確保易于使用。并非所有工程師都熟悉組織處理死信消息的策略。
在像 CrowdStrike 這樣的網(wǎng)絡(luò)安全平臺(tái)中，大規(guī)模實(shí)時(shí)數(shù)據(jù)處理至關(guān)重要。此要求也適用于錯(cuò)誤處理。下一次網(wǎng)絡(luò)攻擊可能是故意包含不適當(dāng)或無效內(nèi)容的惡意消息（如 JavaScript 漏洞利用）。因此，必須通過死信隊(duì)列實(shí)時(shí)處理錯(cuò)誤。
桑坦德銀行 - 用于重試和 DLQ 組合的郵箱 2.0
桑坦德銀行在郵箱應(yīng)用程序中處理海量數(shù)據(jù)的同步數(shù)據(jù)處理面臨巨大挑戰(zhàn)。他們重新架構(gòu)了他們的基礎(chǔ)架構(gòu)并構(gòu)建了一個(gè)解耦且可擴(kuò)展的架構(gòu)，稱為“Santander Mailbox 2.0”。
Santander 的工作負(fù)載并轉(zhuǎn)移到由 Apache Kafka 提供支持的事件溯源：
新的基于異步事件的架構(gòu)中的一個(gè)關(guān)鍵挑戰(zhàn)是錯(cuò)誤處理。 Santander 使用重試和 DQL Kafka 主題構(gòu)建的錯(cuò)誤處理解決了這些問題：
查看來自 Santander 的集成合作伙伴 Consdata的 Kafka 峰會(huì)演講“基于重試策略和死信主題的 Apache Kafka 中的可靠事件傳遞”中的詳細(xì)信息。
Apache Kafka 中可靠且可擴(kuò)展的錯(cuò)誤處理
錯(cuò)誤處理對(duì)于構(gòu)建可靠的數(shù)據(jù)流管道和平臺(tái)至關(guān)重要。存在不同的替代方案來解決這個(gè)問題。該解決方案包括死信隊(duì)列的自定義實(shí)現(xiàn)或利用正在使用的框架，例如 Kafka Streams、Kafka Connect、Spring 框架或 Kafka 的并行消費(fèi)者。
優(yōu)步、CrowdStrike 和桑坦德銀行的案例研究表明，錯(cuò)誤處理并不總是很容易實(shí)現(xiàn)。當(dāng)您設(shè)計(jì)新的應(yīng)用程序或架構(gòu)時(shí)，需要從一開始就考慮到這一點(diǎn)。使用 Apache Kafka 進(jìn)行實(shí)時(shí)數(shù)據(jù)流傳輸很有吸引力，但只有在您能夠處理意外行為時(shí)才能成功。死信隊(duì)列是許多場(chǎng)景的絕佳選擇。
