使用 Azure 通知中心推送通知:常见问题Push notifications with Azure Notification Hubs: Frequently asked questions


通知中心的资源结构是怎样的?What is the resource structure of Notification Hubs?

Azure 通知中心有两个资源级别:中心和命名空间。Azure Notification Hubs has two resource levels: hubs and namespaces. 中心是单个推送资源,可以保存一个应用的跨平台推送信息。A hub is a single push resource that can hold the cross-platform push information of one app. 命名空间是一个区域中所有中心的集合。A namespace is a collection of hubs in one region. 建议的映射将一个命名空间与一个应用相匹配。Recommended mapping matches one namespace with one app. 在命名空间内,可以创建适用于生产应用的生产中心、适用于测试应用的测试中心,等等。Within a namespace, you can have a production hub that works with your production app, a testing hub that works with your testing app, and so on.

通知中心的价格模型有哪些?What is the price model for Notification Hubs?

可以在通知中心定价页上找到最新的定价详细信息。The latest pricing details can be found on the Notification Hubs Pricing page. 通知中心根据命名空间级别计费。Notification Hubs is billed at the namespace level. (有关命名空间的定义,请参阅“通知中心的资源结构是怎样的?”)通知中心提供三个层:(For the definition of a namespace, see "What is the resource structure of Notification Hubs?") Notification Hubs offers three tiers:

  • 免费:此层是探索推送功能的极佳起点。Free: This tier is a good starting point for exploring push capabilities. 不建议对生产应用使用此层。It's not recommended for production apps. 在每个命名空间中,每个月可以预配 500 个设备和执行 100 万次推送,但无法享受服务级别协议 (SLA) 保证。You get 500 devices and 1 million pushes included per namespace per month, with no service level agreement (SLA) guarantee.
  • 基本:建议将此层(或标准层)用于较小型的生产应用。Basic: This tier (or the Standard tier) is recommended for smaller production apps. 在每个命名空间中,每个月可以预配 200,000 个设备和执行 1,000 万次推送(基准)。You get 200,000 devices and 10 million pushes included per namespace per month as a baseline.
  • 标准:建议将此层用于中型到大型生产应用。Standard: This tier is recommended for medium to large production apps. 在每个命名空间中,每个月可以预配 1,000 万个设备和执行 1,000 万次推送(基准)。You get 10 million devices and 10 million pushes included per namespace per month as a baseline. 包含丰富的遥测数据(提供有关推送状态的其他数据)。Includes rich telemetry (additional data about push status provided).

标准层功能:Standard tier features:

  • 丰富的遥测功能:可以根据消息遥测使用通知中心来跟踪任何推送请求和平台通知系统反馈,以便进行调试。Rich telemetry: You can use Notification Hubs Per Message Telemetry to track any push requests and Platform Notification System Feedback for debugging.
  • 多租户:可在命名空间级别使用平台通知系统凭据。Multi-tenancy: You can work with Platform Notification System credentials on a namespace level. 此选项可让你轻松地将租户拆分到相同命名空间内的中心。This option allows you to easily split tenants into hubs within the same namespace.
  • 计划推送:可以计划随时发出通知。Scheduled push: You can schedule notifications to be sent out anytime.
  • 批量操作:如 注册信息导出/导入文档中所述启用注册信息导出/导入功能。Bulk operations: Enables registrations Export/Import functionality as described in the Registrations Export/Import document.

什么是通知中心 SLA?What is the Notification Hubs SLA?

对于基本和标准通知中心层,正确配置的应用程序可在 99.9% 的时间发送推送通知或执行注册管理操作。For Basic and Standard Notification Hubs tiers, properly configured applications can send push notifications or perform registration management operations at least 99.9 percent of the time. 若要详细了解 SLA,请访问通知中心 SLA 页。To learn more about the SLA, go to the Notification Hubs SLA page.


由于推送通知取决于第三方平台通知系统(例如 Apple Push Notification 服务 (APNs)),因此这些消息的传递没有 SLA 保证。Because push notifications depend on third-party Platform Notification Systems such as Apple's Push Notification Service (APNs), there is no SLA guarantee for the delivery of these messages. 在通知中心将批处理发送到平台通知系统(有 SLA 保证)后,平台通知系统将负责执行推送(无 SLA 保证)。After Notification Hubs sends the batches to Platform Notification Systems (SLA guaranteed), it is the responsibility of the Platform Notification Systems to deliver the pushes (no SLA guaranteed).

