CN116911915A - 资源发放方法、装置和电子设备 - Google Patents

Abstract

本申请是关于一种资源发放方法、装置和电子设备。该资源发放方法包括：通过多个第一协程消费消息队列的消息，以执行发放资源任务，并将所述资源发放任务关联信息输入有缓冲的通道，所述消息包括资源发放任务关联信息，所述资源发放任务关联信息来源于资源发放任务数据集；通过第二协程合并处理来自所述有缓冲的通道的多个所述资源发放任务关联信息，得到针对所述资源发放任务数据集的更新数据；如果满足数据更新条件，则基于所述更新数据更新所述资源发放任务数据集。本申请方案能够有效提升资源发放效率。

Description

资源发放方法、装置和电子设备

技术领域

本申请涉及软件开发技术领域，尤其涉及一种资源发放方法、装置和电子设备。

背景技术

相关技术中，可以通过向目标用户发放优惠券等资源，来达到营销目的。

但是，当目标用户数量众多，如向上百万、上千万或更多用户发放资源时，资源发放效率较低，时间成本过高。为了解决上述问题，相关技术可以由用户自己领取优惠券等资源。但用户可能会忘记领，或者不知道可以领券的情况。相关技术可以采用发送通知的方式来引导用户点击领取优惠卷。但是，部分用户不会太关注通知的信息内容，导致这些短信或者通知被至少部分用户忽略掉。相关技术可以编写脚本，在后台任务跑。但是需要在跑脚本之前去找相关人员开发后台任务，不便于实现。

发明内容

为克服相关技术中存在的问题，本申请提供一种资源发放方法、装置和电子设备，本申请的技术方案能够有效提升资源发放效率。

本申请第一方面提供一种资源发放方法，包括：通过多个第一协程消费消息队列的消息，以执行发放资源任务，并将所述资源发放任务关联信息输入有缓冲的通道，所述消息包括资源发放任务关联信息，所述资源发放任务关联信息来源于资源发放任务数据集；通过第二协程合并处理来自所述有缓冲的通道的多个所述资源发放任务关联信息，得到针对所述资源发放任务数据集的更新数据；如果满足数据更新条件，则基于所述更新数据更新所述资源发放任务数据集。

本申请第二方面提供一种资源发放装置，包括：消息消费模块，用于通过多个第一协程消费消息队列的消息，以执行发放资源任务，并将所述资源发放任务关联信息输入有缓冲的通道，所述消息包括资源发放任务关联信息，所述资源发放任务关联信息来源于资源发放任务数据集；信息处理模块，用于通过第二协程合并处理来自所述有缓冲的通道的多个所述资源发放任务关联信息，得到针对所述资源发放任务数据集的更新数据；数据更新模块，用于如果满足数据更新条件，则基于所述更新数据更新所述资源发放任务数据集。

本申请第三方面提供一种资源发放系统，包括：服务器端和客户端。其中，服务器端用于基于如上所示的方法进行资源发放。客户端用于接收并展示由服务器端发放的资源。

本申请第四方面提供一种电子设备，包括：处理器；以及存储器，其上存储有可执行代码，当可执行代码被处理器执行时，使处理器执行如上的方法。

本申请第五方面提供一种非暂时性机器可读存储介质，其上存储有可执行代码，当可执行代码被电子设备的处理器执行时，使处理器执行如上的方法。

本申请第六方面提供一种计算机程序产品，包括可执行代码，当可执行代码被电子设备的处理器执行时，使处理器执行如上的方法。

本申请提供的技术方案可以包括以下有益效果：

本申请实施例提供的资源发放方法、装置和电子设备，通过多个第一协程消费消息队列的消息，实现了同时执行多个任务来读取消息以发放资源，提升了资源发放效率。通过第二协程处理资源发放任务关联信息，得到更新数据，实现了数据库写入缓存功能。这样有效减少为了更新数据库中数据而发生的与数据库之间的交互次数。进而使得发放资源后能够快速更新数据库，以便进行下一次从数据库中读取更新后的资源发放任务关联信息，进行资源发放，提升了资源发放效率。

此外，本申请实施例提供的资源发放方法、装置和电子设备，通过缓冲、汇集的方式得到更新数据，有助于减少高并发带来的数据库锁互斥问题。

此外，本申请实施例提供的资源发放方法、装置和电子设备，通过容器化部署可执行文件，成倍地提升资源发放能力。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

通过结合附图对本申请示例性实施方式进行更详细的描述，本申请的上述以及其它目的、特征和优势将变得更加明显，其中，在本申请示例性实施方式中，相同的参考标号通常代表相同部件。

