基于redis是单线程的，使用的Redis的，有必要有意识的从是否存在极大value的情况，且出现频繁，访问Redis并发的场景，比如一个命令耗时10ms，然后每s并发100，那基本上redis都会阻塞在这个命令上了；

我们先看Redis的几个常见命令时间复杂度：

1. keys * 返回所有的key，keys命令最好不要在生产环境用，会全局遍历，会很慢，要堵塞其他命令。
2. dbsize 显示一共有几个key，这个可以在生产用，不会全局遍历
3. exists keyname 查看key是否存在，存在返回1，不存在返回0
4. del kename 删除key 成功返回1，失败返回0。可以删除多个。
5. expire keyname seconds 为key设置过期时间,秒级
6. ttl keyname 查询key的过期时间，如果返回值为-1，代表不会过期（永久Key），-2代表key不存在了
7. persist keyname 去掉key的过期时间，它就不会过期了（永久Key）
8. tpye keyname 查看key的数据类型

几个复杂度的排序，
O(1), O(n), O(logn), O(nlogn) 的区别：
      O后面的括号中有一个函数，指明某个算法的耗时/耗空间与数据增长量之间的关系。其中的n代表输入数据的量。
      O(1)就是最低的时空复杂度了，也就是耗时/耗空间与输入数据大小无关，无论输入数据增大多少倍，耗时/耗空间都不变。 哈希算法就是典型的O(1)时间复杂度，无论数据规模多大，都可以在一次计算后找到目标（不考虑冲突的话）
      时间复杂度为O(n)，就代表数据量增大几倍，耗时也增大几倍。比如常见的遍历算法。
      O(logn)，当数据增大n倍时，耗时增大logn倍（这里的log是以2为底的，比如，当数据增大256倍时，耗时只增大8倍，是比线性还要低的时间复杂度）。二分查找就是O(logn)的算法，每找一次排除一半的可能，256个数据中查找只要找8次就可以找到目标。
      O(nlogn)同理，就是n乘以logn，当数据增大256倍时，耗时增大256*8=2048倍。这个复杂度高于线性低于平方。归并排序就是O(nlogn)的时间复杂度。

时间复杂度大小的比较：
O(1) < O(logn) < O(n) < O(nlogn) < O(n^2) < O(n^3) < O(2^n)

入上图列出的几个常见命令，keys *这种命令肯定是要慎用的，但是
比如del命令就真的可以随便用吗？
      答案肯定是否定的，del大对象的话，也是比较耗时的（即使Redis4.0以后有异步懒删除，但是也是耗性能的，大内存的频繁置换也是其中一个因素），这个时候如果del并发很高，也是严重会阻塞redis的；

所以整体的结论是时间复杂度高的命令要慎用，并发高的耗时命令要慎用，减少大对象的处理；

以下收集整理Redis命令时间复杂度查询表：
String类型：

比如下面的批量操作 mset，mget命令，复杂度是较高的，批量获取个1000个？ 并发再高点试试？

Hash类型
典型的是这个hgetall， hash里面获取个全量几万的数据，并发稍微高点试试？

List类型
List 的数据结构似乎大部分命令的耗时都较高，其实rpush、lpush这些是批量操作，同时push很多的话，自然是O(k)的复杂度；

Set集合
之前了解到的一些场景，比如求共同好友，共同粉丝之类的；
比如在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis的set集合提供了求交集、并集、差集等操作，即以下的命令sinter suinon sdiff命令，复杂度是O(k)这些，所以一些大V上千万的粉丝，就是个大Set，求交集、并集、差集这些是比较耗时的；

ZSet类型，即排序集合
比如之前就遇到过Zrem批量删除且并发还高导致的Redis阻塞问题（https://blog.csdn.net/wf_feng/article/details/121345797?spm=1001.2014.3001.5501可参考案例）；

总之使用的Redis的，有必要有意识的从是否存在极大value的情况，且出现频繁，访问Redis并发的场景，比如一个命令耗时10ms，然后每s并发100，那基本上redis都会阻塞在这个命令上了；