消息处理方法、装置、电子设备以及存储介质与流程

1.本公开涉及人工智能技术领域，尤其涉及智能办公、即时通讯技术领域。具体地，涉及一种消息处理方法、装置、电子设备、存储介质以及程序产品。


背景技术：

2.消息推送，是指运营人员通过运营平台或第三方工具对用户对应的客户端进行的主动消息推送。通过消息推送，用户可以在客户端通知栏或者状态栏看到消息通知，唤起用户针对推送的消息进行后续操作。随着消息推送的技术越来越成熟，消息推送所带来的问题也不容忽视。例如，消息推送频繁，给用户带来消息干扰；或者没有满足用户的个性化需求，导致用户对推送的消息不感兴趣等。


技术实现要素：

3.本公开提供了一种消息处理方法、装置、电子设备、存储介质以及程序产品。
4.根据本公开的一方面，提供了一种消息处理方法，包括：响应于检测到消息提醒指令，确定候选提醒对象，其中，上述候选提醒对象是可用资源数值小于或等于第一预定阈值的对象；在根据预定提醒策略确定上述候选提醒对象是目标提醒对象的情况下，根据上述可用资源数值，生成与上述目标提醒对象对应的交互消息，其中，上述预定提醒策略用于确定上述候选提醒对象是否是上述目标提醒对象；以及在预定提醒时段，向与上述目标提醒对象对应的客户端发送上述交互消息，以便上述客户端显示上述交互消息。
5.根据本公开的另一方面，提供了一种消息处理装置，包括：响应模块，用于响应于检测到消息提醒指令，确定候选提醒对象，其中，上述候选提醒对象是可用资源数值小于或等于第一预定阈值的对象；生成模块，用于在根据预定提醒策略确定上述候选提醒对象是目标提醒对象的情况下，根据上述可用资源数值，生成与上述目标提醒对象对应的交互消息，其中，上述预定提醒策略用于确定上述候选提醒对象是否是上述目标提醒对象；以及发送模块，用于在预定提醒时段，向与上述目标提醒对象对应的客户端发送上述交互消息，以便上述客户端显示上述交互消息。
6.根据本公开的另一方面，提供了一种电子设备，包括：至少一个处理器；以及与上述至少一个处理器通信连接的存储器；其中，上述存储器存储有可被上述至少一个处理器执行的指令，上述指令被上述至少一个处理器执行，以使上述至少一个处理器能够执行如上上述的方法。
7.根据本公开的另一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，上述计算机指令用于使上述计算机执行如上上述的方法。
8.根据本公开的另一方面，提供了一种计算机程序产品，包括计算机程序，上述计算机程序在被处理器执行时实现如上上述的方法。
9.应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
10.附图用于更好地理解本方案，不构成对本公开的限定。其中：
11.图1示意性示出了根据本公开实施例的可以应用消息处理方法及装置的示例性系统架构；
12.图2示意性示出了根据本公开实施例的消息处理方法的流程图；
13.图3示意性示出了根据本公开另一实施例的确定目标提醒对象的流程图；
14.图4示意性示出了根据本公开实施例的交互消息卡片示意图；
15.图5示意性示出了根据本公开实施例的消息处理装置的框图；以及
16.图6示意性示出了根据本公开实施例的适于实现消息处理方法的电子设备的框图。
具体实施方式
17.以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
18.图1示意性示出了根据本公开实施例的可以应用消息处理方法及装置的示例性系统架构。
19.需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。例如，在另一实施例中，可以应用消息处理方法及装置的示例性系统架构可以包括客户端，但客户端可以无需与服务器进行交互，即可实现本公开实施例提供的消息处理方法及装置。
20.如图1所示，根据该实施例的系统架构100可以包括客户端101、第三方服务器102和服务器103。网络用以在客户端101和服务器103之间、客户端101和第三方服务器102之间、第三方服务器102和服务器103之间提供通信链路的介质。网络可以包括各种连接类型，例如有线和/或无线通信链路等等。
21.用户可以使用客户端101通过网络与服务器103交互，以接收或发送交互消息等。客户端101上可以安装有各种通讯客户端应用，例如知识阅读类应用、网页浏览器应用、搜索类应用、即时通信(instant messaging，im)工具、办公类软件、邮箱客户端和/或社交平台软件等(仅为示例)。
22.客户端101可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。
23.第三方服务器102可以是为第三方公司提供服务的服务器，第三方公司可以是提供储值卡的供应商。可以利用第三方服务器102对处于生命周期内的储值卡提供管理、记录等服务。例如，可以实时监控储值卡的可用资源数值、补充记录、消耗记录等。
24.第三方服务器102可以定时向服务器103发送关于储值卡的相关信息，也可以向服务器103提供查询接口，以通过查询接口与服务器103进行通信连接。
25.查询接口可以包括单卡查询接口1021、批量查询接口1022和分页查询接口1023中
的至少一项。单卡查询接口1021可以包括查询一个储值卡的查询接口。批量查询接口1022可以包括一次性查询全部储值卡的查询接口。分页查询接口1023可以包括分页查询一批储值卡的查询接口。可以利用查询接口将用于执行消息处理方法的服务器103与第三方服务器102通信连接，基于储值卡的标识信息例如卡号，获取储值卡的可用资源数值。
26.服务器103可以是提供各种服务的服务器，例如以向用户的客户端101发送交互消息的方式，对用户所持有的储值卡进行可用资源数值的余额提醒。
27.服务器103可以包括提醒模块1031和补充模块1032。可以利用提醒模块1031获取来自第三方服务器102的可用资源数值。并基于可用资源数值，向目标提醒对象对应的客户端101发送交互消息。可以利用补充模块1032响应于接收到来自客户端101的目标提醒对象的交互操作，根据交互操作更新交互消息。
28.本公开实施例所提供的消息处理方法一般也可以由服务器103执行。相应地，本公开实施例所提供的消息处理装置一般可以设置于服务器103中。本公开实施例所提供的消息处理方法也可以由不同于服务器103且能够与客户端101和/或服务器103通信的服务器或服务器集群执行。相应地，本公开实施例所提供的消息处理装置也可以设置于不同于服务器103且能够与客户端101和/或服务器103通信的服务器或服务器集群中。
29.例如，服务器103响应于检测到消息提醒指令，通过第三方服务器102确定对象的可用资源数值。基于可用资源数值，确定候选提醒对象。在根据预定提醒策略确定候选提醒对象是目标提醒对象的情况下，根据可用资源数值，生成与目标提醒对象对应的交互消息。在预定提醒时段，向与目标提醒对象对应的客户端101发送交互消息，以便客户端101显示交互消息。
30.应该理解，图1中的客户端、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的客户端、网络和服务器。
31.应注意，以下方法中各个操作的序号仅作为该操作的表示以便描述，而不应被看作表示该各个操作的执行顺序。除非明确指出，否则该方法不需要完全按照所示顺序来执行。
32.图2示意性示出了根据本公开实施例的消息处理方法的流程图。
33.如图2所示，该方法200包括操作s210～s230。
34.在操作s210，响应于检测到消息提醒指令，确定候选提醒对象。候选提醒对象是可用资源数值小于或等于第一预定阈值的对象。
35.在操作s220，在根据预定提醒策略确定候选提醒对象是目标提醒对象的情况下，根据可用资源数值，生成与目标提醒对象对应的交互消息。预定提醒策略用于确定候选提醒对象是否是目标提醒对象。
36.在操作s230，在预定提醒时段，向与目标提醒对象对应的客户端发送交互消息，以便客户端显示交互消息。
37.根据本公开的实施例，消息提醒指令可以是针对储值卡的消息提醒指令。储值卡可以指具有可补充、可消耗功能的卡片。例如电影卡、饭卡、游戏卡等。该消息提醒指令按照触发来源划分，可以包括服务器自动触发的消息提醒指令，也可以包括基于客户端的消息提醒请求而触发的消息提醒指令。消息提醒指令按照生成时间划分，可以是按照预定时间间隔生成的消息提醒指令，也可以是随机生成的消息提醒指令。
38.根据本公开的另一实施例，还可以基于储值卡内的可用资源数值来生成消息提醒指令。例如，实时监测每个储值卡的可用资源数值，在确定任一储值卡的可用资源数值小于或等于第一预定阈值的情况下，生成消息提醒指令。
39.根据本公开的实施例，候选提醒对象可以是持有储值卡、且储值卡内存储的可用资源数值小于或等于第一预定阈值的用户。可以基于储值卡的标识与用户标识之间的映射关系，确定储值卡的可用资源数值小于或等于第一预定阈值的候选提醒对象。
40.根据本公开的实施例，可用资源数值可以指可以进行交易兑换或者消耗的资源的价值量。例如，储值卡为饭卡，可用资源数值可以表征可以兑换为食物的数量。例如，储值卡为电影卡，可用资源数值可以表征可以购买电影票的数量。可用资源数值越多，则表明其价值越大，可用资源数值越小，则表明其价值越小。可以根据实际情况预先设置第一预定阈值，利用第一预定阈值来衡量储值卡中可用资源数值的价值大小。在可用资源数值小于或等于第一预定阈值的情况下，确定储值卡余额不足，在利用储值卡中的可用资源数值进行交易兑换或者消耗时，可能存在交易兑换操作失败的问题。
41.以储值卡为饭卡为例，在储值卡内可用资源数值较小的情况下，进行刷卡购买食物时很容易遇到可用资源数值不足的问题，进而容易由储值卡内余额不足导致用餐队伍阻塞或者需要在补充处排很长队进行补充的问题。
42.根据本公开的实施例，可以根据预定提醒策略，对候选提醒对象进行筛选，确定候选提醒对象是否是目标提醒对象。目标提醒对象可以指：在储值卡的使用频率高于预定频率阈值，且可用资源数值小于或等于第一预定阈值的用户。在确定候选提醒对象是目标提醒对象的情况下，在预定提醒时段，向与目标提醒对象对应的客户端发送交互消息。该交互消息可以用于表征可用资源数值小于或等于第一预定阈值，或者“可用资源数值较小，将影响使用”等语义的消息。以便客户端向目标提醒对象及时显示交互消息，提醒目标提醒对象及时补充。
43.根据本公开的实施例，利用预定提醒策略，可以将可用资源数值较小例如小于或等于第一预定阈值、且活跃度较高例如频繁使用储值卡的目标提醒对象确定出来，避免将可用资源数值小于或等于第一预定阈值，但是活跃度低例如储值卡的使用频率低于预定频率阈值的对象误确定为目标提醒对象，对一些储值卡的使用频率较低的对象发送交互消息，进而造成消息打扰。
44.根据本公开的实施例，预定提醒时段可以是预先设定的提醒时段，以储值卡为饭卡为例，预定提醒时段可以是午饭时间的前一时段，或者晚饭时间的前一时段。在预定提醒时段，向与目标提醒对象对应的客户端发送交互消息，能够根据实际情况，在保证对目标提醒对象不造成工作、学习、生活的影响的同时，起到及时提醒的作用。
45.利用本公开实施例提供的消息处理方法，能够利用交互消息对目标提醒对象进行可用资源数值的及时提醒，避免用户在进行交易兑换的过程中发生交易失败的问题，提高用户的便捷性和体验感。
46.根据本公开的实施例，针对如图2所示的操作s210，响应于检测到消息提醒指令，确定候选提醒对象，可以包括如下操作。
47.例如，响应于检测到消息提醒指令，确定储值卡的可用资源数值。在确定可用资源数值小于或等于第一预定阈值的情况下，确定持储值卡的用户为候选提醒对象。
48.根据本公开的实施例，确定储值卡的可用资源数值可以包括推获取方式。例如，接收来自第三方服务器发送的关于储值卡的可用资源数值。但是并不局限于此，还可以包括拉获取方式。例如，利用第三方服务器提供的查询接口，通过查询接口，获取关于储值卡的可用资源数值。
49.根据本公开的实施例，查询接口包括单卡查询接口、批量查询接口和分页查询接口中的至少一项。单卡查询接口可以包括查询一个储值卡的查询接口。批量查询接口可以包括一次性查询全部储值卡的查询接口。分页查询接口可以包括分页查询一批储值卡的查询接口。可以利用查询接口将用于执行消息处理方法的服务器与第三方服务器通信连接，基于储值卡的标识信息例如卡号，获取储值卡的可用资源数值。
50.根据本公开的实施例，利用推获取方式，能够同步到多个服务器中，进而满足获取的可用资源数值的实时性。利用拉获取方式，能够满足获取可用资源数值的方式的多样性。
51.根据本公开的另一实施例，在确定用户的可用资源数值小于或等于第一预定阈值的情况下，可以将该用户作为候选提醒对象。并直接将候选提醒对象作为目标提醒对象。根据可用资源数值，生成与目标提醒对象对应的交互消息。在预定时段，向与目标提醒对象对应的客户端发送交互消息。
52.根据本公开的实施例，与直接将候选提醒对象作为目标提醒对象相比，根据预定提醒策略确定候选提醒对象是目标提醒对象，能够将活跃度低的候选提醒对象排除，实现精准提醒。
53.以储值卡为饭卡为例，持储值卡的用户从来不在对应餐厅吃饭，自己带餐或者点外卖。该类持储值卡的用户活跃度低。利用第一预定阈值与可用资源数值进行比对，该类用户的储值卡中的可用资源数值一直小于第一预定阈值。直接将该类对象作为目标提醒对象，向目标提醒对象对应的客户端发送交互消息，将对该类持储值卡的用户造成打扰。还例如，针对活跃度高的持储值卡的用户，在例如非工作日时间例如周末、节假日期间，或者出差期间，也不会在餐厅进餐。所以在此情况下，即使储值卡中的可用资源数值一直小于第一预定阈值，该类用户也不需要作为目标提醒对象。
54.根据本公开的实施例，可以利用预定提醒策略，将上述情况的候选提醒对象进行排除，将剩余候选提醒对象作为目标提醒对象，以简化交互消息的发送量的同时，避免对非必要用户造成消息打扰。
55.下述将对预定提醒策略进行详细阐述。
56.根据本公开的另一实施例，针对如图2所示的操作s220，在根据预定提醒策略确定候选提醒对象是目标提醒对象的情况下，根据可用资源数值，生成与目标提醒对象对应的交互消息，可以包括如下操作。
57.例如，根据预定提醒策略，确定匹配条件。将满足匹配条件的候选提醒对象确定为目标提醒对象。根据可用资源数值，生成与目标提醒对象对应的交互消息。
58.根据本公开的实施例，匹配条件包括以下至少之一：查询时刻匹配条件、执行成功时刻匹配条件和可用资源数值匹配条件。
59.根据本公开的实施例，查询时刻匹配条件可以包括：实际查询时刻与预期查询时刻之间的匹配条件。例如，实际查询时刻与预期查询时刻之间匹配，则实际查询时刻满足查询时刻匹配条件；实际查询时刻与预期查询时刻之间不匹配，则实际查询时刻不满足查询
时刻匹配条件。实际查询时刻表征第一预定查询任务的实际执行时刻，预期查询时刻表征第一预定查询任务的理论执行时刻。第一预定查询任务表征第一预定轮次的用于查询候选提醒对象的可用资源数值的任务。
60.根据本公开的实施例，实际提醒时刻表征预定提醒任务的实际执行时刻，目标查询时刻表征第二预定查询任务的实际执行时刻，预定提醒任务表征第一预定轮次的用于提醒目标对提醒对象的可用资源数值的任务，第二预定查询任务表征第二预定轮次的用于查询候选提醒对象的可用资源数值的任务，第二预定轮次是第一预定轮次之后的轮次。
61.根据本公开的实施例，消息处理方法可以包括查询任务与提醒任务。查询任务用于查询可用资源数值。提醒任务用于发送交互消息。查询任务的发生时刻要早于同一轮次的提醒任务。
62.以一天需要执行两次消息处理方法的操作为例。第一预定查询任务发生在上午，表征第一预定轮次的用于查询候选提醒对象的可用资源数值的任务。第二预定查询任务发生在下午，表征第二预定轮次的用于查询候选提醒对象的可用资源数值的任务。第一预定查询任务可以为与第二预定查询任务最近一次的理论上已执行的查询任务。例如，预期查询时刻可以为执行第一预定查询任务的理论执行时刻。例如，预期查询时刻为早上10：50。实际查询时刻为执行第一预定查询任务的实际执行时刻。例如，实际查询时刻为10：51。实际提醒时刻表征预定提醒任务的实际执行时刻，例如，实际提醒时刻为11：01。目标查询时刻为执行第二预定查询任务的实际执行时刻，例如为下午4：51。
63.根据本公开的实施例，待比较资源数值可以指历史时刻的可用资源数值。可用资源数值可以指当前时刻的可用资源数值。以第二预定查询任务为例，通过第二预定查询任务所查询得到的为可用资源数值。相对于第一预定查询任务，通过执行第一预定查询任务所查询得到的为待比较资源数值。
64.需要说明的是，实际查询时刻与预期查询时刻之间匹配，可以为实际查询时刻与预期查询时刻相同，但是并不局限于此，还可以为实际查询时刻与预期查询时刻之间的时间间隔小于或等于预定时间间隔阈值。反之，实际查询时刻与预期查询时刻之间的时间间隔大于预定时间间隔阈值，则实际查询时刻与预期查询时刻之间不匹配。
65.根据本公开的实施例，执行成功时刻匹配条件可以包括：实际执行成功时刻与预期执行成功时刻之间的匹配条件。例如，实际执行成功时刻与预期执行成功时刻之间匹配，则实际执行成功时刻满足执行成功时刻匹配条件；实际执行成功时刻与预期执行成功时刻之间不匹配，则实际执行成功时刻不满足执行成功时刻匹配条件。
66.根据本公开的实施例，预期执行成功时刻可以指执行发送交互消息任务的理论执行成功时刻，例如，预期执行成功时刻为11点。实际执行成功时刻为11：05。
67.根据本公开的实施例，实际执行成功时刻与预期执行成功时刻之间匹配的确定方式与实际查询时刻与预期查询时刻之间匹配的确定方式类似，在此不再赘述。
68.根据本公开的实施例，可用资源数值匹配条件可以包括：可用资源数值与待比较资源数值之间的匹配条件。例如，可用资源数值与待比较资源数值之间匹配，则可用资源数值满足可用资源数值匹配条件；可用资源数值与待比较资源数值之间不匹配，则可用资源数值不满足可用资源数值匹配条件。
69.根据本公开的实施例，可用资源数值与待比较资源数值之间匹配，可以理解为：可
用资源数值与待比较资源数值相同。反之，可用资源数值与待比较资源数值之间不匹配，可以理解为：可用资源数值与待比较资源数值不相同。
70.根据本公开的实施例，预定提醒策略可以包括利用查询时刻匹配条件的提醒策略、执行成功时刻匹配条件的提醒策略、可用资源数值匹配条件的提醒策略中的任意一项。但是并不局限于此，预定提醒策略还可以包括利用查询时刻匹配条件的提醒策略、执行成功时刻匹配条件的提醒策略、可用资源数值匹配条件的提醒策略中的任意两项或者三项。
71.例如，根据预定提醒策略，确定匹配条件包括查询时刻匹配条件、执行成功时刻匹配条件和可用资源数值匹配条件。预定提醒策略包括：在确定候选提醒对象的实际查询时刻不满足查询时刻匹配条件的情况下，确定实际执行成功时刻是否满足执行成功时刻匹配条件。在确定候选提醒对象的实际执行成功时刻满足执行成功时刻匹配条件的情况下，确定候选提醒对象为目标提醒对象。在确定候选提醒对象的实际执行成功时刻不满足执行成功时刻匹配条件的情况下，确定可用资源数值是否满足可用资源数值匹配条件。在确定可用资源数值不满足可用资源数值匹配条件的情况下，确定候选提醒对象为目标提醒对象。在确定可用资源数值满足可用资源数值匹配条件的情况下，确定实际提醒时刻与目标查询时刻之间的关系是否满足预定条件。确定可用资源数值与待比较资源数值相匹配且实际提醒时刻与目标查询时刻之间的关系满足预定条件的情况下，确定候选提醒对象是目标提醒对象。
72.根据本公开的实施例，预定提醒策略还包括：在确定候选提醒对象的实际查询时刻满足查询时刻匹配条件的情况下，确定可用资源数值是否满足可用资源数值匹配条件。在确定可用资源数值满足可用资源数值匹配条件的情况下，确定实际提醒时刻与目标查询时刻之间的关系是否满足预定条件。确定可用资源数值与待比较资源数值相匹配且实际提醒时刻与目标查询时刻之间的关系满足预定条件的情况下，确定候选提醒对象是目标提醒对象。确定可用资源数值与待比较资源数值相匹配且实际提醒时刻与目标查询时刻之间的关系不满足预定条件的情况下，停止操作。
73.图3示意性示出了根据本公开另一实施例的确定目标提醒对象的流程图。
74.如图3所示，该方法300包括操作s301～s308。
75.在操作s301，响应于检测到消息提醒指令，确定候选提醒对象。
76.在操作s302，确定实际查询时刻是否与预期查询时刻相匹配。在确定实际查询时刻与预期查询时刻未匹配的情况下，执行操作s303，在确定实际查询时刻与预期查询时刻相匹配的情况下，执行操作s304。
77.根据本公开的实施例，确定实际查询时刻与预期查询时刻未匹配，可以理解为：确定实际查询时刻不满足查询时刻匹配条件。则可以初步确定该查询任务出现服务故障问题或者该候选提醒对象为不活跃用户。
78.在操作s303，确定实际执行成功时刻与预期执行成功时刻是否相匹配。在确定实际执行成功时刻与预期执行成功时刻相匹配的情况下，执行操作s307。在确定实际执行成功时刻与预期执行成功时刻未匹配的情况下，执行操作s304。
79.根据本公开的实施例，实际执行成功时刻与预期执行成功时刻相匹配，可以理解为：确定实际执行成功时刻满足执行成功时刻匹配条件。可以确定查询任务可能是出现服务故障问题，排除候选提醒对象为不活跃用户的可能性。
80.在操作s304，确定可用资源数值与待比较资源数值是否相匹配。在确定可用资源数值与待比较资源数值未匹配的情况下，执行操作s307。在确定可用资源数值与待比较资源数值相匹配的情况下，执行操作s305。
81.根据本公开的实施例，确定可用资源数值与待比较资源数值未匹配，可以理解为：确定可用资源数值不满足可用资源数值匹配条件。则确定候选提醒对象可能对储值卡进行了补充或者消耗等操作。排除了候选提醒对象为不活跃用户的可能性。确定候选提醒对象是目标提醒对象。
82.在操作s305，确定是否存在实际提醒时刻。在确定存在实际提醒时刻的情况下，执行操作s306。在确定不存在实际提醒时刻的情况下，执行操作s308。
83.在操作s306，确定实际提醒时刻与目标查询时刻之间的关系是否满足预定条件。在确定实际提醒时刻与目标查询时刻之间的关系满足预定条件的情况下，执行操作s307。在确定实际提醒时刻与目标查询时刻之间的关系不满足预定条件的情况下，执行操作s308。
84.根据本公开的实施例，实际提醒时刻表征预定提醒任务的实际执行时刻，目标查询时刻表征第二预定查询任务的实际执行时刻，预定提醒任务表征第一预定轮次的用于提醒目标提醒对象的可用资源数值的任务，第二预定查询任务表征第二预定轮次的用于查询候选提醒对象的可用资源数值的任务，第二预定轮次是第一预定轮次之后的轮次。
85.根据本公开的实施例，实际提醒时刻与目标查询时刻之间的关系可以包括：实际提醒时刻所对应的预定提醒任务为目标查询时刻所对应的预定查询任务的前一个轮次的任务或者实际提醒时刻所对应的预定提醒任务为目标查询时刻所对应的预定查询任务的前多个轮次的任务。
86.例如，实际提醒时刻为昨天下午5点。实际提醒时刻所对应的预定提醒任务为昨天的第二个提醒任务。目标查询时刻为今天上午10：51。目标查询时刻所对应的预定查询任务为今天的第一个查询任务。两者之间为相邻轮次。则确定实际提醒时刻所对应的预定提醒任务为目标查询时刻所对应的预定查询任务的前一个轮次的任务。
87.在确定实际提醒时刻所对应的预定提醒任务为目标查询时刻所对应的预定查询任务的前一个轮次的任务的情况下，确定实际提醒时刻与目标查询时刻之间的关系满足预定条件。
88.根据本公开的实施例，记录最近一次提醒任务成功运行的时刻，本次查询任务执行时，对比理论上的上一次提醒任务时刻与本次查询任务时刻之间的关系，避免将不活跃的用户误判为活跃用户。
89.在操作s307，确定候选提醒对象是目标提醒对象。
90.在操作s308，确定候选提醒对象不是目标提醒对象。
91.根据本公开的实施例，利用预定提醒策略，避免了由于服务故障问题导致将不活跃用户确定为具有补充操作或消耗操作的活跃用户，进而向其发送交互消息以打扰到不活跃用户，提高了使用体验。
92.根据本公开的实施例，在如图3所示的操作s301和操作s302之间，还可以执行如下操作。例如，确定候选提醒对象的储值卡是否存在业务记录。在确定不存在业务记录的情况下，执行操作s307；在确定存在业务记录的情况下，执行操作s302。
93.根据本公开的实施例，业务记录可以以日志的形式存储于数据库中。业务记录可以包括可用资源数值记录、消耗记录、补充记录、向客户端发送交互消息的记录中的一项或多项。
94.根据本公开的实施例，如果该储值卡不存在业务记录，可以说明该储值卡为新办理的储值卡。可以对新办理的储值卡，在可用资源数值低于或等于第一预定阈值的情况下，确定持该储值卡的候选提醒对象为目标提醒对象。
95.根据本公开的实施例，在执行如图2所示的操作s230，在预定提醒时段，向与所述目标提醒对象对应的客户端发送交互消息之后，消息处理方法还可以包括操作：更新与目标提醒对象对应的实际执行成功时刻。
96.根据本公开的实施例，更新与目标提醒对象对应的实际执行成功时刻可以包括：将最新的实际执行成功时刻替换历史的实际执行成功时刻。只要保证实际执行成功时刻为最新的时刻即可，在此不做限定。
97.根据本公开的实施例，更新与目标提醒对象对应的实际执行成功时刻，可保证实际执行成功时刻的实时性，进而有利于辅助预定提醒策略，提高从候选提醒对象中确定目标提醒对象的准确性。
98.根据本公开的实施例，在如图2所示的操作s230，在预定提醒时段，向与目标提醒对象对应的客户端发送交互消息之后，消息处理方法还可以包括操作：接收关于交互消息的反馈信息。基于反馈信息，确定交互消息是否发送成功。
99.根据本公开的实施例，在确定未成功向与目标提醒对象对应的客户端发送交互消息的情况下，在确定与实际执行失败时刻之间的时间差值达到第二预定阈值的情况下，重新向与目标提醒对象对应的客户端发送交互消息。
100.根据本公开的实施例，可能由于网络抖动、下游服务故障或者请求超时等原因而导致未成功向与目标提醒对象对应的客户端发送交互消息。
101.根据本公开的实施例，在确定未成功向与目标提醒对象对应的客户端发送交互消息的情况下，记录实际执行失败时刻。并记录当前时刻与实际执行失败时刻之间的时间差值。在确定与实际执行失败时刻之间的时间差值达到第二预定阈值的情况下，重新向与目标提醒对象对应的客户端发送交互消息。
102.根据本公开的实施例，利用反馈信息，可以确定交互消息是否发送成功，再确定未成功向与目标提醒对象对应的客户端发送交互消息的情况下，重新向目标提醒对象对应的客户端发送交互消息。可以利用多次发送以保证交互消息发送成功。
103.根据本公开的实施例，可以利用第二预定阈值，控制相邻两次交互信息之间的发送时间间隔。在保证交互消息成功发送的同时，控制交互消息的发送频率，避免多次频繁地执行发送交互消息的操作。
104.根据本公开的实施例，可以将实际执行失败的交互消息作为发送失败的任务，将发送失败的任务提交到延迟任务池中，在确定与实际执行失败时刻之间的时间差值达到第二预定阈值后，重新执行发送任务，例如，重新向与目标提醒对象对应的客户端发送交互消息，并且配置相应的任务日志。
105.根据本公开的实施例，在确定与实际执行失败时刻之间的时间差值达到第二预定阈值的情况下，重新向与目标提醒对象对应的客户端发送交互消息，还可以包括如下操作。
106.例如，记录发送交互消息的执行失败次数。在确定执行失败次数小于或等于第三预定阈值的情况下，在确定与实际执行失败时刻之间的时间差值达到第二预定阈值的情况下，重新向与目标提醒对象对应的客户端发送交互消息。在确定执行失败次数大于第三预定阈值的情况下，停止向与目标提醒对象对应的客户端发送交互消息。
107.根据本公开的实施例，利用第三预定阈值，可以在利用多次重新发送交互消息也无法实现成功发送交互消息的情况下，避免仍继续发送交互消息而造成资源浪费的问题。
108.根据本公开的实施例，交互消息可以包括用于显示可用资源数值的文字、图片、链接等不具有交互能力的信息。但是并不局限于此，交互消息还可以包括交互控件。交互控件可以是用于体现对象交互指令的控件。交互控件包括按钮、输入框、选择框等中的一种或多种。
109.根据本公开的实施例，对象可以利用交互控件来自动进行历史记录查询、可用资源数值查询以及补充等交互操作。该交互消息可以是一种动态的交互消息卡片，可以根据对象交互指令，产生相应的消息的更新。
110.图4示意性示出了根据本公开实施例的交互消息卡片示意图。
111.如图4所示，交互消息可以以交互消息卡片400的形式展示。交互信息除包括例如用于表示可用资源数值“您的可用资源数值：
××”
的文字外，还可以包括补充控件。补充控件可以包括补充数值选择框401，还可以包括补充确认框402。
112.根据本公开的实施例，交互消息不仅包括文字或者图片类型的消息，还包括交互控件，在显示可用资源数值的同时，提供补充服务，避免目标提醒对象在获悉余额不足、且欲补充的情况下，还需要进行返回操作、登录补充界面的操作等，由此提高了用户的便捷性。
113.根据本公开的实施例，在操作s230在预定提醒时段，向与目标提醒对象对应的客户端发送交互消息之后，消息处理方法还可以包括操作：响应于接收到来自客户端的目标提醒对象的交互操作，根据交互操作更新交互消息。
114.根据本公开的实施例，目标提醒对象利用客户端在看到交互消息后，可以利用交互消息中的交互控件进行交互操作，例如补充的交互操作。服务器可以响应于接收到来自客户端的目标提醒对象的交互操作，根据交互操作更新交互消息。例如，更新交互消息中的可用资源数值。
115.根据本公开的实施例，响应于接收到来自客户的目标提醒对象的交互操作来更新交互消息，能够使得目标提醒对象的可用资源数值实时更新，进而使得可用资源的实时性以及安全性得到保证。
116.根据本公开的实施例，在如图2所示的操作s230后，消息处理方法还可以包括如下操作：在确定目标提醒对象是预定灰度测试对象的情况下，将目标提醒对象添加至灰度测试对象集。灰度测试对象集是用于进行灰度测试的对象集。
117.根据本公开的实施例，灰度测试可以指预定版本的应用程序在上线前，进行的小流量验证测试。预定版本的应用程序可以指用于处理本公开实施例的消息处理方法的升级版本的应用程序。可以通过灰度测试来确定预定版本的应用程序提供的业务服务的效果。
118.根据本公开的实施例，可以预先设置对象筛选规则。基于对象筛选规则确定目标提醒对象是否为预定灰度测试对象。该对象筛选规则可以包括：活跃度规则、可用资源数值
规则等对象属性规则。活跃度规则可以包括：在目标提醒对象的活跃度高于预定活跃度阈值的情况下，确定目标提醒对象是预定灰度测试对象。反之，确定目标提醒对象是非预定灰度测试对象。可用资源数值规则可以包括：在可用资源数值大于预定资源阈值的情况下，确定目标提醒对象是预定灰度测试对象。反之，确定目标提醒对象是非预定灰度测试对象。在确定目标提醒对象是预定灰度测试对象的情况下，将目标提醒对象添加至灰度测试对象集中。按照灰度测试对象集，对灰度测试对象集中的对象进行灰度测试。以便收集来自灰度测试对象集中的对象的反馈，并基于该反馈确定灰度测试效果。
119.根据本公开的实施例，可以从目标提醒对象中确定预定灰度测试对象，进行灰度测试，由此在控制灰度测试集的数据量小，降低处理量的同时，使得灰度测试效果有代表性，提高灰度测试结果的精度。
120.根据本公开的另一实施例，消息处理方法可以应用于服务器群组。服务器群组中包括多个服务器。多个服务器彼此可以同时执行消息处理方法，由此避免因为单服务器出现故障而导致消息处理方法不可执行的问题。为避免多个服务器同时针对同一目标提醒对象执行提醒任务，可以使用分布式锁机制来从多个服务器中确定目标服务器来对该目标提醒对象执行提醒任务。同时在任务内部，为避免在处理某个目标提醒对象的提醒任务时因出现故障而导致整个提醒任务失败的情况，可以将目标提醒对象与目标提醒对象之间的执行逻辑分离。
121.本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。
122.图5示意性示出了根据本公开实施例的消息处理装置的框图。
123.如图5所示，消息处理装置500包括：响应模块510、生成模块520、发送模块530。
124.响应模块510，用于响应于检测到消息提醒指令，确定候选提醒对象。候选提醒对象是可用资源数值小于或等于第一预定阈值的对象。
125.生成模块520，用于在根据预定提醒策略确定候选提醒对象是目标提醒对象的情况下，根据可用资源数值，生成与目标提醒对象对应的交互消息。预定提醒策略用于确定候选提醒对象是否是目标提醒对象。
126.发送模块530，用于在预定提醒时段，向与目标提醒对象对应的客户端发送交互消息，以便客户端显示交互消息。
127.根据本公开的实施例，生成模块包括：第一确定子模块、第二确定子模块以及生成子模块。
128.第一确定子模块，用于根据预定提醒策略，确定匹配条件。匹配条件包括以下至少之一：查询时刻匹配条件、执行成功时刻匹配条件和可用资源数值匹配条件。
129.第二确定子模块，用于将满足匹配条件的候选提醒对象确定为目标提醒对象。
130.生成子模块，用于根据可用资源数值，生成与目标提醒对象对应的交互消息。
131.根据本公开的实施例，在确定实际查询时刻与预期查询时刻未匹配的情况下，第二确定子模块包括：第一确定单元以及第二确定单元。
132.第一确定单元，用于在确定实际执行成功时刻与预期执行成功时刻相匹配的情况下，确定候选提醒对象是目标提醒对象。
133.第二确定单元，用于在确定实际执行成功时刻与预期执行成功时刻未匹配的情况
下，在确定可用资源数值与待比较资源数值未匹配的情况下，确定候选提醒对象是目标提醒对象，
134.根据本公开的实施例，实际查询时刻表征第一预定查询任务的实际执行时刻，预期查询时刻表征第一预定查询任务的理论执行时刻，第一预定查询任务表征第一预定轮次的用于查询候选提醒对象的可用资源数值的任务。
135.根据本公开的实施例，在确定实际查询时刻与预期查询时刻相匹配的情况下，消息处理装置还包括：第一确定模块以及第二确定模块。
136.第一确定模块，用于在确定可用资源数值与待比较资源数值未匹配的情况下，确定候选提醒对象是目标提醒对象。
137.第二确定模块，用于在确定可用资源数值与待比较资源数值相匹配且实际提醒时刻与目标查询时刻之间的关系满足预定条件的情况下，确定候选提醒对象是目标提醒对象，
138.根据本公开的实施例，实际提醒时刻表征预定提醒任务的实际执行时刻，目标查询时刻表征第二预定查询任务的实际执行时刻，预定提醒任务表征第一预定轮次的用于提醒目标对提醒对象的可用资源数值的任务，第二预定查询任务表征第二预定轮次的用于查询候选提醒对象的可用资源数值的任务，第二预定轮次是第一预定轮次之后的轮次。
139.根据本公开的实施例，消息处理装置还包括：添加模块。
140.添加模块，用于在确定目标提醒对象是预定灰度测试对象的情况下，将目标提醒对象添加至灰度测试对象集，其中，灰度测试对象集是用于进行灰度测试的对象集。
141.根据本公开的实施例，消息处理装置还包括：第一更新模块。
142.第一更新模块，用于更新与目标提醒对象对应的实际执行成功时刻。
143.根据本公开的实施例，在确定未成功向与目标提醒对象对应的客户端发送交互消息的情况下，消息处理装置还包括：重新发送模块。
144.重新发送模块，用于在确定与实际执行失败时刻之间的时间差值达到第二预定阈值的情况下，重新向与目标提醒对象对应的客户端发送交互消息。
145.根据本公开的实施例，在确定执行失败次数小于或等于第三预定阈值的情况下，重新发送模块包括：重新发送单元。
146.重新发送单元，用于在确定与实际执行失败时刻之间的时间差值达到第二预定阈值的情况下，重新向与目标提醒对象对应的客户端发送交互消息。
147.根据本公开的实施例，消息处理装置还包括：第二更新模块。
148.第二更新模块，用于响应于接收到来自客户端的目标提醒对象的交互操作，根据交互操作更新交互消息。
149.根据本公开的实施例，交互消息包括交互控件。
150.根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。
151.根据本公开的实施例，一种电子设备，包括：至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行如上所述的方法。
152.根据本公开的实施例，一种存储有计算机指令的非瞬时计算机可读存储介质，其
中，计算机指令用于使计算机执行如上所述的方法。
153.根据本公开的实施例，一种计算机程序产品，包括计算机程序，计算机程序在被处理器执行时实现如上所述的方法。
154.图6示意性示出了根据本公开实施例的适于实现消息处理方法的电子设备的框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
155.如图6所示，电子设备600包括计算单元601，其可以根据存储在只读存储器(rom)602中的计算机程序或者从存储单元608加载到随机访问存储器(ram)603中的计算机程序，来执行各种适当的动作和处理。在ram 603中，还可存储电子设备600操作所需的各种程序和数据。计算单元601、rom 602以及ram 603通过总线604彼此相连。输入/输出(i/o)接口605也连接至总线604。
156.电子设备600中的多个部件连接至i/o接口605，包括：输入单元606，例如键盘、鼠标等；输出单元607，例如各种类型的显示器、扬声器等；存储单元608，例如磁盘、光盘等；以及通信单元609，例如网卡、调制解调器、无线通信收发机等。通信单元609允许电子设备600通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
157.计算单元601可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元601的一些示例包括但不限于中央处理单元(cpu)、图形处理单元(gpu)、各种专用的人工智能(ai)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(dsp)、以及任何适当的处理器、控制器、微控制器等。计算单元601执行上文所描述的各个方法和处理，例如消息处理方法。例如，在一些实施例中，消息处理方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元608。在一些实施例中，计算机程序的部分或者全部可以经由rom 602和/或通信单元609而被载入和/或安装到电子设备600上。当计算机程序加载到ram 603并由计算单元601执行时，可以执行上文描述的消息处理方法的一个或多个步骤。备选地，在其他实施例中，计算单元601可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行消息处理方法。
158.本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、复杂可编程逻辑设备(cpld)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
159.用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的
功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
160.在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
161.为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
162.可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(lan)、广域网(wan)和互联网。
163.计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以是分布式系统的服务器，或者是结合了区块链的服务器。
164.应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
165.上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。