CN107025243B - 一种资源数据的查询方法、查询客户端和查询系统 - Google Patents

一种资源数据的查询方法、查询客户端和查询系统 Download PDF

Info

Publication number
CN107025243B
CN107025243B CN201610073675.8A CN201610073675A CN107025243B CN 107025243 B CN107025243 B CN 107025243B CN 201610073675 A CN201610073675 A CN 201610073675A CN 107025243 B CN107025243 B CN 107025243B
Authority
CN
China
Prior art keywords
resource
query
redis
unique identifier
resource 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
Application number
CN201610073675.8A
Other languages
English (en)
Other versions
CN107025243A (zh
Inventor
李能进
王庆磊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Shenzhou Taiyue Software Co Ltd
Original Assignee
Beijing Shenzhou Taiyue Software Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Beijing Shenzhou Taiyue Software Co Ltd filed Critical Beijing Shenzhou Taiyue Software Co Ltd
Priority to CN201610073675.8A priority Critical patent/CN107025243B/zh
Publication of CN107025243A publication Critical patent/CN107025243A/zh
Application granted granted Critical
Publication of CN107025243B publication Critical patent/CN107025243B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2455Query execution
    • G06F16/24552Database cache management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (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

本发明公开了一种资源数据的查询方法、查询客户端和查询系统。所述方法包括:接收查询指令,并从查询指令中获取待查询资源数据的资源唯一标识Resid;根据待查询资源数据的资源唯一标识Resid查询本地Ehcache缓存;在本地Ehcache缓存中未查询到该资源唯一标识Resid的资源数据时,将该资源唯一标识Resid发送到Redis集群中,并将Redis集群返回的资源数据的哈希表HashMap作为查询结果,将查询结果组装成资源对象ResObject记录到本地Ehcache缓存中。本发明结合本地Ehcache缓存和Redis集群实现了资源数据的快速查询,以及结合Solr搜索引擎实现了资源数据的条件查询,从而改进了传统网管监控系统的数据库查询方式带来的速度慢、灵活性差的问题。

Description

一种资源数据的查询方法、查询客户端和查询系统
技术领域
本发明涉及互联网技术领域,特别涉及一种资源数据的查询方法、查询客户端和查询系统。
背景技术
网管监控系统主要包含资源、告警和性能三种类型的数据,其中资源数据是基础,告警数据和性能数据都是基于或者关联资源数据的。因此,在网管监控系统处理过程中,资源数据的查询速度,对告警数据和性能数据的处理速度有很大的影响。为了提升网管监控系统的处理能力,必须提升资源数据的查询速度。
在传统的网管系统中,资源数据一般都是存储在关系型数据库中的,例如存储在Oracle甲骨文数据库、Mysql数据库,对于资源数据的单个数据查询和组合查询,都是基于数据库查询实现的。关系型数据库的查询方式较为适用于存储资源数据量较小的关系型数据库,当资源数据量比较大时,例如超过1000万的资源数据,且告警数据量和性能数据量都比较大时,假设活动告警产生速度达到5000条/秒的速度,整个系统中对单个资源的查询速度可能需要达到2万次/秒以上,若仅仅依赖于关系型数据库来实现快速查询,是无法达到要求的。
针对上述问题,现有的网管系统一般通过将资源数据初始化到本地缓存中,如缓存到JVM内存中,来提高资源数据的查询速度。但当资源数据量达到1000万或更多时,缓存这些资源数据将会消耗大量的内存,而且重启时还需要将资源数据重新加载到内存中,加载时间过长。
因此,亟需一种新型的网管监控系统,以适应大资源数据量的快速查询。
发明内容
鉴于上述问题,本发明提供了一种资源数据的查询方法、查询客户端和查询系统,以解决传统网管监控系统无法满足大数据的查询需求的问题。
为达到上述目的,本发明的技术方案是这样实现的:
一方面,本发明提供了一种资源数据的查询方法,所述资源数据按照资源唯一标识Resid分布式缓存在Redis集群中,该资源数据的查询方法包括:
接收查询指令,并从查询指令中获取待查询资源数据的资源唯一标识Resid;
根据待查询资源数据的资源唯一标识Resid查询本地Ehcache缓存;
在本地Ehcache缓存中未查询到该资源唯一标识Resid的资源数据时,将该资源唯一标识Resid发送到Redis集群中,并将Redis集群返回的资源数据的哈希表HashMap作为查询结果,将查询结果组装成资源对象ResObject记录到本地Ehcache缓存中。
另一方面,本发明提供了一种资源数据的查询方法,资源数据按照资源唯一标识Resid分布式缓存在Redis集群中,该资源数据的查询方法包括:
接收客户端发送的待查询资源数据的资源唯一标识Resid,在客户端的本地Ehcache缓存中根据该资源唯一标识Resid未查询到相应资源数据;
根据接收到的资源唯一标识Resid从Redis集群中获取该资源唯一标识Resid对应的资源数据的哈希表HashMap,并将哈希表HashMap作为查询结果发送给客户端,使客户端将接收到的查询结果组装成资源对象ResObject记录到客户端本地的Ehcache缓存中。
一方面,本发明还提供了一种资源数据的查询客户端,资源数据按照资源唯一标识Resid分布式缓存在Redis集群中,该资源数据的查询客户端包括:
资源查询接口,用于接收查询指令,并从查询指令中获取待查询资源数据的资源唯一标识Resid;
本地查询单元,用于根据待查询资源数据的资源唯一标识Resid查询本地Ehcache缓存;
服务器查询单元,用于在本地Ehcache缓存中未查询到该资源唯一标识Resid的资源数据时,将该资源唯一标识Resid发送到所述Redis集群中,并将所述Redis集群返回的资源数据的哈希表HashMap作为查询结果,将所述查询结果组装成资源对象ResObject记录到本地Ehcache缓存中。
又一方面,本发明提供了一种资源数据的查询系统,包括:资源数据查询客户端和Redis集群,资源数据按照资源唯一标识Resid分布式缓存在Redis集群中,资源数据查询客户端包括:资源查询接口、本地查询单元和服务器查询单元;
资源查询接口,用于接收查询指令,并从所述查询指令中获取待查询资源数据的资源唯一标识Resid;
本地查询单元,用于根据所述待查询资源数据的资源唯一标识Resid查询本地Ehcache缓存;
服务器查询单元,用于在本地Ehcache缓存中未查询到该资源唯一标识Resid的资源数据时,将该资源唯一标识Resid发送到所述Redis集群中,并将所述Redis集群返回的资源数据的哈希表HashMap作为查询结果,将所述查询结果组装成资源对象ResObject记录到本地Ehcache缓存中;
Redis集群,用于接收客户端发送的所述资源唯一标识Resid,并根据接收到的所述资源唯一标识Resid获取该资源唯一标识Resid对应的资源数据的哈希表HashMap,以及将所述哈希表HashMap作为查询结果发送给客户端。
本发明实施例的有益效果是:本发明将资源数据进行分布式缓存,利用Redis集群的负载均衡能力和错误恢复能力,实现了资源数据的可扩展性和高可用性;并且本发明基于资源数据的分布式缓存,还提供一种新型的资源数据的查询方法,通过借助Ehcache实现本地缓存,避免频繁地远程从Redis集群中获取资源数据,达到加快资源数据读取速度的目的;通过借助搜索引擎实现条件查询,保证条件查询的查询速度。本发明结合本地Ehcache缓存和Redis集群能够实现资源数据的快速查询,以及结合Solr搜索引擎实现了资源数据的条件查询,从而改进了传统网管监控系统的数据库查询方式带来的速度慢、灵活性差的问题。
附图说明
图1为实施例一提供的资源数据的查询方法流程图;
图2为实施例一提供的单个资源查询的查询方法示意图;
图3为实施例一提供的条件查询的查询方法示意图;
图4为实施例二提供的资源数据的查询方法流程图;
图5为实施例二提供的Redis集群中Redis服务器的分布示意图
图6为实施例三提供的资源数据的查询客户端结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明实施方式作进一步地详细描述。
实施例一:
图1为本实施例提供的资源数据的查询方法流程图,该资源数据按照资源唯一标识Resid分布式缓存在Redis集群中,如图1所示,图1中的方法包括:
S110,接收查询指令,并从查询指令中获取待查询资源数据的资源唯一标识Resid。
在本步骤中,当查询指令为单个资源查询指令时,从查询指令中获取待查询资源数据的唯一标识为:从单个资源查询指令中获取该资源唯一标识Resid;
当查询指令为条件查询指令时,从查询指令中获取待查询资源数据的唯一标识为:根据查询条件从搜索引擎Solr中获取满足查询条件的资源唯一标识Resid集合。
搜索引擎是指根据一定的策略、运用特定的计算机程序从互联网上搜集信息,在对信息进行组织和处理后,为用户提供检索服务,将用户检索相关的信息展示给用户的系统。
本实施例优选地使用Solr搜索引擎,Solr搜索引擎是Apache Lucene项目的开源企业搜索平台,支持全文检索命中显示、分面搜索、动态聚类和数据库集成;具有高度可扩展,并提供分布式搜索和索引复制;支持多种输出格式;具有易于安装和配置的特点,且附带基于HTTP的管理界面。
S120,根据待查询资源数据的资源唯一标识Resid查询本地Ehcache缓存,其中该本地Ehcache缓存采用最近最少使用(Least Recently Used,LRU)策略实现。
Ehcache缓存是一种轻量级的缓存实现方案,通过内存和磁盘的两级缓存实现数据的缓存,因此无需担心容量的问题。
在实际应用中,可以为本地Ehcache缓存设置滑动过期阈值,当一条资源数据在本地Ehcache缓存中的存放时间超过该滑动过期阈值时,从本地Ehcache缓存中删除该资源数据。该滑动过期阈值的具体数值可以根据需要进行调整,例如,设置为1小时。
本地Ehcache缓存在初始化时可以设置为空,即初始化时未缓存任何资源数据,在后续的查询过程中,会不断有新的资源数据追加到本地Ehcache缓存中,则当一条资源数据在本地Ehcache缓存中的时间超过滑动过期阈值时,如超过1小时后,强制删除该条资源数据,这种处理方式实现了一种简单的LRU方案,能够控制缓存的容量,节省缓存空间。
S130,在本地Ehcache缓存中未查询到该资源唯一标识Resid的资源数据时,将该资源唯一标识Resid发送到Redis集群中,并将Redis集群返回的资源数据的哈希表HashMap作为查询结果,将查询结果组装成资源对象ResObject记录到本地Ehcache缓存中。
本实施例中的资源数据的查询方法尤其适用于网管监控系统对其资源数据的查询。
由上可见,本实施例将资源数据进行分布式缓存,利用Redis集群的负载均衡能力和错误恢复能力,实现了资源数据缓存的可扩展性和高可用型;并且基于资源数据的分布式缓存,提供了一种新型的资源数据查询方法,通过借助Ehcache实现本地缓存,避免频繁地远程从Redis集群获取数据,从而显著地加快数据读取速度;通过借助搜索引擎实现了条件查询,保证条件查询速度。本实施例结合本地Ehcache缓存和Redis集群能够实现资源数据的快速查询,以及结合Solr搜索引擎实现了资源数据的条件查询,从而改进了传统网管监控系统的数据库查询方式带来的速度慢、灵活性差的问题。
在本实施例的一具体实现中,对于网管系统,当接收到告警需要查询该告警数据对应的资源数据时,或者需要查询性能数据对应的资源数据时,采用图2所示的方法进行查询。
图2为本实施例提供的单个资源查询的查询方法示意图,假设图2是根据告警数据来查询相应的资源数据,则图2中的查询方法如下:
S210,获取告警数据中告警对象的资源唯一标识Resid。
S220,根据获取的资源唯一标识Resid查询本地Ehcache缓存。
S230,当本地Ehcache缓存中存在该资源唯一标识Resid的资源对象ResObject时,将本地Ehcache缓存中该资源唯一标识Resid的资源对象ResObject作为查询结果。
S240,当本地Ehcache缓存中不存在该资源唯一标识Resid的资源对象时,从Redis集群中获取该资源唯一标识Resid的资源数据的哈希表HashMap并返回。
S250,将该哈希表HashMap组装成资源对象ResObject记录到本地Ehcache缓存中。
在本具体实现中,利用本地Ehcache缓存能够使资源数据的读取速度达到每秒2万次以上。
在本实施例的另一具体实现中,对于网管监控系统,当进行条件查询时,是无法从本地Ehcache缓存和/或Redis集群获取查询结果的,这是因为本地Ehcache缓存和Redis集群中均采用键值对Key-Value形式进行数据缓存,Key是指资源的资源唯一标识Resid,Value是指该资源的资源数据对象,包含了该资源的所有属性。
基于上述分析,在客户端接收到条件查询指令时,采用图3所示的方法进行资源数据的查询,图3为本实施例提供的条件查询的查询方法示意图,如图3所示,通过借助Solr搜索引擎实现资源数据的条件查询,本实施例中的条件包括分页查询,其查询过程如下:
S310,获取查询条件。
S320,使搜索引擎Solr按照获取的查询条件进行搜索查询。
S330,从搜索引擎Solr中获取满足查询条件的资源唯一标识Resid集合。
S340,从Redis集群中获取该资源唯一标识Resid集合中的资源数据的哈希表HashMap集合并返回。
S350,将该哈希表HashMap集合组装成资源对象ResObject集合记录到本地Ehcache缓存中。
需要说明的是,在进行条件的资源数据查询时,本发明优选地根据获取资源唯一标识Resid集合直接查询Resid集群,这是因为在进行条件查询时,通常在本地Ehcache缓存中无法获取全部的满足条件的资源数据,因此本实施例直接查询Resid集群,且无需将返回的资源数据的哈希表HashMap组装成资源对象ResObject记录到本地Ehcache缓存中。
实施例二:
基于与实施例一相同的技术构思,本实施例提供了一种资源数据的查询方法。
图4为本实施例提供的资源数据的查询方法流程图,如图4所示,图4中的方法包括:
S410,接收客户端发送的待查询资源数据的资源唯一标识Resid,在客户端的本地Ehcache缓存中根据该资源唯一标识Resid未查询到相应资源数据。
S420,根据接收到的资源唯一标识Resid从Redis集群中获取该资源唯一标识Resid对应的资源数据的哈希表HashMap,并将该哈希表HashMap作为查询结果发送给客户端,使客户端将接收到的查询结果组装成资源对象ResObject记录到客户端本地的Ehcache缓存中。
需要说明的是,本实施例中的Redis集群可采用集群管理工具Redis-sentinel管理Redis集群,可通过利用集群管理工具Redis-sentinel实现Redis集群的负载均衡能力和错误恢复能力。
对于Redis集群的负载均衡能力,由于集群管理工具Redis-sentinel对该Redis集群中的所有Redis服务器进行分组,因此在将资源数据缓存到Redis集群中时,可以将资源数据比较均衡地写入到用于缓存资源数据的Redis服务器分组中。对于网管监控系统,因其主要包括资源数据、告警数据和性能数据,集群管理工具Redis-sentinel将Redis集群中的Redis服务器分为三组,分别用于缓存资源数据、告警数据和性能数据。假如用于缓存资源数据的Redis服务器分组包括3台Redis服务器,在实际应用中,可以将资源数据的资源唯一标识Resid取模处理,根据取模结果将该资源数据分布式缓存到相应的Redis服务器上,从而保证Redis集群可以通过增加Redis服务器实现资源数据的横向扩展。
对于Redis集群的错误恢复能力,由于集群管理工具Redis-sentinel对该Redis集群中的用于缓存资源数据的多台Redis服务器进行交叉配置,实现多台Redis服务器的主从关系。若在执行某个任务的资源出现故障时,其从服务器执行同一任务的资源可以接着完成任务,从而保证Redis集群可以通过主从Redis服务器实现资源数据的高可用性。
此外,借助于Redis服务器的持久化缓存特性,本实施例将资源数据按照资源唯一标识Resid分布式缓存在Redis集群的多台Redis服务器上,使得重启后原来缓存的资源数据无需重新加载,从而能够实现资源数据的快速读取。
其中,对于Redis集群的错误恢复能力的实现方案,具体为:
参照如5所示,图5为本实施例提供的Redis集群中Redis服务器的分布示意图,本实施例步骤S420中的资源数据按照资源唯一标识Resid分布式缓存在Redis集群中具体为:将资源数据按照其资源唯一标识Resid分布式缓存在Redis集群的多台Redis服务器上,并在每台Redis服务器上启动Redis和RedisSlave服务进程,不同Redis服务器上的Redis和RedisSlave服务进程交叉配置实现多台Redis服务器的主从关系。
则步骤S420中的根据接收到的资源唯一标识Resid从Redis集群中获取该资源唯一标识Resid对应的资源数据的哈希表HashMap具体为:
将接收到的资源唯一标识Resid映射到Redis集群相应的Redis服务器上,判断该相应的Redis服务器的Redis服务进程是否异常,
若该Redis服务器的Redis服务进程无异常,从该Redis服务器的Redis服务进程获取该资源唯一标识Resid的资源数据的哈希表HashMap;
若该Redis服务器的Redis服务进程异常,从该Redis服务器的从服务器的RedisSlave服务进程获取该资源唯一标识Resid的资源数据的哈希表HashMap。
由上可见,本实施例将资源数据进行分布式缓存,利用Redis服务器分布式缓存的集群特性,实现了资源数据缓存的横向扩展、高可用和快速读取。
实施例三:
基于与实施例一相同的技术构思,本实施例提供了一种资源数据的查询客户端,资源数据按照资源唯一标识Resid分布式缓存在Redis集群中。
图6为本实施例提供的资源数据的查询客户端结构示意图,如图6所示,图6中的客户端包括:
资源查询接口61,用于接收查询指令,并从查询指令中获取待查询资源数据的资源唯一标识Resid。
其中,当查询指令为单个资源查询指令时,资源查询接口61具体用于从单个资源查询指令中获取该资源唯一标识Resid;当查询指令为条件查询指令时,资源查询接口61具体用于根据查询条件从搜索引擎Solr中获取满足查询条件的资源唯一标识Resid集合。
本地查询单元62,用于根据待查询资源数据的资源唯一标识Resid查询本地Ehcache缓存,其中该Ehcache缓存采用RLU策略实现。
服务器查询单元63,用于在本地Ehcache缓存中未查询到该资源唯一标识Resid的资源数据时,将该资源唯一标识Resid发送到Redis集群中,并将Redis集群返回的资源数据的哈希表HashMap作为查询结果,将查询结果组装成资源对象ResObject记录到本地Ehcache缓存中。
本实施例将资源数据进行分布式缓存,基于资源数据的分布式缓存,使得本地客户端可以通过Ehcache实现本地缓存,避免频繁地远程从Redis服务器获取数据,从而显著地加快数据读取速度;以及通过搜索引擎实现条件查询,保证条件查询速度。本实施例结合本地Ehcache缓存和Redis集群实现资源数据的快速查询,通过结合Solr搜索引擎能够实现资源数据的条件查询,从而改进了传统网管监控系统的数据库查询方式带来的速度慢、灵活性差的问题。
实施例四:
基于与实施例二和三相同的技术构思,本实施例提供了一种资源数据的查询系统。
本实施例的资源数据的查询系统包括:资源数据查询客户端和Redis集群,资源数据按照资源唯一标识Resid分布式缓存在Redis集群中。
本实施例中资源数据查询客户端组成单元和各单元的具体工作方式可以参见实施例三中的资源数据查询客户端,在此不再赘述。
本实施例中的Redis集群,用于接收客户端发送的资源唯一标识Resid,并根据接收到的资源唯一标识Resid获取该资源唯一标识Resid对应的资源数据的哈希表HashMap,以及将哈希表HashMap作为查询结果发送给客户端。
优选地,本实施例中的Redis集群包括:多台Redis服务器和集群管理单元;其中,资源数据按照其资源唯一标识Resid分布式缓存在Redis集群的多台Redis服务器上,每台Redis服务器上启动Redis和RedisSlave服务进程,不同Redis服务器上的Redis和RedisSlave服务进程交叉配置实现多台Redis服务器的主从关系;
集群管理单元,用于将接收到的资源唯一标识Resid映射到Redis集群相应的Redis服务器上,并判断相应的Redis服务器的Redis服务进程是否异常,
若该Redis服务器的Redis服务进程无异常,从该Redis服务器的Redis服务进程获取该资源唯一标识Resid的资源数据的哈希表HashMap;
若该Redis服务器的Redis服务进程异常,从该Redis服务器的从服务器的RedisSlave服务进程获取该资源唯一标识Resid的资源数据的哈希表HashMap。
需要说明的是,本实施例的资源数据的查询系统应用于网管监控系统。
综上所述,本发明公开了一种资源数据的查询方法、查询客户端和查询系统,本发明将资源数据进行分布式缓存,利用Redis集群的负载均衡能力和错误恢复能力,实现了资源数据的可扩展性和高可用性;并且本发明基于资源数据的分布式缓存,还提供一种新型的资源数据的查询方法,通过借助Ehcache实现本地缓存,避免频繁地远程从Redis集群中获取资源数据,达到加快资源数据读取速度的目的;通过借助搜索引擎实现条件查询,保证条件查询的查询速度。本发明结合本地Ehcache缓存和Redis集群能够实现资源数据的快速查询,以及结合Solr搜索引擎实现了资源数据的条件查询,从而改进了传统网管监控系统的数据库查询方式带来的速度慢、灵活性差的问题。
以上所述仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等,均包含在本发明的保护范围内。

Claims (10)

1.一种资源数据的查询方法,其特征在于,所述资源数据按照资源唯一标识Resid分布式缓存在Redis集群中,所述资源数据的查询方法包括:
接收查询指令,并从所述查询指令中获取待查询资源数据的资源唯一标识Resid;
当进行非条件查询时,根据所述待查询资源数据的资源唯一标识Resid查询本地Ehcache缓存;在本地Ehcache缓存中未查询到该资源唯一标识Resid的资源数据时,将该资源唯一标识Resid发送到所述Redis集群中,并将所述Redis集群返回的资源数据的哈希表HashMap作为查询结果,将所述查询结果组装成资源对象ResObject记录到本地Ehcache缓存中;
当进行条件查询时,根据所述待查询资源数据的资源唯一标识Resid直接查询所述Resid集群,且无需将返回的资源数据的哈希表HashMap组装成资源对象ResObject记录到本地Ehcache缓存中。
2.根据权利要求1所述的资源数据的查询方法,其特征在于,
当所述查询指令为单个资源查询指令时,所述从所述查询指令中获取待查询资源数据的唯一标识为:从所述单个资源查询指令中获取该资源唯一标识Resid;
当所述查询指令为条件查询指令时,所述从所述查询指令中获取待查询资源数据的唯一标识为:根据查询条件从搜索引擎Solr中获取满足查询条件的资源唯一标识Resid集合。
3.一种资源数据的查询方法,其特征在于,所述资源数据按照资源唯一标识Resid分布式缓存在Redis集群中,所述资源数据的查询方法包括:
接收客户端发送的待查询资源数据的资源唯一标识Resid,当进行非条件查询时,若在客户端的本地Ehcache缓存中根据该资源唯一标识Resid未查询到相应资源数据;则根据接收到的所述资源唯一标识Resid从所述Redis集群中获取该资源唯一标识Resid对应的资源数据的哈希表HashMap,并将所述哈希表HashMap作为查询结果发送给客户端,使所述客户端将接收到的查询结果组装成资源对象ResObject记录到客户端本地的Ehcache缓存中;
当进行条件查询时,根据所述待查询资源数据的资源唯一标识Resid直接查询所述Resid集群,且无需将返回的资源数据的哈希表HashMap组装成资源对象ResObject记录到本地Ehcache缓存中。
4.根据权利要求3所述的资源数据的查询方法,其特征在于,所述资源数据按照资源唯一标识Resid分布式缓存在Redis集群中包括:
将所述资源数据按照其资源唯一标识Resid分布式缓存在Redis集群的多台Redis服务器上,并在每台Redis服务器上启动Redis和RedisSlave服务进程,不同Redis服务器上的Redis和RedisSlave服务进程交叉配置实现多台Redis服务器的主从关系;
则所述根据接收到的所述资源唯一标识Resid从所述Redis集群中获取该资源唯一标识Resid对应的资源数据的哈希表HashMap包括:
将接收到的所述资源唯一标识Resid映射到所述Redis集群相应的Redis服务器上,判断所述相应的Redis服务器的Redis服务进程是否异常,
若所述Redis服务器的Redis服务进程无异常,从所述Redis服务器的Redis服务进程获取该资源唯一标识Resid的资源数据的哈希表HashMap;
若所述Redis服务器的Redis服务进程异常,从所述Redis服务器的从服务器的RedisSlave服务进程获取该资源唯一标识Resid的资源数据的哈希表HashMap。
5.一种资源数据的查询客户端,其特征在于,所述资源数据按照资源唯一标识Resid分布式缓存在Redis集群中,所述资源数据的查询客户端包括:
资源查询接口,用于接收查询指令,并从所述查询指令中获取待查询资源数据的资源唯一标识Resid;
本地查询单元,用于当进行非条件查询时,根据所述待查询资源数据的资源唯一标识Resid查询本地Ehcache缓存;
服务器查询单元,用于在本地Ehcache缓存中未查询到该资源唯一标识Resid的资源数据时,将该资源唯一标识Resid发送到所述Redis集群中,并将所述Redis集群返回的资源数据的哈希表HashMap作为查询结果,将所述查询结果组装成资源对象ResObject记录到本地Ehcache缓存中;
服务器查询单元,还用于当进行条件查询时,根据所述待查询资源数据的资源唯一标识Resid直接查询所述Resid集群,且无需将返回的资源数据的哈希表HashMap组装成资源对象ResObject记录到本地Ehcache缓存中。
6.根据权利要求5所述的资源数据的查询客户端,其特征在于,
当所述查询指令为单个资源查询指令时,所述资源查询接口,具体用于从所述单个资源查询指令中获取该资源唯一标识Resid;
当所述查询指令为条件查询指令时,所述资源查询接口,具体用于根据查询条件从搜索引擎Solr中获取满足查询条件的资源唯一标识Resid集合。
7.一种资源数据的查询系统,其特征在于,包括:资源数据查询客户端和Redis集群,资源数据按照资源唯一标识Resid分布式缓存在所述Redis集群中,所述资源数据查询客户端包括:资源查询接口、本地查询单元和服务器查询单元;
所述资源查询接口,用于接收查询指令,并从所述查询指令中获取待查询资源数据的资源唯一标识Resid;
所述本地查询单元,用于当进行非条件查询时,根据所述待查询资源数据的资源唯一标识Resid查询本地Ehcache缓存;
所述服务器查询单元,用于在本地Ehcache缓存中未查询到该资源唯一标识Resid的资源数据时,将该资源唯一标识Resid发送到所述Redis集群中,并将所述Redis集群返回的资源数据的哈希表HashMap作为查询结果,将所述查询结果组装成资源对象ResObject记录到本地Ehcache缓存中;还用于当进行条件查询时,根据所述待查询资源数据的资源唯一标识Resid直接查询所述Resid集群,且无需将返回的资源数据的哈希表HashMap组装成资源对象ResObject记录到本地Ehcache缓存中;
所述Redis集群,用于接收客户端发送的所述资源唯一标识Resid,并根据接收到的所述资源唯一标识Resid获取该资源唯一标识Resid对应的资源数据的哈希表HashMap,以及将所述哈希表HashMap作为查询结果发送给客户端。
8.根据权利要求7所述的资源数据的查询系统,其特征在于,所述资源数据的查询系统还包括:Solr搜索引擎;
当所述查询指令为单个资源查询指令时,所述资源查询接口,具体用于从所述单个资源查询指令中获取该资源唯一标识Resid;
当所述查询指令为条件查询指令时,所述资源查询接口,具体用于将查询条件发送给Solr搜索引擎并接收Solr搜索引擎发送的资源唯一标识Resid集合;
所述Solr搜索引擎,用于接收资源查询接口发送的查询条件,并将满足查询条件的资源唯一标识Resid集合发送给所述资源查询接口。
9.根据权利要求7所述的资源数据的查询系统,其特征在于,所述Redis集群包括:多台Redis服务器和集群管理单元;
所述资源数据按照其资源唯一标识Resid分布式缓存在Redis集群的多台Redis服务器上,每台Redis服务器上启动Redis和RedisSlave服务进程,不同Redis服务器上的Redis和RedisSlave服务进程交叉配置实现多台Redis服务器的主从关系;
所述集群管理单元,用于将接收到的所述资源唯一标识Resid映射到所述Redis集群相应的Redis服务器上,判断所述相应的Redis服务器的Redis服务进程是否异常,
若所述Redis服务器的Redis服务进程无异常,从所述Redis服务器的Redis服务进程获取该资源唯一标识Resid的资源数据的哈希表HashMap;
若所述Redis服务器的Redis服务进程异常,从所述Redis服务器的从服务器的RedisSlave服务进程获取该资源唯一标识Resid的资源数据的哈希表HashMap。
10.根据权利要求7至9任一项所述的资源数据的查询系统,其特征在于,所述资源数据的查询系统应用于网管监控系统。
CN201610073675.8A 2016-02-02 2016-02-02 一种资源数据的查询方法、查询客户端和查询系统 Active CN107025243B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610073675.8A CN107025243B (zh) 2016-02-02 2016-02-02 一种资源数据的查询方法、查询客户端和查询系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610073675.8A CN107025243B (zh) 2016-02-02 2016-02-02 一种资源数据的查询方法、查询客户端和查询系统

Publications (2)

Publication Number Publication Date
CN107025243A CN107025243A (zh) 2017-08-08
CN107025243B true CN107025243B (zh) 2020-04-24

Family

ID=59524410

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610073675.8A Active CN107025243B (zh) 2016-02-02 2016-02-02 一种资源数据的查询方法、查询客户端和查询系统

Country Status (1)

Country Link
CN (1) CN107025243B (zh)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109582458A (zh) * 2017-09-28 2019-04-05 北京国双科技有限公司 资源信息加载方法、装置、存储介质及处理器
CN107679203B (zh) * 2017-10-12 2020-11-13 广州华多网络科技有限公司 一种Redis内部数据库调用方法及系统
CN108280227A (zh) * 2018-01-26 2018-07-13 北京奇虎科技有限公司 基于缓存的数据信息处理方法及装置
CN108491466B (zh) * 2018-03-06 2022-08-30 平安科技(深圳)有限公司 电子装置、访问指令信息获取方法及存储介质
CN108829837A (zh) * 2018-06-19 2018-11-16 北京五八信息技术有限公司 一种信息查询方法、装置、设备及计算机可读存储介质
CN109040272A (zh) * 2018-08-16 2018-12-18 北京中科梧桐网络科技有限公司 一种java统一缓存处理框架模型
CN109063210B (zh) * 2018-09-25 2022-07-08 郑州云海信息技术有限公司 存储系统的资源对象查询方法、装置、设备及存储介质
CN109151074B (zh) * 2018-10-29 2023-05-23 南京感度信息技术有限责任公司 基于Redis的集中式缓存队列服务架构方法及网络结构
CN110188119A (zh) * 2019-06-10 2019-08-30 北京百度网讯科技有限公司 用于获取数据的方法和装置
CN110515987A (zh) * 2019-08-30 2019-11-29 恩亿科(北京)数据科技有限公司 一种数据分析结果的查询方法及装置
CN110866034B (zh) * 2019-10-25 2022-12-13 福建天泉教育科技有限公司 服务端节流的方法、存储介质
CN110636341B (zh) * 2019-10-25 2021-11-09 四川虹魔方网络科技有限公司 支持大并发的多层级、细粒度缓存机制launcher接口优化方法
CN111737303A (zh) * 2020-06-28 2020-10-02 中国平安财产保险股份有限公司 数据查询方法、装置、计算机设备及存储介质
CN114490917A (zh) * 2020-11-11 2022-05-13 北京神州泰岳软件股份有限公司 一种全文检索功能的实现方法、装置与电子设备
CN112579607B (zh) * 2020-12-24 2023-05-16 网易(杭州)网络有限公司 数据访问方法和装置、存储介质、电子设备
CN113282619A (zh) * 2021-04-13 2021-08-20 国网山东省电力公司物资公司 一种数据快速查询方法及系统
CN113596177B (zh) * 2021-08-13 2023-06-27 四川虹美智能科技有限公司 智能家居设备的ip地址的解析方法和装置
CN114218469B (zh) * 2021-12-15 2022-09-02 掌阅科技股份有限公司 资源策略处理方法、计算设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102004766A (zh) * 2010-11-09 2011-04-06 北京神州泰岳软件股份有限公司 基于信息系统的可配置信息查询方法及系统
CN103473267A (zh) * 2013-08-09 2013-12-25 深圳市中科新业信息科技发展有限公司 数据存储查询方法及系统
CN104599032A (zh) * 2014-11-28 2015-05-06 国家电网公司 一种面向资源管理的分布式内存电网构建方法及系统
CN104753966A (zh) * 2013-12-25 2015-07-01 明博教育科技有限公司 一种基于服务器和客户端缓存的资源文件查询方法及系统
CN105138592A (zh) * 2015-07-31 2015-12-09 武汉虹信技术服务有限责任公司 一种基于分布式架构的日志数据存储和检索方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9135261B2 (en) * 2009-12-15 2015-09-15 Emc Corporation Systems and methods for facilitating data discovery
CN104360918B (zh) * 2014-10-15 2017-08-29 许继电气股份有限公司 一种智能变电站系统自诊断与自恢复方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102004766A (zh) * 2010-11-09 2011-04-06 北京神州泰岳软件股份有限公司 基于信息系统的可配置信息查询方法及系统
CN103473267A (zh) * 2013-08-09 2013-12-25 深圳市中科新业信息科技发展有限公司 数据存储查询方法及系统
CN104753966A (zh) * 2013-12-25 2015-07-01 明博教育科技有限公司 一种基于服务器和客户端缓存的资源文件查询方法及系统
CN104599032A (zh) * 2014-11-28 2015-05-06 国家电网公司 一种面向资源管理的分布式内存电网构建方法及系统
CN105138592A (zh) * 2015-07-31 2015-12-09 武汉虹信技术服务有限责任公司 一种基于分布式架构的日志数据存储和检索方法

Also Published As

Publication number Publication date
CN107025243A (zh) 2017-08-08

Similar Documents

Publication Publication Date Title
CN107025243B (zh) 一种资源数据的查询方法、查询客户端和查询系统
US8965914B2 (en) Grouping identity records to generate candidate lists to use in an entity and relationship resolution process
CN105827706B (zh) 消息推送装置及方法
EP2545458B1 (en) Method and memory cache data center
CN105159845A (zh) 存储器读取方法
CN110597852B (zh) 数据处理方法、装置、终端及存储介质
CN106997557B (zh) 订单信息采集方法及装置
US20100306234A1 (en) Cache synchronization
RU2009136171A (ru) Кэширование в памяти совместно используемых настраиваемых данных множества арендаторов
US12056089B2 (en) Method and system for deleting obsolete files from a file system
JP2006178554A5 (zh)
CN110071978A (zh) 一种集群管理的方法及装置
CN101330431B (zh) 一种即时信息存储方法和系统
CN104182435A (zh) 基于数据缺失标记的信息检索系统及方法
WO2022062184A1 (zh) 高并发查询方法、智能终端及存储介质
CN103034650B (zh) 一种数据处理系统和方法
US8239391B2 (en) Hierarchical merging for optimized index
CN102724301B (zh) 云数据库系统以及云数据读写处理方法、设备
CN113553306B (zh) 数据处理方法及数据存储管理系统
CN113377777B (zh) 数据加载方法、设备、计算机程序产品及存储介质
EP3507699B1 (en) Method and systems for master establishment using service-based statistics
EP2765517B1 (en) Data stream splitting for low-latency data access
CN116257557A (zh) 数据查询方法、系统、介质、装置和计算设备
CN105162891A (zh) 一种基于ip网络的数据存储方法
CN116226250A (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
CP02 Change in the address of a patent holder
CP02 Change in the address of a patent holder

Address after: Room 818, 8 / F, 34 Haidian Street, Haidian District, Beijing 100080

Patentee after: BEIJING ULTRAPOWER SOFTWARE Co.,Ltd.

Address before: 100089 Beijing city Haidian District wanquanzhuang Road No. 28 Wanliu new building 6 storey block A Room 601

Patentee before: BEIJING ULTRAPOWER SOFTWARE Co.,Ltd.