图1是本申请实施例示出的一种资源发放方法、装置和电子设备的应用场景的示意图；

图2是本申请实施例示出的一种适用于资源发放方法、装置和电子设备的系统架构的示意图；

图3是本申请实施例示出的一种资源发放方法的流程示意图；

图4是本申请实施例示出的协程的示意图；

图5是本申请实施例示出的一种数据流示意图；

图6是本申请实施例示出的另一种资源发放方法的逻辑图；

图7是本申请实施例示出的另一种资源发放方法的流程图；

图8是本申请实施例示出的一种资源发放装置的结构的框图；

图9是本申请实施例示出的一种资源发放系统的结构的框图；

图10是本申请实施例示出的电子设备的结构的框图。

具体实施方式

下面将参照附图更详细地描述本申请的优选实施方式。虽然附图中显示了本申请的优选实施方式，然而应该理解，可以以各种形式实现本申请而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本申请更加透彻和完整，并且能够将本申请的范围完整地传达给本领域的技术人员。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语“第一”、“第二”、“第三”等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

在对本申请的技术方案进行描述之前，先对本申请涉及的本领域的部分技术术语进行说明。

消息队列(Message queue，简称MQ)，是在消息的传输过程中保存消息的容器。

Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。

MySQL是一种关系型数据库管理系统，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。

Golang(简称Go)是Google开发的一种静态强类型、编译型语言。Go语言语法与C相近，但功能上有：内存安全，垃圾回收(GC)，结构形态及并发计算。

JS对象简谱(JavaScript Object Notation，简称JSON)是一种轻量级的数据交换格式。它基于欧洲计算机协会制定的js规范(European Computer ManufacturersAssociation，简称ECMAScript)的一个子集，采用完全独立于编程语言的文本格式来存储和表示数据。简洁和清晰的层次结构使得JSON成为理想的数据交换语言。

容器部署技术在于通过运行容器来实现应用部署，而容器基于镜像运行。容器部署有利于项目的模块化和服务化，服务化则可以自然接入云端。

在应用(app)运营过程中，运营方经常会根据不同活动和促销的业务给用户推送一些优惠券和通知。例如，双11前一天对所有活跃用户或平时t+7未活跃的用户发送资源(如优惠券)和通知，给予用户下单优惠。但是，这批用户的数量可能非常庞大，如上百万、上千万或者更多。要给每个用户发券验证，可能需要很长时间，如几个小时甚至几天的时间。如果未能及时在用户下单前发放资源，会给用户造成非常不好的体验。

以双十一促销活动期间为例，计划在双十一期间的前两天预热阶段给用户发放优惠券，以给用户提供优惠活动。但是，面对这几千万的用户，一个一个用户去发，人工发放需要发很多天。为了解决该问题，相关技术中也可以改由用户自己领取的方式，但用户可能会忘记领，或者不知道可以领券的情况。为了解决上述问题，相关技术可以采用发送通知的方式来间接发放资源。例如，通过给用户发短信或者发通知的形式，引导用户点击领取优惠卷。但是，根据反馈结果来看，大部分用户不会太关注通知的信息内容，导致这些短信或者通知被至少部分用户忽略掉。能够点击通知去领取优惠券的用户更少，这是由于将负担和责任转移到了用户侧，降低了用户体验。此外，这种方式会使得商家端(b端)损失了用户一定的购买意向，上述问题仍然没能很好地解决。

随着市场对优惠券等促销手段需求的不断增加，相关技术开始用文本预处理器(Hypertext Preprocessor，简称php)语言写脚本，在后台任务跑。这种方式虽然释放了一定的人工成本，但是还是需要在跑脚本之前去找相关人员开发后台任务，不便于实现。

以商家发放优惠券的场景为例进行示例性说明。

相关技术中，相关人员可以按照条件找数据人员圈选一定的用户，然后让研发同学开发后台任务以实现发放优惠券，或发送通知进行引导，让用户到指定页面进行领取。

如果需要向几千万用户发放优惠券，或者，需要在某个特定时刻开始发放优惠券，由于查询数据库和数据库写入需要时间，通过脚本任务发放优惠券，就会暴露效率问题。例如，后台每发放一个优惠券需要30毫秒的时间，如果要发1000万的用户需要发4天的时间，不能按照营销需求及时向大部分用户发放优惠券。

