Redis面试知识点1. Redis为什么是单线程的； 2. Redis有几种持久化方式； 3. Redis有哪些数据结

1. Redis为什么是单线程的

Redis 之所以被称为单线程数据库，是因为 Redis 主要采用单线程的事件循环模型来处理客户端请求和数据操作。这可能会让人感到疑惑，因为单线程通常被认为性能较差，无法充分利用多核处理器。然而，Redis 的单线程设计在特定情况下有一些优势，如下所述：

避免锁竞争：在传统的多线程数据库中，多个线程可能会同时访问和修改共享数据，导致复杂的锁竞争和并发控制问题。Redis 的单线程模型避免了这些问题，因为它的所有操作都是顺序执行的，不需要复杂的锁机制。
避免上下文切换：在多线程环境下，线程的切换和调度会引入上下文切换的开销，这可能降低系统性能。由于 Redis 是单线程的，所以避免了大量的上下文切换，从而在一些情况下实现更高的性能。
内存访问效率： Redis 的主要性能瓶颈通常是内存访问速度，而不是 CPU 的计算能力。由于 Redis 以内存为主的数据库，单线程模型在内存操作上表现良好，不会因为多线程而引入额外的开销。

然而，需要注意的是，虽然 Redis 的核心执行是单线程的，但 Redis 在某些场景下可以利用多个线程来执行一些后台任务，例如持久化数据到磁盘、复制数据到其他节点、网络IO等。此外，Redis 也提供了一些并发处理的机制，如使用多个实例来处理更多的并发请求。

总之，Redis 的单线程设计是为了简化并发控制和减少锁竞争，而不是为了充分利用多核处理器。这使得 Redis 在某些情况下能够实现出色的性能和可预测的行为。

2. Redis有几种持久化方式

Redis 支持两种主要的持久化方式，这两种方式可以将数据持久化到磁盘，以防止数据在内存中丢失：

快照（Snapshot）持久化：快照持久化是将 Redis 在某个时间点的数据状态保存到磁盘中，创建一个数据的快照。这种方式可以通过定期创建快照文件，或者在配置文件中设置阈值来触发。快照持久化的文件格式是二进制的 RDB 文件，包含了 Redis 数据的完整快照。虽然这种方式对于恢复数据状态很有用，但是如果在快照之间发生系统崩溃，那么可能会丢失最后一个快照之后的数据。
追加文件（Append-Only File）持久化：追加文件持久化是将 Redis 的操作日志以追加的方式写入到磁盘文件中。每个写操作都会被追加到一个日志文件中，这样就可以通过重新执行这些写操作来恢复数据状态。追加文件持久化可以通过配置文件开启，这样即使系统在快照之间发生崩溃，也能够通过日志文件重新构建数据。这种方式较为耗费磁盘空间，并且相比于快照方式，写入性能可能会稍微降低，因为每次写操作都需要写入到磁盘。

除了上述两种主要的持久化方式，Redis 还提供了混合持久化的选项，允许同时使用快照和追加文件方式。这样可以在一定程度上兼顾快照和实时日志的优势。

在使用 Redis 持久化时，需要根据应用的特点和需求选择适合的方式。快照持久化适用于需要定期备份数据的情况，而追加文件持久化适用于需要更高的数据恢复可靠性和实时性的情况。

3. Redis有哪些数据结构

Redis支持多种数据结构，每种数据结构都具有不同的特点和用途。以下是一些常见的Redis数据结构以及它们适用的业务场景：

