专利名称：向多个目标分发多源推送通知的制作方法
技术领域：
本发明涉及推送通知，尤其涉及向多个目标分发多源推送通知。
背景技术：
背景和相关技术计算机和计算系统已经影响了现代生活的几乎每个方面。计算机通常在工作、休闲、保健、运输、娱乐、家政管理等中都有涉猎。此外，计算系统功能还可以通过计算系统的经由网络连接互连到其他计算系统的能力来增强。网络连接可包括，但不仅限于，经由有线或无线以太网的连接，蜂窝式连接，或者甚至通过串行、并行、USB或其它连接的计算机到计算机的连接。这些连接允许计算系统访问其他计算系统上的服务，并快速且有效地从其他计算系统接收应用数据。开发者可以在iOS、安卓(Android)、视窗手机(Windows Phone)、视窗(Windows )等之上构建移动应用，这些移动应用专注于递送大众感兴趣的新闻、关于世界性事件或足球、橄榄球、曲棍球、棒球联盟或球队的球迷的信息和事实，以使它们保持最新。对于这些应用(以及多种多样的其他应用)中的任何应用而言，在球迷的最喜爱球队得分时或世界上某类新闻事件突发时弹出提醒或祝词(toast)的通知是极大的与众不同者。该与众不同者通常构建和运行服务器基础结构来将这些事件推送到操作系统平台或设备厂商提供的通知渠道中，这超出了专注于优化用户体验的许多移动应用(“app”)开发人员的技能配套。并且如果他们的应用非常成功，则简单的基于服务器的解决方案将迅速触及可伸缩性上限，因为及时地将事件分发给数万或甚至数十万或数百万设备是非常有挑战性的。另外，大量当代移 动应用被编写为通过现有因特网资产的简单体验。例如，新闻应用可以在用户打开应用时即时地显示来自主要新闻提供者的RSS订阅源的最新大标题，而不必导航到网站。独立软件开发者和小的独立软件厂商正在构建大量这样的应用，并且正在以非常低的价格点销售这些应用。对于同样将从推送通知中大大受益的应用而言，不仅事件的分发提出了挑战，而且事件数据的获取也提出挑战，因为获取同样将需要构建和运行非寻常的服务器基础结构。在此要求保护的主题不限于解决任何缺点或仅在诸如上述环境中操作的各个实施例。相反，提供该背景仅用以示出在其中可实践在此描述的部分实施例的一个示例性技术领域。
发明内容
在此所示的一个实施例包括将事件递送给消费者的方法。该方法包括访问专用数据。该方法还包括将专用数据归一化以创建归一化事件。确定基于订阅将接收该事件的多个最终消费者。将来自归一化事件的数据格式化成对每个所确定的最终消费者单独合适的多个不同格式。将来自归一化事件的数据以如下格式递送给所述多个最终消费者中的每个所述格式对各个最终用户合适并且符合由通过其达到消费者的目标基础结构所定义的协议规则。提供发明内容述以便以简化形式介绍将在以下详细描述中进一步描述的一些概念。本发明内容并非旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。另外的特征和优点将在以下的描述中阐述，并且部分可从该描述中显而易见，或者可以从此处的教示实践中习得。本发明的特征和优点可以通过在所附权利要求中特别指出的手段和组合来实现并获取。本发明的特征将从以下描述和所附权利要求书中变得完全显而易见，或者可通过如下所述对本发明的实践而获知。
为了描述可获得本主题的上述和其它优点和特征的方式，将通过参考附图中示出的本主题的具体实施例来呈现以上简要描述的本主题的更具体描述。应该理解，这些附图仅描绘了各典型实施例，因此其不应被认为是对范围的限制，各实施例将通过使用附图用附加特征和细节来描述并解释，在附图中图1示出了一系统的概览，该系统用于收集事件数据、将事件数据映射到通用事件、以及将事件数据分发给各个目标消费者。图2示出了事件数据获取和分发系统；图3示出事件数据获取系统的示例；图4示出事件数据分发系统的示例；图5示出了事件 数据获取和分发系统；图6示出了徽章计数器功能的实施方式；以及图7示出了将事件递送给消费者的方法。
具体实施例方式实施例可以将事件获取系统与通知分发系统和用于将事件映射到通知的映射模型相结合。实施例还能够基于订阅者提供的标准对通知进行过滤。另外，实施例可以具有深度能力，比如以有效方式跟踪各个目标的递送计数。这样的示例在图1中示出。图1示出了来自大量不同源116的信息被递送给大量不同目标102的示例。在一些示例中，来自单个源的信息或从多个源116聚合的信息可被用来创建被递送给大量目标102的单个事件。注意，指示符102可用于共同指代所有目标、或者通常指代单独的目标。具体的各个目标可以由另外的区分符来指示。图1示出了源116。注意，指示符116可用于共同指代所有源、或者通常指代单独的源。具体的各个源可以由另外的区分符来指示。源116例如可以包括多种多样的公共和专用网络服务，包括RSS、Atom和OData订阅源；电子邮件邮箱，包括但不限于这样的支持IMAP和POP3协议；社交网络信息源116，比如推特(Twitter)时间线或脸谱(Facebook)墙；以及外部发布/订阅基础结构上的订阅，比如Windows Azure Service Bus (WindowsAzure服务总线)或Amazon’ s Simple Queue Service (亚马逊简单队列服务)。源116可以用于获取事件数据。如下面将更详细地解释那样，源116可以被组织成获取主题，比如获取主题140 -1。事件数据可以被映射到在104 —般地示出的归一化事件。归一化事件104可以由一个或多个映射模块130映射到针对特定目标102的通知。通知132表示针对目标102的通知。应当理解，单个事件104可以被映射到多个不同的通知，其中所述不同的通知为适于分发给多个不同目标102的不同格式。例如，图1A示出了目标102。目标102支持依赖于目标特性的多个不同的消息格式。例如，一些目标102可以支持中继格式的通知，其他目标102可以支持用于Winttows 7电话的MPNS (Microsoft⑩推送通知服务)格式，其他目标102可以支持用于iOS设备的APN (Apple推送通知)格式的通知，其他目标102可以支持用于安卓(Android)设备的C2DM (云到设备消息收发)格式的通知，其他目标102可以支持用于设备上的浏览器的JSON (Java脚本对象记法)，其他目标102可以支持HTTP (超文本传输协议)的通知，等等。因此，由映射模块130进行的映射可以把从来自一个或多个数据源116的信息中创建的单个事件104映射到针对不同目标102的多个不同通知。不同的通知132然后可以被递送给各个目标102。在一些实施例中，这可以使用图2所示的扇出(fan-out)拓扑来实现。图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的多种不同的格式从各分发分区被发送给目标202。这允许在递送系统的边缘处从共同事件104-1中创建针对各个目标102进行了个别化的个别化通知134，而不是通过该递送系统运送大量个别化的通知。下面示出可在一些实施例中使用的信息收集和事件分发系统的可替代描述。作为基础，一个实施例系统正使用可从华盛顿州雷蒙德市的微软公司获得的Windows Azure Service Bus (Windows Azure服务总线)所提供的发布/订阅基础结构，但该基础结构也可以类似的形式存在于各种其他消息收发系统中。该基础结构提供促进所呈现的方法的所述实现的两种能力主题和队列队列是用于消息的存储结构，它允许以顺序的次序来添加(入队)消息和以与添加消息相同的次序来移除(出队)消息。可由任何数目的并发客户端添加和移除消息，从而允许平抑入队侧的负载并在出队侧的各接收者的范围内平衡处理负载。队列还允许各实体在使消息出队时获取该消息上的锁，从而允许消费客户端显式地控制何时将消息从队列中实际删除、或者在对检索到的消息的处理失败的情况下是否可将它恢复回队列中。主题是具有队列的所有特性的存储结构，但允许多个并发存在的‘订阅’，这些订阅各自允许对入队消息序列的孤立的经过滤的视图。主题上的每个订阅都产生每个入队消息的副本，假定该订阅的 相关联的过滤条件肯定地匹配该消息。因此，入队到具有10个订阅(其中每个订阅具有匹配所有消息的简单的‘穿过’条件)的主题的消息将产生总共10个消息，其中每个订阅一个消息。像队列一样，订阅可具有多个并发消费者，从而提供多个接收者范围内的处理负载的平衡。另一基本概念是‘事件’，它在底层发布/订阅基础结构方面仅仅是消息。在一个实施例的上下文中，事件服从管控消息正文和消息属性的使用的一组简单约束。事件的消息正文一般作为不透明数据块来流动，并且一个实施例所认为的任何事件数据一般在消息属性中流动，它是作为表示该事件的消息的一部分的一组键/值对。现在参考图3，一个实施例基础结构的目标是大规模地从各种各样的不同源116获取事件数据，并将这些事件转发到发布/订阅基础结构以供进一步处理。处理可包括某种形式的分析、实时搜索、或通过拉或推通知机制将事件重新分发到感兴趣的订阅者。一个实施例基础结构定义了获取引擎118，用于获取适配器和事件归一化(normalization)的模型，用于保持关于获取源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)的扩展可以实现保留复杂类型结构和数据但不会复杂化基础事件模型的映射模型。一些实施例归一化到正则的紧凑复杂数据(像JS0N)表示，并将复杂的数据属性(例如复杂数据类型“人”的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 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中由‘I’、省略号、以及‘η’所示，处理角色中的每一个可具有该处理角色的一个或多个实例。注意，在应用于处理角色时，在每一情况下使用‘η’应被认为是与另一情况不同，这意味着处理角色中的每一个不必具有相同数目的实例。‘分发引擎’ 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格式来递送给Windows 7电话、按APN(Apple Push Notification(Apple推送通知))格式递送给iOS设备、按C2DM (Cloud To Device Messaging (云到设备消息收 发))格式递送给安卓设备、按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示出通过分发主题144将 获取分区140耦合到分发分区120的系统概览图示。如上所述，在一些实施例中，可以从来自源116的信息中创建通用事件104。通用事件可以以通用格式来生成，使得在以后，数据可以被生成并置于平台专用的格式。现在在下面示出可以把在一个实施例中实现的通用事件属性映射到特定平台通知的表达的多个示例。$ (name)或者(name)或者> (name)对具有给定名称(name)的事件属性的引用。属性名称不是大小写敏感的。如果所引用的属性的至包含JSON串表达形式的复杂类型数据，则属性名称可以是“点”表达(例如属性.项目)。该表达解析成属性的文本值或者在属性不存在示解析成空串。该值可以根据目标字段的目标大小约束而被修剪。$ (name, η)像上面那样，但是文本在η字符处被显式地修剪，例如$ (title, 20)将标题属性的内容修剪在20个字符。. (name, η)像上面那样，但是文本被加上三个点的后缀，因为其被修剪。经修剪的串和后缀的总大小将不超过η个字符。具有“这是标题行”的输入属性的.(title，20)产生‘这是标题…’。%(name)像$ (name)那样，只是输出是经加密的URI。$/body是指事件的实体本体。实体本体(entity body)不是可修剪的，因为其可能包含包括二进制数据在内的任意数据并且穿过现有的系统。如果$body被映射到目标上的文本属性，则在一些实施例中该映射仅当该本体包含文本内容时才会成功。如果实体本体为空，则表达解析成空串。$Count是指从给定源递送的事件的每目标的计数。该表达解析成由系统计算出的数字，该数字表示相应目标自从上次请求对该计数器进行复位以来已经从该源116接收了多少消息。在一些示例性实施例中，该数字具有从O至99的范围。已经计数器达到了 99，则其不再递增。该值通常被用于徽章和标题计数器。. text...或.text...是文字。文字包含被封装在单引号或双引号中的任意文本。文本可以包含根据转义规则的转义形式的特殊字符。(参见ECMA-262，7. 8. 4)exprl+expr2是将两个表达加入单个串的串接运算符。所述表达可以是以上任何表达。exprl expr2是条件运算符，其在exprl不为O或O长度串的情况下对exprl求值并且在其他情况下对expr2求值。？？运算符比+运算符具有更高优先级、即表达V +$ (a) $ (b)将产生以文字V为前缀的a或b的值。实施例可以使用映射语言来从事件104取得属性，并且将它们映射到正确的位置以用于目标102上的通知
权利要求
1.一种将事件(104)传递给消费者的方法，该方法包括 访问专用数据(702); 将所述专用数据归一化以创建归一化的事件(I04) (704)； 确定基于订阅将接收事件(104)的多个最终消费者(706)； 将来自归一化的事件(104)的数据格式化成对全部所确定的最终消费者合适的多个不同格式(708);以及 将来自归一化的事件(104)的数据以对所述最终消费者合适的格式递送给所述多个最终消费者中的每个(710)。
2.如权利要求1所述的方法，其特征在于，访问专用数据包括从多个源访问数据。
3.如权利要求1所述的方法，其特征在于，将来自归一化的事件的数据以对所述最终消费者合适的格式递送给所述多个最终消费者中的每个包括首先以所述归一化的格式扇出来自所述事件的数据。
4.如权利要求1所述的方法，其特征在于，将来自归一化的事件的数据以对所述最终消费者合适的格式递送给所述多个最终消费者中的每个包括将所述事件打包到多个束中，其中所述束中的每个都包括所述归一化的格式的所述事件以及路由名单，所述路由名单标识多个最终消费者，包括为所述路由名单中所标识的最终用户标识格式。
5.如权利要求4所述的方法，其特征在于，将所述事件打包到多个束中包括询问数据库，以通过参考所述数据库中的最终消费者偏好来确定哪些最终用户被包括在所述路由名单中。
6.如权利要求1所述的方法，其特征在于，将所述专用数据归一化以创建归一化的事件包括将所述数据表示成键值对，所述对由单个不透明二元数据块伴随，事件归一化系统不进一步解释所述单个不透明二元数据块。
7.如权利要求1所述的方法,其特征在于,将来自归一化的事件的数据格式化成对全部所确定的最终消费者合适的多个不同格式包括通过映射具有相同名称的消息属性来将来自所述归一化的事件的一个或多个属性映射到格式。
全文摘要
本发明涉及向多个目标分发多源推送通知。将事件递送给消费者。一种方法包括访问专用数据。该方法还包括将专用数据归一化以创建归一化事件。确定基于订阅将接收该事件的多个最终消费者。将来自归一化事件的数据格式化成对全部所确定的最终消费者合适的多个不同格式。将来自归一化的事件的数据以对最终消费者合适的格式递送给多个最终消费者中的每个。
文档编号H04L29/08GK103051667SQ20121033513
公开日2013年4月17日 申请日期2012年9月11日 优先权日2011年9月12日
发明者C·F·瓦斯特斯 申请人:微软公司