以发放红包的场景为例，相关技术还可以通过开启多进程发放红包。由于每发放一个红包需要将红包的数量减1，防止超发，超出活动预算。在处理库存更新的时候，多个进程一起更新一个红包的库存，又会遇到数据库并发锁冲突的问题，导致更新操作会排队执行，降低发放效率，不能起到多进程的优势。例如，经过测试发现，通过开启多进程发放红包时，每秒最多发放60个红包，如果发放红包的任务时间比较紧迫，则可能导致大部分用户无法及时收到红包。

本申请实施例在采用并发任务发放资源的基础上，通过减少并发任务与数据库之间的交互次数，大幅度减少数据库更新数据花费的用时，有效提升了资源发放效率，无需用户自行领取资源，提升用户便捷度和满意度。

以下结合图1至图10对本申请的技术方案进行示例性说明。

图1是本申请实施例示出的一种资源发放方法、装置和电子设备的应用场景的示意图。

参见图1的左图，客户端的显示界面上可以显示多种功能的控件，用户可以通过点击等操作实现所需的功能。例如，客户端上可以有查看消息或者领取优惠券的功能的控件。相关技术中可以由控件显示有未读消息、通知或显示有未领取优惠券等。用户可能不会关注这些消息或者懒得手动查看优惠券种类，导致打不动预期的促销效果。

参见图1的右图，无需用户手动查看消息或者手动领取优惠券，系统在确定用户为目标用户时，会自动给该目标用户的客户端发放优惠券，这样使得用户在进行购买、支付等操作时，客户端可以自动使用已被发放的优惠券进行结算等，有效提升用户的体验，提升促销效果。该方案的用户体验好，但是同时存在优惠券发放的时间成本过高等问题，本申请的技术方案可以较好地解决该问题。

需要说明的是，图一中所示的终端设备仅为示例性示出，终端设备包括但不限于：智能手机、笔记本电脑、平板电脑和台式机等具有显示幕，并且能够显示互联网(web)界面的设备。

图2是本申请实施例示出的一种适用于资源发放方法、装置和电子设备的系统架构的示意图。需要注意的是，图2所示仅为可以应用本申请实施例的系统架构的示例，以帮助本领域技术人员理解本申请的技术内容，但并不意味着本申请实施例不可以用于其他设备、系统、环境或场景。

参见图2，根据该实施例的系统架构200可以包括终端设备201、204、服务器202、203和网络205。网络205用以在终端设备201、204、服务器202、203之间提供通信链路的介质。网络205可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备201、204通过网络205与其他终端设备、服务器202和主机203进行交互，以接收或发送数据等，如发送配置信息、接收资源发放状态等。终端设备201、204可以安装有各种应用，例如，网页浏览器应用、数据库类应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等应用等。

终端设备201、204包括但不限于台式电脑、平板电脑、膝上型便携计算机等等可以支持浏览网页、上网等功能的电子设备。

服务器202可以接收配置信息、操作指令等，还可以发送资源发放状态等。例如，服务器202可以为后台管理服务器、服务器集群等。

需要说明的是，终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和云端。

本申请的技术方案可以基于上述系统架构实现：在终端设备上设置配置信息，向服务器端发送发放指令等。服务器端按照配置信息确定目标用户和待发放资源，启动容器，并在容器中运行程序以向客户端发放资源，并在发放资源的过程中更新数据库，确保按照预期结果运行。

图3是本申请实施例示出的一种资源发放方法的流程示意图。

参见图3，由客户端执行的资源发放方法，可以包括操作S310～操作S320。

在操作S310，通过多个第一协程消费消息队列的消息，以执行发放资源任务，并将所述资源发放任务关联信息输入有缓冲的通道，所述消息包括资源发放任务关联信息，所述资源发放任务关联信息来源于资源发放任务数据集。

在本实施例中，资源发放任务关联信息包括但不限于：目标用户标识、资源发放任务标识等。此外，资源发放任务关联信息还可以根据资源发放任务所需设置其它信息，如资源类型、资源数量等。有缓冲的通道的详细内容参见如下所示的相关说明。

资源发放任务关联信息可以是基于预设规则确定的信息。例如，根据营销策略从用户群中确定的目标用户的用户标识(UID)。例如，根据预设规则生成资源发放任务标识。此外，资源发放任务关联信息可以是由用户导入的信息。例如，用户可以将指定数据集中的指定数据作为资源发放任务关联信息。例如，用户可以将数据库或者Excel中的数据作为资源发放任务关联信息。

图4是本申请实施例示出的协程的示意图。参见图4所示，进程、线程和协程之间可以是包含关系。以下分别对进程、线程和协程进行说明。

