Query method and device based on archived resume

Abstract

The invention discloses an archived resume-based query method and equipment. The method comprises the following steps: migrating resume data of an enterprise tenant in a target recruitment cycle to an archived database associated with the enterprise tenant; extracting a current archiving identifier; storing the current archiving identifier in a thread local variable of the current thread; when the operation related to the resume data is executed through the service interface, intercepting the data access operation through the section interceptor; when the data access operation relates to cache query, obtaining a current archiving identifier from a thread local variable, combining the current archiving identifier with an original cache key generated in service logic to obtain a new cache key, and accessing the cache by using the new cache key; and when the data access operation relates to database query, obtaining a current archiving identifier from a thread local variable, searching archiving database connection information based on the current archiving identifier, and performing query on the archiving database. The business continuity can be guaranteed, and the historical data query efficiency can be improved.

Description

Technical Field

[0001] This application relates to the field of Internet technology, particularly to the field of Internet information service technology, and especially to a method, device, system, medium, and product for querying archived resumes. Background Technology

[0002] In the field of campus recruitment, enterprises or organizations (hereinafter referred to as "enterprise tenants") conduct recruitment activities annually for specific recruitment cycles such as autumn and spring recruitment, thereby accumulating a large amount of applicant resume data. For purposes such as data retention, audit verification, or future talent pool development, long-term archiving and storage of resume data from historical recruitment cycles, rather than immediate deletion after the recruitment cycle ends, has significant commercial and compliance value. An effective resume data archiving solution ensures that enterprises can quickly trace and review past recruitment information when needed, while avoiding the continuous burden of massive historical data on the performance of the operating recruitment system. It is a crucial technical aspect supporting the data asset management of enterprise recruitment operations.

[0003] Currently, common resume data archiving solutions often employ a strategy of scheduled batch processing and physical isolation. Specifically, the system typically archives data from enterprise tenants marked "pending archiving" at fixed points each year, such as before the start of a new round of campus recruitment. This process usually involves: first, creating a completely new business account and corresponding new database for the enterprise tenants that need to start a new recruitment cycle, and reconfiguring their business processes and field definitions; second, within a pre-set downtime maintenance window, migrating the enterprise tenants' resume data from the previous cycle from their current main business database to a separate, centralized historical archive database; and finally, stopping or restricting access to the old business account. This centralized archive database may store historical data from numerous different enterprise tenants.

[0004] However, the aforementioned centralized, fixed-time batch archiving operations inevitably require system downtime, resulting in the unavailability of all related services during this period, lack of flexibility, and impact on business continuity. Furthermore, after the resume data is migrated to the centralized archive database, it is separated from the original business system logic. When enterprise tenants need to query, export, or audit their historical resumes, they cannot operate directly and transparently through the original business interface. Instead, they must rely on the database administrator to perform a complex manual data extraction and recovery process, which is cumbersome and results in low query efficiency, failing to effectively meet the query business needs. Summary of the Invention

[0005] In view of this, embodiments of this application provide a method, device, system, medium, and product for querying archived resumes, which can solve at least one of the above-mentioned technical problems.

[0006] In a first aspect, embodiments of this application provide a query method based on archived resumes. The method includes: in response to receiving an archiving instruction for a target recruitment period, creating a dedicated archived database for the enterprise tenant issuing the archiving instruction, and migrating the enterprise tenant's resume data within the target recruitment period from the main business database to the archived database associated with the enterprise tenant, wherein the dedicated archived database is only used to store the enterprise tenant's resume data within the target recruitment period; upon receiving a client's query request for archived resumes, extracting an archive identifier from the HTTP request header of the query request to obtain a current archive identifier, wherein the archive identifier is used to identify the archived database; saving the current archive identifier to a thread-local variable of the current thread; and when accessed through a business interface... When performing operations related to resume data, the data access operation is intercepted using an aspect interceptor. When the data access operation involves cache querying, the current archive identifier is obtained from the thread-local variable, and combined with the original cache key generated in the business logic to obtain a new cache key corresponding to the current archive identifier. The new cache key is then used to access the cache to retrieve the corresponding resume data. When the data access operation involves database querying, the current archive identifier is obtained from the thread-local variable, and the corresponding archive database connection information is looked up based on the current archive identifier. The query is then performed on the archive database based on the found archive database connection information to retrieve the resume data. The retrieved resume data is then returned to the client.

[0007] Secondly, embodiments of this application provide a query device based on archived resumes. The device includes: a data migration module, configured to, in response to receiving an archiving instruction for a target recruitment period, create a dedicated archive database for the enterprise tenant issuing the archiving instruction, and migrate the enterprise tenant's resume data within the target recruitment period from the main business database to the archive database associated with the enterprise tenant, wherein the dedicated archive database is only used to store the enterprise tenant's resume data within the target recruitment period; an extraction module, configured to, upon receiving a client's query request for archived resumes, extract an archive identifier from the HTTP request header of the query request to obtain the current archive identifier, wherein the archive identifier is used to identify the archive database; a storage module, configured to save the current archive identifier to a thread-local variable of the current thread; and an interception module, configured to, when a query request is received from a client for archived resumes, extract an archive identifier from the HTTP request header of the query request to obtain the current archive identifier, wherein the archive identifier is used to identify the archive database; a storage module, configured to, when a query request is received from a client for archived resumes, extract an archive identifier from the HTTP request header of the query request to obtain the current archive identifier, wherein the archive identifier is used to identify the archive database; a storage module, configured to, when a query request is received from a client, extract an archive identifier from the HTTP request header of the query request to obtain the current archive identifier; and an interception module, configured to, when a query request is received from a client ...; and an interception module, configured to, when a query request is received from a client, extract an archive identifier from the HTTP request to obtain the current archive identifier; and an interception module, configured to, when a query request is received from a When the interface performs operations related to resume data, it intercepts the data access operations using aspect interceptors. The first query module retrieves the current archive identifier from a thread-local variable when the data access operation involves cache queries. It combines this identifier with the original cache key generated in the business logic to obtain a new cache key corresponding to the current archive identifier, and uses this new cache key to access the cache to retrieve the corresponding resume data. The second query module retrieves the current archive identifier from a thread-local variable when the data access operation involves database queries. It then searches for the corresponding archive database connection information based on this identifier and performs a query on the archive database based on the searched connection information to retrieve the resume data. The return module returns the retrieved resume data to the client.

