深圳网站建设认准乐云践新wordpress缓存稿

当前位置： 首页 > news >正文

深圳网站建设认准乐云践新,wordpress缓存稿,wordpress删除自定义字段,怎么做一个网站app吗一、认识Redis

1. 什么是 Redis#xff1f; Redis 是一种基于内存的数据库#xff0c;对数据的读写操作都是在内存中完成#xff0c;因此读写速度非常快#xff0c;常用于缓存#xff0c;消息队列、分布式锁等场景。Redis 提供了多种数据类型来支持不同的业务场景#…一、认识Redis
2. 什么是 Redis Redis 是一种基于内存的数据库对数据的读写操作都是在内存中完成因此读写速度非常快常用于缓存消息队列、分布式锁等场景。Redis 提供了多种数据类型来支持不同的业务场景比如 String(字符串)、Hash(哈希)。并且对数据类型的操作都是原子性的因为执行命令由单线程负责的不存在并发竞争的问题。 除此之外Redis 还支持事务 、持久化、多种集群方案主从复制模式、哨兵模式、切片机群模式、发布/订阅模式内存淘汰机制、过期删除机制等等。
3. Redis和Memcached有什么区别 Redis 支持的数据类型更丰富String、Hash、List、Set、ZSet而 Memcached 只支持最简单的 key-value 数据类型Redis 支持数据的持久化可以将内存中的数据保持在磁盘中重启的时候可以再次加载进行使用而 Memcached 没有持久化功能数据全部存在内存之中Memcached 重启或者挂掉后数据就没了Redis 原生支持集群模式Memcached 没有原生的集群模式需要依靠客户端来实现往集群中分片写入数据Redis 支持发布订阅模型、Lua 脚本、事务等功能而 Memcached 不支持
4. 为什么用Redis作为MySQL的缓存 Redis 具备高性能 操作 Redis 缓存就是直接操作内存所以速度相当快。Redis具备高并发 Redis 的 QPSQuery Per Second每秒钟处理完请求的次数 是 MySQL 的 10 倍直接访问 Redis 能够承受的请求是远远大于直接访问 MySQL 的 二、Redis数据结构
5. Redis 数据类型以及使用场景分别是什么 String 类型的应用场景缓存对象、常规计数、分布式锁、共享 session 信息等。List 类型的应用场景消息队列但是有两个问题1. 生产者需要自行实现全局唯一 ID2. 不能以消费组形式消费数据等。Hash 类型缓存对象、购物车等。Set 类型聚合计算并集、交集、差集场景比如点赞、共同关注、抽奖活动等。Zset 类型排序场景比如排行榜、电话和姓名排序等。BitMap2.2 版新增二值状态统计的场景比如签到、判断用户登陆状态、连续签到用户总数等HyperLogLog2.8 版新增海量数据基数统计的场景比如百万级网页 UV 计数等GEO3.2 版新增存储地理位置信息的场景比如滴滴叫车Stream5.0 版新增消息队列相比于基于 List 类型实现的消息队列有这两个特有的特性自动生成全局唯一消息ID支持以消费组形式消费数据。
6. Redis 数据类型是怎么实现 SDS 1引出C语言字符串字符数组的不足 获取字符串长度的时间复杂度为 ON 字符串的结尾是以 “\0” 字符标识字符串里面不能包含有 “\0” 字符因此不能保存二进制数据 字符串操作函数不高效且不安全比如有缓冲区溢出的风险有可能会造成程序运行终止 2SDS 优点如下 len —— O1复杂度获取字符串长度 不需要用 “\0” 字符来标识字符串结尾 —— 二进制安全 当判断出缓冲区大小不够用时Redis 会自动将扩大 SDS 的空间大小 —— 不会发生缓冲区溢出 能灵活保存不同大小的字符串从而有效节省内存空间 —— 节省内存空间 链表 1list概念Redis 在 listNode双向链表节点 结构体基础上又封装了 list 这个数据结构。 2优点     获取某个节点的前置节点或后置节点的时间复杂度只需O(1)而且这两个指针都可以指向 NULL所以链表是无环链表     获取链表的表头节点和表尾节点的时间复杂度只需O(1)     获取链表中的节点数量的时间复杂度只需O(1)     链表节点可以保存各种不同类型的值 3缺点     链表每个节点之间的内存都是不连续的意味着无法很好利用 CPU 缓存。     保存一个链表节点的值都需要一个链表节点结构头的分配内存开销较大 压缩列表 1结构 压缩列表就会根据数据类型是字符串还是整数以及数据的大小会使用不同空间大小的 prevlen 和 encoding 这两个元素里保存的信息这种根据数据大小和类型进行不同的空间大小分配的设计思想正是 Redis 为了节省内存而采用的。 这就会导致连锁更新。 2连锁更新 压缩列表新增某个元素或修改某个元素时如果空间不不够压缩列表占用的内存空间就需要重新分配。而当新插入的元素较大时可能会导致后续元素的 prevlen 占用空间都发生变化从而引起「连锁更新」问题导致每个元素的空间都要重新分配造成访问压缩列表性能的下降。 哈希表 1引出Hash 对象的底层实现是压缩列表最新Redis已将压缩列表替换成 listpack和 哈希表。 2结构redis哈希表 和 哈希表节点 Redis 的哈希表结构如下 哈希表节点的结构如下 综上哈希表是一个数组dictEntry **table数组的每个元素是一个指向「哈希表节点dictEntry」的指针。 3哈希冲突rehash渐进式rehash 哈希冲突当有两个以上数量的 kay 被分配到了哈希表中同一个哈希桶上时此时称这些 key 发生了冲突。 rehash: 在正常服务请求阶段插入的数据都会写入到「哈希表 1」此时的「哈希表 2 」 并没有被分配空间。rehash操作如下 第一步、给「哈希表 2」 分配空间一般会比「哈希表 1」 大 2 倍 第二步、将「哈希表 1 」的数据迁移到「哈希表 2」 中 第三步、迁移完成后「哈希表 1 」的空间会被释放并把「哈希表 2」 设置为「哈希表 1」然后在「哈希表 2」 新创建一个空白的哈希表为下次 rehash 做准备。 问题可能会涉及大量的数据拷贝此时可能会对 Redis 造成阻塞无法服务其他请求。 渐进式rehash: 也就是 将数据的迁移的工作不再是一次性迁移完成而是 分多次迁移。 整数集合 1结构 contents 数组的真正类型取决于 intset 结构体里的 encoding 属性的值。所以不同类型的 contents 数组意味着数组的大小也会不同。这就会出现 整数集合的升级操作。 2整数集合的升级操作 过程如下 跳表 1举例 以上图中所有层的各个节点都为跳表的节点。 2跳表查询过程简介是在多个层级上跳来跳去最后定位到元素。当数据量很大时跳表的查找复杂度就是 O(logN)。 3跳表查询过程 根据以下判断条件在层中或层间 跳来跳去 判断条件一、如果当前节点的权重「小于」要查找的权重时跳表就会访问该层上的下一个节点。 判读条件二、如果当前节点的权重「等于」要查找的权重时并且当前节点的 SDS 类型数据「小于」要查找的数据时跳表就会访问该层上的下一个节点。 如果上面两个条件都不满足或者下一个节点为空时跳表就会使用目前遍历到的节点的 level 数组里的下一层指针然后沿着下一层指针继续查找 4跳表节点层数设置 具体做法为跳表在创建节点时候会生成范围为[0-1]的一个随机数如果这个随机数小于 0.25相当于概率 25%那么层数就增加 1 层然后继续生成下一个随机数直到随机数的结果大于 0.25 结束最终确定该节点的层数。 5为什么用跳表而不用平衡树 quicklist 1举例 向 quicklist 添加一个元素的时候不会像普通的链表那样直接新建一个链表节点。而是会检查插入位置的压缩列表是否能容纳该元素如果能容纳就直接保存到 quicklistNode 结构里的压缩列表如果不能容纳才会新建一个新的 quicklistNode 结构。 2问题quicklist 会控制 quicklistNode 结构里的压缩列表的大小或者元素个数来规避潜在的连锁更新的风险但是这并没有完全解决连锁更新的问题。 listpackRedis 在 5.0 新设计一个数据结构叫 listpack目的是替代压缩列表避免连锁更新 1结构 listpack 结构 和 其节点结构 这样的话listpack 没有压缩列表中记录前一个节点长度的字段了listpack 只记录当前节点的长度当我们向 listpack 加入一个新元素的时候不会影响其他节点的长度字段的变化从而避免了压缩列表的连锁更新问题。
   三、Redis线程模型
