使用 Redis 存储会话有多安全？答案

【问题标题】：How safe is it to store sessions with Redis?使用 Redis 存储会话有多安全？
【发布时间】：2012-05-03 22:54:51
【问题描述】：

我目前正在使用 MySql 来存储我的会话。效果很好，就是有点慢。

有人要求我使用 Redis，但我想知道这是否是个好主意，因为我听说 Redis 会延迟写入操作。我有点害怕，因为会话需要是实时的。

有人遇到过这样的问题吗？

【问题讨论】：

既然 Redis 说它具有可选的持久性，那么我会说如果您选择 HDD 上的持久性，那么使用它是安全的。但是，对于会话数据 - 我肯定会将它们保存到 RAM 中（这意味着我不会担心整个考验的耐久性部分）。如果您丢失会话数据，最糟糕的情况就是让您的用户退出。
是的，但这是我的要求的一部分，用户不应该重新登录，顺便说一下，在用户未登录（访客用户）的情况下，一些用户数据会在会话中保留。他们将使用 Redis RAM，但启用了日志记录和/或备份。如果我们丢失了一些会话，这是可以接受的。
我主要担心的是延迟写入，如果用户登录并且会话写入延迟会发生什么情况，他将被重定向但未登录
想象一个电子商务网站，如果会话丢失，当前的购物车也会丢失，这并不可怕，但对用户来说可能很奇怪。来宾用户仅通过会话识别，因此无法恢复他们的购物车。
@BorisGuéry - 并不是我不同意，但如果必须提高性能 - 出现问题时必须做出妥协。是的，用户突然退出登录会很奇怪，这是肯定的 - 但问题是它预计会多久发生一次？如果所有 Redis 节点每年都出现一两次故障，那么当整个集群不可用时，我认为没有理由在几次孤立的时间内降低性能。但这只是我。

【解决方案1】：

这个问题实际上是关于 实时会话， 并且似乎部分是由于对“延迟写入操作”这个短语的误解虽然细节最终在 cmets 中被梳理出来，但我只是想让它超级清晰......

实施实时会话不会有任何问题。

Redis 是一个 in-memory 键值存储，具有可选的磁盘持久性。 “延迟写入操作”是指写入磁盘，而不是一般的数据库，它存在于内存中。如果您设置一个键/值对，您可以立即获取它（即实时）。您选择的关于持久性的策略（延迟写入的时间）将决定崩溃中可能丢失多少数据的上限。

【讨论】：

【解决方案2】：

基本上有两种主要类型可用：异步 snapsnots 和 fsync()。它们分别称为 RDB 和 AOF。更多关于persistence modes on the official page。

例如，守护进程的信号处理在收到 SIGTERM 时会同步到磁盘，因此重启后数据仍然存在。我认为守护程序或操作系统必须在您看到完整性损坏之前崩溃，即使使用默认设置（RDB 快照）也是如此。

AOF 设置使用 Append Only File 记录服务器接收到的命令，并在冷启动时从保存的文件从头开始重新创建 DB。默认的磁盘同步策略是每秒刷新一次 (IIRC)，但可以设置为在每个命令上锁定和写入。

同时使用快照和增量日志似乎提供了一个长期的don't-mind-if-I-miss-a-few-seconds-of-data方法安全但昂贵的增量日志。 Redis 支持开箱即用的集群，因此似乎也可以进行复制。

我自己使用默认的 RDB 设置并将快照保存到远程 FTP。我还没有看到导致数据丢失的故障。最有可能发生急性硬件故障或停电，但我托管在 VPS 上。发生这种情况的可能性很小:)

【讨论】：

【解决方案3】：

Redis 非常适合存储会话。所有操作都在内存中执行，因此读写速度很快。

第二个方面是会话状态的持久性。 Redis 在如何将会话状态持久保存到硬盘方面为您提供了很大的灵活性。您可以通过http://redis.io/topics/persistence 了解更多信息，但在高层次上，这里是您的选择 -

如果您无法承受丢失任何会话的后果，请在配置文件中设置appendfsync always。有了这个，Redis 保证任何写操作都保存到磁盘上。缺点是写操作会比较慢。
如果您可以接受丢失大约 1 秒的数据，请使用 appendfsync everysec。这将在合理的数据保证下提供出色的性能

【讨论】：