CN111752715A - 大量请求量下的***优化方法、装置、设备及存储介质 - Google Patents
大量请求量下的***优化方法、装置、设备及存储介质 Download PDFInfo
- Publication number
- CN111752715A CN111752715A CN202010609526.5A CN202010609526A CN111752715A CN 111752715 A CN111752715 A CN 111752715A CN 202010609526 A CN202010609526 A CN 202010609526A CN 111752715 A CN111752715 A CN 111752715A
- Authority
- CN
- China
- Prior art keywords
- requests
- request
- data
- preset
- accessed
- 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.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
- G06F9/5022—Mechanisms to release resources
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/544—Buffers; Shared memory; Pipes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/5018—Thread allocation
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明涉及区块链技术,公开了一种大量请求量下的***优化方法、装置、设备及存储介质,该方法通过获取第一数据量的第一请求,将所述第一请求中的类似请求进行合并,获得第二数据量的第二请求,所述第一数据量大于所述第二数据量,通过合并类似请求减少了请求量,降低了***压力;获取所述第二请求中访问目标资源的当前线程数量,在所述当前线程数量超过预设线程数时,控制所述预设线程数的线程对所述目标资源进行访问,基于基架运维,通过限流来保证***的稳定性,提高了大量请求量下的***反应速度和稳定性。其中,所述第一请求可存储于区块链中。
Description
技术领域
本发明涉及通信技术领域,尤其涉及一种大量请求量下的***优化方法、装置、设备及存储介质。
背景技术
高并发是***设计的时候必须要考虑的问题,如果在***设计阶段没有充分考虑,那么在实际使用过程中,一旦遇到请求量巨大的时候,***请求会反应缓慢,严重的时候会造成***崩溃。
现在很多***在设计方案的时候考虑高并发,通常采用多建集群和采用缓存的架构设计。但在实际使用过程中,集群并不是无限制的增加,在数据量巨大的情况下,常规的缓存设计很容易造成缓存穿透。因此,请求量过大时***反应慢,甚至导致***崩溃是亟待解决的技术问题。
上述内容仅用于辅助理解本发明的技术方案,并不代表承认上述内容是现有技术。
发明内容
本发明的主要目的在于提供一种大量请求量下的***优化方法、装置、设备及存储介质,旨在解决现有技术中请求量大时***反应慢的技术问题。
为实现上述目的,本发明提供一种大量请求量下的***优化方法,所述大量请求量下的***优化方法包括以下步骤:
获取第一数据量的第一请求;
将所述第一请求中的类似请求进行合并,获得第二数据量的第二请求,所述第一数据量大于所述第二数据量;
获取所述第二请求中访问目标资源的当前线程数量;
在所述当前线程数量超过预设线程数时,控制所述预设线程数的线程对所述目标资源进行访问。
优选地,在所述当前线程数量超过预设线程数时,控制所述预设线程数的线程对所述目标资源进行访问之后,所述大量请求量下的***优化方法还包括:
判断所述第二请求中是否存在访问目标缓存的第三请求;
在所述第二请求中存在所述第三请求时,从各所述第三请求中提取对应的待访问数据;
判断所述目标缓存中是否存在所述待访问数据;
在所述目标缓存中不存在所述待访问数据时,拒绝所述待访问数据对应的第三请求。
优选地,所述判断所述目标缓存中是否存在所述待访问数据,包括:
通过布隆过滤器判断所述目标缓存中是否存在所述待访问数据。
优选地,在所述判断所述目标缓存中是否存在所述待访问数据之前,还包括:
将待存储数据存储至所述目标缓存;
通过K个散列函数将所述待存储数据映射成一个位数组中的K个点,并把所述K个点设置为预设值,其中,K为大于等于1的整数;
所述判断所述目标缓存中是否存在所述待访问数据,包括:
查找所述待访问数据对应的k个点;
判断所述待访问数据对应的k个点是否均为所述预设值;
若所述待访问数据对应的k个点均为所述预设值,则认定所述目标缓存中存在所述待访问数据。
优选地,所述将所述第一请求中的类似请求进行合并,获得第二数据量的第二请求,包括:
计算各第一请求之间的相似度,将相似度超过预设相似度阈值的第一请求认定为类似请求,所述第一请求存储于区块链中;
将所述类似请求进行合并,获得第二数据量的第二请求。
优选地,所述将所述第一请求中的类似请求进行合并,获得第二数据量的第二请求之后,所述大量请求量下的***优化方法还包括:
将第二数据量的第二请求放入队列中,并初始化预设线程;
每隔预设时间读取所述队列中的第二请求,并根据读取的第二请求向目标数据库或目标***进行请求;
接收所述目标数据库或目标***返回的返回结果,并将所述返回结果通过所述预设线程传出;
在请求线程中阻塞性获取到所述返回结果。
优选地,所述控制所述预设线程数的线程对所述目标资源进行访问,包括:
通过信号量控制所述当前线程数量中预设线程数的线程连接所述目标资源。
此外,为实现上述目的,本发明还提出一种大量请求量下的***优化设备,所述大量请求量下的***优化设备包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的大量请求量下的***优化程序,所述大量请求量下的***优化程序配置为实现如上文所述的大量请求量下的***优化方法的步骤。
此外,为实现上述目的,本发明还提出一种存储介质,所述存储介质上存储有大量请求量下的***优化程序,所述大量请求量下的***优化程序被处理器执行时实现如上文所述的大量请求量下的***优化方法的步骤。
此外,为实现上述目的,本发明还提出一种大量请求量下的***优化装置,所述大量请求量下的***优化装置包括:
获取模块,用于获取第一数据量的第一请求;
合并模块,用于将所述第一请求中的类似请求进行合并,获得第二数据量的第二请求,所述第一数据量大于所述第二数据量;
所述获取模块,还用于获取所述第二请求中访问目标资源的当前线程数量;
访问模块,用于在所述当前线程数量超过预设线程数时,控制所述预设线程数的线程对所述目标资源进行访问。
本发明中,通过获取第一数据量的第一请求,将所述第一请求中的类似请求进行合并,获得第二数据量的第二请求,所述第一数据量大于所述第二数据量,通过合并类似请求减少了请求量,降低了***压力;获取所述第二请求中访问目标资源的当前线程数量,在所述当前线程数量超过预设线程数时,控制所述预设线程数的线程对所述目标资源进行访问,基于基架运维,通过限流来保证***的稳定性,提高了大量请求量下的***反应速度和稳定性。
附图说明
图1是本发明实施例方案涉及的硬件运行环境的大量请求量下的***优化设备的结构示意图;
图2为本发明大量请求量下的***优化方法第一实施例的流程示意图;
图3为本发明大量请求量下的***优化方法第二实施例的流程示意图;
图4为本发明大量请求量下的***优化方法第三实施例的流程示意图;
图5为本发明大量请求量下的***优化装置第一实施例的结构框图。
本发明目的的实现、功能特点及优点将结合实施例,参照附图做进一步说明。
具体实施方式
应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
参照图1,图1为本发明实施例方案涉及的硬件运行环境的大量请求量下的***优化设备结构示意图。
如图1所示,该大量请求量下的***优化设备可以包括:处理器1001,例如中央处理器(Central Processing Unit,CPU),通信总线1002、用户接口1003,网络接口1004,存储器1005。其中,通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display),可选用户接口1003还可以包括标准的有线接口、无线接口,对于用户接口1003的有线接口在本发明中可为USB接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如无线保真(WIreless-FIdelity,WI-FI)接口)。存储器1005可以是高速的随机存取存储器(Random Access Memory,RAM)存储器,也可以是稳定的存储器(Non-volatileMemory,NVM),例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。
本领域技术人员可以理解,图1中示出的结构并不构成对大量请求量下的***优化设备的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
如图1所示,作为一种计算机存储介质的存储器1005中可以包括操作***、网络通信模块、用户接口模块以及大量请求量下的***优化程序。
在图1所示的大量请求量下的***优化设备中,网络接口1004主要用于连接后台服务器,与所述后台服务器进行数据通信;用户接口1003主要用于连接用户设备;所述大量请求量下的***优化设备通过处理器1001调用存储器1005中存储的大量请求量下的***优化程序,并执行本发明实施例提供的大量请求量下的***优化方法。
基于上述硬件结构,提出本发明大量请求量下的***优化方法的实施例。
参照图2,图2为本发明大量请求量下的***优化方法第一实施例的流程示意图,提出本发明大量请求量下的***优化方法第一实施例。
在第一实施例中,所述大量请求量下的***优化方法包括以下步骤:
步骤S10:获取第一数据量的第一请求。
应理解的是,本实施例的执行主体是所述大量请求量下的***优化设备,其中,所述大量请求量下的***优化设备可为个人电脑或服务器等电子设备,本实施例对此不加以限制。所述第一数据量为超过百万的大数据量。所述第一请求为***涌入的各种请求,比如,查询请求和同步数据请求等,通常将大量的所述第一请求放入队列中。在***启动时以预设周期执行所述第一请求,比如以10ms为周期执行任务。
步骤S20:将所述第一请求中的类似请求进行合并,获得第二数据量的第二请求,所述第一数据量大于所述第二数据量。
可理解的是,在一个正常***中,总会有一些***查询特别频繁,比如查询个人信息等。在这种类似的请求过程中,可以将请求进行合并。可对各请求进行相似度计算,将相似度超过预设相似度阈值的请求认定为类似请求,将类似请求进行合并,从而降低一定的请求数据量。所述第二请求包括合并请求和未合并的第一请求。所述第一数据量和所述第二数据量均为超过百万的大数据量。
步骤S30:获取所述第二请求中访问目标资源的当前线程数量。
在具体实现中,所述目标资源包括数据库,为了避免所述目标资源的访问线程数过多,导致无法进行正常访问,可对所述第二请求中访问目标资源的线程数量进行控制,所述当前线程数量是指同时请求访问所述目标资源的线程数量。
步骤S40:在所述当前线程数量超过预设线程数时,控制所述预设线程数的线程对所述目标资源进行访问。
需要说明的是,在请求量巨大的情况下,一定要保证***的可用性。可限定访问流量,通过限流来保证***的稳定性。除了一般的物理限制之外,可用令牌算法来限流,控制所述预设线程数的线程对所述目标资源进行访问,超过所述预设线程数的线程先拒绝访问,在有进程访问完成,释放资源,再将资源分配给未访问的线程。所述预设线程数根据数据库的连接数进行设置,比如,数据库的连接数是10个,则所述预设线程数设置为10,控制10个线程同时获取数据库连接,并保存数据,否则会报错,导致无法获取数据库连接。
在本实施例中,通过获取第一数据量的第一请求,将所述第一请求中的类似请求进行合并,获得第二数据量的第二请求,所述第一数据量大于所述第二数据量,通过合并类似请求减少了请求量,降低了***压力;获取所述第二请求中访问目标资源的当前线程数量,在所述当前线程数量超过预设线程数时,控制所述预设线程数的线程对所述目标资源进行访问,基于基架运维,通过限流来保证***的稳定性,提高了大量请求量下的***反应速度和稳定性。
参照图3,图3为本发明大量请求量下的***优化方法第二实施例的流程示意图,基于上述图2所示的第一实施例,提出本发明大量请求量下的***优化方法的第二实施例。
在第二实施例中,在所述步骤S40之后,还包括:
步骤S50:判断所述第二请求中是否存在访问目标缓存的第三请求。
应理解的是,在请求量巨大的情况下,一旦遇到大量访问缓存中不存在的数据,就会瞬间造成数据库宕机。为了避免这种情况发生,可预先判断所述第二数据量的第二请求中是否存在访问所述目标缓存的所述第三请求。可通过提取所述第二请求的请求内容,根据所述请求内容判断是否为访问所述目标缓存的请求。
步骤S60:在所述第二请求中存在所述第三请求时,从各所述第三请求中提取对应的待访问数据。
可理解的是,因为数据库的请求连接数是有限的,一旦请求过多的时候,太多请求数据库,会造成数据库查询缓慢,严重的时候会造成数据库卡死。通常***会采用缓存,将读多写少的数据都写入缓存,以避免大部分请求连接数据库。在请求量巨大的情况下,一旦遇到大量访问到缓存不存在的数据就会瞬间造成数据库宕机。但是如果将数据库的数据全部放在缓存上,基本上不可能实现,存储数据占用的内存太大。可通过从各所述第三请求中提取对应的待访问数据,预先判断所述目标缓存中是否存储了所述待访问数据。
步骤S70:判断所述目标缓存中是否存在所述待访问数据。
需要说明的是,可采用布隆过滤器(bloom filter)判断需要访问的数据是否在缓存中,若所述待访问数据不在所述目标缓存中,则拒绝相应的访问请求,从而避免造成数据库宕机。在本实施例中,所述步骤S70,包括:通过布隆过滤器判断所述目标缓存中是否存在所述待访问数据。
步骤S80:在所述目标缓存中不存在所述待访问数据时,拒绝所述待访问数据对应的第三请求。
在具体实现中,首先判断所述目标缓存中是否存在请求需要访问的数据;若不存在,则拒绝对应的所述第三请求;若存在,则允许访问。避免不存在的时候还访问,造成数据库宕机,也避免不必要的数据访问,减少***压力。在本实施例中,在所述步骤S70之后,还包括:在所述目标缓存中存在所述待访问数据时,允许所述待访问数据对应的第三请求。
进一步地,在本实施例中,在所述步骤S70之前,还包括:
将待存储数据存储至所述目标缓存;
通过K个散列函数将所述待存储数据映射成一个位数组中的K个点,并把所述K个点设置为预设值,其中,K为大于等于1的整数;
相应地,所述步骤S70,包括:
查找所述待访问数据对应的k个点;
判断所述待访问数据对应的k个点是否均为所述预设值;
若所述待访问数据对应的k个点均为所述预设值,则认定所述目标缓存中存在所述待访问数据。
应理解的是,当一个存储数据被加入所述目标缓存时,通过K个散列函数将这个元素映射成一个位数组中的K个点,所述预设值为1,把K个点置为1。检索时,查看待访问数据对应的这些点是不是都是1,以判断集合中有没有它。如果这些点有任何一个0,则被检元素一定不在;如果都是1,则被检元素很可能在。
可理解的是,在使用bloom filter时,需要考量预估数据量n以及期望的误判率fpp,在实现bloom filter时,需要考量哈希(hash)函数的选取以及Bit数组的大小。对于一个确定的场景,预估要存的数据量为n,期望的误判率为fpp,然后需要计算需要的Bit数组的大小m,以及hash函数的个数k,并选择hash函数。Bit数组大小选择:根据预估数据量n以及误判率fpp,bit数组大小的m的计算方式:m=-nlnfpp/(ln)2,通过公式发现m的值越大,误判率就越低。可采用redis的位图(bitmap)来存放bloom filter的映射值。因为bitmap可以存放40多亿的bit,可以基本上满足绝大多数的***,大大降低bloom filter的误判率。
在本实施例中,通过判断所述第二请求中是否存在访问目标缓存的第三请求,在所述第二请求中存在所述第三请求时,从各所述第三请求中提取对应的待访问数据,判断所述目标缓存中是否存在所述待访问数据,在所述目标缓存中不存在所述待访问数据时,拒绝所述待访问数据对应的第三请求,从而避免访问缓存中不存在的数据造成数据库宕机。
参照图4,图4为本发明大量请求量下的***优化方法第三实施例的流程示意图,基于上述方法第一实施例或第二实施例,提出本发明大量请求量下的***优化方法的第三实施例。本实施例基于所述第一实施例进行说明。
在第三实施例中,所述步骤S20,包括:
步骤S201:计算各第一请求之间的相似度,将相似度超过预设相似度阈值的第一请求认定为类似请求,所述第一请求存储于区块链中。
应理解的是,可通过识别各所述第一请求的请求类型,将相同请求类型的第一请求进行相似度计算,所述请求类型包括查询请求和同步数据请求等,具体地,可通过提取各所述第一请求的请求内容,计算所述请求内容之间的相似度。所述预设相似度阈值可基于大数据分析而获得,将相似度超过预设相似度阈值的第一请求认定为类似请求。总会有一些***查询特别频繁,比如多个查询个人信息的第一请求可认定为类似请求。
需要强调的是,为进一步保证所述第一请求的私密和安全性,所述第一请求还可以存储于一区块链的节点中。
步骤S202:将所述类似请求进行合并,获得第二数据量的第二请求,所述第一数据量大于所述第二数据量。
可理解的是,将所述类似请求进行合并,从而降低一定的请求数据量。所述第二请求包括合并请求和未合并的第一请求。所述第一数据量和所述第二数据量均为超过百万的大数据量。
进一步地,在本实施例中,在所述步骤S20之后,还包括:
将第二数据量的第二请求放入队列中,并初始化预设线程;
每隔预设时间读取所述队列中的第二请求,并根据读取的第二请求向目标数据库或目标***进行请求;
接收所述目标数据库或目标***返回的返回结果,并将所述返回结果通过所述预设线程传出;
在请求线程中阻塞性获取到所述返回结果。
需要说明的是,在***涌入大量所述第二请求的时候,将所述第二请求的request放入队列中。所述预设线程为任务调度线程池(Scheduled Thread Pool)线程,在***启动的时候初始化一个Scheduled Thread Pool线程,以所述预设周期,比如10ms为周期地执行任务,线程的操作为:1.读取一次request队列,请求别的***或者数据库;2.拿到返回结果并返回给不同的请求。从Scheduled Thread返回出结果,需要用到CompletableFuture进行线程间的通信,将结果从Scheduled Thread线程中传出,在请求线程中需要阻塞性的拿到CompletableFuture传递的结果。
进一步地,在本实施例中,所述控制所述预设线程数的线程对所述目标资源进行访问,包括:
通过信号量控制所述当前线程数量中预设线程数的线程连接所述目标资源。
在具体实现中,信号量(Semaphore)是用来控制同时访问目标资源的线程数量,它通过协调各个线程,以保证合理的使用公共资源。比如数据库连接。假如有一个需求,要读取几万个文件的数据,因为都是IO密集型任务,所述当前线程数量可为几十个,可以启动几十个线程并发的读取,但是如果读到内存后,还需要存储到数据库中,所述预设线程数可以是10个,而数据库的连接数只有10个,则须控制只有10个线程同时获取数据库连接保存数据,否则会报错无法获取数据库连接,可使用Semaphore来做流控。
在本实施例中,通过计算各第一请求之间的相似度,将相似度超过预设相似度阈值的第一请求认定为类似请求,提高类似请求识别准确率;将所述类似请求进行合并,获得第二数据量的第二请求,通过合并类似请求减少了请求量,降低了***压力。
此外,本发明实施例还提出一种存储介质,所述存储介质上存储有大量请求量下的***优化程序,所述大量请求量下的***优化程序被处理器执行时实现如上文所述的大量请求量下的***优化方法的步骤。
此外,参照图5,本发明实施例还提出一种大量请求量下的***优化装置,所述大量请求量下的***优化装置包括:
获取模块10,用于获取第一数据量的第一请求。
应理解的是,所述第一数据量为超过百万的大数据量。所述第一请求为***涌入的各种请求,比如,查询请求和同步数据请求等,通常将大量的所述第一请求放入队列中。在***启动时以预设周期执行所述第一请求,比如以10ms为周期执行任务。
合并模块20,用于将所述第一请求中的类似请求进行合并,获得第二数据量的第二请求,所述第一数据量大于所述第二数据量。
可理解的是,在一个正常***中,总会有一些***查询特别频繁,比如查询个人信息等。在这种类似的请求过程中,可以将请求进行合并。可对各请求进行相似度计算,将相似度超过预设相似度阈值的请求认定为类似请求,将类似请求进行合并,从而降低一定的请求数据量。所述第二请求包括合并请求和未合并的第一请求。所述第一数据量和所述第二数据量均为超过百万的大数据量。
所述获取模块10,还用于获取所述第二请求中访问目标资源的当前线程数量。
在具体实现中,所述目标资源包括数据库,为了避免所述目标资源的访问线程数过多,导致无法进行正常访问,可对所述第二请求中访问目标资源的线程数量进行控制,所述当前线程数量是指同时请求访问所述目标资源的线程数量。
访问模块30,用于在所述当前线程数量超过预设线程数时,控制所述预设线程数的线程对所述目标资源进行访问。
需要说明的是,在请求量巨大的情况下,一定要保证***的可用性。可限定访问流量,通过限流来保证***的稳定性。除了一般的物理限制之外,可用令牌算法来限流,控制所述预设线程数的线程对所述目标资源进行访问,超过所述预设线程数的线程先拒绝访问,在有进程访问完成,释放资源,再将资源分配给未访问的线程。所述预设线程数根据数据库的连接数进行设置,比如,数据库的连接数是10个,则所述预设线程数设置为10,控制10个线程同时获取数据库连接,并保存数据,否则会报错,导致无法获取数据库连接。
在本实施例中,通过获取第一数据量的第一请求,将所述第一请求中的类似请求进行合并,获得第二数据量的第二请求,所述第一数据量大于所述第二数据量,通过合并类似请求减少了请求量,降低了***压力;获取所述第二请求中访问目标资源的当前线程数量,在所述当前线程数量超过预设线程数时,控制所述预设线程数的线程对所述目标资源进行访问,基于基架运维,通过限流来保证***的稳定性,提高了大量请求量下的***反应速度和稳定性。
在一实施例中,所述大量请求量下的***优化装置还包括:
判断模块,用于判断所述第二请求中是否存在访问目标缓存的第三请求;
提取模块,用于在所述第二请求中存在所述第三请求时,从各所述第三请求中提取对应的待访问数据;
所述判断模块,还用于判断所述目标缓存中是否存在所述待访问数据;
所述访问模块30,还用于在所述目标缓存中不存在所述待访问数据时,拒绝所述待访问数据对应的第三请求。
在一实施例中,所述判断模块,还用于通过布隆过滤器判断所述目标缓存中是否存在所述待访问数据。
在一实施例中,所述大量请求量下的***优化装置还包括:
存储模块,用于将待存储数据存储至所述目标缓存;
映射模块,用于通过K个散列函数将所述待存储数据映射成一个位数组中的K个点,并把所述K个点设置为预设值,其中,K为大于等于1的整数;
所述判断模块,还用于查找所述待访问数据对应的k个点;判断所述待访问数据对应的k个点是否均为所述预设值;若所述待访问数据对应的k个点均为所述预设值,则认定所述目标缓存中存在所述待访问数据。
在一实施例中,所述合并模块20,还用于计算各第一请求之间的相似度,将相似度超过预设相似度阈值的第一请求认定为类似请求,所述第一请求存储于区块链中;将所述类似请求进行合并,获得第二数据量的第二请求。
在一实施例中,所述大量请求量下的***优化装置还包括:
初始化模块,用于将第二数据量的第二请求放入队列中,并初始化预设线程;
读取模块,用于每隔预设时间读取所述队列中的第二请求,并根据读取的第二请求向目标数据库或目标***进行请求;
传出模块,用于接收所述目标数据库或目标***返回的返回结果,并将所述返回结果通过所述预设线程传出;
所述获取模块10,还用于在请求线程中阻塞性获取到所述返回结果。
在一实施例中,所述访问模块30,还用于通过信号量控制所述当前线程数量中预设线程数的线程连接所述目标资源。
本发明所述大量请求量下的***优化装置的其他实施例或具体实现方式可参照上述各方法实施例,此处不再赘述。
本发明所指区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain),本质上是一个去中心化的数据库,是一串使用密码学方法相关联产生的数据块,每一个数据块中包含了一批次网络交易的信息,用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。
需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者***不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者***所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者***中还存在另外的相同要素。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。在列举了若干装置的单元权利要求中,这些装置中的若干个可以是通过同一个硬件项来具体体现。词语第一、第二、以及第三等的使用不表示任何顺序,可将这些词语解释为标识。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如只读存储器镜像(Read Only Memory image,ROM)/随机存取存储器(Random AccessMemory,RAM)、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,空调器,或者网络设备等)执行本发明各个实施例所述的方法。
以上仅为本发明的优选实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本发明的专利保护范围内。
Claims (10)
1.一种大量请求量下的***优化方法,其特征在于,所述大量请求量下的***优化方法包括以下步骤:
获取第一数据量的第一请求;
将所述第一请求中的类似请求进行合并,获得第二数据量的第二请求,所述第一数据量大于所述第二数据量;
获取所述第二请求中访问目标资源的当前线程数量;
在所述当前线程数量超过预设线程数时,控制所述预设线程数的线程对所述目标资源进行访问。
2.如权利要求1所述的大量请求量下的***优化方法,其特征在于,在所述当前线程数量超过预设线程数时,控制所述预设线程数的线程对所述目标资源进行访问之后,所述大量请求量下的***优化方法还包括:
判断所述第二请求中是否存在访问目标缓存的第三请求;
在所述第二请求中存在所述第三请求时,从各所述第三请求中提取对应的待访问数据;
判断所述目标缓存中是否存在所述待访问数据;
在所述目标缓存中不存在所述待访问数据时,拒绝所述待访问数据对应的第三请求。
3.如权利要求2所述的大量请求量下的***优化方法,其特征在于,所述判断所述目标缓存中是否存在所述待访问数据,包括:
通过布隆过滤器判断所述目标缓存中是否存在所述待访问数据。
4.如权利要求2所述的大量请求量下的***优化方法,其特征在于,在所述判断所述目标缓存中是否存在所述待访问数据之前,还包括:
将待存储数据存储至所述目标缓存;
通过K个散列函数将所述待存储数据映射成一个位数组中的K个点,并把所述K个点设置为预设值,其中,K为大于等于1的整数;
所述判断所述目标缓存中是否存在所述待访问数据,包括:
查找所述待访问数据对应的k个点;
判断所述待访问数据对应的k个点是否均为所述预设值;
若所述待访问数据对应的k个点均为所述预设值,则认定所述目标缓存中存在所述待访问数据。
5.如权利要求1~4中任一项所述的大量请求量下的***优化方法,其特征在于,所述将所述第一请求中的类似请求进行合并,获得第二数据量的第二请求,包括:
计算各第一请求之间的相似度,将相似度超过预设相似度阈值的第一请求认定为类似请求,所述第一请求存储于区块链中;
将所述类似请求进行合并,获得第二数据量的第二请求。
6.如权利要求1~4中任一项所述的大量请求量下的***优化方法,其特征在于,所述将所述第一请求中的类似请求进行合并,获得第二数据量的第二请求之后,所述大量请求量下的***优化方法还包括:
将第二数据量的第二请求放入队列中,并初始化预设线程;
每隔预设时间读取所述队列中的第二请求,并根据读取的第二请求向目标数据库或目标***进行请求;
接收所述目标数据库或目标***返回的返回结果,并将所述返回结果通过所述预设线程传出;
在请求线程中阻塞性获取到所述返回结果。
7.如权利要求1~4中任一项所述的大量请求量下的***优化方法,其特征在于,所述控制所述预设线程数的线程对所述目标资源进行访问,包括:
通过信号量控制所述当前线程数量中预设线程数的线程连接所述目标资源。
8.一种大量请求量下的***优化装置,其特征在于,所述大量请求量下的***优化装置包括:
获取模块,用于获取第一数据量的第一请求;
合并模块,用于将所述第一请求中的类似请求进行合并,获得第二数据量的第二请求,所述第一数据量大于所述第二数据量;
所述获取模块,还用于获取所述第二请求中访问目标资源的当前线程数量;
访问模块,用于在所述当前线程数量超过预设线程数时,控制所述预设线程数的线程对所述目标资源进行访问。
9.一种大量请求量下的***优化设备,其特征在于,所述大量请求量下的***优化设备包括:存储器、处理器及存储在所述存储器上并可在所述处理器上运行的大量请求量下的***优化程序,所述大量请求量下的***优化程序被所述处理器执行时实现如权利要求1至7中任一项所述的大量请求量下的***优化方法的步骤。
10.一种存储介质,其特征在于,所述存储介质上存储有大量请求量下的***优化程序,所述大量请求量下的***优化程序被处理器执行时实现如权利要求1至7中任一项所述的大量请求量下的***优化方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010609526.5A CN111752715A (zh) | 2020-06-29 | 2020-06-29 | 大量请求量下的***优化方法、装置、设备及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010609526.5A CN111752715A (zh) | 2020-06-29 | 2020-06-29 | 大量请求量下的***优化方法、装置、设备及存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN111752715A true CN111752715A (zh) | 2020-10-09 |
Family
ID=72676615
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010609526.5A Pending CN111752715A (zh) | 2020-06-29 | 2020-06-29 | 大量请求量下的***优化方法、装置、设备及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111752715A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112184326A (zh) * | 2020-10-14 | 2021-01-05 | 深圳市欢太科技有限公司 | 处理高并发秒杀活动的方法、高并发***、终端及计算机可读存储介质 |
CN112485571A (zh) * | 2020-11-24 | 2021-03-12 | 上汽通用五菱汽车股份有限公司 | 标定方法、***、目标电器及存储介质 |
-
2020
- 2020-06-29 CN CN202010609526.5A patent/CN111752715A/zh active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112184326A (zh) * | 2020-10-14 | 2021-01-05 | 深圳市欢太科技有限公司 | 处理高并发秒杀活动的方法、高并发***、终端及计算机可读存储介质 |
CN112485571A (zh) * | 2020-11-24 | 2021-03-12 | 上汽通用五菱汽车股份有限公司 | 标定方法、***、目标电器及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN106610892B (zh) | 内存泄漏检测方法和装置 | |
US9563477B2 (en) | Performing concurrent rehashing of a hash table for multithreaded applications | |
US8996811B2 (en) | Scheduler, multi-core processor system, and scheduling method | |
CN109656779A (zh) | 内存监控方法、装置、终端和存储介质 | |
CN110188110B (zh) | 一种构建分布式锁的方法及装置 | |
US10049034B2 (en) | Information processing apparatus | |
CN108459913B (zh) | 数据并行处理方法、装置及服务器 | |
CN110134738B (zh) | 分布式存储***资源预估方法、装置 | |
JP3611295B2 (ja) | コンピュータシステム、メモリ管理方法及び記憶媒体 | |
US20240054128A1 (en) | Automatic database query load assessment and adaptive handling | |
CN111752715A (zh) | 大量请求量下的***优化方法、装置、设备及存储介质 | |
CN110222046B (zh) | 列表数据的处理方法、装置、服务器和存储介质 | |
CN114546590B (zh) | Java虚拟机堆内存集合对象监测方法及内存溢出分析方法 | |
CN110084476B (zh) | 案件调整方法、装置、计算机设备和存储介质 | |
CN112306383A (zh) | 执行作业的方法、计算节点、管理节点及计算设备 | |
CN111259299A (zh) | 数据处理方法、装置、计算机设备和存储介质 | |
US6931571B2 (en) | Method and apparatus for handling transient memory errors | |
CN110932935A (zh) | 资源控制方法、装置、设备及计算机存储介质 | |
CN115617553A (zh) | 一种数据库的熔断降级保护方法、装置及电子设备 | |
CN115114612A (zh) | 访问处理方法、装置、电子设备以及存储介质 | |
CN111143351B (zh) | Imsi数据管理方法及设备 | |
CN110222016B (zh) | 一种文件处理方法及装置 | |
CN109886327B (zh) | 一种分布式***中Java数据的处理***及方法 | |
WO2020140623A1 (zh) | 电子装置、元数据处理方法和计算机可读存储介质 | |
CN113419792A (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 |