CN109903178B - 一种确定共同社交对象的方法、装置、系统及计算设备 - Google Patents

Abstract

本发明公开了一种确定共同社交对象的方法、装置、系统及计算设备，属于数据处理技术领域，用于提高共同社交对象的计算效率。该方法包括：获得社交平台中的M个社交用户中的每个社交用户的好友列表，该社交平台中的所有社交用户的社交对象列表是按照预设分配策略分配到节点集群中的各个节点中存储，而社交对象列表包括好友列表；按照预设委托策略，针对每个社交用户，确定每个社交用户的好友列表中的委托用户；再从节点集群中确定用于存储每个委托用户的社交对象列表的节点；并将该社交用户的社交对象列表发送给每个委托用户所匹配的节点，以请求匹配的节点根据接收到的社交对象列表确定对应委托用户与该社交用户之间的共同社交对象。

Description

一种确定共同社交对象的方法、装置、系统及计算设备

技术领域

本发明涉及数据处理技术领域，尤其涉及一种确定共同社交对象的方法、装置、系统及计算设备。

背景技术

社交平台中的共同好友、共同阅读、共同玩过的游戏等共同社交对象作为一种社交特征，可以有效应用于数据分析、好友推荐、用户画像、社交广告等场景。例如，若丙是甲和乙的共同好友，那么在广告推荐中，根据甲和乙的偏好，能够为丙提供推荐依据；在社交场景中，共同好友间会经常查看动态和互动，例如甲和乙均能同时查看丙所发布的动态，丙查看过的一些信息可以推荐给甲和乙，也就是说，覆盖到甲、乙、丙三者中的任何一个则可以起到推广到三者的目的；在游戏场景中，稳定好友关系的甲、乙、丙可能会经常开黑，或者，当甲、乙均玩耍某款游戏应用时，那么为丙再推荐这款游戏时，丙接受推荐的可能性也较大，所以可以获得较好的推荐效果。

要应用共同社交对象这种社交特征，首先需要准确的计算社交网络中的各好友对之间的共同社交对象，而随着社交网络规模的迅速增大，例如，有些社交平台已经拥有超过10亿用户，海量的用户对应上千亿对好友，所以亟需一种计算全量关系链下的海量用户对的共同社交对象的方法。

发明内容

本申请实施例提供一种确定共同社交对象的方法、装置、系统及计算设备，用于提高确定共同社交对象的效率。

一方面，提供一种确定共同社交对象的方法，所述方法包括：

获得社交平台中的M个社交用户中的每个社交用户的社交对象列表，其中，所述社交平台中的所有社交用户的社交对象列表按照预设分配策略分配到节点集群中的各个节点上存储，社交对象列表为与社交用户之间有社交关系的社交对象的集合，社交对象列表包括社交用户的好友列表，M为大于或等于1的整数，且M小于所述所有社交用户的总数；

按照预设委托策略，针对所述M个社交用户中的每个社交用户，从该社交用户的好友列表中确定委托用户；

从所述节点集群中确定用于存储每个委托用户的社交对象列表所匹配的节点；并

将该社交用户的社交对象列表发送给每个委托用户所匹配的节点，以请求匹配的节点根据接收到的社交对象列表确定对应委托用户与该社交用户之间的共同社交对象。

在一种可能的设计方式中，在满足计算共同社交对象的触发条件时，则按照所述预设委托策略，针对所述M个社交用户中的每个社交用户，从该社交用户的好友列表中确定委托用户。

在一种可能的设计方式中，获得社交平台中的M个社交用户中的每个社交用户的社交对象列表，包括：

获得所述M个社交用户分别对应的社交活动关联数据；

根据获得的社交活动关联数据，分别构建针对所述M个社交用户中的每个社交用户的社交对象列表。

在一种可能的设计方式中，针对所述M个社交用户中的每个社交用户，从该社交用户的好友列表中确定委托用户，包括：

遍历该社交用户的好友列表，以从该好友列表中确定社交对象列表存储在本节点的非委托用户；

从该好友列表中除去非委托用户的剩余用户中确定委托用户。

一方面，提供一种确定共同社交对象的装置，所述装置包括：

获得模块，用于获得社交平台中的M个社交用户中的每个社交用户的社交对象列表，其中，所述社交平台中的所有社交用户的社交对象列表按照预设分配策略分配到节点集群中的各个节点存储，社交对象列表为与社交用户之间有社交关系的社交对象的集合，社交对象列表包括社交用户的好友列表，M为大于或等于1的整数，且M小于所述所有社交用户的总数；

第一确定模块，用于按照预设委托策略，针对所述M个社交用户中的每个社交用户，从该社交用户的好友列表中确定委托用户；

第二确定模块，用于从所述节点集群中确定用于存储每个委托用户的社交对象列表的节点；

委托模块，用于将该社交用户的社交对象列表发送给每个委托用户所匹配的节点，以请求匹配的节点根据接收到的社交对象列表确定对应委托用户与该社交用户之间的共同社交对象。

在一种可能的设计方式中，所述装置还包括：

接收模块，用于接收所述节点集群中的其它节点根据所述预设委托策略发送的至少一个社交对象列表，其中，所述至少一个社交对象列表为N个社交用户的社交对象列表，在所述N个社交用户中的社交用户的好友列表中均包括属于所述M个社交用户的委托用户，N为大于或等于1的整数，且N小于所述所有社交用户的总数；

第三确定模块，用于根据所述至少一个社交对象列表，确定属于所述M个社交用户的委托用户与所述N个社交用户之间的共同社交对象。

在一种可能的设计方式中，所述第一确定模块用于：

根据社交用户的用户标识的取值，从该社交用户的好友列表中确定取值大于或小于该社交用户的用户标识的取值的社交用户，并将确定出的社交用户确定为该好友列表中的委托用户；或者，

根据节点的节点标识的取值，从该社交用户的好友列表中确定好友列表存储的节点的取值大于或小于本节点的取值的社交用户，并将确定出的社交用户确定为该好友列表中的委托用户，其中，所述本节点为存储所述M个社交用户的社交对象列表的节点。

在一种可能的设计方式中，所述装置还包括第四确定模块，用于：

从所述节点集群中确定可委托节点，其中，所述可委托节点的数量为所述节点集群的节点总数的一半；

则，所述第二确定模块用于：

从所述可委托节点中确定用于存储每个委托用户的社交对象列表的节点。

在一种可能的设计方式中，所述节点集群中的每个节点具有唯一的节点标识，所述节点集群中的所有节点按照节点标识具有预定排列顺序，所述节点集群的节点总数为K，K为大于或等于2的整数；

则，所述第四确定模块用于：

若K为奇数，则根据所述预定排列顺序，将与本节点依次相邻的(K-1)/2个节点确定为所述可委托节点；

若K为偶数，则根据所述预定排列顺序，将与本节点依次相邻的K/2个节点或(K-2)/2个节点确定为所述可委托节点；

其中，所述本节点为存储所述M个社交用户的好友列表的节点。

在一种可能的设计方式中，若K为偶数，所述节点集群中的K/2个节点中的每个节点按照所述预定排列顺序，将与该节点依次相邻的(K-2)/2个节点确定为所述可委托节点，以及所述节点集群中剩余的K/2个节点中的每个节点按照所述预定排列顺序，将与该节点依次相邻的K/2个节点确定为所述可委托节点。

在一种可能的设计方式中，所述委托模块用于：

若所述M个社交用户中的至少两个社交用户对应的至少两个社交对象列表存储在同一个节点，且所述至少两个社交用户的好友列表中均包括委托用户，则将所述至少两个社交对象列表合并处理为一条信息后发送。

在一种可能的设计方式中，所述委托模块用于：

若该社交用户的好友列表中的至少两个委托用户所匹配的节点为同一个节点，则针对所述至少两个委托用户，只向匹配的节点发送一次该社交用户的社交对象列表。

在一种可能的设计方式中，所述M个社交用户中的每个社交用户与该社交用户的好友之间的共同社交对象的确定过程对应一个计算任务，与所述M个社交用户对应的M个计算任务中的至少两个计算任务并行执行。

在一种可能的设计方式中，每个计算任务划分为至少两个子任务，每个子任务通过调用不同的线程执行，其中，根据每个子任务的执行时长分配对应的线程数量，子任务的执行时长和线程数量呈正相关关系。

在一种可能的设计方式中，采用SIMD向量化方式确定两个社交用户对应的两个社交对象列表中的交集元素，并将确定出的交集元素确定为所述两个社交用户之间的共同社交对象。

一方面，提供一种确定共同社交对象的系统，所述系统包括至少两个计算节点，所述至少两个计算节点中的每个计算节点均采用上述任一种确定共同好友的方法确定共同社交对象，以分别获得共同社交对象计算结果，以及，每个计算节点将获得的共同社交对象计算结果发送给存储节点。

一方面，提供一种即时通信系统，所述即时通信系统包括即时通信服务器、分布式存储集群和共同社交对象计算集群，所述即时通信服务器和所述共同社交对象计算集群均与所述分布式存储集群连接，其中：

所述共同社交对象计算集群包括至少两个计算节点，每个计算节点均采用上述任一种确定共同社交对象的方法确定共同社交对象，以分别获得共同社交对象计算结果，并将获得的共同社交对象结果发送给所述分布式存储集群；

所述分布式存储集群用于存储共同社交对象计算结果；

所述即时通信服务器从所述分布式存储集群获得所述共同社交对象计算结果，并基于所述共同社交对象计算结果向即时通信客户端进行关联推荐。

一方面，提供一种计算设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述各方面中的确定共同社交对象的方法包括的步骤。

一方面，提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行上述各方面中的确定共同社交对象的方法包括的步骤。

本申请实施例中，针对计算共同好友的节点集群中的任意一个节点来说，在获得社交平台中的部分社交用户(例如M个社交用户)中的每个社交用户的好友列表之后，可以按照预设委托策略，确定每个社交用户的好友列表中的委托用户，即，确定每个社交用户的好友列表中需要委托给其它节点进行共同社交对象计算的用户，然后从节点集群中确定出用于存储每个委托用户的社交对象列表的节点，并将社交用户的社交对象列表发送给每个委托用户所匹配的节点，以请求对应匹配的节点根据接收到的社交对象列表和委托用户的社交对象列表，确定每个委托用户与该社交用户之间的共同社交对象，以完成两个用户之间的共同类的计算，从而，节点集群中的每个节点则可以通过预设委托策略将自身原本需要执行的共同类计算任务委托给其它节点执行，从而可以减少节点之间的通信开销和等待时间，进而提高共同社交对象的计算效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例中的社交平台中的多个社交用户的关系链的示意图；

