《p》Kafka將數(shù)據(jù)持久化到了硬盤上，允許你配置一定的策略對數(shù)據(jù)清理，清理的策略有兩個，刪除和壓縮。 《br》 數(shù)據(jù)清理的方式 《br》 刪除 《br》 log.cleanup.policy=delete啟用刪除策略 《br》 直接刪除，刪除后的消息不可恢復(fù)?？膳渲靡韵聝蓚€策略： 《br》 清理超過指定時間清理： 《br》 log.retention.hours=16 《br》 超過指定大小后，刪除舊的消息： 《br》 log.retention.bytes=1073741824 《br》 為了避免在刪除時阻塞讀操作，采用了copy-on-write形式的實現(xiàn)，刪除操作進(jìn)行時，讀取操作的二分查找功能實際是在一個靜態(tài)的快照副本上進(jìn)行的，這類似于Java的CopyOnWriteArrayList。 《br》 壓縮 《br》 將數(shù)據(jù)壓縮，只保留每個key最后一個版本的數(shù)據(jù)。 《br》 首先在broker的配置中設(shè)置log.cleaner.enable=true啟用cleaner，這個默認(rèn)是關(guān)閉的。 《br》 在topic的配置中設(shè)置log.cleanup.policy=compact啟用壓縮策略。 《br》 壓縮策略的細(xì)節(jié)《/p》《p》如上圖，在整個數(shù)據(jù)流中，每個Key都有可能出現(xiàn)多次，壓縮時將根據(jù)Key將消息聚合，只保留最后一次出現(xiàn)時的數(shù)據(jù)。這樣，無論什么時候消費消息，都能拿到每個Key的最新版本的數(shù)據(jù)。 《br》 壓縮后的offset可能是不連續(xù)的，比如上圖中沒有5和7，因為這些offset的消息被merge了，當(dāng)從這些offset消費消息時，將會拿到比這個offset大的offset對應(yīng)的消息，比如，當(dāng)試圖獲取offset為5的消息時，實際上會拿到offset為6的消息，并從這個位置開始消費。 《br》 這種策略只適合特俗場景，比如消息的key是用戶ID，消息體是用戶的資料，通過這種壓縮策略，整個消息集里就保存了所有用戶最新的資料。 《br》 壓縮策略支持刪除，當(dāng)某個Key的最新版本的消息沒有內(nèi)容時，這個Key將被刪除，這也符合以上邏輯

　　Kafka定時清除過期數(shù)據(jù)2017-09-04 14:04《p》Kafka將數(shù)據(jù)持久化到了硬盤上，允許你配置一定的策略對數(shù)據(jù)清理，清理的策略有兩個，刪除和壓縮。 《br》 數(shù)據(jù)清理的方式 《br》 刪除 《br》 log.cleanup.policy=delete啟用刪除策略 《br》 直接刪除，刪除后的消息不可恢復(fù)?？膳渲靡韵聝蓚€策略： 《br》 清理超過指定時間清理： 《br》 log.retention.hours=16 《br》 超過指定大小后，刪除舊的消息： 《br》 log.retention.bytes=1073741824 《br》 為了避免在刪除時阻塞讀操作，采用了copy-on-write形式的實現(xiàn)，刪除操作進(jìn)行時，讀取操作的二分查找功能實際是在一個靜態(tài)的快照副本上進(jìn)行的，這類似于Java的CopyOnWriteArrayList。 《br》 壓縮 《br》 將數(shù)據(jù)壓縮，只保留每個key最后一個版本的數(shù)據(jù)。 《br》 首先在broker的配置中設(shè)置log.cleaner.enable=true啟用cleaner，這個默認(rèn)是關(guān)閉的。 《br》 在topic的配置中設(shè)置log.cleanup.policy=compact啟用壓縮策略。 《br》 壓縮策略的細(xì)節(jié)《/p》《p》如上圖，在整個數(shù)據(jù)流中，每個Key都有可能出現(xiàn)多次，壓縮時將根據(jù)Key將消息聚合，只保留最后一次出現(xiàn)時的數(shù)據(jù)。這樣，無論什么時候消費消息，都能拿到每個Key的最新版本的數(shù)據(jù)。 《br》 壓縮后的offset可能是不連續(xù)的，比如上圖中沒有5和7，因為這些offset的消息被merge了，當(dāng)從這些offset消費消息時，將會拿到比這個offset大的offset對應(yīng)的消息，比如，當(dāng)試圖獲取offset為5的消息時，實際上會拿到offset為6的消息，并從這個位置開始消費。 《br》 這種策略只適合特俗場景，比如消息的key是用戶ID，消息體是用戶的資料，通過這種壓縮策略，整個消息集里就保存了所有用戶最新的資料。 《br》 壓縮策略支持刪除，當(dāng)某個Key的最新版本的消息沒有內(nèi)容時，這個Key將被刪除，這也符合以上邏輯

相關(guān)電子資料下載

• kafka相關(guān)命令詳解 81
• Kafka架構(gòu)技術(shù)：Kafka的架構(gòu)和客戶端API設(shè)計 80
• Spring Kafka的各種用法 91
• kafka client在 spring如何實現(xiàn) 104
• 降本增效：Grab如何在云上將Kafka消費者流量成本降到零 214
• 監(jiān)控Kafka集群的常用的方法和工具介紹 167
• 從Kafka中學(xué)習(xí)高性能系統(tǒng)如何設(shè)計 211
• 物通博聯(lián)WG783-5G-kafka（帶kafka協(xié)議開發(fā)調(diào)試）系列工業(yè)智能網(wǎng)關(guān) 134
• 物通博聯(lián)5G-kafka工業(yè)智能網(wǎng)關(guān)輕松實現(xiàn)數(shù)據(jù)采集kafka上云 155
• 物通博聯(lián)5G-kafka工業(yè)網(wǎng)關(guān)實現(xiàn)kafka協(xié)議對接到云平臺 132