写在后面架构

了解写在后面的主要组件

写在后面允许您集成 Redis Enterprise（作为数据变更的来源）和下游数据库或数据存储。写在后面会捕获 Redis 键空间中选定的一组键模式的任何变更，并将它们以小批量异步写入下游数据库。这意味着您的应用程序无需处理数据重塑或管理与下游数据库的连接。

写在后面可以将 Redis 中的一个键标准化为目标中一个或多个表中的多个记录。要了解更多关于写在后面的声明式作业和规范化的信息，请参阅写在后面快速入门指南。

写在后面拓扑

写在后面的 CLI 和引擎作为一个产品一起发布，可以运行摄取和写在后面两种管道。然而，这两种不同类型的管道具有不同的拓扑结构。

写在后面引擎安装在包含应用程序数据的 Redis 数据库上，而不是独立的暂存 Redis 数据库上。写在后面的数据流及其控制平面仅为 Redis 数据库增加几百 MB 的少量占用空间。在写在后面拓扑中，写在后面在每个分片上并行处理数据，并从每个分片与下游数据库建立单个连接。

写在后面可以跟踪以下 Redis 类型的变更

与摄取场景不同，写在后面没有默认的模型转换行为。您必须始终创建一个声明式作业来指定 Redis 键与目标数据库记录之间的映射。作业配置包含 keys 和 mapping 部分，这有助于使此任务变得容易。

写在后面基于 Python 的 CLI 非常直观易用，并执行验证以帮助您避免错误。CLI 使设置写在后面并在其整个生命周期中进行管理变得容易。

写在后面使用 Redis Gears 作为其运行时环境。Gears 和写在后面引擎逻辑安装在所有源 Redis Enterprise 数据库分片上，但只有主分片处理事件并处理管道。

写在后面引擎从 Redis Streams（每个跟踪的键模式有一个）读取 Redis 变更事件，处理它们，并将它们转换为 SQL 或目标数据库使用的任何其他语言。

写在后面使用事务以小批量方式将变更写入目标。写在后面保证至少一次交付。如果发生任何网络问题、断开连接或其他临时故障，写在后面将继续尝试将变更写入目标。如果发生硬拒绝，写在后面会将拒绝记录和原因保存在死信队列 (DLQ) 中。

写在后面配置持久化在集群级别。配置由 CLI deploy 命令写入，该命令将所有变更保存到配置文件中。此机制允许在需要新分片时自动配置，并且可以在分片和节点故障时幸存下来。