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