图2为本申请实施例中的好友关联数据的示意图；

图3为本申请实施例中的好友列表的示意图；

图4a为本申请实施例中的社交对象列表的一种表示方式的示意图；

图4b为本申请实施例中的社交对象列表的另一种表示方式的示意图；

图5为本申请实施例中的一种应用场景的示意图；

图6为本申请实施例中的另一种应用场景的示意图；

图7为本申请实施例中的确定共同社交对象的方法的流程图；

图8为本申请实施例中的存储在节点集群中的社交用户的好友列表的示意图；

图9为本申请实施例中的确定共同社交对象的方法的另一流程图；

图10为本申请实施例中的确定委托用户的两种策略的示意图；

图11为本申请实施例中的采用流水并行机制执行计算任务的示意图；

图12为本申请实施例中的确定共同好友的方法的流程图；

图13为本申请实施例中的采用SIMD向量化技术确定两个好友列表之间的交集用户的示意图；

图14为本申请实施例中的确定共同社交对象的系统的架构示意图；

图15为本申请实施例中的即时通信系统的架构示意图；

图16为本申请实施例中的确定共同社交对象的装置的结构框图；

图17为本申请实施例中的计算设备的一种结构示意图；

图18为本申请实施例中的计算设备的另一种结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互任意组合。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本申请的说明书和权利要求书及上述附图中的术语“第一”和“第二”是用于区别不同对象，而非用于描述特定顺序。此外，术语“包括”以及它们任何变形，意图在于覆盖不排他的保护。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本申请中的“多个”可以表示至少两个，例如可以是两个、三个或者更多个，本申请实施例不做限制。

另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，在不做特别说明的情况下，一般表示前后关联对象是一种“或”的关系。

以下对本文中涉及的部分用语进行说明，以便于本领域技术人员理解。

1、社交平台，可以理解为是个人的社交关系网络，社交平台可以包括社交网站或者社交应用(Application，APP)等形式，用户可以在社交平台上申请自己的社交账户，并且可以与其他社交账户建立社交关系，例如建立社交好友关系。

2、社交用户，是指社交平台中的用户，不同的社交用户可以使用各自的社交账户在社交平台上进行交互，从而可以维持社交关系。

3、社交活动关联数据，是指社交用户在社交平台中进行的社交活动相关的数据，社交活动例如包括好友聊天、查看资讯、关注公众号、加入群组及参与群组聊天、玩游戏、使用小程序，等等。通过某个社交用户的社交活动关联数据，可以确定该社交用户在社交平台中参与的社交活动的类型以及每种社交活动的具体参与情况。

根据参与的社交活动的类型不同，社交活动关联数据可以包括多种关联数据，例如好友关联数据、游戏关联数据、资讯关联数据、群组关联数据等。

4、好友关联数据，如上所述，好友关联数据是一种具体的社交活动关联数据，好友关联数据是指社交平台中与某个社交用户的好友相关联的数据，换言之，好友关联数据是指用于表征社交用户的社交好友的用户数据。例如，好友关联数据包括社交好友在社交平台中的用户标识，其中的用户标识是用于在该社交平台中唯一指示社交用户的标识，例如用户身份(identification，ID)、编号或者用户昵称，等等。通过一个社交用户的好友关联数据，可以确定该社交用户的社交好友。

请参见图1所示，图1例如为某一社交平台中的多个社交用户的关系链的示意图，图1包括A、B、C、D、E、F、G、H、I这9个社交用户及其对应的社交关系链。以其中的A为例，其社交好友包括B、C、D、E、F这5个社交用户，再以H为例，其社交好友包括B、G、I这3个社交用户，等等。

再参见图2所示，图2示出了图1中的各个社交用户的好友关联数据。以其中的A为例，A的好友关联数据为(A，B)、(A，C)、(A，D)、(A，E)、(A，F)，其中的(A，B)表示A的一个社交好友是B，当然同时也可以表示B的一个社交好友是A，等等，通过A的好友关联数据可以确定出A的社交好友包括B、C、D、E、F；再以其中的E为例，E的好友关联数据为(E，A)、(E，B)、(E，F)，其中的(E，F)表示E的一个社交好友是F，当然同时也可以表示F的一个社交好友是E，等等，通过E的好友关联数据可以确定出E的社交好友包括A、B、F。可见，通过图2所示的好友关联数据可以表明各个社交用户的所有社交好友。

5、社交对象，是指在社交平台中，社交用户在进行社交活动的过程中所关联的社交元素，也就是说，社交对象为与社交用户之间有社交关系的对象，需要说明的是，这里所说的“社交关系”是从广义的角度来说的，即在社交平台中，社交用户单方向交互或者双向交互的对象。

例如，社交用户可以与多个社交好友聊天，那么这里进行聊天的社交好友即可以理解为是一种社交对象；又例如，社交用户可以查看各种资讯或者阅读小说，那么这里的资讯和小说也可以理解为是一种社交对象；又例如，社交用户可以关注公众号或使用小程序，那么这里关注的公众号和使用的小程序也可以理解为是一种社交对象；还例如，社交用户可以加入群组。那么这里加入的群组也可以理解为是一种社交对象；再例如，社交用户可以下载并参与社交平台内提供的游戏或者可以使用社交账户授权登录其它平台的游戏，那么这里的游戏也可以理解为是一种社交对象，等等。

如上所说的社交平台中的社交好友、资讯、小说、公众号、小程序、群组、游戏都可以理解为是本申请实施例中的社交对象，可见，社交对象不仅包括用户(人)，还可以包括其它与社交用户有关联的事物。

6、社交对象列表，是指包括多个社交对象的集合，一个社交用户可以包括一个或多个社交对象列表。

以好友列表为例，一个社交用户的好友列表可以理解为是该社交用户的所有社交好友的集合，具体来说，可以根据社交用户的所有好友关联数据构建出该社交用户的好友列表。请参见图3，图3示出了图1中的所有社交用户的好友列表。其中，以用户A为例，A的好友列表以“A：B，C，D，E，F”表示，其他均是类似的表示方式，通过A的好友列表可以确定出A的所有社交好友为B，C，D，E，F这5个社交用户。

其它社交对象列表可以采用与好友列表类似的表示方式，例如用户A的阅读列表可以“A：阅读1，阅读2，阅读3”表示，以及用户A的游戏列表可以“A：游戏1、游戏2、游戏3”表示，等等。例如参见图4a的社交对象列表，图4a示出了用户A的所有类型的社交活动中的关联对象，根据用户A的小程序列表即“A：小程序010，小程序011，小程序111”可知，用户A使用过的小程序包括小程序010、小程序011、小程序111这三种小程序；根据用户A的游戏列表即“A：游戏aa，游戏bb，游戏cc，游戏dd”可知，用户A玩过的游戏包括游戏aa、游戏bb、游戏cc、游戏dd这四种游戏。

如图4a所示的，用户A的所有社交对象列表包括在一张表中，即一个社交用户的所有社交对象列表可以通过一份文件表示，在具体实施过程中，还可以如图4b所示的，用户A的各个社交对象列表分别是以不同的列表表示，也就是说，一个社交用户的各个社交对象列表也可以相互独立表示。

7、共同社交对象，是指同一社交平台中的两个(或者更多个)社交用户之间共有的社交对象，更具体的来说，是指互为好友的两个社交用户(即好友对)之间共同的社交对象。

以共同好友为例，是指同一社交平台中的两个互为好友的社交用户之间共有的社交好友，换言之，共同好友是针对至少两个社交用户而言的。以图1或图3为例，可见D既是A的社交好友，同时也是B的社交好友，所以D就是A和B的共同好友。

以共同阅读为例，是指同一社交平台中的两个互为好友的社交用户均阅读过的资讯、小说等信息。例如张三和李四互为好友，张三的阅读列表是“张三：资讯1，小说xx，资讯8，资讯66”，而李四的阅读列表是“李四：资讯1，小说yy，资讯25，资讯66”，可见，张三和李四均阅读过的是“资讯1”和“资讯66”，所以张三和李四之间的共同阅读则是“资讯1、资讯66”。

再以共同群为例，是指同一社交平台中的两个互为好友的社交用户均加入的群组。例如张三和李四互为好友，张三的群组列表是“张三：勤劳妈妈辅食群，小宝宝推拿兴趣群，专利撰写提高群，老张家内部群”，以及李四的群组列表是“李四：勤劳妈妈辅食群，小宝宝推拿兴趣群，提高沟通质量群，老李家亲戚群”，可见，张三和李四的共同群组是“勤劳妈妈辅食群、小宝宝推拿兴趣群”。

8、消息传递接口(Message Passing Interface，MPI)，是一个跨语言的通讯协议，用于编写并行计算程序，支持点对点和广播。MPI是一个信息传递应用程序接口，包括协议和语义说明，它们指明其如何在各种实现中发挥其特性。MPI的目标是高性能，大规模性和可移植性。

9、非统一内存访问(Non Uniform Memory Access，NUMA)，是一种用于多处理器的电脑记忆体设计，内存访问时间取决于处理器的内存位置。通过NUMA可以把一台计算机分成多个节点，每个节点内部使用共有的内存控制器，节点之间是通过互联模块进行连接和信息交互。在NUMA下，处理器访问它自己的本地存储器的速度比非本地存储器(存储器的地方到另一个处理器之间共享的处理器或存储器)快一些。

10、单指令多数据流(Single Instruction Multiple Data，SIMD)，能够复制多个操作数，并把它们打包在大型寄存器的一组指令集。基于SIMD向量化技术，指令译码后几个执行部件可以同时访问内存，一次性获得多个操作数进行运算，换言之，通过SIMD向量化技术，可以将计算粒度从单个元素转换为向量，而一个向量可以包括至少两个(例如一般是4个)元素，进而可以提升计算性能，提高计算效率。

以下介绍本申请的设计思想。

如前所述的，由于共同好友、共同阅读等共同社交对象这些社交特征的应用越来越广泛，并且随着社交规模的逐渐增大，例如目前的一些社交平台已经达到1亿甚至10亿级别的社交用户了，鉴于此，需要一种计算全量关系链下的海量用户对的共同社交对象的方法，以准确、高效地计算出各个社交平台中的所有好友对之间的共同社交对象。

