一种适用于关注流任务的通用架构设计

摘要

本申请公开了一种适用于关注流任务的通用架构设计，包括基础数据字典模块、关注信息模块、关注托底模块、项目消费模块和对外接口模块，所述关注信息模块、关注托底模块、项目消费模块和对外接口模块均与基础数据字典模块连接。本申请可以保障业务系统的稳定性，保障关注流数据的实时性和数据可靠性，保证用户在app中的用户体验，架构采用redis作为主数据缓存，hbase作者为数据托底保证了数据的时效性和可靠性，实现关注流页面显示用户实时关注内容的显示分发，提供数据在关注页面的实时显示更新，给用户提供更好的浏览体验，数据进行业务和非业务的分层划分保障了数据的结构性稳健和快速回复以及高容灾性。

说明书

技术领域

本申请涉及一种通用架构设计，具体是一种适用于关注流任务的通用架构设计。

背景技术

关注流架构可以显示用户实时关注内容的显示分发，用户在使用app浏览关注的作者发布的内容时，当前端无法及时更新内容对用户或者关注取关的更新不及时对作者和用户都会造成体验上的不足，所以对于关注流的实时性和可靠性要求是必要的。

目前的基本方案有三种，方案一是通过关注关系单向时间排序返回存储在关系型数据库，但是当数据中关系复杂时会出现数据更新延迟严重，尤其大V数据出现时关系型数据库的性能瓶颈就是整个feed流的任务瓶颈，可扩展性不好，方案二是通过关注关系双向按推荐进行排序返回存储在nosql型数据库，但是在使用方案二时数据在nosql中如hbase中数据的显示性能问题会得到解，对于大V数据的并发数据性质会是一个主要问题，而且对于数据排序和关注取关操作等对nosql的操作非常频繁，导致数据删除等操作会相对比较耗时，更新效果性能是一大问题，方案三是通过关注关系混合按时间排序，存储主从形式，但是对于数据的结构设计可能是一个冗余瓶颈问题。因此，针对上述问题提出一种适用于关注流任务的通用架构设计。

发明内容

一种适用于关注流任务的通用架构设计，包括基础数据字典模块、关注信息模块、关注托底模块、项目消费模块和对外接口模块，所述关注信息模块、关注托底模块、项目消费模块和对外接口模块均与基础数据字典模块连接；

所述对外接口模块一侧连接后台操作模块，所述后台操作模块一侧连接第一关注流显示模块，所述对外接口模块另一侧连接用户端模块，所述用户端模块一侧连接第二关注流显示模块。

进一步地，所述基础数据字典模块包括数据接收模块和数据发送模块，所述关注信息模块包括数据缓存模块和关注信息数据处理模块。

进一步地，所述关注托底模块包括关注信息操作模块和关注信息更新模块，所述项目消费模块包括数据增删模块和消费逻辑处理模块。

进一步地，所述对外接口模块包括信息排列模块和时间信息模块。

进一步地，所述基础数据字典模块存储的数据包括公共数据，和基础数据字典以及基础的关注关系字典。

进一步地，所述基础数据字典模块以redis作为主数据缓存，hbase作为数据托底。

进一步地，所述关注托底模块中的数据信息包括每日离线计算t+1关注信息的基础信息和用以灾备的关联关系。

进一步地，所述项目消费模块包括作者内容增删、关注行为增删和作者增删。

进一步地，所述关注托底模块包括作者内容缓存t+1，作者粉丝缓存t+1、粉丝作者t+1和用户关注作者内容缓存t+1。

进一步地，所述基础数据字典模块包括作者内容缓存、作者粉丝缓存和粉丝作者缓存。

本申请的有益效果是：本申请提供了一种适用于关注流任务的通用架构设计。

附图说明

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

图1为本申请一种实施例的整体结构示意图；

图2为本申请一种实施例的关注流数据流转的过程示意图；

图3为本申请一种实施例的消费流程示意图；

图4为本申请一种实施例的关注流缓存处理逻辑流程示意图。

图中：1、基础数据字典模块；101、数据接收模块；102、数据发送模块；2、关注信息模块；201、数据缓存模块；202、关注信息数据处理模块；3、关注托底模块；301、关注信息操作模块；302、关注信息更新模块；4、项目消费模块；401、数据增删模块；402、消费逻辑处理模块；5、对外接口模块；501、信息排列模块；502、时间信息模块；6、后台操作模块；7、第一关注流显示模块；8、用户端模块；9、第二关注流显示模块。

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本申请中，术语“上”、“下”、“左”、“右”、“前”、“后”、“顶”、“底”、“内”、“外”、“中”、“竖直”、“水平”、“横向”、“纵向”等指示的方位或位置关系为基于附图所示的方位或位置关系。这些术语主要是为了更好地描述本申请及其实施例，并非用于限定所指示的装置、元件或组成部分必须具有特定方位，或以特定方位进行构造和操作。

并且，上述部分术语除了可以用于表示方位或位置关系以外，还可能用于表示其他含义，例如术语“上”在某些情况下也可能用于表示某种依附关系或连接关系。对于本领域普通技术人员而言，可以根据具体情况理解这些术语在本申请中的具体含义。

此外，术语“安装”、“设置”、“设有”、“连接”、“相连”、“套接”应做广义理解。例如，可以是固定连接，可拆卸连接，或整体式构造；可以是机械连接，或电连接；可以是直接相连，或者是通过中间媒介间接相连，又或者是两个装置、元件或组成部分之间内部的连通。对于本领域普通技术人员而言，可以根据具体情况理解上述术语在本申请中的具体含义。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

