最佳实践就是分享一下平时遇到的一些好案例，或者从前面的原理导出的一些结论。首先，最重要的就是选择正确的数据类型，主要以满足业务，性能和场景为优先考量。一般数据量不大的业务，没必要花很大的精力；但是对一些主要业务，就需要做比较细致的优化。如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