最佳實(shí)踐就是分享一下平時(shí)遇到的一些好案例，或者從前面的原理導(dǎo)出的一些結(jié)論。首先，最重要的就是選擇正確的數(shù)據(jù)類型，主要以滿足業(yè)務(wù)，性能和場景為優(yōu)先考量。一般數(shù)據(jù)量不大的業(yè)務(wù)，沒必要花很大的精力；但是對一些主要業(yè)務(wù)，就需要做比較細(xì)致的優(yōu)化。如STRING類型對象可以考慮使用整數(shù)，如果是浮點(diǎn)型，就改成整數(shù)，Id等的值可以考慮用整數(shù)而不是字符串，小整數(shù)多的時(shí)候考慮使用LRU無關(guān)逐出策略等。對于數(shù)據(jù)量大，比較重要，需要做深入優(yōu)化業(yè)務(wù)，還可以充分利用壓縮列表，平均來說有5倍的壓縮比。

這里舉個(gè)官網(wǎng)上的例子，在存Key - Value的時(shí)候，以object后面加一個(gè)整數(shù)作為ID，整個(gè)數(shù)據(jù)庫里可能都是這種類型的數(shù)據(jù)，量又特別大，想對它優(yōu)化的時(shí)候，比較通用的優(yōu)化方法就是取模，相同前綴的Key單獨(dú)做hash。整個(gè)db空間相當(dāng)于一個(gè)大的哈希表，這樣就把本來分配給整個(gè)db空間的Key，按照不同的前綴分成小的哈希表，每個(gè)哈希表里面保證數(shù)據(jù)比較小，那這個(gè)哈希表就會用壓縮列表來保存。

Redis里其實(shí)有7種數(shù)據(jù)類型，另外2種是普通的String，獨(dú)立出來用于特定場合，它是效率非常高且有用的一種方式。

第一個(gè)是位圖Bitmap，它存儲起來實(shí)際上就是字符串，最大可以是512M，當(dāng)用一些讀寫的位操作函數(shù)操作時(shí)，位操作很快。其原理是，若統(tǒng)計(jì)一個(gè)網(wǎng)站的UV，用來訪問的用戶的ID做標(biāo)識。其好處是節(jié)省空間。如果按傳統(tǒng)的集合方式實(shí)現(xiàn)，則內(nèi)存占用大，且難以合并。如果每天的用戶訪問都做了集合，那么統(tǒng)計(jì)一周內(nèi)的訪問，做集合的并集操作，比較占時(shí)間。而用bitmap只需將每天的字符串按位與，計(jì)算較快。比如要統(tǒng)計(jì)用戶每天有沒有訪問網(wǎng)站，1000萬個(gè)用戶實(shí)際上只需要430M，用集合會很大。若統(tǒng)計(jì)UV，一億兩千八百萬用戶做位操作基本上也是幾百毫秒。 Bitmap需要注意的問題是，字符串的最大長度是用戶的ID指定，用戶的ID是多少，就把bitmap的相應(yīng)位設(shè)為1，因此如果ID取的很大，而用戶量很少，Bitmap很稀疏的話，相比集合并不能體現(xiàn)其優(yōu)勢。而且大的bit位一次分配會導(dǎo)致setbit時(shí)間過長。那么，需要合理的進(jìn)行bit位的壓縮，可以用相對值不用絕對值，按位分開成多個(gè)Bitmap，每10000個(gè)用戶單獨(dú)用一個(gè)bitmap，存相對值；再或者用哈希函數(shù)映射成定長的ID如64位等。

第二是HyperLogLog，它是一個(gè)算法，和日志沒關(guān)系，用于計(jì)數(shù)統(tǒng)計(jì)，操作很快，最大空間占用12K，可以記2^64個(gè)數(shù)據(jù)，誤差只有0.81%。也就是說，要追求準(zhǔn)確，就用Bitmap，但是有些業(yè)務(wù)允許有一些誤差，可以使用HyperLogLog。HyperLogLog就是用來統(tǒng)計(jì)位有沒有記成1，不管IP是多少，只要12K 的內(nèi)存就夠了。如果用集合，一百萬個(gè)IP，64字節(jié)，一年的數(shù)據(jù)可能就要5.4G，1億個(gè)IP，一年就要540G，HyperLogLog只要4M就可以。

原地址：https://mp.weixin.qq.com/s/n4HXKXPKf87qgZ_e6s4gPg