如何将中心升级或降级到不同层的命名空间?How do I upgrade or downgrade my hub or namespace to a different tier?

转到 Azure 门户 > 通知中心命名空间通知中心Go to the Azure portal > Notification Hubs Namespaces or Notification Hubs. 选择要更新的资源,转到“定价层”。Select the resource you want to update, and go to Pricing Tier. 请注意以下要求:Note the following requirements:

  • 更新的定价层应用到正在使用的命名空间中的 所有 中心。The updated pricing tier applies to all hubs in the namespace you're working with.
  • 如果设备计数超出所要降级到的层的限制,则需要删除设备才能降级。If your device count exceeds the limit of the tier you're downgrading to, you need to delete devices before you downgrade.

设计和开发Design and development

支持哪些服务器端平台?Which server-side platforms do you support?

服务器 SDK 适用于 .NET、Java、Node.js、PHP 和 Python。Server SDKs are available for .NET, Java, Node.js, PHP, and Python. 通知中心 API 基于 REST 接口,因此如果要处理不同的平台或不希望有其他依赖项,可以直接使用 REST API。Notification Hubs APIs are based on REST interfaces, so you can work directly with REST APIs if you're using different platforms or do not want extra dependency. 有关详细信息,请转到通知中心 REST API 页。For more information, go to the Notification Hubs REST APIs page.

支持哪些客户端平台?Which client platforms do you support?

iOSAndroidWindows UniversalWindows PhoneAndroid China(通过百度)、Xamarin iOSSafari 支持推送通知。Push notifications are supported for iOS, Android, Windows Universal, Windows Phone, Android China (via Baidu), Xamarin iOS, and Safari. 有关详细信息,请参阅通知中心入门教程页。For more information, see the Notification Hubs Getting Started tutorials page.

是否支持短信、电子邮件或 Web 通知?Do you support text message, email, or web notifications?

通知中心将通知发送到运行移动应用的设备。Notification Hubs sends notifications to devices running mobile apps. 它不提供电子邮件或短信功能。It does not provide email or text message capabilities. 通知中心也不提供现成的浏览器内推送通知传递服务。Notification Hubs also does not provide an in-browser push notification delivery service out of the box. 客户可以在支持的服务器端平台上使用 SignalR 实现此功能。Customers can implement this feature using SignalR on top of the supported server-side platforms.

如果通过通知中心发送推送通知,可以支持多少个设备?How many devices can I support if I send push notifications via Notification Hubs?

有关支持的设备数目的详细信息,请参阅通知中心定价页。Refer to the Notification Hubs Pricing page for details on the number of supported devices.

如果需要支持超过 1000 万个注册设备,则必须将设备分布到多个命名空间。If you need support for more than 10 million registered devices, you must partition your devices across multiple namespaces.

我可以发送多少推送通知?How many push notifications can I send out?

Azure 通知中心根据系统中通过的通知数量自动向上扩展,具体取决于所选的层。Depending on the selected tier, Azure Notification Hubs automatically scales up based on the number of notifications flowing through the system.


根据发送的推送通知的数量,总体使用成本可能会增加。The overall usage cost can increase based on the number of push notifications sent. 请务必留意通知中心定价页上概述的层限制。Make sure that you're aware of the tier limits outlined on the Notification Hubs Pricing page.

我们的客户每天使用通知中心发送数百万条推送通知。Our customers use Notification Hubs to send millions of push notifications daily. 只要使用 Azure 通知中心,就不需要执行任何特别的操作来调整推送通知可及范围。You do not have to do anything special to scale the reach of your push notifications as long as you're using Azure Notification Hubs.

已发送的推送通知到达我的设备需要多长时间?How long does it take for sent push notifications to reach my device?

在正常使用情况下(传入负载相当一致),Azure 通知中心能够 在 1 分钟内处理至少 100 万次推送通知发送In a normal-use scenario, where the incoming load is consistent and even, Azure Notification Hubs can process at least 1 million push notification sends a minute. 此速率可能因标记数、传入发送的性质以及其他外部因素而有所不同。This rate might vary depending on the number of tags, the nature of the incoming sends, and other external factors.

