写后架构

探索Write-behind的主要组件

Write-behind 允许你将 Redis Enterprise（作为数据更改的来源）与下游数据库或数据存储集成。 Write-behind 捕获 Redis 键空间中选定键模式的任何更改，并以小批量异步写入下游数据库。这意味着你的应用程序不需要处理数据重塑或管理与下游数据库的连接。

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

写后拓扑

Write-behind的CLI和引擎作为一个产品提供，可以同时运行数据摄取和write-behind管道。 然而，这两种不同类型的管道具有不同的拓扑结构。

Write-behind引擎安装在包含应用程序数据的Redis数据库上，而不是安装在单独的暂存Redis数据库上。Write-behind数据流及其控制平面仅向Redis数据库添加了几百MB的小足迹。在write-behind拓扑中，Write-behind在每个分片上并行处理数据，并从每个分片建立到下游数据库的单一连接。

模型翻译

写后可以跟踪以下Redis类型的更改：

• Hash
• JSON
• Set
• Sorted Set

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

写后组件

写后 CLI

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

写后引擎

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

Write-behind引擎从Redis流（每个跟踪的键模式一个）读取Redis变更事件，处理它们，并将它们转换为SQL或目标数据库使用的其他语言。

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

写后配置

写后配置在集群级别持久化。配置由CLI deploy 命令写入，该命令将所有更改保存到配置文件中。这种机制允许在需要时自动配置新的分片，并且可以在分片和节点故障时继续运行。