这个线程中的所有答案都在谈论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上没有、部分或全部持久化数据。最佳决策将由项目的技术和业务需求驱动。

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

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

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

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

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

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

许多消息不灵通和相对较新的用户认为Redis只是一个缓存，而不是可靠持久性的理想选择。 现实情况是，DB、Cache(以及更多类型)之间的界限现在已经模糊了。

它都是可配置的，作为用户/工程师，我们可以选择将其配置为缓存，DB(甚至是混合)。

每个选择都有收益和成本。Redis也不例外，所有知名的分布式系统都提供了配置不同方面的选项(持久性、可用性、一致性等)。所以，如果你在默认模式下配置Redis，希望它能神奇地给你高可靠的持久性，那么这是团队/工程师的错误(而不是Redis的错误)。

我已经在我的博客上更详细地讨论了这些方面。

另外，这是Redis本身的一个链接。

这个线程中的所有答案都在谈论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。