例如，进程是操作系统分配资源的最小单位。一个进程可以有一个或多个线程，进程是程序一次动态执行的过程。每个进程都有自己的独立内存空间，不同进程通过进程间通信来通信。进程占据独立的内存，所以上下文进程间的切换开销(栈、寄存器、页表、文件句柄等)比较大，但相对比较稳定安全。

不同进程是不同的独立内存空间，上下文切换时需保存调用栈的信息、cpu各寄存器的信息、虚拟内存、以及打开的相关句柄等信息，导致上下文进程间切换开销很大，通讯麻烦。进程间通讯主要通过信号传递的方式来实现的，实现方式有多种，包括信号量、管道、事件等，任何一种方式的通讯方式都需要过内核，导致通讯效率比较低。

线程是程序执行的最小单位(如CPU调度的最小单位)。一个线程可以有一个或多个协程，每个线程都有独立一套的寄存器和栈，这样可以确保线程的控制流是相对独立的。线程与进程不同之处在于：进程是最小的资源分配单位，线程是最小的运行单位。

每个线程有独立一套的寄存器和栈，可以确保线程的控制流是相对独立的。由于同进程下的各个线程之间使用同一线程的内存空间(包括代码段、数据集、堆等)，可以共享进程资源。因此，同进程内的多线程通信相对进程间通信来说更简单高效。但也因为进程资源共享，所以会产生资源竞争，需要通过锁机制来协同，例如通过全局解释器锁(GlobalInterpreter Lock，简称GIL锁)来协同。

GIL锁是解释器用于同步线程的一种机制，其使得任何时刻仅有一个线程在执行。即便在多核处理器上，使用GIL的解释器也只允许同一时间执行一个线程。

也就是说，线程从属于进程，是程序的实际执行者。一个进程至少包含一个主线程，也可以有更多的子线程。多个线程共享所属进程的资源，同时线程也拥有自己的专属资源。线程间通信主要通过共享内存，上下文切换很快，资源开销较少，但相比进程不够稳定容易丢失数据。

协程是一种用户态的轻量级线程，协程的调度完全由用户控制。一个线程可以拥有多个协程，协程不是被操作系统内核所管理，而完全是由程序所控制。

在某些实施例中，通过多个第一协程消费消息队列的消息，以执行发放资源任务可以包括如下操作。对于每个第一协程，首先，解析该第一协程消费的消息得到资源发放任务关联信息。然后，至少基于资源发放任务关联信息执行发放资源任务。例如，消息中可以包括资源发放任务标识、目标用户标识、资源数量等。消息可以是多种格式的信息，如json字符串等。其中，资源可以多种有价对象，包括但不限于：消费券、优惠券、有价证券、红包等，在此不做限定。

在操作S320，通过第二协程合并处理来自所述有缓冲的通道的多个所述资源发放任务关联信息，得到针对所述资源发放任务数据集的更新数据。

在本实施例中，可以通过创建的协程对资源发放任务关联信息进行处理，得到需要更新的数据。相关技术中，为了保证资源发放任务的正确执行，需要及时更新数据库中的资源发放任务关联信息，如已发放用户从目标用户更新为已发放用户。如已发放资源需要在数据库中进行更新，避免超支发放资源。相关技术为了及时更新上述信息，每执行一次资源发放操作，就需要对数据库进行一次写操作。虽然单次写操作需要花费的时间很短，但是，对于需要上百万或上千万次写操作，所花费的时长达到数小时或者数天，严重制约了资源发放任务的效率。

本实施例中对资源发放任务关联信息进行诸如缓冲、汇集等处理，使得可以基于多次资源发放任务产生的数据进行缓冲、汇集等处理，以便根据处理结果对数据库进行写操作，无需分多次逐次进行写操作。第二协程可以是和第一协程不同的协程。

在操作S330，如果满足数据更新条件，则基于所述更新数据更新所述资源发放任务数据集。

在本实施例中，为了提升资源发放任务的效率，并且避免资源发放任务数据集中资源发放任务关联信息紊乱，在第二协程满足数据更新条件时，对资源发放任务数据集进行更新，如对数据库进行写操作以实现数据更新，有效降低了写操作的次数，提升数据库性能，提升资源发放能力。

在某些实施例中，资源发放任务关联信息包括资源关联信息和发放对象关联信息，资源发放任务数据集包括资源关联信息子集和发放对象关联信息子集，第二协程包括资源管理协程和发放对象管理协程。其中，资源关联信息包括但不限于：资源发放任务标识、红包数量等中至少一种。发放对象关联信息包括但不限于：目标用户标识等。

