Redis高级数据结构

1.Redis五大基础数据结构

Redis的五大基础数据结构没啥好说的。

Object]&name=image.png&originHeight=780&originWidth=733&originalType=binary&ratio=1&rotation=0&showTitle=false&size=79065&status=done&style=none&taskId=uc4f5cf3b-0459-45f5-818f-87a6d7d308b&title=&width=733)

2.Redis三个高级数据结构

2.1 Bitmaps位图

现代计算机用二进制位作为信息的基础单位，1字节=8位，比如在ASCLL码下字符“a”对应97，对应二进制位就是0110 0001，许多开发语言都提供了操作位的功能，合理地使用位能够提高内存使用率和效率。抖音、快手等数亿流量的APP他们的日活、月活、留存、漏斗分析等如何做到秒级响应，这其中就有BitMap技术的支持。
Bitmaps本身不是一种新的基础数据结构，实际上底层它就是String，但它支持对bit进行操作；可以把Bitmaps想象成以bit为单位的数组，数组的每个单元只能存储0或1，数组的下标在Bitmaps中叫做偏移量(offset)。因为Redis底层是由C语言编写，C语言中的字符串并非二进制安全，所以Redis的字符串和C中的字符串不一样，而是采用名叫SDS的结构实现，所以Redis中字符串的最大长度是512MB,所以Bitmaps的偏移量最大2^32。
比如需要知道后端打卡记录如果采用传统记录方式则记录为：
int[ ] record = {0,3,6,7}
那么总共占用的空间就是4*4byte = 16byte， 如果采用Bitmaps，则可以用一个offset=8的bit数组表示：

那么使用Bitmaps所使用的空间大小只有1个字节。假设网站有1亿用户，每天独立访问的用户有5千万，如果每天用集合类型和Bitmaps 分别存储活跃用户，很明显，假如用户 id 是 Long 型，64 位，则集合 类型占据的空间为 64 位 x50 000 000= 400MB，而 Bitmaps 则需要 1 bit×100 000 000=12.5MB，可见 Bitmaps 能节省很多的内存空间。

2.2 HyperLogLog

HyperLogLog 也不是一种新的数据结构，底层也是由String类型实现，但是它是一种基数算法，它可以利用极小的内存空间完成独立总数的统计。HyperLogLog 基于概率论中伯努利试验并结合了极大似然估算方法，并做了分桶优化。 如果你的页面访问量非常大，比如一个爆款页面几千万的 UV，你需 要一个很大的 set 集合来统计，这就非常浪费空间。如果这样的页面很多，那 所需要的存储空间是惊人的。为这样一个去重功能就耗费这样多的存储空间，值 得么？其实需要的数据又不需要太精确，105w 和 106w 这两个数字对于老板们 来说并没有多大区别，So，有没有更好的解决方案呢？ 这就是HyperLogLog的用武之地，Redis 提供了 HyperLogLog 数据结构就是 用来解决这种统计问题的。HyperLogLog 提供不精确的去重计数方案，虽然不精 确但是也不是非常不精确，Redis 官方给出标准误差是 0.81%，这样的精确度已经 可以满足上面的 UV 统计需求了。
基数算法：是指一个集合中不重复元素的个数。LogLog Counting（以下简称LLC）出自论文“Loglog Counting of Large Cardinalities”。LLC的空间复杂度仅有[公式]，使得通过KB级内存估计数亿级别的基数成为可能，因此目前在处理大数据的基数计算问题时，所采用算法基本为LLC。

2.3 GEO

Redis 3.2版本提供了GEO(地理信息定位)功能，支持存储地理位置信息用来 实现诸如附近位置、摇一摇这类依赖于地理位置信息的功能。 地图元素的位置数据使用二维的经纬度表示，经度范围 (-180, 180]，纬度范围 (-90, 90]，纬度正负以赤道为界，北正南负，经度正负以本初子午线 (英国格林尼治 天文台) 为界，东正西负。 业界比较通用的地理位置距离排序算法是 GeoHash 算法，Redis也使用GeoHash 算法。GeoHash 算法将二维的经纬度数据映射到一维的整数，这样所有的 元素都将在挂载到一条线上，距离靠近的二维坐标映射到一维后的点之间距离也会很接近。当我们想要计算「附近的人时」，首先将目标位置映射到这条线上，然后在这个一维的线上获取附近的点就行了。 在Redis里面，经纬度使用 52 位的整数进行编码，放进了 zset 里面，zset 的 value是元素的