Redis默认存储引擎到底是啥，怎么用才更顺手呢？

Redis的默认存储引擎就是内存，你把数据交给Redis，它首先（并且主要）就是把数据放在服务器的内存里，这是它速度极快、能达到每秒数十万次操作的根本原因，它不像MySQL那样，数据默认就老老实实写在硬盘文件里，你可以把它理解成一个超高性能的、放在内存中的“大字典”或“大地图”。

光把数据放内存里,万一服务器重启或者断电，所有数据不就全没了吗？是的，所以这就引出了“持久化”的概念，Redis提供了两种主要的持久化方式，把内存里的数据备份到硬盘上，但这并不是默认开启的，需要你根据需求去配置，这就像是，Redis默认在工作时全用脑子记（内存），但你可以让它养成习惯，时不时用笔记本（硬盘）抄写一份。

两种主要的“抄写”方式（持久化）：

1. RDB（快照）：在特定的时间间隔，比如每隔1小时，或者当有1000个新键被创建时，Redis会把当前内存里完整的数据“拍一张照片”，生成一个压缩过的二进制文件（默认叫 dump.rdb）存到硬盘，这个文件很小，恢复起来也快，但问题是，如果两次拍照之间服务器挂了，你会丢失这段时间内的所有新数据。
2. AOF（追加日志）：这种方式更像记日记，Redis会把每一个会修改数据的命令（SET, HSET）都原样记录下来，追加到一个日志文件的末尾，当Redis重启时，它会把日记从头到尾“重演”一遍，来恢复数据，这样数据安全性高，最多丢失一秒的数据（可配置），但日志文件会很大，恢复速度也比RDB慢。

根据Redis官方文档的说明,在早期版本，默认是不开启任何持久化的，这纯粹就是一个内存缓存，但后来，为了数据安全考虑，从Redis 7.0版本开始，默认的持久化配置变成了同时开启RDB和AOF（但AOF默认不主动触发重写，文件可能会增长），它的核心工作模式依然是：所有读写操作首先在内存中完成，持久化是异步的后台任务。

怎么用才更顺手？几个关键点：

1. 明确它的定位，别当普通数据库用：Redis最顺手的场景是缓存和高速读写存储，比如存储会话（Session）、热门文章列表、排行榜、秒杀库存等，不要把它当成MySQL的替代品，用来存所有用户的核心资料，把它当作你应用前端的“闪电内存工作区”。
2. 一定要设置过期时间：对于缓存数据，绝大多数情况都应该使用 EXPIRE 命令或 SET key value EX seconds 来设置一个合理的过期时间，这是防止无用数据占满内存、让缓存自动更新的最基本、最重要的手段，顺手的第一原则就是：除非有明确理由，否则就给Key加个TTL（生存时间）。
3. 警惕“大Key”和“热Key”：
   • 大Key：指一个Key里存了过大的数据，比如一个List里有几十万条记录，或者一个String值有几十MB，这会导致操作变慢、网络阻塞，甚至引发集群数据倾斜，顺手的方法是，把大对象拆散（比如分页、分段存储），或者考虑是否真的适合用Redis存。
   • 热Key：指某个Key被以极高的频率访问，远超其他Key，这可能会打爆单台Redis服务器的CPU，在集群环境下也会导致请求集中到某一个节点，解决思路是：在业务层做本地缓存，或者用Redis集群的哈希标签功能，把热Key拆分成多个子Key分散存储。
4. 根据业务需求配置持久化：如果你能接受丢失几分钟数据（比如纯缓存），用RDB就够了，简单高效，如果你的数据很重要，一点都不能丢（比如购物车、计数器），那就必须开启AOF，并配置为 appendfsync everysec（每秒同步，性能和数据安全的良好平衡），最保险的是 RDB + AOF 组合使用：用RDB做定期完整备份，用AOF保证实时性，恢复时优先用AOF。
5. 善用数据结构，别只用String：Redis顺手的一大精髓在于它丰富的数据结构。
   • 用 List 做简单的消息队列或最新N条记录。
   • 用 Hash 来存储一个对象的多个字段（比如用户信息），可以单独读写某个字段，比存整个JSON字符串到String里更高效。
   • 用 Set 来做去重、共同好友（求交集）。
   • 用 Sorted Set 做排行榜，自动排序，功能强大。 用对了数据结构，你的操作会既简洁又高效。
6. 保证有足够的内存：这是Redis顺畅运行的物理基础，你需要监控内存使用情况，并通过 maxmemory 参数设置上限，并配置一个合适的淘汰策略（如 allkeys-lru），当内存满时，Redis会根据策略自动删除一些Key，为新的数据腾地方，这比直接让Redis崩溃要好。

总结一下：Redis默认就是一个内存存储引擎，快是它的王牌，想用得顺手，核心思想就是 “扬长避短” ：利用它的速度处理热点数据，通过设置过期时间和合理的数据结构来管理内存，根据对数据安全性的要求配置好持久化，并时刻注意避免大Key和热Key带来的性能陷阱，把它当成你应用体系中的“瑞士军刀”，用在最合适的场景，而不是“万能的扳手”。