购物网站首页分成几个模块,宁波人流医院,wordpress 禁止自动保存 插件,有人看免费的视频吗一.预备知识 1.基本全局命令 set key value 将key的值设置成value get key 得到key的值 keys [pattern] 查看匹配pattern的所有key 比如h?llo匹配hallo#xff0c;hbllo#xff0c;hcllo……只要用一个符号将#xff1f;代替即可 比如h*llo匹配hllo#xff0c;heeeello…一.预备知识 1.基本全局命令 set key value 将key的值设置成value get key 得到key的值 keys [pattern] 查看匹配pattern的所有key 比如h?llo匹配hallohbllohcllo……只要用一个符号将代替即可 比如h*llo匹配hlloheeeello……用0个1个或多个字符将*代替即可 比如h[ae]llo匹配hallohello只有这两个 比如h[a-e]llo匹配hallohbllohcllohdllohello这五个 比如h[^e]llo表示除e之外的字母都匹 那keys * 则可以获取到任何key keys命令的时间复杂度是O(N)所以在生产环境上一般禁止使用keys尤其是大杀器 keys *。因为生产环境上的key一般非常非常多而Redis又是一个单线程服务器执行keys*的时间就会非常长就会使redis服务器阻塞住无法给其他命令/其他客户端使用。 就像一个妹纸同时交了三个男友同时与三个男友周旋如果在同一时间三个男友都要约会就周旋不过来了。 而且Redis经常被当作缓存替mysql负重前行。一旦redis被keys *给阻塞住了那么美其他查询redis的命令就超时了就会直接访问mysql。突然一大波请求发送过来mysql就会措手不及容易挂了 exists key [key……] 判断指定的key是否存在 返回值是存在的key的个数 这个命令的时间复杂度是O(1)因为Redis组织这些key-value键值对是按照hash表的方式来组织的每次找一个key都是O(1)所以当key特别多时时间复杂度就成了O(N),N指的是key的个数。 exists key1 exists key2 与exists key1 key2 达到的效果相同但实际上差别很大因为Redis是客户端与服务器之间通过网络进行通信的第一种查询方式会产生更多轮次的网络通信这与直接操作内存比的话效率更低成本更高。 因为每次网络通信都涉及到封装分用进行网络通信时发送放发送一个数据这个数据就要从应用层到物理层层层封装即每一层协议都要加上报头报尾就像抱一个快递要包很多层。接收方收到后这个数据就要从物理层到应用层层层分用也就是拆快递 del key [key^] 删除指定的key 返回值是成功删除掉的key的个数 时间复杂度是O(1)。其实还是和exists一样有几个key就是O几的时间复杂度 我们知道在MySQL中删除数据是很危险的操作那么del在redis中是不是危险操作呢 当redis作为缓存存储热点数据时由于全量数据依然安安全全的在MySQL中所以redis这里误删了几个数据没有太大影响只要通过mysql再把数据给映射到redis就可以了。不过要是突然一下子一大半热点数据redis就大概率无法替mysql负重前行了就可能使得很多的请求突然到了MySQL那里可能会导致MySQL挂掉。 当redis作为MQ消息队列时影响程度就要分情况来看了 当redis代替mysql作为数据库时影响就很大啦 expire key seconds 为指定的key添加过期时间 ttl key 查看当前key剩余的时间 如上过期时间的单位是秒级当到期时ttl的返回值就是-2 expire的应用场景有很多比如点外卖优惠券在指定时间内有效比如手机验证码的有效时间比如分布式锁的实现有多种实现方式其中redis就是一种所谓redis实现分布式锁其实就是给redis加一个特殊的key-value把它删了就是解锁为了避免不能正确解锁的情况redis就会给锁设置过期时间。 pexpire key也是设定过期时间不过它的单位是毫秒 注意当expire和pexpire后面的key不存在时返回值就是0 ttl key 查看当前key剩余的时间 ttl获取指定key的过期时间它的单位也是秒级ttl即Time To Live 当没有关联过期时间时它的返回值就是-1当key不存在时它的返回值就是-2 在IP协议的报头也有一个ttl但那个TTL不是用时间来衡量过期的而是用次数 Redis的过期策略如何实现 一个Redis中存在很多key这些key中可能大部分都有过期时间此时redis服务器咋知道那些key过期了 redis的整体策略就是定期删除和惰性删除。惰性删除就是当key到期时先不删紧接着后面又访问到的时候redis就发现这个key过期了再把它删了同时返回nil而上述过程也要结和定期删除就是每次抽取一小部分key看看有没有到期的有的话就删了。只取一小部分就能够保证这个抽取检查的过程足够快防止redis线程阻塞。 为啥对于定期删除的时间有明确规定因为redis时单线程程序它主要的任务处理命令扫描过期的key……都是在一个线程中执行的如果扫描key这个操作消耗的时间太多或这个操作太频繁就会影响其他命令执行就可能达到和keys*一样的效果. 虽然有了上述两种策略但整体效果还是一般仍然会有key没能及时删除。因此redis也提供了一系列内存淘汰策略这个以后会讲到 注意redis没有使用定时器的策略来实现过期key的删除。但这里我们也简单复习一下定时器的实现 定时器的实现 1.基于优先级队列/堆 在redis的过期key中通过”过期时间越早优先级越高越先出队列队首元素最早过期”的方式实现key的删除。此时定时器秩序分配一个线程让线程去检查队首元素看是否过期。但扫描线程检查队首元素的过期时间时也不能太频繁否则会出现忙等。此时就可更具队首元素的过期时间设置一个等待时间当时间差不多了系统就唤醒线程。这样的话扫描线程就不用高频率扫描队首元素了就能省下cpu开销。但万一要是在休眠的时候来了一个新任务要执行该怎么办那就直接唤醒这个扫描线程重新检查队首元素再根据过期时间去重新调整等待时间。如果key特别多就可以多来几个扫描线程。 当然redis没有采用这个方法因为redis是单线程程序。 2.基于时间轮实现的定时器 把时间划分成很多很多的小段划分的粒度看实际需求把小段分配到一个圆环上每一个小段都是一个链表都代表要执行的任务。假设每一个小段代表100毫秒有一个key是300毫秒后过期那么他就被添加到第三个小格上。然后指针就会每隔100毫秒向下走一小格每次走到一个格子就会把这个格子链表上的任务尝试执行一下看是不是真的到时间了就比如一个任务是3000ms过期那么指针就要转好几圈才能执行到。 对于时间轮来说一共多少格子每个格子多长时间都是可以灵活调配的。但redis也没有采取这个定时器的策略不过redis源码里面有个比较核心的机制事件循环与时间轮优点类似 type key 查看指定key对应的value的数据类型 key不存在时返回null lpushsaddhset等命令会在后面讲到 2.Redis数据结构及内部编码 Redis支持很多数据结构指的是一个value可以是一些复杂的结构然而它的这些键值对都是通过hash表的形式来组织的而且key的类型只能是string类型。在redis官方文档上列出了12中数据结构如下不过我们常用的就是5种StringListSetHashZset(有序集合). 但注意这些只是redis对外的数据结构它内部可不一定真的是使用这个结构存储value的Redis底层在实现上述数据结构时会在源码层面上针对上述实现进行特定的优化来达到节省空间/时间的效果。内部具体实现的数据结构编码方式还会有变数。 就比如redis承诺现在我这里有关hash表你进行查询删除插入操作时都保证O(1)但是这背后的实现可不一定是标准的hash表可能在特定场景下使用别的数据结构实现从而保证承诺 String的内部编码 rawintembstr raw表示最基本的字符串底层持有一个byte数组 int当value是一个整数时redis就会使用int来存储从而更快实现计数加减这样的操作 embstr这个是用来针对短字符串进行特殊优化的。但要是字符串太长就会使用raw hash的内部编码hashtable和ziplist hashtable注意它与java标准库中的hashtable不一样 ziplist压缩列表在hash表中的元素较少时使用ziplist来进行优化但是当元素很多时就不能使用ziplist而是使用hashtable。压缩列表能够节省空间但是它的遍历就会变成顺序遍历那这样的话还能是O(1)的时间复杂度吗可以因为元素很少遍历起来很快。 为啥要压缩redis上有很多key可能某些key的value是hash类型此时若这样的key特别多那么对应的hash结构就很多那肯定要占用很多内存空间。但要是每个hash都不大那就用ziplist尽量去压缩从而使整体占用的内存空间减小。到这里有人会说那不应该hash越大越要压缩吗注意节省了空间那肯定在压缩是有其他开销比如时间…… list的内部编码linkedlist和ziplist linkedlist就是链表 ziplist压缩链表 但是这是旧版本的redis的list实现方式从redis3.2版本开始list的实现方式是quicklist它代替了linkedlist和ziplist兼顾两者的优点。quicklist就是一个链表每一个节点的元素又是一个ziplist。也就是说quicklist的空间和效率都折中兼顾了 set的编码方式hashtable和intset intset当集合中都是整数时就是用intset zset的编码方式skiplist和ziplist skiplist跳表每个节点上有多个指针域巧妙搭配这些指针域的指向就可以达到查询的时间复杂度为O(log2N)就近似于二叉平衡搜索树 通过 object encoding key 的命令可以查看指定key的内部编码方式 3.redis的单线程架构 redis只是用一个线程来处理所有的命令和请求但不是说redis真的只有一个线程其实它也有多个线程只不过其他的线程都是在处理网络IO罢了。 假设有两个请求同时要求key自增那么key最终的结果是加一还是加二呢 首先回顾一下在多线程中自增操作存在线程安全问题因为自增操作在cpu角度是分成三个指令执行的它不是原子的因此可能当两个线程两个cpu核共用同一个内存空间同时要求key自增时key只自增一次。 redis这里两个请求同时要求key自增这也相当于“并行”发起。但是redis服务器这里不会有线程安全问题。因为reids是单线程模型而不是多线程这两个请求看似是同时到达redis服务器但最终还是得在队列里排队一个一个进行。 redis能使用单线程模型很好的工作主要是因为redis的核心业务逻辑都是短平快的不太消耗cpu资源不太吃多核cpu。 但这样的弊端就是redis必须要特别小心若某个操作占用时间特别长那么就会阻塞其他命令的执行 相关面试题Redis虽然是单线程模型但为啥效率这么高速度这么快参照物是数据库 1.redis访问内存而数据库访问硬盘 2.redis的核心功能比数据库简单干的活少提供的功能比数据库少了不少 3.redis单线程模型避免了不必要的线程竞争开销。redis每个基本操作都是短平快的就是简单的操作内存数据结构不是什么特别消耗cpu的操作就算是搞个多线程也没多大意义提升也不大甚至可能降低效率 4.redis处理网络IO时使用了epoll这样的IO多路复用的机制 什么是IO多路复用就是指一共线程可以管理多个socket。针对TCP来说服务器这边每次要服务多个客户端都要给每一个客户端安排一个socket通过此socket来和客户端进行通信。一个服务器要服务多个客户端所以自然而然就有多个socket。这些socket难道都是无时无刻不在传输数据吗当然不是大多数情况下这些socket是静默的上面是没有数据要传输的也就是说同一时刻只有少数socket是活跃的。 在以前介绍TCP服务器的时候有个版本是每个客户端给分配一个线程这就导致客户端很多时线程就很多系统开销就很大。但上面咱们说了大多是线程是不活跃的。所以就可以引入IO多路复用让一个线程同时去处理多个socket这是操作系统给程序员提供的机制即API内部的功能是操作系统内核实现的。 在linux上IO多路复用的实现主要是三套APIselectpollepoll。 什么是epoll呢好比我们去小吃街买炒饭、肉夹馍和饺子我们先去让老板做炒饭在等的过程中去买肉夹馍再在等的过程中去买饺子。这三份饭那个先做好了对应的老板就来喊我最大限度的节省了时间。这就是epoll事件通知/回调机制此时我一个线程就同时做了三件事情但能够同时做这撒气那件事情的前提是这三件事情的交互不太频繁大部分时间都在等待。 那什么是select呢那就是老板不喊我我不停的在三个窗口之间来回跑问老板饭好了没有 对于IO多路复用java中使用的是NIO标准库中提供的一组类底层封装了epoll