CN111125138A - 一种轮询查询数据的方法、装置、计算机设备及存储介质 - Google Patents
一种轮询查询数据的方法、装置、计算机设备及存储介质 Download PDFInfo
- Publication number
- CN111125138A CN111125138A CN201911368300.4A CN201911368300A CN111125138A CN 111125138 A CN111125138 A CN 111125138A CN 201911368300 A CN201911368300 A CN 201911368300A CN 111125138 A CN111125138 A CN 111125138A
- Authority
- CN
- China
- Prior art keywords
- merchant
- key
- value pair
- order information
- redis
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24552—Database cache management
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computational Linguistics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种轮询查询数据的方法、装置、计算机设备及存储介质。所述方法包括:服务器获取订单信息中的商家ID,并将所述商家ID和订单数作为键值对缓存至Redis中;服务器在接收订单查询请求后,根据商家ID判断Redis中是否缓存有所述商家对应的键值对;如果Redis中缓存有所述商家对应的键值对,则判断所述键值对的value是否小于1;当所述value不小于1时,则继续查询数据库,并获取对应的订单信息,并将所述订单信息作为查询结果返回;当所述value小于1时,则直接结束查询流程;如果Redis中未缓存所述商家对应的键值对,则结束查询。本发明通过查询Redis中是否缓存有键值对,判断是否需要继续查询数据库,减小了数据库的访问压力,并且释放了数据库资源。
Description
技术领域
本发明涉及数据处理技术领域,具体涉及一种轮询查询数据的方法、装置、计算机设备及存储介质。
背景技术
随着科技的发展,现在无论是去餐厅吃饭还是付款开票等,都越来越体现人性化,处处为客户考虑。比如用户去餐厅吃饭时,可以提前在网上下单,然后到餐厅就可以直接享用,或者用户到餐厅不用排队去订餐,而是可以通过扫描餐桌上的二维码直接进行订餐,这样不仅节省了用户的时间,而且还提升了餐厅的工作效率。
为了实现上述功能,需要涉及到PC端、手机端和服务端。手机端和服务端之间的通信较为简单,比如用户通过手机扫描二维码下单的时候,手机端会向服务端发送订单信息,服务端接收到订单信息,但是服务端在接收到订单信息以后无法主动向PC端发送订单信息,因此如果PC端想获得对应的订单信息,只能向服务端查询获取。PC端向服务端查询获取订单信息的常用方式有以下几种:1、人工手动查询;2、定时轮询查询;3、通过websocket建立长连接查询。
但是上述三种方式均存在一些弊端,例如通过人工手动查询时,效率低、不方便;而如果是定时轮询查询或者通过websocket建立长连接查询,在用户数量少的时候一般不会出现问题,但是当用户数量比较大时,比如有上千或者上万的用户时,就会出现上千台或者上万台PC端在不断进行定时轮询查询或者通过websocket建立上千个或者上万个长连接,这样会导致服务器压力非常大,并且会消耗大部分资源,从而导致***反应慢,同时还会影响其他功能的正常使用。
因此,如何减小数据库的访问压力以及释放数据库资源是本领域技术人员需要考虑的问题。
发明内容
本发明实施例提供了一种轮询查询数据的方法、装置、计算机设备及存储介质,旨在减小数据库的访问压力以及释放数据库资源。
第一方面,本发明实施例提供了一种轮询查询数据的方法,所述方法包括:
服务器在接收用户提交的订单信息后,将所述订单信息保存至数据库中;
服务器获取所述订单信息中的商家ID,并根据所述商家ID更新对应商家的订单数,并将所述商家ID和订单数作为键值对缓存至Redis中,其中,将所述商家ID作为所述键值对的key,将所述订单数作为所述键值对的value;
服务器在接收商家发送的订单查询请求后,根据所述商家对应的商家ID判断Redis中是否缓存有所述商家对应的键值对;
如果Redis中缓存有所述商家对应的键值对,则判断所述键值对的value是否小于1;
当所述value不小于1时,则继续查询数据库,并获取对应的订单信息,并将所述订单信息作为查询结果返回;当所述value小于1时,则直接结束查询流程;
如果Redis中未缓存所述商家对应的键值对,则直接结束查询流程。
进一步的,还包括:
当服务器接收到所述商家对所述订单信息的消费信息时,对所述数据库中相应的订单信息进行更新,以及将Redis中缓存的键值对的value减1。
进一步的,所述服务器获取所述订单信息中的商家ID,并根据所述商家ID更新对应商家的订单数,并将所述商家ID和订单数作为键值对缓存至Redis中,包括:
根据所述商家ID查询Redis中是否缓存有所述商家ID对应的键值对;
若缓存有所述商家ID对应的键值对,则将键值对中的value加1;
若未缓存所述商家ID对应的键值对,则在Redis中新增一个键值对,并将新增的键值对中的key设置为所述商家ID,value设置为1。
进一步的,所述数据库中保存的订单信息包括:商家ID、订单号、订单状态和订单时间;所述当所述value不小于1时,则继续查询数据库,并获取对应的订单信息,并将所述订单信息作为查询结果返回,包括:
当所述value值大于1时,则查询所述数据库,获取订单时间最早的订单信息,并将所述订单信息作为查询结果返回。
进一步的,所述当服务器接收到所述商家对所述订单信息的消费信息时,对所述数据库中相应的订单信息进行更新,以及将Redis中缓存的键值对的value减1,包括:
将所述数据库中对应的订单信息中的订单状态标记为已处理。
进一步的,所述当服务器接收到所述商家对所述订单信息的消费信息时,对所述数据库中相应的订单信息进行更新,以及将Redis中缓存的键值对的value减1,还包括:
根据商家ID查询Redis中是否缓存有所述商家ID对应的键值对;
若未缓存所述商家ID对应的键值对,则不对Redis中的数据进行修改;
若缓存有所述商家ID对应的键值对,则对Redis中缓存的键值对的value减1。
进一步的,所述若缓存有所述商家ID对应的键值对,则将Redis中缓存的键值对的value减1,包括:
判断Redis中缓存的键值对的value是否小于1;
若所述键值对的value小于1时,则不对Redis中缓存的键值对进行修改;若所述键值对的value不小于1时,则将value值减1。
第二方面,本发明实施例提供了一种轮询查询数据的装置,所述装置包括:
接收单元,用于服务器在接收用户提交的订单信息后,将所述订单信息保存至数据库中;
缓存单元,用于服务器获取所述订单信息中的商家ID,并根据所述商家ID更新对应商家的订单数,并将所述商家ID和订单数作为键值对缓存至Redis中,其中,将所述商家ID作为所述键值对的key,将所述订单数作为所述键值对的value;
第一判断单元,用于服务器在接收商家发送的订单查询请求后,根据所述商家对应的商家ID判断Redis中是否缓存有所述商家对应的键值对;
第二判断单元,用于如果Redis中缓存有所述商家对应的键值对,则判断所述键值对的value是否小于1;
返回单元,用于当所述value不小于1时,则继续查询数据库,并获取对应的订单信息,并将所述订单信息作为查询结果返回;当所述value小于1时,则直接结束查询流程;
结束单元,用于如果Redis中未缓存所述商家对应的键值对,则直接结束查询流程。
第三方面,本发明实施例提供了一种计算机设备,包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现上述的轮询查询数据的方法。
第四方面,本发明实施例提供了一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现上述的轮询查询数据的方法。
本发明实施例提供了一种轮询查询数据的方法、装置、计算机设备及存储介质。所述方法包括:服务器在接收用户提交的订单信息后,将所述订单信息保存至数据库中;服务器获取所述订单信息中的商家ID,并根据所述商家ID更新对应商家的订单数,并将所述商家ID和订单数作为键值对缓存至Redis中,其中,将所述商家ID作为所述键值对的key,将所述订单数作为所述键值对的value;服务器在接收商家发送的订单查询请求后,根据所述商家对应的商家ID判断Redis中是否缓存有所述商家对应的键值对;如果Redis中缓存有所述商家对应的键值对,则判断所述键值对的value是否小于1;当所述value不小于1时,则继续查询数据库,并获取对应的订单信息,并将所述订单信息作为查询结果返回;当所述value小于1时,则直接结束查询流程;如果Redis中未缓存所述商家对应的键值对,则直接结束查询流程。本发明实施例通过查询Redis中是否缓存有商家ID对应的键值对,判断数据库中是否存在有该商家ID对应的订单信息,从而确定是否继续对数据库进行查询,减少了数据库的查询次数,进而减小了数据库的访问压力,并且释放了数据库资源。
附图说明
为了更清楚地说明本发明实施例技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的一种轮询查询数据的方法的流程示意图;
图2为本发明实施例提供的一种轮询查询数据的装置的示意性框图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
应当理解,当在本说明书和所附权利要求书中使用时,术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在,但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
还应当理解,在此本发明说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本发明。如在本发明说明书和所附权利要求书中所使用的那样,除非上下文清楚地指明其它情况,否则单数形式的“一”、“一个”及“该”意在包括复数形式。
还应当进一步理解,在本发明说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合,并且包括这些组合。
下面请参见图1,图1为本发明实施例提供的一种轮询查询数据的方法的流程示意图,具体包括:步骤S101~S106。
S101、服务器在接收用户提交的订单信息后,将所述订单信息保存至数据库中;
本步骤中,当用户通过网上下单或者扫描二维码等方式向服务器提交一条订单信息时,服务器接收到用户提交的订单信息,并将该订单信息保存至数据库中。本实施例中,数据库用于保存每一个用户提交的订单信息,即数据库中可以保存不同用户提交的多条订单信息。
S102、服务器获取所述订单信息中的商家ID,并根据所述商家ID更新对应商家的订单数,并将所述商家ID和订单数作为键值对缓存至Redis中,其中,将所述商家ID作为所述键值对的key,将所述订单数作为所述键值对的value;
本实施例中,服务器一方面将用户提交的订单信息保存至数据库中,另一方面还将该订单信息缓存至Redis中。具体地,本步骤中,服务器首先获取该订单信息中的商家ID,然后根据该商家ID对与该商家对应的订单数进行更新(即将原有的订单数加1),并将商家ID作为键值对的key,将订单数作为键值对的value,最后将键值对key-value缓存至Redis中。在这里,商家ID即是指商家的唯一标识,这个标识可以指商家的名称、组织机构代码等,也可以指商家的联系方式、详细地址等。
在一实施例中,步骤S102包括:根据所述商家ID查询Redis中是否缓存有所述商家ID对应的键值对;若缓存有所述商家ID对应的键值对,则将键值对中的value加1;若未缓存所述商家ID对应的键值对,则在Redis中新增一个键值对,并将新增的键值对中的key设置为所述商家ID,value设置为1。
本实施例中,在将商家ID和订单数作为键值对缓存至Redis中之前,服务器首先根据商家ID对Redis进行查询,即查询Redis中是否缓存有该商家ID对应的键值对,以免在Redis中缓存有该商家ID对应的键值对的情况下,再次将同样的键值对缓存至Redis中。因此,当Redis中缓存有该商家ID对应的键值对时,即Redis中缓存有该商家ID和订单数的键值对,此时,由于用于表示订单数的value已经存在,因此只需要将value加1即可,即表示新增的这条订单信息保存至数据库中(即前述步骤S101保存的订单信息);当Redis中未缓存该商家ID对应的键值对时,也就是Redis中未缓存该商家ID对应的订单数,此时,可以在Redis中增加一个新的键值对,并将该商家ID作为新增的键值对的key,将订单数作为新增的键值对的value,此时,由于键值对是新增的,因此可将value设置为1,表示新增的这条订单信息保存至数据库中(即前述步骤S101保存的订单信息)。
S103、服务器在接收商家发送的订单查询请求后,根据所述商家对应的商家ID判断Redis中是否缓存有所述商家对应的键值对;
本步骤中,当商家向服务器发送订单查询请求后,服务器在接收的订单查询请求中获取该商家的商家ID,并根据获取的商家ID判断Redis中是否缓存有该商家ID对应的键值对。
S104、如果Redis中缓存有所述商家对应的键值对,则判断所述键值对的value是否小于1;
本步骤中,当Redis中缓存有所述商家对应的键值对时,则说明数据库中保存有该商家对应的订单信息,但是无法确定数据库中保存的该商家对应的订单信息是否已经被处理,因此可以通过判断Redis中缓存的键值对的value的大小来确定数据库中保存的该商家对应的订单信息是否被处理。
S105、当所述value不小于1时,则继续查询数据库,并获取对应的订单信息,并将所述订单信息作为查询结果返回;当所述value小于1时,则直接结束查询流程。
当Redis中缓存有所述商家对应的键值对且键值对的value等于1或者大于1时,则说明数据库中保存的该商家对应的订单信息中有一条或者多条订单信息还未被处理,因此可以继续对数据库进行查询,并在未被处理的一条或者多条订单信息中获取订单信息,并将获取的订单信息作为此次查询结果返回;当Redis中缓存有所述商家对应的键值对且键值对的value小于1时,则说明数据库中虽然保存有该商家对应的订单信息,但是这些订单信息已经全部被处理,因此无需继续对数据库进行查询,可以直接结束本次查询流程。
S106、如果Redis中未缓存所述商家对应的键值对,则直接结束查询流程。
本步骤中,如果Redis中未缓存该商家ID对应的键值对时,则说明数据库中未保存该商家ID对应的订单信息,从而不需要继续查询数据库,如此,可以减小数据库的访问压力。
本实施例中,通过将商家ID以及商家ID对应的订单数作为键值对缓存至Redis中,并通过查询Redis中是否缓存有商家ID对应的键值对,判断数据库中是否存在商家ID对应的未处理订单信息,从而确定是否需要对数据库进行访问,如此,减少了数据库的查询次数,避免了过多的无效轮询查询,进而减小了数据库的访问压力,并且释放数据库资源,使工作流程更为顺畅。另外,本实施例之所以选择Redis缓存键值对,是因为Redis缓存访问键值对的速度比数据库快几倍,而且Redis并发量更大,同时Redis还可以部署成集群形式,成为一个独立的应用。
在一实施例中,所述轮询查询数据的方法还包括:
当服务器接收到所述商家对所述订单信息的消费信息时,对所述数据库中相应的订单信息进行更新,以及将Redis中缓存的键值对的value减1。
本实施例中,当商家对查询到的订单信息进行消费后,即对查询到的订单信息进行处理后,服务器会接收到商家对订单信息的消费信息,然后服务器便会对数据库中保存的相应的订单信息进行更新,即将已经被消费(即已经被处理)的订单信息和未被消费(即未被处理)的订单信息区分开来,防止在下一次查询中返回已经被消费的订单信息。同时服务器还会对Redis中的数据进行修改,即将对应的键值对的value减1,也就是说商家消费了一条订单信息,那么相应地,Redis中缓存的键值对的value就要减1,即表示数据库中保存的未被处理的订单信息减少一条。也就是说,作为value的订单数是指还未被处理的订单信息的数量,因为当服务器在接收到一条新的订单信息后,value会相应的加1,当一条订单信息被处理后,value会相应的减1。
需要说明的是,本实施例中,在接收到订单信息的消费信息后,并不需要先对Redis中是否缓存有该商家对应的键值对进行判断,再确定是否对数据库中保存的相应的订单信息进行更新,因为商家已经对订单信息进行消费,即说明数据库中一定保存有该商家对应的订单信息,因此可以直接对数据库中保存的相应的订单信息进行更新。
在一实施例中,所述数据库中保存的订单信息包括:商家ID、订单号、订单状态和订单时间;所述当所述value不小于1时,则继续查询数据库,并获取对应的订单信息,并将所述订单信息作为查询结果返回,包括:当所述value值大于1时,则查询所述数据库,获取订单时间最早的订单信息,并将所述订单信息作为查询结果返回。
本实施例中,用户提交的订单信息包括多项内容,具体可以包括:商家ID、订单号、订单状态以及订单时间,当然订单信息中还可以包括其他内容,例如提交订单信息的用户联系方式等。当服务器根据商家ID查询到对应的键值对的value大于1时,即说明存在多条需要处理的订单信息,此时,可以根据订单信息中的订单时间选择本次查询的结果,也就是说,将订单时间最早的订单信息作为本次查询结果返回。进一步的,当存在订单时间相同的订单信息时,则随机选择其中一条订单信息作为查询结果返回。优选的,商家(即商家所处的PC端)每隔2秒钟进行一次订单信息查询,即商家每隔2秒钟向服务器发送一次订单查询请求,如此,可以避免因商家长时间不进行订单信息查询导致数据库中未处理的订单信息过多,也可以防止商家不间断的向服务器发送订单信息查询请求,导致其中一部分查询请求为无效请求,即未能查询到商家对应的订单信息。在一具体应用场景中,只有当商家登录订单信息查询***,才可以向服务器发送订单信息查询请求,如此,可以在商家不营业或者其他原因的情况下不对用户提供服务时,商家不会持续向服务器发送订单查询请求,服务器也不会持续向商家返回查询结果。
在一实施例中,所述当服务器接收到所述商家对所述订单信息的消费信息时,对所述数据库中相应的订单信息进行更新,以及将Redis中缓存的键值对的value减1,包括:将所述数据库中对应的订单信息中的订单状态标记为已处理。
本实施例中,当服务器对数据库中的订单信息进行更新时,可以将已经被消费的订单信息(即订单信息中包括的订单状态)标记为已处理,也就是说,将已经被消费的订单信息与未被消费的订单信息标记为不同的状态,防止在下一次商家向服务器发送订单信息查询请求时,服务器向商家返回已经被消费的订单信息。
在一实施例中,所述当服务器接收到所述商家对所述订单信息的消费信息时,对所述数据库中相应的订单信息进行更新,以及将Redis中缓存的键值对的value减1,还包括:
根据商家ID查询Redis中是否缓存有所述商家ID对应的键值对;
若未缓存所述商家ID对应的键值对,则不对Redis中的数据进行修改;
若缓存有所述商家ID对应的键值对,则对Redis中缓存的键值对的value减1。
本实施例中,首先根据商家ID查询Redis中是否缓存有该商家ID对应的键值对,如果Redis中未缓存该商家ID对应的键值对,即value不存在,则无需对Redis中的其他数据进行修改;如果Redis中缓存有该商家ID对应的键值对,即value存在,则可以对该键值对的value进行减1操作。
需要说明的是,在正常情况下,在服务器接收到商家对订单信息的消费信息后,是可以对Redis中缓存的键值对的value进行修改的,因为只有当value等于1或者大于1时,服务器才会将订单信息作为查询结果向商家返回,因此在未对Redis中的数据进行修改之前,该商家对应的键值对的value仍旧是等于1或者大于1的,因此当根据商家ID无法查询到对应的键值对时,则说明可能是服务器或者Redis缓存出现错误,或者是其他原因,导致无法查询到商家ID对应的键值对,最终无法对Redis中的数据进行修改。
在一具体实施例中,所述若缓存有所述商家ID对应的键值对,则将Redis中缓存的键值对的value减1,包括:
判断Redis中缓存的键值对的value是否小于1;
若所述键值对的value小于1时,则不对Redis中缓存的键值对进行修改;若所述键值对的value不小于1时,则将value值减1。
本实施例中,当确定Redis中缓存有商家ID对应的键值对时,首先判断该键值对的value的大小,即当value等于1或者大于1时,则可以将value减1,也就是说,数据库中存在一条或者多条未被处理的订单信息,此时这些未被处理订单信息中有一条已经被处理,则可以将Redis的订单数减1;当value小于1时,也就是说value等于0,即说明该商家ID对应的订单数为0,也就是说当前不存在未被处理的订单信息,因此无需对该键值对的value进行减1操作。需要说明的是,在本实施例中,在正常情况下,是可以对value进行减1操作的,因为只有当value等于1或者大于1(即Redis中缓存的订单数等于1或者大于1)时,服务器才会向商家返回订单信息,因此服务器在接收到商家对订单信息的消费信息时,对应的value是等于1或者大于1的,而此时,如果value小于1,即等于0时,则说明由于某种原因造成Redis缓存出现错误,或者是其他原因,最终导致无法对value进行减1操作。
在一实施例中,当Redis中缓存的键值对的value大于1时,则服务器对数据库进行查询,并获取数量与所述value大小相等的订单信息,并将所述订单信息作为查询结果返回。
本实施例中,当Redis中缓存的键值对的value大于1时,则说明数据库中未处理的订单信息的条数超过1条,因此,在商家向服务器发送订单查询请求时,服务器将未处理的订单信息全部作为查询结果返回,如此,可以减少商家向服务器发送订单查询请求的次数,提升订单处理效率。
进一步的,当Redis中缓存的键值对的value大于1且超过预设数量阈值时,则服务器在数据库中获取数量与预设数量阈值相等的订单信息,并将所述订单信息作为查询结果返回。本步骤中,当Redis中缓存的键值对的value大于1且超过预设数量阈值时,则说明当前数据库保存的未处理的订单信息数量过多,当商家向服务器发送订单查询请求时,服务器并不将未处理的订单信息全部作为查询结果返回,而是选择其中一部分(即数量等于预设数量阈值的订单信息)作为查询结果返回,这样做的好处是:避免服务器一次性返回订单信息数量过多,导致商家对查询到的订单信息处理混乱,反而降低对订单信息的处理效率。优选的,被获取的订单信息中的订单时间均早于未被获取的订单信息的订单时间。
在一实施例中,所述当所述value不小于1时,则继续查询数据库,并获取对应的订单信息,并将所述订单信息作为查询结果返回,包括:
当所述value值大于1时,则查询所述数据库,获取优先级最高的订单信息,并将所述订单信息作为查询结果返回。
本实施例与前述实施例的区别在于,前述实施例是返回订单时间最早的订单信息,而本实施例则是返回优先级最高的订单信息。至于订单信息的优先级,可以采用不同的方式来确定,例如按照订单信息中订单金额的高低、用户在对应商家的累积积分的高低、用户在对应商家的订单量的多少来确定。
在一具体应用场景中,可以查询所述数据库中未处理的所有订单信息的订单金额,将订单金额最高的订单信息的优先级设置为最高,所以此时可以将订单金额最高的订单信息作为查询结果返回。
在另一具体应用场景中,可以查询所述数据库中未处理的所有订单信息所对应的用户在该商家的累积积分,将累积积分最高的用户的订单信息的优先级设置为最高,假如该用户未处理的订单信息有多条,那么可以将其订单时间最早的一条订单信息作为查询结果返回;假如该用户未处理的订单信息仅有一条,那么可以直接将该订单信息作为查询结果返回。当然,也可以直接将该用户所有未处理的订单信息作为查询结果返回。
在另一具体应用场景中,可以查询所述数据库中未处理的所有订单信息所对应的用户在该商家的订单量,本应用场景中该订单量是指当前未处理的订单信息的数量,即比较所有用户未处理的订单信息的数量,将订单量最多的用户的订单信息的优先级设置为最高,显然,此处最高优先级的订单信息必然有多条,那么可以将其订单时间最早的一条订单信息作为查询结果返回。当然,也可以直接将该用户所有未处理的订单信息作为查询结果返回。
在另一具体应用场景中,可以查询所述数据库中未处理的所有订单信息所对应的用户在该商家的订单量,本应用场景中该订单量是用户在该商家的历史订单量,即比较所有用户在该商家的历史订单量,将历史订单量最多的用户的订单信息的优先级设置为最高,此时该用户未处理的订单信息的数量可能为1条,也可能为多条,在这种情况下,可以同样按照上述方式返回查询结果。
请参见图2,图2为本发明实施例提供的一种轮询查询数据的装置200的示意性框图,所述装置200包括:
接收单元201,用于服务器在接收用户提交的订单信息后,将所述订单信息保存至数据库中;
缓存单元202,用于服务器获取所述订单信息中的商家ID,并根据所述商家ID更新对应商家的订单数,并将所述商家ID和订单数作为键值对缓存至Redis中,其中,将所述商家ID作为所述键值对的key,将所述订单数作为所述键值对的value;
第一判断单元203,用于服务器在接收商家发送的订单查询请求后,根据所述商家对应的商家ID判断Redis中是否缓存有所述商家对应的键值对;
第二判断单元204,用于如果Redis中缓存有所述商家对应的键值对,则判断所述键值对的value是否小于1;
返回单元205,用于当所述value不小于1时,则继续查询数据库,并获取对应的订单信息,并将所述订单信息作为查询结果返回;当所述value小于1时,则直接结束查询流程;
结束单元206,用于如果Redis中未缓存所述商家对应的键值对,则直接结束查询流程。
在一实施例中,所述装置200还包括:
更新单元,用于当服务器接收到所述商家对所述订单信息的消费信息时,对所述数据库中相应的订单信息进行更新,以及将Redis中缓存的键值对的value减1。
在一实施例中,所述缓存单元202包括:
第一查询单元,用于根据所述商家ID查询Redis中是否缓存有所述商家ID对应的键值对;
加1单元,用于若缓存有所述商家ID对应的键值对,则将键值对中的value加1;
新增单元,用于若未缓存所述商家ID对应的键值对,则在Redis中新增一个键值对,并将新增的键值对中的key设置为所述商家ID,value设置为1。
在一实施例中,所述数据库中保存的订单信息包括:商家ID、订单号、订单状态和订单时间;所述返回单元205包括:
获取单元,用于当所述value值大于1时,则查询所述数据库,获取订单时间最早的订单信息,并将所述订单信息作为查询结果返回。
在一实施例中,所述更新单元包括:
标记单元,用于将所述数据库中对应的订单信息中的订单状态标记为已处理。
在一实施例中,所述更新单元还包括:
第二查询单元,用于根据商家ID查询Redis中是否缓存有所述商家ID对应的键值对;
未缓存单元,用于若未缓存所述商家ID对应的键值对,则不对Redis中的数据进行修改;
减1单元,用于若缓存有所述商家ID对应的键值对,则对Redis中缓存的键值对的value减1。
在一实施例中,所述减1单元包括:
第三判断单元,用于判断Redis中缓存的键值对的value是否小于1;
修改单元,用于若所述键值对的value小于1时,则不对Redis中缓存的键值对进行修改;若所述键值对的value不小于1时,则将value值减1。
由于装置部分的实施例与方法部分的实施例相互对应,因此装置部分的实施例请参见方法部分的实施例的描述,这里暂不赘述。
本发明实施例还提供了一种计算机可读存储介质,其上存有计算机程序,该计算机程序被执行时可以实现上述实施例所提供的步骤。该存储介质可以包括:U盘、移动硬盘、只读存储器(Read-OnlyMemory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
本发明实施例还提供了一种计算机设备,可以包括存储器和处理器,存储器中存有计算机程序,处理器调用存储器中的计算机程序时,可以实现上述实施例所提供的步骤。当然电子设备还可以包括各种网络接口,电源等组件。
说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。对于实施例公开的***而言,由于其与实施例公开的方法相对应,所以描述的比较简单,相关之处参见方法部分说明即可。应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以对本申请进行若干改进和修饰,这些改进和修饰也落入本申请权利要求的保护范围内。
还需要说明的是,在本说明书中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的状况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
Claims (10)
1.一种轮询查询数据的方法,其特征在于,包括:
服务器在接收用户提交的订单信息后,将所述订单信息保存至数据库中;
服务器获取所述订单信息中的商家ID,并根据所述商家ID更新对应商家的订单数,并将所述商家ID和订单数作为键值对缓存至Redis中,其中,将所述商家ID作为所述键值对的key,将所述订单数作为所述键值对的value;
服务器在接收商家发送的订单查询请求后,根据所述商家对应的商家ID判断Redis中是否缓存有所述商家对应的键值对;
如果Redis中缓存有所述商家对应的键值对,则判断所述键值对的value是否小于1;
当所述value不小于1时,则继续查询数据库,并获取对应的订单信息,并将所述订单信息作为查询结果返回;当所述value小于1时,则直接结束查询流程;
如果Redis中未缓存所述商家对应的键值对,则直接结束查询流程。
2.根据权利要求1所述的轮询查询数据的方法,其特征在于,还包括:
当服务器接收到所述商家对所述订单信息的消费信息时,对所述数据库中相应的订单信息进行更新,以及将Redis中缓存的键值对的value减1。
3.根据权利要求1所述的轮询查询数据的方法,其特征在于,所述服务器获取所述订单信息中的商家ID,并根据所述商家ID更新对应商家的订单数,并将所述商家ID和订单数作为键值对缓存至Redis中,包括:
根据所述商家ID查询Redis中是否缓存有所述商家ID对应的键值对;
若缓存有所述商家ID对应的键值对,则将键值对中的value加1;
若未缓存所述商家ID对应的键值对,则在Redis中新增一个键值对,并将新增的键值对中的key设置为所述商家ID,value设置为1。
4.根据权利要求1所述的轮询查询数据的方法,其特征在于,所述数据库中保存的订单信息包括:商家ID、订单号、订单状态和订单时间;所述当所述value不小于1时,则继续查询数据库,并获取对应的订单信息,并将所述订单信息作为查询结果返回,包括:
当所述value值大于1时,则查询所述数据库,获取订单时间最早的订单信息,并将所述订单信息作为查询结果返回。
5.根据权利要求2所述的轮询查询数据的方法,其特征在于,所述当服务器接收到所述商家对所述订单信息的消费信息时,对所述数据库中相应的订单信息进行更新,以及将Redis中缓存的键值对的value减1,包括:
将所述数据库中对应的订单信息中的订单状态标记为已处理。
6.根据权利要求2所述的轮询查询数据的方法,其特征在于,所述当服务器接收到所述商家对所述订单信息的消费信息时,对所述数据库中相应的订单信息进行更新,以及将Redis中缓存的键值对的value减1,还包括:
根据商家ID查询Redis中是否缓存有所述商家ID对应的键值对;
若未缓存所述商家ID对应的键值对,则不对Redis中的数据进行修改;
若缓存有所述商家ID对应的键值对,则对Redis中缓存的键值对的value减1。
7.根据权利要求6所述的轮询查询数据的方法,其特征在于,所述若缓存有所述商家ID对应的键值对,则将Redis中缓存的键值对的value减1,包括:
判断Redis中缓存的键值对的value是否小于1;
若所述键值对的value小于1时,则不对Redis中缓存的键值对进行修改;若所述键值对的value不小于1时,则将value值减1。
8.一种轮询查询数据的装置,其特征在于,包括:
接收单元,用于服务器在接收用户提交的订单信息后,将所述订单信息保存至数据库中;
缓存单元,用于服务器获取所述订单信息中的商家ID,并根据所述商家ID更新对应商家的订单数,并将所述商家ID和订单数作为键值对缓存至Redis中,其中,将所述商家ID作为所述键值对的key,将所述订单数作为所述键值对的value;
第一判断单元,用于服务器在接收商家发送的订单查询请求后,根据所述商家对应的商家ID判断Redis中是否缓存有所述商家对应的键值对;
第二判断单元,用于如果Redis中缓存有所述商家对应的键值对,则判断所述键值对的value是否小于1;
返回单元,用于当所述value不小于1时,则继续查询数据库,并获取对应的订单信息,并将所述订单信息作为查询结果返回;当所述value小于1时,则直接结束查询流程;
结束单元,用于如果Redis中未缓存所述商家对应的键值对,则直接结束查询流程。
9.一种计算机设备,其特征在于,包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现如权利要求1至7任一项所述的轮询查询数据的方法。
10.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的轮询查询数据的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911368300.4A CN111125138B (zh) | 2019-12-26 | 2019-12-26 | 一种轮询查询数据的方法、装置、计算机设备及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911368300.4A CN111125138B (zh) | 2019-12-26 | 2019-12-26 | 一种轮询查询数据的方法、装置、计算机设备及存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111125138A true CN111125138A (zh) | 2020-05-08 |
CN111125138B CN111125138B (zh) | 2023-08-25 |
Family
ID=70503229
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201911368300.4A Active CN111125138B (zh) | 2019-12-26 | 2019-12-26 | 一种轮询查询数据的方法、装置、计算机设备及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111125138B (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112380254A (zh) * | 2020-11-16 | 2021-02-19 | 华南理工大学 | 一种自动化设备的数据缓存***及方法 |
CN113283792A (zh) * | 2021-06-11 | 2021-08-20 | 上海寻梦信息技术有限公司 | 隐私信息的查询方法、装置、设备及存储介质 |
CN113742345A (zh) * | 2021-09-01 | 2021-12-03 | 南方电网深圳数字电网研究院有限公司 | 电力***数据的映射方法及装置 |
CN113792078A (zh) * | 2021-09-23 | 2021-12-14 | 小马国炬(重庆)科技有限公司 | 一种扫码响应方法、装置、设备及存储介质 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030167257A1 (en) * | 2002-01-18 | 2003-09-04 | De Bonet Jeremy S. | Multi-tiered caching mechanism for the storage and retrieval of content multiple versions |
WO2014048540A1 (en) * | 2012-09-27 | 2014-04-03 | Amadeus S.A.S. | Method and system of storing and retrieving data |
US20140164700A1 (en) * | 2012-12-10 | 2014-06-12 | Facebook, Inc. | System and method of detecting cache inconsistencies |
CN105139191A (zh) * | 2015-09-15 | 2015-12-09 | 联动优势电子商务有限公司 | 一种获取订单信息的方法及设备 |
CN106294607A (zh) * | 2016-07-29 | 2017-01-04 | 北京奇虎科技有限公司 | 缓存数据的更新方法及更新装置 |
CN110019255A (zh) * | 2017-07-31 | 2019-07-16 | 北京嘀嘀无限科技发展有限公司 | 数据查询方法、装置、服务器及存储介质 |
CN110019277A (zh) * | 2019-01-17 | 2019-07-16 | 阿里巴巴集团控股有限公司 | 一种数据累积的方法、数据查询的方法、装置及设备 |
-
2019
- 2019-12-26 CN CN201911368300.4A patent/CN111125138B/zh active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030167257A1 (en) * | 2002-01-18 | 2003-09-04 | De Bonet Jeremy S. | Multi-tiered caching mechanism for the storage and retrieval of content multiple versions |
WO2014048540A1 (en) * | 2012-09-27 | 2014-04-03 | Amadeus S.A.S. | Method and system of storing and retrieving data |
US20140164700A1 (en) * | 2012-12-10 | 2014-06-12 | Facebook, Inc. | System and method of detecting cache inconsistencies |
CN105139191A (zh) * | 2015-09-15 | 2015-12-09 | 联动优势电子商务有限公司 | 一种获取订单信息的方法及设备 |
CN106294607A (zh) * | 2016-07-29 | 2017-01-04 | 北京奇虎科技有限公司 | 缓存数据的更新方法及更新装置 |
CN110019255A (zh) * | 2017-07-31 | 2019-07-16 | 北京嘀嘀无限科技发展有限公司 | 数据查询方法、装置、服务器及存储介质 |
CN110019277A (zh) * | 2019-01-17 | 2019-07-16 | 阿里巴巴集团控股有限公司 | 一种数据累积的方法、数据查询的方法、装置及设备 |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112380254A (zh) * | 2020-11-16 | 2021-02-19 | 华南理工大学 | 一种自动化设备的数据缓存***及方法 |
CN113283792A (zh) * | 2021-06-11 | 2021-08-20 | 上海寻梦信息技术有限公司 | 隐私信息的查询方法、装置、设备及存储介质 |
CN113283792B (zh) * | 2021-06-11 | 2024-05-28 | 上海寻梦信息技术有限公司 | 隐私信息的查询方法、装置、设备及存储介质 |
CN113742345A (zh) * | 2021-09-01 | 2021-12-03 | 南方电网深圳数字电网研究院有限公司 | 电力***数据的映射方法及装置 |
CN113792078A (zh) * | 2021-09-23 | 2021-12-14 | 小马国炬(重庆)科技有限公司 | 一种扫码响应方法、装置、设备及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN111125138B (zh) | 2023-08-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111125138A (zh) | 一种轮询查询数据的方法、装置、计算机设备及存储介质 | |
CN106911780B (zh) | 业务id生成方法、装置及*** | |
CN108595207B (zh) | 一种灰度发布方法、规则引擎、***、终端和存储介质 | |
CN110609844B (zh) | 一种数据更新方法,装置及*** | |
CN108694075B (zh) | 处理报表数据的方法、装置、电子设备和可读存储介质 | |
CN108377247B (zh) | 一种消息推送方法和装置 | |
CN111797091A (zh) | 数据库中数据查询的方法、装置、电子设备和存储介质 | |
US10509716B2 (en) | Automated recovery of flighted features based on service requests | |
CN105808661A (zh) | 一种数据查询的方法及装置 | |
CN111367672A (zh) | 数据缓存方法、装置、电子设备及计算机存储介质 | |
CN113886494A (zh) | 即时通讯的消息存储方法、装置、设备及计算机可读介质 | |
CN110233843B (zh) | 一种用户请求的处理方法及装置 | |
CN110032578B (zh) | 一种海量数据查询缓存的方法及装置 | |
CN111586118A (zh) | 数据处理方法、装置和计算机设备 | |
CN113656178B (zh) | 数据处理方法、装置、设备及可读存储介质 | |
CN109063140A (zh) | 一种数据查询方法、中转服务器及计算机可读存储介质 | |
CN107332703B (zh) | 一种多应用日志的查看方法及装置 | |
CN111159131A (zh) | 性能优化方法、装置、设备及计算机可读存储介质 | |
CN101577873B (zh) | 彩信消息查询方法及装置 | |
CN113364830B (zh) | 一种长链接的缓存优化方法及*** | |
JP4575993B1 (ja) | リクエストを処理する情報処理装置、方法及びコンピュータプログラム | |
CN112187667B (zh) | 数据下载方法、装置、设备及存储介质 | |
CN106446080B (zh) | 数据查询的方法、查询服务设备、客户端设备和数据*** | |
CN111488370B (zh) | 列表分页快速响应***和方法 | |
CN112749190B (zh) | 数据查询方法、装置、计算设备及计算机存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |