Redis的边边和角角

渐进式遍历

• keys 一次性的把整个Redis中所有的key都获取到，这种操作较为危险可能会阻塞服务器，渐进式遍历就可以有效减少这种问题
• 渐进式命令：不是一个命令，把所有的key都拿到，而是没执行一次命令，只获取到其中的一小部分，这样的话保证当前这一次操作不会太卡，要想得到所有的key就需要多次遍历了（化整为零）
• 渐进式命令是一组命令，这一组命令的使用方法是一致的，其中代表命令scan

• cursor：光标，涉及到从哪里开始遍历，就指向了当前遍历的位置，光标设置为0，以为着这次便利是从头开始获取，返回值的前半部分，是告诉你，下次继续遍历，光标要从哪里开始
• cursor不能理解成”下标“，不是一个连续递增的整数，仅仅是一个“字符串”，光标这个概念，客户端是不能认识的，redis服务器则知道这个光标对应的位置

选项 

• match：和前面介绍的keys命令是一样的，也就是keys * 中的*，还有别的匹配规则，详情请看前面文章

• count：限制这一次遍历能够获取到多少个元素，默认是10，但是注意，此处的count和MySQL中的limit是不一样的，limit是精确的，但是count则不是，只是给redis服务器一个“提示/建议”，redis服务器有可能不会听取“建议”，但是不会差很多

• type：redis里的key都是string，但是value的数据类型是不一定的，所以type是获取哪种数据类型的value

返回值

有两部分，第一部分是下次光标的位置，另一部分是返回的key，scan是有可能返回空的集合的，如果命令返回的cursor是0，代表遍历结束

• 返回结果不一定是递增的
• count也不一定是准的

注意事项：

• count这里的数字，不是说每次遍历都得设置成一样
• 这里的渐进式遍历，在遍历过程中，不会再服务器存储任何的状态信息的，此处的遍历是随时可以终止的，不会对服务器产生任何的副作用

• 我去吃烧烤，一般烧烤店烤肉的速度非常快，烤肉很快就上来了，烤菜很慢，肉都吃完了，吃饱了，等了很久，菜还没上来，去结账的时候，老板赶紧跑到后厨，看到说，就退不了了
• 烧烤店-服务器，我-客户端，我点了很多烤肉和烤菜，烧烤店就得一样一样的烤好上来，就是在遍历很多key，我遍历了一半之后，我想取消，发现取消不了，服务器这里保存了状态（服务器已经把菜烤上了），如果我想强行取消，此时服务器的状态仍然保留着，此时就会对服务器的运行造成一定影响
• 相比之下，redis则没有采取这样的设定，redis服务器不保留任何状态，遍历是随时可以中断的
• redis则可以是去超市买东西，推个购物车，装很多东西，扫了一半，你突然说后面的你不要了，想直接走

渐进性遍历 scan 虽然解决了阻塞的问题，但如果在遍历期间键有所变化（增加、修改、删 除），可能导致遍历时键的重复遍历或者遗漏，这点务必在实际开发中考虑。

不像C++里可能崩溃了，redis虽然不会崩溃，但是可能会出现遗漏重复

不仅仅是redis，遍历其他内容的时候，也是比较忌讳一边遍历，一边修改的

std:vector<int> v = {1,2,3,4};
for(auto it = v.begin(); it != v.end(); ++it) {
    v.erase(it);
}
//迭代器失效
//当删除完成之后，it这个迭代器指向哪里，已经不知道了

虽然scan比key要好点，但是使用的时候也还是有很多的注意事项，很多的出错的可能的；但是真的需要遍历redis中所有的key嘛？

数据库管理命令

• MySQL中有一个重要的概念，database，一个MySQL服务器上可以有很多database，一个database上可以有很多表；redis也是有database这样的概念的，只不过不像MySQL那样随意，redis中的database是现成的，咱们用户不能创建新的数据库，也不能删除已有的数据库
• 默认redis提供了16个数据库：0-15，这16个数据库中的数据是隔离的，默认情况下是0号
• Redis 提供了⼏个⾯向 Redis 数据库的操作，分别是 dbsize、select、flushdb、flushall 命令， 本机将通过具体的使⽤常⻅介绍这些命令。

切换数据库

select dbIndex

实际使用redis很少会关注到数据库，一般默认使用0号就可以了

获取当前选中数据库中元素的个数

dbsize

删除数据库

flushall

删除所有数据库中的元素

flushdb

删除当前数据库中的元素

• sync/async分别是同步的/异步的，一般使用异步，不然会阻塞住redis服务器
• Redis 中虽然⽀持多数据库，但随着版本的升级，其实不是特别建议使⽤多数据库特性。如 果真的需要完全隔离的两套键值对，更好的做法是维护多个 Redis 实例，⽽不是在⼀个 Redis 实例中维护多数据库。
• 这是因为本⾝ Redis 并没有为多数据库提供太多的特性，其次 ⽆论是否有多个数据库，Redis 都是使⽤单线程模型，所以彼此之间还是需要排队等待命令 的执⾏。同时多数据库还会让开发、调试和运维⼯作变得复杂。所以实践中，始终使⽤数据 库 0 其实是⼀个很好的选择。