reactjs 做网站网络营销培训班

reactjs 做网站,网络营销培训班,企业网站管理系统多站多语言版,网页版面#作者#xff1a;朱雷 文章目录1、Redis 如何将数据写入磁盘1.1.RDB 优势1.2.RDB 的缺点1.3.AOF 优点1.4.AOF 缺点2、持久化原理2.1. RDB快照2.2. AOF仅追加文件3、那么我们应该使用什么#xff1f;1、Redis 如何将数据写入磁盘 持久化是指将数据写入持久化存储。Redis 提供…#作者朱雷文章目录1、Redis 如何将数据写入磁盘1.1.RDB 优势1.2.RDB 的缺点1.3.AOF 优点1.4.AOF 缺点2、持久化原理2.1. RDB快照2.2. AOF仅追加文件3、那么我们应该使用什么1、Redis 如何将数据写入磁盘持久化是指将数据写入持久化存储。Redis 提供了一系列持久化选项包括RDBRedis 数据库RDB 持久性以指定的时间间隔对数据集执行时间点快照。AOF仅追加文件AOF 持久化机制会记录服务器收到的每个写入操作。这些操作可以在服务器启动时重放从而重建原始数据集。命令的记录格式与 Redis 协议本身的格式相同。无持久性您可以完全禁用持久性。这仅在使用redis作为纯缓存时使用。RDB AOF您还可以在同一个实例中结合使用 AOF 和 RDB。1.1.RDB 优势RDB 是 Redis 数据的一个非常紧凑的单文件时间点表示。RDB 文件非常适合备份。例如您可能希望每小时存档最近 24 小时内的 RDB 文件并每天保存一个 RDB 快照持续 30 天。这样您可以在发生灾难时轻松恢复数据集的不同版本。RDB 非常适合灾难恢复它是一个可以传输到远处数据中心的单个紧凑文件。RDB 最大化了 Redis 的性能因为 Redis 父进程为了持久化唯一需要做的就是 fork 一个子进程然后由子进程完成剩下的所有工作。父进程永远不会执行磁盘 I/O 或类似的操作。与 AOF 相比RDB 允许使用大数据集更快地重启。在副本上RDB 支持重启和故障转移后的部分重新同步。1.2.RDB 的缺点如果您需要最大程度地降低 Redis 停止工作例如断电后时数据丢失的风险那么 RDB 并不理想。您可以配置不同的保存点来生成 RDB例如在五分钟后对数据集进行 100 次写入后生成保存点快照。如果 Redis 因任何原因未正确关闭而停止工作您应该做好丢失最新几分钟数据的准备。RDB 需要频繁地 fork() 才能使用子进程将数据持久化到磁盘。如果数据集很大fork() 可能会非常耗时如果数据集很大且 CPU 性能不佳可能会导致 Redis 停止服务客户端几毫秒甚至一秒钟。AOF 也需要 fork()但频率较低您可以调整重写日志的频率而不会影响持久性。1.3.AOF 优点使用 AOF Redis 的持久性更强你可以设置不同的 fsync 策略完全不 fsync、每秒 fsync 或每次执行时 fsync。使用默认的每秒 fsync 策略写入性能仍然非常出色。fsync 由后台线程执行当没有 fsync 正在进行时主线程会尽力执行写入操作因此你只会损失一秒钟的写入数据。AOF 日志是仅追加日志当 AOF 文件过大时Redis 能够在后台自动重写。重写过程非常安全因为 Redis 在继续向旧文件追加数据的同时会使用创建当前数据集所需的最少操作生成一个全新的 AOF 文件。一旦第二个文件准备就绪Redis 就会切换两个 AOF 文件并开始向新文件追加数据。AOF 以易于理解和解析的格式逐一记录所有操作的日志。1.4.AOF 缺点对于同一数据集AOF 文件通常比等效的 RDB 文件更大。AOF 的速度可能比 RDB 慢具体取决于具体的 fsync 策略。通常将 fsync 设置为每秒一次时性能仍然非常高而禁用 fsync 后即使在高负载下AOF 的速度也应该与 RDB 一样快。2、持久化原理以下部分将详细说明这两种持久性模型。2.1. RDB快照工作原理每当 Redis 需要将数据集转储到磁盘时就会发生以下情况Redis fork。我们现在有一个子进程和一个父进程。子进程开始将数据集写入临时 RDB 文件。当子进程完成写入新的 RDB 文件时它将替换旧的 RDB 文件。2.2. AOF仅追加文件快照的持久性并不理想。如果运行 Redis 的计算机停止运行、线路故障或您意外关闭了kill -9实例写入 Redis 的最新数据就会丢失。虽然对于某些应用程序来说这可能不是什么大问题但在某些情况下需要完全持久性而在这些情况下仅使用 Redis 快照并不可行。工作原理仅追加文件是Redis 的另一种完全持久化策略每次 Redis 收到更改数据集的命令例如SET它都会将其附加到 AOF 文件中。可以配置 Redis 将数据写入磁盘的次数 fsync。共有三个选项appendfsync alwaysfsync每次新命令都会被追加到 AOF 文件。速度非常慢但非常安全。appendfsync everysecfsync每秒一次。速度足够快自 2.4 版本以来可能与快照一样快如果发生灾难您可能会丢失 1 秒的数据。appendfsync no永远不要fsync直接把你的数据交给操作系统。这种方法更快但更不安全。通常情况下Linux 会在此配置下每 30 秒刷新一次数据但具体情况取决于内核的具体调整。建议也是默认的策略是fsync每秒执行一次。它既快速又相对安全。该always策略在实际应用中速度很慢但它支持组提交因此如果有多个并行写入Redis 会尝试执行单个fsync操作。3、那么我们应该使用什么一般情况下如果您想要获得与 PostgreSQL 所能提供的相当的数据安全程度那么您应该同时使用这两种持久性方法。如果您非常关心您的数据但在发生灾难时仍然可以忍受几分钟的数据丢失那么您可以单独使用 RDB备份策略。有很多用户单独使用 AOF但我们不鼓励这样做因为不时地进行 RDB 快照对于进行数据库备份、更快地重启以及在 AOF 引擎出现错误时是一个好主意。使用redis作为纯缓存场景建议关闭RDB / AOF持久化功能。使用脚本定期执行RDB备份命令以实现数据备份冗余。存储介质的选择建议优先使用本地SSD磁盘存放RDB和AOF文件充分利用本地I/O的高性能与低延迟特性规避网络延迟风险‌‌。在高并发或写多读少场景下避免使用NFS / Ceph等依赖网络性能作为持久化存储介质。下图是官方警告说明。