建站
咨詢
售后
建站咨詢
新聞中心
隨著科技的不斷發(fā)展，各種復雜的數(shù)據(jù)集成、傳輸問題也層出不窮。為了解決這些問題，我們需要能夠處理大量數(shù)據(jù)的技術和工具。在這些工具中，Kafka就是非常有用的一種。Kafka是一個高性能的消息隊列系統(tǒng)，它可以幫助我們實現(xiàn)分布式的、高吞吐量的數(shù)據(jù)傳輸，通過Kafka配合數(shù)據(jù)庫使用，可以提供一種完美的數(shù)據(jù)傳輸解決方案。
Kafka的特點是高性能的、可伸縮的，這是它適合處理大規(guī)模數(shù)據(jù)集成和傳輸?shù)闹饕颉１M管大部分情況下Kafka用于支持實時數(shù)據(jù)流的處理，但是通過Kafka可以設計用于許多其他方面的解決方案，包括處理和傳輸數(shù)據(jù)到數(shù)據(jù)庫。通常，Kafka作為一個獨立的數(shù)據(jù)總線/數(shù)據(jù)傳輸平臺被實現(xiàn)，用于將異構系統(tǒng)中的數(shù)據(jù)集成在一起。而一個常見的使用場景是，將生產(chǎn)系統(tǒng)上的數(shù)據(jù)實時導入到數(shù)據(jù)庫中。
具體來說，當我們想要將數(shù)據(jù)從一個系統(tǒng)傳輸?shù)搅硪粋€系統(tǒng)時，我們需要考慮如何實現(xiàn)高可用性、可擴展性、可靠性和高速度等方面的需求。考慮到這些方面的解決方案，Kafka的優(yōu)勢體現(xiàn)了出來。通過將Kafka與數(shù)據(jù)庫的結合使用，我們可以實現(xiàn)高效的數(shù)據(jù)傳輸，同時確保數(shù)據(jù)的完整性和可靠性。
Kafka可以將源數(shù)據(jù)按照一定的規(guī)則分隔成多個分區(qū)，并且可以存儲一段時間之內(nèi)的所有數(shù)據(jù)，以便消費者能夠隨時拉取請求。消費者可以隨時從Kafka中讀取數(shù)據(jù)，從而實現(xiàn)快速的數(shù)據(jù)傳輸。當涉及到高速數(shù)據(jù)傳輸時，Kafka主要使用兩種數(shù)據(jù)傳輸機制控制流：發(fā)布/訂閱模型和請求/響應模型。在發(fā)布/訂閱模型中，數(shù)據(jù)生產(chǎn)者在將數(shù)據(jù)推送到特定的主題中，而數(shù)據(jù)消費者從主題中訂閱數(shù)據(jù)。而在請求/響應模型中，數(shù)據(jù)的請求者會通過Kafka向數(shù)據(jù)生產(chǎn)者請求數(shù)據(jù)，隨后數(shù)據(jù)生產(chǎn)者會響應該請求并將數(shù)據(jù)發(fā)送回請求者。
同時，Kafka還具有可擴展性的優(yōu)勢，在大規(guī)模數(shù)據(jù)傳輸場景下，Kafka可以輕松地擴容以應對用戶需求。通過添加更多的傳輸通道，并在單個數(shù)據(jù)中心或多個數(shù)據(jù)中心之間分離分區(qū)，Kafka可以在總線的安全和高可用性方面有所提高。
為了保證數(shù)據(jù)的一致性和完整性，我們需要使用數(shù)據(jù)庫來持久化數(shù)據(jù)。當數(shù)據(jù)從Kafka傳輸?shù)綌?shù)據(jù)庫時，我們需要避免數(shù)據(jù)傳輸中出現(xiàn)的任何數(shù)據(jù)損失或錯誤。為了保證數(shù)據(jù)的可靠傳遞，可以使用Kafka的消息確認機制，以確保數(shù)據(jù)已經(jīng)成功地傳輸。同時，將數(shù)據(jù)存儲到數(shù)據(jù)庫中之前需要確保數(shù)據(jù)的正確性。這可以通過使用數(shù)據(jù)有效性檢查和數(shù)據(jù)加密等技術來實現(xiàn)。
在高速數(shù)據(jù)傳輸場景下，Kafka和數(shù)據(jù)庫的結合是保證數(shù)據(jù)一致性和完整性的更佳解決方案之一。通過使用Kafka，我們可以設計一個完美的數(shù)據(jù)傳輸平臺，使任何類型的數(shù)據(jù)在不同系統(tǒng)之間進行傳輸?shù)玫礁咝幚砗蛡鬏?。此外，Kafka還可以用于其他方面的數(shù)據(jù)處理，如數(shù)據(jù)分析和機器學習等。因此，Kafka是一種非常有用且強大的數(shù)據(jù)傳輸、處理工具，它在大數(shù)據(jù)領域中發(fā)揮著重要的作用。
成都網(wǎng)站建設公司-創(chuàng)新互聯(lián)為您提供網(wǎng)站建設、網(wǎng)站制作、網(wǎng)頁設計及定制高端網(wǎng)站建設服務！
Kafka的重復、丟數(shù)據(jù)及順序消費等問題
①、kafka的順序消息僅僅是通過partitionKey，將叢芹某類消息寫入橡鄭運同一個partition，一個partition只能對應一個消費線程，以保證數(shù)據(jù)有序。
②、除了發(fā)送消息需要指定partitionKey外，producer和consumer實例化無區(qū)別。
③、kafka broker宕機，kafka會有自選擇，所以宕機不會減少partition數(shù)量，也就不會影響partitionKey的sharding。
acks設置為0：broker接收消息立即返回，還沒寫入磁盤，容易丟失數(shù)據(jù)
acks設置為1：等待broker的ack，如果leader落盤了就返回ack，如果follower同步完成前l(fā)eader掛了就會丟失未同步的數(shù)據(jù)（follower選舉）
acks設置為-1：等待所有l(wèi)eader和follower都落盤后返回ack，如果follower已同步，但是broker返回ack前l(fā)eader掛了，則會重復發(fā)送消息。
consumer自動提交offset，但其實未處理好消息，容易丟數(shù)據(jù)。可以選擇手動提交，處理完后再提交offset
0.9版本的kafka改進了coordinator的設計，提出了group coordinator——每個consumer group都會被分配一個這樣的coordinator用于組管理和位移管理。這個group coordinator比原來承擔了更多的責任，比如組成員管理、位移提交保護機制等。當新版本consumer group的之一個consumer啟動的時候，它會去和kafka server確定誰是它們組的coordinator。之后該group內(nèi)的所有成員都會和該coordinator進行協(xié)調(diào)通信。顯而易見，這種coordinator設計不再需要zookeeper了，性能上可以得到很大的提升。
每個 Group 都會選擇一個 Coordinator 來完成自己組內(nèi)各 Partition 的 Offset 信息，選擇的規(guī)則如下： 1. 計算 Group 對應在 __consumer_offsets 上的 Partition 2. 根據(jù)對應的Partition尋找該Partition的leader所對應的Broker，該Broker上的Group Coordinator即就是該Group的Coordinator
numPartitionsPerConsumer=counsumer/partitions——》5/3=1，每個消費者至少被分配一個partition
consumersWithExtraPartition=counsumer%partitions——》5%3=2
i=0,start=0,length=2;
i=1,start=2,length=2;
i=2,start=4,length=1;
如果是4個partitions和3個consumer
i=0,start=0,length=2;
i=1,start=2,length=1;
i=2,start=3,length=1;
for(每一個TopicPartition)
? 以RoundRobin的方式選擇一個訂閱了這個Topic的Consumer，將這個TopicPartition分派給這個梁梁Consumer end
“sticky”這個單詞可以翻譯為“粘性的”，Kafka從0.11.x版本開始引入這種分配策略，它主要有兩個目的：
為什么會重復消費：之一種可能是生產(chǎn)者重復發(fā)送消息。第二種可能是消費者手動提交時掛掉了，導致消費了數(shù)據(jù)但是沒有提交offset。
為什么會丟失數(shù)據(jù)：之一種可能是ack非-1的情況下，follower未同步完全，leader掛了。第二種可能是消費者自動提交，但其實還沒完成消費。
怎么保證生產(chǎn)者消息不重復，0.11后，生產(chǎn)者會生成pid，和一個sequence number，通過pid sequence number brokerid作為key，如果在partition中已經(jīng)存在，則只持久化一條。且Producer重啟可以通過TransactionID拿到原來的pid，所以可以跨會話的保持一致
保證順序消費：需要保證順序的消息發(fā)到同一個partition中，consumer會自己根據(jù)順序消費
0.9.0.0 版本之前判斷副本之間是否同步，主要是靠參數(shù) replica.lag.max.messages 決定的，即允許 follower 副本落后 leader 副本的消息數(shù)量，超過這個數(shù)量后，follower 會被踢出 ISR。
replica.lag.max.messages 也很難在生產(chǎn)上給出一個合理值，如果給的小，會導致 follower 頻繁被踢出 ISR，如果給的大，broker 發(fā)生宕機導致 leader 變更時，肯能會發(fā)生日志截斷，導致消息嚴重丟失的問題。
在 0.9.0.0 版本之后，Kafka 給出了一個更好的解決方案，去除了 replica.lag.max.messages，，用 replica.lag.time.max.ms 參數(shù)來代替，該參數(shù)的意思指的是允許 follower 副本不同步消息的更大時間值，即只要在 replica.lag.time.max.ms 時間內(nèi) follower 有同步消息，即認為該 follower 處于 ISR 中，這就很好地避免了在某個瞬間生產(chǎn)者一下子發(fā)送大量消息到 leader 副本導致該分區(qū) ISR 頻繁收縮與擴張的問題了。
Kafka集群中多個broker，有一個會被選舉為controller leader，負責管理整個集群中分區(qū)和副本的狀態(tài)，比如partition的leader 副本故障，由controller 負責為該partition重新選舉新的leader 副本；當檢測到ISR列表發(fā)生變化，有controller通知集群中所有broker更新其MetadataCache信息；或者增加某個topic分區(qū)的時候也會由controller管理分區(qū)的重新分配工作
實際上，Broker 在啟動時，會嘗試去 ZooKeeper 中創(chuàng)建 /controller 節(jié)點。Kafka 當前選舉控制器的規(guī)則是：之一個成功創(chuàng)建 /controller 節(jié)點的 Broker 會被指定為控制器。
故障轉移
?當 Broker 0 宕機后，ZooKeeper 通過 Watch 機制感知到并刪除了 /controller 臨時節(jié)點。之后，所有存活的 Broker 開始競選新的控制器身份。Broker 3 最終贏得了選舉，成功地在 ZooKeeper 上重建了 /controller 節(jié)點。之后，Broker 3 會從 ZooKeeper 中讀取集群元數(shù)據(jù)信息，并初始化到自己的緩存中。
kafka發(fā)生數(shù)據(jù)庫的介紹就聊到這里吧，感謝你花時間閱讀本站內(nèi)容，更多關于kafka發(fā)生數(shù)據(jù)庫,Kafka與數(shù)據(jù)庫的結合：數(shù)據(jù)傳輸?shù)耐昝澜鉀Q方案,Kafka的重復、丟數(shù)據(jù)及順序消費等問題的信息別忘了在本站進行查找喔。
香港云服務器機房,創(chuàng)新互聯(lián)（www.cdcxhl.com）專業(yè)云服務器廠商,回大陸優(yōu)化帶寬,安全/穩(wěn)定/低延遲.創(chuàng)新互聯(lián)助力企業(yè)出海業(yè)務,提供一站式解決方案。香港服務器-免備案低延遲-雙向CN2+BGP極速互訪！
分享標題：Kafka與數(shù)據(jù)庫的結合：數(shù)據(jù)傳輸?shù)耐昝澜鉀Q方案(kafka發(fā)生數(shù)據(jù)庫)
轉載來源：http://www.5511xx.com/article/cdhpjei.html