字符串（String）：字符串是最基本的数据结构，可以存储文本、数字等。适用于缓存、计数器、短时数据存储等场景。
哈希（Hash）：哈希存储了字段和值之间的映射，类似于关联数组。适用于存储对象、用户属性、缓存项等，可以方便地访问和修改单个字段。底层实现上类似于Java中的HashMap，都采用了散列表（哈希表）结合链表的方式来解决哈希冲突的问题。Redis做了优化，当Hash中的键值对数量较少时，为了节省内存，会采用特殊的编码方式（例如zipmap）来紧凑存储键值对；当数量增多时，则转换为真正的哈希表结构，即数组加链表的形式。
列表（List）：列表是有序的字符串列表，可以在列表的两端进行插入、删除等操作。适用于实现消息队列、实时日志、最近活动列表等场景。底层实现上类似于Java中的LinkedList，它们都是基于双向链表结构实现的，Redis做了优化，当List中的元素数量较少且元素大小较小的情况下，Redis可能会选择使用ziplist（压缩列表）作为底层实现，这样可以节省空间并提高处理效率。但一旦超过一定的条件限制，List就会转为使用双向链表来存储数据。
集合（Set）：集合是无序且不重复的字符串集合，支持交集、并集、差集等操作。适用于标签系统、关注列表、好友关系等场景。底层实现上类似于Java中的HashSet。
有序集合（Sorted Set）：有序集合在集合的基础上为每个成员关联一个分数，通过分数排序。适用于排行榜、范围查询、优先级队列等场景。底层是由哈希表（Hash）和跳跃表（Skip List）这两种数据结构来实现的。
位图（Bitmap）：位图是一系列的位操作，可以用来表示某些状态，如用户在线状态、签到情况等。适用于存储位操作相关的数据。
地理空间（Geo）：地理空间数据结构可以存储地理位置的经纬度信息，并支持查找附近的位置。适用于地理位置服务、附近搜索等场景。
超级日志（HyperLogLog）：超级日志是用于估算集合基数（不重复元素数量）的数据结构，占用空间较小。适用于统计独立用户数、页面浏览数等场景。

这些数据结构在不同场景下可以灵活组合和使用，以满足各种应用程序的需求。选择合适的数据结构有助于提高性能、降低存储成本，并简化应用程序的开发和维护。

4. 什么是缓存穿透

缓存穿透是指在缓存系统中，频繁查询一个不存在于缓存中的数据，从而导致每次查询都必须请求数据库，造成数据库负担过重。这种情况通常发生在恶意攻击、大量无效请求或数据更新不及时的情况下。

缓存穿透会导致以下问题：

数据库压力增大：由于每次查询都需要访问数据库，会导致数据库的负载大幅增加，可能引发性能问题。
响应时间延长：由于缓存未命中，每次查询都要请求数据库，导致响应时间延长，影响用户体验。

解决缓存穿透的常见方案包括：

缓存空对象或错误信息：当数据库中不存在某个键对应的值时，可以将这种情况也缓存起来，即缓存一个特定的空对象或错误信息。这样，在下一次查询时，如果发现缓存中存在这个空对象或错误信息，就不再请求数据库，从而避免频繁的无效查询。
热点数据预加载：针对可能的热点数据，可以在应用启动时或定期进行预加载，将这些数据提前存入缓存，从而减少缓存未命中的可能性。
设置短期缓存过期时间：对于一些预期会被频繁访问的数据，可以设置短期缓存过期时间，确保数据在缓存中不会长时间保持不变，即使数据发生变化，也能够及时更新到缓存中。
限流和验证：在缓存层面对请求进行限流，防止频繁请求造成的负担。另外，可以在应用层对请求进行验证，排除恶意攻击或无效请求。

5. 什么是缓存击穿

缓存击穿是一种缓存使用场景中的性能问题，它发生在一个热点数据项被频繁地请求，但在缓存中却不存在（缓存失效），从而导致大量的请求直接访问底层数据存储，造成数据库负载剧增，影响系统性能。

这种情况通常发生在以下情况下：

热点数据失效：当一个非常热门的数据项的缓存过期，而在缓存失效期间，有大量的请求同时访问这个数据项，导致缓存失效瞬间引发大量对底层数据存储的请求。
首次访问：当应用程序启动或重新部署后，热门数据项的缓存为空，导致首次访问的请求直接穿透到底层数据存储。

为了解决缓存击穿问题，可以采取以下一些解决方案：