[0008] Thirdly, embodiments of this application provide an electronic device, including: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the steps of the query method based on archived resumes as described in the first aspect.

[0009] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the steps of the query method based on archived resumes as described in the first aspect.

[0010] Fifthly, embodiments of this application provide a computer program product stored in a non-volatile storage medium, which, when executed by a processor, implements the steps of the query method based on archived resumes as described in the first aspect.

[0011] In a sixth aspect, embodiments of this application provide a chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the steps of the query method based on archived resumes as described in the first aspect.

[0012] This application provides a method, device, system, medium, and product for querying archived resumes. By responding to archiving instructions for a target recruitment cycle and triggering archiving operations instantly, and creating a dedicated archived database for data migration, it achieves on-demand, real-time data archiving capabilities. This overcomes the limitations of traditional solutions that rely on fixed downtime windows for batch processing, thus resolving service interruptions and business discontinuities caused by archiving operations. Secondly, by establishing an independent and identifiable archived database for each enterprise tenant's historical resume data, separating historical data from currently active data in physical storage, the main business system environment can continue to be used across different recruitment cycles without requiring a complete rebuild for each new cycle, thereby reducing repetitive configuration work and resource overhead associated with starting a new recruitment cycle. Furthermore, by extracting an archive identifier from the request, passing this identifier using a thread-local variable throughout the request's lifecycle, and dynamically routing to the corresponding archived database or cache key at the data access layer based on this identifier using an aspect-oriented interceptor, this solution constructs a unified and transparent historical data access channel at the application logic layer. Building upon this foundation, users can directly and seamlessly query archived resume data through standard business interfaces, without needing to be aware of the underlying physical storage location of the data, nor requiring database administrators to perform complex manual data extraction and recovery operations. This resolves the pain points of inconvenient access and cumbersome processes for historical data. Thus, this application enables efficient and flexible archiving of resume data while ensuring business continuity, reducing system maintenance and configuration costs, and improving the convenience and efficiency of historical data queries. Attached Figure Description

[0013] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings of the embodiments of this application will be briefly described below.

[0014] Figure 1 This is a flowchart illustrating a query method based on archived resumes provided in an embodiment of this application; Figure 2 This is an exemplary schematic diagram of an enterprise tenant interface provided in an embodiment of this application; Figure 3 This is an exemplary flowchart illustrating a query method based on archived resumes provided in another embodiment of this application; Figure 4 This is a schematic diagram of the structure of a query device based on archived resumes provided in an embodiment of this application; Figure 5 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0015] The principles and spirit of this application will be described below with reference to several exemplary embodiments. It should be understood that these embodiments are provided to make the principles and spirit of this application clearer and more thorough, enabling those skilled in the art to better understand and implement the principles and spirit of this application. The exemplary embodiments provided herein are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments described herein without inventive effort are within the scope of protection of this application.

[0016] In this document, terms such as first, second, and third are used only to distinguish one entity (or operation) from another entity (or operation), and are not intended to require or imply any order or relationship between these entities (or operations).

[0017] The following description, in conjunction with the accompanying drawings, details the query method based on archived resumes provided in this application through specific embodiments and application scenarios.

[0018] Figure 1 This is a flowchart illustrating a query method based on archived resumes provided in an embodiment of this application. The executing entity of this query method based on archived resumes can be a query device based on archived resumes.

[0019] In some examples, this resume-based query device can be applied to a server.

[0020] The following example illustrates the resume-based query method of this application, using a resume-based query device as the execution entity. It should be noted that the aforementioned execution entity and application scenario do not constitute a limitation on this application.

[0021] like Figure 1 As shown, the query method based on archived resumes provided in this application embodiment may include steps 110-170.

[0022] Step 110: In response to receiving an archiving instruction for the target recruitment cycle, create a dedicated archiving database for the enterprise tenant that issued the archiving instruction, and migrate the resume data of the enterprise tenant during the target recruitment cycle from the main business database to the archiving database associated with the enterprise tenant. Step 120: Upon receiving a query request from a client for an archived resume, extract the archive identifier from the HTTP request header of the query request to obtain the current archive identifier; Step 130: Save the current archive identifier to the thread-local variable of the current thread; Step 140: When performing operations related to resume data through the business interface, the data access operation is intercepted through the aspect interceptor; Step 150: When the data access operation involves cache query, obtain the current archive identifier from the thread local variable, combine the current archive identifier with the original cache key generated in the business logic to obtain a new cache key corresponding to the current archive identifier, and use the new cache key to access the cache to obtain the corresponding resume data from the cache. Step 160: When the data access operation involves database query, obtain the current archive identifier from the thread local variable, look up the corresponding archive database connection information based on the current archive identifier, and perform a query on the archive database based on the found archive database connection information to obtain resume data from the archive database. Step 170: Return the obtained resume data to the client.