目前的计算共同社交对象的方式，计算节点之间的小消息交互量太大，共同社交对象的计算效率较低。以共同社交对象是共同好友为例，例如通过一个节点集群(或者又称作计算机集群)来计算同一社交平台中的所有好友对之间的共同好友，以节点集群中的第一节点和第二节点为例来说明现有的计算好友对的共同好友的方法，假设第一节点中存储有如图3中所示的用户A的好友列表，以及第二节点中存储有如图3中所示的用户B的好友列表。

对于第一节点来说，通过用户A的好友列表可知用户A包括B、C、D、E、F这5个好友，在需要计算共同好友时，则需要分别计算A与B之间、A与C之间、A与D之间、A与E之间、A与F之间的共同好友。以计算A与B之间的共同好友为例，首先，第一节点需要确定出用于存储用户B的好友列表节点(例如是第二节点)，进一步地，第一节点向第二节点发送“请求用户B的好友列表”的请求，然后，第二节点根据接收到的请求向第一节点发送用户B的好友列表(即B：C，D，E，G，H，I)，第一节点在接收到用户B的好友列表之后，再计算用户A的好友列表(即A：B，C，D，E，F)和用户B的好友列表之间的交集，进而得到两个好友列表的交集是(C，D，E)，则表明用户A和用户B的共同好友是用户C、D、E。至此，完成了一个好友对之间的共同好友的计算。对于其它好友对的共同好友的计算，均采用上述方式进行。

在现有的共同好友计算方式中，当需要计算某个好友对之间的共同好友时，当前的计算节点需要先向其它节点发起获得用户的好友列表的请求，然后再等待其它节点返回相应的好友列表，所以每次计算过程都伴随着“请求-接收”两次网络通信，对于整个节点集群来说，则会产生大量的小消息，小消息传输频繁，会影响整体的计算效率，并且在每次“请求”之后还会间隔一定的等待时间才能接收到其它节点返回的好友列表，等待过程导致时间浪费，进一步地降低了计算效率。可见，现有的确定共同好友的方式的计算效率较低，这一问题在包括10亿级社交用户的社交平台中显得更为突出。

与计算共同好友类似的，其它的共同社交对象的计算方法亦是如此。

通过对现有技术进行分析，本发明人发现导致共同社交对象的计算效率低下的主要原因就是如上所说的“请求-接收”的频繁网络通信，并且消息一来一回会造成等待时间浪费，鉴于此，本发明人考虑到可以利用好友的对称性，以共同好友为例，可以利用“我和你的共同好友”等价于“你和我的共同好友”的好友对称特性，当前计算节点将计算共同好友的任务委托给需要计算的好友对中的对方好友所在的节点来执行，这样可以避免不必要的“请求好友列表”的通信开销，还可减少发送请求之后的等待时间的浪费，提升整体计算效率。

继续以上述第一节点、第二节点为例，当第一节点要计算用户A与用户B之间的共同好友时，可以直接将用户A的好友列表发送给第二节点，以委托第二节点来计算用户A与用户B之间的共同好友，而第二节点计算出的是用户B与用户A之间的共同好友，利用上述所说的好友对称特性，第二节点计算出的“用户B与用户A之间的共同好友”就等价于第一节点需要计算出的“用户A与用户B之间的共同好友”，进而减小“请求好友列表”的通信开销，避免了“请求”之后的等待时间的浪费，提高了共同好友的计算效率。

基于上述技术构思，本发明人提出了一种确定共同社交对象的技术方案，具体来说，针对计算共同社交对象的节点集群中的任意一个节点来说，在获得社交平台中的部分社交用户(例如M个社交用户)中的每个社交用户的好友列表之后，可以按照预设委托策略，确定每个社交用户的好友列表中的委托用户，即，确定每个社交用户的好友列表中需要委托给其它节点进行共同社交对象计算的用户，然后从节点集群中确定出用于存储每个委托用户的社交对象列表的节点，以社交用户A为例，进一步的可以将社交用户A的社交对象列表发送给社交用户A的好友列表中的每个委托用户所匹配的节点，以请求匹配的节点根据接收到的社交对象列表来计算各个委托用户与社交用户A之间的共同社交对象，例如可以计算每个委托用户与社交用户A之间的共同好友、共同阅读、共同群组、共同玩过的游戏，等等。这样，节点集群中的每个节点均可以通过预设委托策略将自身原本需要执行的共同社交对象计算任务委托给其它节点执行，从而可以减少“请求社交对象列表”的通信开销和等待时间的浪费，进而提高共同社交对象的计算效率。

在介绍完本申请实施例的设计思想之后，下面对本申请实施例提供的技术方案适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本发明实施例而非限定。在具体实施时，可以根据实际需要灵活地应用本申请实施例提供的技术方案。

请参见图5所示，图5为本申请的技术方案适用的一种应用场景。在图5中，包括多个终端设备(即终端设备101、终端设备102和终端设备103)、社交平台服务器200、社交数据存储集群300和计算集群400。

其中，终端设备101、终端设备102和终端设备103中均可以运行同一社交应用，该同一社交应用对应同一个社交平台，例如微信平台、QQ平台、facebook或其它社交平台。任意一个终端设备例如可以是手机、平板电脑、掌上电脑(Personal Digital Assistant，PDA)，笔记本电脑、智能穿戴式设备(例如智能手表和智能手环)、个人计算机，等等，无论是哪种类型的设备，在这些终端中均可以安装有同一社交平台对应的客户端，并且通过各个终端可以登录相应的社交账户，进而成为社交平台中的一个社交用户。

各个终端设备均可以与社交平台服务器200进行通信，社交平台服务器200用于为各个终端设备提供社交应用的相关服务，社交平台服务器200与社交数据存储集群300、计算集群400均可以通信，在具体实施过程中，社交平台服务器200所生成的所有社交数据可以全部或部分存储在社交数据存储集群300中，这里所说的社交数据例如可以包括好友关联数据、社交平台的各社交用户的个人数据以及社交用户之间的交互数据，等等。

计算集群400可以从社交数据存储集群300处获得各种社交数据，即可以获得各个社交用户的社交活动关联数据，例如可以获得好友关联数据、阅读关联数据、游戏关联数据，等等，进而构建各个社交用户的好友列表、阅读列表和游戏列表。或者，也可以由社交平台服务器200构建各个社交用户的社交对象列表，并将构建好的所有社交对象列表发送给计算集群400，也就是说，计算集群400可以通过自身构建社交对象列表或者接收社交平台服务器200发送的社交对象列表的方式，获得社交平台上的所有社交用户的社交对象列表。在本申请实施例中，计算集群400是专用于计算共同社交对象的计算机集群，针对共同社交对象的计算采用了一些定向的优化配置，由于所有社交用户的社交对象列表的构建的计算量也较大，所以为了尽量不影响社交平台服务器200为各个终端设备提供及时有效的社交服务，故可采用由计算集群400自身构建各个社交用户的好友列表的方式。

图6为基于图5所示的应用场景的细化，以下结合图5和图6对该应用场景进行进一步的介绍。

社交平台服务器200可以包括社交客户端的输入/输出端口(Input/Output，I/O)接口201、处理器202、存储器203、数据库204、社交数据输出接口206和共同类计算结果输入接口205。其中，社交客户端的I/O接口201用于与各个终端设备网络连接，以通过社交客户端的I/O接口201与各个终端设备进行数据交互，存储器203和数据库204均可以用于存储数据，以及存储器203还可以用于存储一些指令，处理器202与存储器203和数据库204均连接，用于对存储器203和数据库204中存储的数据和指令进行处理。社交数据输出接口206与社交数据存储集群300中的存储节点中的社交数据接收接口302连接，用于实现社交平台服务器200与社交数据存储集群300之间的社交数据的交互。以及，可以通过共同类计算结果输入接口205接收存储节点发送的共同类计算结果，其中的“共同类”是指前述提到的例如共同好友、共同阅读、共同玩过的游戏、共同群组、共同使用过的小程序等共同社交对象。在实际中，社交平台服务器200可以是个人计算机、大中型计算机、计算机集群，等等。

社交数据存储集群300可以采用分布式存储系统(Hadoop Distributed FileSystem，HDFS)的存储架构。社交数据存储集群300中可以配置多个存储节点，图5中所示的是以社交数据存储集群300包括存储节点1、存储节点2、存储节点3、存储节点4这四个存储节点为例进行举例说明，在实际中，可以根据社交平台所包括的社交用户的数量以及活跃程度进行相应的存储节点的配置。图6中是以一个存储节点为例进行示意说明，每个存储节点可以包括处理器301、用于存储共同好友计算结果的存储器、以及用于存储社交数据(例如社交活动关联数据)的数据库、社交数据接收接口302好共同类计算结果输出接口303。其中，处理器301可以对共同类计算结果和社交活动关联数据进行处理，用于存储社交数据的数据库为计算集群400中的每个计算节点提供相应的社交数据，以及，用于存储共同类计算结果的存储器可以接收计算集群400中的各个计算节点所计算得到的共同类计算结果，然后再通过共同类计算结果输出接口303将共同类计算结果发送给社交平台服务器200，以便于社交后台服务器200可以以共同类计算结果为推荐依据，向各个终端设备根据其好友关系进行相应的例如阅读、游戏、购物等关联推荐。

计算集群400可以包括多个计算节点，例如在本申请实施例中，以社交平台的用户达到10亿级别为例，可以在计算集群400中部署30-50个计算节点，各个计算节点之间依赖MPI进行消息通信，每个计算节点可以采用NUMA架构，这样可以充分利用各个计算节点的内存、通信带宽和I/O带宽等硬件资源，各个计算节点内部分别计算一部分好友对的共同社交对象，通过各个计算节点的协同计算，可以快速、高效的完成海量用户对的共同社交对象的计算。

请参见图6，为了简化，图6中是以包括两个计算节点(即计算节点K-1和计算节点K)为例进行图示说明，其中的计算节点K-1包括存储器401、处理器402、数据交互接口403和共同类计算结果输出接口404，以及计算节点K包括存储器405、处理器406、数据交互接口407和共同类计算结果输出接口408。其中，数据交互接口403和数据交互接口407之间依赖MPI进行通信，以实现计算节点K-1与计算节点K之间的数据交互，例如计算节点K-1可以通过数据交互接口403接收计算节点K通过数据交互接口407发送的好友列表。各个计算节点中的存储器用于存储数据和指令，对应的处理器用于处理这些数据和指令以进行共同好友的计算，以及，每个计算节点在得到共同好友计算结果之后，可以通过各自的共同类计算结果输出接口将共同类计算结果发送给存储节点，以通过存储节点集中存储和管理所有的共同类计算结果，同时也便于社交平台服务器200直接从存储节点实时的获取到共同类计算结果，从而实现确保共同社交对象计算的时效。