7. Redis 是单线程吗 Redis 单线程指的是「接收客户端请求-解析请求 -进行数据读写等操作-发送数据给客户端」这个过程是由一个线程主线程来完成的。 但是Redis 程序并不是单线程的Redis 在启动的时候是会启动后台线程BIO的 Redis 在 2.6 版本会启动 2 个后台线程分别处理关闭文件、AOF 刷盘这两个任务Redis 在 4.0 版本之后新增了一个新的后台线程用来异步释放 Redis 内存也就是 lazyfree 线程。例如执行 unlink key / flushdb async / flushall async 等命令会把这些删除操作交给后台线程来执行好处是不会导致 Redis 主线程卡顿。因此当我们要删除一个大 key 的时候不要使用 del 命令删除因为 del 是在主线程处理的这样会导致 Redis 主线程卡顿因此我们应该使用 unlink 命令来异步删除大key。 之所以 Redis 为「关闭文件、AOF 刷盘、释放内存」这些任务创建单独的线程来处理是因为这些任务的操作都是很耗时的如果把这些任务都放在主线程来处理那么 Redis 主线程就很容易发生阻塞这样就无法处理后续的请求了。
8. Redis 单线程模式是怎样的 待更
9. Redis 采用单线程为什么还这么快 Redis 的大部分操作都在内存中完成并且采用了高效的数据结构因此 Redis 瓶颈可能是机器的内存或者网络带宽而并非 CPU既然 CPU 不是瓶颈那么自然就采用单线程的解决方案了Redis 采用单线程模型可以避免了多线程之间的竞争省去了多线程切换带来的时间和性能上的开销而且也不会导致死锁问题。Redis 采用了 I/O 多路复用机制处理大量的客户端 Socket 请求IO 多路复用机制是指一个线程处理多个 IO 流。简单来说在 Redis 只运行单线程的情况下该机制允许内核中同时存在多个监听 Socket 和已连接 Socket。内核会一直监听这些 Socket 上的连接请求或数据请求。一旦有请求到达就会交给 Redis 线程处理这就实现了一个 Redis 线程处理多个 IO 流的效果。
10. Redis 6.0 之前为什么使用单线程 Redis采用单线程避免多线程直接的上下文切换和进程调度等所以CPU 并不是制约 Redis 性能表现的瓶颈所在更多情况下是受到内存大小和网络I/O的限制可维护性高多线程模型虽然在某些方面表现优异但是需要考虑线程之间的同步和通信等。避免竞争和锁 带来性能的消耗。
11. Redis 6.0 之后为什么引入了多线程 在 Redis 6.0 版本之后也采用了多个 I/O 线程来处理网络请求这是因为随着网络硬件的性能提升Redis 的性能瓶颈有时会出现在网络 I/O 的处理上。 所以为了提高网络 I/O 的并行度Redis 6.0 对于网络 I/O 采用多线程来处理。但是对于命令的执行Redis 仍然使用单线程来处理所以大家不要误解 Redis 有多线程同时执行命令。 四、Redis持久化 Redis持久化篇 五、Redis集群 Redis集群 六、Redis过期删除和内存淘汰 过期删除策略 过期字典实际上是哈希表每当我们对一个 key 设置了过期时间时Redis 会把该 key 带上过期时间存储到一个过期字典expires dict中也就是说「过期字典」保存了数据库中所有 key 的过期时间。 当我们查询一个 key 时Redis 首先检查该 key 是否存在于过期字典中 如果不在则正常读取键值 如果存在则会获取该 key 的过期时间然后与当前系统时间进行比对如果比系统时间大那就没有过期否则判定该 key 已过期。过期删除策略有哪些 1定时删除 在设置 key 的过期时间时同时创建一个定时事件当时间到达时由事件处理器自动执行 key 的删除操作。 2惰性删除 不主动删除过期键每次从数据库访问 key 时都检测 key 是否过期如果过期则删除该 key。 3定期删除 每隔一段时间「随机」从数据库中取出一定数量的 key 进行检查并删除其中的过期key。 最终Redis 选择「惰性删除定期删除」这两种策略配和使用 内存淘汰策略 不进行数据淘汰的策略 noevictionRedis3.0之后默认的内存淘汰策略 它表示当运行内存超过最大设置内存时不淘汰任何数据这时如果有新的数据写入则会触发 OOM但是如果没用数据写入的话只是单纯的查询或者删除操作的话还是可以正常工作。进行数据淘汰的策略对设置过期时间的数据淘汰 和 所有数据范围内淘汰 1在设置了过期时间的数据中进行淘汰 volatile-random随机淘汰设置了过期时间的任意键值 volatile-ttl优先淘汰更早过期的键值。 volatile-lruRedis3.0 之前默认的内存淘汰策略淘汰所有设置了过期时间的键值中最久未使用的键值 volatile-lfuRedis 4.0 后新增的内存淘汰策略淘汰所有设置了过期时间的键值中最少使用的键值 2在所有数据范围内进行淘汰 allkeys-random随机淘汰任意键值; allkeys-lru淘汰整个键值中最久未使用的键值 allkeys-lfuRedis 4.0 后新增的内存淘汰策略淘汰整个键值中最少使用的键值。如何查看和修改Redis 内存淘汰策略 查看config get maxmemory-policy 修改1config set maxmemory-policy 策略 2通过修改 Redis 配置文件修改设置maxmemory-policy 策略LRU算法 和 LFU算法 1LRU算法LRU 全称是 Least Recently Used 翻译为最近最少使用会选择淘汰最近最少使用的数据。传统 LRU 算法的实现是基于「链表」结构链表中的元素按照操作顺序从前往后排列最新操作的键会被移动到表头当需要内存淘汰时只需要删除链表尾部的元素即可。 缺点如下 缺点一、需要用链表管理所有的缓存数据这会带来额外的空间开销 缺点二、当有数据被访问时需要在链表上把该数据移动到头端如果有大量数据被访问就会带来很多链表移动操作会很耗时进而会降低 Redis 缓存性能。 2Redis是如何实现LRU算法的 Redis 实现的是一种近似 LRU 算法目的是为了更好的节约内存它的实现方式是在 Redis 的对象结构体中添加一个额外的字段用于记录此数据的最后一次访问时间。 当 Redis 进行内存淘汰时会使用随机采样的方式来淘汰数据它是随机取 5 个值此值可配置然后淘汰最久没有使用的那个。 3LFU算法LFU 全称是 Least Frequently Used 翻译为最近最不常用LFU 算法是根据数据访问次数来淘汰数据的它的核心思想是“如果数据过去被访问多次那么将来被访问的频率也更高”。所以 LFU 算法会记录每个数据的访问次数。当一个数据被再次访问时就会增加该数据的访问次数。 4Redis 是如何实现 LFU 算法的 LFU 算法相比于 LRU 算法的实现多记录了「数据的访问频次」的信息。 Redis 对象头中的 lru 字段在 LRU 算法下和 LFU 算法下使用方式并不相同。 在 LRU 算法中Redis 对象头的 24 bits 的 lru 字段是用来记录 key 的访问时间戳因此在 LRU 模式下Redis可以根据对象头中的 lru 字段记录的值来比较最后一次 key 的访问时间长从而淘汰最久未被使用的 key。 在 LFU 算法中Redis对象头的 24 bits 的 lru 字段被分成两段来存储高 16bit 存储 ldt(Last Decrement Time)低 8bit 存储 logc(Logistic Counter)。 两个变量代表的含义 ldt 是用来记录 key 的访问时间戳 logc 是用来记录 key 的访问频次注意logc 是访问频次访问频率 七、Redis缓存设计 Redis缓存篇 八、Redis实战
12. Redis 如何实现延迟队列 在 Redis 可以使用有序集合ZSet的方式来实现延迟消息队列的ZSet 有一个 Score 属性可以用来存储延迟执行的时间。 在使用 zadd score1 value1 命令就可以一直往内存中生产消息之后。再利用 zrangebyscore 查询就能得到待处理的任务了通过循环执行队列任务即可。
    
