Redis存储位置怎么调，顺便聊聊用Redis改存储方式那些事儿

关于Redis存储位置的调整，说白了就是决定Redis把你的数据放在哪里、怎么放，这主要涉及到两个核心的东西：一个是持久化策略，另一个是内存管理，咱们一个一个聊,就用大白话来说。

第一部分：Redis的存储位置和持久化——数据怎么“存盘”

你可以把Redis想象成一个超级快的、主要在工作台（内存）上干活的计算器，内存快，但一断电数据就全没了，为了数据安全，我们得时不时地把工作台上的重要数据“存盘”到硬盘里，这个“存盘”的过程，就是持久化，Redis主要给了我们两种“存盘”方式,也就是两种调整存储位置的核心手段。

第一种方式叫RDB（快照模式），这种方式就像是你玩游戏时的手动存档或者定时自动存档。（来源：Redis官方文档对RDB的描述）它会每隔一段时间，或者满足一定条件时，给内存里的所有数据拍一张完整的快照，然后把这个快照文件（一个叫dump.rdb的文件）写到硬盘上你指定的目录里，这个目录就是你调整的第一个“存储位置”，你可以在Redis的配置文件redis.conf里找到“dir ./”这一行，把后面的路径改成你想要的任何地方，dir /data/redis”，这样，RDB快照就会存到那个目录下了，RDB的好处是恢复大数据集时速度很快，因为就是一个文件直接读进来，缺点是如果两次存档之间服务器宕机,你会丢失那段时间的数据。

第二种方式叫AOF（追加日志模式），这种方式更像是一个写日记的习惯。（来源：Redis官方文档对AOF的描述）它不拍整体快照，而是把你每一次对数据进行的写命令（比如set, hset等）都记录下来，追加到一个日志文件的末尾，这个日志文件（默认是appendonly.aof）的存放位置，同样由上面提到的“dir”参数决定，AOF的优点是数据安全性高很多，你可以配置成每秒钟同步一次日志到硬盘，这样最多丢一秒的数据，缺点是日志文件会越来越大,而且恢复起来比RDB慢。

在实际应用中，很多人会选择两者同时开启，用AOF来保证数据不丢失，用RDB来做冷备份和快速恢复，这样，你就把数据存储在了两个地方：高速但易失的内存里,以及相对低速但持久化的硬盘上的RDB文件和AOF文件里。

第二部分：聊聊用Redis改变存储方式的那些事儿

这部分就更有意思了，它不仅仅是“存盘”到硬盘，而是如何利用Redis的特性,从根本上改变我们应用存取数据的方式。

以前，很多应用一遇到数据就去读数据库（比如MySQL），数据库扛不住就加机器，搞得很复杂，Redis的出现，引入了一个“缓存”的概念，这本身就是一种存储方式的革命，我们把最常用、最热点的数据从慢速的数据库里“搬”到快速的Redis内存中，读的时候先找Redis，找不到再去数据库，这极大地减轻了数据库的压力，提升了应用速度，这就是最经典的“用Redis改存储方式”。

再往深了说，Redis丰富的数据结构让我们可以设计出更精巧的存储方案,举个例子：

• 告别复杂SQL查询：以前你要统计一个用户的朋友圈点赞列表，可能需要在数据库里好几张表关联查询，现在你可以用Redis的集合（Set） 或有序集合（Sorted Set），发一条朋友圈时，为其创建一个集合，每个点赞的用户ID直接塞进去，要查谁点了赞，直接从这个集合里取就行了，速度快如闪电，数据存储的思维从“关系型”变成了“结构化缓存”。
• 实现简单的消息队列：以前发个通知、处理个异步任务，可能要引入RabbitMQ、Kafka这种专业的消息队列系统，但很多简单场景下，用Redis的列表（List） 就能搞定，生产者用LPUSH命令把任务塞进列表一头，消费者用RPOP从另一头取任务执行，存储方式从“重型中间件”变成了“轻量级数据结构”。
• 应对秒杀场景：传统的数据库更新库存，在瞬间高并发下很容易挂掉，利用Redis的单线程和原子操作特性，我们可以先把商品库存数量预加载到Redis里，秒杀开始时，用户请求直接操作Redis，用DECR命令原子性地减库存，减成功了才算抢到,这样就把存储和计算的巨大压力从数据库转移到了Redis身上。

用Redis改变存储方式也不是没有代价，你引入了Redis，就意味着系统更复杂了，你要考虑缓存和数据库的数据一致性問題（比如先更新数据库还是先删缓存？），要考虑Redis挂掉后的降级方案,要监控它的内存使用别撑爆了。

调整Redis的存储位置（持久化）是保证数据安全的基础操作，是“术”；而利用Redis改变整个应用的存储和数据处理方式，则是提升性能和架构设计的“道”，从简单的缓存，到替代部分数据库功能，再到实现复杂的业务逻辑，Redis给了我们很大的想象空间，让我们在面对不同场景时，可以更灵活、更高效地设计和选择数据的“安家”之处，关键是要理解它的能力和局限,因地制宜地使用它。