一、消息隊列應用場景
應用場景：應用解耦、異步消息、流量削峰等問題，實現高性能、高可用、可伸縮和最終一致性架構。
Kafka是由LinkedIn開發的一個分佈式的消息系統，可獨立部署在單臺服務器上，也可部署在多臺服務器上構成集群。它提供了發佈與訂閱功能。用戶可以發送數據到Kafka集群中，也可以從Kafka集群中讀取數據。Kafka使用Scala編寫，它以可水平擴展和高吞吐率而被廣泛使用。
目前越來越多的開源分佈式處理系統如Storm，Spark，Flink都支持與Kafka集成。現在我們的數據實時處理平臺也使用到了kafka。現在它已被多家不同類型的公司作為多種類型的數據管道和消息系統使用。
訪問Kafka技術專欄，瞭解更多的技術細節和項目代碼。
專欄
Kafka v2.3 快速入門與實踐
39.8幣
54人已購
二、Kafka消息的順序性
在 Kafka 中，我們可以通過發送帶有鍵的消息來實現這一目的。使用相同鍵發送的事件或消息都能保證正確的順序，因為它們被髮送到了相同的分區。
三、Kafka消息的消費者
我們使用 Spring Boot 來實現微服務，這些服務從 Kafka 主題讀取數據。Spring Boot 提供了很棒的內置 Kafka 消費者，可以無縫消費，並提供了簡便的註解（annotation），用於消費和反序列化數據。
除了專有的微服務消費者外，我們還有 CDC變更數據捕獲工具，將數據索引到多種存儲中，以便進行進一步的分析。其中包括用於關鍵字搜索的 Elasticsearch、用於審記的 Apache Hive，以及用於進一步下游處理的 Kafka。這些數據的內容可以直接來自 Kafka 消息，並使用 ID 字段作為主鍵，根據 TYPE 字段進行 CRUD 操作。
訪問Spring Cloud Alibaba技術專欄，瞭解更多的技術細節和項目代碼。
專欄
Spring Cloud微服務架構項目實戰
33.9幣
44人已購
四、消息傳遞保證
在分佈式系統中，保證一次僅一次消息傳遞並不是一件容易的事情，因為涉及的組件太多，太過複雜。消費者行為應該具有冪等性，以應對任何潛在的基礎設施和生產者故障。
但即使應用程序是冪等的，也不應該為已處理過的消息進行重複繁重的計算。為了做到這一點，一種流行方法是通過分佈式緩存（如Redis）來跟蹤消息的 UUID，只要在到期時間間隔內遇到相同的 UUID，就不進行重複處理。
Flink 在內部使用 RocksDB 實現狀態管理，使用鍵作為消息的 UUID，以此來實現只處理一次。如果你只想使用 Kafka，Kafka Streams 也提供了一種方法。基於 Spring Boot 的應用程序可以使用 Redis或EVCache 。
專欄
SkyWalking分佈式鏈路追蹤和監控
19.8幣
54人已購
