Redis高级数据类型

GEO

这个功能可以将用户给定的地理位置信息储存起来， 并对这些信息进行操作。

使用场景

来实现诸如附近位置、摇一摇这类依赖于地理位置信息的功能。geo的数据类型为zset。

常用命令

GEOADD Sicily 13。361389 38。115556 "Palermo" 15。087269 37。502669 "Catania" #添加地理位置的坐标。
GEOPOS Sicily Palermo Catania  #获取地理位置的坐标。
GEODIST Sicily Palermo Catania km  #计算两个位置之间的距离。
GEORADIUS Sicily 15 37 200 km WITHDIST WITHCOORD #根据用户给定的经纬度坐标来获取指定范围内的地理位置集合。
GEORADIUSBYMEMBER Sicily Agrigento 100 km #根据储存在位置集合里面的某个地点获取指定范围内的地理位置集合。
GEOHASH Sicily Palermo Catania #返回一个或多个位置对象的 geohash 值。

HyperLogLog

HyperLogLog是用来做基数统计的算法，它提供了不精确的去重计数方案。

HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的，并且是很小的。在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 264 个不同元素的基数，这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。

使用场景

假如我要统计网页的UV（浏览用户数量，一天内同一个用户多次访问只能算一次），传统的解决方案是使用Set来保存用户id，然后统计Set中的元素数量来获取页面UV。但这种方案只能承载少量用户，一旦用户数量大起来就需要消耗大量的空间来存储用户id。我的目的是统计用户数量而不是保存用户，这简直是个吃力不讨好的方案！而使用Redis的HyperLogLog最多需要12k就可以统计大量的用户数，尽管它大概有0。81%的错误率，但对于统计UV这种不需要很精确的数据是可以忽略不计的。

常用命令

PFADD key element [element 。。。]  #添加指定元素到 HyperLogLog 中。
PFCOUNT key [key 。。。]  #返回给定 HyperLogLog 的基数估算值。
PFMERGE destkey sourcekey [sourcekey 。。。] #将多个 HyperLogLog 合并为一个 HyperLogLog

BitMap

BitMap通过一个bit位来表示某个元素对应的值或者状态，其中的key就是对应元素本身。我们知道8个bit可以组成一个Byte，所以bitmap本身会极大的节省储存空间。

使用场景

在开发中，可能会遇到这种情况：需要统计用户的某些信息，如活跃或不活跃，登录或者不登录；又如需要记录用户一年的打卡情况，打卡了是1， 没有打卡是0，如果使用普通的 key/value存储，则要记录365条记录，如果用户量很大，需要的空间也会很大，所以 Redis 提供了 Bitmap 位图这中数据结构，Bitmap 就是通过操作二进制位来进行记录，即为 0 和 1；如果要记录 365 天的打卡情况，使用 Bitma表示的形式大概如下：0101000111000111………………………，这样有什么好处呢？当然就是节约内存了，365 天相当于 365 bit，又 1 字节 = 8 bit ， 所以相当于使用 46 个字节即可。

常用命令

SETBIT key offset value #设置或者清空key的value(字符串)在offset(偏移量)处的bit值(只能只0或者1)。
GETBIT key offset #获取offset设置的值，未设置过默认返回0
BITCOUNT key [start end]   #统计指定key位置为1的数量（区间统计不建议使用，bitcount用的是byte来计算位数，其他setbit和getbit用的是bit）
BITOP operation(AND/OR/XOR/NOT) destkey key [key 。。。] # Bit运算，BITOP 支持四种表达式运算： AND（交集）， OR（并集）， XOR（异或）
BITPOS key bit [start] [end] #返回设置为1或0的一个字符串中的第一个点的位置