最佳實踐就是分享一下平時遇到的一些好案例，或者從前面的原理導出的一些結論。首先，最重要的就是選擇正確的數據類型，主要以滿足業務，性能和場景為優先考量。一般數據量不大的業務，沒必要花很大的精力；但是對一些主要業務，就需要做比較細致的優化。如STRING類型對象可以考慮使用整數，如果是浮點型，就改成整數，Id等的值可以考慮用整數而不是字符串，小整數多的時候考慮使用LRU無關逐出策略等。對于數據量大，比較重要，需要做深入優化業務，還可以充分利用壓縮列表，平均來說有5倍的壓縮比。
這里舉個官網上的例子，在存Key - Value的時候，以object后面加一個整數作為ID，整個數據庫里可能都是這種類型的數據，量又特別大，想對它優化的時候，比較通用的優化方法就是取模，相同前綴的Key單獨做hash。整個db空間相當于一個大的哈希表，這樣就把本來分配給整個db空間的Key，按照不同的前綴分成小的哈希表，每個哈希表里面保證數據比較小，那這個哈希表就會用壓縮列表來保存。
Redis里其實有7種數據類型，另外2種是普通的String，獨立出來用于特定場合，它是效率非常高且有用的一種方式。
第一個是位圖Bitmap，它存儲起來實際上就是字符串，最大可以是512M，當用一些讀寫的位操作函數操作時，位操作很快。其原理是，若統計一個網站的UV，用來訪問的用戶的ID做標識。其好處是節省空間。如果按傳統的集合方式實現，則內存占用大，且難以合并。如果每天的用戶訪問都做了集合，那么統計一周內的訪問，做集合的并集操作，比較占時間。而用bitmap只需將每天的字符串按位與，計算較快。比如要統計用戶每天有沒有訪問網站，1000萬個用戶實際上只需要430M，用集合會很大。若統計UV，一億兩千八百萬用戶做位操作基本上也是幾百毫秒。 Bitmap需要注意的問題是，字符串的最大長度是用戶的ID指定，用戶的ID是多少，就把bitmap的相應位設為1，因此如果ID取的很大，而用戶量很少，Bitmap很稀疏的話，相比集合并不能體現其優勢。而且大的bit位一次分配會導致setbit時間過長。那么，需要合理的進行bit位的壓縮，可以用相對值不用絕對值，按位分開成多個Bitmap，每10000個用戶單獨用一個bitmap，存相對值；再或者用哈希函數映射成定長的ID如64位等。
第二是HyperLogLog，它是一個算法，和日志沒關系，用于計數統計，操作很快，最大空間占用12K，可以記2^64個數據，誤差只有0.81%。也就是說，要追求準確，就用Bitmap，但是有些業務允許有一些誤差，可以使用HyperLogLog。HyperLogLog就是用來統計位有沒有記成1，不管IP是多少，只要12K 的內存就夠了。如果用集合，一百萬個IP，64字節，一年的數據可能就要5.4G，1億個IP，一年就要540G，HyperLogLog只要4M就可以。
原地址：https://mp.weixin.qq.com/s/n4HXKXPKf87qgZ_e6s4gPg
