ruby-on-rails - 将复杂的哈希传递给 Sidekiq 作业

Question

来自Best Practices Guide对于使用 Sidekiq，我知道最好将“字符串、整数、 float 、 bool 值、null(nil)、数组和散列”作为参数传递给作业。

我通常只是将持久对象的 ID 传递给我的作业，但由于延迟限制，我需要在运行作业后保存该对象。

我正在使用的非持久化对象包含多种数据类型:

#MyObject<00x000>{
id: nil
start_time: Fri, 11 Dec 2020 08:45:00 PST -08:00 (*this is a TimeWithZone object)
rate: 18.0 (*this is a BigDecimal object)
...
}

我计划先将此对象转换为散列，然后将其传递给我的作业:

MyJob.perform_async(my_object.attributes)

然后像这样持久化对象:

MyObject.new(my_object_hash).save

我的问题是，这样安全吗？即使我将“简单”数据类型传递给 Sidekiq，它实际上包含复杂的对象。我会失去精度吗？

谢谢!

Answer 1

这听起来像是“potayto, potahto”解决方案。你不是不用Sidekiq的序列化，而是自己序列化。

让我们看看为什么 sidekiq 有这个规则:

Even if they did serialize correctly, what happens if your queue backs up and that quote object changes in the meantime? [...]Don't pass symbols, named parameters, keyword arguments or complex Ruby objects (like Date or Time!) as those will not survive the dump/load round trip correctly.

我想添加第三个:

Serializing state makes it impossible to distinguish between persisted and ethereal (in-memory, memoized, lazy-loaded etc) data. E.g. a def sent_mails; @sent_mails ||= Mail.for(user_id: id); end now gets serialized: do you want that?

sidekiq也提供了解决方案:

Don't save state to Sidekiq, save simple identifiers. Look up the objects once you actually need them in your perform method.

XY problem here

您的真正问题不是在何处或如何序列化状态。因为 sidekiq 警告不要序列化状态，无论您在何处以及如何执行此操作。

您需要解决的问题是如何将状态存储在可以正确存储的地方。或者根本避免存储状态:不在 redis/sidekiq 中，也不在给您带来问题的存储中。

延迟

您的存储速度慢吗？难道不是验证、序列化、缓慢的存储副作用吗？

您能否通过两步来改进它:插入状态并稍后更新/丰富/验证它异步？如果您使用的是 Rails，它在这里对您没有帮助，甚至可能对您不利，但一个常见的模型是将对象存储在一个特殊的“队列”表或事件队列中；例如kafka 以此闻名。

当例如存储通过慢速网络发生在慢速 API 上，这可能无法解决，但是当存储发生在本地数据库中时，您可以使用数十年的解决方案来提高写入性能。无论是在你的数据库中，还是在一些专门的状态存储队列中(sidekiq 不是这样一个专门的存储队列)，这取决于用于存储的技术。例如。 Linux 将允许您通过内存进行存储，从而使写入磁盘的速度非常快，但无法保证它确实已写入磁盘。

例如在簿记 API 中，我们会将经过验证的对象存储在 PostgreSQL 中，然后让异步作业稍后为其添加昂贵的属性(例如，必须从遗留 API 或通过复杂计算检索的状态)。

例如在写入量大的 GIS 系统中，我们会将对象存储到“to_process_places”表中，该表由处理 Places 的工具监控。这完全取决于您的领域和要求。

不使用状态。

一个常见的解决方案是不制作对象，而是使用客户的实际负载。只需发送 HTTP 有效负载(在 rails 中，params)并保留它。也许合并到一个 header 中(如 Request Date )或过滤掉一些数据( header 标记或 cookie)。

如果您的 Controller 可以使用这些数据进行操作，那么延迟作业也可以。不要在 Controller 中构建对象，而是将其留给延迟的工作。这甚至可以产生真正整洁和精简的 Controller :它们所做的只是(一些身份验证和授权，然后)调用适当的作业并向其传递经过净化的 params。

显然，这需要权衡，比如不能同步验证，而是通过电子邮件、推送通知或延迟响应提供此类信息，具体取决于您的要求(例如，大型 CSV 导入可以通过电子邮件发送任何验证问题，但如果登录无效，登录请求可能需要立即得到响应。

还需要考虑一下:您可能不想将 Base64 编码的 CSV 一起发送到 sidekiq，而是将文件写入(临时)存储并传递文件名/url。这听起来很明显，因为它是:文件上传本质上是前面提到的“临时状态存储”的实现:你不会将整个 PDF/high-res-header-image/CSV 传递给 sidekiq，而是存储它某个地方，这样 sidekiq 以后可以把它捡起来进行处理。如果将其他属性传递给 sidekiq 存在问题，为什么其他属性不采用相同的模式？