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

Question 1

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

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

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

Question 2

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

第二个方面是会话状态的持久性。Redis使您可以灵活地将会话状态持久化到硬盘。您可以通过http://redis.io/topics/persistence进行了解，以了解更多信息，但从总体上讲，这是您的选择-

如果您承担不起丢失任何会话的费用，请appendfsync always在配置文件中进行设置。这样，Redis可以确保将任何写操作保存到磁盘。缺点是写操作将较慢。
如果您可以丢失大约1秒钟的数据，请使用appendfsync everysec。合理的数据保证将带来出色的性能

Question 3

基本上有两种主要类型：异步snapsnots和fsync()。它们分别称为RDB和AOF。有关持久性模式的更多信息，请访问官方页面。

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

AOF设置使用“仅附加文件”记录服务器接收的命令，并在冷启动时从头开始从保存的文件重新创建数据库。默认的磁盘同步策略是每秒刷新一次（IIRC），但可以将其设置为在每个命令上锁定和写入。

同时使用快照和增量日志似乎可以提供长期的“ 别管我，如果我错过了几秒钟的数据”方法，同时提供了一个更安全但成本较高的增量日志。Redis开箱即用地支持集群，因此复制似乎也可以完成。

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

Question 4

这个问题实际上是关于实时会话的，似乎部分是由于对“延迟的写操作”一词的误解而引起的。尽管最终在评论中提到了细节，但我只是想让它变得更加简洁。 ..

实施实时会话将没有任何问题。

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