[0023] The resume-based query method provided in this application, by responding to an archiving instruction for a target recruitment cycle and triggering an archiving operation immediately, and creating a dedicated archiving database for data migration, achieves on-demand, real-time data archiving capabilities. This overcomes the limitations of traditional solutions that rely on fixed downtime windows for batch processing, thereby resolving service interruptions and business discontinuities caused by archiving operations. Secondly, by establishing an independent and identifiable archiving database for each enterprise tenant's historical resume data, separating historical data from currently active data in physical storage, the main business system environment (including business process configurations, account systems, etc.) can continue to be used in different recruitment cycles without needing to be completely rebuilt for each new cycle, thus reducing repetitive configuration work and resource overhead when starting a new recruitment cycle. Furthermore, by extracting an archiving identifier from the request, passing this identifier using a thread-local variable throughout the request's lifecycle, and dynamically routing to the corresponding archiving database or cache key at the data access layer based on this identifier using an aspect interceptor, this solution constructs a unified and transparent historical data access channel at the application logic layer. Building upon this foundation, users can directly and seamlessly query archived resume data through standard business interfaces, without needing to be aware of the underlying physical storage location of the data, nor requiring database administrators to perform complex manual data extraction and recovery operations. This resolves the pain points of inconvenient access and cumbersome processes for historical data. Thus, this application enables efficient and flexible archiving of resume data while ensuring business continuity, reducing system maintenance and configuration costs, and improving the convenience and efficiency of historical data queries.

[0024] The specific implementation of the above steps will be described in detail below with reference to specific embodiments.

[0025] In step 110, in response to receiving an archiving instruction for a target recruitment period, a dedicated archiving database is created for the enterprise tenant that issued the archiving instruction, and the resume data of the enterprise tenant during the target recruitment period is migrated from the main business database to the archiving database associated with the enterprise tenant.

[0026] In step 110, the dedicated archiving database is used solely to store resume data from enterprise tenants within the target recruitment cycle. The target recruitment cycle can be a specific historical recruitment period that has ended and requires data archiving, distinct from ongoing recruitment cycles, such as "2024 Autumn Campus Recruitment." The (dedicated) archiving database refers to a database instance specifically created for a particular enterprise tenant's specific target recruitment cycle to store its historical resume data long-term. It is physically isolated from the main business database and logically uniquely corresponds to the enterprise tenant identifier and the recruitment cycle identifier. The archiving command can be triggered manually or automatically when the system detects the end of the target recruitment cycle.

[0027] For example, when the server receives an archiving instruction for a specific recruitment period, "2024 Autumn Recruitment," for "Company A" through the management backend, it can respond by calling the cloud database service API to create a new physical database instance for the enterprise tenant, serving as its dedicated archiving database for the "2024 Autumn Recruitment" period. Afterward, the system initiates a data migration task, selecting all resume data records belonging to "Company A" and generated during the "2024 Autumn Recruitment" period from the main business database. Using batch data transfer tools or programs, this data is securely and completely copied to the created dedicated archiving database. Optionally, after the migration is complete, this archived data can be deleted or marked from the main business database to free up space and improve performance.

[0028] The archive database can be deployed independently or belong to the same database cluster as the main business database but logically isolated using different schemas or database names. The system records the mapping relationship between the connection information of the archive database and the enterprise tenant identifier and recruitment cycle identifier in the configuration center.

[0029] In step 120, when a client requests a query for an archived resume, the archive identifier is extracted from the HTTP request header of the query request to obtain the current archive identifier.

[0030] In step 120, the archive identifier is used to identify the archive database. The archive identifier can be a combination of the enterprise tenant identifier and the recruitment cycle identifier, such as "CompanyA_2024Autumn", or a unique key value mapped to this combination within the system.

[0031] For example, when the client is a browser used by the company's HR department, and it accesses the system's "Historical Talent Pool" interface and selects to view the resume list for "Company A - 2024 Autumn Recruitment," it will send a query request to the server. This request will carry the archive identifier "CompanyA_2024Autumn" in a predefined field in its HTTP request header, such as "X-Archive-ID." The server-side request controller receives this request, and before the request enters the business logic, a filter or interceptor reads the value of the predefined field, "CompanyA_2024Autumn," from the HTTP request header and parses it as the "current archive identifier."

[0032] In step 130, the current archive identifier is saved to the thread-local variable of the current thread.

[0033] In step 130, the parsed current archive identifier can be set to a thread-local variable bound to the worker thread currently processing the request, such as Java's ThreadLocal, using a filter or a dedicated aspect component. At this point, the current archive identifier is visible to all subsequent code logic serving the request throughout its entire lifecycle.

[0034] In step 140, when an operation related to resume data is performed through a business interface, the data access operation is intercepted through an aspect interceptor.

[0035] In step 140, the server's control layer calls a method of a business service interface, which contains the core logic for querying resume data. Inside the business interface method, when the actual data access code is executed, such as calling MyBatis' Mapper method to access the database or calling RedisTemplate to operate the cache, the predefined data routing aspect interceptor uses an aspect-oriented programming (AOP) framework to intercept the data access method before it is called.

