CN112861016A - 一种健康社交平台Feed流***的数据高并发处理方法 - Google Patents

Abstract

本发明属于数据高并发处理方法技术领域，尤其为tweet存储到数据库中，tweetmeta存储到timeline内，S1，用户发布tweet时，根据social graph将tweetmeta通过fanout写入到timeline list中；只保存元数据，借助Redis能够很好的支持大量元数据推送；S2，用户查看自己的timeline时，直接从自己的timeline取tweetmeta，然后再从DB中获取对应的tweet数据；通过对SNS社交***进行升级，可以实现千万级数据Feed流服务***设计开发，进而提供更好的***性能；且该处理方法优化增强社交推荐算法、优化数据精准匹配，以及社交关系中数据重复问题；有效的推动用户增加交流频率、活跃度，提升用户体验。

Description

一种健康社交平台Feed流***的数据高并发处理方法

技术领域

本发明属于数据高并发处理方法技术领域，具体涉及一种健康社交平台Feed流***的数据高并发处理方法。

背景技术

大数据的数据采集是在确定用户目标的基础上，针对该范围内所有的结构化、半结构化和非结构化的数据的采集，采集后对这些数据进行处理，从中分析和挖掘出有价值的信息。在大数据的采集过程中，其面临的挑战主要有两点，其一是异构物联网设备的通信协议以及数据协议呈现多样性；Feed流***，最关键的两个核心，一个是存储，一个是推送。Feed流***中需要存储的内容分为两部分，一个是社交关系（比如好友、社群成员、关注列表），一种是Feed消息内容。Feed推送***需要的功能有两个，一个是发布Feed，一个是读取Feed流；随着海量设备接入，数据采集的高并发数会产生性能瓶颈，导致数据积压、连接超时等问题；导致***不能够将数据动态实时的传播给订阅者，不易实现基于SNS的社交网络的内容推；针对目前的数据高并发处理方法使用过程中所暴露的问题，有必要对数据高并发处理方法进行结构上的改进与优化。

发明内容

为解决现有技术中存在的上述问题，本发明提供了一种健康社交平台Feed流***的数据高并发处理方法，具有便于通过Feed流把动态实时的传播给订阅者，实现基于SNS的社交网络的内容推送的特点。

为实现上述目的，本发明提供如下技术方案：tweet存储到数据库中，tweetmeta存储到timeline内，包括以下步骤：

S1，用户发布tweet时，根据social graph将tweetmeta通过fanout写入到timelinelist 中；只保存元数据，借助Redis能够很好的支持大量元数据推送；

S2，用户查看自己的timeline时，直接从自己的timeline取tweetmeta，然后再从DB中获取对应的tweet数据。

作为本发明的一种健康社交平台Feed流***的数据高并发处理方法优选技术方案，发布Feed消息时；

1）.Feed消息先进入一个队列服务。从Feed消息中抽取出元数据(TweetMeta) 如发布人，发布域，发布时间，内容类型，内容id；

2）.将Feed消息存储到Mysql数据库内，存储成功后异步调用元数据发布服务进行发布；

3）.元数据发布服务从元数据内提取出发布人和发布域以及Feed消息的ID，调用社交关系服务来确定需要推送Feed的队列列表；

4）.使用元数据发布服务的批量写入接口一次性将多行数据写入到多个Feed流内。

作为本发明的一种健康社交平台Feed流***的数据高并发处理方法优选技术方案，读取Feed流的时；

1）.从Feed流中读取出最新的N条Feed消息的Feed ID；

2）.获取到Feed ID列表后，异步调用Feed内容存储接口（具备缓存功能），直接通过Id来读取相应的Feed内容；

3）.将2）中的结果进行合并，返回给用户。读取Feed流的流程就结束了。当用户获取更多数据时，以当前最后一条Feed的Score作为最大范围重复1）的过程即可。

作为本发明的一种健康社交平台Feed流***的数据高并发处理方法优选技术方案，采用三元闭包理论及共同好友与时序推荐算法；在共同好友的基础上，加入了时间维度；基于用户对新添加的好友更感兴趣的假设。

