使用 Redis — Python 文档

来自菜鸟教程
Celery/docs/latest/getting-started/backends-and-brokers/redis
跳转至:导航、​搜索

使用Redis

安装

对于 Redis 支持,您必须安装其他依赖项。 您可以使用 celery[redis] bundle 一次性安装 Celery 和这些依赖项:

$ pip install -U "celery[redis]"

配置

配置很简单,只需配置你的 Redis 数据库的位置:

app.conf.broker_url = 'redis://localhost:6379/0'

其中 URL 的格式为:

redis://:password@hostname:port/db_number

方案后面的所有字段都是可选的,并且在端口 6379 上将默认为 localhost,使用数据库 0。

如果应使用 Unix 套接字连接,则 URL 需要采用以下格式:

redis+socket:///path/to/redis.sock

通过将 virtual_host 参数添加到 URL,可以在使用 Unix 套接字时指定不同的数据库编号:

redis+socket:///path/to/redis.sock?virtual_host=db_number

直接连接到 Redis Sentinel 列表也很容易:

app.conf.broker_url = 'sentinel://localhost:26379;sentinel://localhost:26380;sentinel://localhost:26381'
app.conf.broker_transport_options = { 'master_name': "cluster1" }

可以使用 sentinel_kwargs 将其他选项传递给 Sentinel 客户端:

app.conf.broker_transport_options = { 'sentinel_kwargs': { 'password': "password" } }

可见性超时

可见性超时定义了在将消息重新传递给另一个工作人员之前等待工作人员确认任务的秒数。 请务必查看下面的 警告

这个选项是通过 :setting:`broker_transport_options` 设置来设置的:

app.conf.broker_transport_options = {'visibility_timeout': 3600}  # 1 hour.

Redis 的默认可见性超时为 1 小时。


结果

如果您还想在 Redis 中存储任务的状态和返回值,您应该配置以下设置:

app.conf.result_backend = 'redis://localhost:6379/0'

有关 Redis 结果后端支持的选项的完整列表,请参阅 Redis 后端设置

如果您使用 Sentinel,您应该使用 :setting:`result_backend_transport_options` 设置指定 master_name:

app.conf.result_backend_transport_options = {'master_name': "mymaster"}

连接超时

要为 Redis 结果后端配置连接超时,请使用 :setting:`result_backend_transport_options` 下的 retry_policy 键:

app.conf.result_backend_transport_options = {
    'retry_policy': {
       'timeout': 5.0
    }
}

有关可能的重试策略选项,请参阅 retry_over_time()


注意事项

可见性超时

如果任务在 可见性超时 内没有得到确认,该任务将被重新交付给另一个工作人员并执行。

这会导致执行时间超过可见性超时的 ETA/倒计时/重试任务出现问题; 事实上,如果发生这种情况,它将再次执行,并再次循环执行。

因此,您必须增加可见性超时以匹配您计划使用的最长 ETA 时间。

请注意,Celery 将在 worker 关闭时重新传递消息,因此长时间的可见性超时只会在发生电源故障或强制终止 worker 时延迟“丢失”任务的重新传递。

周期性任务不会受到可见性超时的影响,因为这是一个独立于 ETA/倒计时的概念。

您可以通过配置具有相同名称的传输选项来增加此超时:

app.conf.broker_transport_options = {'visibility_timeout': 43200}

该值必须是描述秒数的 int。


钥匙驱逐

Redis 在某些情况下可能会从数据库中驱逐密钥

如果您遇到如下错误:

InconsistencyError: Probably the key ('_kombu.binding.celery') has been
removed from the Redis database.

那么您可能希望通过在 redis 配置文件中设置来配置 redis-server 以不驱逐密钥:

  • maxmemory 选项
  • maxmemory-policy 选项到 noevictionallkeys-lru

有关详细信息,请参阅有关驱逐策略的 Redis 服务器文档:

分组结果排序

直到 4.4.6 和包括 4.4.6 的 Celery 版本使用未排序的列表来存储 Redis 后端中组的结果对象。 这可能导致这些结果以与原始组实例化中的关联任务不同的顺序返回。 Celery 4.4.7 引入了一个选择加入行为,它修复了这个问题并确保组结果以定义任务的相同顺序返回,匹配其他后端的行为。 在 Celery 5.0 中,此行为已更改为选择退出。 该行为由 result_chord_ordered 配置选项控制,可以像这样设置:

# Specifying this for workers running Celery 4.4.6 or earlier has no effect
app.conf.result_backend_transport_options = {
    'result_chord_ordered': True    # or False
}

这是共享相同 Redis 后端以存储结果的工作人员的运行时行为的不兼容更改,因此所有工作人员必须遵循新的或旧的行为以避免损坏。 对于一些运行 Celery 4.4.6 或更早版本的 worker 的集群,这意味着运行 4.4.7 的 worker 不需要特殊配置,并且运行 5.0 或更高版本的 worker 必须将 result_chord_ordered 设置为 False。 对于没有运行 4.4.6 或更早版本的 worker 但有些运行 4.4.7 的 worker 的集群,建议将所有 worker 的 result_chord_ordered 设置为 True 以简化未来的迁移。 如果下游任务由迁移的工作人员运行,行为之间的迁移将破坏当前保存在 Redis 后端中的结果并导致破坏 - 相应地计划。