CN103051465B - 对广播系统徽章计数器的计数和重置 - Google Patents

Abstract

对广播系统徽章计数器的计数和重置。将来自服务器的徽章计数器提供给消费者。徽章计数器指示多个通知。一种方法包括接收事件序列中的一个事件。该事件具有相关联的时间戳。该方法还包括将该事件与来自事件序列中在该事件之前发生的事件的多个附加时间戳相关联。该方法还包括为终端用户消费者设备创建通知，该通知包括对基于多个附加时间戳的徽章计数器的指示。该方法还包括将包括徽章计数器值的通知发送给消费者设备。

Description

对广播系统徽章计数器的计数和重置

技术领域

本发明涉及通信技术，尤其涉及对计数器进行计数和重置的技术。

背景技术

背景和相关技术

计算机和计算系统已经影响了现代生活的几乎每个方面。计算机通常在工作、休闲、保健、运输、娱乐、家政管理等中都有涉猎。

此外，计算系统功能还可以通过计算系统的经由网络连接互连到其他计算系统的能力来增强。网络连接可包括，但不仅限于，经由有线或无线以太网的连接，蜂窝式连接，或者甚至通过串行、并行、USB或其它连接的计算机到计算机的连接。这些连接允许计算系统访问其他计算系统上的服务，并快速且有效地从其他计算系统接收应用数据。

许多计算机意在通过与计算机的直接用户交互来使用。这样，计算机具有输入硬件和软件用户接口以促成用户交互。例如，现代通用计算机可包括用于允许用户向计算机输入数据的键盘、鼠标、触摸垫、相机等。另外，有各种软件用户接口可用。

软件用户接口的示例包括图形用户界面、基于文本命令行的用户界面、功能键或热键用户界面等等。

如苹果公司为iOS(APNs)所提供的、或微软公司为Windows Phone(MPNS)所提供的移动推送通知系统允许服务器发送通知以包括所谓的“徽章计数器”，“徽章计数器”在该电话的用户界面上引起表示（数字）计数器值的视觉指示。电话平台有意地对如何解释该值不作结论，但该值通常用于指示有多少已到达的消息用户尚未阅读之类的事实。然而，更准确地，徽章计数器可反映自用户上一次打开应用或与应用交互以来所接收到的消息数量。例如，用户可接收多个电子邮件，其中每一电子邮件与徽章计数器值一起被发送，该徽章计数器值随着每一电子邮件被发送而递增。用户随后可打开电子邮件应用，且实际上没有阅读任一个电子邮件，但这仍然导致要将指示用户已看过电子邮件的消息发送给向用户发送电子邮件的服务器。服务器将基于这一消息来重置徽章计数器。从服务器所发送的后续电子邮件将包括从该重置所递增的徽章计数器。

在此要求保护的主题不限于解决任何缺点或仅在诸如上述环境中操作的各个实施例。相反，提供该背景仅用以示出在其中可实践在此描述的部分实施例的一个示例性技术领域。

发明内容

此处所示的一个实施例涉及一种向消费者提供来自服务器的徽章计数器的方法。徽章计数器指示多个通知。该方法包括接收事件序列中的一个事件。该事件具有相关联的时间戳。该方法还包括将该事件与来自事件序列中该事件之前发生的事件的多个附加时间戳相关联。该方法还包括为终端用户消费者设备创建通知，该通知包括对基于多个附加时间戳的徽章计数器的指示。该方法还包括将包括徽章计数器值的通知发送给消费者设备。

提供本发明内容以便以简化形式介绍将在以下详细描述中进一步描述的一些概念。本发明内容并非旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。

另外的特征和优点将在以下的描述中阐述，并且部分可从该描述中显而易见，或者可以从此处的教示实践中习得。本发明的特征和优点可以通过在所附权利要求中特别指出的手段和组合来实现并获取。本发明的特征将从以下描述和所附权利要求书中变得完全显而易见，或者可通过如下所述对本发明的实践而获知。

附图说明

为了描述可获得本主题的上述和其它优点和特征的方式，将通过参考附图中示出的本主题的具体实施例来呈现以上简要描述的本主题的更具体描述。应该理解，这些附图仅描绘了各典型实施例，因此其不应被认为是对范围的限制，各实施例将通过使用附图用附加特征和细节来描述并解释，在附图中：

图1示出徽章计数器功能的实现；

图2示出事件数据获得和分发系统；

图3示出事件数据获得系统的示例；

图4示出事件数据分发系统的示例；以及

图5示出提供徽章计数器的方法。

具体实施例

徽章计数器值通常由服务器提供，但通常反映与应用的用户有关的专用状态条件及其对通知以及与事件有关的应用的特定消费。这些计数器可对广播系统提出特别困难的挑战，这些广播系统将单个事件（诸如体育分数或股票报价）扇出（fan out）至数千或甚至数百万个目标，并且出于缩放能力和吞吐量原因而不能承受使用数据库更新来跟踪每一用户的当前计数器。如果服务器必需跟踪每一用户的当前计数器，则将共同消息扇出到多个用户的几乎所有益处被消除，因为需要为用户中的每一个维护单独状态。

所描述的某些实施例允许在事件广播系统中跟踪单独计数器，而无需对每一终端用户的计数器进行单独跟踪。这可由接收一系列事件的服务器来完成，其中该系列中的每一事件都与时间戳列表相关联。每一事件的时间戳列表包括该事件的时间戳和该系列中所有先前事件的时间戳。

用户将时间戳发送给服务器。时间戳是用户何时在用户设备处执行过某一用户交互的指示符。例如，时间戳可以是用户何时在设备上打开过一应用的指示。服务器将用户所发送的时间戳与快要发送给用户的事件的时间戳列表作比较。服务器在时间戳列表中对用户发送时间戳之后发生的、快要发送给用户的事件的时间戳数量进行计数，并且发送这一计数作为徽章计数器。

所附图1中示出一示例。图1示出目标102-1。目标102-1从递送引擎108-1接收事件104和徽章计数器106。目标102-1将时间戳110发送给递送引擎108-1。目标102-1向递送引擎108-1发送的时间戳110可基于目标102-1处的某一动作。例如，用户可打开与递送引擎108-1向目标102-1发送的事件104和徽章计数器106相关联的应用。打开应用可导致时间戳110从目标102-1被发送到递送引擎108-1，指示何时打开过应用。

递送引擎108-1接收一系列112事件（如104-1、104-2、104-3和104-n所示）。该系列112事件中的每一事件分别与时间戳的列表114-1、114-2、114-3或114-n相关联。时间戳的每一列表包括当前事件的时间戳、以及该系列中当前事件之前的每一事件的时间戳。在所示示例中，事件104-1是向递送引擎108-1发送的供递送给目标的第一事件。由此，与事件104-1相关联的列表114-1包括与事件104-1被发送到递送引擎108-1的时间相对应的单个条目T1。在事件104-1之后将事件104-2发送到递送引擎108-1，并且由此事件104-2与包括对应于事件104-1和104-2何时被分别发送到递送引擎108-1的时间戳T1和T2的列表114-2相关联。在事件104-2之后将事件104-3发送到递送引擎108-1，并且由此事件104-3与包括对应于事件104-1、104-2和104-3何时被分别发送到递送引擎108-1的时间戳T1、T2和T3的列表114-3相关联。在事件104-3（且可能如列表114-n中省略号所指示的多个其他事件）之后将事件104-n发送到递送引擎108-1，并且由此事件104-n与包括对应于事件104-1、104-2、104-3至104-n何时被分别发送到递送引擎108-1的时间戳T1、T2、T3至Tn的列表114-n相关联。

假设目标102-1没有将任何时间戳110发送到递送引擎108-1。当递送引擎发送事件104-1时，它也会发送对应于T1的值为1的徽章计数器。当递送引擎发送事件104-2时，它也会发送对应于两个时间戳T1和T2的计数的值为2的徽章计数器。当递送引擎发送事件104-3时，它也会发送对应于三个时间戳T1、T2和T3的计数的值为3的徽章计数器。当递送引擎发送事件104-n时，它也会发送对应于n个时间戳T1至Tn的计数的值为n的徽章计数器。

现在假设目标发送带有发生在时间T2和T3之间的绝对时间的时间戳110。在这一点处有可能事件104-1和104-2已经被递送到目标102-1。当事件104-3被发送到目标时，递送引擎108-1在确定徽章计数器的值时，仅对发生在时间戳110之后的时间戳进行计数。由此，在这一场景中递送引擎108-1将对应于T3（因为事件T1和T2发送在时间戳110之前）的值为1的徽章计数器连同事件104-3一起发送。这一过程可使用从目标102-1接收到的被用来确定徽章计数器值的最新近的时间戳110来重复。

如上所述，各实施例在其中单个事件被散发到多个（并且可能是大量的）最终用户的消息散发系统中尤其有用。这样的示例在图2中示出。图2示出了来自大量不同源的信息被递送给大量不同目标的示例。在一些示例中，来自单个源的信息或从多个源聚集的信息可被用来创建被递送给大量目标的单个事件。在一些实施例中，这可以使用所附图2所示的扇出拓扑来实现。

图2示出了源116。如本文稍后将讨论的，实施例可以利用获取分区140。获取分区140中的每一个可包括多个源116。可能存在大量且各种各样的源116。源116提供信息。这些信息可包括例如但不限于电子邮件、文本消息、实时股票报价、实时赛事比分、新闻更新，等等。

图2示出了每一分区包括获取引擎，如说明性的获取引擎118。获取引擎118从源116收集信息，并基于该信息来生成事件。在图2所示的示例中，多个事件被示为由获取引擎使用各个源来生成。使用事件104-1来进行说明。在一些实施例中，事件104-1可如以下解释的那样来标准化。获取引擎118可以是诸如因特网等网络上从该网络上的源116收集信息的服务。

图2示出了事件104-1被发送给分发主题144。分发主题144将事件散发给多个分发分区。分发分区120-1被用作所有分发分区的类似物。各分发分区各自服务由订阅所表示的多个终端用户或设备。分发分区所服务的订阅的数量可与其他分发分区所服务的数量不同。在一些实施例中，分区所服务的订阅的数量可取决于分发分区的能力。作为替换或补充，分发分区可被选择来基于与终端用户的逻辑或地理邻近度来服务用户。这可允许以更加及时的方式将警报递送给最终用户。

在所示示例中，分发分区120-1包括分发引擎122-1。分发引擎122-1咨询数据库124-1。数据库124-1包括关于订阅的信息并具有关于相关联的递送目标102的细节。具体而言，该数据库可包括信息，诸如描述目标102的平台的信息、目标102所使用的应用、目标102的网络地址、使用目标102的终端用户的用户偏好，等等。使用数据库124-1中的信息，分发引擎122-1构建包126-1，其中包126-1包括事件104（或至少来自事件104的信息）和标识目标102中的要将来自事件104-1的信息作为通知发送到的多个目标102的路由名单128-1。包126-1随后被置于队列130-1中。

分发分区120-1可包括多个递送引擎。递送引擎使各个包从队列130-1中出队并将通知递送给目标102。例如，递送引擎108-1可从队列130-1中取出包126-1并将事件104信息发送给路由名单128-1中标识的目标102。因而，包括事件104-1信息的通知134能以适用于不同目标102并专用于单独目标102的多种不同的格式从各分发分区被发送给目标102。这允许在递送系统的边缘处从共同事件104-1创建针对各单独目标102来个别化的个别化通知134，而非携带大量个别化的通知穿过该递送系统。

下面示出可在一些实施例中使用的信息收集和事件分发系统的替换描述。

作为基础，一个实施例系统正使用可从华盛顿州雷蒙德市的微软公司获得的Windows Azure Service Bus（Windows Azure服务总线）所提供的发布/订阅基础结构，但该基础结构也可以类似的形式存在于各种其他消息收发系统中。该基础结构提供便于所呈现的方法的所描述的实现的两种能力：主题和队列

队列是用于消息的存储结构，它允许以顺序的次序来添加消息（入队）和以与添加消息相同的次序来移除消息（出队）。可由任何数量的并发客户机添加和移除消息，从而允许利用入队侧的负载并跨出队侧的各接收者来平衡处理负载。队列还允许各实体在使消息出队时获得该信息上的锁，从而允许消费客户机对何时将消息从队列中实际删除或在对检索到的消息的处理失败的情况下它是否可被恢复回队列中进行显式控制。

主题是具有队列的所有特性的存储结构，但允许多个并发的现有‘订阅’，这些订阅各自允许对入队消息序列的孤立的经过滤的视图。主题上的每一订阅产生每一入队消息的副本，假定该订阅的相关联的过滤条件肯定地匹配该消息。因此，入队到具有10个订阅（其中每一订阅具有匹配所有消息的简单的‘穿过’条件）的主题的消息将产生总共10个消息，每个订阅一个消息。像队列一样，订阅可具有多个并发消费者，提供跨各接收者的处理负载的平衡。

另一基本概念是‘事件’，它在底层发布/订阅基础结构方面仅仅是消息。在一个实施例的上下文中，事件服从管控消息正文和消息属性的使用的一组简单约束。事件的消息正文一般作为不透明数据块来流动，并且一个实施例所认为的任何事件数据一般在消息属性中流动，它是作为表示该事件的消息的一部分的一组键/值对。

现在参考图3，一个实施例基础结构的目标是大规模地从各种各样的不同源116获取事件数据，并将这些事件转发到发布/订阅基础结构以供进一步处理。处理可包括某种形式的分析、实时搜索、或通过拉或推通知机制将事件重新分发到感兴趣的订阅者。

一个实施例基础结构定义了获取引擎118，用于获取适配器和事件归一化的模型，用于保持关于获取源116的元数据的分区存储138，公共分区和调度模型，以及用于在运行时如何使获取源116状态的用户发起的改变流入系统而无需进一步的数据库查找的模型。

在具体实现中，获取可支持具体的获取适配器从各种各样的公共和私有联网服务中获取事件，联网服务包括RSS、Atom和OData订阅源，包括但不限于这种支持IMAP和POP3协议的电子邮件邮箱，像Twitter时间线或Facebook墙的社交网络信息源116，以及对像Windows Azure Service Bus（Windows Azure服务总线）或Amazon’s Simple QueueService（Amazon简单队列服务）的外部发布/订阅基础结构的订阅。

事件归一化

归一化事件数据以使事件可由订阅者正被移交到的发布/订阅基础结构上的订阅者实际可以消费的。归一化意味着，在本上下文中，事件被映射到具有对信息项的一致表示的共同事件模型上，在各种上下文中各个订阅者可能对该信息项感兴趣。此处所选择的模型是键/值对的平面列表形式的事件的简单表示，该键/值对可由系统不进一步解释的单个不透明二元数据块伴随。该事件表示在大多数发布/订阅基础结构上是轻松地可表示的，并且还非常清楚地映射到诸如HTTP的常见因特网协议。

为了示出事件归一化，考虑RSS或Atom订阅源入口到事件104的映射（参见图1和2）。RSS和Atom是两个因特网标准，它们通常非常广泛地用于按时间次序发布新闻和其他当前的信息，并且有助于使该信息可用于计算机程序中以结构化方式的处理。RSS和Atom共享非常类似的结构以及一组命名不同但语义相同的数据元素。因此，第一个归一化步骤是为在两个标准中定义的这种语义相同的元素定义公共名称，像标题或提要。第二，通常用相应的“本地”名称来映射仅出现在一个标准中但未出现在另一个标准中的数据。除此之外，这些种类的订阅源通常带有“扩展”，该扩展是未在核心标准中定义、但使用相应标准中的可扩展性工具来添加额外数据的数据项。

以跨不同事件源116共享的常见方式来映射这些扩展中的一些（包括但不限于用于地理位置的GeoRSS或将结构化数据嵌入到Atom订阅源中的OData），使得向其发射事件的发布/订阅基础结构上的订阅者可按照统一的方式来解释地理位置信息，而不论是否已经从RSS或Atom或Twitter时间线获取了数据。继续GeoRSS示例，表示地理“点”的简单GeoRSS表达式可因此被映射到表示WGS84坐标的一对数字“纬度”/“经度”属性。

带有复杂的结构化数据（诸如OData）的扩展可以实现保留复杂类型结构和数据但不会复杂化基础事件模型的映射模型。一些实施例归一化到正则的紧凑复杂数据（像JSON）表示，并将复杂的数据属性（例如复杂数据类型“人”的OData属性“承租人”）映射到键/值对，其中键是属性名“承租人”，并且值是用姓名、生物信息、和以JSON序列化形式表示的地址信息来描述人的复杂数据。如果数据源是XML文档，像它在RSS或Atom的情形中那样，则可通过将XML数据转录到保留XML所提供的结构的JSON中，但使XML特性（像属性和元素）扁平化来创建值，意味着将同一XML元素节点的下属的XML属性和元素二者映射到JSON属性作为没有进一步区别的“兄弟”。

源和分区

一个实施例基础结构在“源描述”记录中捕捉关于数据源116的元数据，该记录可被存储在源数据库138中。“源描述”可具有一组公共元素和一组数据源专用的元素。公共元素可包括源的名称、源116被认为是有效的期间的时间跨度间隔，人类可读的描述，以及供区别的源116的类型。源专用元素取决于源116的类型并可包括网络地址、凭证或获得对该地址所表示的资源的访问的其他安全关键材料、以及元数据，该元数据指导源获取适配器以特定方式执行数据获取（像提供时间间隔以供检查RSS订阅源）、或以特定方式执行时间转发（诸如，将从当前事件新闻订阅源获取的事件间隔开至少60秒），使得如果这是要构建的端到端的体验，则通知接收者有机会在受限的屏幕表面上观看每个爆炸性新闻条目。

在诸如源数据库138的一个或多个存储中保持源描述。可在这些存储内沿两个不同的粥跨存储地对源描述进行分区。

第一个轴是系统承租人的区别。系统承租人或“名字空间”是在系统内为实体创建隔离范围的机制。示出一个具体的情形，如果“Fred”是实现一个实施例的系统的用户，则Fred将能够创建为Fred提供隔离的虚拟环境的承租人范围，该虚拟环境可完全独立于系统中其他源116地保持源描述和配置和状态。这个轴可作为区别因素来跨各存储地传播源描述，尤其是在承租人需要隔离（可包括诸如密码的安全敏感数据的）已存储的元数据，或出于技术、管理或商业原因的情形中。系统承租人还可表示与一个特定数据中心的亲合性，在该数据中心中保持源描述，并且在那里执行数据获取。

第二个轴可以是从预定义标识符范围中选择的数字分区标识符的区别。可从源描述包含的不变量中得出分区标识符，诸如源名称和承租人标识符。可使用散列函数（许多候选之一是Jenkins散列，参见http://www.burtleburtle.net/bob/hash/doobs.html）从这些不变量中得出分区标识符，并且可对散列值使用模函数，来向下计算所得的散列值直到分区标识符范围。将标识符范围选择为比预期存储该系统中曾保持的全部源描述所需要的最大数量的存储分区更大（并且可以是显著地更大）。

引入存储分区通常由容量限制来激励，该容量限制要么立即与底层数据存储上的存储容量配额相关，要么与影响获取引擎118的容量限制（诸如，给定数据中心或数据中心部分的带宽约束）相关，这可导致实施例创建跨不同数据中心或数据中心部门地利用容量以满足入门带宽需求的获取分区140。存储分区拥有整个标识符范围的子集，并且可因此从其分区标识符中直接推断源描述记录与存储分区（和访问该分区的资源）的关联。

除提供存储分区轴以外，分区标识符还用于调度或获取任务，以及清晰地定义获取分区140对给定源描述的所有权关系（可能与对存储分区的关系不同）。

所有权和获取分区

系统中的每个源描述可由特定的获取分区140所拥有。使用清晰且唯一的所有权，因为系统不需要并行地来自多个位置中确切的同一源116的事件，这可能会导致发射双重事件。为了使这点更具体，在承租人范围内定义的一个RSS订阅源由系统中的正好一个获取分区140所有，并且在分区内，在时间的任意给定点上存在在特定订阅源上运行的一个已调度的获取。

获取分区140通过获得分区标识符范围的所有权的方式来获得源描述的所有权。可以使用可具有故障转移功能并可分配主/备份所有者的外部专用分区系统，或使用分区标识符范围在担任获取引擎角色的不同计算实例的数量之间均匀分散的更简单的机制，来为获取分区140分配标识符范围。在具有外部分区系统的更高级的实现中，如果系统从“冷”状态启动，意味着该分区尚没有前一个所有者，则分区的所选的主所有者负责播种对任务的调度。在较简单的场景中，拥有分区的计算实例拥有对调度的播种。