在图6所示的应用场景中，计算节点K-1和计算节点K均可以采用后文介绍的确定共同社交对象的方法来计算各计算节点中各自存储的部分社交用户与其好友之间的共同社交对象，即，计算集群400中的每个计算节点均可以采用前述提到的委托策略进行共同社交对象的计算，以提高共同社交对象的计算效率，确保共同好社交对象更新(例如新增好友或者删除好友)的时效性。

为进一步说明本申请实施例提供的技术方案，下面结合附图以及具体实施方式对此进行详细的说明。虽然本申请实施例提供了如下述实施例或附图所示的方法操作步骤，但基于常规或者无需创造性的劳动在所述方法中可以包括更多或者更少的操作步骤。在逻辑上不存在必要因果关系的步骤中，这些步骤的执行顺序不限于本申请实施例提供的执行顺序。所述方法在实际的处理过程中或者装置执行时，可按照实施例或者附图所示的方法顺序执行或者并行执行。

以下结合图7所示的流程图对本申请实施例中的技术方案进行说明，图7中各个步骤的执行主体例如可以是图5或图6中的计算集群400中的任意一个计算节点，例如是计算节点1或者计算节点K-1或者计算节点K，等等，也就是说，图7是站在单个计算节点的角度对单个计算节点内部进行共同社交对象计算的过程进行说明。

为了便于描述和理解，以下以图7中的各步骤是由节点集群中的第一节点执行的为例对本申请实施例中的方案进行说明。

S701：获得社交平台中的M个社交用户中的每个社交用户的社交对象列表，其中，该社交平台中的所有社交用户的社交对象列表按照预设分配策略分配到节点集群中的各个节点中存储，该社交对象列表中至少包括社交用户的好友列表。

本申请实施例中的M为大于或等于1的整数，且M小于社交平台中的所有社交用户的总数，换言之，M个社交用户为社交平台中的部分社交用户，这样，可以将社交平台上的所有社交用户的社交对象列表尽量分配到所有计算节点中，以充分利用各个计算节点的资源来协同计算社交平台中的全量用户的共社交对象，提高计算效率。

如前所述的，可以由社交平台服务器根据各个社交用户的社交活动关联数据构建所有社交用户的社交对象列表之后再发送给第一节点，或者，第一节点可以先获得社交活动关联数据，进而再根据社交活动关联数据在本地构建各个社交用户的社交对象列表，对于第一节点获得M个社交用户的社交对象列表的方式本申请实施例不限制。

本申请实施例中，无论是哪种共同社交对象的共同类计算，前提都是基于好友对的，换言之，是计算互为好友的两个设计用户之间的共同社交对象的，例如计算好友对之间的共同好友、共同阅读、共同群组等等。所以，在计算共同好友对象之前，需要通过各个社交用户的好友列表来确定需要计算哪些好友对之间的共同社交对象，又由于好友列表本身就是一种具体的社交对象列表，所以本申请实施例中的各个社交用户的社交对象列表自然是至少包括好友列表的。进一步地，若是计算共同好友，则可以只使用好友列表，若是计算例如共同阅读或者共同群组等其它共同类的话，则还对应需要例如阅读列表和群组列表等社交对象列表的。

可以为节点集群中的各个计算节点编号，例如按照数字编号，假设节点集群中共包括50个计算节点，那么则可以将这50个计算节点分别以1、2、3、……、50进行编号标识，在编号之后，这50个节点例如可以直称作节点1、节点2、节点3、……、节点50。

以及，还可以根据各个社交用户的用户标识(例如用户ID)为各个社交用户编号，即将各个社交用户的用户ID作为该社交用户的编号，例如编号后的用户可以以用户1、用户2、用户3、用户4、用户5……分别表示。

在具体实施过程中，为了便于计算，可以采用预设分配策略将所有社交用户的社交对象列表尽量平均的分配到节点集群中的各个计算节点中，以通过各个计算节点尽量均衡的对所有社交用户的共同社交对象进行计算。假设社交平台中一共有10亿社交用户，以及部署有50个计算节点，那么则可以将这10亿个社交用户的社交对象列表平均分配到这50个计算节点中，则，每个计算节点则可以获得大约2千万个社交用户的社交对象列表。

同时，还可以按照一定顺序将各个社交用户的社交对象列表尽量平均的分配到各个计算节点中，例如，可以采用哈希的思想进行平均分配，举个简单的例子，可以将10亿个社交用户的用户ID以50进行取模运算，根据计算结果，则可以将用户1、用户51、用户101、用户151等用户ID每间隔50的社交用户分配到节点1上，以及可以将用户2、用户52、用户102、用户152等用户ID每间隔50的社交用户分配到节点2上，依次类推。例如参见图8所示，图8示出了各个节点上所分配的社交用户以及各社交用户的好友列表，可见，用户1、用户51、用户101、用户151等社交用户的好友列表存储在节点1中，以及用户2、用户52、用户102、用户152等社交用户的好友列表存储在节点2中，等等。

需要说明的是，对于前述的预设分配策略，节点集群中的各个计算节点都是预先知晓的，以好友列表为例，每个计算节点都预先知晓各个社交用户的好友列表是存储在哪个计算节点中的，比如对于节点1来说，其不止知晓用户1、用户51、用户101和用户151的好友列表存储在节点1的本地，还能确定用户2、用户52、用户102、用户152等用户的好友列表是存储在节点2中的，同理，对于其他社交用户的好友列表也能知晓究竟存储在哪个节点上。也就是说，预设分配策略对于各个计算节点来说相当于是透明的，每个计算节点相应的知道各个计算节点中的好友列表的存储情况。需要说明的是，图8中只是示意性的示出了其中一部分的社交用户和部分社交用户的好友列表，在具体实施过程中，当然还可以采用其它分配策略，本申请实施例不做限制。

S702：判断是否满足计算共同社交对象的触发条件。

也就是说，在进行共同社交对象计算之前，第一节点可以判断当前是否满足需要进行共同社交对象计算的触发条件。在具体实施过程中，该触发条件例如是达到预定时刻，即可以预先设置好更新周期，进而可以按照一定的周期来重新计算社交平台中的全量社交用户的共同社交对象，以该对该社交平台中的好友关系链进行更新，该更新周期例如是2天、7天或者15天，等等。另一种触发条件可以是指接收到用于指示计算共同社交对象的指令，该指令例如是社交平台服务商手动触发的，这样在有好友关系链需要更新的需求时，可以实时、灵活的进行更新，以确保好友关系链的时效性。

通过触发条件的限制，可以控制共同社交对象计算集群有规律的或者按照用户实际需求来进行更新，可以在一定程度上节约设备资源。

在确定满足前述的触发条件时，第一节点则可以启动本申请实施例中的预设委托策略来进行共同社交对象的委托计算，即执行S703；如果确定不满足前述的触发条件，第一节点则可以继续对触发条件进行检测，直至满足该触发条件后再执行S703。

S703：按照预设委托策略，针对M个社交用户中的每个社交用户，从该社交用户的好友列表中确定委托用户。

本申请实施例中，将社交用户的社交对象列表中需要委托给其它节点进行共同社交对象计算的社交好友称作“委托用户”，也就是说，某个社交用户的好友列表中的委托用户与该社交用户之间的共同社交对象的计算任务是要委托给其它节点来执行的，换言之，委托用户与其所属的社交用户之间的共同社交对象的计算任务是需要委托给其它节点执行的。其中，委托用户所属的社交用户可以按照以下理解：以图3中的用户A的好友列表为例，若用户A的好友列表中的用户C、E的好友列表存储在其它节点上，则可以将用户C、E选定为委托用户，即表明用户C、E与用户A之间的共同好友的计算任务需要委托给其它节点来执行，那么，本申请实施例中可以将委托用户所在的好友列表所属的用户称作委托用户所属的社交用户，继续前述例子，委托用户C、E所属的社交用户就是用户A，因为委托用户C、E所在的好友列表是用户A的好友列表。

按照上述理解，同一个委托用户所属的社交用户可能有一个或多个，继续以图3为例，假设用户A的委托用户为B、C，以及用户B的委托用户为C、D，可见对于同一委托用户C来说，用户A既是用户C所属的社交用户，用户B也是用户C所属的社交用户，此时委托用户C对应有两个所属的社交用户。

以共同社交对象是共同好友为例，为了解决现有在计算共同好友时需要“请求-接收”的频繁网络通信而导致计算效率低下的问题，本申请实施例利用好友的对称性，即利用“我和你的共同好友”等价于“你和我的共同好友”的好友对称特性，第一节点可以将计算共同好友的任务委托给需要计算的好友对中的对方好友所匹配的节点来执行，这样可以避免不必要的“请求好友列表”的通信开销，还可减少发送请求之后的等待时间的浪费，提升整体的计算效率。

在本申请实施例中的，针对每个好友列表中的委托好友的选择策略具有多种，例如可以将该好友列表中的所有好友均确定为委托好友，或者可以随机选择一些作为委托好友，或者可以采用对角通信策略来选择委托用户，或者可以采用半环状通信策略来选择委托用户，等等，无论采用哪种方式，均可以不同程度的减少如前述的“请求好友列表”的通信开销，进而提升计算效率。其中的对角通信策略和半环状通信策略将在后文中详述。

此外，在从各个好友列表中选择委托用户之前，可以先遍历好友列表，以从该好友列表中选出好友列表就存储在本节点(即第一节点)的用户，本申请实施例中将好友列表就存储在第一节点中的用户称作非委托用户，进而再从好友列表中除去非委托用户的剩余用户中去确定委托用户。这样，好友列表本就存储在本地的用户可以直接由本节点进行共同好友的计算，也无需将其好友列表再发送给其它节点，通过本地的数据进行公共好友计算的方式可以确保较高的计算效率，减少节点间的通信开销。

S704：从节点集群中确定用于存储每个委托用户的社交对象列表的节点。