作为本发明的一种健康社交平台Feed流***的数据高并发处理方法优选技术方 案，采用经验公式

，时间相差越大，权重越小；δ u，fi 为u与fi建立好友关系的时间，δ fi，fof 为fi与fof建立好友关系的时间，-0.3为惩罚因 子。

作为本发明的一种健康社交平台Feed流***的数据高并发处理方法优选技术方案，采用本地缓存Ehcache和集中式缓存redis组成的二级缓存，解决社交数据缓存过载。

a) 使用内存缓存时，一旦应用重启后，由于缓存数据丢失，缓存雪崩，给数据库造成巨大压力，导致应用堵塞；

b) 使用内存缓存时，多个应用节点无法共享缓存数据；

c) 使用集中式缓存，由于大量的数据通过缓存获取，导致缓存服务的数据吞吐量太大，带宽跑满。现象就是 Redis 服务负载不高，但是由于机器网卡带宽跑满，导致数据读取非常慢；

在遭遇问题a、b 时，使用 Redis 来缓存数据，因此就难以避免的导致了问题c的发生。

当发生问题c时，采用 Redis的集群，通过集群来降低缓存服务的压力。

作为本发明的一种健康社交平台Feed流***的数据高并发处理方法优选技术方案，利用现有的内存缓存框架作为一级缓存，把Redis作为二级缓存。

作为本发明的一种健康社交平台Feed流***的数据高并发处理方法优选技术方案，所有数据的读取先从一级缓存中读取，不存在时再从二级缓存读取，降低对二级缓存Redis 的访问次数。

作为本发明的一种健康社交平台Feed流***的数据高并发处理方法优选技术方案，一级缓存框架可以通过配置来控制在内存中存储的数据量，避免内存溢出。

与现有技术相比，本发明的有益效果是：

（1）通过对SNS社交***进行升级，可以实现千万级数据Feed流服务***设计开发，进而提供更好的***性能；且该处理方法优化增强社交推荐算法、优化数据精准匹配，以及社交关系中数据重复问题；有效的推动用户增加交流频率、活跃度，提升用户体验；

（2）本方法符合目前Feed流***的的业务需求和设计目标，有效解决了社交关系下将动态实时分发给订阅者的内容传播问题；通过将Feed内容和元数据分离的方式，有效的降低了Feed流***的内存需求；该方法采用应用层有机组合与常用开源稳定的存储方案结合的方式，降低了实现的的难度，极大的提高了扩展性。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1为本发明的Feed流发布流程图；

图2为本发明中的Feed流***图谱结构总体框图；

图3为本发明中的Feed流***逻辑结构框图；

图4为本发明中的Feed流读取流程图；

图5为时序推荐算法流程图；

图6为经验公式示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例

请参阅图1-6，本发明提供以下技术方案：tweet存储到数据库中，tweetmeta存储到timeline内，包括以下步骤：

S1，用户发布tweet时，根据social graph将tweetmeta通过fanout写入到timelinelist 中；只保存元数据，借助Redis能够很好的支持大量元数据推送；

S2，用户查看自己的timeline时，直接从自己的timeline取tweetmeta，然后再从DB中获取对应的tweet数据，本实施方案中的测试环境为单台4核 8G 千兆网卡Centos7.5服务器，在docker内部署redis4.2，mysql 5.7，feed流***。压测客户端使用apachejmeter5.3，100线程组压测10min。

具体的，发布Feed消息时；

1）.Feed消息先进入一个队列服务。从Feed消息中抽取出元数据(TweetMeta) 如发布人，发布域，发布时间，内容类型，内容id；

2）.将Feed消息存储到Mysql数据库内，存储成功后异步调用元数据发布服务进行发布；

3）.元数据发布服务从元数据内提取出发布人和发布域以及Feed消息的ID，调用社交关系服务来确定需要推送Feed的队列列表；

如果发布域是好友则通过社交关系服务获取发布人的好友列表；如果发布域是社群则通过社交关系服务获取社群的成员列表；其他情况按照社交关系获取对应的推送Feed队列；

4）.使用元数据发布服务的批量写入接口一次性将多行数据写入到多个Feed流内，发布Feed的流程到此结束。

