抢单方法、装置、电子设备及存储介质与流程

1.本公开实施例涉及互联网技术领域，更具体地，涉及一种抢单方法、装置、电子设备及计算机可读存储介质。


背景技术：

2.随着互联网技术的不断发展，用户可以通过各种内容生成平台方便的生成、查看以及分享视频、图片、图文等各种形式的内容数据。为了确保用户上传的内容数据能够符合相关管理规范，内容生成平台通常会根据用户上传的内容数据结合用户标识等相关信息，对应生成内容工单，并在相关审核人员审核通过该内容工单的情况下发布该内容数据。
3.由于不同审核人员在筛选待审核的内容工单时，往往并不是基于内容工单的工单标识，而往往是根据不同维度的筛选条件进行筛选，因此，在同一时刻，可能存在不同审核人员对同一内容工单进行抢单的情况；同时，由于管理全部内容工单的内容工单池的数据量较大且变化也较快，这就对电子设备如何快速的响应用户的抢单请求提出了挑战。


技术实现要素：

4.本公开的一个目的是提供一种抢单方法、装置、电子设备及存储介质，以使得电子设备可以快速的响应用户的抢单请求，以将目标内容工单提供至用户所使用的终端设备。
5.本公开的第一方面，提供了一种抢单方法，该方法包括：
6.接收终端设备发送的抢单请求，其中，所述抢单请求包括用于筛选目标内容工单的目标筛选条件；
7.响应于所述抢单请求，根据所述目标筛选条件，基于预设的多级查询引擎，获得所述目标内容工单；
8.其中，所述多级查询引擎包括第一查询引擎和第二查询引擎，所述第一查询引擎为基于多个消息队列对应管理满足不同筛选条件的内容工单的查询引擎，所述第二查询引擎为基于索引机制管理内容工单的查询引擎。
9.本公开的第二方面，还提供了一种抢单装置，包括：
10.接收模块，用于接收终端设备发送的抢单请求，其中，所述抢单请求包括用于筛选目标内容工单的目标筛选条件；
11.响应模块，用于响应于所述抢单请求，根据所述目标筛选条件，基于预设的多级查询引擎，获得所述目标内容工单；
12.其中，所述多级查询引擎包括第一查询引擎和第二查询引擎，所述第一查询引擎为基于多个消息队列对应管理满足不同筛选条件的内容工单的查询引擎，所述第二查询引擎为基于索引机制管理内容工单的查询引擎。
13.本公开的第三方面，还提供了一种电子设备，包括：
14.存储器，用于存储可执行的指令；
15.处理器，用于根据所述可执行的指令的控制，运行所述电子设备执行根据本公开
的第一方面所述的方法。
16.本公开的第四方面，还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有可被计算机读取执行的计算机程序，所述计算机程序用于在被所述计算机读取运行时，执行根据本公开的第一方面所述的方法。
17.本公开实施例的一个有益效果在于，根据本公开的实施例，在接收到用户所使用的终端设备发送的抢单请求的情况下，区别于相关技术中基于单一查询引擎进行响应时可能存在的响应不及时的问题，本公开的实施例可以根据抢单请求中的筛选条件，通过预设的多级查询引擎，快速的将目标内容工单提供至该终端设备。
18.通过以下参照附图对本说明书的示例性实施例的详细描述，本说明书的其它特征及其优点将会变得清楚。
附图说明
19.被结合在说明书中并构成说明书的一部分的附图示出了本说明书的实施例，并且连同其说明一起用于解释本说明书的原理。
20.图1是本公开实施例提供的抢单方法的流程示意图。
21.图2是本公开实施例提供的抢单处理的框架示意图。
22.图3是本公开实施例提供的实现第一查询引擎的框架示意图。
23.图4是本公开实施例提供的抢单装置的原理框图。
24.图5是本公开实施例提供的电子设备的硬件结构示意图。
具体实施方式
25.现在将参照附图来详细描述本公开的各种示例性实施例。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本发明的范围。
26.以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本发明及其应用或使用的任何限制。
27.对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为说明书的一部分。
28.在这里示出和讨论的所有例子中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它例子可以具有不同的值。
29.应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。
30.《方法实施例》
31.通常，针对用户的抢单请求，一般可以通过以下任一方式构建查询引擎：1、基于关系型数据库；2、基于消息队列；3、基于es(elasticsearch)搜索引擎。
32.然而，基于关系型数据库，例如，mysql、tidb等关系型数据库构建查询引擎的方式虽然能够支持灵活的筛选条件并且能够将数据按照严格排序的方式提供给电子设备，但是由于关系型数据库的索引限制，该种方式在管理的数据量较大，例如，在达到百万计的量级之后，数据库的性能将急剧下降，在该种情况下，基于该种方式构建的查询引擎可能存在不
能快速响应用户抢单请求的问题。基于消息队列构建查询引擎的方式往往存在数据分发不够灵活的问题，即，其往往需要电子设备预先建立与不同消息队列对应的主题，并需要用户预先订阅相关主题，存在不够方便、灵活的问题。而基于es搜索引擎构建查询引擎的方式存在索引建立时间耗时较长，可能不能快速响应用户抢单请求的问题。
33.另外，与传统抢单，例如电商抢单不同，在电商抢单场景下，往往是根据用户指定的物品id进行抢单，其抢单范围较小；而在内容工单的抢单场景下，审核人员往往是通过指定不同维度的筛选条件来发出抢单请求，其要求电子设备处理的抢单范围要远大于传统抢单；而与出行打车系统的派单相比，由于出行打车系统的派单通常是基于网状，即对应区域范围内的司机及客户进行派单，因此，其在需要处理的数据的量级上也远小于内容工单的抢单场景。
34.为使得在内容工单的抢单场景下，电子设备可以快速的响应用户的抢单请求，本公开的实施例提供了一种抢单方法，请参看图1，其是本公开实施例提供的抢单方法的流程示意图。该方法可以由电子设备实施，该电子设备具体可以为服务器，例如，可以为刀片服务器、机架式服务器等；或者，根据需要，该电子设备也可以为终端设备，例如，可以为手机、平板电脑等，此处不做特殊限定；需要说明的是，在本公开的实施例中，如无特殊说明，以该电子设备为服务器进行举例说明。
35.如图1所述，本实施例的方法可以包括如下步骤s1100-s1200，以下予以详细说明。
36.步骤s1100，接收终端设备发送的抢单请求，其中，所述抢单请求包括用于筛选目标内容工单的目标筛选条件。
37.终端设备是指用户，例如，是待审核内容工单的审核人员所使用的设备，该终端设备可以为手机、平板电脑等设备，此处不做特殊限定。
38.抢单请求，可以是用户基于终端设备向实施该方法的电子设备发送的、用于获取满足目标筛选条件的目标内容工单的数据请求。
39.在本公开的实施例中，用于筛选内容工单的筛选条件可以包括至少一个维度，例如，可以从涉及领域、用户类型、数据量级、是否热点内容等多个维度构建筛选条件。
40.步骤s1200，响应于所述抢单请求，根据所述目标筛选条件，基于预设的多级查询引擎，获得所述目标内容工单；其中，所述多级查询引擎包括第一查询引擎和第二查询引擎，所述第一查询引擎为基于多个消息队列对应管理满足不同筛选条件的内容工单的查询引擎，所述第二查询引擎为基于索引机制管理内容工单的查询引擎。
41.在一个实施例中，所述根据目标筛选条件，基于预设的多级查询引擎，获得目标内容工单，包括：获取当前内容工单池中存储的全部内容工单的总数据量；在该总数据量大于预设阈值的情况下，根据目标筛选条件，基于该第一查询引擎，获得目标内容工单；以及，在该总数据量不大于预设阈值的情况下，根据该目标筛选条件，基于该第二查询引擎，获得目标内容工单。
42.为便于理解，请参看图2，其是本公开实施例提供的抢单处理的框架示意图。如图2所示，为解决基于单一方式构建的查询引擎在响应用户的抢单请求时可能存在的不够及时的问题，本公开的实施例提供的抢单方法通过预设的包括第一查询引擎和第二查询引擎的多级查询引擎，可以在当前用于存储全部内容工单的内容工单池中的总数据量大于预设阈值的情况下，根据基于多个消息队列管理满足不同筛选条件的第一查询引擎快速、方便的
查询获得目标内容工单；而在总数据量较小，例如，不大于预设阈值的情况下，可以通过基于索引机制的第二查询引擎快速的查询获得目标内容工单数据。
43.以下，首先对该多级查询引擎中的第一查询引擎如何管理满足不同筛选条件的内容工单进行详细说明。
44.在一个实施例中，第一查询引擎可以通过以下步骤管理满足不同筛选条件的内容工单：根据接收到的、用于筛选第一内容工单的第一筛选条件，通过预设散列算法，获得第一队列标识；根据所述第一队列标识，在队列注册清单中，确定是否已创建所述第一队列标识所标识的第一消息队列；在确定未创建所述第一消息队列的情况下，根据所述第一队列标识，创建所述第一消息队列，并将所述第一消息队列的队列信息写入所述队列注册清单，其中，所述队列信息包括所述第一队列标识；在确定已创建所述第一消息队列的情况下，基于预设缓存机制，将用于存储全部内容工单的内容工单池中的所述第一内容工单写入所述第一消息队列。
45.其中，第一筛选条件可以包括至少一个筛选维度；该方法具体可以通过以下步骤获得第一队列标识：将至少一个筛选维度中，每一筛选维度的筛选值进行拼接，获得第一筛选键值；根据第一筛选键值，通过预设散列算法，获得第一队列标识。
46.具体地，请参看图3，其是本公开实施例提供的实现第一查询引擎的框架示意图。如图3所示，第一查询引擎在初始时刻可以不包含消息队列，或者，也可以预置对应不同筛选条件的若干个消息队列；当接收到第一抢单请求的情况下，第一查询引擎可以获取该第一抢单请求中的第一筛选条件，并通过将第一筛选条件中对应至少一个筛选维度的筛选值进行拼接，通过预设散列算法得到一个可以唯一性的标识一消息队列的第一队列标识；之后，第一查询引擎可以根据该第一队列标识，在队列注册清单中查询确定是否已创建第一消息队列；若未创建，则可以基于redis数据库创建第一消息队列，并将第一消息队列的队列信息写入队列注册清单，即注册表中；若已创建，则第一查询引擎则可以从存储全部内容工单的内容工单池中获取满足第一筛选条件的第一内容工单写入该第一消息队列，以在第一查询引擎接收到终端设备发送的抢单请求时，可以根据匹配筛选条件，从匹配的消息队列中取出最新的内容工单提供给终端设备。
47.需要说明的是，在本公开的实施例中，在根据第一筛选条件，构建第一队列标识时，具体可以先将第一筛选条件中对应不同筛选维度的筛选值进行拼接得到第一筛选键值，再使用散列算法，例如，md5信息摘要算法(md5，md5message-digestalgorithm)对该筛选键值进行加密，以确保第一队列标识的唯一性。例如，可以以类似“筛选维度1：筛选值1；筛选维度2：筛选值2
…”
的形式将筛选条件中对应不同筛选维度的筛选值进行拼接以得到对应筛选键值，之后，可以使用md5算法对该筛选键值进行加密。
48.另外，在成功创建第一消息队列之后，为提升查询引擎的响应准确性，该方法还可以通过单独一线程将内容工单池中满足第一筛选条件的内容工单实时写入第一消息队列，以使得第一查询引擎可以及时的严格按照时间顺序将用户生成的内容数据所对应的内容工单提供至审核人员进行审核。当然，也可以按照其他缓存机制，例如，按照预设时间间隔从内容工单池中获取内容工单并写入该第一消息队列，此处不做特殊限定。
49.此外，在本公开的一个优选实施例中，如图2所示，第一查询引擎中的消息队列可以存储在第一查询引擎数据库中，该第一查询引擎数据库具体可以为redis数据库，即，第
一查询引擎可以为基于redis数据库构建的消息队列响应抢单请求的查询引擎；当然，在具体实施时，也可以基于kafka、rocketmq等消息中间件构建的消息队列，此处不做特殊限定。
50.以上，结合图3对如何实现第一查询引擎进行了详细说明，根据以上说明可知，在本公开的实施例中，多级查询引擎中的第一查询引擎由于通过多个消息队列分别管理满足不同筛选条件的内容工单，并且由于在成功创建消息队列的情况下，第一查询引擎会将实时生成的内容工单预先分配至对应消息队列，这就使得在用户有抢单时，当用户抢单请求中的筛选条件能够命中已存在的消息队列时，第一查询引擎可以快速的将满足目标筛选条件的目标工单数据提供至用户终端设备。以下，对电子设备在接收到抢单请求的情况下，在当前内容工单池中的总数据量大于预设阈值的情况下，如何根据目标筛选条件，基于该第一查询引擎，获得目标工单数据进行详细说明。
51.请继续参看图2，在具体实施时，所述根据目标筛选条件，基于第一查询引擎，获取目标内容工单，包括：根据目标筛选条件，通过预设散列算法，获得目标队列标识；在根据目标队列标识，确定已创建目标消息队列的情况下，获取目标消息队列中当前存储的内容工单作为待确定内容工单；对待确定内容工单进行锁单处理，获得锁单状态；在锁单状态表示成功锁单的情况下，将待确定内容工单作为目标内容工单。
52.其中，所述对待确定内容工单进行锁单处理，获得锁单状态，包括：获取内容工单池中与待确定内容工单对应的内容工单的锁定标识；在该锁定标识表示数据未锁定的情况下，设置该锁定标识为表示数据已锁定的信息，并设置锁单状态为表示成功锁单的信息；以及，在该锁定标识表示数据已锁定的情况下，设置锁单状态为表示锁单失败的信息。
53.具体地，在根据目标筛选条件计算得到的目标队列标识，确定已成功创建对应目标消息队列的情况下，则说明第一查询引擎已预先分配好队列中的数据，此时，只需要将当前目标消息队列中的内容工单全部取出作为待确定内容工单；在获得待确定内容工单之后，为避免其他审核人员对同一内容工单的重复审核，可以先到内容工单池中确定待确定内容工单的锁定状态是否为未锁定状态；若是未锁定状态，则可将内容工单池中对应内容工单的锁定标识设置为已锁定，同时设置锁定状态为成功锁定的信息，以指示第一查询引擎将待确定内容工单作为目标内容工单，并将目标内容工单提供至终端设备，以供用户审核。
54.需要说明的是，若在进行锁单处理时，某一内容工单的锁定标识已为锁定状态，则表示其他审核人员已在审核该内容工单，此时，为避免人员重复处理，如图2所示，第一查询引擎可以返回结果为空的目标内容工单，或者，也可以返回类似“系统中不存在满足筛选条件的内容工单”的提示信息，此处不做特殊限定。
55.还需要说明的是，如图2所示，若在根据目标筛选条件计算得到的目标队列标识确定当前还未创建目标消息队列的情况下，此时第一查询引擎可以先创建该目标消息队列，但是由于队列的创建以及预分配数据需要消耗一定的时间，为了提升抢单速度，此时可以进行引擎逐级回退处理，即，在第一查询引擎未命中对应消息队列的情况下，可以从第一查询引擎回退至第二查询引擎，基于第二查询引擎，获得目标内容工单。
56.在一个实施例中，第二查询引擎可以为基于关系型数据库管理内容工单的查询引擎，为节省存储空间，该关系型数据库在管理内容工单时，可以与内容工单池共享存储空间，所述根据目标筛选条件，基于第二查询引擎，获得目标内容工单，包括：根据目标筛选条
件，基于该关系型数据库中预先建立的数据管理索引，获得待确定内容工单；在对待确定内容工单进行锁单处理且成功锁单的情况下，将待确定内容工单作为目标内容工单。
57.需要说明的是，为确保数据的安全和稳定，第二查询引擎中的数据存储必须保证数据不丢失、不重复且具备容灾能力，例如，第二查询引擎可以为基于主从架构构建的关系型数据库。
58.还需要说明的是，在具体实施时，多级查询引擎中的第二查询引擎也可以为基于es搜索引擎构建的查询引擎；或者，本公开实施例提供的多级查询引擎也可以包括第三查询引擎，该第三查询引擎可以为基于es搜索引擎构建的查询引擎。在具体实施时，可以在根据第二查询引擎获取目标内容工单时，统计数据获取时长，并在数据获取时长大于预设阈值的情况下，从第二查询引擎回退至第三查询引擎中进行查询，以进一步提升针对抢单请求的响应速度，进而提升用户体验。
59.另外，在具体实施时，在用户直接根据内容工单的工单标识，例如，工单id搜索目标内容工单时，则可以不必根据预设多级查询引擎查询该内容工单，而是可以直接在内容工单池中进行锁单处理，并在锁单成功的情况下，返回该目标内容工单以供用户审核。
60.综上所述，本公开的实施例提供的方法，在接收到用户所使用的终端设备发送的抢单请求的情况下，区别于相关技术中基于单一查询引擎进行响应时可能存在的响应不及时、不够准确的问题，本公开的实施例可以根据抢单请求中的筛选条件，通过预设的多级查询引擎，快速的将目标内容工单提供至该终端设备
61.《装置实施例》
62.与上述方法实施例相对应，在本实施例中，还提供一种抢单装置，如图4所述，该装置400可以包括接收模块410和响应模块420。
63.该接收模块410，用于接收终端设备发送的抢单请求，其中，所述抢单请求包括用于筛选目标内容工单的目标筛选条件；该响应模块420，用于响应于所述抢单请求，根据所述目标筛选条件，基于预设的多级查询引擎，获得所述目标内容工单；其中，所述多级查询引擎包括第一查询引擎和第二查询引擎，所述第一查询引擎为基于多个消息队列对应管理满足不同筛选条件的内容工单的查询引擎，所述第二查询引擎为基于索引机制管理内容工单的查询引擎。
64.《设备实施例》
65.在本实施例中，还提供一种电子设备，如图5所述，该电子设备500还可以包括处理器520和存储器510，该存储器510用于存储可执行的指令；该处理器520用于根据指令的控制运行电子设备以执行根据本公开任意实施例的方法。
66.该电子设备500可以是服务器，或者也可以为终端设备，在此不做限定。
67.《计算机可读存储介质实施例》
68.本实施例提供了一种计算机可读存储介质，该存储介质中存储有可执行命令，该可执行命令被处理器执行时，执行本说明书任意方法实施例中描述的方法。
69.以上已经描述了本说明书的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人物来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术改进，或者使本技术领域的
其它普通技术人物能理解本文披露的各实施例。本技术的范围由所附权利要求来限定。