我建议你在http://redis.io/topics/persistence上阅读这篇文章。当您仅使用内存存储来提高性能时，基本上就失去了保证的持久性。想象一下这样一个场景:插入到内存中，但是在它被持久化到磁盘之前失去了电源。会有数据丢失。

Redis支持所谓的“快照”。这意味着它将在某个时间点(例如，每一个完整的小时)对内存中的内容进行完整的复制。当您在两个快照之间断电时，您将丢失从最后一个快照到崩溃之间的数据(不一定是断电..)。像大多数nosql - db一样，Redis将数据安全性与性能进行了权衡。

Most NoSQL-databases follow a concept of replication among multiple nodes to minimize this risk. Redis is considered more a speedy cache instead of a database that guarantees data consistency. Therefore its use cases typically differ from those of real databases: You can, for example, store sessions, performance counters or whatever in it with unmatched performance and no real loss in case of a crash. But processing orders/purchase histories and so on is considered a job for traditional databases.

答案通常是肯定的，但更全面的答案实际上取决于您试图存储的数据类型。一般来说，更完整的简短回答是:

Redis并不是最适合持久存储的，因为它主要关注性能 Redis确实更适合于可靠的内存中存储/缓存当前状态数据，特别是通过提供跨多个客户端/服务器使用的中央数据源来实现可伸缩性

话虽如此，默认情况下，Redis会定期保存数据快照(显然是每1分钟保存一次，但我还没有验证这一点——这在下面的文章中有描述，这是一个很好的基本介绍):

http://qnimate.com/redis-permanent-storage/

博士TL;

官方文件显示:

RDB持久性[默认值]以指定的时间间隔执行数据集的时间点快照。 AOF持久化[需要显式配置]记录服务器接收到的每个写操作，将在服务器启动时再次播放，重构 原始数据集。

如果需要的话，Redis必须显式地配置AOF持久性，这将导致性能损失以及不断增长的日志。对于有限数量的数据流的相对可靠的持久性来说，它可能足够了。

你可以选择完全不坚持。更好的性能，但所有的数据丢失时，Redis关闭。

Redis有两种持久机制:RDB和AOF。RDB使用调度程序全局快照，AOF将更新写入与MySql类似的只能追加的日志文件。

你可以用其中一个，也可以两个都用。当Redis重新启动时，它通过读取RDB文件或AOF文件来构造数据。

这是一个配置问题。你可以在Redis上没有、部分或全部持久化数据。最佳决策将由项目的技术和业务需求驱动。

根据Redis关于持久性的文档，简而言之，你可以设置你的实例，随时或每次查询时将数据保存到磁盘。它们提供了两种策略/方法AOF和RDB(请阅读文档查看详细信息)，您可以单独使用它们，也可以同时使用它们。

如果你想要一个“类似SQL的持久性”，他们说:

一般的提示是，如果你想要达到与PostgreSQL提供的数据安全程度相当的数据安全性，你应该同时使用这两种持久性方法。

这个线程中的所有答案都在谈论redis持久化数据的可能性:https://redis.io/topics/persistence(在每次写入(更改)后使用AOF +)。

这是一个很好的开始链接，但它没有向您展示全貌。

你真的可以/应该在Redis上保存不可恢复的数据/状态吗?

Redis文档没有谈到:

哪些redis提供商支持这个(每次写入后AOF +)选项:

Almost none of them - redis labs on the cloud does NOT provide this option. You may need to buy the on-premise version of redis-labs to support it. As not all companies are willing to go on-premise, then they will have a problem. Other Redis Providers does not specify if they support this option at all. AWS Cache, Aiven,... AOF + after every write - This option is slow. you will have to test it your self on your production hardware to see if it fits your requirements. Redis enterpice provide this option and from this link: https://redislabs.com/blog/your-cloud-cant-do-that-0-5m-ops-acid-1msec-latency/ let's see some banchmarks:

AWS上的1x x1.16xlarge实例-它们不能实现低于2ms的延迟:

从请求的第一个字节到达集群到'写'响应的第一个字节被发送回客户端，延迟是在哪里测量的

他们在更好的硬盘(Dell-EMC VMAX)上进行了额外的垛标，结果是操作延迟< 1ms(!!)，从70K ops/sec(写密集测试)到660K ops/sec(读密集测试)。漂亮impresive ! !

但它需要一个(非常)熟练的devops来帮助您创建这个基础设施并长期维护它。

有人可能(错误地)认为，如果你有一个redis节点集群(带有副本)，现在你就有了完全的持久性。这是虚假声明:

All DBs (sql,non-sql,redis,...) have the same problem - For example, running set x 1 on node1, how much time it takes for this (or any) change to be made in all the other nodes. So additional reads will receive the same output. well, it depends on alot of fuctors and configurations. It is a nightmare to deal with inconsistency of a value of a key in multiple nodes (any DB type). You can read more about it from Redis Author (antirez): http://antirez.com/news/66. Here is a short example of the actual ngihtmare of storing a state in redis (+ a solution - WAIT command to know how much other redis nodes received the latest change change):

    def save_payment(payment_id)
        redis.rpush(payment_id,”in progress”) # Return false on exception
        if redis.wait(3,1000) >= 3 then
            redis.rpush(payment_id,”confirmed”) # Return false on exception
            if redis.wait(3,1000) >= 3 then
                return true
            else
                redis.rpush(payment_id,”cancelled”)
                return false
            end
        else
            return false
    end

上面的示例并不适用，并且存在一个真正的问题，即预先知道每个时刻实际有多少节点(和活动的)。

其他db也会有同样的问题。也许他们有更好的api，但问题仍然存在。

据我所知，很多应用程序甚至没有意识到这个问题。

总而言之，选择更多的dbs节点不是一键配置。它涉及更多。

总结本研究，我们要做的是:

你的团队有多少开发人员(所以这项任务不会拖你后腿)? 你有一个熟练的devops吗? 你们团队的分布式系统技能是什么? 花钱买硬件? 是时候投资解决方案了吗? 也许更多……

Redis服务器不时地将所有数据保存到HDD，从而提供一定程度的持久性。

在以下情况下保存数据:

时不时地自动 手动调用BGSAVE命令时 当redis关闭时

但是redis中的数据并不是真正持久的，因为:

redis进程崩溃意味着丢失自上次保存以来的所有更改 只有当你有足够的空闲RAM(额外的RAM等于redis DB的大小)时才能执行BGSAVE操作。

注意:BGSAVE内存需求是一个真正的问题，因为redis继续工作，直到没有更多的RAM运行，但它停止保存数据到HDD更早(大约在10分钟)。50%的RAM)。

更多信息请参见Redis Persistence。