调度

获取任务的调度需求取决于具体源的性质，但通常存在两种类型的获取模型，该获取模型在一些所描述的实施例中实现。

在第一个模型中，所有者在源的网络服务上启动某种形式的连接或长期运行的网络请求，并在该连接上等待数据报或流形式的数据被返回。在通常也被称为长期轮询的长期运行的请求的情形中，源网络服务将保存该请求直到发生超时或直到数据变为可用—进而，获取适配器将等待用或不用负载结果来完成该请求，并随后重发该请求。因此，该获取调度模型具有“紧”循环的形式，该循环在源116的所有者得知源的时候得以初始化，并且其中在当前连接或请求完成或被临时中断时，新的请求或连接立即被初始化。由于所有者直接控制紧循环，因此该循环可在所有者正在运行时可靠地保持存活。如果所有者停止并重新启动，则该循环也重新启动。如果所有者改变，则循环停止，并且新的所有者启动该循环。

在第二个模型中，源的网络服务不支持长期运行的请求或在数据变为可用时产生该数据的连接，但是是无论何时查询都立即返回的常规的请求/响应服务。在这些服务中，这一点应用于许多web资源，以持续的紧循环来请求数据导致源116上的巨大量的负载，并且也导致显著的网络流量，该网络流量要么仅指示源116尚未改变，要么在最糟的情形中反复地携带相同的数据。为了平衡及时的事件获取的需求并且不用无效的查询流量使源116过载，获取引擎118将由此在“定时的”循环中执行请求，其中基于间隔周期性地执行源116上的请求，该间隔平衡那些考虑并且还考虑了来自源116的提示。“定时的”循环在源116的所有者得知源的时候被初始化。

存在定时循环的两个值得注意的实现变型。第一个变型用于低规模、最大努力场景，并使用本地、存储器内的定时对象来调度，这使规模、控制和重新启动特性与紧循环的那些特性相类似。该循环被初始化，并立即调度使获取任务的第一次迭代运行的定时器回调。当该任务完成（即使有错误）并且确定该循环将继续执行时，在接下来即将执行任务的瞬间调度另一个定时器回调。

第二个变型使用经调度的消息摂，这是包括Windows Azure^TM Service Bus的若干发布/订阅系统的一个特征。该变型以稍高的复杂度为代价提供显著更高的获取比例。调度循环由所有者来初始化，并且将消息置于获取分区的调度队列中。该消息包括源描述。它接下来由执行获取任务的工人拾取，并随后将所得的事件入队到目标发布/订阅系统中。最后，它还将新的“经调度的”消息入队到调度队列中。该消息被称为“经调度的”，因为它是用它变为可用于供调度队列上的任何消费者检索的时间瞬间来标记的。

在该模型中，获取分区140可通过具有一个主要播种调度并且可与执行实际获取任务的任意数量的“工人”角色配对的“所有者”角色而被扩展。

源更新

在系统运行时，获取分区140需要能够得知要观察的新的源116以及将不再观察哪个源116。除了（下面描述的）由于检测到的不可恢复的或临时的错误而将源116列入黑名单的情形以外，关于这一点的决定通常在于用户，并且是与管理服务142交互的结果。为了传递这种改变，获取系统在底层发布/订阅基础结构中维护“源更新”主题。每个获取分区140具有针对该主题的专用订阅，该订阅具有过滤条件，该过滤条件将适合的消息约束为携带获取分区所拥有的范围内的分区标识符的那些消息。这使管理服务142能够设置关于新的或已引退的源116的更新，并将它们发送到正确的分区140，而不需要分区所有权分布的知识。

管理服务142将更新命令提交到包括源描述、分区标识符（出于前述的过滤目的）、和操作标识符的主题，该操作标识符指示是否要添加源116或者是否从系统中移除源116。

一旦获取分区140所有者已检索到命令消息，则要么它将为新的源116调度新的获取循环，要么它将中断并挂起、或甚至使现有的获取循环引退。

列入黑名单

可将数据获取失败的源116临时地或永久地列入黑名单。当源116网络资源不可用或返回与所发起的获取请求不直接相关的错误时，执行临时列入黑名单。临时列入黑名单的持续时间取决于错误的性质。通过中断常规的调度循环（紧或定时）并在期望另一方解决错误条件的时间瞬间调度循环的下一次迭代（经由回调或经调度的消息），来执行临时列入黑名单。

当确定错误是获取请求的直接结果时执行永久列入黑名单，意味着该请求正导致认证或授权错误、或远程的源116指示某个其他请求错误。如果将资源永久列入黑名单，则在分区存储中将源116标记为已列入黑名单，并立即中止获取循环。恢复永久列入黑名单的源116需要移除存储中的黑名单标记，可能还有引起请求的行为改变的配置改变，并且经由源更新主题来重新启动获取循环。

通知分发

各实施例可被配置成将来自给定输入事件的信息的副本分发给与特定范围相关联的大量“目标102”中的每一个，并且对于每一目标102在最小的时间中这样做。目标102可包括耦合到适配器的标识符的设备或应用的地址和用于访问该通知系统或基础结构的辅助数据，其中该适配器到某第三方通知系统或某网络可访问的外部基础结构。