相应地，通过第二协程合并处理来自所述有缓冲的通道的多个所述资源发放任务关联信息，得到针对所述资源发放任务数据集的更新数据可以包括如下操作，将所述资源关联信息缓冲、汇集在通道，以便所述资源管理协程合并处理来自所述通道的多个所述资源关联信息，得到第一更新数据。此外，将所述发放对象关联信息缓冲、汇集在通道，以便所述发放对象管理协程合并处理来自所述通道的多个所述发放对象关联信息，得到第二更新数据。这样可以通过两个协程分别对两个数据子集进行更新，减少写操作的总用时。

在某些实施例中，将所述资源关联信息缓冲、汇集在通道，以便所述资源管理协程合并处理来自所述通道的多个所述资源关联信息可以包括如下操作。首先，创建资源更新通道(channel，简称chan)，资源更新通道包括第一预设缓冲长度。然后，资源更新通道基于第一预设缓冲长度存储资源关联信息。接着，资源管理协程汇集资源更新通道中存储的资源关联信息。

其中，为了提升系统的稳定性和处理速度，可以采用有缓冲的通道。Go语言中有缓冲的通道(buffered channel)是一种在被接收前能存储一个或者多个值的通道。这种类型的通道并不强制要求go协程(goroutine)之间必须同时完成发送和接收。通道会阻塞发送和接收动作的条件也会不同。只有在通道中没有要接收的值时，接收动作才会阻塞。只有在通道没有可用缓冲区容纳被发送的值时，发送动作才会阻塞。有缓冲的通道和无缓冲的通道之间的不同：无缓冲的通道保证进行发送和接收的goroutine会在同一时间进行数据交换。有缓冲的通道没有这种保证，有助于提升资源发放任务的执行效率。

具体地，在无缓冲通道的基础上，为通道增加一个有限大小的存储空间形成带缓冲通道。带缓冲通道在发送时无需等待接收方接收即可完成发送过程，并且不会发生阻塞，只有当存储空间满时才会发生阻塞。同理，如果缓冲通道中有数据，接收时将不会发生阻塞，直到通道中没有数据可读时，通道将会再度阻塞。采用有缓冲的通道，能够实现异步收发过程，效率可以有明显的提升。

在某些实施例中，将所述发放对象关联信息缓冲、汇集在通道，以便所述发放对象管理协程合并处理来自所述通道的多个所述发放对象关联信息可以包括如下操作。首先，创建发放对象更新通道，发放对象更新通道包括第二预设缓冲长度。然后，发放对象更新通道基于第二预设缓冲长度存储发放对象关联信息。接着，发放对象管理协程汇集发放对象更新通道中存储的发放对象关联信息。

在一个具体实施例中，资源更新通道和/或发放对象管理协程采用有缓冲的通道，通道的缓冲长度设置为100，同时设置缓冲清理时间为2秒，降低与数据库的交互次数降低耗时，同时避免高并发带来的数据库锁互斥问题。

在某些实施例中，如果满足数据更新条件，则基于更新数据更新资源发放任务数据集可以包括如下操作，响应于资源管理协程满足第一更新条件，更新资源关联信息子集，并且，响应于发放对象管理协程满足第二更新条件，更新发放对象关联信息子集。

图5是本申请实施例示出的一种数据流示意图。

参见图5，数据库中存在资源关联信息子集和发放对象关联信息子集，可以根据营销策略等选出这两个子集，这两个子集的数据之间可以存在对应关系。根据预设规则对这两个子集中存在对应关系的数据进行组装，得到消息，并添加到消息队列中，等待协程1～协程n消费消息队列中的消息。协程1～协程n对消费的消息进行解析，得到资源关联信息和发放对象关联信息，并分别缓存在资源更新通道或者发放对象更新通道中。在满足第一更新条件时，协程a获取资源更新通道中的多个数据，并进行汇集分析，得到第一更新数据，并基于第一更新数据更新资源关联信息子集。在满足第二更新条件时，协程b获取发放对象更新通道中的多个数据，并进行汇集分析，得到第二更新数据，并基于第二更新数据更新发放对象关联信息子集。这样就完成了一次循环。后续循环过程中，可以基于更新后的资源关联信息子集和发放对象关联信息子集组装消息，然后重复与上一次循环相同的操作，直至完成所有资源、所有目标用户的发放，或者直至出现执行异常。

