Getting Started Guide¶
概述¶
消息服务是一个基于 RESTful API 的消息服务。它支持分布式 Web 应用程序，并且基于 OpenStack Zaqar 项目。
消息服务是大型分布式 Web 应用程序的重要组成部分。您可以在公共、私有和混合云环境中使用的消息服务。
在开发分布式 Web 应用程序时，您通常会设置多个代理来完成这些应用程序的任务集。这些任务可以是任何事情，从创建用户到删除存储块。消息服务提供了一个简单的接口，该接口将这些任务创建为队列、消息和声明。然后，该接口会根据需要和执行来发布、声明、读取和删除它们。
消息服务处理任务的分配，但并不一定管理任务的顺序。应用程序在更高层次上处理工作流。
本指南解释了如何访问和开始使用 API，以便您可以开始将消息服务用于您的应用程序。提供了如何正确输入必要的 URL（使用 cURL）以设置和使用一组基本的消息服务操作的说明。
运行示例的先决条件¶
为了运行本指南中的示例，您必须具备以下先决条件
一个云帐户
在注册期间指定的用户名和密码
对 HTTP/1.1 协议的先验知识
对云和 RESTful API 的基本熟悉
消息服务的工作原理¶
以下是消息服务工作原理的概述。有关消息服务术语的定义，请参阅下面的词汇表。
您创建一个队列，生产者或发布者将消息发布到该队列。
工作者（消费者或订阅者）从队列中声明或获取消息，完成消息中的工作，然后删除消息。
如果工作者在完成消息中的工作之前将离线，则工作者可以退还声明的生存时间 (TTL)，将消息放回队列中供另一个工作者声明。
订阅者监控这些队列中的声明，以跟踪活动并帮助排除故障。
对于大多数用例，消息服务不负责消息的顺序。但是，如果只有一个生产者，消息服务会确保消息以先进先出 (FIFO) 的顺序处理。
消息模式¶
消息服务 API 支持各种消息模式，包括以下模式
任务分发
事件广播
点对点消息传递
任务分发¶
任务分发模式具有以下特征
生产者被编程为将消息发送到队列。
多个工作者（或消费者）被编程为监控队列。
只有一名工作者可以声明消息，这样其他工作者就无法声明消息并重复工作。
工作者在完成工作后必须删除消息。
TTL 将消息恢复到未声明状态，如果工作者从未完成。
此模式非常适合将作业分派给多个处理器。
事件广播¶
事件广播模式的特征是
发布者将消息发送到队列。
多个观察者（或订阅者）获取队列中的消息。
多个观察者对每条消息采取行动。
观察者发送标记以跳过已查看的消息。
TTL 最终会删除消息。
此模式非常适合一次向多个观察者通知事件。
点对点消息传递¶
点对点消息传递模式的特征是
发布者将消息发送到队列。
消费者获取队列中的消息。
消费者可以通过将另一条消息发送到同一队列（队列默认情况下是双工的）来回复处理消息的结果。
发布者从队列获取回复。
消费者发送标记以跳过已查看的消息。
TTL 最终会删除消息。
此模式非常适合与特定客户端通信，尤其是在需要从该客户端获取回复时。
消息服务操作¶
本节列出了消息服务 API 中所有可用的操作。本文档在 OpenStack API 参考 中使用一些最常见的操作。
有关所有操作的详细信息，请参阅消息服务 API v2 参考。
主文档¶
主文档可用的操作如下
获取主文档
队列¶
队列可用的操作如下
创建队列
列出队列
获取队列
更新队列
获取队列统计信息
删除队列
消息¶
消息可用的操作如下
发布消息
获取消息
获取特定消息
按 ID 获取一组消息
删除消息
按 ID 删除一组消息
声明¶
声明可用的操作如下
声明消息
获取声明
更新声明
释放声明
订阅¶
订阅可用的操作如下
创建订阅
列出订阅
获取订阅
更新订阅
删除订阅
池¶
池可用的操作如下
创建池
列出池
获取池
更新池
删除池
规格¶
风味可用的操作如下
创建风味
列出风味
获取风味
更新风味
删除风味
健康状况¶
健康状况可用的操作如下
Ping 以获取基本健康状况
获取详细健康状况
用例¶
队列系统用于协调应用程序中的任务。以下是一些示例
备份：备份应用程序可能会使用队列系统来连接用户在控制面板中执行的操作与服务器上的客户备份代理。当客户想要启动备份时，他们只需在面板上选择“启动备份”。这样做会导致生产者将“startBackup”消息放入队列。每隔几分钟，客户服务器上的代理（工作者）会检查队列，查看是否有任何新消息需要处理。代理声明“startBackup”消息并在客户服务器上启动备份。
存储：收集大型分布式存储系统的统计信息可能是一个漫长的过程。存储系统可以使用队列系统来确保作业完成，即使最初失败。由于消息在工作者完成作业后才会被删除，因此存储系统可以确保没有作业未完成。如果工作者未能完成作业，则消息会保留在队列中供另一个服务器完成。在这种情况下，工作者声明消息以执行统计作业，但声明的 TTL 已过期，并且当作业花费的时间过长时（意味着它很可能失败）消息会放回队列。通过为声明提供 TTL，应用程序可以保护自己免受工作者在处理消息时离线的影响。在声明的 TTL 过期后，消息会放回队列供另一个工作者声明。
电子邮件：电子邮件应用程序的团队不断将客户电子邮件从旧版本迁移到新版本，因此他们开发了一个工具，让客户可以自行执行此操作。迁移需要很长时间，因此不能通过单个 API 调用或单个服务器来完成。当用户从其门户网站启动迁移作业时，迁移工具会将包含如何运行迁移的详细信息的消息发送到队列。一组迁移引擎（在本例中为消费者）会定期检查队列中的新迁移任务，声明消息，执行迁移，并使用迁移详细信息更新数据库。此过程允许一组服务器协同工作，以在合理的时间内完成大型迁移。
以下是消息服务的通用用例
在多个工作者之间分发任务（事务作业队列）
将事件转发到数据收集器（事务事件队列）
将事件发布到任何数量的订阅者（事件广播）
向一个或多个代理发送命令（点对点消息传递或事件广播）
从远程过程调用 (RPC) 代理请求操作或获取信息（点对点消息传递）
其他资源¶
有关使用 API 的更多信息，请参阅消息服务 API v2 参考。您开始使用消息服务所需的一切都是入门指南、参考和您的云帐户。
有关 OpenStack Zaqar API 的信息，请参阅 OpenStack API 参考。
此 API 使用标准 HTTP 1.1 响应代码，如 www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 中所述。
词汇表¶
声明 工作者检查消息以执行任务的过程。声明消息可防止其他工作者尝试处理相同的消息。
声明 TTL 定义消息将处于声明状态的时间长短。一次只能由一名工作者声明消息。
消费者 从队列中声明消息的服务器。
消息 任务、通知或生产者或发布者发送到队列的任何有意义的数据。消息存在直到被接收者删除或由系统根据 TTL（生存时间）值自动删除。
消息 TTL 定义消息的可访问时间长短。
生产者 将消息发送到队列的服务器或应用程序。
生产者 - 消费者 一种模式，其中读取队列的每个工作者应用程序都必须声明消息，以防止重复处理。稍后，当工作完成时，工作者负责删除消息。如果未在预定义的时间内删除消息，则可以由其他工作者声明。
发布者 将消息发布到队列的服务器或应用程序，目的是向多个订阅者分发信息或更新。
发布者 - 订阅者 一种模式，其中所有工作者应用程序都可以访问队列中的所有消息。工作者无法删除或更新消息。
队列 包含消息的实体。理想情况下，每个工作类型创建一个队列。例如，如果您想压缩文件，您将创建一个专门用于此作业的队列。任何从该队列读取的应用程序都只会压缩文件。
订阅者 像 RSS 提要一样监视消息的观察者，但不声明任何消息。
TTL 生存时间值。
工作者 从队列中声明消息并根据这些消息执行操作的客户端。