一些实施例可包括被分成三个不同的处理角色的体系结构，这些角色在下文中详细描述并且可参考图4来理解。如图4中由‘1’、……、以及‘n’所示，处理角色中的每一个可具有该处理角色的一个或多个实例。注意，在应用于处理角色时，在每一情况下使用‘n’应被认为是与另一情况不同，这意味着处理角色中的每一个不必具有相同数量的实例。‘分发引擎’112角色接受事件并将它们与包含各组目标102的路由名单（参见例如图2中的路由名单128-1）绑定。‘递送引擎’108接受这些绑定并处理路由名单以递送给由目标102所表示的各网络位置。由管理服务142所示出的‘管理角色’提供管理目标102的外部API，并且还负责接受来自递送引擎108的统计数据和出错数据并负责处理/存储该数据。

数据流锚定在‘分发主题144’上，各事件被提交到该主题以供分发。所提交的事件是使用消息属性来用它们相关联的范围进行标记的，这可以是将事件与原始消息进行区分的上述约束之一。

在所示示例中，分发主题144对于每一‘分发分区120’具有一个穿过（未过滤）订阅。‘分发分区’是负责向给定范围的目标102的子集分发并递送通知的被隔离的资源集合。发送到分发主题中的每一事件的副本对所有并发地配置的分发分区而言通过它们相关联的订阅实际上是同时可用的，从而允许分发工作的并行化。

通过划分分区（partitioning）来达到的并行化帮助实现及时的分发。为理解这一点，考虑具有一千万个目标102的范围。如果目标的数据被保持在未经分区的存储中，则该系统将必须顺序地遍历单个的大型数据库结果集，或者如果结果集是使用对同一存储进行的分区查询来获得的，则用于获取目标数据的吞吐量将至少被给定存储的前向（fronting）网络网关基础结构的吞吐量上限所扼制，结果，将通知递送给其描述记录在给定结果集中发生得非常晚的目标102的递送等待时间将可能是不令人满意的。

相反，如果一千万个目标102分散在1000个存储上，每一存储保持10000个目标记录，并且这些存储与像在此描述的那样以分区的形式执行查询并处理结果的专用计算基础结构（本文描述的‘分发引擎122’和‘递送引擎108’）配对，则对目标描述的获取可以在很大一组计算和网络资源上并行化，从而显著地降低分发所有事件时从所分发的第一到最后事件所测量到的时间差。

分发分区的实际数量在技术上没有限制。它的范围可以从单个分区到大于一的任何数量的分区。

在所示示例中，一旦分发分区120的‘分发引擎122’获得了事件104，它首先计算事件数据的大小并随后计算路由名单128的大小，这可基于事件大小与底层消息收发系统的可允许的最大消息大小和绝对大小上限中的较小者之间的增量来计算。以如下方式来限制事件的大小：有某一最小的头上空间来容纳‘路由名单’数据。

路由名单128是包含目标102描述的列表。路由名单由分发引擎122通过对分区的存储124中保持的目标102执行匹配该事件的范围的查找查询来创建，从而返回与该事件的范围和基于事件数据的过滤条件来缩小选择的一组进一步条件相匹配的所有目标102。各实施例可包括将结果限制为在当前时刻被认为有效的目标102的时间窗口条件，这意味着当前UTC时间处于目标描述记录中包含的开始/结束有效时间窗口内，以及其他过滤条件。这一设施被用于黑名单，这在本文中稍后描述。在遍历查找结果时，该引擎创建事件104的副本，用从存储124中检索到的目标描述将路由名单128填充到最大大小，并随后将所得的事件包和路由名单排入该分区的‘递送队列130’中。

路由名单技术确保从分发引擎122到递送引擎108的事件的事件流速高于底层基础结构上的实际消息流速，意味着例如在30个目标描述可连同事件数据一起打包到路由名单128中的情况下，事件/目标对的流速是事件/目标对被直接编组到消息中的情况的30倍。

递送引擎108是来自递送队列130的事件/路由名单绑定126的消费者。递送引擎108的角色要使这些绑定出队，并将事件104递送给路由名单128中列出的所有目的地。递送通常通过将事件消息格式化成相应目标基础结构所理解的通知消息的适配器来发生。例如，通知消息可按MPNS格式来递送给7电话、按APN（Apple Push Notification（苹果推送通知））格式递送给iOS设备、按C2DM（Cloud To Device Messaging（云到设备消息收发））格式递送给Android设备、按JSON（Java Script Object Notation（Java脚本对象记法））格式递送给设备上的浏览器、按HTTP（超文本传输协议）来递送，等等。

递送引擎108通常使递送在各独立的目标102上并行化，并且使递送在共享由目标基础结构所实施的范围的各目标102上串行化。后一情况的示例是递送引擎中的特定适配器可选择通过单个网络连接发送以特定通知平台上的特定目标应用为目标的所有事件。

使用递送队列130将分发引擎122和递送引擎108解除耦合，以允许递送引擎108的独立伸缩并避免递送减速倒退回并阻塞分发查询/打包阶段。

每一分发分区120可具有并发地观察递送队列130的任何数量的递送引擎实例。递送队列130的长度可被用来确定多少递送引擎是并发地活动的。如果队列长度超过特定阈值，则可向分区120添加新递送引擎实例以增加发送吞吐量。