在某些实施例中，上述方法可以通过如下方式确定消息队列中的消息。首先，将从资源发放任务数据集中获得的发放任务标识，资源信息、关联的用户标识组装成待消费消息。然后，将待消费消息加入消息队列。例如，查询出与资源发放任务对应的目标用户的用户标识，并将资源信息，任务创建人信息，资源发放任务标识及用户标识组装成json字符串，然后加入到消息队列中。

在某些实施例中，资源发放任务数据集中的数据可以通过如下方式得到。首先，基于资源发放条件确定目标发放对象和目标发放对象的发放对象关联信息。然后，确定与目标发放对象对应的待发放资源的资源关联信息。接着，将发放对象关联信息和资源关联信息相关联地存储在资源发放任务数据集中。

图6是本申请实施例示出的另一种资源发放方法的逻辑图。

参见图6，示出了一种可能的资源发放方法的逻辑图。

资源发放方法可以分为三部分，第一部分是人群圈选，配置指定人群场景发放任务。第二部分是异步定时执行任务功能。第三部分是核心部分执行高效的发放任务程序。

关于第一部分，以发放红包为例进行示例性说明。可以由场景配置中心在内部运营的平台搭建，运营在平台上配置场景名称和指定要发的红包，选择不同的用户圈选条件。具体可以包括两个程序。第一步，程序会根据条件圈选出指定用户数量进行提示，第二步，用户确认后提交建立发放任务。

a)场景配置前置检查。

i.检查场景名称是否重复创建以及执行时间是否正确设置。

ii.检查符合条件的人群是否存在。

iii.检查红包剩余库存适合符合所选人群数。

b)提交保存场景任务。

i.先创建一条执行任务将配置的信息存储到mysql数据库。其中，mysql一种数据存储数据关系型数据库。

ii.通过运营圈选的条件查询出符合条件的uid存储到mysql数据库，并且与配置的任务建立关联，为执行发放任务做准备。其中，uid用来标识用户唯一性的数字。

关于第二部分，定时触发任务执行程序，可以分为两步。第一步，查询出符合条件的待发放任务。第二步，筛选完任务后，发放任务消息。

a)查询所有待发任务查询。

i.从mysql中取出所有待发任务。

ii.校验任务状态是否正常，校验红包状态是否正常，校验用户数据及红包库存。

iii.若状态不正常即刻发放飞书消息，通知相关人员，并将任务状态标记为发放失败，记录原因。

b)组装任务信息发放任务消息。

i.查询出准备好的任务关联的uid，并将红包信，任务创建人信息，任务id及uid组装成json字符串。其中，json一种通用数据传递的字符串格式。

ii.将组装好的任务json数据，指定topic发放到kafka消息中间件中，等待发放程序消费任务消息。其中，kakfa是一种消息中间件。.Topic是kafka标识消息分类的字符串标识。

关于第三部分，消费kafka任务消息，执行发放任务。

a)golang语言消费任务执行程序执行发放任务:

i.程序初始化先创建库存更新chan(通道)，红包关系数据存储chan，再分别创建协程接受库存chan和红包chan中的数据，进行缓冲汇集，缓冲长度设置为100，同时设置缓冲清理时间为2秒，降低与数据库的交互次数降低耗时，同时避免高并发带来的数据库锁互斥问题。其中，.chan是glang语言用来实现协程间数据互通的工具。

ii.开启50个golang的协程任务，订阅指定kafka topic消息，解析json数据。以开启50个golang的协程任务为例，资源发放速度是常规方法的8倍以上。

iii.校验数据是否正确，校验是否发放重复；

iv.分别将库存更新任务，红包关系存储任务，发放到指定的chan，完成红包的发放。

本实施例对相关技术的资源发放方法进行革新优化增效，通过利用golang语言协程的优势，利用kafka高效消息消费工具实现任务异步话增效，通用控制，流量控制，有效提升了资源发放效率。

图7是本申请实施例示出的另一种资源发放方法的流程图。

参见图7所示，上述方法除了包括操作S310～操作S330之外，还可以执行操作S740。

在操作S740，容器化部署二进制的可执行文件，可执行文件包括第一协程、第二协程中至少一种。

在一个具体实施例中，可以通过如下方式进行服务部署。

首先，将服务程序打包成二进制可执行文件。然后，将服务通过k8s容器化部署，利用k8s容器管理能力(监控\保活\告警)，并部署多个实例进程，以提高效率。其中，k8s是一种容器部署，服务发现，容器管理的解决工具。资源发放效率随着容器数量的倍增而近似成倍提升。