在预计的传递时间内,服务能计算每个平台的目标,并根据注册的标记或标记表达式将消息路由到推送通知服务 (PNS)。During the estimated delivery time, the service calculates the targets per platform and routes messages to the Push Notification Service (PNS) based on the registered tags or tag expressions. PNS 负责将通知发送到设备。It is the responsibility of the PNS to send notifications to the device.

PNS 对于传递通知不提供任何 SLA 保证。The PNS does not guarantee any SLA for delivering notifications. 但是,大多数推送通知会在发送到通知中心之后的数分钟内(通常在 10 分钟内)传递到目标设备。However, most push notifications are delivered to target devices within a few minutes (typically within 10 minutes) from the time they are sent to Notification Hubs. 少量的通知可能需要更长时间。A few notifications might take more time.


Azure 通知中心有一个策略,可删除任何无法在 30 分钟内传递到 PNS 的推送通知。Azure Notification Hubs has a policy in place to drop any push notifications that aren't delivered to the PNS within 30 minutes. 这一延迟的出现原因有多种,但最常见的是因为 PNS 限制了应用程序。This delay can happen for a number of reasons, but most commonly because the PNS is throttling your application.

是否有任何延迟保证?Is there any latency guarantee?

推送通知的特性(由平台特定的外部 PNS 传递)导致没有延迟保证。Because of the nature of push notifications (they are delivered by an external, platform-specific PNS), there is no latency guarantee. 通常情况下,大部分推送通知会在几分钟内完成传递。Typically, the majority of push notifications are delivered within a few minutes.

设计包含命名空间和通知中心的解决方案时需要考虑哪些因素?What do I need to consider when designing a solution with namespaces and notification hubs?

移动应用/环境Mobile app/environment

  • 为每个环境中的每个移动应用使用一个通知中心。Use one notification hub per mobile app, per environment.
  • 在多租户方案中,每个租户都应具有一个单独的中心。In a multi-tenant scenario, each tenant should have a separate hub.
  • 切勿对生产环境和测试环境使用同一个通知中心。Never share the same notification hub for production and test environments. 这种做法可能导致发送通知时出现问题。This practice might cause problems when sending notifications. (Apple 提供沙盒和生产推送终结点,每个终结点具有单独的凭据。)(Apple offers Sandbox and Production Push endpoints, each with separate credentials.)
  • 默认情况下,可以通过 Azure 门户或 Visual Studio 中的 Azure 集成组件将测试通知发送到已注册的设备。By default, you can send test notifications to your registered devices through the Azure portal or the Azure integrated component in Visual Studio. 阈值设置为从注册池中随机选取的 10 个设备。The threshold is set to 10 devices that are selected at random from the registration pool.


如果中心最初的配置使用 Apple 沙盒证书,后来又使用 Apple 生产证书重新配置,则原始设备令牌会失效。If your hub was originally configured with an Apple sandbox certificate and then was reconfigured to use an Apple production certificate, the original device tokens are invalid. 无效的令牌会导致推送失败。Invalid tokens cause pushes to fail. 请将生产和测试环境分开,针对不同的环境使用不同的中心。Separate your production and test environments, and use different hubs for different environments.

PNS 凭据PNS credentials

将移动应用注册到某个平台的开发人员门户(例如 Apple 或百度)后,将会发送应用标识符和安全令牌。When a mobile app is registered with a platform's developer portal (for example, Apple or Baidu), an app identifier and security tokens are sent. 应用后端将这些令牌提供给平台的 PNS,以便能够将推送通知发送到设备。The app back end provides these tokens to the platform's PNS so that push notifications can be sent to devices. 安全令牌的形式可以是证书(例如,在 Apple iOS 或 Windows Phone 中)或安全密钥(例如,在 Baidu Android 或 Windows 中)。Security tokens can be in the form of certificates (for example, Apple iOS or Windows Phone) or security keys (for example, Baidu Android or Windows). 必须在通知中心内配置安全令牌。They must be configured in notification hubs. 配置通常在通知中心级别完成,但是,也可以在多租户方案中的命名空间级别完成。Configuration is typically done at the notification-hub level, but it can also be done at the namespace level in a multitenant scenario.


命名空间可用于部署分组。Namespaces can be used for deployment grouping. 在多租户方案中,还可以使用命名空间来表示同一应用的所有租户的所有通知中心。They can also be used to represent all notification hubs for all tenants of the same app in a multi-tenant scenario.