[0036] In step 150, when the data access operation involves cache query, the current archive identifier is obtained from the thread local variable, the current archive identifier is combined with the original cache key generated in the business logic to obtain a new cache key corresponding to the current archive identifier, and the cache is accessed using the new cache key to obtain the corresponding resume data from the cache.

[0037] In step 150, the aspect interceptor first determines whether the intercepted operation belongs to cache query. If the business interface method name matches get or query and the target object is a cache client, it is confirmed that the data access operation involves cache query, and the saved current archive identifier is obtained from the thread local variable of the current thread.

[0038] Next, retrieve the key originally generated for query caching in the business logic (the original cache key), such as "resume:list:page:1:size:10". Combine the current archive identifier with this original cache key according to a predefined rule, for example, concatenate them as: "CompanyA_2024Autumn:resume:list:page:1:size:10".

[0039] In this way, the new cache key provides namespace isolation, ensuring that cached data from different companies and at different time periods will not conflict even if the business logic is the same. Using the refactored new cache key, a cache client (such as Redis) is invoked for querying. If a match is found, the cached list of resume data is returned directly; otherwise, the process continues.

[0040] In step 160, when the data access operation involves a database query, the current archive identifier is obtained from the thread local variable, the corresponding archive database connection information is found based on the current archive identifier, and a query is executed on the archive database based on the found archive database connection information to obtain resume data from the archive database.

[0041] In step 160, in the aspect interceptor, if it is determined that the intercepted operation is a database query, such as the Mapper method that executes SQL, then the current archive identifier is also obtained from the thread-local variable.

[0042] Here, the server maintains a configuration table that records the actual connection information of each archive identifier and its corresponding archive database. This information may include, for example, the Java Database Connectivity (JDBC) URL, username, and password. The aspect interceptor uses the obtained current archive identifier, such as "CompanyA_2024Autumn," as the key to query the configuration table and retrieve the archive database connection information. After obtaining the archive database connection information, the aspect interceptor directs the connection for this database operation to the archive database created in step 110, for example, the archive database dedicated to "Company A-2024 Autumn Recruitment." Subsequently, the intercepted database query method is allowed to proceed. The SQL executed by this method will then run on the correct archive database, retrieving the corresponding historical resume data.

[0043] It should be noted that this application does not specify the execution order of steps 150 and 160.

[0044] Step 170 involves returning the acquired resume data to the client.

[0045] In step 170, resume data retrieved from either the cache or the archive database will be returned as the return value of the business interface method, following the original call chain. After receiving the data returned by the business layer, the controller encapsulates it into a standard format (such as JSON) and returns it to the client that initiated the query via an HTTP response. This achieves real-time, isolated archiving of historical resume data, as well as transparent and precise access to the archived data through the original business interface.

[0046] According to an embodiment of this application, optionally, after migrating the resume data of the enterprise tenant during the target recruitment period from the main business database to the archive database associated with the enterprise tenant in step 110, it may further include: migrating the index data of the resume search of the enterprise tenant during the target recruitment period from the main business search engine to the archive search engine created for the enterprise tenant.

[0047] Specifically, after completing the migration of resume data from the main business database to the archive database, the system initiates an associated index data migration task. Based on this index data migration task, a dedicated archive search engine instance or index is created or allocated for the enterprise tenant in the search service cluster. From the main business search engine, all index data corresponding to the migrated resume data is located and extracted, including the resume's text content, fields, and other searchable information. This index data is then migrated or rebuilt into the newly created archive search engine.

[0048] Thus, building upon the archiving of structured resume data, unstructured index data used for rapid retrieval is further archived synchronously. By migrating the index data for resume searches within a specific enterprise tenant's target recruitment cycle to the archived search engine created for them, complete archiving and isolation of historical resume full-text search capabilities are achieved. This ensures that when users query archived resumes through business interfaces, they can not only obtain structured data but also efficiently perform complex search operations such as fuzzy searches and conditional filtering using the search engine. This achieves physical data isolation, releases main system resources, and fully preserves the searchability of historical resume data, providing a consistent and efficient search experience as when querying current data.

[0049] According to embodiments of this application, optionally, the archive identifier includes a combination of an enterprise tenant identifier and a recruitment cycle identifier, or the archive identifier is a unique key mapped to the archive database of a specific enterprise tenant in a specific recruitment cycle.

[0050] Among them, the enterprise tenant identifier is a code or string used to uniquely identify an enterprise tenant in the system; the recruitment cycle identifier is a code or string used to uniquely identify a specific recruitment cycle, such as "2024Autumn".

[0051] There are two ways to generate or obtain archive identifiers. The first is a combination method: when an archive identifier needs to be generated, such as when generating a query request or record configuration, the enterprise tenant identifier and the recruitment cycle identifier are directly concatenated using a predetermined separator to generate a string such as "CompanyA_2024Autumn". The second is a mapping key method: when the archive database is created, the system generates a globally unique key, such as a UUID, and persistently stores the correspondence between this unique key, the enterprise tenant identifier, the recruitment cycle identifier, and the archive database connection information. When the archive identifier is needed subsequently, this unique key can be used directly, or it can be retrieved by querying the enterprise tenant identifier and the recruitment cycle identifier.

[0052] In this embodiment, it is ensured that the archive identifier can uniquely and accurately point to the target archive database. Whether it is through the combination of enterprise tenant identifier and recruitment cycle identifier, or through the internal decoupling method of the mapped unique key, it provides a reliable routing basis for cache key combination and database connection lookup based on the identifier in subsequent steps, which ensures the accuracy of data routing from the root and avoids erroneous access between data from different enterprise tenants or different recruitment cycles.

