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

我目前正在使用MySql存储我的会话。它工作得很好，但有点慢

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

---

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

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

第二个方面是会话状态的持久性。Redis在如何将会话状态持久化到硬盘上方面为您提供了很大的灵活性。你可以通过学习了解更多，但在高层次上，以下是你的选择-

如果您无法承受任何会话丢失的代价，请在配置文件中设置

appendfsync always

。通过这种方式，Redis可以保证任何写操作都保存到磁盘上。缺点是写操作会比较慢

如果您不介意丢失大约1s的数据，请使用

appendfsync everysec

。这将提供良好的性能和合理的数据保证

---

基本上有两种主要的可用类型：异步snapsnots和

fsync（）

。它们分别称为RDB和AOF。更多关于

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

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

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

---

我自己使用默认的RDB设置，并将快照保存到远程FTP。我还没有看到导致数据丢失的故障。最有可能的情况是出现严重的硬件故障或断电，但我的主机是VPS。发生这种情况的可能性很小：）

这个问题实际上是关于实时会话的，部分原因似乎是对“延迟写入操作”这一短语的误解。虽然细节最终在评论中被梳理出来，但我只想说清楚

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

---

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

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