在推送通知方案中,地理分布并非总是关键所在。Geo-distribution is not always critical in push notification scenarios. 用于向设备传递推送通知的各个 PNS(例如 APNs 或百度)不会均匀分布。Various PNSes (for example, APNs or Baidu) that deliver push notifications to devices aren't evenly distributed.

如果有一个在全球范围内使用的应用程序,可以在全球不同的 Azure 区域使用通知中心服务在命名空间中创建中心。If you have an application that is used globally, you can create hubs in different namespaces by using the Notification Hubs service in different Azure regions around the world.


我们不建议采用这种做法,因为这会增大管理成本,尤其是注册成本。We don't recommend this arrangement because it increases your management cost, particularly for registrations. 仅当确实有需要时,才采用这种做法。It should be done only if there is an explicit need.

我该从应用后端注册还是直接通过客户端设备注册?Should I do registrations from the app backend or directly through client devices?

在创建注册之前,如果必须对客户端进行身份验证,从应用后端进行注册很有用。Registrations from the app backend are useful when you have to authenticate clients before creating the registration. 如果标记必须由应用后端根据应用逻辑创建或修改,这种注册方法也很有用。They're also useful when you have tags that must be created or modified by the app backend based on app logic. 有关详细信息,请转到后端注册指南后端注册指南 2 页。For more information, go to the Backend Registration guidance and Backend Registration guidance 2 pages.

什么是推送通知传递安全模型?What is the push notification delivery security model?

Azure 通知中心使用基于共享访问签名的安全模型。Azure Notification Hubs uses a shared access signature-based security model. 可以在根命名空间级别或细粒度通知中心级别使用共享访问签名令牌。You can use the shared access signature tokens at the root namespace level or at the granular notification hub level. 可以使用不同的授权规则(例如,发送消息权限,或侦听通知权限)设置共享访问签名令牌。Shared access signature tokens can be set to follow different authorization rules, for example, to send message permissions or to listen for notification permissions. 有关详细信息,请参阅通知中心安全模型文档。For more information, see the Notification Hubs security model document.

如何处理推送通知中的敏感有效负载?How should I handle sensitive payload in push notifications?

所有通知都由平台的 PNS 传递到目标设备。All notifications are delivered to target devices by the platform's PNS. 将通知发送到 Azure 通知中心后,系统会对通知进行处理并将其传递到相应的 PNS。When a notification is sent to Azure Notification Hubs, it is processed and passed to the respective PNS.

从发送方到 Azure 通知中心、再到 PNS 的所有连接都使用 HTTPS。All connections, from the sender to the Azure Notification Hubs to the PNS, use HTTPS.


Azure 通知中心不会记录消息的有效负载。Azure Notification Hubs does not log the payload of messages.

若要发送敏感有效负载,我们建议使用安全推送模式。To send sensitive payloads, we recommend using a Secure Push pattern. 发送方将带有消息标识符的 ping 通知传递到设备,其中不包含敏感有效负载。The sender delivers a ping notification with a message identifier to the device without the sensitive payload. 当设备上的应用收到该有效负载后,可直接调用安全 API 来提取消息详细信息。When the app on the device receives the payload, the app calls a secure API directly to fetch the message details. 有关如何实现此模式的指导,请转到通知中心安全推送教程页。For a guide on how to implement this pattern, go to the Notification Hubs Secure Push tutorial page.


为灾难恢复提供哪种支持?What support is provided for disaster recovery?

我们提供元数据灾难恢复范围(通知中心名称、连接字符串和其他重要信息)。We provide metadata disaster recovery coverage on our end (the Notification Hubs name, the connection string, and other critical information). 触发灾难恢复方案后,注册数据是通知中心基础结构中丢失的 唯一片段When a disaster recovery scenario is triggered, registration data is the only segment of the Notification Hubs infrastructure that is lost. 必须实施某种解决方案,将此数据重新填充到恢复后的新中心:You must implement a solution to repopulate this data into your new hub post-recovery:

  1. 在另一个数据中心创建辅助通知中心。Create a secondary notifications hub in a different data center. 我们建议一开始就创建一个辅助通知中心,以便在发生影响管理功能的灾难恢复事件时保护自己。We recommend creating one from the beginning to shield you from a disaster recovery event that might affect your management capabilities. 也可以在发生灾难恢复事件时创建一个辅助通知中心。You can also create one at the time of the disaster recovery event.

  2. 使用以下选项之一,使辅助通知中心与主通知中心保持同步:Keep the secondary notification hub in sync with the primary notification hub using one of the following options:

    • 使用可在两个通知中心同时创建和更新安装的应用后端。Use an app backend that simultaneously creates and updates installations in both notification hubs. 通过安装,你可以指定自己的唯一设备标识符,从而使其更适合复制方案。Installations allow you to specify your own unique device identifier, making it more suitable for the replication scenario. 有关详细信息,请参阅示例代码For more information, see this sample code.
    • 使用一个应用后端从主通知中心获取注册信息的常规转储作为备份。Use an app backend that gets a regular dump of registrations from the primary notification hub as a backup. 然后,通知中心可以将这些信息批量插入辅助通知中心。It can then perform a bulk insert into the secondary notification hub.

