1.本发明涉及redis数据库、计算机网络、多核cpu、计算机算法等领域，特别涉及一种减少网络交互并提升cpu利用率的架构。
背景技术：
2.redis是一个key-value结构的数据存储系统，提供了string、list、 set等多种数据结构，针对不同的数据结构提供了不同的api，可以实现一些基本的计算能力，例如：求和、去重、排序等算法。
3.在redis 6.0版本之前，其核心架构设计采用单线程模型，因为当时主流网络带宽在1gbps以下。因此，1gbps带宽下简单的数据查询流量，1个cpucore足以提供足够的算力需求。随着近年来新的网络技术发展，带宽突破了 1gbps的时候，redis单线程的模型也演化到多线程模型。
4.然而，当下1gbps网络基础设施仍被广为采用，另一方面，cpu架构多核已成为缺省配置。有些应用模型借助于redis实现存贮，需要频繁的拉取数据到应用服务器上，然后再进行大量的计算。在这一场景，主要有以下两个问题：
5.1、应用系统和redis之间的网络带宽压力是提升应用系统的一大瓶颈；
6.2、redis服务器的cpu能力无法被充分使用。
7.当下1gbps网络基础设施仍广为采用，另一方面，cpu架构多核已是标准配置。应用模型借助于redis实现存贮，频繁拉取数据到应用服务器后进行大量的计算。这仍然是是一种典型的应用模式，需要我们寻找好的解决方案，以应对网络带宽所面对的挑战。
8.网络吞吐已达瓶颈，能否降低对网络带宽的压力是我们必须面对和解决的问题。与此同时，对于多核cpu的能力进行利用，不浪费计算资源也是我们的另一个主要关注点。
9.因此，本案提出将计算从application端迁移到redis端，这样以来我们就可以减少application端与redis端网络交互，最终达成了降低网络带宽端压力的目的。同时部分计算转移到redis，也必然可以利用redis服务器富裕的其他cpu core。也就是说，能同时达成了以下两个目的:
10.1、降低应用系统和redis之间的网络带宽压力；
11.2、提高redis服务器的cpu使用能力。
12.以大数据实时聚合指标计算为例，计算某商户下某个用户过去一段时间实际的交易金额等复杂的标签。为了实现该算法，需要在redis存储原始的某商户下所有用户的交易明细记录，application从redis拉取特定用户的全记录集合，然后完成汇总。在这个过程中，application需要频繁的和redis 的交互，对网络带宽造成较大压力，而最终网络也将成为整个application 系统的瓶颈。
13.在本方案中，将计算从application侧抽取,然后转移到redis端， application只需要做数据写入和聚合查询，而所有的聚合计算均在redis内完成。这可以最大程度减少application与redis的交互，降低网络带宽的压力，同时把聚合计算迁移到redis上也提升
了对redis服务器上cpu的使用能力。
技术实现要素：
14.本发明要解决的技术问题是克服现有技术的缺陷，提供一种减少网络交互并提升cpu利用率的架构。
15.本发明提供了如下的技术方案：
16.本发明提供一种减少网络交互并提升cpu利用率的架构，该架构包括以下：
17.一、redis算法plugin服务
18.(algorithm-plugin-server)：由算法插件管理模块和算法插件注册模块两部分组成,实现算法插件的实例化，并注册到注册中心供后续使用；
19.a)算法插件管理模块(manager)：用户可以基于算法模版自行离线开发插件，然后在管理模块内将插件上传到注册中心，同时对外提供算法元数据信息；
20.b)算法插件注册中心模块(register)：接收到算法插件信息后通知到 redis，最终完成算法插件的实例化和运行时的注册；
21.二、redis服务：
22.由redis本身模块、算法对外暴露api、framework框架三部分组成，实现了算法插件的集成，进行数据的存储聚合计算，同时提供api以供外部 application使用；
23.a)redis本身模块：原redis数据库，主要提供数据存储；
24.b)算法对外暴露api(algorithm-api)：在原来redis暴露api的基础上水平扩展新的api，供外部application调用；
25.c)framework框架：主要负责算法插件的编译，进行插件与redis的集成；同时负责数据的监听，进行相应算法的计算；
26.三、application
27.表示一般的应用程序，其负责写入数据到redis，触发redis内算法计算，并最终直接查询计算结果。
28.作为本发明的一种优选技术方案，该架构中的操作与运行流程如下所示：
29.a、用户通将算法信息通过配置上传到算法插件管理模块，算法管理模块将配置信息编译生成一个算法脚本；同时将生成的算法脚本上传到注册中心；
30.b、算法插件注册中心模块接收到算法后，进行算法插件的解析,最终通知注册到framework；
31.c、framework调用脚本解释器完成脚本的编译和实例化；
32.d、framework完成插件的编译后同步起一个子进程，持续监听redis的写入命令；
33.e、application接收到算法的元数据信息后，开始启动应用，进行数据的清洗过滤，将清洗后的数据写入到redis中；
34.f、当子进程监听到redis中有新数据写入时，会调用算法脚本进行增量的数据计算，最后将计算后的数据结果再次写入到缓存中；
35.g、application最后负责查询计算后的数据。
36.与现有技术相比，本发明的有益效果如下：
37.1)在传统架构(如图3)中，所有的计算都集中在application端，计算过程中与
redis有大量的交互。因此，带宽往往成为应用性能的瓶颈，同时redis 服务器上的多核cpu也会造成资源闲置。本专利所提出的架构方案(如图1)，将算法动态集成到redis中，从而将计算从application端迁移到了redis 端。这样以来，既做到了提高redis服务器的资源利用率也降低了网络带宽的压力。
38.2)当前redis支持数据结构和特有的api，只能完成一些简单的算法。本案所提出的新架构，能够让用户自定义各种算法，丰富了redis的算法api，具有更广泛的适用性。
附图说明
39.附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：
40.图1是本发明的架构及装置示意图；
41.图2是本发明的新架构内部交互流程图
42.图3是本发明的传统架构的流程图；
43.图4是本发明的实时数据分析系统架构图。
具体实施方式
44.以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。其中附图中相同的标号全部指的是相同的部件。
45.实施例1
46.如图1-4，本发明提供一种减少网络交互并提升cpu利用率的架构，该架构包括以下：
47.一、redis算法plugin服务
48.(algorithm-plugin-server)：由算法插件管理模块和算法插件注册模块两部分组成,实现算法插件的实例化，并注册到注册中心供后续使用；
49.a)算法插件管理模块(manager)：用户可以基于算法模版自行离线开发插件，然后在管理模块内将插件上传到注册中心，同时对外提供算法元数据信息；
50.b)算法插件注册中心模块(register)：接收到算法插件信息后通知到 redis，最终完成算法插件的实例化和运行时的注册；
51.二、redis服务：
52.由redis本身模块、算法对外暴露api、framework框架三部分组成，实现了算法插件的集成，进行数据的存储聚合计算，同时提供api以供外部 application使用；
53.a)redis本身模块：原redis数据库，主要提供数据存储；
54.b)算法对外暴露api(algorithm-api)：在原来redis暴露api的基础上水平扩展新的api，供外部application调用；
55.c)framework框架：主要负责算法插件的编译，进行插件与redis的集成；同时负责数据的监听，进行相应算法的计算；
56.三、application
57.表示一般的应用程序，其负责写入数据到redis，触发redis内算法计算，并最终直
接查询计算结果。
58.该架构中的操作与运行流程如图2所示：
59.a、用户通将算法信息通过配置上传到算法插件管理模块，算法管理模块将配置信息编译生成一个算法脚本；同时将生成的算法脚本上传到注册中心；
60.b、算法插件注册中心模块接收到算法后，进行算法插件的解析,最终通知注册到framework；
61.c、framework调用脚本解释器完成脚本的编译和实例化；
62.d、framework完成插件的编译后同步起一个子进程，持续监听redis的写入命令；
63.e、application接收到算法的元数据信息后，开始启动应用，进行数据的清洗过滤，将清洗后的数据写入到redis中；
64.f、当子进程监听到redis中有新数据写入时，会调用算法脚本进行增量的数据计算，最后将计算后的数据结果再次写入到缓存中；
65.g、application最后负责查询计算后的数据。
66.实时数据分析系统是当前大型电商必可或缺的系统能力，被广泛应用于实时在线营销和商品推荐中。这里以该应用为例展示本案在具体应用中的实施方法与过程(如图4)。
67.a、用户通过服务端(algorithm-plugin-server)配置(某个商户下某个用户过去7天实际的交易金额)标签算法插件。
68.b、服务端将该算法的元数据信息提供给application(data analysissystem)端进行业务配置。
69.c、同时服务端中的注册中心(register)将算法插件注册到redis中，使算法插件生效。
70.d、application(data analysis system)端配置好算法后，启动流式应用，持续消费kafka中的数据，进行数据的初步筛选过滤，将需要的数据写入到redis中。
71.e、redis监听到新的数据写入时，启动算法插件进行数据计算，将计算后的标签数据重新写入到缓存中。
72.f、application(data analysis system)端根据约定好的标签格式进行标签数据的查询使用。
73.进一步的，本发明中具备以下要点：
74.1、提出了一种能够降低redis网络带宽并提升redis服务器cpu利用率的架构方案。
75.2、提出了一种redis服务侧算法与api热插拔方案。
76.最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。