请参阅图1-4所示，一种适用于关注流任务的通用架构设计，包括基础数据字典模块1、关注信息模块2、关注托底模块3、项目消费模块4和对外接口模块5，所述关注信息模块2、关注托底模块3、项目消费模块4和对外接口模块5均与基础数据字典模块1连接，基础数据字典模块1包括作者内容缓存、作者粉丝缓存和粉丝作者缓存，用于存储公共数据和基础数据字典以及基础的关注关系字典；

所述对外接口模块5一侧连接后台操作模块6，后台操作模块6用于管理维护人员进行监控、维护，所述后台操作模块6一侧连接第一关注流显示模块7，所述对外接口模块5另一侧连接用户端模块8，所述用户端模块8一侧连接第二关注流显示模块9，第一关注流显示模块7和第二关注流显示模块9用于关注流信息显示，用户端模块8用于用户操作app。

所述基础数据字典模块1包括数据接收模块101和数据发送模块102，用于接收和调取数据信息，所述关注信息模块2包括数据缓存模块201和关注信息数据处理模块202，用于用户同步更新由基础字典更新导致的下游关注信息的更新；所述关注托底模块3包括关注信息操作模块301和关注信息更新模块302，用于每日离线计算t+1关注信息的基础信息和关联关系及时用以灾备，所述项目消费模块4包括数据增删模块401和消费逻辑处理模块402，用以生产端更新的数据操作对下游关注缓存的更新动作；所述对外接口模块5包括信息排列模块501和时间信息模块502，用于返回中台请求数据，并排序；所述基础数据字典模块1存储的数据包括公共数据，和基础数据字典以及基础的关注关系字典；所述基础数据字典模块1以redis作为主数据缓存，hbase作为数据托底，redis即远程字典服务，是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API，是一个key-value存储系统，和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set--有序集合)和hash(哈希类型)，这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的，在此基础上，redis支持各种不同方式的排序，hbase是一个分布式的、面向列的开源数据库，该技术来源于Fay Chang所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”，就像Bigtable利用了Google文件系统(File System)所提供的分布式数据存储一样，hbase在Hadoop之上提供了类似于Bigtable的能力，HBase-Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用hbase技术可在廉价PC Server上搭建起大规模结构化存储集群，hbase是Apache的Hadoop项目的子项目，hbase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库,另一个不同的是hbase基于列的而不是基于行的模式；所述关注托底模块3中的数据信息包括每日离线计算t+1关注信息的基础信息和用以灾备的关联关系；所述项目消费模块4包括作者内容增删、关注行为增删和作者增删；所述关注托底模块3包括作者内容缓存t+1，作者粉丝缓存t+1、粉丝作者t+1和用户关注作者内容缓存t+1；所述基础数据字典模块1包括作者内容缓存、作者粉丝缓存和粉丝作者缓存。

本申请在使用时，所述基础数据字典模块1包括作者内容缓存、作者粉丝缓存和粉丝作者缓存，用于存储公共数据和基础数据字典以及基础的关注关系字典，关注信息模块2包括用户关注作者内容缓存，用于用户同步更新由基础字典更新导致的下游关注信息的更新，关注托底模块3包括作者内容缓存t+1，作者粉丝缓存t+1、粉丝作者t+1和用户关注作者内容缓存t+1，用于每日离线计算t+1关注信息的基础信息和关联关系及时用以灾备，项目消费模块4包括作者内容增删逻辑、关注行为增删逻辑和作者增删逻辑，用以生产端更新的数据操作对下游关注缓存的更新动，对外接口模块5包括返回用户请求关注流页面信息并按时间顺序排列。

关注流数据流转的过程包括生产端产生关注流数据，消费端按相对逻辑消费关注流数据，字典缓存按逻辑更新，关注内容信息缓存按逻辑更新和接口请求按顺序返回相关数据，其中消费阶段用于生产端提供各种要求动作数据，消费端对分级缓存按设计关系进行逐步顺序动作，公共缓存变更阶段用于该阶段由消费端更新公共字典的内容数据，关注信息变更阶段用于当公共字典变更后有关联关系变更下游关注流信息内容，数据上报用于该阶段有借口请求对外接口返回变更后的关注流信息。

本申请在使用时为了提高数据的可靠性和关注流信息更新的时效性，将数据做了分级缓存处理，以便保证数据结构的稳健和更新的可操作，数据据生产端数据初始化，消费端会监测相关逻辑字段是否存在，消费端会根据最终配置，判断传入数据的合法性和有效性，如果生产端数据开始传入并且合法有效，则进入关注流逻辑处理阶段，那么其执行步骤如下，消费程序判断消费信息是属于哪一模块处理逻辑进行数据分发，准备数据对字典缓存进行数据处理，该阶段由于都是字典数据处理效率会很高，字典缓存处理结束，会根据逻辑处理对应下游关注数据流的缓存数据，关注流数据处理广播数据，进行关注流内容数据的变更此阶段分冷用户和热用户，若热用户直接处理关注信息的缓存数据，若为冷用户则在会在字典缓存中获取关注关系，获取关注内容填充进关注流内容缓存保证数据的准确性，前端接口发送请求，接口处理关注流缓存返回结果数据。

本申请的有益之处在于：

本申请可以保障业务系统的稳定性，保障关注流数据的实时性和数据可靠性，保证用户在app中的用户体验，架构采用redis作为主数据缓存，hbase作者为数据托底保证了数据的时效性和可靠性，实现关注流页面显示用户实时关注内容的显示分发，提供数据在关注页面的实时显示更新，给用户提供更好的浏览体验，数据进行业务和非业务的分层划分保障了数据的结构性稳健和快速回复以及高容灾性。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。