四川手机网站制作,天津 企业网站建设,服务器怎么做网站,柳州论坛网站建设1.Redis是什么?
Redis 是一个基于 C 语言开发的开源数据库#xff08;BSD 许可#xff09;#xff0c;与传统数据库不同的是 Redis 的数据是存在内存中的#xff08;内存数据库#xff09;#xff0c;读写速度非常快#xff0c;被广泛应用于缓存方向。并且#xff0c…1.Redis是什么?
Redis 是一个基于 C 语言开发的开源数据库BSD 许可与传统数据库不同的是 Redis 的数据是存在内存中的内存数据库读写速度非常快被广泛应用于缓存方向。并且Redis 存储的是 KV 键值对数据。
2.Redis的优缺点
Redis是一个开源的、内存存储、支持键值对、具有持久性的数据结构存储系统具有以下优缺点 优点
高性能Redis将数据全部存储在内存中并使用单线程模型这使得Redis的读写速度非常快。丰富的数据结构Redis支持多种数据结构包括字符串、列表、哈希表、集合和有序集合等这些数据结构可以满足不同应用场景的需求。数据持久化Redis支持将数据持久化到磁盘中包括快照和日志文件两种方式这使得Redis可以在系统宕机后快速恢复数据。支持分布式Redis支持分布式架构可以将数据分散到多个节点中提高系统的可扩展性和容错性。简单易用Redis提供了简单易用的命令行接口同时也支持多种编程语言的客户端使用起来非常方便。
缺点
数据存储受限由于Redis将所有数据存储在内存中所以受到内存容量的限制如果数据量很大需要更多的内存。单线程模型虽然Redis使用单线程模型来保证读写性能但是在高并发情况下单线程模型也可能成为瓶颈。不适合存储大文件由于Redis是将所有数据存储在内存中因此不适合存储大文件等大型二进制数据。数据一致性Redis支持数据持久化但是在高并发的情况下可能会存在数据一致性问题需要进行额外的配置和处理。配置复杂Redis提供了多种配置选项需要根据不同的使用场景进行不同的配置这可能会增加系统配置的复杂度。
3.Redis为什么这么快
基于内存Redis 将数据全部存储在内存中而内存的访问速度是磁盘的上千倍这使得 Redis 能够快速地读取和写入数据。高效的事件处理模型Redis 基于 Reactor 模式设计开发了一套高效的事件处理模型主要是单线程事件循环和 IO 多路复用这使得 Redis 能够高效地处理大量的并发请求。优化过的数据结构实现Redis 内置了多种优化过后的数据结构实现如哈希表、有序集合等这些数据结构能够高效地处理常见的数据操作如插入、删除、查找等。异步非阻塞的网络模型Redis 使用异步非阻塞的网络模型这使得 Redis 能够高效地处理大量的并发请求而不会因为等待 I/O 操作而阻塞线程从而提高了系统的吞吐量。数据持久化Redis 支持将数据持久化到磁盘中包括快照和日志文件两种方式这使得 Redis 可以在系统宕机后快速恢复数据从而提高了系统的可靠性。
4.Redis为何选择单线程
Redis 选择单线程模型的主要原因是为了避免线程切换带来的开销和竞争条件带来的复杂性从而提高系统的性能和可靠性。具体来说单线程模型带来以下几个优点
避免线程切换带来的开销线程切换会带来一定的开销包括上下文切换和内存开销等而单线程模型能够避免这些开销从而提高系统的性能。避免竞争条件带来的复杂性在多线程模型下多个线程之间会存在竞争条件需要使用锁等机制来避免竞争条件带来的复杂性而单线程模型能够避免这些复杂性从而提高系统的可靠性。更容易实现单线程模型相对于多线程模型更容易实现和维护因为它不需要考虑线程间的同步和通信等问题。更容易进行优化由于单线程模型不会存在多线程间的竞争条件因此可以更容易地进行优化如利用 CPU 缓存等。
需要注意的是Redis 的单线程模型并不代表它只能处理一个请求实际上 Redis 通过事件处理模型和异步非阻塞的网络模型能够同时处理大量的并发请求从而实现高吞吐量和低延迟。
5.Redis应用场景有哪些
Redis 作为一种高性能、可靠性高的内存数据库在许多应用场景中得到了广泛的应用。以下是 Redis 的一些常见应用场景
缓存Redis 作为一种高速缓存数据库可以将热点数据缓存在内存中从而提高系统的读写性能。消息队列Redis 的发布/订阅模式和 List 数据结构可以实现轻量级的消息队列从而支持异步消息通信。计数器和排行榜Redis 的原子性操作和 Sorted Set 数据结构可以实现高效的计数器和排行榜功能。分布式锁Redis 的原子性操作和过期时间可以实现高效的分布式锁功能从而保证多个进程或线程之间的数据访问互斥。会话存储Redis 可以作为会话存储数据库将用户的会话信息存储在内存中从而支持高并发的 Web 应用程序。地理位置和空间索引Redis 的 Geo 数据结构可以实现高效的地理位置和空间索引功能从而支持 LBS 应用程序。数据库持久化Redis 支持将数据持久化到磁盘中从而支持数据备份和恢复提高系统的可靠性。
综上所述Redis 在缓存、消息队列、计数器和排行榜、分布式锁、会话存储、地理位置和空间索引、数据库持久化等多个应用场景中都具有很好的表现。
6.Memcached和Redis的区别
Redis 支持更丰富的数据类型支持更复杂的应用场景。Redis 不仅仅支持简单的 k/v 类型的数据同时还提供 listsetzsethash 等数据结构的存储。Memcached 只支持最简单的 k/v 数据类型。Redis 支持数据的持久化可以将内存中的数据保持在磁盘中重启的时候可以再次加载进行使用,而 Memcached 把数据全部存在内存之中。Redis 有灾难恢复机制。 因为可以把缓存中的数据持久化到磁盘上。Redis 在服务器内存使用完之后可以将不用的数据放到磁盘上。但是Memcached 在服务器内存使用完之后就会直接报异常。Memcached 没有原生的集群模式需要依靠客户端来实现往集群中分片写入数据但是 Redis 目前是原生支持 cluster 模式的。Memcached 是多线程非阻塞 IO 复用的网络模型Redis 使用单线程的多路 IO 复用模型。 Redis 6.0 引入了多线程 IO Redis 支持发布订阅模型、Lua 脚本、事务等功能而 Memcached 不支持。并且Redis 支持更多的编程语言。Memcached 过期数据的删除策略只用了惰性删除而 Redis 同时使用了惰性删除与定期删除。
7.Redis 数据类型有哪些
5 种基础数据结构 String字符串、List列表、Set集合、Hash散列、Zset有序集合。3 种特殊数据结构 HyperLogLogs基数统计、Bitmap 位存储、Geospatial (地理位置)
8.keys命令存在的问题
性能问题keys 命令会遍历整个 Redis 数据库中的所有键值对于大型 Redis 数据库来说这个操作可能会耗费大量时间和系统资源导致 Redis 服务器的性能下降。阻塞问题由于 keys 命令会遍历整个 Redis 数据库因此在执行 keys 命令期间Redis 服务器会被阻塞无法响应其他请求。安全问题keys 命令可以返回 Redis 数据库中的所有键值包括一些敏感数据如果在生产环境中误用 keys 命令可能会导致泄露敏感数据。
9.SortedSet和List异同点
相同点
都可以存储多个元素。都可以通过索引来访问元素。都可以在头部或尾部插入和删除元素。都可以进行范围查询即查询某个范围内的元素。都支持阻塞式的弹出和插入操作。都可以通过多种命令实现数据结构的基本操作如增删改查。
不同点
数据结构不同List 是链表结构SortedSet 是平衡树结构。元素的唯一性List 允许存储重复的元素而 SortedSet 不允许存储重复的元素并且元素按照指定的权重进行排序。排序方式不同List 中的元素按照插入顺序排序而 SortedSet 中的元素按照指定的权重排序。操作复杂度不同List 中的大多数操作的复杂度都是 O(1) 级别的而 SortedSet 中的大多数操作的复杂度都是 O(log N) 级别的其中 N 表示元素个数。适用场景不同List 适用于先进先出FIFO的场景如消息队列、任务队列等SortedSet 适用于有序排列并且需要去重的场景如排行榜、计数器等。
10.Redis事务
Redis 事务的基本使用方法如下
通过 MULTI 命令开启一个事务。在事务中执行多个命令这些命令并不会立即被执行而是被放入一个队列中。通过 EXEC 命令将事务中的所有命令依次执行。如果在事务执行过程中发生错误可以通过 DISCARD 命令取消事务。
下面是一个简单的 Redis 事务示例
sqlCopy code
MULTI SET key1 value1 SET key2 value2 GET key1 EXEC在这个示例中首先通过 MULTI 命令开启一个事务然后执行了三个命令SET key1 value1、SET key2 value2 和 GET key1。这些命令并不会立即被执行而是被放入一个队列中。最后通过 EXEC 命令将事务中的所有命令依次执行如果所有命令都执行成功则返回结果集否则返回 nil。 Redis 事务还支持一些高级功能如 WATCH 命令、CAS 命令等可以用来实现乐观锁、原子操作等功能。 需要注意的是在 Redis 中事务并不是严格意义上的 ACID 事务因为 Redis 事务并不能保证所有命令的原子性即使其中一个命令执行失败也不会回滚已执行的命令。因此在使用 Redis 事务时需要格外小心避免出现意外情况。
11.持久化机制
RDB方式 Redis 可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。Redis 创建快照之后可以对快照进行备份可以将快照复制到其他服务器从而创建具有相同数据的服务器副本Redis 主从结构主要用来提高 Redis 性能还可以将快照留在原地以便重启服务器的时候使用。 快照持久化是 Redis 默认采用的持久化方式在 redis.conf 配置文件中默认有此下配置
save 900 1 #在900秒(15分钟)之后如果至少有1个key发生变化Redis就会自动触发bgsave命令创建快照。save 300 10 #在300秒(5分钟)之后如果至少有10个key发生变化Redis就会自动触发bgsave命令创建快照。save 60 10000 #在60秒(1分钟)之后如果至少有10000个key发生变化Redis就会自动触发bgsave命令创建快照。
Redis 提供了两个命令来生成 RDB 快照文件
save : 同步保存操作会阻塞 Redis 主线程bgsave : fork 出一个子进程子进程执行不会阻塞 Redis 主线程默认选项。
AOF方式 与快照持久化相比AOF 持久化的实时性更好因此已成为主流的持久化方案。默认情况下 Redis 没有开启 AOFappend only file方式的持久化可以通过 appendonly 参数开启
appendonly yes 开启 AOF 持久化后每执行一条会更改 Redis 中的数据的命令Redis 就会将该命令写入到内存缓存 server.aof_buf 中然后再根据 appendfsync 配置来决定何时将其同步到硬盘中的 AOF 文件。 AOF 文件的保存位置和 RDB 文件的位置相同都是通过 dir 参数设置的默认的文件名是 appendonly.aof。 在 Redis 的配置文件中存在三种不同的 AOF 持久化方式它们分别是
appendfsync always #每次有数据修改发生时都会写入AOF文件,这样会严重降低Redis的速度
appendfsync everysec #每秒钟同步一次显式地将多个写命令同步到硬盘
appendfsync no #让操作系统决定何时进行同步为了兼顾数据和写入性能用户可以考虑 appendfsync everysec 选项 让 Redis 每秒同步一次 AOF 文件Redis 性能几乎没受到任何影响。而且这样即使出现系统崩溃用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候Redis 还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。
12.AOF 重写了解吗
当 AOF 变得太大时Redis 能够在后台自动重写 AOF 产生一个新的 AOF 文件这个新的 AOF 文件和原有的 AOF 文件所保存的数据库状态一样但体积更小。 AOF 重写是一个有歧义的名字该功能是通过读取数据库中的键值对来实现的程序无须对现有 AOF 文件进行任何读入、分析或者写入操作。 在执行 BGREWRITEAOF 命令时Redis 服务器会维护一个 AOF 重写缓冲区该缓冲区会在子进程创建新 AOF 文件期间记录服务器执行的所有写命令。当子进程完成创建新 AOF 文件的工作之后服务器会将重写缓冲区中的所有内容追加到新 AOF 文件的末尾使得新的 AOF 文件保存的数据库状态与现有的数据库状态一致。最后服务器用新的 AOF 文件替换旧的 AOF 文件以此来完成 AOF 文件重写操作。 Redis 7.0 版本之前如果在重写期间有写入命令AOF 可能会使用大量内存重写期间到达的所有写入命令都会写入磁盘两次。
13.RDB和AOF如何选择?
RDB 比 AOF 优秀的地方
RDB 文件存储的内容是经过压缩的二进制数据 保存着某个时间点的数据集文件很小适合做数据的备份灾难恢复。AOF 文件存储的是每一次写命令类似于 MySQL 的 binlog 日志通常会必 RDB 文件大很多。当 AOF 变得太大时Redis 能够在后台自动重写 AOF。新的 AOF 文件和原有的 AOF 文件所保存的数据库状态一样但体积更小。不过 Redis 7.0 版本之前如果在重写期间有写入命令AOF 可能会使用大量内存重写期间到达的所有写入命令都会写入磁盘两次。使用 RDB 文件恢复数据直接解析还原数据即可不需要一条一条地执行命令速度非常快。而 AOF 则需要依次执行每个写命令速度非常慢。也就是说与 AOF 相比恢复大数据集的时候RDB 速度更快。
AOF 比 RDB 优秀的地方
RDB 的数据安全性不如 AOF没有办法实时或者秒级持久化数据。生成 RDB 文件的过程是比较繁重的 虽然 BGSAVE 子进程写入 RDB 文件的工作不会阻塞主线程但会对机器的 CPU 资源和内存资源产生影响严重的情况下甚至会直接把 Redis 服务干宕机。AOF 支持秒级数据丢失取决 fsync 策略如果是 everysec最多丢失 1 秒的数据仅仅是追加命令到 AOF 文件操作轻量。RDB 文件是以特定的二进制格式保存的并且在 Redis 版本演进中有多个版本的 RDB所以存在老版本的 Redis 服务不兼容新版本的 RDB 格式的问题。AOF 以一种易于理解和解析的格式包含所有操作的日志。你可以轻松地导出 AOF 文件进行分析你也可以直接操作 AOF 文件来解决一些问题。比如如果执行FLUSHALL命令意外地刷新了所有内容后只要 AOF 文件没有被重写删除最新命令并重启即可恢复之前的状态。
14.Redis常见的部署方式有哪些
单机部署
单机部署是指将Redis部署在单个服务器上通过监听特定端口提供服务。这种方式简单易用适用于小规模应用场景但是容易出现单点故障无法满足高可用性要求。
主从复制部署
主从复制部署是指在主节点上写入数据在从节点上进行复制。通过多个从节点来实现读写分离提高读取性能并且从节点可以作为主节点的备份保证高可用性。
集群部署
集群部署是将Redis实例分布在多个物理节点上通过集群管理器对实例进行管理和调度实现高可用性和横向扩展。集群部署相对于主从复制部署能够提供更高的性能和更好的可扩展性但是需要考虑数据分片和节点之间的网络通信问题。
哨兵部署
哨兵部署是在主从复制基础上增加了哨兵节点来监控主节点状态当主节点宕机时哨兵节点会自动切换从节点为新的主节点。哨兵部署可以提供较高的可用性并且相对于集群部署来说管理和维护成本更低但是对于大规模数据和高并发场景来说性能和可扩展性不如集群部署。
15.主从复制
Redis主从复制是一种数据同步机制其中一个Redis实例作为主节点Master而其他Redis实例则作为从节点Slave来复制主节点的数据。 主节点接收客户端的写操作并将这些写操作的结果通过网络发送给从节点从节点接收这些结果并更新本地数据。这样即使主节点宕机从节点也可以继续提供服务并保持数据的完整性。 在配置Redis主从复制时需要指定主节点的IP地址和端口号并将从节点的配置文件中的slaveof选项设置为主节点的IP地址和端口号。一旦从节点成功连接到主节点它将开始接收主节点的数据并将其存储在本地内存中。 主从复制可以用于多种场景例如
数据备份从节点可以用作主节点数据的备份以避免数据丢失。负载均衡从节点可以用于分担主节点的负载提高系统的性能和稳定性。读写分离主节点可以专注于处理写操作而从节点可以处理读操作以提高系统的并发性能。
需要注意的是主从复制并不是高可用性的解决方案因为当主节点宕机时需要手动切换从节点成为主节点来维护服务的可用性。如果需要高可用性可以使用Redis Sentinel或Redis Cluster。
16.哨兵Sentinel
https://pdai.tech/md/db/nosql-redis/db-redis-x-sentinel.html https://juejin.cn/post/6998564627525140494#heading-13 作用
监控监控所有 Redis 节点的状态。故障转移当哨兵发现主节点下线时会在所有从节点中选择一个作为新的主节点并将所有其他节点的 Master 指向新的主节点。同时已下线的原主节点也会被降级为从节点并修改配置将 Master 指向新的主节点等到它重新上线时就会自动以从节点进行工作。通知当哨兵选举了新的主节点之后可以通过 API 向客户端进行通知。
哨兵的原理 从库发现 对于哨兵的配置我们只需要配置主库的信息哨兵在连接主库之后会调用 INFO 命令获取主库的信息再从中解析出连接主库的从库信息再以此和其他从库建立连接进行监控。 发布/订阅机制 哨兵们在连接同一个主库之后是通过发布/订阅pub/sub模式来发现彼此的存在的。 监控 哨兵在对 Redis 节点建立 TCP 连接之后会周期性地发送 PING 命令给节点默认是 1s以此判断节点是否正常。如果在 down-after-millisenconds 时间内没有收到节点的响应它就认为这个节点掉线了。 主观下线 当哨兵发现与自己连接的其他节点断开连接它就会将该节点标记为主观下线sdown包括主节点、从节点或者其他哨兵都可以标记为 sdown 状态。 客观下线 哨兵确认主节点是否真的宕机这一步成为客观下线确认如果主节点真的宕机了哨兵就会将主节点标记为客观下线odown状态。 客观下线投票过程
当哨兵发现主节点下线标记主节点为 sdown 状态。哨兵向其他哨兵发送 SENTINEL is-master-down-by-addr 命令询问其他哨兵该主节点是否已下线。其他哨兵在收到投票请求之后会检查本地主缓存中主节点的状态并进行回复1 表示下线0 表示正常。发起的询问的哨兵在接收到回复之后会累加“下线”的得票数。当下线的票数大于一半哨兵数量并且不小于 quorum 时就会将主节点标记为 odown 状态。并开始准备故障转移发起投票的哨兵有一个投票倒计时倒计时结束如果票数仍然不够的话则放弃本次客观线下投票。并尝试继续与主节点建立连接。
17.Redis cluster
Redis Cluster 是 Redis 的分布式实现允许您将 Redis 在多个节点之间水平扩展提供高可用性和自动数据分片。Redis Cluster 自动将数据分配到多个节点上这有助于分配负载并增加应用程序的吞吐量。 Redis Cluster 使用一种称为哈希槽的分片算法它允许将每个键分配给集群中的特定节点。这确保每个节点仅存储数据的一个子集从而更容易扩展和管理 Redis 数据库。 Redis Cluster 支持主从复制模型其中每个主节点有一个或多个从节点。主节点负责处理读写操作而从节点复制主节点的数据并作为热备份在主节点故障时可以立即接替主节点的功能。 Redis Cluster 还提供自动故障转移当主节点失败时将自动替换为其中一个从节点。这有助于确保高可用性并在节点故障时防止数据丢失。
18.哈希分区算法有哪些
CRC16算法Redis cluster默认的哈希分区算法是CRC16算法它是一种快速的哈希算法具有良好的分布性和低碰撞率。在Redis cluster中每个键都会被CRC16算法映射到一个16位整数上然后根据这个整数对节点数取模得到该键所在的节点。CRC32算法Redis cluster也支持CRC32算法作为哈希分区算法它是一种更为复杂的哈希算法具有更好的随机性和更低的碰撞率。在Redis cluster中使用CRC32算法需要手动设置。MD5算法Redis cluster还支持MD5算法作为哈希分区算法它是一种更为安全的哈希算法具有很高的随机性和很低的碰撞率。在Redis cluster中使用MD5算法需要手动设置。
不同的哈希分区算法适用于不同的场景CRC16算法在性能和效果上都有良好的表现因此是Redis cluster默认的哈希分区算法。如果需要更高的哈希分布性和更低的碰撞率可以考虑使用CRC32算法或MD5算法。
19.过期键的删除策略
常用的过期数据的删除策略就两个重要自己造缓存轮子的时候需要格外考虑的东西
惰性删除 只会在取出 key 的时候才对数据进行过期检查。这样对 CPU 最友好但是可能会造成太多过期 key 没有被删除。定期删除 每隔一段时间抽取一批 key 执行删除过期 key 操作。并且Redis 底层会通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响。
定期删除对内存更加友好惰性删除对 CPU 更加友好。两者各有千秋所以 Redis 采用的是 定期删除惰性/懒汉式删除。但是仅仅通过给 key 设置过期时间还是有问题的。因为还是可能存在定期删除和惰性删除漏掉了很多过期 key 的情况。这样就导致大量过期 key 堆积在内存里然后就 Out of memory 了。 怎么解决这个问题呢答案就是Redis 内存淘汰机制。
20.内存淘汰策略有哪些
Redis 提供 6 种数据淘汰策略
volatile-lruleast recently used从已设置过期时间的数据集server.db[i].expires中挑选最近最少使用的数据淘汰volatile-ttl从已设置过期时间的数据集server.db[i].expires中挑选将要过期的数据淘汰volatile-random从已设置过期时间的数据集server.db[i].expires中任意选择数据淘汰allkeys-lruleast recently used当内存不足以容纳新写入数据时在键空间中移除最近最少使用的 key这个是最常用的allkeys-random从数据集server.db[i].dict中任意选择数据淘汰no-eviction禁止驱逐数据也就是说当内存不足以容纳新写入数据时新写入操作会报错。这个应该没人使用吧
4.0 版本后增加以下两种
volatile-lfuleast frequently used从已设置过期时间的数据集server.db[i].expires中挑选最不经常使用的数据淘汰allkeys-lfuleast frequently used当内存不足以容纳新写入数据时在键空间中移除最不经常使用的 key。
21.如何保证缓存与数据库双写时的数据一致性
https://juejin.cn/post/6850418121754050567#comment
22.缓存穿透
缓存穿透说简单点就是大量请求的 key 是不合理的根本不存在于缓存中也不存在于数据库中 。这就导致这些请求直接到了数据库上根本没有经过缓存这一层对数据库造成了巨大的压力可能直接就被这么多请求弄宕机了。 解决办法 最基本的就是首先做好参数校验一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库 id 不能小于 0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等。
23.缓存雪崩
缓存在同一时间大面积的失效导致大量的请求都直接落到了数据库上对数据库造成了巨大的压力。 这就好比雪崩一样摧枯拉朽之势数据库的压力可想而知可能直接就被这么多请求弄宕机了。 针对 Redis 服务不可用的情况
采用 Redis 集群避免单机出现问题整个缓存服务都没办法使用。限流避免同时处理大量的请求。
针对热点缓存失效的情况
设置不同的失效时间比如随机设置缓存的失效时间。缓存永不失效不太推荐实用性太差。设置二级缓存。
缓存雪崩和缓存击穿有什么区别
缓存雪崩和缓存击穿比较像但缓存雪崩导致的原因是缓存中的大量或者所有数据失效缓存击穿导致的原因主要是某个热点数据不存在与缓存中通常是因为缓存中的那份数据已经过期
24.缓存击穿
缓存击穿中请求的 key 对应的是 热点数据 该数据 存在于数据库中但不存在于缓存中通常是因为缓存中的那份数据已经过期 。这就可能会导致瞬时大量的请求直接打到了数据库上对数据库造成了巨大的压力可能直接就被这么多请求弄宕机了。
有哪些解决办法
设置热点数据永不过期或者过期时间比较长。针对热点数据提前预热将其存入缓存中并设置合理的过期时间比如秒杀场景下的数据在秒杀结束之前不过期。请求数据库写数据到缓存之前先获取互斥锁保证只有一个请求会落到数据库上减少数据库的压力。
缓存穿透和缓存击穿有什么区别
缓存穿透中请求的 key 既不存在于缓存中也不存在于数据库中。 缓存击穿中请求的 key 对应的是 热点数据 该数据 存在于数据库中但不存在于缓存中通常是因为缓存中的那份数据已经过期
25.Redis 怎么实现消息队列?
1List 结构2Pub/Sub 模式3Stream 结构 https://mp.weixin.qq.com/s/_q0bI62iFrG8h-gZ-bCvNQ
26.pipeline的作用
Redis Pipeline是一种优化Redis批量查询的技术。它允许客户端将多个Redis命令一次性发送给Redis服务器而不需要等待每个命令的响应。这样可以减少客户端与服务器之间的往返通信从而提高Redis的性能。 具体来说Redis Pipeline的工作原理如下
客户端将多个Redis命令打包成一个请求。客户端将打包后的请求发送给Redis服务器。Redis服务器收到请求后不立即执行而是将请求缓存起来。Redis服务器按照请求的顺序逐一执行请求并将执行结果保存在缓存中。客户端最终一次性接收所有命令的执行结果。
相比于单独发送每个Redis命令使用Pipeline可以极大地减少通信延迟和网络带宽从而提高Redis的吞吐量。在一些需要批量查询Redis的场景下使用Pipeline可以显著提高应用程序的性能。
27.LUA脚本
减少网络开销在 Lua脚本 中可以把多个命令放在同一个脚本中运行原子操作Redis 会将整个脚本作为一个整体执行中间不会被其他命令插入编写脚本过程中无需担心会出现竞态条件复用性客户端发送的脚本会永远存储在 Redis中意味着其他客户端可以复用这一脚本。
28.什么时候使用pipeline什么时候使用lua
当多个redis命令之间没有依赖、顺序关系例如第二条命令依赖第一条命令的结果时建议使用pipline如果命令之间有依赖或顺序关系时pipline就无法使用此时可以考虑才用lua脚本的方式来使用。
28.什么是RedLock?
在RedLock中多个客户端通过竞争获取一个分布式锁只有获得锁的客户端才能够执行对共享资源的访问。为了防止分布式环境中出现单点故障RedLock采用了多个Redis实例来存储锁信息并且在获取锁时需要占用大多数Redis实例的锁才能成功获取锁从而保证了分布式锁的可靠性和高可用性。
29.Redis单线程理解
RedLock是基于redis实现的分布式锁它能够保证以下特性
互斥性在任何时候只能有一个客户端能够持有锁避免死锁当客户端拿到锁后即使发生了网络分区或者客户端宕机也不会发生死锁利用key的存活时间容错性只要多数节点的redis实例正常运行就能够对外提供服务加锁或者释放锁
RedLock算法思想意思是不能只在一个redis实例上创建锁应该是在多个redis实例上创建锁n / 2 1必须在大多数redis节点上都成功创建锁才能算这个整体的RedLock加锁成功避免说仅仅在一个redis实例上加锁而带来的问题。
30.lO多路复用
Redis 采用了多路复用机制使其在网络 IO 操作中能并发处理大量的客户端请求实现高吞吐率。 其实 Redis 是利用上Linux 中的 IO 多路复用机制 Linux 中的 IO 多路复用机制是指一个线程处理多个 IO 流。 简单来说在 Redis 只运行单线程的情况下该机制允许内核中同时存在多个监听套接字和已连接套接字。 内核会一直监听这些套接字上的连接请求或数据请求。一旦有请求到达就会交给 Redis 线程处理这就实现了一个 Redis 线程处理多个 IO 流的效果。