[0053] According to an embodiment of this application, optionally, step 130, which saves the current archive identifier to the thread local variable of the current thread, may specifically include: when a query request is intercepted by the aspect interceptor, before executing the business logic of the business interface, storing the extracted current archive identifier in the thread local variable bound to the current request thread; the method may also include: after the business interface is executed, performing post-processing through the aspect interceptor to clear the current archive identifier stored in the thread local variable.

[0054] Specifically, after the query request is received but before the business logic of the business interface is executed, the aspect interceptor is triggered first. It extracts the current archive identifier from the request and stores it in the thread-local variable of the current thread. Only then can the business interface method be executed. After the business interface method has finished executing, that is, after the data access operation is completed and the result is about to be returned, the post-processing logic defined in the aspect interceptor actively removes or sets the current archive identifier previously stored in the same thread-local variable to null.

[0055] In the embodiments of the present application, by defining to save an identifier before the execution of the business logic and clear the identifier after the execution of the business logic, a self-cleaning context passing mechanism that strictly corresponds to the life cycle of a single HTTP request is constructed. In this way, on the one hand, it ensures that the current archived identifier is available throughout the call chain involved in processing the current query, supporting the dynamic routing of the cache and the database; on the other hand, through timely cleaning operations, it effectively prevents the residual identifier information in the thread local variable from polluting the processing of subsequent unrelated requests, avoids potential data routing errors, and eliminates the risk of memory leakage that may be caused by thread reuse, improving the robustness and reliability of the system.

[0056] According to an embodiment of the present application, optionally, in step 150 above, combining the current archived identifier with the original cache key generated in the business logic to obtain a new cache key corresponding to the current archived identifier may specifically include: adding the current archived identifier to the head or tail of the original cache key in a string concatenation manner to generate a new cache key including namespace isolation information.

[0057] Among them, the namespace isolation information refers to an identifier segment attached before or after the original key and used to divide different data regions or tenants, which is used to make the modified new cache key unique in the global key space and avoid conflicts.

[0058] Specifically, when a cache query is required, the current archived identifier is obtained from the thread local variable, such as "TenantA_2023Fall". At the same time, the business logic generates an original cache key, such as "resume:list:filters:name=张三". The combination process is to perform a string operation, for example, using the current archived identifier as a prefix, adding a separator ":", and then concatenating the original cache key to generate a new cache key such as "TenantA_2023Fall:resume:list:filters:name=张三".

[0059] In the embodiments of the present application, by adding the current archived identifier as namespace information to the original cache key, a logically isolated storage area is created for the cache data of different enterprise tenants and different recruitment cycles in the shared cache service. This ensures that even for the same business queries of different tenants, that is, the generated original cache keys are the same, they will not access each other's cache data, guaranteeing the multi-tenant isolation and security of the cache data. At the same time, this implementation method is simple and reliable, with extremely small performance overhead.

[0060] According to an embodiment of this application, optionally, the above step 150, which uses a new cache key to access the cache to obtain resume data from the cache, may specifically include: querying the distributed key-value storage database using the new cache key; if the query is successful, directly returning the cached data in the distributed key-value storage database as resume data; if the query is unsuccessful, triggering the execution of a database query operation.

[0061] Specifically, after obtaining the new cache key, the client interface of the distributed key-value store database (such as Redis) is used to execute a query. If the database returns valid resume data (i.e., "query hit"), this data is returned directly as the result, and subsequent database access processes may be skipped. If the database returns empty or indicates that the key does not exist (i.e., "query miss"), the subsequent database query operation (i.e., step 160) is triggered normally to retrieve data from the archive database.

[0062] In this embodiment, by using dynamically generated, isolated new cache keys to query the distributed key-value storage database and handling both hit and miss scenarios, a high-efficiency speed buffer layer is provided for querying archived resume data while ensuring cache isolation. When the query hits, the resume data can be returned extremely quickly, significantly reducing response latency and alleviating access pressure on the archived database; when the query misses, it can seamlessly return to the source database for querying, ensuring eventual data consistency.

[0063] According to an embodiment of this application, optionally, the step 160 above, which involves finding the corresponding archive database connection information based on the current archive identifier, may include: querying preset configuration information based on the current archive identifier; obtaining target connection information matching the current archive identifier based on the mapping relationship; and establishing a connection with the corresponding archive database based on the target connection information.

[0064] The configuration information is used to record the mapping relationship between different archive identifiers and the network connection address and authentication information of the corresponding archive database. This mapping relationship can be, for example, the corresponding association between the archive identifier and the network connection address (such as JDBCURL, host port) and authentication information (such as username, password) of the archive database.

[0065] Specifically, when it is necessary to find a database connection based on the current archive identifier, the system first queries the preset configuration information using the current archive identifier, such as "ID_12345" as the key. This configuration information can be a map in memory, a configuration file, or a service from a configuration center. From this configuration information, the target connection information matching the identifier is obtained. Based on the target connection information, a valid connection to the corresponding archive database is established through a database connection pool or dynamic data source component.

[0066] In this embodiment, target connection information is obtained by querying preset configuration information that records mapping relationships, enabling dynamic and configurable management of data source connections. This allows changes to the address, authentication, and other information of the archived database to be updated without modifying the business code, only requiring a configuration update, thus improving system maintainability and flexibility. Simultaneously, this method ensures that the connection found based on the current archive identifier is precisely matched, providing a reliable basis for accurately executing queries on the target archived database.

