前言
对于Redis而言，很多小伙伴只关注其关键的五大基础类型：string、hash、list、set、sorted set(有序集合)，其实还有三种特殊类型在很多应用场景也比较适合使用，分别是：bitmap、geospatial、hyperloglog；上一篇(跟我一起学Redis之五种基本类型及其应用场景举例(干了6个小时))对五种类型进行分享，接下来结合应用场景来说说三种特殊类型的使用方式；
正文
geospatial(地理空间)
该类型在Redis3.2.0版本中加入，其本质是将经纬度通过geohash技术转换成一个值，使用sorted set将其存储；具体内部实现在这里不进行研究，这次主要说应用。
经度(longitude)、维度(latitude)小伙伴肯定不陌生(流泪，当初地理差的一批)：
- 有效的经度是-180度到180度；
- 有效的纬度是-85.05112878度到85.05112878度；
该类型只有六个命令，先简单介绍一下各命令的功能和关键参数：
-
GEOADD：添加地理空间位置信息，即经纬度信息；
GEOADD key 经度1 维度1 member1 [经度2 维度2 member2 ...]
-
GEODIST：获取指定位置之间的距离，默认单位为米；
GEODIST key member1 member2 [单位]
单位可以指定，如下几种：
m：指定单位为米；
km：指定单位为千米；
mi：指定单位为英里；
ft：指定单位为英尺；
-
GEOHASH：返回11个字符的Geohash字符串，字符串越相似，位置越接近；一般底层调试使用的比较多。
GEOHASH key member1 [member2 ...]
-
GEOPOS：返回指定一个或多个位置元素的位置信息，即经纬度信息；
GEOPOS key member1 [member2 ...]
-
GEORADIUS：以指定的经纬度为圆心，查找指定半径范围的位置元素；
GEORADIUS key 经度 维度 半径 m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count]
半径后面指定一个单位，m|km|ft|mi指定其中一个；
WITHDIST：在返回查找到位置元素， 同时对应位置元素与中心之间的距离也一并返回。
WITHCOORD：将位置元素的经度和维度也一并返回。
WITHHASH：以 52 位有符号整数的形式返回， 返回位置元素经过原始 geohash 编码的有序集合分值，即一串字符串；
COUNT：代表返回位置信息的条数，类似于分页条数；
-
GEORADIUSBYMEMBER：指定的对应位置元素为圆心，查找指定半径范围的位置元素；GEORADIUS命令是通过指定经纬度为圆心，其他使用方式一致；
GEORADIUSBYMEMBER key member 半径 m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count]
命令功能及参数说明就简单说这么多(我怕说理论)，欲知详情，请小伙伴去官网瞅瞅；
接下来结合应用场景进行命令实战，不然小伙伴要忍不住啦↓↓↓
应用场景实战1
绿色出行，小黄、小蓝、青桔、哈罗各种共享自行车应该已经是很多小伙伴们出行必用了吧，来，先截个哈罗的图看看：
图中显示定位附近的小车，小伙伴可以先想想，如果这个需求给自己，怎么实现？
如果用Redis，这样搞试试：
每一辆共享单车肯定有定位功能，将其定位信息(经纬度)存储到后台管理系统中，这里我们模拟定位信息存储，我们用百度地图坐标拾取器可以取得地图上任意一点的经纬度信息，如下图：
网页地址为：http://api.map.baidu.com/lbsapi/getpoint/index.html
模拟共享单车定位信息存储到后台Redis：
当我们打开手机时，App同样会通过手机进行定位，比如得到对应位置的经纬度信息为：113.768365(经度),34.724814(纬度)，这样就可以指定用户的定位信息为中心，去查找附近指定半径的单车，然后将其标注在地图上：
应用场景实战2
再来一个需求，比如说微信附近的人，直播APP附近直播的播友，还有某陌附近的美女，如下图：
如果用Redis实现，同样是通过APP(比如微信)将用户的定位信息保存到后台Redis中，这里还是使用百度地图拾取器的方式取得位置信息模拟将定位信息保存在Redis：
附近餐馆、附近加油站、附近酒店同样的原理，最后关于具体的信息可以通过得到信息(比如说用户ID、共享单车标识等)去存储详细信息的数据库中查询。
bitmap
bitmap在Redis2.2.0版本加入，其并不是一种实际的数据类型，而是在字符串类型基础上定义的一组面向位的操作。因为字符串是二进制安全的blob，对应value能存储的最大长度是512 MB，即可以设置2^32个不同的位；大概的结构如下：**
**
实践出真理，看看其类型到底是不是string类型：
常用命令如下：
-
SETBIT：设置指定key中指定位置(offset)的值(0 或 1)；
SETBIT key offset value
-
GETBIT：获取指定key中指定位置(offset)的值，未设置过默认返回0；
GETBIT key offset
-
BITCOUNT：统计指定key位置为1的数量,可以指定区间(这里的区间以字节(byte)为单位)；
BITCOUNT key [start end]
-
BITOP：进行位运算，支持四种表达式运算: AND(交集), OR(并集), XOR(异或)和NOT(取非)；
BITOP operation destkey key [key ...]
operation 可以指定对应的运算方式，运算的结果存入destkey中；
-
BITPOS：返回指定key中指定值的第一个位置；
BITPOS key bit [start] [end]
模拟应用场景实战：
bitmap由于存储的值只能是0或1，所以很适合两种状态的数据记录和分析，比如说是否签到，是否登录，然后通过签到记录的数据可以统计周、月、年签到数，通过登录的数据可以分析用户是否活跃；
应用场景用户签到
比如某多多连续签到送现金、运动打卡App(比如Keep)、学习打卡App或者小程序，都会有对打卡数据的统计，如下图某音极速版连续签到送积分：
如果用Redis实现，如下：
应用场景用户登录即用户活跃分析：
如下统计逻辑：
bitmap适合数据量比较大的场景，如果数据几十上千，用bitmap反而相对比较占空间，直接使用用户ID作为Key使用set存储，但是如果数据量大时，Key值所占空间比较大，比较浪费，而bitmap用512M内存就能标识40亿数据状态；当然，不介意bitmap的位数很大，设置或分析数据的时候可能会导致堵塞，所以当位数很大时，建议将其拆分为多个Key，保证分析的高效。
先休息一下，晃晃头，眨巴眨巴眼睛，然后继续往下↓↓↓
hyperloglog
先说说什么是基数？
基数（cardinal number）在数学上，是集合论中刻画任意集合大小的一个概念。两个能够建立元素间一一对应的集合称为互相对等集合。例如3个人的集合和3匹马的集合可以建立一一对应，是两个对等的集合。
百度百科
比如数据集 {1, 3, 5, 7, 5, 7, 8}， 那么这个数据集的基数集为 {1, 3, 5 ,7, 8}, 基数(不重复元素)为5。 基数估计就是在误差可接受的范围内，快速计算基数。
菜鸟教程
通俗一点就是不重复元素的个数(这是个人通俗的理解)，先到这，实战再来回顾这句话；
hyperloglog是一种概率数据统计结构，适合超大数据量的基数统计，速度快，而且空间占用小，；但是统计的结果存在低于1%的误差，如果需要的是精确统计的话，使用基础类型set进行统计也不错，但当统计元素比较多时，内存占用空间会增大，毕竟用空间换精确度嘛。
和bitmap感觉很像，都适合大数据量的统计，但是bitmap还关注统计对象，比如说谁签到多少次，而hyperloglog只进行基数统计，不关注是谁进行签到；比如常听到UV统计场景，即一个页面，一个用户访问多次，也只算一次，最后只关注这个页面被多少用户访问，而不在乎是谁访问；微信公众号文章的统计也是针对用户统计的，同一个用户不管访问几次，只算一次阅读；
常用命令：
-
PFADD：添加元素到指定HyperLogLog；
PFADD key element [element ...]
-
PFCOUNT：返回指定HyperLogLog的基数估算值；
PFCOUNT key [key ...]
如果指定多个HyperLogLog ，返回它们并集近似基数，存在低于1%的误差；
-
PFMERGE：将多个 HyperLogLog 合并为一个 HyperLogLog ；
PFMERGE destkey sourcekey [sourcekey ...]
模拟应用场景
模拟页面UV统计，即用户访问数，不注重是谁访问：
模拟App应用市场下载数，比如某音下载量都好几亿了，这个肯定不关心是谁下载吧，只关心下载数量来衡量应用参数；
总结
先到这吧，这篇总耗时又搞了几个小时，上文中应用场景模拟只是给小伙伴提供思路，小伙伴可以根据需求进行设计；下一遍说说配置文件；
一个被程序搞丑的帅小伙，关注"Code综艺圈"，识别关注跟我一起学~~~
撸文不易，莫要白瞟，三连走起~~~~