通过S703，第一节点可以确定出本地存储的M个社交用户对应的每个好友列表中的委托用户，进而，则需要从节点集群中确定出分别用于存储每个委托用户的社交对象列表的节点，为了便于描述，本申请实施例中将用于存储委托用户的社交对象列表的节点称作与委托用户所匹配的节点。

在具体实施过程中，根据计算需求的不同，所需要的社交对象列表也可能不同，例如，若需计算好友对的共同好友，那么则需要好友对中的每个用户的好友列表，若需要计算好友对的共同阅读，则需要好友对中的每个用户的阅读列表，等等。进一步地，在确定对应匹配的节点时则可以根据实际计算需求确定出用于存储实际需要的社交对象列表的节点。

例如，用户1的所有社交对象列表存储在第一节点，用户2的所有社交对象列表存储在第二节点，且用户2是用户1的好友列表中的委托用户，若是需要计算用户1与用户2之间的共同好友或者共同阅读，则可以将第二节点确定为是与委托用户2匹配的节点。

S705：将该社交用户的社交对象列表发送给每个委托用户所匹配的节点，以请求匹配的节点根据接收到的社交对象列表确定对应委托用户与该社交用户之间的共同社交对象。

为了实现委托计算，第一节点可以将社交用户的社交对象列表对应发送给各个委托用户所匹配的节点，以请求对应匹配的节点能够进行委托计算，例如发送给第二节点。基于本申请实施例的技术方案，进一步地，第二节点可以根据接收到的社交对象列表和本地存储的委托用户的社交对象列表，来计算两者之间的共同社交对象。

以图8例，节点1(即第一节点)确定出用户1的好友列表中的委托用户为3、52，若是需要计算共同好友，由于第一节点可以知晓各个社交用户的好友列表在各个节点中的存储情况，所以第一节点可以确定出与委托用户3所匹配的节点是节点3，以及与委托用户52所匹配的节点是节点2，进一步地，可以将用户1的好友列表发送给节点2和节点3。当节点2接收到用户1的好友列表之后，则可以根据用户1的好友列表与本地存储的用户52的好友列表来计算用户1与用户52之间的共同好友，计算结果是用户3，即用户1与用户52之间的共同好友是用户。类似的，节点3也可以按照该方式计算出用户3与用户1之间的共同好友是用户51。

继续以图8为例，节点1(即第一节点)确定出用户1的好友列表中的委托用户为98，若是需要计算共同阅读，由于第一节点可以知晓各个社交用户的阅读列表在各个节点中的存储情况，例如第一节点确定出用户98的阅读列表存储在节点8(图8中未示出)，那么则可以将用户1的阅读列表发送给节点8。节点8在接收到用户1的阅读列表之后，则可以根据用户1的阅读列表和本地存储的用户98的阅读列表来计算用户1和用户98之间的共同阅读。

也就是说，本申请实施例通过预设委托策略的计算思想，设计了将自身需要执行的共同社交对象的计算任务委托给对端节点来执行的计算方式，这样可以大量减少通信开销和省去等待时间，从而可以提高共同社交对象的计算效率，确保共同社交对象计算的时效性。

图7所示的流程是站在第一节点的角度，即通过第一节点单方面去委托其它节点进行共同社交对象的计算。但是如前所述的，节点集群中的每个计算节点均可以执行和第一节点相同的操作，换言之，在第一节点向其它节点委托计算任务的同时，第一节点也可能收到其它节点委托给第一节点的计算任务，而委托第一节点进行共同社交对象计算的节点与第一节点委托出去的节点可能是同一节点，或者也可能是不同的节点。在一个节点集群中，对于10亿级别的用户量来说，这种相互委托的委托量是很大的，直观的理解，可以认为节点集群中的每个节点都在向外委托计算任务，同时也可能频繁接收到其它节点委托过来的计算任务，也就是说，节点集群中的一个节点既是委托方，同时也可能是被委托方，单个节点是同时具有委托方和被委托方的双重身份的。

在以前述的S703-S705说明了第一节点作为委托方的基础之上，第一节点还可以作为被委托方而接收其它节点的委托进行共同社交对象的计算。

在本申请实施例中，第一节点还可以接收节点集群中的其它节点按照前述的预设委托策略发送的一个或多个社交对象列表，进而再执行被委托方的操作对其它节点委托过来的计算任务进行处理。对于第一节点执行以被委托方的角色来执行的流程可以参见S706-S707对应的实施例。此外需要说明的是，第一节点委托其它节点以及接收其它节点的委托这两种流程可以是部分先后的，也就是说，S701-S705与S706-S707的执行顺序是不限制的，在图7中仅是以S706-S707在S701-S705后执行为了进行举例说明。

S706：接收节点集群中的其它节点根据预设委托策略发送的至少一个社交对象列表，其中，该至少一个社交对象列表为N个社交用户的社交对象列表，在该N个社交用户中的每个社交用户的好友列表中均包括属于前述的M个社交用户的委托用户。其中的N为大于或等于1的整数，且N小于社交平台上所有社交。

S707：根据接收的该至少一个社交对象列表，确定属于前述的M个社交用户中的委托用户与N个社交用户之间的共同社交对象。

例如，第二节点中存储了用户2的好友列表，用户2的好友列表是“2：1，4，9，10，51”，第二节点可以从该好友列表中确定1和9为委托用户，此时可以将这里的用户1和用户9理解为是上述的N个委托用户，进一步地，若是需要计算共同好友，第二节点确定用户1和用户9的好友列表是存储于第一节点中的，则可以将用户2的好友列表直接发送给第一节点，第一节点则可以根据用户2的好友列表和用户1、用户9的好友列表，分别计算用户2与用户1，以及用户2与用户9之间的共同好友。进而，第一节点完成了第二节点委托过来的计算任务。在具体实施过程中，第一节点可能同时接收到多个其它节点委托过来的计算任务，第一节点可以并行或依次执行这些计算任务。

如前所述的，本申请实施例可以采用多种不同的选择策略来确定每个好友列表中的委托用户，为了便于理解，以下结合图9介绍几种选择策略。

参见图9所示，可以采用如S901中的对角通信策略来选择委托用户，在另一种实施方式中，还可以采用S904中的半环状通信策略来选择委托用户，以下对这两种选择策略分别进行说明。

1)对角通信策略。

对于本申请实施例中的对角通信策略，以下分别通过S902和S903提供两种具体实施方式。

第一种实施方式

S902：针对每个好友列表，将用户ID值大于或小于当前用户的ID值的用户确定为委托用户。

在第一种对角通信策略的实施方式中，可以根据社交用户的用户标识的取值，从每个社交用户的好友列表中确定取值大于或小于该社交用户的用户标识的取值的社交用户，并将确定出的社交用户作为该好友列表中的委托用户。

以图8为例，对于节点1中的用户1的好友列表，节点1按照第一种对角通信策略中的“大于”的选择方式，则可以将2、3、4、51、52、98均确定为委托用户，因为这些用户的用户ID均大于用户1的用户ID；又例如对于节点2中的用户52的好友列表，节点2按照第一种对角通信策略中的“大于”的选择方式，则可以将88、163确定为委托用户，因为这些用户的用户ID均大于用户1的用户ID。

第二种实施方式

S903：针对每个好友列表，将节点编号大于或小于当前节点的编号的用户确定为委托用户。

在第二种对角通信策略中，可以根据节点的节点标识的取值，从每个社交用户的好友列表中确定好友列表存储的节点的取值小于或大于本节点的取值的社交用户，并将确定出的社交用户确定为该好友列表中的委托用户，其中的本节点即为存储M个社交用户的好友列表的节点，即为存储当前进行委托用户选择的好友列表的节点，在本申请实施例中即为第一节点。

继续以图8为例，对于节点1中的用户1的好友列表，节点1按照第二种对角通信策略中的“大于”的选择方式则可以将2、3、4、52、98均确定为委托用户，而由于存储用户51的好友列表的节点与存储用户1的好友列表的节点是同一个节点，所以就不用将用户51选择为委托用户；又例如对于节点3中的用户3的好友列表，节点2按照第二种对角通信策略中的“大于”的选择方式，则可以将9、18、66和98确定为委托用户，其中的用户1、51对应存储其好友列表的节点1的标识小于节点3的标识，所以不将其作为委托好友。

采用对角通信策略的方式来选择委托用户，可以在一定程度上减少节点之间的“请求好友列表”的通信开销。并且，利用好友的对称性，只从单向上选择委托用户，例如只选择比自身的用户ID大的或者节点标识小的，全部从一个方向上选择，达到消息对折的目的，通过消息对折的方式，大约可以减少一半的通信量和计算量，从而提高计算效率。

对角通信策略，采用的是一种直接而朴素的思想，即按照用户ID值的大小或者节点编号的大小，按照一个方向(由大到小的方向或者由小到大的方向)，以当前用户或者当前节点作为参照基准来进行委托用户的筛选，请参见图10中的(a)图所示，图10中的(a)图和(b)图横向上标识颜色的方块可以理解为对应节点委托出去的计算任务，而纵向上标识有颜色的方块表示对应节点自身计算的任务。在图10中的(a)图中，颜色最深的方块表示节点0自身需要执行的计算任务，而其它不同程度的灰色方块表示节点0委托给其它节点的计算任务，可见节点0自身的计算任务较少，而例如节点5或节点6等编号较大的节点的计算任务就比较多，这样很容易导致负载不均衡，即，有的节点计算任务很重，而有的节点计算任务很轻，这样则难以充分利用各个节点的资源，出现负载不均衡的问题。

2)半环状通信策略。

基于前述提到的负载不均衡的问题，本申请实施例可以采用半环状通信策略来有效解决该问题。在半环状通信策略下，每个节点可以将计算任务委托给其余一半计算节点，同时也接收并计算来自其余一半节点的委托任务，如图10中的(b)图所示，当采用半环状通信策略之后，节点0的发送量和计算量几乎是相等的，以及其它节点的计算量和委托量也差不多是均分的，并且，节点0与其它节点的计算量和委托量都是差不多的，这样的话，可以使得节点集群中的每个节点均能大致保持一半的计算量和一半的委托量，从而实现负载均衡的目的。

对于本申请实施例中的半环状通信策略，以下以第一节点为例通过S905-S910来进行说明，对于节点集群中的其它节点可以按照类似的方式实施。

S905：第一节点从节点集群中选择可委托节点。

其中，可委托节点是指第一节点可以委托其进行共同好友计算的节点，第一节点选择的可委托节点的数量是节点集群的节点总数的一半。

