《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)，刪除操作進行時，讀取操作的二分查找功能實際是在一個靜態(tài)的快照副本上進行的，這類似于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)，刪除操作進行時，讀取操作的二分查找功能實際是在一個靜態(tài)的快照副本上進行的，這類似于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將被刪除，這也符合以上邏輯