[0067] Optionally, according to an embodiment of this application, when the above step 140 performs operations related to resume data through the business interface, the data access operations of the business interface are intercepted by the aspect interceptor. This may include: using an aspect-oriented programming interceptor, during the execution of the business interface, uniformly intercepting the call operations to the cache component and the call operations to the database access component.

[0068] Specifically, during the execution of the business interface, Aspect-Oriented Programming (AOP) interceptors are configured to intercept specific method calls. These intercepted method calls include: all calls to methods exposed by the caching component, such as `redisTemplate.opsForValue().get(key)`; and all calls to methods exposed by the database access component, such as `resumeMapper.selectById(id)`. When the business code reaches these call points, the interceptor will intercept them uniformly and insert routing processing logic, such as combining cache keys or switching data sources, before executing its original logic.

[0069] In this embodiment, centralized routing control is achieved at the lowest and most critical level of data access by uniformly intercepting calls to the caching component and the database access component. This non-intrusive interception method enables all business code that accesses data through standard components to automatically acquire dynamic routing capabilities, eliminating the need to write special branch code for accessing archived data. This maximizes code reuse and the purity of business logic, reducing system complexity and maintenance costs.

[0070] Optionally, according to an embodiment of this application, step 170, which returns the obtained resume data to the client, may include: returning the obtained resume data via a business interface and an aspect interceptor to display it in the historical talent pool list area of ​​the client's enterprise tenant interface.

[0071] The enterprise tenant interface can be a web page or client application interface presented to enterprise tenants (such as HR). The historical talent pool list area can be a specific visual area within the enterprise tenant interface used to display a list of archived resumes from historical recruitment cycles.

[0072] Specifically, after receiving the response, the client-side application parses the data, renders it, and displays it in the list area of ​​the historical talent pool page corresponding to the specific historical recruitment cycle the user is currently interacting with, for example... Figure 2 The list area corresponding to the historical recruitment cycle "202509" in the enterprise tenant interface shown can display the resume data received in this specific historical recruitment cycle.

[0073] In this embodiment, archived resume data obtained through dynamic routing is returned and displayed in the historical talent pool list area of ​​the enterprise tenant interface via a standard interface, providing users with a historical data query experience seamlessly integrated with the original system interface. Users do not need to jump to a special management backend or use additional tools; they can transparently view resumes from different historical recruitment cycles in a unified interface. This makes access to archived data intuitive, convenient, and in line with user operating habits, thus improving the inconvenience of accessing historical data in traditional methods.

[0074] As a concrete example, Figure 3 This is an exemplary flowchart illustrating a query method based on archived resumes provided in an embodiment of this application. It shows the specific execution flow of a client querying archived resume data in the form of a sequence diagram: Step 1, Process Initiation: The client sends an HTTP request to the server. The HTTP header of this request contains the archive identifier (archiveId) used to specify the archive database.

[0075] Step 2, Request Reception and Aspect Intercepting: After the request arrives at the server, it is received by the controller. The controller triggers the aspect pre-intercepting, which means that the request is handed over to the aspect interceptor for preprocessing. The aspect interceptor performs its first key operation: extracting the archiveId from the header.

[0076] Step 3, Context Information Storage: The extracted archiveId is returned to the aspect interceptor, which stores the archiveId in the thread local vector (ThreadLocal). The aspect uniformly saves the archive identifier for reuse by subsequent layers.

[0077] Step 4, Cache Query Routing: The business logic initiates a cache query to Redis, generating a raw key. The aspect interceptor intervenes again, intercepting the cache operation and retrieving the raw key. The interceptor obtains the archiveId from ThreadLocal. Using the obtained archiveId, the aspect interceptor performs an operation to concatenate the archiveId to generate a new key, forming a new key in the format "raw key + separator + archiveId". This new key ensures namespace isolation for cached data. The new key is used to query the Redis cache. If the data exists, Redis returns the isolated cached data of the archived data, and the process can directly jump to the final step of returning the data. Step 5, Database Query Routing: If the cache misses, a database query request is initiated; the aspect interceptor intercepts the database operation and retrieves the archiveId from ThreadLocal again; the archiveId is matched against the archive database connection string. This step means that the system dynamically determines the specific archive database connection information to be accessed based on the identifier, rather than a fixed connection to the main business database; the database access component (Database) uses the matched archive database connection string to execute a query against the archive database (ArchiveDB), rather than the main business database (FormalDB); after executing the query, the archive database returns the archive database data.

[0078] Step 6, Resource Cleanup and Response Return: After the database query is completed and the data is returned, the aspect interceptor performs post-processing to clean up the archiveId in ThreadLocal to prevent the identification information from being leaked to subsequent irrelevant requests; finally, the obtained resume data (whether from Redis cache or archive database) is returned layer by layer through the database access component, aspect interceptor, and controller until it is delivered to the client, completing this query.

[0079] In this embodiment, an aspect interceptor is used to uniformly manage the archive identifier (archiveId) at both the beginning and end of the request chain, and dynamically apply the identifier in the intermediate data access layer (caching and database), thereby achieving transparent and accurate access to the archive database and avoiding erroneous interaction with the main business database.

[0080] Corresponding to the method embodiments of this application, this application also provides a query device based on archived resumes.