例如，节点集群包括的总节点数量为K，K为大于或等于2的整数，例如为38或者49，等等。节点集群中的每个节点具有唯一的节点标识，即可以为每个节点编号，并且，节点集群中的所有节点按照节点标识具有预定排列顺序，其中的预定排列顺序例如是按照节点编号由大到小排列或者由小到大排列的顺序，为了便于理解，后文将以预定排列顺序是按照节点编号由小到大的进行排列的顺序进行举例。

以下结合S906-S908说明第一节点从节点集群中选择可委托节点的过程。

S906：第一节点判断节点集群包括的节点总数K是否为奇数，换言之，第一节点可以先确定节点总数是奇数还是偶数。

S907：若K为奇数，则根据前述的预定排列顺序，可以将与本节点(即第一节点)依次相邻的(K-1)/2个节点确定为可委托节点。

例如K为11，除去第一节点自身还剩余10个节点，所以按照此方式，可以先确定可委托节点的数量是10的一半，即5个，进一步地，可以将与第一节点依次相邻的5个节点确定为是最终的可委托节点。假设第一节点的编号是6，则可以将与6依次相邻，例如编号依次增大的编号为7、8、9、10、11的节点确定为是可委托节点，当然也可以将编号依次减少的编号为5、4、3、2、1的节点确定为是可委托节点，等等。

S908：若K不为偶数，即K为偶数，则根据前述的预定排列顺序，可以将与本节点(即第一节点)依次相邻的K/2个节点或(K-2)/2个节点确定为可委托节点。

例如K为8，除去第一节点自身还剩余7个节点，所以按照此方式，可以将与第一节点依次相邻的3个节点或4个节点确定为是最终的可委托节点。假设第一节点的编号是4，则可以将与4依次相邻，例如编号依次增大的编号为5、6、7或者5、6、7、8的节点确定为是可委托节点。

在该种情况中，对于某个节点来说，到底是选择依次相邻的K/2个节点作为可委托节点，还是选择依次相邻的(K-2)/2个节点作为可委托节点，具体可以按照以下方式来确定。

首先，若整个节点集群的节点总数K为偶数，那么则可以配置其中一半节点，即配置其中的K/2个节点选择依次相邻的K/2个节点作为可委托节点，以及配置剩余的K/2个节点选择依次相邻的(K-2)/2个节点作为可委托节点。例如可以配置编号较小的一半节点选择依次相邻的K/2个节点作为可委托节点，而配置编号较大的另一半节点选择依次相邻的(K-2)/2个节点作为可委托节点，或者还可以随机将所有节点均分为两部分，或者还可以采用其他方式将所有节点均分为两部分。

在通过S906-S908选择出可委托节点之后，可以执行S909。

S909：将好友列表中的社交对象列表存储在确定出的可委托节点中的用户确定为委托用户。

即，在确定出了可委托节点之后，针对一个好友列表来说，可以确定该社交列表中的哪些社交用户的社交对象列表是存储在这些可委托节点中的，进而，可以将社交对象列表存储在这些可委托节点中的社交用户确定为是该好友列表中的委托用户，可以通过可委托节点来反向确定一个好友列表中的委托用户。

在此过程中，好友列表中的社交用户的社交对象列表可能不一定存储在这些确定出的可委托节点中，换言之，通过前面S906-S908的步骤确定出的可委托节点是备选的可委托节点，而第一节点最终选择的可委托节点一定包括在前述的备选的可委托节点中，但是，并不一定所有的备选的可委托节点都会进行委托计算，而是只将存储有委托用户的好友列表的可委托节点作为最终会委托计算任务的节点。

根据节点总数K的奇偶数的不同，分别提供了对应的确定可委托节点的方案，这样可以尽量使得各个节点最终选择委托的节点是按照节点一半的划分方式来选择的，从而能够尽量确保各个节点自身的计算任务和委托任务是相等的，进而提高整体的负载均衡性。

S910：采用上述的对角通信策略或半环状通信策略，最终可以选择出每个好友列表中的委托用户，从而完成各个好友列表中的委托用户的选择。

在具体实施过程中，节点集群中各个节点的设备资源一般是大致相同的，也就是说，可以采用软硬件资源大致相同的多个节点设备来部署本申请实施例中的共同好友计算集群。本申请实施例中的技术方案不仅要求算法本身高效，还要求软硬件整体考虑，最大化地同时榨取各个极端节点的CPU占用率、访存带宽、通信带宽、I/O带宽等各方面性能。基于此考虑，本申请实施例设计了流水并行的任务执行机制，具体来说，将M个社交用户中的每个社交用户与该社交用户的好友之间的共同社交对象的确定过程作为一个计算任务，进而可以将与M个社交用户对应的M个计算任务中的至少两个计算任务并行执行，换言之，即可以让多个计算任务并行处理，这样可以在一定程度上提高计算效率，并且可以充分利用设备资源。

进一步地，还可以将每个计算任务划分为至少两个子任务，每个子任务通过调用不同的线程执行，其中，根据每个子任务的执行时长分配对应的线程数量，子任务的执行时长和线程数量呈正相关关系，正相关关系例如可以是正比例关系。例如，可以将执行时长较短的子任务的线程数配置为多于执行时长较长的子任务的线程数，例如子任务1的执行时长是t，而子任务2的执行时长是2t，那么则可以将执行子任务1的线程数配置为用于执行子任务2的线程数，这样可以避免子任务1执行完毕后的处于等待状态，通过细粒度的线程数调优，可以确保每个阶段的执行时间均衡，避免任一阶段成为整体瓶颈。

此外，在消息接收端，即，作为被委托方的节点，可以依照“用完即走”的理念处理每一条消息，每条消息到达后即以流水的形式完成所有计算，然后顺序处理下一条消息。因此接收端可以无需缓存大量的数据，降低内存开销。

以计算共同好友为例，例如图11所示，图11所示的是任务1-任务5这五个任务，这五个任务并行处理的，即各个任务之间都有一些任务阶段在时间上是相互重叠的，即并行执行。例如，可以将一个完整的计算任务拆解为检索二度好友、跨节点发送好友列表、跨节点接收好友列表、计算共同好友、输出共同好友这五个阶段。每个阶段都可以多线程方式并行执行，并且通过细粒度线程数调优可以确保每个阶段的执行时间均衡，避免任一阶段成为整体瓶颈，进而提高节点的计算效率。

以上从单个节点的角度介绍了本申请实施例中的确定共同好友的方案，以下再结合图12从多节点的角度来对本申请实施例中的技术方案进行说明，并且是以计算互为好友的好友对之间的共同好友为例进行举例说明，对于例如共同阅读、共同群组、共同游戏等其它共同类的计算可以参照图12类似理解。

请参见图12所示，图12中包括存储节点、第一节点、第二节点和第三节点这4个设备，其中的第一节点、第二节点和第三节点属于同一节点集群，例如属于前述提到的共同好友计算集群，那么第一节点、第二节点和第三节点即口可以理解为是该集群中的任意三个计算节点。其中的存储节点用于存储各个计算节点确定出的共同好友计算结果，并且可以对存储的共同好友计算结果进行管理和维护，例如还可以发送给社交平台服务器。

S1201：第一节点确定本地存储的用户A的好友列表中的委托用户是用户B、C、E，以及本地存储的用户D的好友列表中的委托用户是用户E。其中，用于存储用户B、C的计算节点是第二节点，用于存储用户E的好友列表的计算节点是第三节点。

S1202：第一节点判断第二节点和第三节点是否都属于可委托节点。

在具体实施过程中，可以按照前述介绍的方式先确定出可委托节点，然后再将第二节点和第三节点与确定出的可委托节点进行匹配比较，进而得到判断结果。

若确定第二节点和第三节点均属于可委托节点，那么则可以执行后续S1003-S1009的操作。

S1203：第一节点将用户A的好友列表发送给第二节点，并且在整个计算共同好友的过程中，只向第二节点发送一次用户A的好友列表。

这是因为，委托用户B和C所匹配的节点均是第二节点，当第一节点向第二节点委托B时，则会向第二节点发送一次用户A的好友列表，当再次向第二节点委托C时，由于之前已经发送过用户A的好友列表，即表明第二节点处已经存储有用户A的好友列表，所以在委托C时就可以无需再次发送用户A的好友列表了，也就是说，若一个社交用户的好友列表中包括的至少两个委托用户所匹配的节点为同一个节点，则针对该至少两个委托用户只向该同一个节点发送一次该好友列表，尽量减少节点间的通信开销。这可以理解为是一种消息合并的方式，可以减少向同一节点的重复发送的次数，甚至可以完全不重复发送，这样可以减少集群中的消息传输数量，节约通信资源。

S1204：在接收到第一节点发送的用户A的好友列表之后，第二节点可以根据用户A的好友列表，分别计算用户B、C与用户A之间的共同好友，进而得到第一计算结果，第一计算结果即为用户B与用户A之间的共同好友，以及用户C与用户A之间的共同好友。

S1205：第二节点在得到第一计算结果之后，可以将第一计算结果发送给存储节点，以通过存储节点保存第一计算结果。

S1206：第一节点将用户A的好友列表和用户D的好友列表合并处理为一条合并信息。

S1207：第一节点将得到的上述合并信息发送给匹配的第三节点。

由于第一节点需要将用户A的好友列表中的E以及用户D中的好友列表中的E均委托给第三节点处理，为了避免引发消息洪水，即避免在同一时刻大量信息发送给同一节点，在本申请实施例中采用了合并消息的方式来减少消息传输的数量，同时也可以在一定程度上减少对端节点的缓存占用，也就是说，若至少两个社交用户的好友列表所匹配的节点为同一个节点，则将该至少两个社交用户对应的至少两个好友列表合并处理为一条信息，并将得到的该一条信息发送给上述的同一个节点。

在具体实施过程中，可能将两个好友列表或者更多个好友列表一起进行合并处理，为了使得各个节点均能有效识别合并处理后得到的合并信息，在节点集群中可以自定义消息序列化，即可以自定义或者采用现有的数据格式来合并处理多个好友列表，这样各个计算节点都能对合并信息进行有效识别，以确保共同好友计算的准确性。

S1208：第三节点在接收到合并信息之后，可以根据合并信息和用户E的好友列表，分别计算用户E与用户A、D之间的共同好友，得到第二计算结果。第二计算结果即为用户E与用户A之间的共同好友，以及用户E与用户D之间的共同好友。