13. Redis 的大 key 如何处理 如何找到大 key 1redis-cli –bigkeys 查找大key 2使用 SCAN 命令查找大 key 3使用 RdbTools 工具查找大 key如何删除大 key 1分批次删除 删除大 Hash使用 hscan 命令删除大 List通过 ltrim 命令删除大 Set使用 sscan 命令删除大 ZSet使用 zremrangebyrank 2异步删除Redis 4.0版本以上 从 Redis 4.0 版本开始可以采用异步删除法用 unlink 命令代替 del 来删除。 除了主动调用 unlink 命令实现异步删除之外我们还可以通过配置参数达到某些条件的时候自动进行异步删除。 主要有 4 种场景默认都是关闭的 lazyfree-lazy-eviction no —— 内存超过 maxmeory lazyfree-lazy-expire no —— 设置了过期时间的键值当过期之后是否开启 lazy free 机制删除 lazyfree-lazy-server-del —— 隐式的 del是否开启 lazy free 机制删除例如 rename noslave-lazy-flush no —— lave 在加载 master 的 RDB 文件前会运行 flushall 来清理自己的数据是否开启 lazy free 机制删除
14. Redis 管道有什么用 主要作用使用管道技术可以解决多个命令执行时的网络等待。所以管道技术本质上是客户端提供的功能而非 Redis 服务器端的功能。
15. Redis 事务支持回滚吗 一个事务在开启过程之后向命令队列中加入命令时候若此时执行DISCARD则清空命令队列中的任务。并不会执行事务任何命令。若一个事务在开启之后向命令队列中加入命令当事务执行之后EXEC命令若事务中有一句命令是错误的则该条命令之前都会执行成功它之后的不会执行。也就是没有回滚机制。
16. 如何用 Redis 实现分布式锁的 概念在分布式环境下完成并发控制。用于控制某个资源在同一时刻只能被一个应用使用。实现加锁操作需要满足三个条件 1使用SET命令时候带上NX选项。加锁包括了读取锁变量、检查锁变量值和设置锁变量值三个操作需要以原子操作的方式完成。 2SET 命令执行时加上 EX/PX 选项设置其过期时间。锁变量需要设置过期时间以免客户端拿到锁后发生异常导致锁一直无法释放。 3 SET 命令设置锁变量值时每个客户端设置的值是一个唯一值用于标识客户端。锁变量的值需要能区分来自不同客户端的加锁操作以免在释放锁时出现误释放操作。 满足上面三个条件之后SET命令是这个样子 实现解锁操作Lua脚本解锁的时候先判断锁的 unique_value 是否为加锁的客户端是的话将 lock_key 键删除。 因为解锁操作需要两步。Redis 在执行 Lua 脚本时可以以原子性的方式执行所以可以通过Lua脚本来执行解锁的两步来保证锁释放操作的原子性。优点 1性能高效 2实现方便setnx命令 3避免单点故障缺点 1超时时间不好设置。如果锁的超时时间设置过长会影响性能如果设置的超时时间过短会保护不到共享资源。 怎么改善  基于续约的方式设置超时时间 —— 写一个守护线程然后去判断锁的情况当锁快失效的时候再次进行续约加锁当主线程执行完成后销毁续约锁即可 2Redis 主从复制模式中的数据是异步复制的这样导致分布式锁的不可靠性。如果在 Redis 主节点获取到锁后在没有同步到其他节点时Redis 主节点宕机了此时新的 Redis 主节点依然可以获取锁所以多个应用服务就可以同时获取到锁。 怎么改善 Redlock红锁。核心思想为是让客户端和多个独立的 Redis 节点依次请求申请加锁如果客户端能够和半数以上的节点成功地完成加锁操作那么我们就认为客户端成功地获得分布式锁否则加锁失败。