具体的，读取Feed流的时；

1）.从Feed流中读取出最新的N条Feed消息的Feed ID(也可以按照一个范围区间进行读取，范围起始位置是上次读取到的最新Feed的ID，结束位置可以使当前时间，也可以是MAX)。；

2）.获取到Feed ID列表后，异步调用Feed内容存储接口（具备缓存功能），直接通过Id来读取相应的Feed内容；

3）.将2）中的结果进行合并，返回给用户。读取Feed流的流程就结束了。当用户获取更多数据时，以当前最后一条Feed的Score作为最大范围重复1）的过程即可。

本处理方法采用Redis有序集合（zset）作为底层构建feed推送功能。

1）Redis 有序集合和集合一样也是string类型元素的集合，且不允许重复的成员。

2）不同的是每个元素都会关联一个double类型的分数；redis正是通过分数来为集合中的成员进行从小到大的排序。

3）有序集合的成员是唯一的，但分数(score)却可以重复。

4）集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。 集合中最大的成员数为 2^32 - 1 (4294967295， 每个集合可存储40多亿个成员)。

具体的，采用三元闭包理论及共同好友与时序推荐算法；在共同好友的基础上，加入了时间维度；基于用户对新添加的好友更感兴趣的假设，本实施例中。

具体的，采用经验公式

，时间相差越大，权重 越小；δ u，fi 为u与fi建立好友关系的时间，δ fi，fof 为fi与fof建立好友关系的时间，- 0.3为惩罚因子；惩罚因子，是一个经验参数，需要根据具体情况进行调整；根据这个经验公 式能直接计算出好友推荐的得分，也可以作为一维特征与其他特征一起做回归。

具体的，采用本地缓存Ehcache和集中式缓存redis组成的二级缓存，解决社交数据缓存过载。

a) 使用内存缓存时，一旦应用重启后，由于缓存数据丢失，缓存雪崩，给数据库造成巨大压力，导致应用堵塞；

b) 使用内存缓存时，多个应用节点无法共享缓存数据；

c) 使用集中式缓存，由于大量的数据通过缓存获取，导致缓存服务的数据吞吐量太大，带宽跑满。现象就是 Redis 服务负载不高，但是由于机器网卡带宽跑满，导致数据读取非常慢；

在遭遇问题a、b 时，使用 Redis 来缓存数据，因此就难以避免的导致了问题c的发生。

当发生问题c时，采用 Redis的集群，通过集群来降低缓存服务的压力。

具体的，利用现有的内存缓存框架作为一级缓存，把Redis作为二级缓存。

具体的，所有数据的读取先从一级缓存中读取，不存在时再从二级缓存读取，降低对二级缓存 Redis 的访问次数。

具体的，一级缓存框架可以通过配置来控制在内存中存储的数据量，避免内存溢出。

本发明中因为社交Feed的时效性，Feed流内没有必要存储所有Feed 列表，只需要保存最新的Feed即可；

通过定时扫描Feed流内的Feed数量大小，当超过MAX_SIZE时，执行清除部分Feed的操作。Redis内整体存储数据量保持在一个相对稳定的状态，减轻服务器压力，同时提高***的稳定性；

当需要读取时间范围超出Feed流内数据时，直接通过Feed内存存储数据进行筛选出对应时间段内的Feed ID，然后通过Feed读取中的步骤3即可返回相应Feed内容。

feed流***在在压测过程中平均响应时间为92ms，tps为945；响应时间均值在100ms，部分响应时间会增加到200ms； tps均值在945，部分时间会降低至600。通过查看feed流jvm监控数据发现，频繁的写入请求导致JVM出现短时GC，造成tps下降，响应时间增大。可以通过增大jvm内存和调整gc参数减少GC次数。

Feed: Feed流中的每一条状态或者消息都是Feed，比如朋友圈中的一个状态就是一个Feed，微博中的一条微博就是一个Feed。

Feed流是持续更新并呈现给用户内容的信息流。每个人的朋友圈，微博关注页等等都是一个Feed流。