在某些实施例中，为了及时发现资源发放异常，便于维护系统，上述方法还可以包括如下操作。

首先，确定发放资源任务的状态。然后，如果状态是异常，则输出告警信息，并且记录异常原因。

具体地，可以校验任务状态是否正常，校验红包状态是否正常，校验用户数据及红包库存。如果状态不正常即刻通知相关人员(如发送短信、发送邮件或者发放飞书消息等)，并将任务状态标记为发放失败，记录原因。

本实施例通过容器化部署有效地进一步提升了资源发放效率，并且可以在资源发放出现异常时，及时告知相关维护管理人员进行维护，提升系统可靠性。

本申请的另一方面还提供了一种资源发放装置。

图8是本申请实施例示出的一种资源发放装置的结构的框图。

参见图8，上述装置800可以包括消息消费模块810、信息处理模块820和数据更新模块830。

消息消费模块810用于通过多个第一协程消费消息队列的消息，以执行发放资源任务，并将所述资源发放任务关联信息输入有缓冲的通道，所述消息包括资源发放任务关联信息，所述资源发放任务关联信息来源于资源发放任务数据集。

信息处理模块820用于通过第二协程合并处理来自所述有缓冲的通道的多个所述资源发放任务关联信息，得到针对所述资源发放任务数据集的更新数据。

数据更新模块830用于如果满足数据更新条件，则基于所述更新数据更新所述资源发放任务数据集。

具体地，该资源发放装置800可以实现自动人群圈选功能，kafka异步化任务能力，使程序可以同时执行多个任务。此外，利用golang的协程优势，解决传统发放的数据库写操作次数过多导致效率较低问题和数据库互锁问题，优化了用户体验，有效降低了发生经济损失的概率。

关于上述实施例中的装置800其中各个模块、单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不再做详细阐述说明。

本申请的另一方面还提供了一种资源发放系统。

图9是本申请实施例示出的一种资源发放系统的结构的框图。

参见图9，该资源发放系统900可以包括：客户端910、服务器端920。

客户端910用于接收服务器端920发放的资源，并且可以在客户端的显示界面上进行显示。此外，还可以基于资源进行支付、结算等功能。

服务器端920用于执行如上所示的资源发放方法。

具体地，资源发放系统可以根据配置的任务，通过json形式数据传输到消息处理中间件，异步化任务处理，并利用golang协程和chan数据汇集缓冲的实现，实现灵活高效任务的执行。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不再做详细阐述说明。

图10是本申请实施例示出的电子设备的结构的框图。该电子设备例如可以是配置平台设备、网页端设备或客户端设备等。

参见图10，电子设备1000包括存储器1010和处理器1020。

处理器1020可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器1010可以包括各种类型的存储单元，例如系统内存、只读存储器(ROM)，和永久存储装置。其中，ROM可以存储处理器1020或者计算机的其他模块需要的静态数据或者命令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的命令和数据的非易失性存储设备。在一些实施方式中，永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中，永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备，例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的命令和数据。此外，存储器1010可以包括任意计算机可读存储媒介的组合，包括各种类型的半导体存储芯片(DRAM，SRAM，SDRAM，闪存，可编程只读存储器)，磁盘和/或光盘也可以采用。在一些实施方式中，存储器1010可以包括可读和/或写的可移除的存储设备，例如激光唱片(CD)、只读数字多功能光盘(例如DVD-ROM，双层DVD-ROM)、只读蓝光光盘、超密度光盘、闪存卡(例如SD卡、min SD卡、Micro-SD卡等等)、磁性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。

存储器1010上存储有可执行代码，当可执行代码被处理器1020处理时，可以使处理器1020执行上文述及的方法中的部分或全部。

上文中已经参考附图详细描述了本申请的方案。在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详细描述的部分，可以参见其他实施例的相关描述。本领域技术人员也应该知悉，说明书中所涉及的动作和模块并不一定是本申请所必须的。另外，可以理解，本申请实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减，本申请实施例装置中的模块可以根据实际需要进行合并、划分和删减。

此外，根据本申请的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本申请的上述方法中部分或全部步骤的计算机程序代码命令。

或者，本申请还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质)，其上存储有可执行代码(或计算机程序、或计算机命令代码)，当可执行代码(或计算机程序、或计算机命令代码)被电子设备(或电子设备、服务器等)的处理器执行时，使处理器执行根据本申请的上述方法的各个步骤的部分或全部。

本领域技术人员还将明白的是，结合这里的申请所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。