S1209：第三节点在得到第二计算结果之后，即可以将第二计算结果发送给存储节点，以通过存储节点保存第二计算结果。

也就是说，各个节点得到的共同好友计算结果均可以发送给存储节点，通过存储节点可以对所有的共同好友计算结果进行管理和维护，进一步地，各社交平台服务器可以从该存储节点处获得共同好友计算结果，进而依据好友关系链对各客户端用户进行关联推荐，例如推荐资讯阅读、推荐商品、推荐游戏等，实现更为精准的智能营销。

在具体实施过程中，以计算共同好友为例，无论是节点集群中的哪个节点，在获得了两个好友列表之后，则可以基于该两个好友列表计算出共同好友。还是以图3为例，在获得了用户A和用户B的好友列表之后，可以计算两个好友列表之间的交集元素，进而再得到的交集元素确定为是用户A与用户B之间的共同好友，也就是说，共同好友的计算，最后演化成计算两个集合的交集，目前来说，一般是采用依次将一个集合中的每个元素与另一个集合中的所有集合进行一一对比，通过多轮比较进而得到两个集合的交集，也就是说，目前在计算两个好友列表(即两个集合)之间的交集用户时，是以单个元素为比较基准，一个一个的逐次进行比较，效率较低。

基于以上所述，本申请实施例提供一种基于SIMD向量化技术来计算两个好友列表之间的交集好友的方式，具体来说，就是将计算粒度从现有的单个元素转换成向量，而一个向量至少包括2个元素。以一个向量包括4个元素为例，那么在进行匹配比较的时候就可以向量为粒度批量的进行匹配比较，请参见图13所示，例如有集合1和集合2这两个集合，通过SIMD向量化的方式，保持集合1(即2，4，6，8)不变，将集合2(即1，2，3，4)看作包括4个元素的向量，然后将集合2对应的向量与集合1进行比较，在比较的时候，即比较对应的位上的数字是否相同，若相同，则可以将原本全为0的集合(例如称作参考集合)的对应位置成1，如图13中的右图所示，当集合2移位变成(2，3，4，1)时，确定在左起的第一位上集合1和集合2的数值相同，则可以将参考集合中的对应位置成1，重复前面的操作，则可以将向量中的所有位比较完成，最后可见集合1从左起的第1位和第2位的元素是集合2中也存在的元素，换言之，集合1和集合2之间的交集是(2，4)。通过更大粒度的SIMD向量化方式，可以提高匹配的效率，进而提升整体计算性能。

在本申请实施例中，计算节点可以采用委托策略进行来委托对端设备进行共同好友的计算，从而可以减少节点之间的“请求好友列表”的通信开销，提高共同好友的计算效率。进一步地，采用了消息对折、对角通信策略和半环状通信策略来减少节点之间的消息传输数量，提升计算效率，尤其是半环状通信策略还可以尽量确保集群中的负载均衡，充分利用各个计算节点的设备资源。本申请实施例还提出了流水并行机制、消息合并和SIMD向量化求交集的方式来优化本申请实施例中的确定共同好友的技术方案。

通过一系列的优化方案，本申请中的用于计算共同好友的节点集群中，只部署30-50台设备仅用10分多钟就完成10亿级的全量好友的共同好友或共同群组等共同类的计算，以实现快速、高效的共同类计算方式。

基于同一发明构思，请参见图14所示，本申请实施例提供一种确定共同社交对象的系统，该系统包括至少两个计算节点，例如图14中是以包括第一计算节点、第二计算节点、第三计算节点和第四计算节点为例进行图示说明，各个计算节点之间可以基于MPI方式进行数据交互和通信，本申请实施例中的任意一个计算节点均可通过前述介绍的确定共同社交对象的方法计算好友对之间的共同社交对象，以分别获得共同社交对象的计算结果(还可以称作共同类计算结果)，以及，每个计算节点可以将获得的共同类计算结果发送给存储节点，以通过存储节点来存储所有的共同类计算结果。

本申请实施例中的确定共同社交对象的系统，各个计算节点可以采用委托策略来委托其他计算节点来执行共同社交对象的计算任务，这样可以减少节点间的通信开销，同时通过各个计算节点之间的协同作用，也可以提高计算效率。

基于同一发明构思，请参见图15所示，本申请实施例提供一种即时通信系统，该系统包括即时通信服务器1501、分布式存储集群1502和共同类计算集群1503。即时通信服务器1501和共同类计算集群1503均与分布式存储集群1502连接。其中的即时通信服务器1501可以理解为是图5或图6中的社交平台服务器200，分布式存储集群1502可以理解为是图5或图6中的社交数据存储集群300，以及共同类计算集群1503可以理解为是图5或图6中的计算集群400。其中：

共同类计算集群1503包括至少两个计算节点，每个计算节点均可以采用上述任一种确定共同社交对象的方法确定共同类，以分别获得共同类计算结果，并将获得的共同类结果发送给分布式存储集群1502；

分布式存储集群1502用于存储共同类计算结果；

即时通信服务器1501从分布式存储集群获1502得共同类计算结果，并基于共同类计算结果向即时通信客户端进行关联推荐。

基于本申请实施例中的确定共同社交对象的系统不仅可以获得较高的计算效率，还可以确保好友关系链的时效性、进而可以为用户进行准确的关联推荐。

基于同一发明构思，本申请实施例提供一种确定共同社交对象的装置，该确定共同社交对象的装置可以是计算节点，例如图5或6中的任一计算节点。该确定共同社交对象的装置可以是硬件结构、软件模块、或硬件结构加软件模块。该确定共同社交对象的装置可以由芯片系统实现，芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。请参见图16所示，本申请实施例中的确定共同好友的装置包括获得模块1601、第一确定模块1602、第二确定模块1603和委托模块1604。其中：

获得模块1601，用于获得社交平台中的M个社交用户中的每个社交用户的社交对象列表，其中，社交平台中的所有社交用户的社交对象列表按照预设分配策略分配到节点集群中，社交对象列表为与社交用户关联的社交对象的集合，社交对象列表包括好友列表，M为大于或等于1的整数，且M小于所有社交用户的总数；

第一确定模块1602，用于按照预设委托策略，针对M个社交用户中的每个社交用户，从该社交用户的好友列表中确定委托用户；

第二确定模块1603，用于从节点集群中确定用于存储每个委托用户的社交对象列表的节点；

委托模块1604，用于将该社交用户的社交对象列表发送给每个委托用户所匹配的节点，以请求匹配的节点根据接收到的社交对象列表确定对应委托用户与该社交用户之间的共同社交对象。

在一种可能的实施方式中，继续参见图16所示，本申请实施例中的确定共同社交对象的装置还包括：

接收模块1605，用于接收节点集群中的其它节点根据预设委托策略发送的至少一个社交对象列表，其中，至少一个社交对象列表为N个社交用户的社交对象列表，在N个社交用户中的每个社交用户的好友列表中均包括属于M个社交用户的委托用户，N为大于或等于1的整数，且N小于所有社交用户的总数；

第三确定模块1606，用于根据所述至少一个社交对象列表，确定属于M个社交用户的委托用户与N个社交用户之间的共同社交对象。

在一种可能的实施方式中，第一确定模块1602用于：

根据社交用户的用户标识的取值，从每个社交用户的好友列表中确定取值大于或小于该社交用户的用户标识的取值的社交用户，并将确定出的社交用户确定为该好友列表中的委托用户；或者，

根据节点的节点标识的取值，从每个社交用户的好友列表中确定好友列表存储的节点的取值大于或小于本节点的取值的社交用户，并将确定出的社交用户确定为该好友列表中的委托用户，其中，本节点为存储M个社交用户的社交对象列表的节点。

在一种可能的实施方式中，请参见图16所示，本申请实施例中的确定共同社交对象的装置还包括第四确定模块1607，用于从节点集群中确定可委托节点，其中，可委托节点的数量为节点集群的节点总数的一半；

则，第二确定模块1603，用于从可委托节点中确定用于存储每个委托用户的社交对象列表的节点。

在一种可能的实施方式中，节点集群中的每个节点具有唯一的节点标识，所述节点集群中的所有节点按照节点标识具有预定排列顺序，节点集群的节点总数为K，K为大于或等于2的整数；则，第四确定模块1607，用于：

若K为奇数，则根据预定排列顺序，将与本节点依次相邻的(K-1)/2个节点确定为可委托节点；

若K为偶数，则根据预定排列顺序，将与本节点依次相邻的K/2个节点或(K-2)/2个节点确定为可委托节点；

其中，本节点为存储M个社交用户的好友列表的节点。

在一种可能的实施方式中，若K为偶数，节点集群中的K/2个节点中的每个节点按照预定排列顺序，将与该节点依次相邻的(K-2)/2个节点确定为可委托节点，以及节点集群中剩余的K/2个节点中的每个节点按照预定排列顺序，将与该节点依次相邻的K/2个节点确定为可委托节点。

在一种可能的实施方式中，委托模块1604，用于若M个社交用户中的至少两个社交用户对应的至少两个社交对象列表存储在同一个节点，且该至少两个社交用户的好友列表中均包括委托用户，则将至少两个社交对象列表合并处理为一条信息，并将得到的一条信息发送给前述的同一个节点。

在一种可能的实施方式中，委托模块1604，用于若一个社交用户的好友列表中包括的至少两个委托用户所匹配的节点为同一个节点，则针对至少两个委托用户只向前述的同一个节点发送一次该社交对象列表。

在一种可能的实施方式中，M个社交用户中的每个社交用户与该社交用户的好友之间的共同社交对象的确定过程对应一个计算任务，与M个社交用户对应的M个计算任务中的至少两个计算任务并行执行。

在一种可能的实施方式中，每个计算任务划分为至少两个子任务，每个子任务通过调用不同的线程执行，其中，根据每个子任务的执行时长分配对应的线程数量，子任务的执行时长和线程数量呈正相关关系。

在一种可能的实施方式中，采用SIMD向量化方式确定两个社交用户对应的两个社交对象列表中的交集元素，并将确定出的交集元素确定为所述两个社交用户之间的共同社交对象。

前述的确定共同社交对象的方法的实施例涉及的计算节点执行的各步骤的所有相关内容均可以援引到本申请施例中的确定共同社交对象的装置所对应的功能模块的功能描述，在此不再赘述。

本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，另外，在本申请各个实施例中的各功能模块可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