Timeline是一种Feed流的类型，微博，朋友圈都是Timeline类型的Feed流，但是由于Timeline类型出现最早，使用最广泛，最为人熟知，有时候也用Timeline来表示Feed流。

个人页Timeline用于展示自己发送过的Feed消息的页面，比如微信中的相册，微博的个人页等。

元数据MetaData是记录Feed流中的每一条状态或消息的元信息（如发布人，发布域，发布时间，内容类型，内容id等）的数据格式。

最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种健康社交平台Feed流***的数据高并发处理方法，其特征在于，tweet存储到数据库中，tweetmeta存储到timeline内，包括以下步骤：

S1，用户发布tweet时，根据social graph将tweetmeta通过fanout写入到timelinelist 中；只保存元数据，借助Redis能够很好的支持大量元数据推送；

S2，用户查看自己的timeline时，直接从自己的timeline取tweetmeta，然后再从DB中获取对应的tweet数据。

2.根据权利要求1所述的一种健康社交平台Feed流***的数据高并发处理方法，其特征在于：发布Feed消息时；

1）.Feed消息先进入一个队列服务；

从Feed消息中抽取出元数据(TweetMeta) 如发布人，发布域，发布时间，内容类型，内容id；

2）.将Feed消息存储到Mysql数据库内，存储成功后异步调用元数据发布服务进行发布；

3）.元数据发布服务从元数据内提取出发布人和发布域以及Feed消息的ID，调用社交关系服务来确定需要推送Feed的队列列表；

4）.使用元数据发布服务的批量写入接口一次性将多行数据写入到多个Feed流内。

3.根据权利要求2所述的一种健康社交平台Feed流***的数据高并发处理方法，其特征在于：读取Feed流的时；

1）.从Feed流中读取出最新的N条Feed消息的Feed ID；

2）.获取到Feed ID列表后，异步调用Feed内容存储接口（具备缓存功能），直接通过Id来读取相应的Feed内容；

3）.将2）中的结果进行合并，返回给用户；

读取Feed流的流程就结束了；

当用户获取更多数据时，以当前最后一条Feed的Score作为最大范围重复1）的过程即可。

4.根据权利要求1所述的一种健康社交平台Feed流***的数据高并发处理方法，其特征在于：采用三元闭包理论及共同好友与时序推荐算法；在共同好友的基础上，加入了时间维度；基于用户对新添加的好友更感兴趣的假设。

5.根据权利要求4所述的一种健康社交平台Feed流***的数据高并发处理方法，其特 征在于：采用经验公式

，时间相差越大，权重越小；δ u，fi 为u与fi建立好友关系的时间，δ fi，fof 为fi与fof建立好友关系的时间，-0.3为惩 罚因子。

6.根据权利要求5所述的一种健康社交平台Feed流***的数据高并发处理方法，其特征在于：采用本地缓存Ehcache和集中式缓存redis组成的二级缓存，解决社交数据缓存过载；

a) 使用内存缓存时，一旦应用重启后，由于缓存数据丢失，缓存雪崩，给数据库造成巨大压力，导致应用堵塞；

b) 使用内存缓存时，多个应用节点无法共享缓存数据；

c) 使用集中式缓存，由于大量的数据通过缓存获取，导致缓存服务的数据吞吐量太大，带宽跑满；

现象就是 Redis 服务负载不高，但是由于机器网卡带宽跑满，导致数据读取非常慢；

在遭遇问题a、b 时，使用 Redis 来缓存数据，因此就难以避免的导致了问题c的发生；

当发生问题c时，采用 Redis的集群，通过集群来降低缓存服务的压力。

7.根据权利要求6所述的一种健康社交平台Feed流***的数据高并发处理方法，其特征在于：利用现有的内存缓存框架作为一级缓存，把Redis作为二级缓存。

8.根据权利要求7所述的一种健康社交平台Feed流***的数据高并发处理方法，其特征在于：所有数据的读取先从一级缓存中读取，不存在时再从二级缓存读取，降低对二级缓存 Redis 的访问次数。

9.根据权利要求8所述的一种健康社交平台Feed流***的数据高并发处理方法，其特征在于：一级缓存框架可以通过配置来控制在内存中存储的数据量，避免内存溢出。

Images