分发分区120和相关联的分发和递送引擎实例能以实际上无限的方式来伸缩，以达到大规模的最优并行化。如果目标基础结构能够接收并以并行的方式向各设备转发一百万个事件请求，则所描述的系统能够跨其递送基础结构来分发事件——可能利用跨各数据中心的网络基础结构和带宽——以用事件提交来使目标基础结构饱和以供像目标基础结构在负载不足且在给定的任何授予的递送限额之下所允许的那样及时地递送给所有所需目标102的方式。

在经由其相应基础结构适配器将消息递送给目标102时，在一些实施例中，该系统记录一些统计信息条目。这些统计信息条目包括接收到递送绑定与递送出任何单独消息之间的持续时间的测量到的时间段以及实际发送操作的持续时间的测量到的时间段。统计信息的另一部分是递送是成功还是失败的指示符。这一信息被收集在递送引擎108内并在逐个范围的基础上和逐个目标-应用的基础上积累成平均值。‘目标应用’是所引入的用于统计信息累积的具体目的的编组标识符。计算得到的平均值以所定义的时间间隔被发送到递送状态队列146。该队列由管理服务142中的一（组）工作者来排空，它出于各种目的来将事件数据提交给数据仓库。这些目的可包括，除操作监控以外，对向其递送事件的承租人记账和/或将统计信息公开给承租人以供第三方自己记账。

在检测到递送错误时，这些错误被分类成临时和永久错误状况。临时错误状况可包括例如不准许该系统达到目标基础结构的递送点的网络故障或目标基础结构报告已经临时达到了递送限额。永久错误状况可包括例如目标基础结构上的认证/授权错误或不能在没有手动干预的情况下复原的其他错误以及其中目标基础结构报告该目标不再可用或该目标想要在永久的基础上接受消息的错误状况。一旦被分类，错误报告就被提交到递送故障队列148。对于临时错误状况，该错误还可包括绝对UTC时间戳，直至该错误状况预期要被解决为止。同时，对于这一递送引擎实例所进行的任何进一步本地递送，该目标被目标适配器在本地列入黑名单。该黑名单也可包括时间戳。

递送故障队列148由管理角色中的一（组）工作者来排空。永久错误可使得相应目标从管理角色能访问的其相应分发分区存储124中立即删除。‘删除’意味着该记录确实被移除或者另选地通过将该记录的有效性时间段的‘结束’时间戳设置成该错误的时间戳来使该记录仅仅被移出查找查询的视线。临时错误状况可使得目标在该错误所指示的时间段期间被停用。可以通过将目标的有效性时间段的开始上移到该错误所指示的时间戳来完成停用，在该所指示的时间戳处预期该错误状况将复原。

以下讨论现涉及可以执行的多种方法以及方法动作。虽然用特定次序讨论或用以特定次序发生的流程图示出了各个方法动作，但除非明确规定否则不需要特定次序，或因为一动作依赖于另一动作在执行该动作之前完成而需要特定次序。

现在参考图5，示出了将来自服务器的徽章计数器提供给消费者的方法500。徽章计数器指示多个通知。方法500包括接收事件序列中的一个事件，该事件具有相关联的时间戳（动作502），该情况的一个示例在图1中示出。例如，事件104-3可与时间戳T3相关联。方法500还包括将该事件与来自事件序列中该事件之前发生的事件的多个附加时间戳相关联（动作504）。该情况的一个示例在图1中示出，该示例示出了将附加时间戳T1和T2与事件104-2相关联。

方法500还包括为终端用户消费者设备创建通知，该通知包括对基于多个附加时间戳的徽章计数器的指示（动作506）。图1示出了包括事件104和徽章计数器106的通知。

方法500还包括向消费者设备发送包括徽章计数器值的通知（设备508）。图1示出了要将事件104和徽章计数器106发送到目标102-1。

可以实施方法500的实施例，其中发送包括徽章计数器的通知包括发送受到最大值限制的徽章计数器值。例如，徽章计数器的最大值可以是受到由最终用户消费者设备的特定平台所指定的最大徽章计数器值限制的依赖平台的值。例如，某些平台将徽章计数器值的大小限于99。

可以实施方法500的实施例，其中徽章计数器值基于由消费者检查通知流导致的重置时间戳。例如，用户可检查设备上的通知，这导致时间戳（诸如时间戳110）被发回到服务器。徽章计数器可基于该重置时间戳，诸如通过仅对与重置时间戳之后发生的事件相关联的时间戳进行计数。

另选地或另外地，可以实施方法500的实施例，其中徽章计数器值基于由消费者打开应用导致的重置时间戳。例如，用户打开与徽章计数器相关联的应用可导致时间戳被发回服务器，其中此后的徽章计数器值基于该时间戳。

另选地或另外地，可以实施方法500的实施例，其中徽章计数器值基于由用户指定的时间窗口。例如，用户可指定时间窗以便能够确定在特定时间帧内发生的事件数量。

另选地或另外地，可以实施方法500的实施例，其中徽章计数器值基于时间戳的总计数的徽章计数器值。在这一示例中，徽章计数器值表示特定流内总的所有时间的通知数量。

此外，各种方法可由包括一个或多个处理器和诸如计算机存储器等计算机可读介质的计算机系统来实施。具体而言，计算机存储器可存储计算机可执行指令，这些指令在由一个或多个处理器执行时使得诸如各实施例中所述的各个动作等各种功能被执行。

