CN113094378B - 数据处理方法、装置、电子设备和存储介质 - Google Patents
数据处理方法、装置、电子设备和存储介质 Download PDFInfo
- Publication number
- CN113094378B CN113094378B CN202110296791.7A CN202110296791A CN113094378B CN 113094378 B CN113094378 B CN 113094378B CN 202110296791 A CN202110296791 A CN 202110296791A CN 113094378 B CN113094378 B CN 113094378B
- Authority
- CN
- China
- Prior art keywords
- data
- cache
- database
- information acquisition
- cache data
- 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.)
- Active
Links
- 238000003672 processing method Methods 0.000 title claims abstract description 20
- 238000000034 method Methods 0.000 claims abstract description 64
- 238000012545 processing Methods 0.000 claims abstract description 52
- 230000004044 response Effects 0.000 claims description 23
- 238000012795 verification Methods 0.000 claims description 16
- 230000008569 process Effects 0.000 description 20
- 230000008859 change Effects 0.000 description 15
- 238000010586 diagram Methods 0.000 description 11
- 238000004891 communication Methods 0.000 description 10
- 238000007726 management method Methods 0.000 description 7
- 230000008520 organization Effects 0.000 description 7
- 238000005516 engineering process Methods 0.000 description 6
- 230000009471 action Effects 0.000 description 4
- 230000000694 effects Effects 0.000 description 4
- 230000003993 interaction Effects 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 230000005236 sound signal Effects 0.000 description 4
- 238000004590 computer program Methods 0.000 description 3
- 230000001133 acceleration Effects 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 2
- 230000003139 buffering effect Effects 0.000 description 2
- 238000013523 data management Methods 0.000 description 2
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 241000565357 Fraxinus nigra Species 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 238000003384 imaging method Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 230000008447 perception Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
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
- G06F16/2358—Change logging, detection, and notification
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
-
- 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
-
- 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/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/548—Queue
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Software Systems (AREA)
- Computational Linguistics (AREA)
- Quality & Reliability (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本公开关于数据处理方法、装置、电子设备和存储介质，所述方法包括：在确定数据库中保存的第一数据被更新为第二数据的情况下，生成对应于所述第二数据的第二缓存数据并将其存储在预设缓存中，所述预设缓存中还存储有对应于所述第一数据的第一缓存数据；在待响应的信息获取请求的数量超出数量阈值的情况下，使用所述第二缓存数据响应预设数量的所述信息获取请求，并使用所述第一缓存数据响应剩余的所述信息获取请求。该方案能够有效避免短时间内处理大量请求可能导致的缓存雪崩，一定程度上提升了数据库系统的运行稳定性。
Description
技术领域
本公开涉及数据处理领域，尤其涉及数据处理方法、装置、电子设备和存储介质。
背景技术
现阶段，网络电商、直播平台、数据管理平台等各类网络业务系统通常使用数据库(Database，DB)保存业务运行过程中的业务数据。在业务数据数量较多的情况下，为避免直接操作数据库可能导致的处理耗时长及数据库损害等问题，通常在网络业务系统和数据库之间设置缓存。
然而，在缓存中保存的缓存数据随着数据库中数据的更新而更新后，若缓存设备短时间内接收到大量信息获取请求，通常无法及时高效对请求进行处理。以商品定时抢购活动相关的项目为例，在删除抢购活动的相关人员在该项目中的权限数据后，若接收到该抢购活动相关的海量的商品抢购请求，由于此时缓存中并不存在上述权限数据，则会临时从数据库中多次拉取上述权限信息以响应商品抢购请求，从而导致数据库可能在短时间内接收到过多的信息拉取请求，甚至引发缓存雪崩，因此数据库系统的稳定较低。因此，如何避免请求导致的缓存雪崩，成为使用缓存时亟待解决的问题。
发明内容
本公开提供了数据处理方法、装置、电子设备和存储介质，以至少解决相关技术中的技术问题。本公开的技术方案如下：
根据本公开实施例的第一方面，提出一种数据处理方法，包括：
在确定数据库中保存的第一数据被更新为第二数据的情况下，生成对应于所述第二数据的第二缓存数据并将其存储在预设缓存中，所述预设缓存中还存储有对应于所述第一数据的第一缓存数据；
在待响应的信息获取请求的数量超出数量阈值的情况下，使用所述第二缓存数据响应预设数量的所述信息获取请求，并使用所述第一缓存数据响应剩余的所述信息获取请求。
可选的，还包括：
在待响应的信息获取请求的数量不超出所述数量阈值的情况下，使用所述第二缓存数据响应所述信息获取请求。
可选的，所述数量阈值包括：
预设的数量值；或者，
根据当前资源占用率和/或预测资源占用率确定出的最大请求处理数量。
可选的，所述在确定数据库中保存的第一数据被更新为第二数据的情况下，生成对应于所述第二数据的第二缓存数据，包括：
从消息队列中获取数据更新消息，所述数据更新消息对应于数据库中保存的第一数据被更新为第二数据的数据更新事件；
根据所述数据更新消息生成缓存更新事件；
对所述缓存更新事件进行幂等校验，并在校验通过的情况下，根据所述缓存更新事件生成对应于所述第二数据的第二缓存数据。
可选的，所述数据库包括MySQL数据库，所述数据更新消息被根据对应于所述数据更新事件的binlog日志文件生成。
可选的，所述第一缓存数据被分配有第一版本号，所述方法还包括：
为所述第二缓存数据分配区别于所述第一版本号的第二版本号，其中，所述第一版本号和第二版本号被分别用于查询所述第一缓存数据和第二缓存数据。
可选的，所述预设缓存包括redis缓存，所述第一缓存数据和第二缓存数据被按照哈希hash结构存储在所述redis缓存中。
可选的，所述第一缓存数据和第二缓存数据包括用户在多层级架构下的权限数据，所述hash结构所对应hash表的key字段用于记录对象层级、field字段用于记录用户标识、value字段用于记录用户权限。
可选的，还包括：
响应于获取到的数据更新消息，确定所述数据更新消息对应的目标用户标识；
通过查询所述第一缓存数据所对应hash表的field字段，将记录有所述目标用户标识的field字段所在的权限数据确定为待处理的目标权限数据；
根据所述数据更新消息指定的更新方式，更新所述目标权限数据。
可选的，还包括：
在所述第二缓存数据中未查询到用于响应任一信息获取请求的目标数据的情况下，向所述数据库发送数据获取请求；
根据所述数据库返回的所述目标数据更新所述第二缓存数据。
根据本公开实施例的第二方面，提出一种数据处理装置，包括：
生成及存储单元，被配置为在确定数据库中保存的第一数据被更新为第二数据的情况下，生成对应于所述第二数据的第二缓存数据并将其存储在预设缓存中，所述预设缓存中还存储有对应于所述第一数据的第一缓存数据；
第一响应单元，被配置为在待响应的信息获取请求的数量超出数量阈值的情况下，使用所述第二缓存数据响应预设数量的所述信息获取请求，并使用所述第一缓存数据响应剩余的所述信息获取请求。
可选的，还包括：
第二响应单元，被配置为在待响应的信息获取请求的数量不超出所述数量阈值的情况下，使用所述第二缓存数据响应所述信息获取请求。
可选的，所述数量阈值包括：
预设的数量值；或者，
根据当前资源占用率和/或预测资源占用率确定出的最大请求处理数量。
可选的，所述生成及存储模块还被配置为：
从消息队列中获取数据更新消息，所述数据更新消息对应于数据库中保存的第一数据被更新为第二数据的数据更新事件；
根据所述数据更新消息生成缓存更新事件；
对所述缓存更新事件进行幂等校验，并在校验通过的情况下，根据所述缓存更新事件生成对应于所述第二数据的第二缓存数据。
可选的，所述数据库包括MySQL数据库，所述数据更新消息被根据对应于所述数据更新事件的binlog日志文件生成。
可选的，还包括：
版本号分配单元，被配置为为所述第二缓存数据分配区别于所述第一版本号的第二版本号，其中，所述第一版本号和第二版本号被分别用于查询所述第一缓存数据和第二缓存数据。
可选的，所述预设缓存包括redis缓存，所述第一缓存数据和第二缓存数据被按照哈希hash结构存储在所述redis缓存中。
可选的，所述第一缓存数据和第二缓存数据包括用户在多层级架构下的权限数据，所述hash结构所对应hash表的key字段用于记录对象层级、field字段用于记录用户标识、value字段用于记录用户权限。
可选的，还包括：
标识确定单元，被配置为响应于获取到的数据更新消息，确定所述数据更新消息对应的目标用户标识；
数据确定单元，被配置为通过查询所述第一缓存数据所对应hash表的field字段，将记录有所述目标用户标识的field字段所在的权限数据确定为待处理的目标权限数据；
数据更新单元，被配置为根据所述数据更新消息指定的更新方式，更新所述目标权限数据。
根据本公开实施例的第三方面，提出一种电子设备，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现如上述第一方面中任一实施例所述的数据处理方法。
根据本公开实施例的第四方面，提出一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述第一方面中任一实施例所述的数据处理方法。
根据本公开实施例的第五方面，提供一种计算机程序产品，包括计算机程序和/或指令，所述计算机程序和/或指令被处理器执行时实现上述第一方面中任一实施例所述的数据处理方法。
本公开的实施例提供的技术方案至少带来以下有益效果：
根据本公开的实施例，在数据库中的数据被更新后，缓存设备相应的生成更新后的第二缓存数据，并将更新前的第一缓存数据作为第二缓存数据的备份数据，从而在接收到多个信息获取请求后，不仅能够使用第二缓存数据对其中一部分信息获取请求做出响应，还能够使用作为备份数据的第一缓存数据对剩余的信息获取请求做出响应，因此即便在短时间内接收到海量的信息获取请求，也能够实现对各个信息获取请求的有效响应，从而有效避免了缓存雪崩的发生，一定程度上提升了数据库系统的稳定性。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。
图1是一示例性实施例提供的一种数据处理系统的架构示意图；
图2是根据本公开的实施例示出的一种数据处理方法的流程图；
图3是根据本公开的实施例示出的一种多层级架构的示意图；
图4是根据本公开的实施例示出的一种缓存数据的存储方法示意图；
图5是根据本公开的实施例示出的一种缓存数据的更新方法流程图；
图6是根据本公开的实施例示出的一种缓存数据的请求响应方法的流程图；
图7是根据本公开的实施例示出的一种数据处理装置的示意框图；
图8是根据本公开的实施例示出的另一种数据处理装置的示意框图；
图9是根据本公开的实施例示出的一种电子设备的结构图。
具体实施方式
为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。
需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
现阶段，网络电商、直播平台、数据管理平台等各类网络业务系统通常使用数据库保存业务运行过程中的业务数据。在业务体量较小的情况下，直接操作数据库尚能支撑业务运行，然而随着业务不断扩张，网络业务系统产生的数据量也逐渐增多，此时继续采用直接操作数据库的方式对海量业务数据进行管理，将大大影响业务数据的处理能力甚至危及数据库安全。在业务数据数量较多的情况下，为避免直接操作数据库可能导致的处理耗时长及数据库损害等问题，通常在网络业务系统和数据库之间设置缓存。
然而，在缓存中保存的缓存数据随着数据库中数据的更新而更新后，若缓存设备短时间内接收到大量信息获取请求，通常无法及时高效对请求进行处理。以商品定时抢购活动相关的项目为例，在删除抢购活动的相关人员在该项目中的权限数据后，若接收到该抢购活动相关的海量的商品抢购请求，由于此时缓存中并不存在上述权限数据，则会临时从数据库中多次拉取上述权限信息以响应商品抢购请求，从而导致数据库可能在短时间内接收到过多的信息拉取请求，甚至引发缓存雪崩，因此数据库系统的稳定较低。因此，如何使用缓存中存储的数据对请求请求进行响应，以避免大量请求导致的缓存雪崩，成为使用缓存时亟待解决的问题。
以图1为例，图1是一示例性实施例提供的一种数据处理系统的架构示意图，该数据处理系统包括归属于网络业务系统的服务器等业务设备11、缓存设备12和数据库13，其中，业务数设备11通过缓存设备12连接至数据库13(当然，业务数设备11也可以与数据库13之间存在直接连接，图中并未示出)。业务设备11在处理业务过程中产生的新的业务数据可以被分别保存缓存设备12和数据库13中，通常情况下，缓存设备12中会保存经常被查询的业务数据(即高频业务数据)的缓存数据，即相当于将高频业务数据在缓存设备中进行备份。从而在业务设备11需要处理高频业务数据对应的高频业务时，可以将信息获取请求提交至缓存设备12，以由缓存设备12对信息获取请求进行处理，从而不仅大大加快了对信息获取请求的响应速度，而且能够有效避免大量请求直接被发送至数据库13可能导致的响应失败甚至数据库损坏。但是，当缓存设备中保存的某一缓存数据因超时、请求频率下降甚至人员误操作而被删除后，将无法实现对信息获取请求的阻挡，特别是在业务设备11需要在短时间内处理大量关于该缓存数据的请求的情况下，将导致大量请求被直接发送至数据库13等待响应，即出现缓存雪崩。
为此本公开提出一种数据处理方法，在数据库中的数据被更新后，通过缓存设备相应的生成更新后的第二缓存数据，并将更新前的第一缓存数据作为第二缓存数据的备份数据，从而在接收到的信息获取请求的数量超出预设数量的情况下，不仅使用第二缓存数据对其中预设数量的信息获取请求做出响应，还使用第一缓存数据作为备份数据对剩余的信息获取请求做出响应，从而能够在请求方无感知的情况下对短时间内接收到的海量信息获取请求进行响应，从而能够有效避免缓存雪崩，一定程度上提升了数据库系统的稳定性。
图2是根据本公开的实施例示出的一种数据处理方法的流程图。如图2所示，该方法应用于缓存设备，可以包括以下步骤202-204。
步骤202，在确定数据库中保存的第一数据被更新为第二数据的情况下，生成对应于所述第二数据的第二缓存数据并将其存储在预设缓存中，所述预设缓存中还存储有对应于所述第一数据的第一缓存数据。
在本实施例中，数据库中保存的第一数据和由第一数据更新得到的第二数可以为业务系统产生的业务数据，例如可以为用户在多层级架构下的权限数据、用户在不同时间线或不同业务窗口中的操作记录等。另外，上述预设缓存可以被部署于独立的缓存设备中，或者也可以被部署于数据库所在的存储设备中(此时该存储设备即为预设缓存所在的缓存设备)，如将数据库所在存储设备的内存作为预设缓存，本公开实施例并不对此进行限制。
其中，缓存设备可以通过多种方式确定上述第一数据被更新为第二数据。例如，因为数据库中的数据更新通常使用特定的更新关键字，因此缓存设备可以监听数据库的操作语句，并在监听到预设的更新关键字的情况下，进一步根据该关键字所在的命令语句确定相应的被更新数据(即第一数据)和更新后数据(即第二数据)。例如，在更新关键字为UPDATE的情况下，若监听到下述命令语句：
UPDATE user SET name＝'AA'WHERE name＝'aa'；
则缓存设备可以确定相应的第二数据为列名“AA”，进而可以在该语句执行前读取列名AA对应的第一数据，或者在该语句执行后解析相应的更新日志以确定相应的第一数据。当然，本公开实施例所述的“更新”并不限于上述关键词UPDATE对应的数据更新方式，而应当被理解为更广义的数据更新，即数据变化。如上述关键词还可以为新增数据、修改数据、移动数据位置、删除数据等，不再赘述。
又例如，上述存储设备也可以预先订阅关于数据库中第一数据的更新事件，从而能够在第一数据发生变化并产生相应的更新事件的情况下，获知到该更新事件，进而可以根据该更新事件确定相应的第二数据。
再例如，缓存设备还可以检查数据库的操作日志，进而通过解析操作日志中与数据变化相关的更新日志，确定相应的第一数据和第二数据，关于日志的具体解析方式可以参见相关技术中的记载，此处不再赘述。
在一实施例中，上述预设缓存可以为redis缓存，此时上述第一缓存数据和第二缓存数据均可以按照hash结构存储在该redis缓存中。该redis缓存的hash结构结构可以用于存储结构化数据，如用户id、昵称、头像、积分等数据。在hash结构下，任一数据存在相应的键值对(Key-Value)，其中，键值Key可以认为是该数据的索引(或标识)，而Value即为按照预定格式进行序列化处理后的具体数据。因此在修改已存储的某一缓存数据时，通过该数据的Key取出相应的Value，并对该Value进行反序列化得到具体的待修改数据，进而在修改该数据中某一项的具体值后，将修改后的数据序列化为新的Value并存储到Redis中相应位置(如原位置)即可，该方式在数据变动时对数据结构的改动最小(仅涉及到待修改数据所在的Value，无需改动其他数据)，从而保证了缓存数据的快速更新。另外，因为Hash结构会在单个Hash数据元素不足一定数据量时对缓存数据进行压缩存储，所以可以大量节约缓存设备的存储空间。
进一步的，上述第一缓存数据和第二缓存数据可以为用户在多层级架构下的权限数据，例如，在用户所在机构具有集团、分公司、部门、项目组等4级组织架构的情况下，上述第一数据(或者第二数据)可以为该用户在组织架构中的任一身份数据，如“a集团”、“b公司”、“c部门”或者“d1项目组”等，不再赘述。假设用户被从“d1项目组”人事调动至“d2项目组”，则数据库中保存的该用户所在组织架构中的“项目组”数据会被更新，相应的，更新前的第一数据为“d1项目组”，更新后的第二数据为“d2项目组”。其中，上述redis缓存中的hash结构所对应hash表的key字段可以用于记录对象层级、field字段可以用于记录用户标识、value字段可以用于记录用户权限。从而通过上述hash结构能够通过一个key值相应的存储多条用户权限，即实现对用户权限的结构化存储，有助于实现对用户权限的快速存储、轻便更改和快速查找。
进一步的，在hash结构下，可以利用hash结构的field字段更新权限数据。例如，可以响应于获取到的数据更新消息，确定数据更新消息对应的目标用户标识，然后通过查询第一缓存数据所对应hash表的field字段，将记录有目标用户标识的field字段所在的权限数据确定为待处理的目标权限数据，再根据上述数据更新消息指定的更新方式，更新目标权限数据。通过该方式能够利用field字段，确保在hash结构下实现对多级权限数据的准确定位和有效更新。
当然，上述预设缓存也可以为分布式的Memcached缓存，甚至服务器本地的localCache缓存等(此时，上述业务设备11与缓存设备12可以位于同一物理设备中)。另外，上述数据库可以为MySQL、SqlServe、Oracler等关系型数据库(Structured QueryLanguage，SQL)，也可以为Cassandra、MongoDB、CouchDB等非关系型数据库(Not only SQL，NoSQL)，本公开实施例并不对此进行限制。
在一实施例中，缓存设备可以为其保存的任一更新前后的缓存数据分别分配唯一的版本号。例如，在为第一缓存数据预先分配第一版本号的情况下，可以在根据第一缓存数据生成第二缓存数据后，基于第一版本号为第二缓存数据分配第二版本号，其中，上述第一版本号和第二版本号可以被分别用于查询第一缓存数据和第二缓存数据。因为第二缓存数据被根据第一缓存数据生成，所以可以将第二缓存数据作为第一缓存数据在变更前的数据快照，进而在查询第一缓存数据和第二缓存数据时可以根据相应的版本号实现快速查询。而且，通过上述版本号的依次更新，能够实现对缓存数据变更记录的回溯，因此对于任一时刻的最新版本缓存数据(即第二缓存数据)来说，始终存在其对应的前一版本缓存数据(即第一缓存数据)作为其备份数据，从而能够同时使用最新版本缓存数据和其前一版本缓存数据保证在请求数量超限时针对请求的正常响应。
在一实施例中，可以通过下述方式生成第二缓存数据：从消息队列中获取数据更新消息，该数据更新消息对应于数据库中保存的第一数据被更新为第二数据的数据更新事件，然后根据数据更新消息生成缓存更新事件，并基于该缓存更新事件生成对应于第二数据的第二缓存数据。通过上述消息队列能够保证任一数据更新事件对应的数据更新消息均能够被缓存设备获取到，进而可靠生成第二缓存数据。
另外，为避免同一数据更新事件(如多人对同一数据进行的多次相同操作)可能产生的多个数据更新消息导致对缓存数据的多次重复更新，可以对接收到的任一缓存更新事件进行幂等校验，若该缓存更新事件通过幂等校验，则表明该缓存更新事件对应的第一缓存数据尚未被更新，所以此时可以基于该缓存更新事件生成对应于第二数据的第二缓存数据。通过该方式，可以保证多个相同的数据更新事件对应的第一缓存数据仅被更新一次，即获得一份第二缓存数据，从而通过避免数据被重复更新，减少设备的数据处理压力。具体的，上述幂等校验可以通过token限流、悲观/乐观锁、状态机幂等多种方式实现，具体实现方式可以参见相关技术中记载的内容，此处不再赘述。
进一步的，在上述数据库为MySQL数据库的情况下，上述数据更新消息可以被根据对应于数据更新事件的binlog日志文件生成。具体的，MySQL数据库中发生上述数据更新事件后，会产生相应的binlog日志文件，此时可以通过maxwell等日志解析器对该binlog日志文件进行解析，进而将解析得到的数据变更信息包含在缓存更新消息中(直接或通过消息队列)发送至上述缓存设备或其管理设备，进而缓存设备或其管理设备可以基于该消息中的数据变更信息生成相应的第二缓存数据。通过解析binlog日志文件的方式，能够保证MySQL数据库中发生的数据更新事件均会被缓存设备或其管理设备感知到，进而做出相应处理，避免缓存更新事件被遗漏。
步骤204，在待响应的信息获取请求的数量超出数量阈值的情况下，使用所述第二缓存数据响应预设数量的所述信息获取请求，并使用所述第一缓存数据响应剩余的所述信息获取请求。
在一实施例中，为加快数量阈值的确定速度，上述数量阈值可以为预设的数量值，如10000、150000等。当然，该数值可以根据缓存设备的自身数据处理能力进行确定，本公开实施例并不对此进行限制。例如可以根据缓存设备的历史工作记录确定该设备的峰值请求处理数量，如在预先设置CUP占用率上限为90％的情况下，若历史工作记录表明缓存设备平均在100000TPS(Transactions Per Second，每秒传输数量)的情况下CUP占用率达到90％，则可以设置该设备的数量阈值为100000。
或者，上述数量阈值也可以为根据当前资源占用率和/或预测资源占用率确定出的最大请求处理数量。例如，可以预先确定缓存设备的资源总量，并根据该资源总量确定设备的当前资源占用率，或者根据当前资源占用率和当前待响应的信息获取请求数量预测设备在预设时间段后的预测资源占用率，进而可以基于上述当前资源占用率和/或预测资源占用率确定出当前时刻或预设时间段后的最大请求处理数量，并将该最大请求处理数量确定为上述数量阈值，以实现对缓存设备的负载调节，以避免请求响应失败。
例如，缓存设备可以根据自身的历史工作记录确定该设备处理任一请求的平均处理时长以及平均资源占用率。以缓存设备的CPU占用率不超出90％(即缓存设备的资源总量为CUP占用率等于90％)为例，假设任一请求的平均处理时长为5ms、平均资源占用率为0.01％，则缓存设备同一时刻最多可以同时响应90％/0.01％＝9000个请求。若当前时刻的当前CPU占用率为60％，且缓存设备已经接受到的待响应的信息获取请求数量为20000个，则因为缓存设备同时响应3000个请求即需要占用30％的CPU占用率，而且5ms后剩余17000(大于9000)个请求尚未被执行，所以5ms(即预设时长)后的预测CPU占用率为90％，进而可以设置数量阈值为9000。当然，确定上述平均处理时长以及平均资源占用率时，可以根据请求类型、请求对应的待处理数据的数据量等对历史工作记录对应的历史处理请求进行分类，并针对不同类别分别确定相应的平均处理时长以及平均资源占用率，以便预测出更精确资源占用率。
在一实施例中，在上述待响应的信息获取请求的数量不超出上述数量阈值的情况下，可以通过查询第二缓存数据响应当前时刻的信息获取请求。可见，在待响应的信息获取请求的数量S不超出数量阈值S0(即S≤S0)时，仅使用第二缓存数据即可对全部S个信息获取请求作出响应；而在待响应的信息获取请求的数量S超出数量阈值S0(即S>S0)时，使用第二缓存数据已无法对全部信息获取请求作出响应，此时可以使用上述第二缓存数据对全部S个信息获取请求中的S0个请求做出响应，而使用第一缓存数据对其余的S-S0个请求做出响应，从而保证全部S个请求均得到正常响应。可以理解的是，该方案是通过将第一缓存数据作为第二缓存数据的备用数据对请求进行响应：在请求过多的情况下，虽然部分请求(如上述S-S0个)被使用实时性较差(更新前的数据信息较为滞后)的第二缓存数据进行响应，但是客户端侧的展示结果也要优于将这部分请求全部驳回至请求方(如直接向请求方返回请求失败消息)，从而一定程度上避免了这部分请求方所对应用户对请求的驳回感知。特别是在第一缓存数据与第二缓存数据差异较小(即第二数据相对于第一数据仅发生极小部分变化)的情况下，对上述超量请求的处理时效性更加明显。
在一实施例中，在针对任一信息获取请求进行响应的过程中，若在第二缓存数据中未查询到用于响应任一信息获取请求的目标数据，则可以向数据库发送数据获取请求，并根据数据库响应于该数据获取请求返回的目标数据更新第二缓存数据，从而保证后续请求能够使用该更新后的第二缓存数据进行响应。另外，还可以使用上述目标数据或对第二缓存数据进行更新后的数据(如第三缓存数据)响应上述任一信息获取请求，从而保证对任一信息获取请求都能够及时作出响应。
根据本公开的实施例，在数据库中的数据被更新后，缓存设备相应的生成更新后的第二缓存数据，并将更新前的第一缓存数据作为(新生成的)第二缓存数据的备份数据，从而在接收到多个信息获取请求后，不仅能够使用第二缓存数据对其中一部分信息获取请求做出响应，还能够使用作为备份数据的第一缓存数据对剩余的信息获取请求做出响应，从而即便在短时间内接收到海量的信息获取请求，也能够实现对各个信息获取请求的有效响应，从而有效避免了缓存雪崩的发生，一定程度上提升了数据库系统的稳定性。
下面结合图3-图5以第一缓存数据和第二缓存数据为用户在多层级架构下的权限数据为例，对缓存数据的存储、更新等处理过程进行详细说明。
图3是根据本公开的实施例示出的一种多层级架构的示意图。以图3为例，数据库可以被租户租用，并根据自身相关的团体、项目等多级架构对数据库进行相应处理，以便数据库按照上述多级架构存储各个级别下的业务数据。其中，上述租户可以为企业、机构等，相应的，用户可以为企业或机构中的员工。任一租户下可能存在团队、项目等多个架构层级，此时租户可以中的管理人员可以按照相应的架构层级将租户中的任一用户分配至相应的架构下。当然，上述租户也可以为个人用户，相应的，上述数据库可以存储该个人用户所实施项目的项目数据等，本公开实施例并不对此进行限制。
如图3所示，数据库可以包括租户层级、团队层级和项目层级。其中，租户层级中可以包括多个租户，任一租户1的团队层级下可以包括公开团队、私密团队和示例团队等多个团队，任一团队下可以包括若干项目，如公开团队下可以包括项目1和项目2，私密团队下可以包括项目3，示例团队下可以包括项目4和项目5等，不再一一赘述。
在图3所示多层级架构下，租户1中的任一用户可以被分配至任一团队，也可以进一步被分配至任一团队的任一项目中，因此任一用户的权限等级与其在多层级架构中的位置相对应。例如，租户经理可以拥有对公开团队、私密团队和示例团队等全部或部分团队的控制权，示例团队的主管可以拥有对项目4和项目5的控制权，执行项目4具体任务的用户可以拥有对项目4的全部或部分控制权等。可见，任一用户在租户中扮演的角色不同，其对应的用户权限也有所不同。而且，通常情况下用户的权限有随角色向下传递的特性，例如租户的管理员是其下方所有团队的管理员，团队的管理员又是其下方所有项目的管理员。如果任一用户同时具有多种角色(如既是某项目的创建者，又是该团队的管理员)，则该用户的权限通常以该用户在租户中所扮演多个角色中的最高权限为准。以企业类型的租户为例，上述权限可以为邀请企业成员、登录企业管理后台，解散企业、创建团队、添加和管理团队成员、解散团队、创建项目、添加、删除和管理项目成员、增删改项目任务等、删除项目等，不再一一赘述。
缓存设备可以将与用户所扮演的多个角色相关的多组数据作为用户缓存数据保存在预设缓存中，下面结合图4所示的一种缓存数据的存储方法示意图，以将缓存数据以hash结构保存在预设的redis缓存的hash表中为例，对上述缓存数据的存储方法进行说明。
如图4所示，hash表中的任一数据元素包括key字段、field字段和value字段。其中，任一数据元素中的key字段可以用于记录对象层级、field字段可以用于记录用户标识、value字段可以用于记录用户权限。例如，租户数据元素401中的key字段可以用于记录租户标识、field字段可以用于记录用户标识、value字段可以用于记录对该租户拥有控制权限的用户列表；团队数据元素402中的key字段可以用于记录该团队所属租户的租户标识、field字段可以用于记录用户标识、value字段可以用于记录对该团队拥有控制权限的用户列表；项目数据元素403中的key字段可以用于记录该项目所属团队的团队标识、field字段可以用于记录用户标识、value字段可以用于记录对该项目拥有控制权限的用户列表。
其中，任一key字段可能对应于多个用户，例如，在团队T1存在n个拥有控制权限的用户的情况下，团队数据元素中的key字段可以对应于n个用户标识和团队列表的组合，即项目数据元素403中“team:团队id_version”字段对应于多个“用户标识，有权限的团队列表”，即用户U1、U2和U3及其分别对应的项目列表。
在数据库中保存的层级架构发生变化(如组织机构调整)或用户在层级架构中的位置发生变化(如人事调动)后，缓存设备中保存的相应用户的权限缓存信息也会相应的被更新。例如，在用户U1被从项目1调动至项目2后，项目数据元素403被相应的更新为项目数据元素404(即项目数据元素404是更新后的项目数据元素)，具体更新过程可以参见下述图5所示实施例的记载，此处暂不赘述。
需要说明的是，该更新是数据快照形式的数据更新，即在hash表的可用存储空间中生成新的项目数据元素404，该项目数据元素404的缓存数据版本号，可以在更新前的项目数据元素403的key字段中保存的缓存数据版本号“version”的基础上累加，如生成的缓存数据的版本号为“version+1”，则此时生成的项目数据元素404的key字段为“team:团队id_version+1”，其对应的缓存数据为“用户U1，项目2”。
图5是根据本公开的实施例示出的一种缓存数据的更新方法流程图，数据库、缓存设备和Maxwell解析器之间相互配合实现该方法。下面结合图5对图4所示的将项目数据元素403更新为项目数据元素404的过程进行说明。如图5所示，该过程可以包括下述步骤502-508。
步骤502，数据库中的用户权限发生变更。
在用户U1被管理人员从项目1调动至项目2后，用户U1在层级架构中的位置发生变化，相应的，数据库中保存的上述位置数据也发生变化，即数据库中发生了数据更新事件。以MySQL数据库为例，在上述数据更新事件发生后，数据库会生成二进制形式的binlog日志文件，该文件记录有上述数据更新事件对应的数据变化前后的数据变更信息。因此，缓存设备可以按照预设的固定周期，获取数据库产生的binlog日志文件；或者也可以在监听到数据更新事件发生后获取该事件对应的binlog日志文件。
步骤504，缓存设备调用Maxwell解析器解析数据库产生的binlog日志文件。
步骤506，Maxwell解析器生成并发送数据更新消息至消息队列。
进一步的，获取到上述binlog日志文件后，缓存设备可以通过调用日志解析服务对binlog日志文件进行解析。
以Maxwell解析器为例，该解析器能够实时读取并解析MySQL数据库产生的二进制形式的binlog日志文件，并使用解析日志得到的数据变更信息生成JSON格式的数据更新消息，然后作为消息生产者将该消息提供至Kafka、RabbitMQ、MetaQ、ActiveMQ等消息队列中，以供其他设备或服务对消息进行消费。
步骤508，缓存设备消费并过滤队列消息。
缓存设备可以通过轮询或消息订阅等方式获取消息队列中的上述数据更新消息，即消费上述数据更新消息。因为从消息队列中获取到的消息中可能还包括与缓存数据更新无关的其他消息，因此缓存设备在获取到上述数据更新消息后，可以按照预设的过滤规则对数据更新消息进行过滤，以得到所需的数据更新消息，如上述数据更新事件对应的数据更新消息，从而避免其他消息的干扰，并减少不必要的数据处理。
步骤510，缓存设备对队列消息生成的缓存更新事件进行幂等校验。
在接收到上述数据更新消息后，缓存设备可以相应的生成缓存更新事件。为避免同一数据更新事件(如多人对同一数据进行的多次相同操作)或者对应于相同操作结果的多个数据更新事件(如依次对同一数据进行增加、修改和删除的数据更新事件)可能产生的多个数据更新消息导致对缓存数据的多次重复更新，可以对缓存更新事件进行幂等校验。
若缓存更新事件通过幂等校验，则表明该缓存更新事件对应的第一缓存数据尚未被更新，此时可以转入步骤512；否则，若缓存更新事件未通过幂等校验，则表明该缓存更新事件对应的第一缓存数据已经被更新，此时无需对相关数据再次进行更新，可以转入步骤514退出当前缓存更新流程。
步骤512，缓存设备使用binlog数据更新项目数据元素403中的缓存数据。
因为上述数据更新消息中包含数据变更信息(即对应于binlog日志文件的binlog数据)，所以可以根据该数据变更信息对缓存设备中相应的缓存数据进行更新。
承接于图4的前述实施例，即将项目数据元素403更新为项目数据元素404。亦即在项目数据元素403的基础上生成项目数据元素404，此时的项目数据元素404即相当于版本号为“Version+1”的第二缓存数据，项目数据元素403即相当于版本号为“Version”的第一缓存数据。至此，完成对项目数据元素403的更新过程。
步骤514，更新结束。
在本实施例中，因为缓存数据被按照hash结构保存在缓存设备中，所以对于缓存数据的增加、删除、修改等数据操作仅需要处理一条数据元素即可，相对于按照列表list结构存储的缓存数据，大大减少了业务系统或数据库与缓存设备之间的交互次数，有助于减轻缓存设备的交互压力。
图6是根据本公开的实施例示出的一种缓存数据的请求响应方法的流程图，该方法适用于缓存设备。通过查询更新后的项目数据元素，缓存设备可以对针对用户权限发出的权限获取请求进行响应，下面结合图6对该过程进行说明。如图6所示，该过程可以包括下述步骤602-616。
步骤602，接收请求方发送的权限获取请求。
在本实施例中，上述权限获取请求的请求方可以为用户客户端，如企业内部普通用户或管理人员的客户端，例如，项目管理人员通常仅能够查看自身所管理项目的项目信息，因此在任一项目管理人员(即下述用户)登录项目管理页面时，可以输入自身的用户账号和密码，进而客户端在核实该用户合法的情况下，可以向缓存设备请求获取该用户的用户权限，从而确定应当向该用户展示的项目信息。或者，上述权限获取请求也可以发送至服务端，并由服务端向缓存设备请求获取相应的用户权限。
步骤604，判断当前待响应的权限获取请求是否达到限流标准。
因为缓存设备通常服务于多个服务器所连接的多个客户端，因此缓存设备可能在一段时间内接收到大量的用户权限获取请求。例如在用户为普通访客的情况下，大量的普通访客对应的客户端可能在极短时间内发送大量的权限获取请求(如在商品秒杀场景下验证用户的合法权限，判断用户是否为黑灰产用户)，因此可以根据请求数量对权限获取请求进行分流处理。
首先，可以确定预先设置的固定数值的数量阈值S0，或者也可以获取缓存设备的当前资源占用率或者预测缓存设备在预设时长(如0.5s)后的预测资源占用率，并根据上述当前资源占用率或预测资源占用率确定缓存设备当前时刻或预设时长后的最大请求处理数量，并将该数量确定为数量阈值S0。
然后，可以确定当前接收到的待响应的权限获取请求的数量S，并进行判断：若S≤S0，则转入步骤608；否则，若S>S0，则将数量为S0(如前S0个)的权限获取请求转入步骤608，并将剩余数量个(如S-S0个)的权限获取请求转入步骤606。
步骤606，判断版本号为Version的第一缓存数据中是否存在目标数据。
对于剩余S-S0个请求中的任一权限获取请求，先从该请求中提取请求针对的目标用户，然后在图4所述的第一缓存数据(项目数据元素401-403)中查询是否存在针对目标用户的目标数据。例如，计算用户U1的用户权限需要用到用户U1所在全部项目的项目标识，则可以将用户U1所在全部项目的项目标识确定为目标数据。
以项目数据元素403为例，若如图4所示数据更新为项目变更，则能够在项目数据元素404中查询到用户U1对应的目标数据(项目1)，此时转入步骤612；否则，若针对项目数据元素403的更新为删除(如用户U1被从所有项目中删除，项目数据元素404中不包含用户U1，图中未示出)，则无法在项目数据元素404中查询到用户U1对应的任何目标数据，此时转入步骤610。
步骤608，判断版本号为Version+1的第二缓存数据中是否存在目标数据。
类似于第一缓存数据，对于S0(或小于S0)个请求中的任一权限获取请求，先从该请求中提取请求针对的目标用户，然后在图4所述的第二缓存数据(项目数据元素401、402和404)中查询是否存在针对目标用户的目标数据。
仅以项目数据元素403为例，若如图4所示数据更新为项目变更，则能够在项目数据元素404中查询到用户U1对应的目标数据(项目1)，此时转入步骤612；否则，若针对项目数据元素403的更新为删除，则无法在项目数据元素404中查询到用户U1对应的任何目标数据，此时转入步骤614。
步骤610，确定用户无权限。
此时，因为作为备份数据源的项目数据元素403中不存在用户用户U1，所以表明该用户U1不具有针对目标对象的用户权限。
步骤612，从第一缓存数据或第二缓存数据中获取目标数据，并计算用户权限。
缓存设备可以从上述第一缓存数据或第二缓存数据中获取查询到的目标数据，并根据用户对于较高层级数据的管理权限确定对较低层级数据的管理权限。如获取用户U1对应的项目1的项目标识及其相关信息。进而可以基于上述相关信息计算用户U1针对各个项目的项目信息的获取权限：如在用户拥有针对项目1的管理权限且项目1包含子项目11的情况下，用户U1同样拥有针对子项目11的管理权限，自然也拥有获取子项目11的项目信息的权限。
步骤614，从数据库中请求获取目标数据，并计算用户权限。
在上述第一缓存数据和第二缓存数据中均不存在目标数据的情况下，表明缓存设备中保存的缓存数据的所对应的时刻晚于数据库中数据的所对应的时刻。即数据库中的第二数据可能已经被更新为更新版本的第三数据，但是缓存设备中的第二缓存数据尚未更新，从而导致缓存数据与数据库中所保存数据之间的不一致，此时，缓存设备可以向数据库请求获取最新版本的目标数据，并使用该目标数据对缓存数据进行更新。
同时，获取到该目标数据后，可以直接使用该目标数据确定用户权限，也可以在更新缓存数据后，使用更新后的缓存数据确定用户权限，本公开实施例并不对此进行限制。
步骤616，向请求方返回用户权限的确定结果。
通过上述步骤确定用户权限(不具有权限或具有何种权限)后，缓存设备可以将该用户权限的确定结果返回至请求方，从而完成对权限获取请求的响应。
可见，在待响应的信息获取请求的数量S不超出数量阈值S0时，仅使用第二缓存数据即可对全部S个信息获取请求作出响应；而在待响应的信息获取请求的数量S超出数量阈值S0(即S>S0)时，仅使用第二缓存数据无法对全部信息获取请求作出响应，此时可以使用上述第二缓存数据对全部S个信息获取请求中的S0个请求做出响应，并使用第一缓存数据对全部S个信息获取请求中的S-S0个请求做出响应，从而保证全部S个请求均得到正常响应。
与前述数据处理方法的实施例相对应地，本公开还提出了数据处理装置的实施例。
图7是根据本公开的实施例示出的一种数据处理装置的示意框图。本实施例所示的数据处理装置可以适用于缓存设备，该缓存设备可以为包含一独立主机的物理服务器、主机集群承载的虚拟服务器、云服务器等。
如图7所示，所述数据处理装置可以包括：
生成及存储单元701，被配置为在确定数据库中保存的第一数据被更新为第二数据的情况下，生成对应于所述第二数据的第二缓存数据并将其存储在预设缓存中，所述预设缓存中还存储有对应于所述第一数据的第一缓存数据；
第一响应单元702，被配置为在待响应的信息获取请求的数量超出数量阈值的情况下，使用所述第二缓存数据响应预设数量的所述信息获取请求，并使用所述第一缓存数据响应剩余的所述信息获取请求。
对于图7所示的资源信息的获取装置，可选的，还可以包括其他一个或多个单元。可参见图8所示的另一种数据处理装置，如图8所示：
可选的，还包括：
第二响应单元803，被配置为在待响应的信息获取请求的数量不超出所述数量阈值的情况下，使用所述第二缓存数据响应所述信息获取请求。
可选的，所述数量阈值包括：
预设的数量值；或者，
根据当前资源占用率和/或预测资源占用率确定出的最大请求处理数量。
可选的，所述生成及存储单元701还被配置为：
从消息队列中获取数据更新消息，所述数据更新消息对应于数据库中保存的第一数据被更新为第二数据的数据更新事件；
根据所述数据更新消息生成缓存更新事件；
对所述缓存更新事件进行幂等校验，并在校验通过的情况下，根据所述缓存更新事件生成对应于所述第二数据的第二缓存数据。
可选的，所述数据库包括MySQL数据库，所述数据更新消息被根据对应于所述数据更新事件的binlog日志文件生成。
可选的，还包括：
版本号分配单元804，被配置为为所述第二缓存数据分配区别于所述第一版本号的第二版本号，其中，所述第一版本号和第二版本号被分别用于查询所述第一缓存数据和第二缓存数据。
可选的，所述预设缓存包括redis缓存，所述第一缓存数据和第二缓存数据被按照哈希hash结构存储在所述redis缓存中。
可选的，所述第一缓存数据和第二缓存数据包括用户在多层级架构下的权限数据，所述hash结构所对应hash表的key字段用于记录对象层级、field字段用于记录用户标识、value字段用于记录用户权限。
可选的，还包括：
标识确定单元805，被配置为响应于获取到的数据更新消息，确定所述数据更新消息对应的目标用户标识；
数据确定单元806，被配置为通过查询所述第一缓存数据所对应hash表的field字段，将记录有所述目标用户标识的field字段所在的权限数据确定为待处理的目标权限数据；
数据更新单元807，被配置为根据所述数据更新消息指定的更新方式，更新所述目标权限数据。
可选的，还包括：
请求发送单元808，被配置为在所述第二缓存数据中未查询到用于响应任一信息获取请求的目标数据的情况下，向所述数据库发送数据获取请求；
缓存更新单元809，被配置为根据所述数据库返回的所述目标数据更新所述第二缓存数据。
本公开的实施例还提出一种电子设备，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现如上述任一实施例所述的数据处理方法。
本公开的实施例还提出一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述任一实施例所述的数据处理方法。
本公开的实施例还提出一种计算机程序产品，所述计算机程序产品被配置为执行上述任一实施例所述的数据处理方法。
图9是根据本公开的实施例示出的一种电子设备的示意框图。例如，电子设备900可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。
参照图9，电子设备900可以包括以下一个或多个组件：处理组件902，存储器904，电源组件906，多媒体组件908，音频组件910，输入/输出(I/O)的接口912，传感器组件914，以及通信组件918。
处理组件902通常控制电子设备900的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件902可以包括一个或多个处理器920来执行指令，以完成上述数据处理方法的全部或部分步骤。此外，处理组件902可以包括一个或多个模块，便于处理组件902和其他组件之间的交互。例如，处理组件902可以包括多媒体模块，以方便多媒体组件908和处理组件902之间的交互。
存储器904被配置为存储各种类型的数据以支持在电子设备900的操作。这些数据的示例包括用于在电子设备900上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器904可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。
电源组件906为电子设备900的各种组件提供电力。电源组件906可以包括电源管理系统，一个或多个电源，及其他与为电子设备900生成、管理和分配电力相关联的组件。
多媒体组件908包括在电子设备900和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件908包括一个前置摄像头和/或后置摄像头。当电子设备900处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。
音频组件910被配置为输出和/或输入音频信号。例如，音频组件910包括一个麦克风(MIC)，当电子设备900处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器904或经由通信组件918发送。在一些实施例中，音频组件910还包括一个扬声器，用于输出音频信号。
I/O接口912为处理组件902和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。
传感器组件914包括一个或多个传感器，用于为电子设备900提供各个方面的状态评估。例如，传感器组件914可以检测到电子设备900的打开/关闭状态，组件的相对定位，例如所述组件为电子设备900的显示器和小键盘，传感器组件914还可以检测电子设备900或电子设备900一个组件的位置改变，用户与电子设备900接触的存在或不存在，电子设备900方位或加速/减速和电子设备900的温度变化。传感器组件914可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件914还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件914还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。
图像采集组件916可以用于采集被摄对象的图像数据，以形成关于被摄对象的图像，并可以对该图像进行必要的处理。该图像采集组件916可以包括相机模组，相机模组中的图像传感器(Sensor)通过镜头感应来自被摄对象的光线，将得到的感光数据提供给图像信号处理器(ISP，Image Signal Processing)，由后者根据感光数据生成对应于被摄对象的图像。其中，上述图像传感器可以为CMOS传感器或CCD传感器，当然，也可以为红外传感器、深度传感器等；相机模组可以内置在电子设备900中，也可以为电子设备900的外接模组；上述ISP可以内置在相机模组中，也可以外挂在上述电子设备中(不在相机模组内)。
通信组件918被配置为便于电子设备900和其他设备之间有线或无线方式的通信。电子设备900可以接入基于通信标准的无线网络，如WiFi，运营商网络(如2G、3G、4G或5G)，或它们的组合。在一个示例性实施例中，通信组件918经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件918还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。
在本公开一实施例中，电子设备900可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述数据处理方法。
在本公开一实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器904，上述指令可由电子设备900的处理器920执行以完成上述数据处理方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。
本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。
应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。
需要说明的是，在本公开中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上对本公开实施例所提供的方法和装置进行了详细介绍，本文中应用了具体个例对本公开的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本公开的方法及其核心思想；同时，对于本领域的一般技术人员，依据本公开的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本公开的限制。
Claims (22)
1.一种数据处理方法，其特征在于，包括：
在确定数据库中保存的第一数据被更新为第二数据的情况下，生成对应于所述第二数据的第二缓存数据并将其存储在预设缓存中，所述预设缓存中还存储有对应于所述第一数据的第一缓存数据；
在待响应的信息获取请求的数量超出数量阈值的情况下，使用所述第二缓存数据响应预设数量的所述信息获取请求，并使用所述第一缓存数据响应剩余的所述信息获取请求。
2.根据权利要求1所述的方法，其特征在于，还包括：
在待响应的信息获取请求的数量不超出所述数量阈值的情况下，使用所述第二缓存数据响应所述信息获取请求。
3.根据权利要求1所述的方法，其特征在于，所述数量阈值包括：
预设的数量值；或者，
根据当前资源占用率和/或预测资源占用率确定出的最大请求处理数量。
4.根据权利要求1所述的方法，其特征在于，所述在确定数据库中保存的第一数据被更新为第二数据的情况下，生成对应于所述第二数据的第二缓存数据，包括：
从消息队列中获取数据更新消息，所述数据更新消息对应于数据库中保存的第一数据被更新为第二数据的数据更新事件；
根据所述数据更新消息生成缓存更新事件；
对所述缓存更新事件进行幂等校验，并在校验通过的情况下，根据所述缓存更新事件生成对应于所述第二数据的第二缓存数据。
5.根据权利要求4所述的方法，其特征在于，所述数据库包括MySQL数据库，所述数据更新消息被根据对应于所述数据更新事件的binlog日志文件生成。
6.根据权利要求1所述的方法，其特征在于，所述第一缓存数据被分配有第一版本号，所述方法还包括：
为所述第二缓存数据分配区别于所述第一版本号的第二版本号，其中，所述第一版本号和第二版本号被分别用于查询所述第一缓存数据和第二缓存数据。
7.根据权利要求1所述的方法，其特征在于，所述预设缓存包括redis缓存，所述第一缓存数据和第二缓存数据被按照哈希hash结构存储在所述redis缓存中。
8.根据权利要求7所述的方法，其特征在于，所述第一缓存数据和第二缓存数据包括用户在多层级架构下的权限数据，所述hash结构所对应hash表的key字段用于记录对象层级、field字段用于记录用户标识、value字段用于记录用户权限。
9.根据权利要求8所述的方法，其特征在于，还包括：
响应于获取到的数据更新消息，确定所述数据更新消息对应的目标用户标识；
通过查询所述第一缓存数据所对应hash表的field字段，将记录有所述目标用户标识的field字段所在的权限数据确定为待处理的目标权限数据；
根据所述数据更新消息指定的更新方式，更新所述目标权限数据。
10.根据权利要求1-9中任一项所述的方法，其特征在于，还包括：
在所述第二缓存数据中未查询到用于响应任一信息获取请求的目标数据的情况下，向所述数据库发送数据获取请求；
根据所述数据库返回的所述目标数据更新所述第二缓存数据。
11.一种数据处理装置，其特征在于，包括：
生成及存储单元，被配置为在确定数据库中保存的第一数据被更新为第二数据的情况下，生成对应于所述第二数据的第二缓存数据并将其存储在预设缓存中，所述预设缓存中还存储有对应于所述第一数据的第一缓存数据；
第一响应单元，被配置为在待响应的信息获取请求的数量超出数量阈值的情况下，使用所述第二缓存数据响应预设数量的所述信息获取请求，并使用所述第一缓存数据响应剩余的所述信息获取请求。
12.根据权利要求11所述的装置，其特征在于，还包括：
第二响应单元，被配置为在待响应的信息获取请求的数量不超出所述数量阈值的情况下，使用所述第二缓存数据响应所述信息获取请求。
13.根据权利要求11所述的装置，其特征在于，所述数量阈值包括：
预设的数量值；或者，
根据当前资源占用率和/或预测资源占用率确定出的最大请求处理数量。
14.根据权利要求11所述的装置，其特征在于，所述生成及存储模块还被配置为：
从消息队列中获取数据更新消息，所述数据更新消息对应于数据库中保存的第一数据被更新为第二数据的数据更新事件；
根据所述数据更新消息生成缓存更新事件；
对所述缓存更新事件进行幂等校验，并在校验通过的情况下，根据所述缓存更新事件生成对应于所述第二数据的第二缓存数据。
15.根据权利要求14所述的装置，其特征在于，所述数据库包括MySQL数据库，所述数据更新消息被根据对应于所述数据更新事件的binlog日志文件生成。
16.根据权利要求11所述的装置，其特征在于，还包括：
版本号分配单元，被配置为为所述第二缓存数据分配区别于第一版本号的第二版本号，其中，所述第一版本号和第二版本号被分别用于查询所述第一缓存数据和第二缓存数据。
17.根据权利要求11所述的装置，其特征在于，所述预设缓存包括redis缓存，所述第一缓存数据和第二缓存数据被按照哈希hash结构存储在所述redis缓存中。
18.根据权利要求17所述的装置，其特征在于，所述第一缓存数据和第二缓存数据包括用户在多层级架构下的权限数据，所述hash结构所对应hash表的key字段用于记录对象层级、field字段用于记录用户标识、value字段用于记录用户权限。
19.根据权利要求18所述的装置，其特征在于，还包括：
标识确定单元，被配置为响应于获取到的数据更新消息，确定所述数据更新消息对应的目标用户标识；
数据确定单元，被配置为通过查询所述第一缓存数据所对应hash表的field字段，将记录有所述目标用户标识的field字段所在的权限数据确定为待处理的目标权限数据；
数据更新单元，被配置为根据所述数据更新消息指定的更新方式，更新所述目标权限数据。
20.根据权利要求11-19中任一项所述的装置，其特征在于，还包括：
请求发送单元，被配置为在所述第二缓存数据中未查询到用于响应任一信息获取请求的目标数据的情况下，向所述数据库发送数据获取请求；
缓存更新单元，被配置为根据所述数据库返回的所述目标数据更新所述第二缓存数据。
21.一种电子设备，其特征在于，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现如权利要求1至10中任一项所述的数据处理方法。
22.一种计算机可读存储介质，其特征在于，当所述存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如权利要求1至10中任一项所述的数据处理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110296791.7A CN113094378B (zh) | 2021-03-19 | 2021-03-19 | 数据处理方法、装置、电子设备和存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110296791.7A CN113094378B (zh) | 2021-03-19 | 2021-03-19 | 数据处理方法、装置、电子设备和存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113094378A CN113094378A (zh) | 2021-07-09 |
| CN113094378B true CN113094378B (zh) | 2024-02-06 |
Family
ID=76669244
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110296791.7A Active CN113094378B (zh) | 2021-03-19 | 2021-03-19 | 数据处理方法、装置、电子设备和存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113094378B (zh) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114064807B (zh) * | 2021-11-29 | 2023-07-18 | 四川虹美智能科技有限公司 | 用户系统及其数据提供方法 |
| CN115158945B (zh) * | 2022-07-21 | 2024-04-30 | 杭州壹悟科技有限公司 | 基于多种设备系统协助作业的仓储管理方法、设备及介质 |
| CN115576966A (zh) * | 2022-09-29 | 2023-01-06 | 海尔优家智能科技（北京）有限公司 | 数据更新方法、装置、存储介质及电子装置 |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101043318A (zh) * | 2007-03-19 | 2007-09-26 | 华为技术有限公司 | 前后台数据同步的方法及用于前后台数据同步的装置 |
| CN107506396A (zh) * | 2017-07-31 | 2017-12-22 | 努比亚技术有限公司 | 一种数据缓存初始化方法、移动终端以及计算机可读存储介质 |
| CN109167810A (zh) * | 2018-07-27 | 2019-01-08 | 阿里巴巴集团控股有限公司 | 监听、通知、刷新方法和装置、计算设备及存储介质 |
| CN109885399A (zh) * | 2019-01-17 | 2019-06-14 | 平安普惠企业管理有限公司 | 数据处理方法、电子装置、计算机设备及存储介质 |
| CN111177161A (zh) * | 2019-11-07 | 2020-05-19 | 腾讯科技（深圳）有限公司 | 数据处理方法、装置、计算设备和存储介质 |
| CN112003945A (zh) * | 2020-08-26 | 2020-11-27 | 杭州迪普科技股份有限公司 | 服务请求响应方法及装置 |
| CN112307119A (zh) * | 2020-10-27 | 2021-02-02 | 广州市网星信息技术有限公司 | 数据同步方法、装置、设备及存储介质 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10545995B2 (en) * | 2017-05-22 | 2020-01-28 | Sap Se | Validating query results during asynchronous database replication |
-
2021
- 2021-03-19 CN CN202110296791.7A patent/CN113094378B/zh active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101043318A (zh) * | 2007-03-19 | 2007-09-26 | 华为技术有限公司 | 前后台数据同步的方法及用于前后台数据同步的装置 |
| CN107506396A (zh) * | 2017-07-31 | 2017-12-22 | 努比亚技术有限公司 | 一种数据缓存初始化方法、移动终端以及计算机可读存储介质 |
| CN109167810A (zh) * | 2018-07-27 | 2019-01-08 | 阿里巴巴集团控股有限公司 | 监听、通知、刷新方法和装置、计算设备及存储介质 |
| CN109885399A (zh) * | 2019-01-17 | 2019-06-14 | 平安普惠企业管理有限公司 | 数据处理方法、电子装置、计算机设备及存储介质 |
| CN111177161A (zh) * | 2019-11-07 | 2020-05-19 | 腾讯科技（深圳）有限公司 | 数据处理方法、装置、计算设备和存储介质 |
| CN112003945A (zh) * | 2020-08-26 | 2020-11-27 | 杭州迪普科技股份有限公司 | 服务请求响应方法及装置 |
| CN112307119A (zh) * | 2020-10-27 | 2021-02-02 | 广州市网星信息技术有限公司 | 数据同步方法、装置、设备及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113094378A (zh) | 2021-07-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113094378B (zh) | 数据处理方法、装置、电子设备和存储介质 | |
| CN107133309B (zh) | 流程实例的存储、查询方法及装置、存储介质及电子设备 | |
| CN111274214B (zh) | 一种文件锁处理方法、装置及电子设备和存储介质 | |
| CN111782391A (zh) | 资源分配方法、装置、电子设备和存储介质 | |
| CN114244595A (zh) | 权限信息的获取方法、装置、计算机设备及存储介质 | |
| CN113220482A (zh) | 调用请求处理方法、装置、电子设备及存储介质 | |
| CN112528185A (zh) | 评论信息展示方法、装置、服务器、终端 | |
| CN112328658A (zh) | 用户档案数据处理方法、装置、设备及存储介质 | |
| CN111988669B (zh) | 视频交互数据的处理方法、装置、电子设备和存储介质 | |
| CN112711515B (zh) | 一种实时监控方法、装置及电子设备 | |
| CN113901496A (zh) | 基于多业务系统的业务处理方法、装置和设备 | |
| CN114428589A (zh) | 一种数据处理方法、装置、电子设备及存储介质 | |
| CN110795314B (zh) | 一种检测慢节点的方法、装置及计算机可读存储介质 | |
| CN113111123A (zh) | 集群业务的调用方法、装置、电子设备、存储介质及产品 | |
| CN112487454A (zh) | 一种数据管理方法、装置、设备及存储介质 | |
| CN108984294B (zh) | 资源调度方法、装置及存储介质 | |
| CN115834483A (zh) | 基于集群的流量控制方法、装置、设备及存储介质 | |
| CN113704315B (zh) | 一种用户推荐方法、装置、电子设备及存储介质 | |
| CN114143590A (zh) | 一种视频播放方法、服务器及存储介质 | |
| CN111898100A (zh) | 代码泄露溯源的方法、装置及终端设备 | |
| CN116244358A (zh) | 数据处理方法、设备及存储介质 | |
| CN114066370A (zh) | 库存服务调用方法、装置、设备、存储介质及程序产品 | |
| CN113342539B (zh) | 数据处理方法、装置、电子设备和存储介质 | |
| CN116909760B (zh) | 数据处理方法、装置、可读存储介质、电子设备 | |
| CN113098754A (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 |