CN108200180A - 一种用于限制请求频率的方法、装置及计算机设备 - Google Patents
一种用于限制请求频率的方法、装置及计算机设备 Download PDFInfo
- Publication number
- CN108200180A CN108200180A CN201810015270.8A CN201810015270A CN108200180A CN 108200180 A CN108200180 A CN 108200180A CN 201810015270 A CN201810015270 A CN 201810015270A CN 108200180 A CN108200180 A CN 108200180A
- Authority
- CN
- China
- Prior art keywords
- request
- user
- preset
- slot
- sends
- 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
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/62—Establishing a time schedule for servicing the requests
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Telephonic Communication Services (AREA)
Abstract
本发明提供了一种用于限制请求频率的方法、装置及计算机设备,方法包括:获取用户发送请求的第一时间戳及所述用户的用户标识中;判断限制请求频率的熔断机制是否启动,若确定熔断机制处于关闭状态时,确定第一时间戳的第一时间槽位slot;根据第一时间戳对应的第一slot及用户标识为用户在每个所述slot中生成唯一的第一发送请求标识key值;统计第一总时间段内第一key值的数量,第一总时间段包括每个第一slot对应的时间段;根据第一key值的数量判断用户在所述第一总时间段内发送的请求是否全部发送成功,若成功,则继续判断第一key值的数量是否超出第一阈值,若超出所述预设的第一阈值,则拒绝用户当前发送的请求。
Description
技术领域
本发明属于网络开发技术领域,尤其涉及一种用于限制请求频率的方法、装置及计算机设备。
背景技术
线上服务器经常会遇到请求量过高或接口被刷的情况,例如某个活动抽奖,会引来很多请求蜂拥而来。此时,一方面我们需要提高接口的性能,另一方面也需要对请求做一定的频率限制。
而目前主流限制请求频率的做法无法统计全局请求数据,只是针对单机的请求数据进行限制因此无法准确地限制对应客户端的请求频率。
发明内容
针对现有技术存在的问题,本发明实施例提供了一种用于限制请求频率的方法、装置及计算机设备,用于解决现有技术中在限用户的制请求频率时,没有统计到全局的请求频率,导致无法准确地限制客户端的请求频率的技术问题。
本发明实施例提供一种用于限制请求频率的方法,应用在直播平台上,所述方法包括:
获取用户发送请求的第一时间戳及所述用户的用户标识;
判断限制请求频率的熔断机制是否启动,若确定所述熔断机制处于关闭状态时,确定所述第一时间戳的第一时间槽位slot,所述第一slot包括多个,每个所述第一slot对应不同的时间段;
根据所述第一时间戳对应的第一slot及所述用户标识为所述用户在每个所述第一slot中生成唯一的第一发送请求标识key值,并将所述第一key值存储至预先建立的缓存器中;
统计所述第一总时间段内所述第一key值的数量,所述第一总时间段包括每个所述第一slot对应的时间段;
根据所述第一key值的数量判断所述用户在所述第一总时间段内发送的请求是否全部发送成功,若全部发送成功,则继续判断所述第一key值的数量是否超出预设的第一阈值,若所述第一key值的数量超出所述预设的第一阈值,则拒绝所述用户当前发送的请求。
上述方案中,确定所述熔断机制处于启动状态时,包括:
判断所述熔断机制的启动时间是否超出预设的启动时间,若确定所述熔断机制的启动时间确超出了预设的启动时间,则允许发送预设数量的请求,所述预设数量的请求的多个第二时间戳对应同一个第二slot;
确定多个所述第二时间戳对应的第二slot;
根据所述第二slot及当前用户的用户标识为所述当前用户在所述第二slot中生成第二key值;
根据预设的第二总时间段内所述第二key值的数量,判断所述当前用户在所述第二总时间段内发送的请求是否全部发送成功,若全部发送成功,则关闭所述熔断机制,并允许用户发送当前请求。
上述方案中,根据所述第一key值的数量判断所述用户在所述第一总时间段内发送的请求是否全部发送成功,若发送失败,包括:
统计所述第一总时间段内的发送失败率及连续失败的次数;
当确定所述发送失败率超出预设的发送失败率且所述连续失败的次数超出预设的第二阈值时,启动所述熔断机制,并基于令牌桶算法或漏桶算法统计所述用户在预设的第三总时间段内发送请求的总次数;
判断所述用户在预设的第三总时间段内发送请求的总次数是否超出了预设的第三阈值,若超出,则拒绝所述用户发送的请求。
上述方案中,判断所述当前用户在所述第二总时间段内发送的请求是否全部发送成功,若发送失败,包括:
基于令牌桶算法或漏桶算法统计所述用户在预设的第四总时间段内发送请求的总次数;
判断所述用户在预设的第四总时间段内发送请求的总次数是否超出了预设的第四阈值,若超出,则拒绝所述用户发送的请求。
本发明还提供一种用于限制请求频率的装置,所述装置包括:
获取单元,用于获取用户发送请求的第一时间戳及所述用户的用户标识;
第一判断单元,用于判断限制请求频率的熔断机制是否启动,若确定所述熔断机制处于关闭状态时,确定所述第一时间戳的第一时间槽位slot,所述第一slot包括多个,每个所述第一slot对应不同的时间段;
生成单元,用于根据所述第一时间戳对应的第一slot及所述用户标识为所述用户在每个所述第一slot中生成唯一的第一发送请求标识key值,并将所述第一key值存储至预先建立的缓存器中;
统计单元,用于统计所述第一总时间段内所述第一key值的数量,所述第一总时间段包括每个所述第一slot对应的时间段;
第二判断单元,用于根据所述第一key值的数量判断所述用户在所述第一总时间段内发送的请求是否全部发送成功,若全部发送成功,则继续判断所述第一key值的数量是否超出预设的第一阈值,若所述第一key值的数量超出所述预设的第一阈值,则拒绝所述用户当前发送的请求。
上述方案中,所述第一判断单元还用于:在确定所述熔断机制启动时,判断所述熔断机制的启动时间是否超出预设的启动时间,若确定所述熔断机制的启动时间确超出了预设的启动时间,则允许发送预设数量的请求,所述预设数量的请求的多个第二时间戳对应同一个第二slot;并确定多个所述第二时间戳对应的第二slot;
所述生成单元,还用于根据所述第二slot及当前用户的用户标识为所述当前用户在所述第二slot中生成第二key值;
所述第二判断单元,还用于根据预设的第二总时间段内所述第二key值的数量,判断所述当前用户在所述第二总时间段内发送的请求是否全部发送成功,若全部发送成功,则关闭所述熔断机制,并允许用户发送的当前请求。
上述方案中,所述第二判断单元具体用于:
在所述用户在所述第一总时间段内发送请求失败时,统计所述第一总时间段内的发送失败率及连续失败的次数;
当确定所述发送失败率超出预设的发送失败率且所述连续失败的次数超出预设的第二阈值时,启动所述熔断机制,并基于令牌桶算法或漏桶算法统计所述用户在预设的第三总时间段内发送请求的总次数;
判断所述用户在预设的第三总时间段内发送请求的总次数是否超出了预设的第三阈值,若超出,则拒绝所述用户发送的请求。
上述方案中,所述第二判断单元用于:
在所述当前用户在所述第二总时间段内发送的请求发送失败时,基于令牌桶算法或漏桶算法统计所述用户在预设的第四总时间段内发送请求的总次数;
判断所述用户在预设的第四总时间段内发送请求的总次数是否超出了预设的第四阈值,若超出,则拒绝所述用户发送的请求。
本发明还提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时能够执行如上述任一所述的方法。
本发明还提供一种限制请求频率的计算机设备,包括:
至少一个处理器;以及
与所述处理器通信连接的至少一个存储器,其中,
所述存储器存储有可被所述处理器执行的程序指令,所述处理器调用所述程序指令能够执行如上述任一所述的方法。
本发明提供了一种用于限制请求频率的方法、装置及计算机设备,所述方法包括:获取用户发送请求的第一时间戳及所述用户的用户标识;判断限制请求频率的熔断机制是否启动,若确定所述熔断机制处于关闭状态时,确定所述第一时间戳的第一时间槽位slot,所述第一slot包括多个,每个所述第一slot对应不同的时间段;根据所述第一时间戳对应的第一slot及所述用户标识为所述用户在每个所述slot中生成唯一的第一发送请求标识key值,并将所述第一key值存储至预先建立的缓存器中;统计所述第一总时间段内所述第一key值的数量,所述第一总时间段包括每个所述第一slot对应的时间段;根据所述第一key值的数量判断所述用户在所述第一总时间段内发送的请求是否全部发送成功,若全部发送成功,则继续判断所述第一key值的数量是否超出预设的第一阈值,若所述第一key值的数量超出所述预设的第一阈值,则拒绝所述用户当前发送的请求;如此,当有多个用户发送请求时,将每个用户在预设的第一总时间段内的第一key值存储至预先建立的缓存器中,可以对用户发送的请求次数做全局统计,这样与现有技术中单机统计的请求次数不同,全局统计可以记录到每个用户向各个单机服务器发送的总请求次数,而单机统计时只能统计到用户向自身发送的请求次数(导致统计的次数不准确),这样就可以准确地统计用每个用户在预设的第一总时间段内发送的总请求次数,进而可以准确地限制用户的请求频率。
附图说明
图1为本发明实施例一提供的用于限制请求频率的方法流程示意图;
图2为本发明实施例二提供的用于限制请求频率的装置结构示意图;
图3为本发明实施例三提供的用于限制请求频率的计算机设备结构示意图。
具体实施方式
为了解决现有技术中在限用户的制请求频率时,没有统计到全局的请求频率,导致无法准确地限制客户端的请求频率的技术问题,本发明提供了一种用于限制请求频率的方法、装置及计算机设备,所述方法包括:获取用户发送请求的第一时间戳及所述用户的用户标识;判断限制请求频率的熔断机制是否启动,若确定所述熔断机制处于关闭状态时,确定所述第一时间戳的第一时间槽位slot,所述第一slot包括多个,每个所述第一slot对应不同的时间段;根据所述第一时间戳对应的第一slot及所述用户标识为所述用户在每个所述第一slot中生成唯一的第一发送请求标识key值,并将所述第一key值存储至预先建立的缓存器中;统计所述第一总时间段内所述第一key值的数量,所述第一总时间段包括每个所述第一slot对应的时间段;根据所述第一key值的数量判断所述用户在所述第一总时间段内发送的请求是否全部发送成功,若全部发送成功,则继续判断所述第一key值的数量是否超出预设的第一阈值,若所述第一key值的数量超出所述预设的第一阈值,则拒绝所述用户当前发送的请求。
下面通过附图及具体实施例对本发明的技术方案做进一步的详细说明。
实施例一
本实施例提供一种用于限制请求频率的方法,如图1所示,所述方法包括:
S110,获取用户发送请求的第一时间戳及所述用户的用户标识;
本步骤中,获取用户发送请求的第一时间戳及所述用户的用户标识。其中,本实施例中的所述用户可以为多个用户,也可以只为一个用户。这样将用户的请求次数存储至缓存器中,可以准确统计出用户发送的请求次数。其中,所述用户标识为用户的互联网协议IP地址、用户在直播平台中的登陆账号ID或者用户使用的设备标识ID。每个用户在使用设备登陆直播平台时,直播平台都会为该设备生成一个唯一的设备ID。
比如,在第一总时间段内,用户向第一个服务器发送5次请求,向第二个服务器发送10次请求,那么缓存器记录的是用户共发送了15次请求。而基于单机统计时,是有每个服务器来记录用户向自身发送的请求次数,比如,第一个服务器记录的用户请求次数是5次,第二个服务器记录的请求次数是10次,这样的话就导致统计不准确,因此也无法准确限制用户的请求频率。
S111,判断限制请求频率的熔断机制是否启动,若确定所述熔断机制处于关闭状态时,执行步骤S112;当确定所述熔断机制处于启动状态时,则执行步骤S116~119。
S112,确定所述第一时间戳的第一时间槽位slot,所述第一slot包括多个,每个所述第一slot对应不同的时间段;
获取到第一时间戳后,判断限制请求频率的熔断机制是否启动,若确定所述熔断机制处于关闭状态时,表示此时使用的是基于全局统计的请求频率的限制机制,则确定所述第一时间戳的第一时间槽位slot,所述第一slot包括多个,每个所述第一slot对应不同的时间段,所述第一总时间段包括每个所述第一slot对应的时间段。这里,所述熔断机制是指当redis缓存或memcache缓存出现宕机时,本实施例可以继续进行单机请求频率的限制机制。
具体地,可以根据公式(1)确定所述第一slot:
slot=now/duration (1)
在公式(1)中,所述now为第一时间戳,所述duration为第一总时间段,;即所述slot为分片时间,比如第一总时间段为0~60s,那么以30s为一个slot的话,所述第一总时间段就可以分为0~30s及30~60s,相应地,所述第一slot就包括2个,分别为0~30s及30~60s。
当第一时间戳为20s时,那么第一时间戳对应的slot就为第一个slot。
S113,根据所述第一时间戳对应的第一slot及所述用户标识为所述用户在每个所述第一slot中生成唯一的第一发送请求标识key值;
当获取到第一时间戳对应的第一slot后,根据所述第一时间戳对应的第一slot及所述用户标识为所述用户在每个所述slot中生成唯一的第一发送请求标识key值,并将所述第一key值存储至预先建立的缓存器中,相当于将所述用户的在预设的第一总时间段内的请求次数存储至预先建立的缓存器中,所述预设的缓存器可以由redis数据库缓存或memcache缓存实现。
具体地,可根据公式(2)计算所述第一key值:
key=encrypt(用户标识+slot) (2)
所述公式(2)中的用户标识为用户的IP地址、用户在直播平台中的登陆ID或者用户使用的设备ID中的至少一个。所述encrypt为摘要加密算法,可以包括md5及sha1等算法。
这样就生成了第一key值,同样把第一key值存储在缓存器中。
S114,统计所述第一总时间段内所述第一key值的数量,根据所述第一key值的数量判断所述用户在所述第一总时间段内发送的请求是否全部发送成功;
第一key值生成之后,统计所述第一总时间段内所述第一key值的数量。同样,比如第一总时间段有两个slot,若用户在两个slot内发送的请求全部发送成功时,所述第一key值的数量就为2;若用户只有在第一个slot内发送的请求全部发送成功时,所述第一key值的数量就为1。
那么就根据所述第一key值的数量判断所述用户在所述第一总时间段内发送的请求是否全部发送成功。
S115,若全部发送成功,则继续判断所述第一key值的数量是否超出预设的第一阈值,若所述第一key值的数量超出所述预设的第一阈值,则拒绝所述用户的请求;
本步骤中,若用户在第一总时间段内发送的请求全部发送成功时,则继续判断所述第一key值的数量是否超出预设的第一阈值,若所述第一key值的数量超出所述预设的第一阈值,则说明该用户的请求频率已经超过发送限值,拒绝所述用户的请求。若所述第一key值的数量没有超出所述预设的第一阈值,则允许用户继续发送请求。所述第一阈值为预设的key值数量。
比如,若第一key值的数量为2,但是第一阈值中预设的key值数量为1,那么则表明用户的请求频率已经超过发送限值,拒绝所述用户当前发送的请求。
进一步地,若用户在第一总时间段内发送的请求没有全部发送成功时(部分发送成功时),统计所述第一总时间段内的发送失败率及连续失败的次数;
当确定所述发送失败率超出预设的发送失败率且所述连续失败的次数超出预设的第二阈值时,启动所述熔断机制,并基于令牌桶算法或漏桶算法统计所述用户在预设的第三总时间段内发送请求的总次数;比如,当发送失败率为60%以上,且连续失败的次数超过3次,就启动所述熔断机制。
另外,当确定所述发送失败率超出预设的发送失败率且所述连续失败的次数没有超出预设的第二阈值时,则暂时不启动熔断机制,继续统计发送失败率及连续发送失败的次数,直至发送失败率达到预设的失败率且连续发送失败的次数达到第三阈值,启动熔断机制。
然后判断所述用户在预设的第三总时间段内发送请求的总次数是否超出了预设的第三阈值,若超出,则拒绝所述用户发送的请求。比如第三总时间段为10s,第三阈值为10s内发送10次,若用户在10s内发送了20次,则说明用户在预设的第三总时间段内发送请求的总次数是否超出了预设的第三阈值,则拒绝用户当前发送的请求。
S116,判断所述熔断机制的启动时间是否超出预设的启动时间,若确定所述熔断机制的启动时间确超出了预设的启动时间,则允许发送预设数量的请求;
本步骤中,若熔断机制已开启,说明基于全局统计请求频率的限制机制可能出现宕机情况,此时使用的是基于单机请求频率的限制机制,那么判断所述熔断机制的启动时间是否超出预设的启动时间,若确定所述熔断机制的启动时间确超出了预设的启动时间,则允许发送预设数量的请求。
为了描述方便,假设所述预设数量的请求的多个第二时间戳对应同一个第二slot;当然,所述预设数量的请求的多个第二时间戳也可以对应不同的第二slot。
S117,然后确定多个所述第二时间戳对应的第二slot;具体的确定方法按照公式(1)确定即可,在此不再赘述。
S118,根据所述第二slot及当前用户的用户标识为所述当前用户在所述第二slot中生成第二key值;具体生成方式如上述公式(2)所述,在此也不再赘述。
S119,根据预设的第二总时间段内所述第二key值的数量,判断所述当前用户在所述第二总时间段内发送的请求是否全部发送成功,若全部发送成功,则说明基于全局统计请求频率的限制机制已经重新启动成功,则关闭所述熔断机制,并允许所述用户发送当前请求。这样的话,可以通过允许发送预设数量的请求来检测基于全局统计请求频率的限制机制是否已经重启,若重启,则继续使用基于全局统计请求频率的限制机制。
同样,所述当前用户在所述第二总时间段内发送的请求没有全部发送成功,则基于令牌桶算法或漏桶算法统计所述用户在预设的第四总时间段内发送请求的总次数;判断所述用户在预设的第四总时间段内发送请求的总次数是否超出了预设的第四阈值,若超出,则拒绝所述用户当前发送的请求。
实施例二
相应于实施例一,本实施例还提供一种用于限制请求频率的装置,如图2所示,所述装置包括:获取单元21、第一判断单元22、生成单元23、统计单元24及第二判断单元25;其中,
获取单元21用于获取用户发送请求的第一时间戳及所述用户的用户标识。
其中,本实施例中的所述用户可以为多个用户,也可以为一个用户。这样将用户的请求次数存储至缓存器中,可以准确统计出用户发送的请求次数。其中,所述用户标识为用户的互联网协议IP地址、用户在直播平台中的登陆账号ID或者用户使用的设备标识ID。每个用户在使用设备登陆直播平台时,直播平台都会为该设备生成一个唯一的设备ID。
比如,在第一总时间段内,用户向第一个服务器发送5次请求,向第二个服务器发送10次请求,那么缓存器记录的是用户共发送了15次请求。而基于单机统计时,是有每个服务器来记录用户向自身发送的请求次数,比如,第一个服务器记录的用户请求次数是5次,第二个服务器记录的请求次数是10次,这样的话就导致统计不准确,因此也无法准确限制用户的请求频率。
当获取到第一时间戳及用户标识后,第一判断单元22用于判断限制请求频率的熔断机制是否启动,若确定所述熔断机制处于关闭状态时,表示此时使用的是基于全局统计的请求频率的限制机制,则确定所述第一时间戳的第一时间槽位slot,所述第一slot包括多个,每个所述第一slot对应不同的时间段;所述第一总时间段包括每个所述第一slot对应的时间段。这里,所述熔断机制是指当redis缓存或memcache缓存出现宕机时,本实施例可以继续进行单机请求频率的限制机制。
具体地,可以根据公式(1)确定所述第一slot:
slot=now/duration (1)
在公式(1)中,所述now为第一时间戳,所述duration为第一总时间段,;即所述slot为分片时间,比如第一总时间段为0~60s,那么以30s为一个slot的话,所述第一总时间段就可以分为0~30s及30~60s,相应地,所述第一slot就包括2个,分别为0~30s及30~60s。
当第一时间戳为20s时,那么第一时间戳对应的slot就为第一个slot。
当获取到第一时间戳对应的第一slot后,生成单元23用于根据所述第一时间戳对应的第一slot及所述用户标识为所述用户在每个所述slot中生成唯一的第一发送请求标识key值,并将所述第一key值存储至预先建立的缓存器中,相当于将所述用户的在预设的第一总时间段内的请求次数存储至预先建立的缓存器中,所述预设的缓存器可以由redis数据库缓存或memcache缓存实现。
具体地,可根据公式(2)计算所述第一key值:
key=encrypt(用户标识+slot) (2)
所述公式(2)中的用户标识为用户的IP地址、用户在直播平台中的登陆ID或者用户使用的设备ID中的至少一个。所述encrypt为摘要加密算法,可以包括md5及sha1等算法。
这样就生成了第一key值,同样把第一key值存储在缓存器中。
第一key值生成之后,统计单元24用于统计所述第一总时间段内所述第一key值的数量;第二判断单元25用于根据所述第一key值的数量判断所述用户在所述第一总时间段内发送的请求是否全部发送成功,若全部发送成功,则继续判断所述第一key值的数量是否超出预设的第一阈值,若所述第一key值的数量超出所述预设的第一阈值,则拒绝所述用户的请求。
具体地,同样,比如第一总时间段有两个slot,若用户在两个slot内发送的请求全部发送成功时,所述第一key值的数量就为2;若用户只有在第一个slot内发送的请求全部发送成功时,所述第一key值的数量就为1。
那么就根据所述第一key值的数量判断所述用户在所述第一总时间段内发送的请求是否全部发送成功。
若用户在第一总时间段内发送的请求全部发送成功时,第二判断单元25则继续判断所述第一key值的数量是否超出预设的第一阈值,若所述第一key值的数量超出所述预设的第一阈值,则说明该用户的请求频率已经超过发送限值,拒绝所述用户的请求。若所述第一key值的数量没有超出所述预设的第一阈值,则允许用户继续发送请求。所述第一阈值为预设的key值数量。
比如,若第一key值的数量为2,但是第一阈值中预设的key值数量为1,那么则表明用户的请求频率已经超过发送限值,拒绝所述用户当前发送的请求。
进一步地,若第二判断单元25确定用户在第一总时间段内发送的请求没有全部发送成功时(部分发送成功时),统计所述第一总时间段内的发送失败率及连续失败的次数;
当确定所述发送失败率超出预设的发送失败率且所述连续失败的次数超出预设的第二阈值时,启动所述熔断机制,并基于令牌桶算法或漏桶算法统计所述用户在预设的第三总时间段内发送请求的总次数;比如,当发送失败率为60%以上,且连续失败的次数超过3次,就启动所述熔断机制。
另外,当确定所述发送失败率超出预设的发送失败率且所述连续失败的次数没有超出预设的第二阈值时,则暂时不启动熔断机制,继续统计发送失败率及连续发送失败的次数,直至发送失败率达到预设的失败率且连续发送失败的次数达到第三阈值,启动熔断机制。
然后第二判断单元25继续判断所述用户在预设的第三总时间段内发送请求的总次数是否超出了预设的第三阈值,若超出,则拒绝所述用户发送的请求。比如第三总时间段为10s,第三阈值为10s内发送10次,若用户在10s内发送了20次,则说明用户在预设的第三总时间段内发送请求的总次数是否超出了预设的第三阈值,则拒绝用户当前发送的请求。
另外,所述第一判断单元22还用于:在确定所述熔断机制启动时,判断所述熔断机制的启动时间是否超出预设的启动时间,若确定所述熔断机制的启动时间确超出了预设的启动时间,则允许发送预设数量的请求,所述预设数量的请求的多个第二时间戳对应同一个第二slot;为了描述方便,假设所述预设数量的请求的多个第二时间戳对应同一个第二slot,确定多个所述第二时间戳对应的第二slot;当然,所述预设数量的请求的多个第二时间戳也可以对应不同的第二slot。具体的确定方法按照公式(1)确定即可,在此不再赘述。
所述生成单元23还用于根据所述第二slot及当前用户的用户标识为所述当前用户在所述第二slot中生成第二key值;具体生成方式如上述公式(2)所述,在此也不再赘述。
所述第二判断单元25还用于根据预设的第二总时间段内所述第二key值的数量,判断所述当前用户在所述第二总时间段内发送的请求是否全部发送成功,若全部发送成功,则说明基于全局统计请求频率的限制机制已经重新启动成功,则关闭所述熔断机制,并允许所述用户发送当前请求。这样的话,可以通过允许发送预设数量的请求来检测基于全局统计请求频率的限制机制是否已经重启,若重启,则继续使用基于全局统计请求频率的限制机制。
同样,所述第二判断单元25还用于:当前用户在所述第二总时间段内发送的请求没有全部发送成功,则基于令牌桶算法或漏桶算法统计所述用户在预设的第四总时间段内发送请求的总次数;判断所述用户在预设的第四总时间段内发送请求的总次数是否超出了预设的第四阈值,若超出,则拒绝所述用户当前发送的请求。
实施例三
本实施例还提供一种用于限制请求频率的计算机设备,如图3所示,所述计算机设备包括:射频(Radio Frequency,RF)电路310、存储器320、输入单元330、显示单元340、音频电路350、WiFi模块360、处理器370、以及电源380等部件。本领域技术人员可以理解,图3中示出的计算机设备结构并不构成对计算机设备的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
下面结合图3对计算机设备的各个构成部件进行具体的介绍:
RF电路310可用于信号的接收和发送,特别地,将基站的下行信息接收后,给处理器370处理。通常,RF电路310包括但不限于至少一个放大器、收发信机、耦合器、低噪声放大器(Low Noise Amplifier,LNA)、双工器等。
存储器320可用于存储软件程序以及模块,处理器370通过运行存储在存储器320的软件程序以及模块,从而执行计算机设备的各种功能应用以及数据处理。存储器320可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序等;存储数据区可存储根据计算机设备的使用所创建的数据等。此外,存储器320可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
输入单元330可用于接收输入的数字或字符信息,以及产生与计算机设备的用户设置以及功能控制有关的键信号输入。具体地,输入单元330可包括键盘331以及其他输入设备332。键盘331,可收集用户在其上的输入操作,并根据预先设定的程式驱动相应的连接装置。键盘331采集到输出信息后再送给处理器370。除了键盘331,输入单元330还可以包括其他输入设备332。具体地,其他输入设备332可以包括但不限于触控面板、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。
显示单元340可用于显示由用户输入的信息或提供给用户的信息以及计算机设备的各种菜单。显示单元340可包括显示面板341,可选的,可以采用液晶显示器(LiquidCrystal Display,LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板341。进一步的,键盘331可覆盖显示面板341,当键盘331检测到在其上或附近的触摸操作后,传送给处理器370以确定触摸事件的类型,随后处理器370根据输入事件的类型在显示面板341上提供相应的视觉输出。虽然在图3中键盘331与显示面板341是作为两个独立的部件来实现计算机设备的输入和输入功能,但是在某些实施例中,可以将键盘331与显示面板341集成而实现计算机设备的输入和输出功能。
音频电路350、扬声器351,传声器352可提供用户与计算机设备之间的音频接口。音频电路350可将接收到的音频数据转换后的电信号,传输到扬声器351,由扬声器351转换为声音信号输出;
WiFi属于短距离无线传输技术,计算机设备通过WiFi模块360可以帮助用户收发电子邮件、浏览网页和访问流式媒体等,它为用户提供了无线的宽带互联网访问。虽然图3示出了WiFi模块360,但是可以理解的是,其并不属于计算机设备的必须构成,完全可以根据需要在不改变发明的本质的范围内而省略。
处理器370是计算机设备的控制中心,利用各种接口和线路连接整个计算机设备的各个部分,通过运行或执行存储在存储器320内的软件程序和/或模块,以及调用存储在存储器320内的数据,执行计算机设备的各种功能和处理数据,从而对计算机设备进行整体监控。可选的,处理器370可包括一个或多个处理单元;优选的,处理器370可集成应用处理器,其中,应用处理器主要处理操作系统、用户界面和应用程序等。
计算机设备还包括给各个部件供电的电源380(比如电源适配器),优选的,电源可以通过电源管理系统与处理器370逻辑相连。
本发明实施例提供的用于限制请求频率的方法、装置及计算机设备能带来的有益效果至少是:
本发明提供了一种用于限制请求频率的方法、装置及计算机设备,所述方法包括:获取用户发送请求的第一时间戳及所述用户的用户标识;判断限制请求频率的熔断机制是否启动,若确定所述熔断机制处于关闭状态时,确定所述第一时间戳的第一时间槽位slot,所述第一slot包括多个,每个所述第一slot对应不同的时间段;根据所述第一时间戳对应的第一slot及所述用户标识为所述用户在每个所述slot中生成唯一的第一发送请求标识key值,并将所述第一key值存储至预先建立的缓存器中;统计所述第一总时间段内所述第一key值的数量,所述第一总时间段包括每个所述第一slot对应的时间段;根据所述第一key值的数量判断所述用户在所述第一总时间段内发送的请求是否全部发送成功,若全部发送成功,则继续判断所述第一key值的数量是否超出预设的第一阈值,若所述第一key值的数量超出所述预设的第一阈值,则拒绝所述用户当前发送的请求;如此,当有多个用户发送请求时,将每个用户在预设的第一总时间段内的第一key值存储至预先建立的缓存器中,对用户发送的请求次数做全局统计,这样与现有技术中单机统计的请求次数不同,全局统计可以记录到每个用户向各个单机服务器发送的总请求次数,而单机统计时只能统计到用户向自身发送的请求次数(导致统计的次数不准确),这样就可以准确地统计用每个用户在预设的第一总时间段内发送的总请求次数,进而可以准确地限制用户的请求频率;另外,在基于全局统计请求频率的限制机制出现宕机的情况时,还可继续利用基于单机请求频率的限制机制对用户的请求频率进行限制,进而确保了业务高可用。
在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述,构造这类系统所要求的结构是显而易见的。此外,本发明也不针对任何特定编程语言。应当明白,可以利用各种编程语言实现在此描述的本发明的内容,并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
在此处所提供的说明书中,说明了大量具体细节。然而,能够理解,本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中,并未详细示出公知的方法、结构和技术,以便不模糊对本说明书的理解。
类似地,应当理解,为了精简本公开并帮助理解各个发明方面中的一个或多个,在上面对本发明的示例性实施例的描述中,本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而,并不应将该公开的方法解释成反映如下意图:即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说,如下面的权利要求书所反映的那样,发明方面在于少于前面公开的单个实施例的所有特征。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解,可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件,以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外,可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述,本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外,本领域的技术人员能够理解,尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征,但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如,在下面的权利要求书中,所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现,或者以在一个或者多个处理器上运行的软件模块实现,或者以它们的组合实现。本领域的技术人员应当理解,可以在实践中使用微处理器或者数字信号处理器(DSP,Digital Signal Processing)来实现根据本发明实施例的网关、代理服务器、系统中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如,计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读存储介质上,或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到,或者在载体信号上提供,或者以任何其他形式提供。应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制,并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中,不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中,这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
以上所述,仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围,凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等,均应包含在本发明的保护范围之内。
Claims (10)
1.一种用于限制请求频率的方法,其特征在于,应用在直播平台上,所述方法包括:
获取用户发送请求的第一时间戳及所述用户的用户标识;
判断限制请求频率的熔断机制是否启动,若确定所述熔断机制处于关闭状态时,确定所述第一时间戳的第一时间槽位slot,所述第一slot包括多个,每个所述第一slot对应不同的时间段;
根据所述第一时间戳对应的第一slot及所述用户标识为所述用户在每个所述第一slot中生成唯一的第一发送请求标识key值,并将所述第一key值存储至预先建立的缓存器中;
统计所述第一总时间段内所述第一key值的数量,所述第一总时间段包括每个所述第一slot对应的时间段;
根据所述第一key值的数量判断所述用户在所述第一总时间段内发送的请求是否全部发送成功,若全部发送成功,则继续判断所述第一key值的数量是否超出预设的第一阈值,若所述第一key值的数量超出所述预设的第一阈值,则拒绝所述用户当前发送的请求。
2.如权利要求1所述的方法,其特征在于,确定所述熔断机制处于启动状态时,包括:
判断所述熔断机制的启动时间是否超出预设的启动时间,若确定所述熔断机制的启动时间确超出了预设的启动时间,则允许发送预设数量的请求,所述预设数量的请求的多个第二时间戳对应同一个第二slot;
确定多个所述第二时间戳对应的第二slot;
根据所述第二slot及当前用户的用户标识为所述当前用户在所述第二slot中生成第二key值;
根据预设的第二总时间段内所述第二key值的数量,判断所述当前用户在所述第二总时间段内发送的请求是否全部发送成功,若全部发送成功,则关闭所述熔断机制,并允许用户发送当前请求。
3.如权利要求1所述的方法,其特征在于,根据所述第一key值的数量判断所述用户在所述第一总时间段内发送的请求是否全部发送成功,若发送失败,包括:
统计所述第一总时间段内的发送失败率及连续失败的次数;
当确定所述发送失败率超出预设的发送失败率且所述连续失败的次数超出预设的第二阈值时,启动所述熔断机制,并基于令牌桶算法或漏桶算法统计所述用户在预设的第三总时间段内发送请求的总次数;
判断所述用户在预设的第三总时间段内发送请求的总次数是否超出了预设的第三阈值,若超出,则拒绝所述用户发送的请求。
4.如权利要求2所述的方法,其特征在于,判断所述当前用户在所述第二总时间段内发送的请求是否全部发送成功,若发送失败,包括:
基于令牌桶算法或漏桶算法统计所述用户在预设的第四总时间段内发送请求的总次数;
判断所述用户在预设的第四总时间段内发送请求的总次数是否超出了预设的第四阈值,若超出,则拒绝所述用户发送的请求。
5.一种用于限制请求频率的装置,其特征在于,所述装置包括:
获取单元,用于获取用户发送请求的第一时间戳及所述用户的用户标识;
第一判断单元,用于判断限制请求频率的熔断机制是否启动,若确定所述熔断机制处于关闭状态时,确定所述第一时间戳的第一时间槽位slot,所述第一slot包括多个,每个所述第一slot对应不同的时间段;
生成单元,用于根据所述第一时间戳对应的第一slot及所述用户标识为所述用户在每个所述第一slot中生成唯一的第一发送请求标识key值,并将所述第一key值存储至预先建立的缓存器中;
统计单元,用于统计所述第一总时间段内所述第一key值的数量,所述第一总时间段包括每个所述第一slot对应的时间段;
第二判断单元,用于根据所述第一key值的数量判断所述用户在所述第一总时间段内发送的请求是否全部发送成功,若全部发送成功,则继续判断所述第一key值的数量是否超出预设的第一阈值,若所述第一key值的数量超出所述预设的第一阈值,则拒绝所述用户当前发送的请求。
6.如权利要求5所述的装置,其特征在于,所述第一判断单元还用于:在确定所述熔断机制启动时,判断所述熔断机制的启动时间是否超出预设的启动时间,若确定所述熔断机制的启动时间确超出了预设的启动时间,则允许发送预设数量的请求,所述预设数量的请求的多个第二时间戳对应同一个第二slot;并确定多个所述第二时间戳对应的第二slot;
所述生成单元,还用于根据所述第二slot及当前用户的用户标识为所述当前用户在所述第二slot中生成第二key值;
所述第二判断单元,还用于根据预设的第二总时间段内所述第二key值的数量,判断所述当前用户在所述第二总时间段内发送的请求是否全部发送成功,若全部发送成功,则关闭所述熔断机制,并允许用户发送的当前请求。
7.如权利要求5所述的装置,其特征在于,所述第二判断单元具体用于:
在所述用户在所述第一总时间段内发送请求失败时,统计所述第一总时间段内的发送失败率及连续失败的次数;
当确定所述发送失败率超出预设的发送失败率且所述连续失败的次数超出预设的第二阈值时,启动所述熔断机制,并基于令牌桶算法或漏桶算法统计所述用户在预设的第三总时间段内发送请求的总次数;
判断所述用户在预设的第三总时间段内发送请求的总次数是否超出了预设的第三阈值,若超出,则拒绝所述用户发送的请求。
8.如权利要求6所述的装置,其特征在于,所述第二判断单元用于:
在所述当前用户在所述第二总时间段内发送的请求发送失败时,基于令牌桶算法或漏桶算法统计所述用户在预设的第四总时间段内发送请求的总次数;
判断所述用户在预设的第四总时间段内发送请求的总次数是否超出了预设的第四阈值,若超出,则拒绝所述用户发送的请求。
9.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,该程序被处理器执行时能够执行如权利要求1至4任一所述的方法。
10.一种限制请求频率的计算机设备,其特征在于,包括:
至少一个处理器;以及
与所述处理器通信连接的至少一个存储器,其中,
所述存储器存储有可被所述处理器执行的程序指令,所述处理器调用所述程序指令能够执行如权利要求1至4任一所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810015270.8A CN108200180B (zh) | 2018-01-08 | 2018-01-08 | 一种用于限制请求频率的方法、装置及计算机设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810015270.8A CN108200180B (zh) | 2018-01-08 | 2018-01-08 | 一种用于限制请求频率的方法、装置及计算机设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN108200180A true CN108200180A (zh) | 2018-06-22 |
CN108200180B CN108200180B (zh) | 2020-09-08 |
Family
ID=62588211
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810015270.8A Active CN108200180B (zh) | 2018-01-08 | 2018-01-08 | 一种用于限制请求频率的方法、装置及计算机设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108200180B (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109992431A (zh) * | 2019-03-05 | 2019-07-09 | 福建天泉教育科技有限公司 | 一种实现重试的方法及终端 |
CN110737567A (zh) * | 2019-10-17 | 2020-01-31 | 吉旗(成都)科技有限公司 | 基于缓存的服务端接口熔断方法及装置 |
CN111556109A (zh) * | 2020-04-17 | 2020-08-18 | 北京达佳互联信息技术有限公司 | 请求处理方法、装置、电子设备和存储介质 |
CN111866156A (zh) * | 2020-07-27 | 2020-10-30 | 网易(杭州)网络有限公司 | 熔断处理方法及装置 |
CN113438177A (zh) * | 2021-06-22 | 2021-09-24 | 中国平安财产保险股份有限公司 | 限制号码外呼的方法及装置、电子设备、存储介质 |
WO2022134806A1 (zh) * | 2020-12-22 | 2022-06-30 | 深圳壹账通智能科技有限公司 | 热点key的确定方法、装置、设备及存储介质 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102083089A (zh) * | 2009-11-27 | 2011-06-01 | 中国移动通信集团山东有限公司 | 一种访问业务监控方法、系统及装置 |
CN102780603A (zh) * | 2011-05-11 | 2012-11-14 | 阿里巴巴集团控股有限公司 | 网站流量控制方法及装置 |
CN105138691A (zh) * | 2015-09-18 | 2015-12-09 | 北京百度网讯科技有限公司 | 分析用户业务量的方法和系统 |
CN105282047A (zh) * | 2015-09-25 | 2016-01-27 | 小米科技有限责任公司 | 访问请求处理方法及装置 |
US20170127104A1 (en) * | 2015-10-30 | 2017-05-04 | Rovi Guides, Inc. | Methods and systems for monitoring content subscription usage |
CN107220382A (zh) * | 2017-06-28 | 2017-09-29 | 环球智达科技(北京)有限公司 | 数据分析方法 |
CN107426181A (zh) * | 2017-06-20 | 2017-12-01 | 竞技世界(北京)网络技术有限公司 | 恶意Web访问请求的拦截方法及装置 |
-
2018
- 2018-01-08 CN CN201810015270.8A patent/CN108200180B/zh active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102083089A (zh) * | 2009-11-27 | 2011-06-01 | 中国移动通信集团山东有限公司 | 一种访问业务监控方法、系统及装置 |
CN102780603A (zh) * | 2011-05-11 | 2012-11-14 | 阿里巴巴集团控股有限公司 | 网站流量控制方法及装置 |
CN105138691A (zh) * | 2015-09-18 | 2015-12-09 | 北京百度网讯科技有限公司 | 分析用户业务量的方法和系统 |
CN105282047A (zh) * | 2015-09-25 | 2016-01-27 | 小米科技有限责任公司 | 访问请求处理方法及装置 |
US20170127104A1 (en) * | 2015-10-30 | 2017-05-04 | Rovi Guides, Inc. | Methods and systems for monitoring content subscription usage |
CN107426181A (zh) * | 2017-06-20 | 2017-12-01 | 竞技世界(北京)网络技术有限公司 | 恶意Web访问请求的拦截方法及装置 |
CN107220382A (zh) * | 2017-06-28 | 2017-09-29 | 环球智达科技(北京)有限公司 | 数据分析方法 |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109992431A (zh) * | 2019-03-05 | 2019-07-09 | 福建天泉教育科技有限公司 | 一种实现重试的方法及终端 |
CN110737567A (zh) * | 2019-10-17 | 2020-01-31 | 吉旗(成都)科技有限公司 | 基于缓存的服务端接口熔断方法及装置 |
CN111556109A (zh) * | 2020-04-17 | 2020-08-18 | 北京达佳互联信息技术有限公司 | 请求处理方法、装置、电子设备和存储介质 |
CN111866156A (zh) * | 2020-07-27 | 2020-10-30 | 网易(杭州)网络有限公司 | 熔断处理方法及装置 |
WO2022134806A1 (zh) * | 2020-12-22 | 2022-06-30 | 深圳壹账通智能科技有限公司 | 热点key的确定方法、装置、设备及存储介质 |
CN113438177A (zh) * | 2021-06-22 | 2021-09-24 | 中国平安财产保险股份有限公司 | 限制号码外呼的方法及装置、电子设备、存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN108200180B (zh) | 2020-09-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108200180A (zh) | 一种用于限制请求频率的方法、装置及计算机设备 | |
CN106130816B (zh) | 一种内容分发网络监控方法、监控服务器及系统 | |
CN104159159B (zh) | 基于视频的交互方法、终端、服务器及系统 | |
CN105119806B (zh) | 消息更新方法及装置 | |
CN105005909A (zh) | 预测流失用户的方法及装置 | |
CN104580167B (zh) | 一种传输数据的方法、装置和系统 | |
CN103634717B (zh) | 一种利用耳机控制的方法、装置及终端设备 | |
CN104679969A (zh) | 防止用户流失的方法及装置 | |
CN104822090A (zh) | 视频播放的方法、装置和系统 | |
CN104992342A (zh) | 推广信息投放有效性确定方法、监测服务器及终端 | |
CN105847325B (zh) | 应用客户端的调试方法及装置 | |
CN108572908B (zh) | 信息反馈方法及装置 | |
CN104580177B (zh) | 资源提供方法、装置和系统 | |
CN104598263A (zh) | 应用程序运行方法、配置文件生成方法和装置 | |
CN106294168B (zh) | 一种进行应用程序测试的方法和系统 | |
CN104735657B (zh) | 安全终端验证方法、无线接入点绑定方法、装置及系统 | |
CN105207880A (zh) | 群组推荐方法和装置 | |
CN108184148B (zh) | 一种用于识别用户的方法、装置及计算机设备 | |
CN104519262A (zh) | 获取视频数据的方法、装置及终端 | |
CN108089928A (zh) | 终端控制方法及装置 | |
CN104660769A (zh) | 一种添加联系人信息的方法、装置和系统 | |
CN104539597A (zh) | 多媒体数据推送方法及装置 | |
CN107122036A (zh) | 中央处理器频率调节方法及装置 | |
CN110442310A (zh) | 应用数据处理方法、装置、存储介质及终端设备 | |
CN105302589B (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 |