[0081] Figure 4 This is a schematic diagram of the structure of a query device based on archived resumes provided in an embodiment of this application. Figure 4As shown, the query device 400 based on archived resumes may include: a data migration module 410, an extraction module 420, a storage module 430, an interception module 440, a first query module 450, a second query module 460, and a return module 470.

[0082] The data migration module 410 is used to respond to an archiving instruction for a target recruitment period, create a dedicated archiving database for the enterprise tenant that issued the archiving instruction, and migrate the resume data of the enterprise tenant within the target recruitment period from the main business database to the archive database associated with the enterprise tenant. The dedicated archive database is used only to store the resume data of the enterprise tenant within the target recruitment period. The extraction module 420 is used to extract the archive identifier from the HTTP request header of the query request when a client queries archived resumes, obtaining the current archive identifier, which is used to identify the archive database. The storage module 430 is used to save the current archive identifier to a thread-local variable of the current thread. The interception module 440 is used to intercept operations related to resume data performed through the business interface. During operation, data access operations are intercepted using aspect interceptors. The first query module 450 is used to obtain the current archive identifier from a thread-local variable when the data access operation involves cache querying, combine the current archive identifier with the original cache key generated in the business logic to obtain a new cache key corresponding to the current archive identifier, and use the new cache key to access the cache to obtain the corresponding resume data from the cache. The second query module 460 is used to obtain the current archive identifier from a thread-local variable when the data access operation involves database querying, look up the corresponding archive database connection information based on the current archive identifier, and perform a query on the archive database based on the found archive database connection information to obtain resume data from the archive database. The return module 470 is used to return the obtained resume data to the client.

[0083] The resume-based query device provided in this application provides an on-demand, real-time data archiving capability by instantly triggering archiving operations in response to archiving instructions for a target recruitment cycle and creating a dedicated archiving database for data migration. This overcomes the limitations of traditional solutions that rely on fixed downtime windows for batch processing, thus resolving service interruptions and business discontinuities caused by archiving operations. Secondly, by establishing an independent and identifiable archiving database for each enterprise tenant's historical resume data, separating historical data from currently active data in physical storage, the main business system environment can continue to be used in different recruitment cycles without needing to be completely rebuilt for each new cycle, thereby reducing repetitive configuration work and resource overhead when starting a new recruitment cycle. Furthermore, by extracting an archiving identifier from the request, passing the identifier using a thread-local variable throughout the request's lifecycle, and dynamically routing to the corresponding archiving database or cache key at the data access layer based on the identifier using an aspect interceptor, this solution constructs a unified and transparent historical data access channel at the application logic layer. Building upon this foundation, users can directly and seamlessly query archived resume data through standard business interfaces, without needing to be aware of the underlying physical storage location of the data, nor requiring database administrators to perform complex manual data extraction and recovery operations. This resolves the pain points of inconvenient access and cumbersome processes for historical data. Thus, this application enables efficient and flexible archiving of resume data while ensuring business continuity, reducing system maintenance and configuration costs, and improving the convenience and efficiency of historical data queries.

[0084] In some embodiments, the data migration module is further configured to: after migrating the resume data of the enterprise tenant during the target recruitment period from the main business database to the archive database associated with the enterprise tenant, migrate the index data of the resume search of the enterprise tenant during the target recruitment period from the main business search engine to the archive search engine created for the enterprise tenant.

[0085] In some embodiments, the archive identifier includes a combination of an enterprise tenant identifier and a recruitment cycle identifier, or the archive identifier is a unique key mapped to an archive database of a specific enterprise tenant in a specific recruitment cycle.

[0086] In some embodiments, the storage module 430 is specifically used to: when a query request is intercepted by the aspect interceptor, store the extracted current archive identifier in a thread-local variable bound to the current request thread before executing the business logic of the business interface; it also includes a post-processing module, which is used to perform post-processing through the aspect interceptor after the business interface is executed to clear the current archive identifier stored in the thread-local variable.

[0087] In some embodiments, the first query module is specifically used to: add the current archive identifier to the beginning or end of the original cache key by concatenating strings, so as to generate a new cache key containing namespace isolation information.

[0088] In some embodiments, the first query module is specifically used to: query the distributed key-value store database using the new cache key; if the query is successful, the cached data in the distributed key-value store database is directly returned as resume data; if the query is unsuccessful, a database query operation is triggered.

[0089] In some embodiments, the second query module is specifically used to: query preset configuration information based on the current archive identifier, wherein the configuration information is used to record the mapping relationship between different archive identifiers and the network connection address and authentication information of the corresponding archive database; obtain the target connection information matching the current archive identifier based on the mapping relationship, and establish a connection with the corresponding archive database based on the target connection information.

[0090] In some embodiments, the interception module is specifically used to: intercept calls to the cache component and calls to the database access component during the execution of the business interface through an interceptor based on aspect-oriented programming.

[0091] In some embodiments, the return module 470 is specifically used to: return the acquired resume data through the business interface and aspect interceptor, so as to display it in the historical talent pool list area of ​​the enterprise tenant interface on the client.

[0092] The query device based on archived resumes provided in this application embodiment can achieve... Figure 1-3 The various processes implemented in the method embodiments can achieve the same technical effect, and will not be described again here to avoid repetition.

[0093] Figure 5 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application.

[0094] like Figure 5 As shown, the electronic device 500 includes a memory 501, a processor 502, and a computer program stored in the memory 501 and executable on the processor 502.

[0095] In one example, the processor 502 described above may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0096] Memory 501 may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the query method based on archived resumes in the embodiments of the first aspect of this application.

