一种推荐方法及服务器与流程

1.本发明涉及推荐系统技术领域，尤其涉及一种推荐方法及服务器。


背景技术：

2.终端中安装的某些应用配置有推荐系统，推荐系统用于根据用户行为、用户信息、库内标的物信息等内容，向用户推荐符合其兴趣偏好的标的物，例如视频应用标的物体现为片源，交易应用标的物体现为实体/虚拟商品。以视频应用为例，推荐系统根据用户对视频的行为操作(如点击、观看、收藏和分享等)，来分析用户可能感兴趣的视频类型，在库内的候选片源中筛选与该视频类型匹配的推荐片源，并在指定的推荐页面向用户显示推荐片源，这样既能满足用户观看偏好视频的需求，也有利于应用平台的资源推广和运营。
3.一些场景中，在业务高峰期，访问流量可能超出推荐系统的承载能力，推荐系统可实施服务降级策略，例如向客户端返回兜底数据或限流等，进而降低系统压力，至少保证系统核心业务可用，但这些降级策略属于有损服务降级，导致用户无法享受正常的推荐系统服务，尤其对于应用平台内的有价值用户，例如视频应用内的会员用户，交易应用内的高消费用户等，有损服务降级会影响用户体验，不利于应用平台维系重要客户和发展潜在用户。


技术实现要素：