本发明的各实施例可以包括或利用包含计算机硬件的专用或通用计算机，这将在下文中更详细地讨论。本发明范围内的各实施例还包括用于承载或存储计算机可执行指令和/或数据结构的物理和其他计算机可读介质。这样的计算机可读介质可以是可由通用或专用计算机系统访问的任何可用介质。存储计算机可执行指令的计算机可读介质是物理存储介质。承载计算机可执行指令的计算机可读介质是传输介质。由此，作为示例而非限制，本发明的各实施例可包括至少两种显著不同的计算机可读介质：物理计算机可读存储介质和传输计算机可读介质。

物理计算机存储介质包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储（如CD、DVD等）、磁盘存储或其他磁存储设备、或可用于存储计算机可执行指令或数据结构形式的所需程序代码装置且可由通用或专用计算机访问的任何其他介质。

“网络”被定义为允许在计算机系统和/或模块和/或其他电子设备之间传输电子数据的一个或多个数据链路。当信息通过网络或另一个通信连接（硬连线、无线、或者硬连线或无线的组合）传输或提供给计算机时，该计算机将该连接适当地视为传输介质。传输介质可包括可用于携带计算机可执行指令或数据结构形式的所需程序代码装置且可由通用或专用计算机访问的网络和/或数据链路。以上介质的组合也被包括在计算机可读介质的范围内。

此外，在到达各种计算机系统组件时，以计算机可执行的指令或数据结构的形式存在的程序代码装置可以自动地从传输计算机可读介质传输到物理计算机可读存储介质（或者反之亦然）。例如，通过网络或数据链路接收到的计算机可执行指令或数据结构可被缓存在网络接口模块（例如，“NIC”）内的RAM中，然后最终被传送到计算机系统RAM和/或计算机系统处的较不易失性的计算机可读物理存储介质。因此，计算机可读物理存储介质可被包括在同样（或甚至主要）利用传输介质的计算机系统组件中。

计算机可执行指令包括，例如使通用计算机、专用计算机、或专用处理设备执行某一功能或某组功能的指令和数据。计算机可执行指令可以是例如二进制代码、诸如汇编语言之类的中间格式指令、或甚至源代码。尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述特征或动作。相反，上述特征和动作是作为实现权利要求的示例形式而公开的。

本领域的技术人员将理解，本发明可以在具有许多类型的计算机系统配置的网络计算环境中实践，这些计算机系统配置包括个人计算机、台式计算机、膝上型计算机、消息处理器、手持式设备、多处理器系统、基于微处理器的或可编程消费电子设备、网络PC、小型计算机、大型计算机、移动电话、PDA、寻呼机、路由器、交换机等等。本发明也可在其中通过网络链接（或者通过硬连线数据链路、无线数据链路，或者通过硬连线和无线数据链路的组合）的本地和远程计算机系统两者都执行任务的分布式系统环境中实施。在分布式系统环境中，程序模块可位于本地和远程存储器存储设备中。

本发明可具体化为其他具体形式而不背离其精神或特征。所描述的实施例在所有方面都应被认为仅是说明性而非限制性的。因此，本发明的范围由所附权利要求书而非前述描述指示。落入权利要求书的等效方案的含义和范围内的所有改变被权利要求书的范围所涵盖。

Claims (8)

1.一种将来自服务器的徽章计数器发送到消费者的方法，所述徽章计数器指示多个通知：

接收来自终端用户消费者设备的第一时间戳，所述时间戳是何时执行过终端用户交互的指示符；

标识时间戳列表，所述时间戳列表包括多个时间戳，所述多个时间戳包括与事件序列中的事件相关联的时间戳，其中每一事件被扇出至多个终端用户消费者设备处的多个不同终端用户，以使得不需要对每一个所述终端用户执行对计数器的单独跟踪；

在所述时间戳列表中标识在所述第一时间戳之后出现的时间戳；

为终端用户消费者设备创建通知，所述通知包括对基于所述在所述第一时间戳之后出现的时间戳的数量的徽章计数器值的指示，以使能够基于所接收到的第一时间戳创建用于每个不同终端用户消费设备的不同徽章计数器，而不需要对每一个所述终端用户单独跟踪徽章计数器；以及

向所述消费者设备发送所述事件序列中时间戳在所述第一时间戳之后的第一个事件和包括徽章计数器值的通知。

2.如权利要求1所述的方法，其特征在于，发送包括徽章计数器的通知包括发送受到最大值限制的徽章计数器值。

3.如权利要求2所述的方法，其特征在于，所述最大值是受到与所述终端用户消费者设备的特定平台所指定的最大徽章计数器值限制的依赖平台的值。

4.如权利要求2所述的方法，其特征在于，所述最大值是99。

5.如权利要求1所述的方法，其特征在于，其中徽章计数器值基于由消费者检查通知流所引起的重置时间戳。

6.如权利要求1所述的方法，其特征在于，其中徽章计数器值基于由消费者打开应用所引起的重置时间戳。

7.如权利要求1所述的方法，其特征在于，其中徽章计数器值基于由用户所指定的时间窗口。

8.如权利要求1所述的方法，其特征在于，其中徽章计数器值基于时间戳的总计数。