附图中的流程图和框图显示了根据本申请的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行命令。也应当注意，在有些作为替换的实现中，方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机命令的组合来实现。

以上已经描述了本申请的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (11)

1.一种资源发放方法，其特征在于，包括：

通过多个第一协程消费消息队列的消息，以执行发放资源任务，并将资源发放任务关联信息输入有缓冲的通道，所述消息包括资源发放任务关联信息，所述资源发放任务关联信息来源于资源发放任务数据集；

通过第二协程合并处理来自所述有缓冲的通道的多个所述资源发放任务关联信息，得到针对所述资源发放任务数据集的更新数据；

如果满足数据更新条件，则基于所述更新数据更新所述资源发放任务数据集。

2.根据权利要求1所述的方法，其特征在于，所述通过多个第一协程消费消息队列的消息，以执行发放资源任务，包括：

对于所述多个第一协程中的每个第一协程，解析该第一协程消费的消息，得到资源发放任务关联信息；

至少基于所述资源发放任务关联信息执行发放资源任务。

3.根据权利要求2所述的方法，其特征在于，所述资源发放任务关联信息包括资源关联信息和发放对象关联信息，所述资源发放任务数据集包括资源关联信息子集和发放对象关联信息子集，所述第二协程包括资源管理协程和发放对象管理协程；

所述通过第二协程合并处理来自所述有缓冲的通道的多个所述资源发放任务关联信息，得到针对所述资源发放任务数据集的更新数据，包括：

将所述资源关联信息缓冲、汇集在通道，以便所述资源管理协程合并处理来自所述通道的多个所述资源关联信息，得到第一更新数据，并且，将所述发放对象关联信息缓冲、汇集在通道，以便所述发放对象管理协程合并处理来自所述通道的多个所述发放对象关联信息，得到第二更新数据。

4.根据权利要求3所述的方法，其特征在于，所述将所述资源关联信息缓冲、汇集在通道，以便所述资源管理协程合并处理来自所述通道的多个所述资源关联信息，包括：

创建资源更新通道，所述资源更新通道包括第一预设缓冲长度；

所述资源更新通道基于所述第一预设缓冲长度存储所述资源关联信息；

所述资源管理协程汇集所述资源更新通道中存储的资源关联信息。

5.根据权利要求3所述的方法，其特征在于，所述将所述发放对象关联信息缓冲、汇集在通道，以便所述发放对象管理协程合并处理来自所述通道的多个所述发放对象关联信息，包括：

创建发放对象更新通道，所述发放对象更新通道包括第二预设缓冲长度；

所述发放对象更新通道基于所述第二预设缓冲长度存储所述发放对象关联信息；

所述发放对象管理协程汇集所述发放对象更新通道中存储的发放对象关联信息。

6.根据权利要求3所述的方法，其特征在于，所述如果满足数据更新条件，则基于所述更新数据更新所述资源发放任务数据集，包括：

响应于所述资源管理协程满足第一更新条件，更新所述资源关联信息子集，并且，响应于所述发放对象管理协程满足第二更新条件，更新所述发放对象关联信息子集。

7.根据权利要求1所述的方法，其特征在于，还包括：

容器化部署二进制的可执行文件，所述可执行文件包括所述第一协程、所述第二协程中至少一种。

8.根据权利要求1所述的方法，其特征在于，还包括：

将从所述资源发放任务数据集中获得的发放任务标识，资源信息、关联的用户标识组装成待消费消息；

将所述待消费消息加入所述消息队列。

9.根据权利要求1所述的方法，其特征在于，还包括：

基于资源发放条件确定目标发放对象和所述目标发放对象的发放对象关联信息；

确定与所述目标发放对象对应的待发放资源的资源关联信息；

将所述发放对象关联信息和所述资源关联信息相关联地存储在所述资源发放任务数据集中。

10.一种资源发放装置，其特征在于，包括：

消息消费模块，用于通过多个第一协程消费消息队列的消息，以执行发放资源任务，并将资源发放任务关联信息输入有缓冲的通道，所述消息包括资源发放任务关联信息，所述资源发放任务关联信息来源于资源发放任务数据集；

信息处理模块，用于通过第二协程合并处理来自所述有缓冲的通道的多个所述资源发放任务关联信息，得到针对所述资源发放任务数据集的更新数据；

数据更新模块，用于如果满足数据更新条件，则基于所述更新数据更新所述资源发放任务数据集。

11.一种电子设备，其特征在于，包括：

处理器；以及

存储器，其上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行根据权利要求1-9中任一项所述的方法。