热点数据永不过期：对于非常热门的数据项，可以设置缓存永不过期，或者过期时间设得很长，这样可以减少缓存失效的频率。
预加载：在系统启动或空闲时，预先加载热点数据到缓存中，以防止首次访问时的缓存穿透问题。
互斥锁（Mutex Lock）：当检测到某个数据项的缓存失效时，可以使用互斥锁来保证只有一个线程去更新缓存，而其他线程等待更新完成后再获取缓存。
分布式锁：在分布式系统中，可以使用分布式锁来控制只有一个节点进行缓存的更新操作，防止多个节点同时重建缓存。
空值缓存：即使底层数据不存在，也将空值（null）缓存起来一段时间，以防止大量请求穿透到底层数据存储。
基于事件的缓存更新：当缓存失效时，先从底层数据存储中获取数据，然后将数据写入缓存。这可以避免多个请求同时更新缓存。
使用CDN或反向代理：对于某些静态数据或页面，可以使用CDN或反向代理来缓存，减少请求直接到达应用服务器。

选择适当的解决方案取决于具体的应用场景和需求，通常结合多种策略可以有效地解决缓存击穿问题。

6. 什么是缓存雪崩

缓存雪崩是指在缓存中大量的缓存数据同时失效或者被清除，导致大量的请求直接访问数据库或其他后端系统，造成系统性能急剧下降甚至崩溃的现象。这通常发生在缓存中的数据过期时间设置相近，然后在同一时间点同时失效，导致大量的请求集中访问后端系统。

造成缓存雪崩的原因可能包括：

缓存数据过期时间集中：如果大量的缓存数据设置了相同的过期时间，那么在这些数据过期时可能会出现大量请求访问后端系统。
服务器重启或宕机：当缓存服务器发生重启或宕机，导致所有缓存数据都失效，可能会导致大量请求直接访问后端系统。
缓存层故障：缓存系统发生故障，导致无法正常提供缓存服务，请求也会直接访问后端系统。

为了应对缓存雪崩问题，可以采取以下一些解决方案：

设置随机的过期时间：将缓存数据的过期时间设置成随机的，避免大量数据在同一时间点失效。
使用持久化缓存：使用持久化缓存，即使缓存服务器重启或宕机，数据也能从持久化存储中恢复，减少失效的可能性。
缓存预加载：提前在缓存中加载数据，避免在请求到来时才去加载缓存数据，从而分散访问压力。
分布式缓存：将缓存数据分布到多个缓存节点中，减少单点故障的风险，避免整个缓存层的故障。
限流和降级：在缓存失效时，可以通过限制请求的流量或者降级功能，避免大量请求同时访问后端系统。
监控和报警：设置监控和报警机制，及时发现缓存失效情况，采取相应的应对措施。

综合使用这些解决方案，可以有效减少缓存雪崩带来的影响，保障系统的稳定性和性能。

7. Redis 事务机制

Redis的事务机制允许将多个操作打包成一个原子操作，即要么所有操作都成功执行，要么全部都不执行。Redis的事务机制是通过MULTI、EXEC、DISCARD和WATCH等命令来实现的。以下是Redis事务机制的基本概念和命令：

MULTI：事务的开始，该命令标记一个事务块的开始。
EXEC：执行事务，将之前在MULTI和EXEC之间的命令执行为一个原子操作。
DISCARD：放弃事务，取消事务块，清除之前在MULTI和EXEC之间的命令。
WATCH：监视一个或多个键，如果在事务执行期间这些键被修改，则事务会被取消。

事务的使用步骤如下：

使用MULTI命令开始一个事务块。
在MULTI和EXEC之间，执行要包含在事务中的命令，这些命令不会立即执行，而是在EXEC命令执行时一起执行。
如果需要取消事务，可以使用DISCARD命令。
如果需要提交事务，可以使用EXEC命令，Redis会依次执行在MULTI和EXEC之间的命令。
如果在事务执行期间，被监视的键发生了变化，事务会被取消。