辅助通知中心可能最终会出现安装/注册过期的情况。The secondary notification hub may end up with expired installations/registrations. 当推送到过期的句柄时,通知中心会根据从 PNS 服务器接收到的响应自动清除关联的安装/注册记录。When the push is made to an expired handle, Notification Hubs automatically cleans the associated installation/registration record based on the response received from the PNS server. 若要从辅助通知中心清理过期的记录,请添加自定义逻辑来处理每次发送的反馈。To clean expired records from a secondary notification hub, add custom logic that processes feedback from each send. 然后,使辅助通知中心中的安装/注册过期。Then, expire installation/registration in the secondary notification hub.

如果没有后端,当应用在目标设备上启动时,它们会在辅助通知中心执行新注册。If you don’t have a backend, when the app starts on target devices, they perform a new registration in the secondary notification hub. 辅助通知中心最终将拥有所有已注册的活动设备。Eventually the secondary notification hub will have all the active devices registered.

在一段时间内,包含未打开的应用的设备将收不到通知。There will be a time period when devices with unopened apps won't receive notifications.

我的所有数据是否都以加密形式存储?Is all of my data stored in encrypted form?

Azure 通知中心会加密所有静态的客户数据(注册标记除外)。Azure Notification Hubs encrypts all customer data at rest with the exception of registration tags. 出于此原因,不应使用标记存储个人数据或机密数据。For this reason, you should not store personal or confidential data using tags.

是否有审核日志功能?Is there audit log capability?

是的。Yes. 所有通知中心管理操作都会更新 Azure 门户中公开的 Azure 活动日志。All Notification Hubs management operations update the Azure Activity Log to which is exposed in the Azure portal. Azure 活动日志可使用户了解对订阅中的资源执行的操作。The Azure Activity Log offers insights into the operations performed on resources in your subscriptions. 通过活动日志,可确定对订阅中的资源进行的任何写入操作(PUT、POST、DELETE)的内容、执行者和时间。Using the Activity Log, you can determine the what, who, and when for any write operations (PUT, POST, DELETE) made for the resources in your subscription. 还可以了解操作和其他相关属性的状态。You can also understand the status of the operations and other relevant properties. 但是,However. 活动日志不包括读取 (GET) 操作。the Activity Log does not include read (GET) operation.

监视和故障排除Monitoring and troubleshooting

故障排除功能有哪些?What troubleshooting capabilities are available?

Azure 通知中心提供多项可用于故障排除的功能,尤其是针对通知被删除的最常见情况。Azure Notification Hubs provides several features for troubleshooting, particularly for the most common scenario of dropped notifications. 有关详细信息,请参阅通知中心故障排除白皮书。For details, see the Notification Hubs troubleshooting white paper.

遥测功能有哪些?What telemetry features are available?

Azure 通知中心允许在 Azure 门户中查看遥测数据。Azure Notification Hubs enables viewing telemetry data in the Azure portal. 可以在通知中心指标页上找到有关可用指标的详细信息。Details of the metrics are available on the Notification Hubs Metrics page.

还可以通过编程方式访问指标。You can also programmatically access metrics. 有关详细信息,请参阅以下文章:For more information, see the following articles:


通知成功仅意味着推送通知已传递到外部 PNS(例如,APNs(对于 iOS 和 macOS)或 Baidu(对于 Android 设备))。Successful notifications mean simply that push notifications have been delivered to the external PNS (for example, APNs for iOS and macOS or Baidu for Android devices). PNS 负责将通知传递到目标设备。It is the responsibility of the PNS to deliver the notifications to target devices. PNS 通常不会向第三方公开传递指标。Typically, the PNS does not expose delivery metrics to third parties.