Redis数据结构，渐进式遍历，数据库管理
1.Redis的其他数据结构
前面我们主要讲述了Redis中比较常用的集中数据结构String，List，Hash，Set，Zset，但这并不代表Redis只用这几种数据结构还有如Streams，Geospatial，Hyperloglog，Bitfields，Bitmap这样的数据结构，接下来我们对这些数据结构进行一下简单的介绍。
1.1 Streams流
用来模拟实现事件的传播机制
Streams可以理解为一个队列，redis作为消息队列的重要支撑，属于是List的blpop/brpop的升级版本，可以替代传统List实习可靠的消息系统
1.2 Geospatial地理空间索引
用来存储坐标（经纬度），基于Zset实现的地理位置存储与查询
存储一些点之后，就可以给用户顶一个坐标，去从刚才存储的点里进行查找（按找搬家，矩形区域）
这些功能在适用于“附近的人/地点搜索”，“共享单车停放热区”等与地图相关的场景
1.3 Hyperloglog基数统计
概率型数据结构，用于高效估算海量数据的唯一值数量（基数）
前面我们讲过Set有一个应用场景就是统计服务器的UV（Unique Visitor），使用Set当然可以计算UV，但最大的问题在于如果UV数据量非常大，Set就很消耗空间（假设Set中存储userId，每个userId按照8个字节，1亿UV≈0.8G，而采用Hyperloglog可以使用约12KB内存）
Hyperloglog不存储元素的内容，但是能够记录元素特征，从而在新增元素的时候，就能够知道当前新增的元素是一个已经存在的还是一个新的元素，用于计数（记录当前集合中元素的个数），但无法告诉程序员元素都是什么
Hyperloglog适用于计算UV，去重计数等场景，不适合精确计数或获取具体元素
1.4 Bitfields位域
本质上是精确进行位操作的一种方法，针对字符串进行位操作的扩展命令，支持原子性读写
位域具有灵活位操作，多类型支持的特点
Bitfields适用于用户权限，功能开关，实时计数器等场景
1.5 Bitmap位图
使用bit位来表示整数，位图本质上就是一个基于字符串的位数组，支持位操作
位图具有高效存储，批量操作的特点
Bitmap适用于用户在线状态，每日签到等场景
2.渐进式遍历
Redis每次使用scan命令进行渐进式遍历键，进而解决直接使用keys获取键时可能出现的阻塞问题。每次scan命令的时间复杂度是O(1)，但是要完整地完成所有键的遍历，需要执行多次scan
cursor：给Redis服务器一个提示
count：count和实际返回key个数不一定相同，不写默认为10
pattern：表示匹配的规则
type：指定魔种类型获取该类型的value
语法：scan cursor [MATCH pattern] [COUNT count] [TYPE type]
时间复杂度：O(1)
返回值：下次scan的游标（cursor）以及本次得到的键
示例：
渐进式遍历，在遍历的过程中，不会在服务器这边存储任何的状态信息，此时的遍历是随时可以终止的，不会对服务器产生任何影响。渐进式遍历虽然解决了阻塞问题，但如果在遍历过程中键有所变化（增加，修改，删除），可能导致遍历时键的重复遍历或者遗漏，这点务必在实际开发中考虑
3.数据库管理
MySQL中有一个重要的概念Database，一个MySQL服务器上可以有很多Database，一个Database可以有多个表，MySQL上可以随意创建/删除数据库。其实Redis也有Database这样的概念的，只不过不像MySQL那样随意，Redis中的Database是现成的，用户不能创建新的数据库，也不可以删除数据库
Redis中默认提供了16个数据库 0-15，这16个数据库中的数据是隔离的，默认情况下使用0号数据库
Redis提供了几个面向数据库的操作，分别是dbsize（获取到当前数据库中key的个数），select，flushdb（删除当前数据库中的key），flushall（删除所有数据库中的key）命令
Redis通过 Select dbIndex（数据库编号）来实现数据库的切换