4.为解决上述背景技术中论述的问题，本发明提供一种推荐方法及服务器，在服务器中设置不同级别的降级模式，基于用户等级及推荐系统的当前运行情况，实施差异化弹性降级策略。
5.第一方面实施例提供的服务器，包括：
6.通信器，用于与终端设备通信连接；
7.控制器，被配置为执行：
8.监控到满足降级条件时，查询当前在线用户的用户等级以及为不同用户等级预设的降级模式组合，所述降级模式组合内排序有多种档位的降级模式；
9.确定与所述服务器的当前运行状态匹配的降级策略，所述降级策略指示每个用户等级对应的降级模式的档位；
10.在执行所述降级策略后，向每个在线用户的终端设备发送对应的推荐信息。
11.第二方面实施例提供由服务器执行的推荐方法，包括：
12.监控到满足降级条件时，查询当前在线用户的用户等级以及为不同用户等级预设的降级模式组合，所述降级模式组合内排序有多种档位的降级模式；
13.确定与服务器当前运行状态匹配的降级策略，所述降级策略指示每个用户等级对应的降级模式的档位；
14.在执行所述降级策略后，向每个在线用户的终端设备发送对应的推荐信息。
15.本技术场景中，用户a访问推荐引擎后，服务器端生成与用户a兴趣偏好相符的推荐信息，并将该推荐信息推送至用户a的终端设备a(即客户端)，终端设备a即可在推荐页面
中向用户a展示该推荐信息，由于服务器同时与大量终端通信，在线用户众多，若服务器的访问流量超过自身负荷，就会触发降级机制。
16.本技术根据用户历史行为，进行用户等级的分类，所述用户等级体现了用户对应用平台的重要性和价值，在降级机制下，更倾向于优先向高等级用户提供无损推荐服务，因此为每个用户等级制定对应的降级模式组合，例如用户等级1对应于降级模式组合1，用户等级2对应于降级模式组合2等等。每个用户等级下的降级模式组合中包括多种档位的降级模式，并对档位排序，所述档位体现了降级模式的服务有损程度以及对系统算力的消耗程度，档位越高则算力消耗越大，但服务有损程度越低(越接近于无损服务)，因此需要基于服务器的运行状态，掌握服务器的负荷/访问流量情况，在触发降级机制时，匹配最佳的降级策略，以划分2个用户等级为例，假设用户等级1高于用户等级2，用户等级1对应的降级模式组合1按序包括{档位11，档位12，档位13，档位14}，用户等级2对应的降级模式组合2按序包括{档位21，档位22，档位23，档位24}，则在确定降级策略时，优先保持用户等级1处于最高的档位11，使用户等级2的降级模式从档位21开始下调，假设在下调至档位24时，系统解除超负荷，则降级策略确定为用户等级1对应的降级模式为档位11，用户等级2对应的降级模式为档位24。假设用户b属于用户等级1的范畴，则利用档位11的降级模式得到推荐信息b，并将推荐信息b推送至用户b的终端；假设用户d属于用户等级2的范畴，则利用档位24的降级模式得到推荐信息d，并将推荐信息d推送至用户d的终端，从而为不同等级用户适配降级档位，优先保留对高等级用户的无损服务能力，实现差异化弹性降级策略，降级策略可以随系统运行状态动态自适应，提升了推荐系统的降级动态响应能力。
附图说明
17.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要访问的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
18.图1示出了根据一些实施例的终端设备与服务器的推荐交互场景；
19.图2中示例性示出了终端显示推荐页面的示意图；
20.图3中示例性示出了推荐系统的模型架构示意图；
21.图4中示例性示出了多路召回策略的示意图；
22.图5中示例性示出了用户等级的分类示意图；
23.图6中示例性示出了用户等级与降级模式组合的关系配置图；
24.图7中示例性示出了第一种降级调试的示意图；
25.图8中示例性示出了第二种降级调试的示意图；
26.图9中示例性示出了第三种降级调试的示意图；
27.图10中示例性示出了第四种降级调试的示意图；
28.图11中示例性示出了在图8基础上进行降级恢复的示意图一；
29.图12中示例性示出了在图9基础上进行降级恢复的示意图二；
30.图13中示例性示出了一种服务器的结构示意图；
31.图14中示例性示出了一种服务器的架构配置示意图；
32.图15中示例性示出了终端与服务器之间的推荐交互处理逻辑；
33.图16中示例性示出了服务器端执行的推荐方法的流程图。
具体实施方式
34.为使本技术的目的和实施方式更加清楚，下面将结合本技术示例性实施例中的附图，对本技术示例性实施方式进行清楚、完整地描述，显然，描述的示例性实施例仅是本技术一部分实施例，而不是全部的实施例。
35.需要说明的是，本技术中对于术语的简要说明，仅是为了方便理解接下来描述的实施方式，而不是意图限定本技术的实施方式。除非另有说明，这些术语应当按照其普通和通常的含义理解。
36.术语“包括”和“具有”以及他们的任何变形，意图在于覆盖但不排他的包含，例如，包含了一系列组件的产品或设备不必限于清楚地列出的所有组件，而是可包括没有清楚地列出的或对于这些产品或设备固有的其它组件。
37.术语“模块”是指任何已知或后来开发的硬件、软件、固件、人工智能、模糊逻辑或硬件或/和软件代码的组合，能够执行与该元件相关的功能。
38.在一些场景实施例中，图1示例出终端设备与服务器的推荐交互场景，服务器100可与多个终端设备200通信交互，终端设备200不限于智能电视、智能手机、平板电脑、笔记本电脑等具有显示功能的移动或固定终端，终端设备200可通过局域网(lan)、无线局域网(wlan)和其他网络与服务器100进行通信连接，服务器100可以是一个集群，也可以是多个集群，可包括一类或多类服务器。
39.在一些场景实施例中，用户可在终端设备200访问及查看推荐页面，不同应用平台所推荐的标的物类型不同，例如视频应用可显示推荐片源，交易应用可显示推荐商品，浏览器应用可推荐资讯等，终端设备200向服务器100发送推荐请求，服务器100响应于推荐请求，可根据用户历史行为、最近热门/流行的标的物等因素，生成匹配于用户兴趣偏好的推荐信息，并将推荐信息推送给终端设备200，终端设备200在相应的推荐页面中展示推荐信息。
40.在一些场景实施例中，以终端设备200为智能电视为例，如图2所示，应用平台中可以创建专门的推荐页面，例如在视频点播程序的界面中的导航栏21中增设如“推荐”、“猜你喜欢”等类似的控件，例如用户点击图2中的推荐控件211，即可进入推荐页面，推荐页面中向用户显示由服务器100中的推荐系统进行大数据建模后，预测输出并推送的符合用户兴趣偏好的推荐信息212。
41.在一些实施例中，推荐页面可以按照预设模板进行显示，所述预设模板包括推荐信息的数量、优先级、排版布局等，使推荐页面按照预设的板式展示给用户，用户可通过如翻页、滑动等操作形式来切换推荐信息212。
42.在一些实施例中，可以设置焦点，并且该焦点可跟随用户切换推荐信息的动作而同步移动，从而使用户准确定位当前被选中的目标推荐信息具有焦点的推荐信息一般需要作醒目处理，例如将该推荐信息做高亮处理、适度放大该推荐信息等，使焦点与非焦点有较为突出的对比，便于用户分辨。
43.在一些实施例中，参照图2，每项推荐信息212例如可包括预览图像、标的物信息和
链接于推荐信息的触发控件等。例如对于视频应用，预览图像是从片源视频中任意选取的一帧图像并作缩略处理后得到；标的物信息体现为视频信息，包括但不限于视频时长、视频名称、视频内容简介等，以便用户快速了解所推荐视频的简要信息，并筛选出期望观看的目标视频；触发控件体现为播放控件，当用户点击目标推荐信息时触发播放控件，跳转至目标视频的播放界面，从而起播目标视频。又例如，对于交易应用，预览图像是对商品图片进行缩略处理后得到；标的物信息体现为商品信息，包括但不限于商品品牌、品类、价格等，以便用户筛选出期望购买的目标商品；触发控件体现为链接跳转控件，当用户点击目标推荐信息时触发链接跳转控件，使ui跳转至商品详情页面。对于不同的应用平台和终端，推荐页面显示的标的物类型以及ui显示效果可适应性设置，不限于本技术实施例的示例。
44.在一些实施例中，服务器100中配置有不同应用平台的推荐系统，图3示例一种推荐系统的模型架构，整体上包括输入层和输出层两个层面。在输入层中采集数据集，所述数据集不限于包括用户数据、标的物数据等，其中用户数据可包括用户信息、用户行为数据等，用户行为数据是用户对标的物产生的行为，例如用户点击、收藏、加购物车、购买、评价了哪些商品的行为记录，用户信息不限于包括年龄、性别、所在地等信息；标的物数据不限于包括标的物类别等详情信息、交易量、点击量、标的物入库时间等相关信息。输入层采集数据集后，调用训练模型对数据集进行处理得到特征集，所述特征集不限于包括用户特征、标的物特征、场景特征、用户行为特征等，将特征集作为数据样本传输给输出层，从而为输出层的预测训练提供数据支持。
45.在一些实施例中，参照图3，输出层不限于包括召回层和排序层，召回层用于根据召回策略，从候选集中筛选出用户可能感兴趣的标的物，比如候选集中包括百万甚至千万量级的商品，通过召回层后可缩减至几十或几百量级，从而降低推荐延迟，使用户能够快速得到商品推荐反馈。排序层通过调用排序模型，对召回层召回的标的物进行精准排序，以标的物是商品为例，计算召回商品的得分，按照得分由高至低的顺序对召回商品进行排序，从而输出推荐结果。所述推荐结果可采用如集合、列表等排序组合形式，终端设备200接收到服务器100返回的推荐结果后，按照推荐结果指示的排序，在推荐页面中按序展示各项推荐信息，以使更符合用户兴趣偏好的标的物靠前展示。
46.在一些实施例中，对于召回层，期望召回标的物的丰富度和全面覆盖性较高，但召回数量过多却会影响系统运算速度，进而增加推荐延迟，为兼顾召回率和召回运算速度，可采用多路召回策略。如图4所示，该策略下召回层包括q个召回通道，每个召回通道对应于一种召回子策略，例如图4中召回通道1对应于从候选集中召回热门商品、召回通道2对应于利用协同过滤规则从候选集中召回商品，召回通道q对应于根据兴趣标签从候选集中召回商品，等等，召回通道w会召回前sw个商品，w用于标识召回通道的序号，1≤w≤q，每路召回通道的sw值可相同或不同，将每路召回通道的召回结果分别输入排序层，或者也可将多路召回结果汇总后输入排序层，并由排序层进行精准排序。多路召回策略的优势在于并行多种召回子策略，避免单一召回策略所导致的精确度低和覆盖范围窄，并且依赖于小型子策略的简单模型计算，能够大幅降低响应时间。
47.在一些实施例中，每路召回通道可设置通道开关，实现独立控制每路召回通道的开启(on)或关闭状态(off)，从而决策召回层所启用的召回通道的类别和数量。推荐系统的架构、以及各层级采用的模型和算法不作限定。
48.为解决背景技术中存在的问题，本技术提供一种基于用户等级分类和推荐系统运行状态，实施差异化弹性降级策略的方案。在一些实施例中，可根据用户历史行为、用户活跃度等因素，来预估用户价值，具体地，可借助某些用户价值分类模型来划分多种用户价值，例如采用rfm模型，rfm模型包括recency(最近一次交易)、frequency(交易频率)和monetary(交易金额)这三项衡量指标，例如划分为重要价值客户、重要发展客户、重要挽留客户、重要唤回客户、一般价值客户、一般保持客户、一般发展客户、一般挽留客户等，重要价值客户是指rfm三项指标均突出，属于优质客户，需要重点维系；重要发展客户是指交易金额大且贡献度高，最近有交易，需要重点识别和维系；重要挽留客户是指交易金额大，潜在的有价值客户，需要挽留；重要唤回客户是指交易金额和交易次数较大，但最近无交易，需要唤回；一般价值客户、一般保持客户、一般发展客户和一般挽留客户相对于前述重要级别的用户，其rfm水平要较差一些。
49.在一些实施例中，根据模型划分出的用户价值，对用户等级进行分类界定及排序，用户等级和用户价值可同步或非同步，例如前述rfm模型划分出8类价值用户，则可将用户等级同步划分为8类，或者根据用户价值的相似性，对用户价值进行归类，例如将重要价值客户和重要发展客户归类为用户等级1，将重要挽留客户和重要唤回客户归类为用户等级2，将一般价值客户和一般保持客户归类为用户等级3，将一般发展客户和一般挽留客户归类为用户等级4，并制定用户等级排序，例如用户等级从高到低为用户等级1＞用户等级2＞用户等级3＞用户等级4。用户等级体现了用户对应用平台的重要性和价值。需要说明的是，用户等级的分类方式不限于本实施例，用户等级的数量和类别不限定。
50.在一些实施例中，参照图5的示例，设用户等级的分类数量为n，用户等级i内分布的用户数量为ri，1≤i≤n，i表示用户等级从高到低排序后的等级序号，即i值越小用户等级越高，i值越大用户等级越低。ri取值不是固定的，例如用户a在交易应用中新注册时被划分到最低用户等级(即用户等级n)，但随着用户a在后续交易中频率和金额的累积，并且属于长期稳定且活跃的用户，因此用户a的等级评估会逐步升级，甚至上升到最高用户等级(即用户等级1)；又例如，用户b原属于用户等级2，但用户b在之后较长时间内都未产生过任何交易，则对用户b的等级评估可能会降级，例如逐渐下降到排序靠后的较低等级。因此，各用户等级内的用户分布及其数量ri都是随用户行为而动态可变的。
51.在一些实施例中，参照图5，对于推荐系统而言，每个用户等级内可分布有在线用户和离线用户，所述在线用户是指已登录应用平台，并且访问推荐引擎来请求推荐信息的终端用户；所述离线用户是指未启动或未登录应用平台，或者未请求推荐信息的终端用户，即服务器100仅向在线用户推送推荐信息，不向离线用户推送推荐信息。
52.在一些实施例中，参照图6示例的用户等级与降级模式组合的关系配置，本技术为每个用户等级预设对应的降级模式组合，设user_leveli表示第i个用户等级，user_leveli对应的降级模式组合表示为degrademodei，degrademodei排序有多种档位的降级模式，设degrademodei中排序在第j个档位的降级模式表示为mode_level
i,j
，1≤j≤mi，mi表示degrademodei内包括的降级模式总数。即从纵向分布来看，i值递增则用户等级逐级下降；从横向分布来看，对于每个降级模式组合，j值递增则档位被逐渐调低。其中，各用户等级下的mi值可相同或不同。
53.对于每个降级模式组合，其内档位体现了降级模式的服务有损程度以及对系统算
力的消耗程度，档位越高则算力消耗和系统负荷越大，但服务有损程度越低(即越接近于无损服务)。
54.在一些实施例中，每个降级模式组合内的最高档位，即mode_level
i,1
全部配置为正常推荐模式，即非降级状态下的无损降级模式，为用户提供无损推荐服务。
55.在一些实施例中，对于mode_level
i,j
，2≤j≤mi，这些档位全部属于有损降级模式。对于每个降级模式组合内的最低档位，即mode_level
i,mi
全部配置为返回兜底数据，即停止实质的推荐运算，服务器100仅向终端设备200返回预设的兜底数据，所述兜底数据不限于预先准备好的静态页面数据、预设推荐列表等，以供终端设备200的推荐页面进行展示。
56.在一些实施例中，对于mode_level
i,j
，1≤j＜mi，即每个降级模式组合内非最低档位的降级模式，可定义有输出推荐信息所使用的召回策略和排序策略，所述召回策略包括候选集的大小、所开启的召回通道的数量和类别等，候选集越大则召回层的算力消耗和系统负荷越大，在多路召回策略下，开启的召回通道数量越多则召回层的算力消耗和系统负荷越大。所述排序策略包括排序策略的启闭状态以及所调用的排序模型类别，排序策略若指示为关闭状态，则不调用任何排序模型，跳过排序层而直接输出召回结果，因此会降低系统的算力消耗和负荷；排序策略若指示为开启状态，则排序层需要调用排序模型执行运算处理，其中所调用的排序模型类别也会影响系统的算力消耗和负荷，例如调用的排序模型复杂度越高则系统的算力消耗和负荷越大，调用的排序模型越简单则系统的算力消耗和负荷越小。
57.因此，可根据不同的召回策略和排序策略，对每个降级模式组合进行档位划分和档位模式配置，例如若召回通道较多，候选集较大，调用的排序模型较为复杂，则对应的降级模式档位较高；若召回通道单一，候选集较小，不调用任何排序模型或调用的排序模型较为简单，则对应的降级模式档位较低。
58.在完成用户等级分类，并且配置好各用户等级对应的降级模式组合等前提工作以后，即可实施本技术的差异化弹性降级策略。在一些实施例中，服务器可实时监控自身的运行状态，例如监控cpu利用率、内存消耗、rt(reaction time，响应时间，表征系统对请求作出响应的时间)等状态指标，当其中至少一项状态指标超过阈值约束，即监控到系统当前满足降级条件，需要触发降级机制。
59.在一些实施例中，如果cpu利用率、内存占用、rt等任意一项状态指标超过阈值，都会导致系统当前的超时请求比例增加，因此可以利用超时请求比例来决策是否触发降级机制，所述超时请求比例用于表征超时请求在全部请求中的占比。若超时请求比例大于预设阈值，则判定满足降级条件；若超时请求比例在预设阈值限制范围内，则未满足降级条件，无需启动降级机制。
60.在一些实施例中，在未触发降级机制的情况下，服务器控制自身推荐系统按照正常推荐策略工作，所述正常推荐策略是指每个用户等级对应的降级模式都为各自组合内的最高档位，即user_leveli对应的降级模式为mode_level
i,1
，即允许为每个用户等级下的在线用户提供无损服务。
61.在一些实施例中，若满足降级条件，则确定与服务器的当前运行状态匹配的降级策略，所述降级策略用于指示每个用户等级对应触发的降级模式档位，基于优先保留对高
等级用户的无损服务的原则，从最低用户等级开始，参照图6，即以degrademoden中的mode_level
n,1
作为降级起点，按序下调user_leveln对应的降级档位，同时监控当前系统负荷，user_leveln对应的降级档位下降，当前系统负荷也随之下降，若降至mn为degrademoden的档位总数，即已降至degrademoden的最低档位时，当前系统负荷仍超过系统负荷上限，则继续下调前一用户等级user_level
n-1
的降级档位，以此类推，直至当前系统负荷被降低至小于或等于系统负荷上限，或者直至全部用户等级都下调至各自组合内的最低档位，停止降级策略的调试流程。
62.在一些实施例中，设i表示用户等级从高到低排序后的等级序号，以i从n递减的优先级顺序，即i初始为n，纵向降级的优先级顺序为用户等级从低向高，按照degrademodei内的档位排序，依序下调user_leveli对应的降级模式的档位，即横向降级的顺序为档位由高到低，即优先对低等级用户进行服务降级，保留对高等级用户的无损服务，在降档过程中同步更新ki的取值，ki表示user_leveli对应的当前降级模式的档位序号，user_leveli对应的降级档位每被下调一档，则将ki的取值累积加一。其中，i的初始值为n，但在实施降级机制过程中，i值是变量，当user_leveli对应的降级档位下调至mode_level
i,mi
(即degrademodei内的最低档位)时，当前系统负荷仍超出系统承载能力，则对高一级的用户等级继续下调降级档位，即有i＝i-1。
63.在一些实施例(a1)中，直至当前系统负荷被降低至小于或等于系统负荷上限时，若满足i等于n并且kn≤mn，说明仅最低用户等级被有损降级，其他用户等级均可保留无损服务，则该场景下配置的降级策略为前n-1个用户等级对应的降级模式为各自组合内的最高档位，第n个用户等级对应的降级模式为第n个降级模式组合内的第kn档位。
64.在一些实施例(a2)中，直至当前系统负荷被降低至小于或等于系统负荷上限时，若满足1＜i＜n并且ki≤mi，说明前i-1个用户等级可保留无损服务，从第i个用户等级以后均为有损降级，因此该场景下配置的降级策略为前i-1个用户等级对应的降级模式为各自组合内的最高档位，第i个用户等级对应的降级模式为第i个降级模式组合内的第ki档位，第i 1～第n个用户等级对应的降级模式为各自组合内的最低档位。
65.在一些实施例(a3)中，直至当前系统负荷被降低至小于或等于系统负荷上限时，若满足i＝1并且k1＜m1，说明第2～第n个用户等级均为有损降级并且都已被调至各自组合内的最低档位，而最高用户等级虽也为有损降级但未调至最低档位，因此该场景下配置的降级策略为第1个用户等级对应的降级模式为第1个降级模式组合内的第k1档位，第2～第n个用户等级对应的降级模式为各自组合内的最低档位。
66.在一些实施例(a4)中，直至满足i等于1并且k1等于m1，说明全部用户等级的降级模式都被下调至各自组合内的最低档位，降级已全面覆盖各个用户等级，并且属于最大程度的降级和算力释放，此时无论当前系统负荷是否下降至系统负荷上限内，都需要停止降级策略的调试过程，因此该场景下配置的降级策略为n个用户等级对应的降级模式均为各自组合内的最低档位。
67.在一些实施例中，系统负荷是动态变化的，例如在线用户减少、服务器的访问流量降低、实施服务降级等，都会缓解系统压力，因此服务器在监控到降级条件被解除时，可逐渐对有损降级进行逆向恢复。
68.在一些实施例中，基于优先恢复高等级用户被降级的推荐服务的原则，与前述降
级调试相反地，以i值递增的优先级顺序，即以前述停止降级调试时的i值为初始值，纵向恢复的优先级顺序为用户等级从高向低，按照degrademodei内的档位排序，依序上调user_leveli对应的降级模式的档位，即横向恢复的顺序为档位由低到高，在升档过程中同步更新ki的取值，ki表示user_leveli对应的当前降级模式的档位序号，user_leveli对应的降级档位每被上调一档，则将ki的取值减一。其中，在实施降级恢复过程中，i值同样是变量，当user_leveli对应的降级档位上调至mode_level
i,1
(即degrademodei内的最高档位)时，若当前系统负荷未达到系统承载能力的上限，则对低一级的用户等级继续上调降级档位，即有i＝i 1，以此类推，直至当前系统负荷上升至系统负荷上限，或者直至n个用户等级对应的降级模式全部恢复为各自组合内的最高档位为止。
69.在一些实施例(b1)中，对于前述实施例(a1)的场景，在进行降级恢复时，由于i＝n，因此前n-1个用户等级未作降级处理,仅需针对user_leveln，以degrademoden内的为起点，按序上调档位，同时监控当前系统负荷，直至当前系统负荷上升至系统负荷上限，或者直至档位调至mode_level
n,1
，则停止降级恢复流程。
70.在一些实施例(b2)中，对于前述实施例(a2)的场景，前i-1个用户等级未作降级处理，以degrademodei内的为起点，按照横纵向恢复的优先级顺序，逐渐上调档位，同时监控当前系统负荷，直至当前系统负荷上升至系统负荷上限，或者直至档位调至mode_level
n,1
，则停止降级恢复流程。
71.在一些实施例(b3)中，对于前述实施例(a3)的场景，n个用户等级都被有损降级，则以degrademode1内的为起点，按照横纵向恢复的优先级顺序，逐渐上调档位，同时监控当前系统负荷，直至当前系统负荷上升至系统负荷上限，或者直至档位调至mode_level
n,1
，则停止降级恢复流程。
72.在一些实施例(b4)中，对于前述实施例(a4)的场景，n个用户等级全部进行组合内最低档位的降级，则以degrademode1内的为起点，按照横纵向恢复的优先级顺序，逐渐上调档位，同时监控当前系统负荷，直至当前系统负荷上升至系统负荷上限，或者直至档位调至mode_level
n,1
，则停止降级恢复流程。
73.在一些实施例中，参照图7～图12，是以划分三个用户等级(即n＝3)、每个用户等级对应的降级模式集合中包括四个档位(即mi＝4，i＝1,2,3)为例，对前述降级调试和降级恢复流程进行示例性描述。
74.在一些实施例中，如图7所示，在触发降级调试前，假设user_level1对应的降级档位为mode_level
1,1
，user_level2对应的降级档位为mode_level
2,1
，user_level3对应的降级档位为mode_level
3,1
，即各用户等级都处于各自组合内的最高档位，支持向各等级在线用户提供无损服务，在监控到满足降级条件时，触发降级调试，参照图7，对应于前述实施例(a1)的场景，档位下调顺序为mode_level
3,1
(降级调试起点)
→
mode_level
3,2
→
mode_level
3,3
(降级调试终点)，即当下调至mode_level
3,3
档位时，当前系统负荷被降低至小于或等于系统负荷上限，无需再继续下调，停止降级调试流程，并确定降级策略为{user_level1：mode_level
1,1
；user_level2：mode_level
2,1
；user_level3：mode_level
3,3
}。
75.在一些实施例中，如图8所示，对应于前述实施例(a2)的场景，档位下调顺序为mode_level
3,1
(降级调试起点)
→
mode_level
3,2
→
mode_level
3,3
→
mode_level
3,4
→
切换至
user_level2→
mode_level
2,1
(user_level2的调档起点)
→
mode_level
2,2
(降级调试终点)，即当调至mode_level
2,2
档位时，当前系统负荷被降低至小于或等于系统负荷上限，则停止降级调试流程，确定降级策略为{user_level1：mode_level
1,1
；user_level2：mode_level
2,2
；user_level3：mode_level
3,4
}。
76.在一些实施例中，如图9所示，对应于前述实施例(a3)的场景，档位下调顺序为mode_level
3,1
(降级调试起点)
→
mode_level
3,2
→
mode_level
3,3
→
mode_level
3,4
→
切换至user_level2→
mode_level
2,1
(user_level2的调档起点)
→
mode_level
2,2
→
mode_level
2,3
→
mode_level
2,4
→
切换至user_level1→
mode_level
1,1
(user_level1的调档起点)
→
mode_level
1,2
(降级调试终点)，即当调至mode_level
1,2
档位时，当前系统负荷被降低至小于或等于系统负荷上限，则停止降级调试流程，确定降级策略为{user_level1：mode_level
1,2
；user_level2：mode_level
2,4
；user_level3：mode_level
3,4
}。
77.在一些实施例中，如图10所示，对应于前述实施例(a4)的场景，档位下调顺序为mode_level
3,1
(降级调试起点)
→
mode_level
3,2
→
mode_level
3,3
→
mode_level
3,4
→
切换至user_level2→
mode_level
2,1
(user_level2的调档起点)
→
mode_level
2,2
→
mode_level
2,3
→
mode_level
2,4
→
切换至user_level1→
mode_level
1,1
(user_level1的调档起点)
→
mode_level
1,2
→
mode_level
1,3
→
mode_level
1,4
(降级调试终点)，即已实施最大程度降级，则停止降级调试流程，确定降级策略为{user_level1：mode_level
1,4
；user_level2：mode_level
2,4
；user_level3：mode_level
3,4
}。
78.在一些实施例中，如图11所示，以在图8场景下进行降级恢复为示例，档位上调顺序为mode_level
2,2
(降级恢复起点)
→
mode_level
2,1
→
切换至user_level3→
mode_level
3,4
(user_level3的调档起点)
→
mode_level
3,3
→
mode_level
3,2
→
mode_level
3,1
(降级恢复终点)，即在未超过系统负荷上限的前提下，将三个用户等级全部恢复至无损服务模式，即实现了降级的充分恢复，因此停止降级恢复流程，转换至正常推荐策略，正常推荐策略为{user_level1：mode_level
1,1
；user_level2：mode_level
2,1
；user_level3：mode_level
3,1
}。
79.在一些实施例中，如图12所示，以在图9场景下进行降级恢复为示例，档位上调顺序为mode_level
1,2
(降级恢复起点)
→
mode_level
1,1
→
切换至user_level2→
mode_level
2,4
(user_level2的调档起点)
→
mode_level
2,3
→
mode_level
2,2
→
mode_level
2,1
→
切换至user_level3→
mode_level
3,4
(user_level3的调档起点)
→
mode_level
3,3
(降级恢复终点)，即当恢复至mode_level
3,3
档位时，当前系统负荷达到系统负荷上限，若继续恢复将会超出系统承载能力，因此停止降级恢复流程，此时降级策略由恢复前的{user_level1：mode_level
1,2
；user_level2：mode_level
2,4
；user_level3：mode_level
3,4
更新为恢复后的{user_level1：mode_level
1,1
；user_level2：mode_level
2,1
；user_level3：mode_level
3,3
}，由于user_level3仍处于有损降级，属于降级的未充分恢复情形。
80.在一些实施例中，服务器在调试决策或动态更新降级策略后，根据降级策略中指示的各用户等级对应的降级模式档位，控制自身推荐系统按照档位降级模式中定义的召回策略和排序策略，预测并输出与每个在线用户兴趣偏好匹配的推荐结果，并将相应的推荐结果返回给不同等级内的在线用户所使用的终端设备200，以使终端设备200在推荐页面中显示推荐结果；或者，对于被降级至最低档位的用户等级，服务器将预设的兜底数据返回给该用户等级内的在线用户使用的终端设备200，终端设备200在推荐页面中加载显示兜底数
据。
81.在一些实施例中，例如用户a被评估并划分到user_level2，用户a使用的终端设备a向服务器发送推荐请求后，服务器根据系统当前运行状态来决策降级策略，降级策略中指示user_level2的降级模式为mode_level
2,2
档位，则推荐系统利用mode_level
2,2
计算出为用户a提供的推荐信息a，服务器将推荐信息a发送至终端设备a，终端设备a在推荐页面中向用户a展示推荐信息a。
82.在一些实施例中，例如用户b被评估并划分到user_level1，用户b使用的终端设备b向服务器发送推荐请求后，服务器根据系统当前运行状态来决策降级策略，降级策略中指示user_level1的降级模式为mode_level
1,1
档位，则推荐系统利用mode_level
1,1
计算出为用户b提供的推荐信息b，服务器将推荐信息b发送至终端设备b，终端设备b在推荐页面中向用户b展示推荐信息b。
83.在一些实施例中，例如用户c被评估并划分到user_level3，用户c使用的终端设备c向服务器发送推荐请求后，服务器根据系统当前运行状态来决策降级策略，降级策略中指示user_level3的降级模式为mode_level
3,4
档位，则推荐系统当前暂停对用户c进行推荐预测，服务器直接将预设的兜底数据发送至终端设备c，终端设备c在推荐页面中向用户c显示接收到的兜底数据。
84.由以上技术方案可知，在满足降级条件时，本技术根据系统当前运行状态和用户等级分类，决策降级策略，从而为每个用户等级适配降级档位，优先保留对高等级用户的无损服务，从最低用户等级起开始按序下调档位，而在解除降级条件后，优先恢复高等级用户的服务能力，从当前有损降级中的最高用户等级起按序上调档位。本技术能实现差异化弹性降级及其恢复方式，在系统超负荷运行时无需限制某些用户的访问请求，并且用户侧对服务降级和档位切换基本无感知，保证用户应用体验，并且有利于应用平台对高价值用户的维系，从而发挥和挖掘用户价值。此外，降级策略可以随系统运行状态进行动态自适应更新，提升了推荐系统的降级动态响应能力。
85.在一些实施例中，如图13所示，服务器100至少包括控制器101和通信器102，控制器101被配置为执行包含前述降级调试和降级恢复机制的推荐方法；通信器102用于实现服务器100与终端设备200之间的通信交互，所述通信交互不限于接收终端设备200的推荐请求，以及向终端设备200发送由推荐系统预测输出的推荐信息等。服务器100的结构不限于本实施例，当然服务器100也可实现其他业务。
86.在一些实施例中，如图14所示，服务器100包括推荐引擎100a、采集模块100b、存储模块100c、预估模块100d，其中推荐引擎100a包括决策模块100a-1和推荐模型100a-2。图14中涉及的引擎和功能模块均可受控于控制器101。
87.在一些实施例中，用户通过访问推荐引擎，可执行推荐服务中的相关业务。采集模块100b用于采集推荐引擎100a上报的系统运行状态，系统运行状态涉及的状态指标不限于包括cpu利用率、系统可用内存/内存消耗、rt(tp999)、每个历史时间点的系统流量、各降级档位的执行次数、每种降级档位每次执行时的cpu时间和内存占用等，cpu时间用于表征cpu全速工作时完成任务进程所消耗的时间。采集模块100b将采集到的状态指标数据保存在存储模块100c中，以及将如cpu利用率、系统可用内存/内存消耗、rt等指标发送至决策模块100a-1。
88.在一些实施例中，预估模块100d包括三个子模块，分别为用户等级预估子模块100d-1、档位算力预估子模块100d-2、系统算力上限预估子模块100d-3。其中，用户等级预估子模块100d-1中配置有用户价值分类模型(例如rfm模型)，并基于用户价值分类模型划分的用户价值，对用户等级进行分类。
89.在一些实施例中，档位算力预估子模块100d-2用于从存储模块100c中读取所需的状态指标数据，例如读取每个降级档位mode_level
i,j
的历史执行次数、cpu每次执行mode_level
i,j
所消耗的算力，算力的衡量维度包括cpu时间和内存占用，由此计算每个降级档位mode_level
i,j
执行一次平均需要的算力，从而得到每个降级档位mode_level
i,j
对应的档位算力，档位算力表示为computing_power
i,j
。档位算力不是固定的，而是可以随推荐引擎100a不断上报的状态指标数据而动态更新，从而保证档位算力的精准性。
90.在一些实施例中，系统算力上限预估子模块100d-3用于从存储模块100c中读取所需的状态指标数据，例如查询过去一定时间段(例如一周、半个月)内具有最大系统流量且cpu能够保持稳定运行的高峰期时间片(例如15分钟)，并统计高峰期时间片内消耗的总cpu时间和内存，作为系统算力上限，系统算力上限表示为computing_power
t
。系统算力上限也不是固定的，而是可以随推荐引擎100a不断上报的状态指标数据而动态更新，从而保证系统算力上限的精准性。
91.在一些实施例中，在用户等级预估子模块100d-1对用户等级分类后，可在决策模块100a-1中制定各用户等级对应的降级模式组合。决策模块100a-1接收采集模块100b发送的如cpu利用率、系统可用内存/内存消耗、rt等指标，用于监控是否满足降级条件，若监控到满足降级条件时，则启动服务降级机制，决策降级策略，并将降级策略发送给推荐模型100a-2，推荐模型100a-2根据降级策略指示的各用户等级所应触发的降级档位，进行推荐预测和运算，进而给出推荐结果；若监控到未满足降级条件，则决策模块100a-1向推荐模型100a-2发送非降级指示信息，推荐模型100a-2响应于非降级指示信息，不进行服务降级，保持执行正常推荐策略并反馈推荐结果。
92.在一些实施例中，在降级调试和降级恢复时，都涉及检测当前系统负荷是否小于或等于系统负荷上限，参照图5，查询每个用户等级内当前具有的在线用户数量为ri′
，1≤i≤n，根据每个用户等级当前所选的降级模式占用的档位算力，计算当前所需总算力，即有computing_powerz表示当前所需总算力，表示在降级调试/降级恢复时第i个用户等级当前所选的降级模式的档位算力，ki表示在降级调试/降级恢复时第i个用户等级当前所选的降级模式的档位序号，1≤ki≤mi，mi表示第i个降级模式组合内包括的降级模式总数，ki是变量，ki会随降级调试/降级恢复时的调档动作而动态变化。若computing_powerz≤computing_power
t
(系统算力上限)，即检测到当前系统负荷≤系统负荷上限；若computing_powerz＞computing_power
t
，即检测到当前系统负荷超过系统负荷上限。
93.在一些实施例中，基于图14示例的服务器结构配置，图15示例终端与服务器之间的推荐交互处理逻辑，涉及服务器端的离线处理逻辑以及服务器与终端设备之间的在线处理逻辑。
94.在一些实施例中，参照图15，服务器端的离线处理逻辑包括：采集模块100b采集系
统运行的状态指标数据，并将状态指标数据写入存储模块100c；预估模块100d进行用户等级分类，可选地，将用户等级写入redis(remote dictionary server，远程字典服务，相当于一种数据库)；决策模块100a-1可从redis中获取用户等级的类别，并制定每个用户等级对应的降级模式组合；预估模块100d从存储模块100c中读取数据，基于历史高峰期时间片内消耗的总cpu时间和内存，预估系统算力上限，以及，根据每个降级档位被执行的次数以及每次执行消耗的cpu时间和内存，预估每个降级档位的档位算力，可选地，将系统算力上限和每个降级档位的档位算力写入redis，则前期准备工作已完成。
95.在一些实施例中，参照图15，服务器与终端设备之间的在线处理逻辑包括：各终端设备200向决策模块100a-1发送推荐请求，决策模块100a-1响应于推荐请求，从采集模块100b获取如rt、cpu利用率、系统内存占用等系统运行状态，并判断是否满足降级条件，若满足降级条件，则执行降级处理逻辑；若不满足降级条件，则执行非降级处理逻辑。
96.在一些实施例中，参照图15，非降级处理逻辑被配置为：决策模块100a-1向推荐模型100a-2发送非降级指示信息；推荐模型100a-2响应于非降级指示信息，执行正常推荐策略，并向终端设备200返回推荐结果，终端设备200将推荐结果展示给当前终端用户。
97.在一些实施例中，参照图15，降级处理逻辑被配置为：决策模块100a-1从redis获取系统算力上限、每个降级档位的档位算力、以及每个用户等级内当前具有的在线用户数量为ri′
；然后决策模块100a-1按照用户等级从低到高的优先级顺序，进行档位降级调试，直至最终匹配出降级策略；决策模块100a-1根据当前终端用户的用户信息，向redis查询当前终端用户所属的用户等级；决策模块100a-1将当前终端用户所属的用户等级对应的降级档位通知到推荐模型100a-2；推荐模型100a-2根据被通知的降级档位进行召回和排序，并将输出的推荐结果返回给终端设备200，终端设备200将推荐结果展示给当前终端用户。
98.在一些实施例中，降级处理逻辑可细，在解除分为前述在触发降级时执行的降级调试流程，以匹配最佳的降级策略，以及触发条件后的降级恢复流程。参照图15，所述降级恢复流程包括：决策模块100a-1按照有损降级中用户等级从高到低的优先级顺序，进行档位上调并按序恢复，直至达到系统算力上限或充分恢复为止，在此期间，降级策略会发生动态更新，决策模块100a-1需要将降级策略的恢复变化同步至推荐模型100a-2，推荐模型100a-2同步上调、切换相应的用户等级的档位，并根据更新的降级模式档位进行运算并返回推荐结果。
99.在一些实施例中，参照图16，本技术还提供一种由服务器端执行的推荐方法，所述方法包括如下程序步骤：
100.步骤s161，监控是否满足降级条件。若监控到满足降级条件，则执行步骤s162；反之，若不满足降级条件，则则执行步骤s165。
101.步骤s162，查询当前在线用户的用户等级以及为不同用户等级预设的降级模式组合。所述降级模式组合内排序有多种档位的降级模式。
102.步骤s163，确定与服务器当前运行状态匹配的降级策略。所述降级策略指示每个用户等级对应的降级模式的档位。
103.步骤s164，在执行降级策略后，向每个在线用户的终端设备发送对应的推荐信息。
104.步骤s165，执行正常推荐策略，并向每个在线用户的终端设备发送对应的推荐信息。其中，所述正常推荐策略是指每个用户等级对应的降级模式为各自组合内的最高档位。
105.所述方法还可包括服务器端执行的离线处理逻辑，以及在线处理逻辑中确定降级策略的具体降级调试方案，以及降级恢复方案等，这些内容已在前述各项实施例中作出了清楚描述，具体请参照前述各实施例，此处不再赘述。
106.本技术主要侧重服务器端的处理逻辑，而终端设备只需支持推荐功能，能够与服务器通信连接，并显示服务器推送的推荐信息即可，本技术对终端设备的类别、软硬件配置不作其他限定。服务器的软硬件架构和配置不限于本技术实施例的示例。在本技术降级规则的基础上，可以对降级策略匹配、降级恢复、离线处理逻辑的配置、以及推荐系统中其他的处理环节进行变型和扩展，从而得到适应更多场景的、可行的推荐和降级方案。另外，本技术中涉及的用户等级、降级模式组合、档位等标识仅仅是示例性的表达，不构成对本发明的限定。
107.在一些实施例中，本发明还提供一种计算机存储介质，该计算机存储介质可存储有程序。当计算机存储介质位于服务器100中时，该程序执行时可包括控制器101被配置执行的推荐方法、降级调试和降级恢复机制等所涉及的程序步骤。其中，计算机存储介质可为磁碟、光盘、只读存储记忆体(英文：read-only memory，简称rom)或随机存储记忆体(英文：random access memory，简称ram)等。
108.最后应说明的是：以上各实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述各实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的范围。
109.为了方便解释，已经结合具体的实施方式进行了上述说明。但是，上述示例性的讨论不是意图穷尽或者将实施方式限定到上述公开的具体形式。根据上述的教导，可以得到多种修改和变形。上述实施方式的选择和描述是为了更好的解释本公开的内容，从而使得本领域技术人员更好的使用所述实施方式。