需要注意的是，Redis的事务机制并不同于传统数据库的事务，它不支持回滚和隔离级别。事务块中的命令在EXEC执行时会一次性执行，但如果在事务执行过程中发生了错误，错误信息会被记录，但不会影响后续命令的执行。

Redis的事务适用于需要一系列命令作为一个原子操作来执行的场景，但要注意它的一些限制和特性，以及与传统数据库事务的差异。

8. Redis怎么实现分布式锁

在Redis中实现分布式锁是一个常见的应用场景，可以确保在分布式环境下只有一个客户端可以访问共享资源。以下是一种常见的基于Redis的分布式锁实现方法：

使用SETNX命令：

获取锁：客户端通过执行SETNX命令（SET if Not eXists）来设置一个特定的键作为锁，只有在键不存在的情况下才会设置成功，表示获取锁成功。客户端可以设置一个过期时间，以免锁因为某种原因没有被释放而永远占用。
释放锁：当客户端完成任务后，通过删除该键来释放锁，以允许其他客户端获取锁。

这种实现方法的关键在于 SETNX 命令的原子性，它保证只有一个客户端可以成功地设置锁。然而，这种简单的实现方法可能会存在一些问题，如死锁、误解锁等。因此，在使用分布式锁时需要考虑以下一些因素：

锁超时：设置锁时可以设置一个超时时间，确保即使持有锁的客户端发生故障，锁也会在一定时间后自动释放。
防止误解锁：可以在锁的值中加入唯一的标识，以确保只有持有锁的客户端才能释放锁。
续约机制：在锁的有效期内，可以定期延长锁的超时时间，以避免任务执行时间过长导致锁自动释放。
分布式环境下的时间问题：由于分布式系统的时钟不一致，锁的超时时间和判断是否持有锁的操作需要使用相对时间或者使用更加精确的时钟同步方法。

总之，通过Redis的SETNX命令可以实现基本的分布式锁。然而，在实际应用中需要考虑分布式环境的复杂性和一致性问题，以确保分布式锁的正确性和可靠性。如果需要更加稳定和复杂的分布式锁实现，可以考虑使用基于Redis的分布式锁库，如Redlock、Redission等。

9. Redis如何做内存优化

合理设置最大内存限制：在Redis配置文件中，可以通过设置maxmemory参数来限制Redis使用的最大内存。这有助于防止Redis占用过多内存而导致系统性能下降。
使用合适的数据结构：选择合适的数据结构可以节省内存。例如，使用哈希结构存储对象属性，使用位图存储标志状态等。
压缩数据： Redis支持字符串的压缩，可以通过开启字符串压缩选项来减少内存使用。不过，压缩会增加CPU负载，需要权衡。
删除过期数据： Redis支持设置过期时间，可以自动删除过期数据，释放内存。这需要根据业务需求设置合适的过期时间。
使用适当的内存淘汰策略： Redis提供了多种内存淘汰策略，如LRU（最近最少使用）、LFU（最不常用）等，根据业务情况选择合适的策略。
使用分片： Redis支持分片，将数据分散到多个Redis实例中，每个实例占用的内存较少，有助于分担内存负担。
持久化配置：如果开启了持久化，可以合理配置快照和追加文件的策略，避免频繁写入磁盘导致内存膨胀。
使用内存分配器： Redis支持多种内存分配器，可以根据实际情况选择合适的分配器，以优化内存使用效率。
避免大键和大值：避免存储过大的键和值，尽量拆分为更小的数据单元。
监控和优化：使用Redis内置的监控工具，如INFO命令、Redis CLI等，定期监控内存使用情况，及时发现并处理内存泄漏和内存溢出问题。

10. Redis的过期策略

Redis的过期策略用于在某些条件下自动删除已过期的键，以释放内存空间。Redis提供了多种过期策略来管理过期键的删除。以下是一些常见的过期策略：

