Redis特殊的三种数据类型
（为什么说他特殊呢？如果使用type 命令查看，HyperLogLog和BitMap是String类型的，Geo是zSet类型的。但是他们的语法和原本的数据类型又有所出入）
1：HyperLogLog（基数估算器）
2：BitMap（类似于java当中的map一样的数据结构，但是key仅仅可以为数字类型，value只有0，1两个值）
3：Geo（是一种基于GeoHash算法的一种zSet的数据结构。可用于附近查询，但是我个人认为该类型在技术和性能上还不建议用于生产环境）
HyperLogLog
版本支持：
Redis 在 2.8.9 版本添加了 HyperLogLog 结构。
基本概念：
Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定 的、并且是很小的。
PFADD如果存入相同的元素，则会覆盖，而不是单纯的累加。
但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。
性能：
在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基 数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。这三个操作的时间复杂度均为O(1)。
应用：
这个结构可以非常省内存的去统计各种计数，比如注册 IP 数、每日访问 IP 数、页面实时UV）、在线用户数等。但是它也有局限性，就是只能统计数量，而没办法去知道具体的内容是什么。
基本语法：
| 序号 | 命令及描述 |
|---|---|
| 1 | PFADD key element [element ...] 添加指定元素到 HyperLogLog 中。 |
| 2 | PFCOUNT key [key ...] 返回给定 HyperLogLog 的基数估算值。 |
| 3 | PFMERGE destkey sourcekey [sourcekey ...] 将多个 HyperLogLog 合并为一个 HyperLogLog |
参考：https://www.runoob.com/redis/redis-hyperloglog.html
BitMap
版本支持：
Redis 从 2.2 版本之后新增了setbit, getbit, bitcount 等几个 bitmap 相关命令。
基本概念：
BitMap 就是通过一个 bit 位来表示某个元素对应的值或者状态, 其中的 key 就是对应元素本身，实际上底层也是通过对字符串的操作来实现。
性能：
redis中bit映射被限制在512MB之内，所以最大是2^32位。建议每个key的位数都控制下，因为读取时候时间复杂度O(n)，越大的串读的时间花销越多。
应用
这个数据结构可以用来，储存用户在线状态。这里只需要一个 key，然后把用户 ID 作为 key，如果在线就设置为 1，不在线就设置为 0。
基本语法：
| 序号 | 命令及描述 |
|---|---|
| 1 | SETBIT key field value 添加指定元素到 BitMap 中。 |
| 2 | GETBIT key field 返回给定 BitMap 的field的bit值。未赋值和0值均返回0。 |
| 3 | BITCOUNT key 返回给定BitMap 所有field的bit值为1的，field总数。 |
Geo
版本支持：
Redis 的 GEO 特性在 Redis 3.2 版本中推出
基本概念：
这个功能可以将用户给定的地理位置信息储存起来， 并对这些信息进行操作。
主要针对于用户存储的地理位置信息进行，距离换算，附近的数据位置查询功能。
性能：
该数据不是作者亲自做的实验，所以不能保证数据的正确性。
| 原始数据大小 | mem | 80%cpu qps |
|---|---|---|
| 10000 | 5.5MB | 26000 |
| 100000 | 14MB | 22000 |
| 1000000 | 102MB | 10000 |
参考：https://www.codercto.com/a/89291.html
应用
可用于LBS 的附近查询功能，但是作者不推荐使用。
1：该功能仅能支持简单的附近查询，如果需求出现了，各种状态，类型的过滤。使用该功能就形同虚设了（例如查询附近1公里内的所用女性用户）
2：该功能的数据存储结构很单一，较难满足当下，互联网应用的复杂的应用需求。
（如果各位老板有该方向的需求，可以参考作者的另一篇文章，针对LBS 附近查询功能的简单实现）
（以上文章的概念，定义等。如果出现错误请各位看官指正）