[0097] The processor 502 runs a computer program corresponding to the executable program code by reading the executable program code stored in the memory 501, in order to implement the query method based on archived resumes in the embodiment of the first aspect described above.

[0098] In some examples, the electronic device 500 may also include a communication interface 503 and a bus 510. For example, Figure 5 As shown, the memory 501, processor 502, and communication interface 503 are connected through bus 510 and complete communication with each other.

[0099] The communication interface 503 is mainly used to enable communication between various modules, systems, units, and / or devices in the embodiments of this application. Input devices and / or output devices can also be connected through the communication interface 503.

[0100] Bus 510 includes hardware, software, or both, that couples components of electronic device 500 together. For example, and not limitingly, bus 510 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-E) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 510 may include one or more buses. Although specific buses are described and illustrated in the embodiments of this application, this application considers any suitable bus or interconnection.

[0101] The electronic device provided in this application embodiment is capable of achieving Figure 1-3 The various processes implemented in the method embodiments can achieve the same technical effect, and will not be described again here to avoid repetition.

[0102] In conjunction with the resume-based query method described in the above embodiments, this application embodiment can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions; when executed by a processor, these computer program instructions implement any step in the above method embodiments.

[0103] In conjunction with the resume-based query method described in the above embodiments, this application embodiment can provide a computer program product to implement this method. This (computer) program product is stored in a non-volatile storage medium, and when executed by at least one processor, it implements any step in the above method embodiments.

[0104] This application also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0105] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0106] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0107] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0108] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or systems. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0109] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, systems (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing system to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing system, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0110] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for querying archived resumes, characterized in that, The method includes: In response to receiving an archiving instruction for a target recruitment period, a dedicated archiving database is created for the enterprise tenant that issued the archiving instruction, and the resume data of the enterprise tenant during the target recruitment period is migrated from the main business database to the archiving database associated with the enterprise tenant. The dedicated archiving database is used only to store the resume data of the enterprise tenant during the target recruitment period. When a client requests a query for an archived resume, the archive identifier is extracted from the HTTP request header of the query request to obtain the current archive identifier, wherein the archive identifier is used to identify the archive database; Save the current archive identifier to the thread-local variable of the current thread; When performing operations related to resume data through the business interface, the data access operation is intercepted through the aspect interceptor; When the data access operation involves cache query, the current archive identifier is obtained from the thread local variable, the current archive identifier is combined with the original cache key generated in the business logic to obtain a new cache key corresponding to the current archive identifier, and the cache is accessed using the new cache key to obtain the corresponding resume data from the cache; When the data access operation involves a database query, the current archive identifier is obtained from the thread local variable, the corresponding archive database connection information is found based on the current archive identifier, and a query is performed on the archive database based on the found archive database connection information to obtain resume data from the archive database; The obtained resume data is returned to the client.

2. The method according to claim 1, characterized in that, After migrating the resume data of the enterprise tenant during the target recruitment cycle from the main business database to the archive database associated with the enterprise tenant, the process also includes: The index data of the enterprise tenant's resume search during the target recruitment cycle will be migrated from the main business search engine to the archive search engine created for the enterprise tenant.

3. The method according to claim 1, characterized in that, The archive identifier includes a combination of an enterprise tenant identifier and a recruitment cycle identifier, or the archive identifier is a unique key mapped to the archive database of a specific enterprise tenant in a specific recruitment cycle.

4. The method according to claim 1, characterized in that, Saving the current archive identifier to the thread-local variable of the current thread includes: When the query request is intercepted by the aspect interceptor, before executing the business logic of the business interface, the extracted current archive identifier is stored in a thread-local variable bound to the current request thread; The method further includes: After the business interface is completed, the aspect interceptor performs post-processing to clear the current archive identifier stored in the thread local variable.

5. The method according to claim 1, characterized in that, The current archive identifier is combined with the original cache key generated in the business logic to obtain a new cache key corresponding to the current archive identifier, including: The current archive identifier is added to the beginning or end of the original cache key by concatenating strings to generate a new cache key containing namespace isolation information.

6. The method according to claim 1 or 5, characterized in that, Accessing the cache using the new cache key to retrieve resume data from the cache includes: Use the new cache key to query the distributed key-value store database; If the query finds a match, the cached data in the distributed key-value storage database is returned directly as the resume data; If the query fails to find a match, the database query operation will be executed.

7. The method according to claim 1, characterized in that, Based on the current archive identifier, the corresponding archive database connection information is retrieved, including: Based on the current archive identifier, query the preset configuration information, which is used to record the mapping relationship between different archive identifiers and the network connection address and authentication information of the corresponding archive database; Based on the mapping relationship, obtain the target connection information that matches the current archive identifier, and establish a connection with the corresponding archive database based on the target connection information.

8. The method according to claim 1, characterized in that, When performing operations related to resume data through a business interface, the data access operations of the business interface are intercepted using an aspect-oriented interceptor, including: By using interceptors in aspect-oriented programming, calls to the caching component and calls to the database access component are uniformly intercepted during the execution of the business interface.

9. The method according to claim 1, characterized in that, Returning the acquired resume data to the client includes: The acquired resume data is returned via the business interface and the aspect interceptor and displayed in the historical talent pool list area of ​​the enterprise tenant interface on the client.

10. An electronic device, characterized in that, The electronic device includes a processor and a memory storing computer program instructions; when the electronic device executes the computer program instructions, it implements the method as described in any one of claims 1-9.

Images