定时过期（Timer）： Redis会在每个键的过期时间设置时创建一个定时器，在过期时间到达时删除该键。这是一种实时过期策略，适用于需要精确控制过期时间的情况。
惰性过期（Lazy Expiration）： Redis在访问某个键时，会先检查键是否过期，如果过期则删除键。这种策略会在访问时检查过期键，避免了不必要的内存消耗，但可能导致过期键未及时删除。
定期过期（Expire Scan）： Redis会每隔一段时间（默认100毫秒）随机抽取一些键，并检查是否过期，过期的键会被删除。这种策略在处理大量过期键时有一定的效率，但仍然存在漏掉过期键的可能性。
定期淘汰（Eviction）：当内存占用达到设定的最大内存限制时，Redis会根据一些淘汰算法（如LRU、LFU等）删除键，从而腾出空间。这并不是严格意义上的过期策略，但在某种程度上可以减少内存占用。

通常情况下，Redis会综合使用定时过期、惰性过期和定期淘汰等策略来管理过期键。在实际应用中，可以根据业务场景和需求选择合适的过期策略。需要注意的是，虽然Redis会自动处理过期键，但过期键的实际删除可能会因为Redis的内部策略、配置参数和系统负载等因素而有所不同。

11. Redis的内存淘汰策略

Redis的内存淘汰策略用于在内存占用达到设定的最大内存限制时，选择一些键进行删除，以释放空间。Redis提供了多种内存淘汰策略，每种策略都有不同的算法来决定哪些键会被优先删除。以下是一些常见的内存淘汰策略：

LRU（Least Recently Used）：最近最少使用策略，即优先删除最近最少被访问的键。当内存不足时，会删除最久未被访问的键，以腾出空间。
LFU（Least Frequently Used）：最不常用策略，即优先删除被访问次数最少的键。这种策略适用于需要频繁访问的键，以保留较少访问的键。
Random：随机策略，即随机选择要删除的键。这种策略简单，但可能导致某些键被频繁删除，而另一些键很少被删除。
TTL（Time To Live）：过期时间策略，即优先删除已过期的键。这种策略适用于需要及时释放过期键的情况。
淘汰数量固定策略： Redis可以设置在一次淘汰操作中删除的键的数量，以便更精确地控制内存释放。

需要注意的是，不同的内存淘汰策略适用于不同的场景和需求。选择合适的策略需要考虑到业务的特点、访问模式以及对内存占用的要求。可以通过在Redis配置文件中设置maxmemory-policy参数来选择所需的淘汰策略。同时，Redis也支持自定义的淘汰策略，通过编写Lua脚本来实现特定的淘汰算法。

12. Redis的常用应用场景

Redis作为一个高性能的内存数据存储系统，具有快速读写、持久性、数据结构多样性等特点，广泛应用于各种应用场景。以下是一些常见的Redis应用场景：

缓存： Redis最常见的应用场景之一就是缓存。通过将热门数据存储在Redis中，可以大幅提高应用程序的读取性能，减轻数据库的压力。
会话存储： Redis可以用于存储用户会话数据，例如登录状态、购物车信息等。由于Redis的快速读写能力，它在处理会话存储方面非常高效。
排行榜和计数器： Redis的有序集合（Sorted Set）和计数器等数据结构非常适合实现排行榜、点赞数、访问次数等功能。
实时消息传递： Redis的发布/订阅（Pub/Sub）机制使其成为构建实时消息传递系统的良好选择，可以用于聊天应用、通知系统等。
任务队列： Redis可以用作任务队列，通过将任务放入队列中，多个工作者（workers）可以从队列中获取任务并执行，适用于异步任务处理。
地理位置服务： Redis的地理空间数据结构可以用于存储地理位置信息，并支持查询附近的位置，适用于地图应用、附近搜索等。
分布式锁： Redis可以用于实现分布式锁，确保在分布式系统中只有一个客户端可以访问共享资源。
缓存预热：在系统启动或低峰期，可以预先将热门数据加载到Redis中，以提高系统性能。
反爬虫限流： Redis可以用于限制同一IP或用户在一定时间内的访问频率，以应对恶意爬虫行为。
延迟队列： Redis的有序集合可以用于实现延迟队列，即将任务以延迟时间作为权重存储在有序集合中，工作者从集合中获取任务并执行。