基于同一发明构思，基于同一发明构思，本申请实施例还提供一种计算设备，该计算设备例如是前述的计算节点，该计算设备例如是图5或图6中的任意一个计算节点。如图17所示，本申请实施例中的计算设备包括至少一个处理器1701，以及与至少一个处理器1701连接的存储器1702和通信接口1703，本申请实施例中不限定处理器1701与存储器1702之间的具体连接介质，图17中是以处理器1701和存储器1702之间通过总线1700连接为例，总线1700在图17中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线1700可以分为地址总线、数据总线、控制总线等，为便于表示，图17中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

在本申请实施例中，存储器1702存储有可被至少一个处理器1701执行的指令，至少一个处理器1701通过执行存储器1702存储的指令，可以执行前述的推荐多媒体内容的方法中所包括的步骤。

其中，处理器1701是计算设备的控制中心，可以利用各种接口和线路连接整个计算设备的各个部分，通过运行或执行存储在存储器1702内的指令以及调用存储在存储器1702内的数据，计算设备的各种功能和处理数据，从而对计算设备进行整体监控。可选的，处理器1701可包括一个或多个处理单元，处理器1701可集成应用处理器和调制解调处理器，其中，处理器1701主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1701中。在一些实施例中，处理器1701和存储器1702可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。

处理器1701可以是通用处理器，例如中央处理器(CPU)、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器1702作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器1702可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random AccessMemory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(Read Only Memory，ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性存储器、磁盘、光盘等等。存储器1702是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器1702还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

通信接口1703是能够用于进行通信的传输接口，例如可以通过通信接口1703接收数据或者发送数据。

参见图18所示的计算设备的进一步地的结构示意图，该计算设备还包括帮助计算设备内的各个器件之间传输信息的基本输入/输出系统(I/O系统)1801、用于存储操作系统1802、应用程序1803和其他程序模块1804的大容量存储设备1805。

基本输入/输出系统1801包括有用于显示信息的显示器1806和用于用户输入信息的诸如鼠标、键盘之类的输入设备1807。其中显示器1806和输入设备1807都通过连接到系统总线1700的基本输入/输出系统1801连接到处理器601。所述基本输入/输出系统1801还可以包括输入输出控制器以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地，输入输出控制器还提供输出到显示屏、打印机或其他类型的输出设备。

所述大容量存储设备1805通过连接到系统总线1700的大容量存储控制器(未示出)连接到处理器1701。所述大容量存储设备1805及其相关联的计算机可读介质为该服务器包提供非易失性存储。也就是说，大容量存储设备1805可以包括诸如硬盘或者CD-ROM驱动器之类的计算机可读介质(未示出)。

根据本发明的各种实施例，该计算设备包还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即该计算设备可以通过连接在所述系统总线1700上的通信接口1703连接到网络1808，或者说，也可以使用通信接口1703来连接到其他类型的网络或远程计算机系统(未示出)。

基于同一发明构思，本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机指令，当该计算机指令在计算机上运行时，使得计算机执行如前述的确定共同社交对象的方法的步骤。

基于同一发明构思，本申请实施例还提供一种确定共同社交对象的装置，该确定共同好友的装置包括至少一个处理器及存储介质，当该存储介质中包括的指令被该至少一个处理器执行时，可以执行如前述的确定共同社交对象的方法的步骤。

基于同一发明构思，本申请实施例还提供一种芯片系统，该芯片系统包括处理器，还可以包括存储器，用于实现如前述的确定共同社交对象的方法的步骤。该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。

在一些可能的实施方式中，本申请实施例提供的确定共同社交对象的方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在计算机上运行时，所述程序代码用于使所述计算机执行前文述描述的根据本发明各种示例性实施方式的确定共同社交对象的方法中的步骤。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程计算设备的处理器以产生一个机器，使得通过计算机或其他可编程计算设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程计算设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程计算设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (14)

1.一种确定共同社交对象的方法，其特征在于，所述方法包括：

获得社交平台中的M个社交用户中的每个社交用户的社交对象列表，其中，所述社交平台中的所有社交用户的社交对象列表按照预设分配策略分配到节点集群中的各个节点上存储，社交对象列表为与社交用户之间有社交关系的社交对象的集合，社交对象列表包括社交用户的好友列表，M为大于或等于1的整数，且M小于所述所有社交用户的总数；

按照预设委托策略，针对所述M个社交用户中的每个社交用户，从该社交用户的好友列表中确定委托用户；所述按照预设委托策略，针对所述M个社交用户中的每个社交用户，从该社交用户的好友列表中确定委托用户，包括：根据社交用户的用户标识的取值，从该社交用户的好友列表中确定取值大于或小于该社交用户的用户标识的取值的社交用户，并将确定出的社交用户确定为该好友列表中的委托用户；或者，根据节点的节点标识的取值，从该社交用户的好友列表中确定好友列表存储的节点的取值大于或小于本节点的取值的社交用户，并将确定出的社交用户确定为该好友列表中的委托用户，其中，所述本节点为存储所述M个社交用户的社交对象列表的节点；

从所述节点集群中确定用于存储每个委托用户的社交对象列表所匹配的节点；并

将该社交用户的社交对象列表发送给每个委托用户所匹配的节点，以请求匹配的节点根据接收到的社交对象列表确定对应委托用户与该社交用户之间的共同社交对象。

2.如权利要求1所述的方法，其特征在于，所述方法还包括：

接收所述节点集群中的其它节点根据所述预设委托策略发送的至少一个社交对象列表，其中，所述至少一个社交对象列表为N个社交用户的社交对象列表，在所述N个社交用户中的每个社交用户的好友列表中均包括属于所述M个社交用户的委托用户，N为大于或等于1的整数，且N小于所述所有社交用户的总数；

根据所述至少一个社交对象列表，确定属于所述M个社交用户的委托用户与所述N个社交用户之间的共同社交对象。

3.如权利要求1所述的方法，其特征在于，所述方法还包括：

从所述节点集群中确定可委托节点，其中，所述可委托节点的数量为所述节点集群的节点总数的一半；

则，从所述节点集群中确定用于存储每个委托用户的社交对象列表的节点，包括：

从所述可委托节点中确定用于存储每个委托用户的社交对象列表的节点。

4.如权利要求3所述的方法，其特征在于，所述节点集群中的每个节点具有唯一的节点标识，所述节点集群中的所有节点按照节点标识具有预定排列顺序，所述节点集群的节点总数为K，K为大于或等于2的整数；

则，从所述节点集群中确定可委托节点，包括：

若K为奇数，则根据所述预定排列顺序，将与本节点依次相邻的(K-1)/2个节点确定为所述可委托节点；

若K为偶数，则根据所述预定排列顺序，将与本节点依次相邻的K/2个节点或(K-2)/2个节点确定为所述可委托节点；

其中，所述本节点为存储所述M个社交用户的好友列表的节点。

5.如权利要求4所述的方法，其特征在于，若K为偶数，所述节点集群中的K/2个节点中的每个节点按照所述预定排列顺序，将与该节点依次相邻的(K-2)/2个节点确定为所述可委托节点，以及所述节点集群中剩余的K/2个节点中的每个节点按照所述预定排列顺序，将与该节点依次相邻的K/2个节点确定为所述可委托节点。

6.如权利要求1所述的方法，其特征在于，若所述M个社交用户中的至少两个社交用户对应的至少两个社交对象列表存储在同一个节点，且所述至少两个社交用户的好友列表中均包括委托用户，则将所述至少两个社交对象列表合并处理为一条信息后发送。

7.如权利要求1所述的方法，其特征在于，将该社交用户的社交对象列表发送给该好友列表中的每个委托用户所匹配的节点，包括：

若该社交用户的好友列表中的至少两个委托用户所匹配的节点为同一个节点，则针对所述至少两个委托用户，只向匹配的节点发送一次该社交用户的社交对象列表。

8.如权利要求1-7任一所述的方法，其特征在于，所述M个社交用户中的每个社交用户与该社交用户的好友之间的共同社交对象的确定过程对应一个计算任务，与所述M个社交用户对应的M个计算任务中的至少两个计算任务并行执行。

9.如权利要求8所述的方法，其特征在于，每个计算任务划分为至少两个子任务，每个子任务通过调用不同的线程执行，其中，根据每个子任务的执行时长分配对应的线程数量，子任务的执行时长和线程数量呈正相关关系。

10.如权利要求1-7任一所述的方法，其特征在于，采用单指令多数据流SIMD向量化方式确定两个社交用户对应的两个社交对象列表中的交集元素，并将确定出的交集元素确定为所述两个社交用户之间的共同社交对象。

11.一种确定共同社交对象的系统，其特征在于，所述系统包括至少两个计算节点，所述至少两个计算节点中的每个计算节点均采用权利要求1-10任一所述的方法确定共同社交对象，以分别获得共同社交对象计算结果，以及，每个计算节点将获得的共同社交对象计算结果发送给存储节点。

12.一种确定共同社交对象的装置，其特征在于，所述装置包括：

获得模块，用于获得社交平台中的M个社交用户中的每个社交用户的社交对象列表，其中，所述社交平台中的所有社交用户的社交对象列表按照预设分配策略分配到节点集群中的各个节点上存储，社交对象列表为与社交用户之阿金有社交关系的社交对象的集合，社交对象列表包括社交用户的好友列表，M为大于或等于1的整数，且M小于所述所有社交用户的总数；

第一确定模块，用于按照预设委托策略，针对所述M个社交用户中的每个社交用户，从该社交用户的好友列表中确定委托用户；所述第一确定模块，具体用于：根据社交用户的用户标识的取值，从该社交用户的好友列表中确定取值大于或小于该社交用户的用户标识的取值的社交用户，并将确定出的社交用户确定为该好友列表中的委托用户；或者，根据节点的节点标识的取值，从该社交用户的好友列表中确定好友列表存储的节点的取值大于或小于本节点的取值的社交用户，并将确定出的社交用户确定为该好友列表中的委托用户，其中，所述本节点为存储所述M个社交用户的社交对象列表的节点；

第二确定模块，用于从所述节点集群中确定用于存储每个委托用户的社交对象列表的节点；

委托模块，用于将该社交用户的社交对象列表发送给每个委托用户所匹配的节点，以请求匹配的节点根据接收到的社交对象列表确定对应委托用户与该社交用户之间的共同社交对象。

13.一种计算设备，其特征在于，所述计算设备包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如权利要求1-10任一所述的方法包括的步骤。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行如权利要求1-10任一所述的方法包括的步骤。

Images