总之，Redis在各种应用场景中都发挥着重要作用，其快速的读写能力和多样的数据结构使得它成为构建高性能、实时、可扩展的应用程序的理想选择。

13. Redis的主从模式

Redis的主从模式是一种用于数据复制和高可用性的架构，允许多个Redis实例之间建立一个主从关系，其中一个实例充当主服务器（master），而其他实例充当从服务器（slaves）。主从模式有助于数据备份、故障恢复和读写分离等需求。

以下是Redis主从模式的主要特点和工作方式：

数据复制：主服务器将数据写入到自己的数据库中，然后通过异步的方式将写操作传播到从服务器，使从服务器的数据与主服务器保持一致。
读写分离：通过将主服务器用于写操作，从服务器用于读操作，可以分摊读写压力，提高系统的读写性能。
高可用性：如果主服务器发生故障，从服务器可以接管成为新的主服务器，从而实现故障转移，提高系统的可用性。
数据备份：从服务器可以用于备份数据，以防止主服务器数据丢失。
异步复制：默认情况下，Redis主从复制是异步的，即主服务器写入数据后，并不立即等待从服务器确认。这可以提高性能，但可能导致主从数据不一致。
全量复制和增量复制：初次复制时，从服务器会进行全量复制，即复制所有主服务器的数据。之后的复制是增量复制，只复制发生变化的数据。
复制链：从服务器也可以充当其他从服务器的主服务器，从而构建复制链。这种链式复制可以在多个级别上实现数据的传播。
可配置性： Redis主从复制可以配置为只复制特定的数据库、特定的数据类型等，以满足不同需求。

需要注意的是，Redis主从复制是异步的，这意味着从服务器可能会因为网络故障或其他原因导致数据滞后，从而导致数据不一致。为了确保数据一致性，可以使用Redis的复制延迟监控、持久化等手段。另外，Redis 6.0版本引入了支持半同步复制的功能，以提高数据可靠性。

Redis的主从模式在提供高可用性和扩展性方面有很大帮助，但在配置和管理时需要考虑数据一致性和复制延迟等问题。

14. Redis的哨兵模式

Redis的哨兵模式是一种用于监控和自动故障转移的架构，用于提高Redis系统的高可用性。在哨兵模式中，有一组特殊的Redis实例称为"哨兵"，它们负责监控主服务器和从服务器的状态，当主服务器发生故障时，哨兵可以自动将一个从服务器提升为新的主服务器，以实现故障转移。

以下是Redis哨兵模式的主要特点和工作方式：

监控：哨兵会周期性地检查所有主服务器和从服务器的状态，包括是否存活、是否正常运行等。
自动故障转移：当哨兵检测到主服务器不可用时，它会选举一个新的主服务器，然后将其他从服务器切换为新的主服务器的从服务器，从而实现故障转移。
配置更新：如果主服务器发生故障，哨兵会更新所有客户端的连接配置，以指向新的主服务器，从而实现无感知的故障切换。
多哨兵支持：可以在Redis集群中部署多个哨兵，这些哨兵会协同工作来监控和管理主从服务器。
提供监控信息：哨兵可以提供有关主从服务器状态、故障转移历史等信息，以供监控和管理。
配置自动化：哨兵模式可以在一定程度上实现自动化的故障转移和节点管理，减少人工干预。

需要注意的是，哨兵模式虽然提供了一定的高可用性，但在故障转移过程中仍然可能出现数据不一致或数据丢失的情况。为了进一步提高可靠性，可以使用持久化、数据备份等手段。另外，哨兵模式适用于较小规模的Redis集群，对于更大规模的集群，可以考虑使用Redis Cluster。

Redis哨兵模式是为了应对单点故障和提高系统的可用性而设计的，但在配置和管理时需要考虑到故障转移的延迟、数据一致性和监控等问题。

15. Redis的集群模式

Redis的集群模式是一种用于构建高可用性和分布式的数据存储架构，通过将多个Redis节点组成一个集群，实现数据分片、负载均衡和故障转移等功能。Redis Cluster提供了自动分片和节点管理功能，使得在分布式环境下使用Redis更加方便和可靠。

以下是Redis集群模式的主要特点和工作方式：

自动分片： Redis Cluster会将数据自动分成多个槽（slot），每个槽对应一个节点。这样，集群中的每个节点都只负责管理一部分数据，实现了数据分片。
节点故障转移：当某个节点发生故障时，Redis Cluster会自动进行故障转移，将故障节点的槽分配给其他正常节点，从而实现高可用性。
负载均衡：客户端可以通过Redis Cluster提供的路由机制，将请求均匀地分发到集群中的不同节点上，实现负载均衡。
节点管理： Redis Cluster支持自动添加和移除节点，使得集群的扩展和缩减变得更加容易。新节点加入集群后，数据会自动迁移。
数据复制： Redis Cluster中的每个节点都有多个复制节点，用于实现数据的备份和高可用性。每个主节点会有1个或多个从节点，实现数据冗余。
节点通信：集群中的节点通过Gossip协议进行通信，用于检测节点状态、故障检测和配置更新等。
客户端支持：使用Redis Cluster，客户端可以透明地访问集群中的不同节点，而无需手动管理节点。

Redis集群模式在处理大规模数据、提高系统可用性和性能方面具有很大优势，但在配置和管理时也需要考虑到数据一致性、故障转移的延迟等问题。使用Redis Cluster可以有效地构建分布式系统，但也需要了解其特性和限制，以适应不同的业务需求。

16. Redis为什么这么快？

内存存储 Redis 是基于内存操作的数据库，不论读写操作都是在内存上完成的，直接访问内存的速度远比访问磁盘的速度要快多个数量级。 备注：内存访问一次大概120ns（微秒），SSD 硬盘访问一次50-150us（纳秒），如果按照访问一次150us来算，性能差距在1000倍。这是因为1us等于1000ns。所以，150微秒是150,000纳秒，而120纳秒只是150微秒的一千分之一。
数据结构 Redis 提供了多种高效的数据结构，如字符串、哈希、列表、集合等，这些专门优化过的数据结构支持高效的读写操作。 具体来说，字符串结构，作者底层使用简单动态字符串（SDS）替换传统字符串，内部有一个 len 字段记录了字符串长度：实现了 O(1) 复杂度的 strlen 操作，并保证了二进制安全性。以及 Redis 在内部针对区分了多种 SDS 类型，不同大小的字符串会对应不同的 SDS 实现，有效的节省内存。另外值得一说的是，Redis 中的 ZSet 会在数据较多的时候使用跳表实现。跳表是一种基于链表实现的数据结构，它可以通过具有多级索引的方式来加速查找元素。相比起正常的列表，它在插入、删除和搜索时都具备 O(logn) 的复杂度，并且相比起树实现起来更加简单。
非阻塞 IO Redis 基于 IO 多路复用实现了非阻塞式 IO，采用 IO 多路复用技术，并发处理连接。通过 epoll 模型和自己实现的简单的事件框架，将 epoll 中的读、写、关闭、连接都转化成了事件，然后利用 epoll 的多路复用特性，把 IO 操作时间优化到了极致。
线程模型 Redis 把所有主线操作使用单线程模型，将网络 IO 以及指令读写全部交由一个线程来执行。这样可以带来避免线程创建而导致的性能消耗，多线程上下文切换而引起的 CPU 开销，以及避免了多个线程之间的竞争问题，比如临界区资源的线程安全、锁的申请、释放以及死锁等问题。