First screen page display method and device, equipment and medium

Abstract

The invention relates to a first screen page display method and device, equipment and a medium in the technical field of computers, and the method comprises the steps: responding to a request obtaining event of a first screen page, and querying and obtaining page resource data of the first screen page in a cache; aiming at the page resource data of the first screen page which is not stored in the cache, obtaining the page resource data obtained by a plurality of micro-service instances to query a database in parallel; starting a preset page template engine to inject the complete page resource data of the first-screen page into a preset page template and perform page rendering to obtain a corresponding first-screen page file; and returning the first screen page file to the client corresponding to the triggered request acquisition event for displaying the first screen page. The first screen page can be quickly constructed, the display time is greatly shortened, and the user experience is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for displaying a first-screen page and the corresponding apparatus, computer equipment, and computer-readable storage medium. Background Technology

[0002] In current application development, especially in client-server architecture applications, the loading efficiency of the first screen or initial interface is a core indicator determining user experience. Current technology employs a client-side rendering architecture. In this model, when a user launches the application or triggers a first-screen request, the server primarily provides a lightweight application container framework. The core data and specific content required by the page are obtained asynchronously by the logic code running on the client. The backend system serving these data requests typically handles all requests through a unified service interface. Upon receiving a data request, this service interface often processes multiple data query tasks sequentially, such as querying user information, content lists, and configuration parameters in turn. Each query must wait for the previous query to complete and return a result before execution can begin, resulting in the overall data retrieval time equal to the sum of the times for each sequential query. Only after all data has been retrieved from the database or other data sources in this sequential manner will the server return the complete data set to the client. Ultimately, the client needs to rely on its own computing resources to dynamically populate content, construct components, and render visuals based on the received data and pre-defined interface logic, thereby generating the final first-screen interface displayed to the user.

[0003] This traditional method suffers from significant efficiency bottlenecks in its technical principles. The problem stems first from the high sequential dependency of the data acquisition phase. Because multiple database queries are forced to be executed serially, the latency of the entire data input / output process is amplified. In complex business scenarios requiring the aggregation of multi-source data, this latency is significantly amplified, becoming a major factor limiting response speed. Secondly, the complete chain from request initiation to final interface rendering is unnecessarily lengthened. The client must receive all data before initiating the final rendering process, which is itself a computationally intensive process. This means that from the time a user sends a request to seeing the complete content, multiple continuous and blocking stages are involved, including network communication, serial data queries, data return, and client-side rendering. The "critical path" formed by these stages makes it difficult to reduce the overall latency of the initial screen display. Users typically have to wait a long time, facing a blank or loading state, especially when data queries are complex or network conditions are poor, resulting in a significant decline in user experience. Therefore, existing technical solutions struggle to meet users' widespread expectation for an immediate and fast response on the first screen of an application. Summary of the Invention

[0004] The primary objective of this application is to solve at least one of the aforementioned problems by providing a method for displaying a first-screen page, and the corresponding apparatus, computer equipment, and computer-readable storage medium.

[0005] To achieve the various objectives of this application, the following technical solution is adopted: A method for displaying a first-screen page, provided for one of the purposes of this application, includes the following steps: Respond to the request event for the first screen page, query and retrieve the page resource data of the first screen page from the cache; For page resource data of the first screen page that is not stored in the cache, obtain the page resource data obtained by multiple microservice instances querying the database in parallel; The preset page template engine is enabled to inject the complete page resource data of the first screen page into the preset page template and render the page to obtain the corresponding first screen page file; The first screen page file is returned to the client corresponding to the request event, for displaying the first screen page.

[0006] On the other hand, a first-screen page display device provided to meet one of the purposes of this application includes an event response module, a parallel database query module, a page rendering module, and a page display module. The event response module is used to respond to a request to retrieve the first-screen page, query and retrieve the page resource data of the first-screen page from the cache. The parallel database query module is used to retrieve the page resource data of the first-screen page that is not stored in the cache, obtained by multiple microservice instances querying the database in parallel. The page rendering module is used to enable a preset page template engine to inject the complete page resource data of the first-screen page into a preset page template and perform page rendering to obtain the corresponding first-screen page file. The page display module is used to return the first-screen page file to the client corresponding to the client that triggered the request to retrieve the first-screen page for displaying the first-screen page.

[0007] In another aspect, a computer device provided for one of the purposes of this application includes a central processing unit and a memory, the central processing unit being used to invoke and run a computer program stored in the memory to perform the steps of the first screen page display method described in this application.

[0008] In another aspect, a computer-readable storage medium is provided to suit another purpose of this application, which stores, in the form of computer-readable instructions, a computer program implemented according to the described first-screen page display method, which, when invoked by a computer, executes the steps included in the method.

[0009] The technical solution of this application has many advantages, including but not limited to the following aspects: This application firstly significantly improves page loading efficiency by utilizing a caching mechanism. When responding to user requests, it prioritizes querying and retrieving existing first-screen page resource data from the cache, avoiding redundant queries for duplicate content. By fully leveraging the high-speed reading capabilities of caching technology, it drastically reduces data retrieval waiting time. Especially for frequently accessed popular page content, it achieves near real-time response speeds, effectively shortening the time users spend facing a blank screen and providing a smoother initial interactive experience.

[0010] Secondly, by employing multiple microservice instances to query the database in parallel, the performance bottleneck of the traditional serial query architecture is fundamentally overcome. For page resource data not stored in the cache, instead of using a sequential query mode, the microservice architecture is used to synchronously acquire data from multiple data sources through parallel calls. This allows various data query tasks that previously required overlapping waiting times to be performed simultaneously, reducing the overall data acquisition time from the sum of the times of various queries to the longest single query duration. This significantly improves the efficiency of multi-source data aggregation in complex business scenarios, enabling a more rational allocation and utilization of service resources.

[0011] Furthermore, by enabling a pre-defined page template engine on the server side to complete the entire page rendering process, the computationally intensive rendering tasks are transferred from the client to the server, achieving an optimized and restructured technical architecture. The server directly returns the rendered first-screen page file to the client, eliminating the need for the client to perform complex data parsing, content filling, and visual rendering—time-consuming operations. This server-side rendering mode not only reduces the computational burden on terminal devices and decreases dependence on client hardware performance, but also ensures that users receive a fast and consistent first-screen display experience under various network environments and device conditions. It effectively solves the problem of inconsistent experiences caused by differences in client rendering capabilities in traditional architectures, while also improving the security and search engine friendliness of the first-screen content. Attached Figure Description

[0012] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart illustrating a typical embodiment of the first-screen page display method of this application; Figure 2 This is a schematic block diagram of the first screen display device of this application; Figure 3 This is a schematic diagram of the structure of a computer device used in this application. Detailed Implementation

[0013] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0014] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this application means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0015] Those skilled in the art will understand that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0016] Those skilled in the art will understand that the terms "client," "terminal," and "terminal device" as used herein include both devices that receive wireless signals, devices that only possess wireless signal receiver capabilities without transmission capabilities, and devices with receiving and transmitting hardware, devices that have receiving and transmitting hardware capable of bidirectional communication over a bidirectional communication link. Such devices may include: cellular or other communication devices such as personal computers or tablets, having single-line displays, multi-line displays, or cellular or other communication devices without multi-line displays; PCS (Personal Communications Service) that can combine voice, data processing, fax, and / or data communication capabilities; PDAs (Personal Digital Assistants) that may include radio frequency receivers, pagers, internet / intranet access, web browsers, notebooks, calendars, and / or GPS (Global Positioning System) receivers; and conventional laptops and / or handheld computers or other devices that have and / or include radio frequency receivers. As used herein, "client," "terminal," and "terminal device" can be portable, transportable, installed in a means of transportation (air, sea, and / or land), or suitable and / or configured to operate locally and / or in a distributed manner, operating in any other location on Earth and / or in space. "Client," "terminal," and "terminal device" as used herein can also be a communication terminal, an internet access terminal, or a music / video playback terminal, such as a PDA, a MID (Mobile Internet Device), and / or a mobile phone with music / video playback capabilities, or a smart TV, set-top box, etc.

[0017] The hardware referred to by the names "server," "client," and "service node" in this application is essentially an electronic device with the equivalent capabilities of a personal computer. It is a hardware device with the necessary components revealed by the von Neumann architecture, such as a central processing unit (including an arithmetic logic unit and a control unit), memory, input devices, and output devices. The computer program is stored in its memory, and the central processing unit loads the program stored in the secondary storage into the main memory to run it, execute the instructions in the program, and interact with the input and output devices to complete specific functions.

[0018] It should be noted that the concept of "server" used in this application can also be extended to apply to server clusters. Based on network deployment principles as understood by those skilled in the art, the servers should be logically divided; physically, these servers can be independent yet accessible through interfaces, or they can be integrated into a single physical computer or a computer cluster. Those skilled in the art should understand this flexibility and should not use it to constrain the implementation of the network deployment method described in this application.

[0019] One or more of the technical features of this application, unless explicitly specified herein, can be deployed on a server and accessed by a client remotely calling the online service interface provided by the server, or can be directly deployed and run on a client for access.

[0020] Unless otherwise specified, all data involved in this application may be stored remotely on a server or on a local terminal device, as long as it is suitable for use by the technical solution of this application.

[0021] Those skilled in the art will understand that although the various methods in this application are described based on the same concept and thus present commonality among them, they can be performed independently unless otherwise specified. Similarly, the various embodiments disclosed in this application are all based on the same inventive concept; therefore, concepts expressed in the same way, as well as concepts that are appropriately changed for convenience but are expressed differently, should be understood equivalently.

[0022] Unless otherwise expressly stated, the various embodiments disclosed in this application can be combined in a cross-cutting manner to flexibly construct new embodiments, as long as such combination does not depart from the inventive spirit of this application and can meet the needs of the prior art or solve a certain deficiency in the prior art. Those skilled in the art should be aware of such modifications.

[0023] The first screen display method of this application can be programmed into a computer program product and deployed on a client or server to run. For example, in the exemplary application scenario of this application, it can be deployed on the server of an e-commerce platform. In this way, the method can be executed by human-computer interaction with the process of the computer program product through a graphical user interface by accessing the interface opened after the computer program product runs.

[0024] Please see Figure 1 The method for displaying the first screen of this application, in its typical embodiment, includes the following steps: Step S1100: Respond to the request to obtain the first screen page, query and obtain the page resource data of the first screen page in the cache; When a user launches the application through the client, the client initiates an HTTP request for the initial page, triggering a request retrieval event. The request received by the server typically contains information to uniquely identify the target page, such as the URL path, user identifier (user_id), and possible business query parameters (e.g., category, sorting). The server first constructs a unique cache key based on this information. The cache key is generated according to a predefined naming convention to ensure that requests from the same user under the same conditions map to the same cache entry, while also distinguishing page content from different users or with different parameters.

[0025] Subsequently, the server initiates a query to the Redis distributed cache cluster. The Redis cluster, as a high-performance in-memory data store, is used to cache processed page resource data. Page resource data refers to the collection of all resource data required to construct the user-visible first screen, including static resources (such as HTML fragments, CSS stylesheet references, JavaScript file paths, and image URLs) and dynamic data (such as the basic information of the currently logged-in user, personalized recommendation lists, and the number of real-time notifications). This data has already been aggregated, serialized (usually in JSON string format), and stored in Redis during previous request processing.

[0026] During a query, the server executes a Redis GET command using the generated cached key. If the key exists in the cache and the corresponding value has not expired, a cache hit occurs. The server immediately deserializes the retrieved serialized data, restoring it to a structured data object (such as a JavaScript object), which can be directly used for subsequent page assembly. This process is entirely completed in memory, avoiding disk I / O or network calls, and the response time can typically be controlled in the millisecond range, thus significantly shortening the preparation time for the first screen of data.

[0027] If a cache miss occurs (i.e., the key does not exist or the data has expired), the server records the missing data portion of the query and proceeds to subsequent parallel calls to microservices to retrieve the complete data. To optimize cache effectiveness, differentiated lifecycle management is implemented for different types of cached data. For frequently accessed hot data, such as homepage navigation configurations or site-wide announcements, a longer expiration time (TTL), such as 1 hour, is set to keep it in the cache for a longer period to serve a large number of requests. For user-personalized or time-sensitive data, such as a personal order list, a shorter expiration time, such as 5 minutes, is set to ensure the relative freshness of the data. This strategy of dynamically adjusting the TTL based on data access patterns achieves a balance between improving cache hit rate and ensuring data timeliness.

[0028] Furthermore, to address the challenges of cache consistency and effectiveness in high-concurrency scenarios, a protection mechanism is introduced during the cache query phase. For example, when a cache miss occurs, the Redis SETNX command is used to attempt to set a temporary lock. Only requests that successfully set the lock are allowed to execute subsequent time-consuming database or microservice queries to retrieve data from the origin server and update the cache. Other concurrent requests wait for the lock to be released before directly reading data from the newly populated cache, thus effectively preventing excessive instantaneous pressure on backend services caused by "cache breakdown".

[0029] Meanwhile, the cache key design can include a data version number (such as "homepage:v2:12345"). When business logic changes or data is updated, the old cache can be made invalid by updating the version number, thus achieving a smooth transition and data consistency management.

[0030] Step S1200: For the page resource data of the first screen page that is not stored in the cache, obtain the page resource data obtained by multiple microservice instances querying the database in parallel; When the server fails to find the complete page resource data required for the initial screen in the cache, it initiates a parallel query mechanism, retrieving the missing data from the database by calling multiple microservice instances. Specifically, the server first identifies the missing data portions in the cache, which typically include information from different business domains. Each business domain is handled by an independent microservice instance deployed in a distributed environment, with each instance encapsulating specific business logic and database access capabilities.

[0031] In one embodiment, based on the NestJS framework, the server obtains client proxies for these microservice instances through dependency injection and then concurrently initiates data query requests to multiple microservice instances. The dependency injection container manages the lifecycle of the gRPC client instances. For example, a gRPC client service class is defined using the `@Injectable()` decorator, and this class injects gRPC client configuration in its constructor using the `@Inject()` decorator. The dependency injection container scans all decorators, resolves dependencies, and creates singleton gRPC client instances when the application starts. When a microservice needs to be called, the server obtains these pre-configured gRPC client instances from the dependency injection container, eliminating the need for manual instantiation and ensuring connection reuse and resource optimization. Furthermore, the gRPC client, acting as a proxy for microservice calls, encapsulates the communication details with the gRPC server. Each gRPC client corresponds to a microservice instance, and these microservice instances, abstracted as gRPC servers, are deployed across multiple nodes, collectively forming a microservice cluster. The server initiates remote procedure calls (RPCs) in parallel to multiple gRPC servers through gRPC clients. For example, the server uses the `Promise.all()` method or the RxJS library to simultaneously call multiple gRPC clients, such as user services, content services, and configuration services. Each gRPC client establishes a connection with its corresponding gRPC server via the HTTP / 2 protocol and sends a serialized query request based on Protocol Buffers format. After receiving the request, the gRPC server performs database query operations in parallel, such as retrieving data through SQL queries or NoSQL access, and then serializes the results and returns them to the gRPC client. After receiving all the response results, the gRPC client performs data transformation, converting the Protocol Buffers format response into a plain JavaScript object, then aggregates this data according to the page requirements, and finally returns the aggregated page resource data to the server.

[0032] In another embodiment, the server can use an asynchronous programming library (such as the parallel function of the async library) to manage concurrent HTTP requests sent to various microservice instances that provide RESTful APIs.

[0033] In another embodiment, using message queues and worker patterns, the server publishes different data query tasks as messages to the message queue. Multiple independent worker microservice instances consume these messages in parallel, execute queries, and write the results back to the cache or another result queue. The server then asynchronously collects all the results.

[0034] In other embodiments, when the data source is multiple different databases or search engines, the server can establish multiple database connection pools and use the connection pools to execute SQL queries or search requests concurrently, and then merge the result sets.

[0035] All of the above implementation methods break the chain dependency of traditional serial queries, enabling multiple independent I / O operations to overlap, thereby reducing the overall data acquisition time from the sum of the time spent on each operation to the time spent on the slowest operation, significantly improving the efficiency of the data acquisition stage.

[0036] Step S1300: Activate the preset page template engine to inject the complete page resource data of the first screen page into the preset page template and perform page rendering to obtain the corresponding first screen page file; After obtaining complete page resource data, the server executes the page rendering process using a pre-defined page template engine. A page template engine is a software component specifically designed to combine data with a predefined HTML structure to generate a complete HTML file. In this technical solution, the page template engine is pre-configured on the server side, such as using server-side rendering template engines like Nunjucks, EJS, or Pug. These engines support injecting dynamic data into static HTML templates. The pre-defined page template is an HTML file containing placeholders and logical control instructions. These placeholders match the field structure of the page resource data. For example, an e-commerce homepage template might contain "{user.name}" to display the username and "{recommendation.list}" to insert a list of recommended products.

[0037] The rendering process first converts page resource data into a data structure recognizable by the template engine, typically a JavaScript object or a mapping table. Then, the server calls the template engine's rendering method, passing in the page template path or identifier and the prepared data object. The template engine parses the template file, identifying variable placeholders, conditional statements, loop structures, and other instructions, replacing all placeholders with actual data, and executing the logical operations within the template. For example, when processing product list data, the template engine iterates through the data array, generating the corresponding HTML element structure for each product item. During this process, the template engine also handles details such as CSS style injection, JavaScript code snippet embedding, and image resource path parsing.

[0038] In one embodiment, the server-side rendering mechanism of the Next.js framework is used to execute the React component in the Node.js environment. After obtaining data through the getServerSideProps function, it is directly rendered as HTML.

[0039] In another embodiment, Vue.js is used in conjunction with the Nuxt.js framework. The first screen data is obtained through the asyncData method, and then the rendering function of the Vue component is executed on the server to generate HTML.

[0040] During server-side rendering, performance optimization is a primary focus. For example, template files are pre-compiled, converting them into efficient JavaScript functions to avoid repeatedly parsing template syntax with each request. Simultaneously, a streaming rendering strategy is employed for key content on the first screen, prioritizing the rendering of visible areas so users can see the main page content faster. After rendering, the server performs HTML optimization, including removing unnecessary comments, compressing whitespace, and inlining critical CSS to improve initial rendering speed. The final generated first-screen page file is a complete HTML file containing all necessary content, styles, and initial states, which can be directly parsed and displayed in the client's browser without waiting for additional JavaScript execution or data requests, thus achieving instant rendering of the first-screen content.

[0041] Step S1400: Return the first screen page file to the client corresponding to the client that triggered the request to obtain the event, so as to display the first screen page.

[0042] After rendering the initial page, the server returns the generated initial page file to the client via the network. The initial page file is a complete HTML file, containing the page content with injected data, inline CSS styles, initial JavaScript state, and all necessary DOM structure. This file uses standard HTML5 format and UTF-8 character encoding to ensure cross-platform compatibility. The server constructs a response via HTTP or HTTPS, using the initial page file as the response body and setting key response header information.

[0043] When network conditions are poor or client device performance is limited, the server can enable chunked transfer encoding, sending the initial page file in chunks according to the importance of the DOM structure. Prioritizing the transmission of HTML content in the visible initial area allows the client browser to render progressively, enabling users to see a portion of the page content before fully receiving the file. For client connections supporting HTTP / 2 or HTTP / 3 protocols, the server utilizes the protocol's multiplexing capabilities to simultaneously transmit the initial page file and critical static resources (such as core CSS and initial images) within the same connection, avoiding the head-of-line blocking problem of traditional HTTP / 1.1.

[0044] In high-concurrency scenarios, the server employs an asynchronous non-blocking I / O model to handle response transmission. For example, in a Node.js environment, the Stream API is used to write responses chunk by chunk, avoiding memory spikes caused by large files; in a Java environment, the asynchronous processing features of Servlet 3.0 are used to release request thread resources. For business scenarios with high security requirements, the server performs Content Security Policy (CSP) injection before returning the initial page file, adding the Content-Security-Policy meta tag to the HTML header to restrict script loading sources and inline script execution, preventing XSS attacks. When the server detects that the client supports server push technology, it proactively pushes critical resources such as core CSS files and initial images while returning the initial page file, eliminating additional RTT (Round-Trip Time) latency and further accelerating page display.

[0045] It is easy to understand from the above embodiments that, compared with the prior art, this application has many advantages, including at least: This application firstly significantly improves page loading efficiency by utilizing a caching mechanism. When responding to user requests, it prioritizes querying and retrieving existing first-screen page resource data from the cache, avoiding redundant queries for duplicate content. By fully leveraging the high-speed reading capabilities of caching technology, it drastically reduces data retrieval waiting time. Especially for frequently accessed popular page content, it achieves near real-time response speeds, effectively shortening the time users spend facing a blank screen and providing a smoother initial interactive experience.

[0046] Secondly, by employing multiple microservice instances to query the database in parallel, the performance bottleneck of the traditional serial query architecture is fundamentally overcome. For page resource data not stored in the cache, instead of using a sequential query mode, the microservice architecture is used to synchronously acquire data from multiple data sources through parallel calls. This allows various data query tasks that previously required overlapping waiting times to be performed simultaneously, reducing the overall data acquisition time from the sum of the times of various queries to the longest single query duration. This significantly improves the efficiency of multi-source data aggregation in complex business scenarios, enabling a more rational allocation and utilization of service resources.

[0047] Furthermore, by enabling a pre-defined page template engine on the server side to complete the entire page rendering process, the computationally intensive rendering tasks are transferred from the client to the server, achieving an optimized and restructured technical architecture. The server directly returns the rendered first-screen page file to the client, eliminating the need for the client to perform complex data parsing, content filling, and visual rendering—time-consuming operations. This server-side rendering mode not only reduces the computational burden on terminal devices and decreases dependence on client hardware performance, but also ensures that users receive a fast and consistent first-screen display experience under various network environments and device conditions. It effectively solves the problem of inconsistent experiences caused by differences in client rendering capabilities in traditional architectures, while also improving the security and search engine friendliness of the first-screen content.

[0048] In a further embodiment, before step S1100, querying and obtaining the page resource data of the first screen page in the cache, the following steps are included: Step S1000: Receive the client request corresponding to the request acquisition event, and parse the user identity token and request user identifier in the client request; When the application starts or a user navigates to a specific page, the client generates a fetch request event, which triggers the client to send an HTTP or HTTPS request to the server.

[0049] The server first receives this client request, which typically includes a request header, a request body, and URL parameters. In the request header, the Authorization or Cookie field carries a user identity token, an encrypted string issued by the server when the user logs in. This token contains user identity information and time-sensitive verification data, commonly in the form of JWT (JSON Web Token) or OAuth token.

[0050] The server extracts the user identity token by parsing the HTTP request header and obtains the request user identifier from the request URL parameters, request body, or specific request header fields. This identifier is a unique user identifier in plaintext, such as user ID, mobile phone number, or email address.

[0051] The parsing process can be implemented using various technologies. For example, in a Node.js environment, the `req.headers` and `req.query` objects of the Express framework can be used to obtain the request headers and query parameters, respectively; in a Java Spring Boot framework, the `getHeader` and `getParameter` methods of the `HttpServletRequest` object can be used to extract the corresponding information; and in a Python Flask framework, the request headers and query parameters can be obtained through the `request.headers` and `request.args` dictionaries.

[0052] Step S1010: Verify whether the user identity token matches the requesting user identifier. If they do not match, end the response to the request acquisition event.

[0053] After obtaining the user identity token and the request user identifier, the server executes verification logic to confirm the legitimacy of the request. The core of the verification is to verify whether the user identity represented by the token matches the user identity claimed in the request parameters, thereby preventing authorization theft or request tampering. The verification process first verifies the user identity token. For example, for a JWT token, the server uses a preset key or public key to verify its signature validity and checks whether the token has expired. After successful verification, the server decodes the payload of the JWT token, extracting the user identifier encoded within the token (e.g., the sub or userId field). Subsequently, the server performs a precise string or numerical comparison between the user identifier extracted from this authenticated token and the request user identifier directly parsed from the client request. If they match, it indicates that the token holder and the request initiator are identical, and the verification passes. If they do not match, it indicates a security risk, such as the token being stolen or the request being maliciously forged. At this point, the server immediately terminates its subsequent processing of the request. Specifically, it constructs and returns an HTTP response indicating unauthorized access, such as a 401 (Unauthorized) status code response, including error information in the response body. Then, it terminates the current request processing chain, ceasing any further data queries or page rendering operations. This verification mechanism is a crucial element in ensuring system security, guaranteeing that only legitimate, authenticated users can access the resources they are authorized to access. In different implementations, the token format can be other types besides JWT, such as OAuth 2.0 access tokens.

[0054] The validation process can be implemented using a unified authentication middleware pattern, completing the validation before the request enters the business logic; alternatively, validation logic can be injected before method invocation using AOP (Aspect-Oriented Programming); or the framework's built-in authentication mechanism can be utilized, such as Spring Security's AuthenticationManager or Express's Passport middleware. The validation process must guarantee atomicity and consistency to avoid the risk of unauthorized access due to flawed validation logic in high-concurrency scenarios.

[0055] In this embodiment, by adding a matching and verification mechanism between the user identity token and the requesting user identifier before querying the cache, the system's security and resource utilization efficiency are significantly improved. This effectively prevents identity impersonation and unauthorized access risks, intercepting illegal requests early in the request processing flow and avoiding unnecessary subsequent resource queries and processing overhead. This pre-verification mechanism not only protects user data privacy and reduces the possibility of malicious attacks, but also optimizes server resource allocation, allowing limited computing resources to focus on serving legitimate users. Thus, while ensuring security, it maintains overall response performance, providing users with a more reliable and personalized first-screen display service.

[0056] In a further embodiment, step S1000, receiving the client request corresponding to the request acquisition event, includes the following steps: Step S1001: The load balancer receives the client request corresponding to the request acquisition event and determines the target server in the server cluster whose load status meets the preset conditions. The load balancer receives the client request corresponding to the request acquisition event. Here, the load balancer is a network device or software component deployed at the server-side entry point, its core function being to act as a unified point for all external client requests. When a user initiates an HTTP / HTTPS request for the homepage from a mobile application or browser, the request first reaches the load balancer, not the application server directly handling business logic. The load balancer listens on a preset network port (e.g., 80 or 443), receives TCP connections from the network, and parses the HTTP protocol. The received client request contains a complete HTTP message, including the request method, URL, request headers, and possibly a request body.

[0057] Upon receiving a request, the load balancer does not immediately forward it. Instead, it selects the most suitable server from multiple backend business servers (i.e., the server cluster) based on preset rules and algorithms. This selected server becomes the target server. The decision-making basis for determining the target server is the server's "load status," a comprehensive indicator used to quantify the server's current workload or health. The load balancer continuously collects load status information from each server in the cluster, either actively or passively.

[0058] The preset conditions are the screening criteria set by the load balancing strategy. The determination process usually follows this procedure: The load balancer first checks the health status of each server, for example by periodically sending HTTP health check requests (such as GET / health), and only includes servers with a status of "healthy" or "alive" in the candidate pool; then, it applies a specific load balancing algorithm to select a server from the candidate pool as the target server.

[0059] Load balancing algorithms include, but are not limited to: round-robin algorithms, which distribute requests sequentially to each server to ensure absolute balance; least connections algorithms, which prioritize distributing new requests to the server with the fewest active connections, suitable for long-connection scenarios; response time-based algorithms, which prioritize distributing requests to the server with the shortest historical average response time; or weighted algorithms based on server weights, which assign different weights to servers according to their processing capacity, with more capable servers receiving more requests.

[0060] In addition, load status can also meet preset conditions such as server CPU utilization being below 70%, memory idle rate being above 20%, and the current request queue length not exceeding the limit, among other conditions. The load balancer's built-in decision engine evaluates these metrics in real time and ultimately selects a target server that meets all preset conditions as the server for responding to request retrieval events.

[0061] Step S1002: The load balancer forwards the client request to the target server, and the target server responds to the request to obtain the event.

[0062] The load balancer forwards the client request to the target server, and the target server responds to the request by acquiring an event. After determining the target server, the load balancer performs a forwarding operation. Forwarding means that the load balancer, acting as a proxy, sends the received original client request (or a modified request according to certain rules) to the selected target server over the network. Specifically, the load balancer establishes a new TCP connection with the target server (or reuses a connection from an existing connection pool) and sends the received HTTP request message almost verbatim.

[0063] In this embodiment, a load balancer is introduced as the core component for request distribution. It intelligently assesses the real-time load status of the server cluster and accurately directs client requests to the optimal target server. This fundamentally solves the problem of uneven server resource allocation in high-concurrency scenarios, effectively avoiding the risk of overall performance degradation or even service interruption due to single-point overload. The load balancing mechanism not only significantly improves the overall throughput and availability of the system, ensuring continuous service stability, but also provides the technical foundation for horizontal scaling, enabling service providers to flexibly adjust server scale according to business growth. This dynamic resource scheduling strategy significantly optimizes the response time of user requests while maximizing the return on investment of hardware resources, providing a more consistent and efficient first-screen loading experience for a large user base.

[0064] In a further embodiment, after step S1010, verifying that the user identity token matches the requesting user identifier, the following steps are included: Step S1011: Determine the source information, source page information and request method information corresponding to the client request, determine whether the source information and source page information are reliable, and determine whether the request method information indicates whether the request belongs to a pre-inspection request; After the user identity token requested by the client successfully matches the requesting user identifier, the server needs to further verify the security of the request. The server extracts source information (Origin field value) from the HTTP request header. This field indicates the originating site of the request, including the protocol, domain name, and port number. It also obtains the source page information (Referer field value), which records which specific page the user linked from to this request. Furthermore, the server identifies the request method information, i.e., the HTTP request method type, including GET, POST, OPTIONS, etc. The server uses a pre-defined whitelist mechanism to determine the trustworthiness of the source information and source page information: it performs a precise string comparison between the extracted Origin value and a pre-defined list of trusted sources; only a complete match is considered trustworthy. Similarly, it performs domain name resolution on the Referer value and compares it with a list of trusted domains. Regarding the request method information, the server specifically checks whether the request is a preflight request. A preflight request specifically refers to a request with the HTTP method OPTIONS and containing the Access-Control-Request-Method header. This is a security check mechanism automatically initiated by the browser before cross-domain requests. The server determines whether a request is a preflight request by checking if the request method is OPTIONS and if the Access-Control-Request-Method header field is present.

[0065] Step S1012: When the source information or the source page information is reliable, and the request method information indicates that the client request does not belong to the pre-inspection request, configure the preset cross-domain response header information for the request; When at least one of the source information or the originating page information is determined to be trustworthy, and the request method information indicates that the current request is not a preflight request, the server configures the preset cross-origin response header information in the response header. Specifically, the server sets the Access-Control-Allow-Origin header field to the Origin value in the request, indicating that cross-origin access from that origin is allowed; it adds the Access-Control-Allow-Credentials header field and sets it to true to allow credentials; it sets the Access-Control-Allow-Methods header field to include all HTTP methods supported by the server, such as GET, POST, and PUT; it adds the Access-Control-Allow-Headers header field to specify allowed request headers, such as Content-Type and Authorization; and it sets the Access-Control-Max-Age header field to specify the caching time for the preflight request result, typically 86400 seconds. In different technology frameworks, such as the Node.js Express framework, these response headers are set through the res.header() method; in the Java Spring Boot framework, a global CORS strategy is configured through the @CrossOrigin annotation or WebMvcConfigurer; in the Nginx reverse proxy layer, these cross-domain header information can be preset in the configuration file through the add_header directive.

[0066] Step S1013: When both the source information and the source page information are unreliable, or when the request method information indicates that the client request is a pre-inspection request, the response to the request acquisition event ends.

[0067] When both the source information and the originating page information are determined to be untrusted, or the request method information indicates that the current request is a preflight request, the server immediately terminates the processing of that request. For requests from untrusted sources, the server constructs an HTTP 403 Forbidden response with a JSON-formatted error message in the response body, such as {"code":403,"message":"Forbidden origin"}, and closes the connection. For preflight requests, the server does not execute business logic but directly returns an HTTP 204 No Content response, containing only necessary CORS response headers such as Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Max-Age, without any response body content. In high-concurrency environments, the server employs a short-circuit mechanism; once it determines that the response needs to be terminated, it immediately releases the thread resources and database connection occupied by the request to avoid unnecessary computation consuming system resources. This security interception mechanism can also be implemented in the API gateway layer or web application firewall. By configuring security rules, requests that do not meet the conditions are blocked and rejected before reaching the business server.

[0068] In this embodiment, a request security filtering mechanism is further strengthened on top of authentication. Through multi-dimensional credibility assessment of request source information, originating page, and request method, legitimate cross-domain requests are accurately identified and corresponding response headers are configured. This effectively defends against common web security threats such as Cross-Site Request Forgery (CSRF) and Cross-Site Scripting (XSS) attacks, while complying with the security requirements of modern web applications. This refined request processing strategy not only ensures the security boundary of exposed interfaces, preventing malicious requests from penetrating core business logic, but also optimizes the efficiency of legitimate cross-domain communication by correctly handling preflight requests. Therefore, a multi-layered security protection system is built without sacrificing user experience, significantly improving the overall security level while ensuring a seamless access experience for legitimate users.

[0069] In a further embodiment, after step S1200, obtaining the page resource data obtained by multiple microservice instances querying the database in parallel, the following steps are included: Step S2200: Based on the data storage size of the page resource data provided by the microservice instance, determine the expiration time and storage method corresponding to the page resource data; After retrieving page resource data obtained from parallel database queries by multiple microservice instances, the server needs to dynamically decide on a caching strategy based on the characteristics of this data. The server first calculates the actual memory footprint of the page resource data, typically in bytes. This calculation can be implemented using built-in functions, such as using the `Buffer.byteLength()` method to measure the length of the serialized JSON string in a Node.js environment, or obtaining the precise memory footprint of an object through the `Instrumentation` interface in a Java environment. After determining the data storage size, the server determines the corresponding expiration time and storage method according to preset mapping rules. The expiration time refers to the effective duration of the data in the cache; after expiration, the data is considered invalid and cleaned up. The storage method refers to the organization and encoding method of the data in the caching system. Mapping rules are typically implemented as configuration tables or decision functions. For example, when the data storage size is less than 100KB, an expiration time of 30 minutes is set, and full storage is used; when the data size is between 100KB and 500KB, an expiration time of 15 minutes is set, and compressed storage is used; when the data size exceeds 500KB, an expiration time of 5 minutes is set, and sharded storage is used. In compressed storage, the server compresses the data using GZIP or Snappy algorithms before storing it in the cache, reducing memory usage. In sharded storage, the server splits large data objects into multiple independent fragments based on fields or business dimensions, with each fragment stored using a different cache key, preventing large single cache entries from impacting caching system performance. The server may also adjust storage strategies based on data content characteristics. For example, data containing sensitive user information may be forcibly encrypted using the AES-256 algorithm before being cached; for frequently accessed but slowly changing data, a strategy combining longer expiration times and shorter refresh intervals is used to ensure a balance between data freshness and response speed. These decision-making logics are typically encapsulated in the cache strategy manager component, which dynamically adjusts threshold parameters through configuration files or environment variables, adapting to different business scenarios without modifying the core code.

[0070] Step S2210: Asynchronously store the page resource data and its expiration time into the cache according to the storage method.

[0071] After determining the storage method and expiration time of the page resource data, the server will perform an asynchronous cache write operation. Asynchronous storage means that the cache write process will not block the current request processing main thread. The server will continue the subsequent process immediately after initiating the cache write task, without waiting for the write operation to complete.

[0072] In the implementation, the server first converts the page resource data into a format supported by the target caching system, such as serializing JavaScript objects into JSON strings. Simultaneously, the server converts the expiration time into a time unit recognizable by the caching component, such as seconds or milliseconds required by Redis. Depending on the chosen storage method, the server preprocesses the data: if compressed storage is used, the zlib module is called for GZIP compression; if sharded storage is used, the data is split into multiple subsets according to preset sharding rules, and a unique cache key is generated for each subset, such as adding the suffix "_part1" to the original key name. After preprocessing, the server submits the cache write task to an asynchronous task queue, which can be an in-memory Promise queue, a dedicated asynchronous executor, or a distributed message queue. In a Node.js environment, the server might use `process.nextTick()` or `setImmediate()` to schedule the write operation to the next stage of the event loop; in a Java environment, a `CompletableFuture` or `ExecutorService` thread pool might be used to submit `Callable` tasks.

[0073] Internally, the cache write operation involves the server establishing a connection with the cache server through a cache client library, executing the SET or SETEX command to write data to the Redis cluster, and setting the EXPIRE parameter to specify the expiration time. For sharded storage, the server needs to initiate multiple parallel write commands, each responsible for one data segment. During the write process, the server can configure a reasonable timeout threshold, such as 500 milliseconds. When there is a network anomaly or the cache server is overloaded, the write operation is automatically abandoned without affecting the main process execution, and a warning log is recorded for subsequent monitoring and analysis.

[0074] In addition, the server can implement a retry mechanism for write failures. After the first asynchronous write fails, the task is placed in a delayed queue and retried up to three times using an exponential backoff algorithm. All asynchronous write operations are executed in a background thread or process, without affecting the server's response speed to the current request, ensuring that the timeliness of the generation and return of the first page file is not affected by caching operations.

[0075] In this embodiment, a dynamic caching strategy based on data storage size is implemented for page resource data returned by microservices. This strategy intelligently determines expiration times and storage methods, and uses an asynchronous mechanism to write data to the cache. This solves the resource waste problem caused by the "one-size-fits-all" strategy in traditional caching systems. By processing data of different sizes differently, it significantly improves cache space utilization efficiency. The asynchronous write mechanism avoids blocking the main business process during caching operations, ensuring the real-time response of the first screen. The expiration time configuration based on data size balances the relationship between data timeliness and cache hit rate. With this refined cache management strategy, not only is the pressure of repeated database queries reduced, but the selection of appropriate storage methods also optimizes memory usage efficiency, providing crucial support for maintaining high performance under high load conditions.

[0076] In a further embodiment, after step S1100, querying and obtaining the page resource data of the first screen page in the cache, the following steps are included: Step S2100: Update the most recent access time of the page resource data of the first screen page in the cache, and at the same time determine whether the page resource data belongs to hot data; After retrieving the page resource data for the first page in the cache, the server needs to update the access timestamp of that cached item. This operation is achieved by modifying the time field in the cache data metadata. Specifically, in the Redis caching system, while the server executes the EXPIRE command to reset the key's time-to-live, it records the last access timestamp of each cache key using an additional hash table. The most recent access time refers to the exact moment when the page resource data was read from the cache, recorded precisely to the millisecond level in Unix timestamp format. This timestamp is used to measure the data's activity and access frequency.

[0077] While updating the most recent access time, the server executes hot data determination logic. Hot data refers to page resource data that is accessed frequently within a specific time window. The determination criteria include, but are not limited to: access frequency threshold per unit time (e.g., more than 100 accesses per minute), average value of consecutive access intervals (e.g., average interval less than 2 seconds), or a weighted access frequency algorithm based on a sliding window.

[0078] In one embodiment, the server maintains an independent hotspot counter. Each time the cache is hit, the corresponding counter is incremented by 1. When the counter value exceeds a preset threshold (such as 1000), it is determined to be hotspot data. In another embodiment, the server uses a variant of the LFU (Least Frequently Used) algorithm to calculate the ratio of access frequency to data size. When the ratio exceeds a dynamically adjusted baseline, the data is identified as hot data.

[0079] In another implementation, the server defines hotspot rules based on business characteristics. For example, for e-commerce platforms, the first-screen page resource data containing promotional activities and flash sale products is marked as hotspot data by default, without needing to be verified by access frequency.

[0080] Step S2110: When the page resource data is hot data, extend the expiration time of the page resource data.

[0081] When page resource data is identified as hot data, the server automatically extends its expiration time in the cache. Expiration time refers to the effective period during which the caching system retains the data; after this period, the cached data will be automatically cleaned up or marked as invalid. The extension operation is achieved by resetting the TTL (Time To Live) value of the cache key, specifying the new expiration time by calling the EXPIREAT or PEXPIRE command in Redis. The specific extension strategy employs a multi-level dynamic adjustment mechanism: in one embodiment, the basic extension ratio is 50% of the original expiration time, for example, extending the original 5-minute expiration time to 7.5 minutes; the enhanced extension strategy differentiates based on the hotness level, extending by 100% when the access frequency exceeds a threshold of 200%, and by 200% when it exceeds 300%; an upper limit control mechanism prevents the expiration time from growing indefinitely, setting an absolute maximum value (e.g., 24 hours) or a relative maximum value (not exceeding 5 times the original expiration time).

[0082] In another embodiment, differentiated expiration rules are used for different types of data. For example, the expiration time of user-personalized data (such as shopping carts and browsing history) is extended to a maximum of 30 minutes, while the expiration time of globally shared data (such as product categories and promotional information) can be extended to several hours.

[0083] Expiration operations are executed within transactions to ensure the atomicity of expiration updates. In a distributed caching environment, the server uses a coordination mechanism of the cache cluster (such as slot mapping in Redis Cluster) to ensure that expiration time updates are consistently effective across all data shards, avoiding differences in user experience caused by cache inconsistencies.

[0084] In this embodiment, a hot data identification and dynamic expiration time adjustment mechanism is introduced after cache querying. By updating the access timestamp and intelligently judging the data popularity, a cache time extension strategy is implemented for popular content. This effectively addresses the limitations of traditional caching systems in adapting to changes in access patterns, allowing limited cache resources to prioritize the highest-value content. By implementing an adaptive cache optimization mechanism, the hit rate of frequently accessed content is significantly improved, reducing the pressure of repeated calls to backend services, while ensuring a consistent experience for a large number of users accessing popular content. By dynamically focusing cache resources on hot data that truly generates business value, not only is overall response speed improved, but infrastructure costs are also reduced, achieving a dual optimization of user experience and operational efficiency.

[0085] In a further embodiment, after step S2210, which asynchronously stores the page resource data and its expiration time into the cache according to the storage method, the following steps are included: Step S3210: Determine whether the data storage volume of the cache has reached a preset threshold. When the data storage volume reaches the preset threshold, activate the cache cleaner. In a caching system, data storage volume refers to the total memory space occupied by all key-value pairs in the current cache, usually measured in bytes. The server obtains real-time storage volume data by calling the caching system's internal API, such as executing the `INFO memory` command in Redis to retrieve the `used_memory` field value, or directly reading it through the `getMemoryUsage()` method provided by its client library. A preset threshold is a pre-configured upper limit for memory usage, determined based on the server's physical memory capacity and business needs, typically set to 70%-80% of the physical memory. For example, on a server with 16GB of memory, the preset threshold can be configured to 12GB. The server compares the real-time storage volume with the preset threshold; when the real-time storage volume is greater than or equal to the preset threshold, the cache cleaner component is automatically activated. The cache cleaner is an independent background service module responsible for performing cache item filtering and eviction operations, ensuring that the cleanup operations do not excessively impact the performance of the main business logic.

[0086] Step S3211: The cache cleaner deletes the corresponding page resource data in the cache according to the target cleanup strategy with the best cache cleanup effect based on the preset cleanup strategy.

[0087] The preset cleanup strategy is a predefined set of cache eviction algorithms, including LRU (Least Recently Used), LFU (Least Frequently Used), TTL-first (Expiration Time First), and hybrid strategies.

[0088] After startup, the cache cleaner first performs a full sampling analysis of the current cache state, collecting metrics from one or more dimensions such as access frequency, last access time, remaining validity period, and data volume for each cache item. Then, the cleaner calculates the expected effect value of each cleanup strategy based on a preset evaluation function. This function comprehensively considers three core parameters: the amount of memory space released, the impact on hit rate, and CPU consumption cost. For example, the effect value of the LRU strategy = estimated memory released × 0.6 - estimated hit rate decrease × 0.3 - CPU consumption × 0.1. The cleaner sorts the effect values ​​of all strategies and selects the strategy with the highest value as the target cleanup strategy. During the execution phase, the cleaner filters items to be deleted according to the specific rules of the target cleanup strategy. For example, when selecting the LRU strategy, it sorts by last access time from smallest to largest and selects the top N items; when selecting the TTL priority strategy, it selects the item with the shortest remaining validity period. The cleaner removes the selected page resource data from the cache using batch DELETE commands, and simultaneously records the cleanup log including the number of deleted items, the total amount of memory released, and the strategy name for subsequent monitoring and analysis. The cleanup operation is performed in batches, with each batch processing no more than, for example, 1000 keys, and the batch interval is no less than, for example, 100 milliseconds, to avoid service jitter caused by instantaneous high load.

[0089] In this embodiment, a threshold-triggered intelligent cache cleanup mechanism is designed. When the cache capacity reaches a critical point, a multi-strategy evaluation algorithm is automatically activated to select the optimal cleanup scheme. This fundamentally solves the memory overflow risk faced by the caching system and avoids system crashes or performance drops caused by cache bloat through proactive resource management. The centralized strategy evaluation mechanism comprehensively considers multi-dimensional data factors, achieving optimal release of cache space while ensuring core functionality remains unaffected. By adopting this proactive cache governance strategy, not only is long-term operational stability ensured, but a high hit rate is maintained through continuous optimization of cache content quality. This provides elastic buffering capabilities for sudden traffic spikes during peak business periods, significantly improving service reliability and predictability.

[0090] Please see Figure 2This invention provides a first-screen page display device to meet one of the purposes of this application. It is a functional embodiment of the first-screen page display method of this application. The device includes an event response module 1100, a parallel database query module 1200, a page rendering module 1300, and a page display module 1400. The event response module 1100 is used to respond to a request to retrieve the first-screen page, query and retrieve the page resource data of the first-screen page from the cache. The parallel database query module 1200 is used to retrieve the page resource data of the first-screen page that is not stored in the cache, obtained by parallel database queries from multiple microservice instances. The page rendering module 1300 is used to enable a preset page template engine to inject the complete page resource data of the first-screen page into a preset page template and perform page rendering to obtain the corresponding first-screen page file. The page display module 1400 is used to return the first-screen page file to the client corresponding to the client that triggered the request to retrieve the first-screen page for displaying the first-screen page.

[0091] In a further embodiment, before the event response module 1100, there are: a request parsing submodule, used to receive a client request corresponding to the request acquisition event, and parse the user identity token and the request user identifier in the client request; and a user verification submodule, used to verify whether the user identity token and the request user identifier match, and if they do not match, to end the response to the request acquisition event.

[0092] In a further embodiment, receiving the client request corresponding to the request acquisition event includes: a load balancing submodule, used by the load balancer to receive the client request corresponding to the request acquisition event and determine the target server in the server cluster whose load status meets preset conditions; and a request forwarding submodule, used by the load balancer to forward the client request to the target server, and by the target server to respond to the request acquisition event.

[0093] In a further embodiment, after the user verification submodule, the system includes: an information judgment submodule, used to determine the source information, source page information, and request method information corresponding to the client request, to determine whether the source information and source page information are trustworthy, and to determine whether the request method information indicates whether the request belongs to a pre-inspection request; a request configuration submodule, used to configure preset cross-domain response header information for the request when the source information or the source page information is trustworthy, and the request method information indicates that the client request does not belong to a pre-inspection request; and a first event termination submodule, used to terminate the response to the request acquisition event when both the source information and the source page information are untrustworthy, or the request method information indicates that the client request belongs to a pre-inspection request.

[0094] In a further embodiment, after the parallel database lookup module 1200, there are: a storage decision submodule, used to determine the expiration time and storage method corresponding to the page resource data based on the data storage size of the page resource data provided by the microservice instance; and an asynchronous caching submodule, used to asynchronously store the page resource data and its expiration time into the cache according to the storage method.

[0095] In a further embodiment, after the event response module 1100, there is a: a time update submodule, used to update the most recent access time of the page resource data of the first screen page in the cache, and at the same time determine whether the page resource data belongs to hot data; and an event extension submodule, used to extend the expiration time of the page resource data when the page resource data belongs to hot data.

[0096] In a further embodiment, after the asynchronous caching submodule, there is a submodule for determining whether the cached data storage volume has reached a preset threshold, and when the data storage volume reaches the preset threshold, activating the cache cleaner; and a cache cleaning submodule for having the cache cleaner centrally select the target cleaning strategy with the best cache cleaning effect based on a preset cleaning strategy to delete the corresponding page resource data in the cache.

[0097] To address the aforementioned technical problems, embodiments of this application also provide computer equipment. For example... Figure 3 The diagram shows the internal structure of a computer device. The computer device includes a processor, a computer-readable storage medium, a memory, and a network interface connected via a system bus. The computer-readable storage medium stores an operating system, a database, and computer-readable instructions. The database may store a sequence of control information. When the computer-readable instructions are executed by the processor, the processor can implement a first-screen page display method. The processor of the computer device provides computing and control capabilities to support the operation of the entire computer device. The memory of the computer device may store computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor can execute the first-screen page display method of this application. The network interface of the computer device is used for communication with a terminal. Those skilled in the art will understand that… Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0098] In this embodiment, the processor is used to execute... Figure 2The system contains the specific functions of each module and its sub-modules, and the memory stores the program code and various data required to execute these modules or sub-modules. The network interface is used for data transmission between the user terminal and the server. In this embodiment, the memory stores the program code and data required to execute all modules / sub-modules in the first-screen page display device of this application, and the server can call the server's program code and data to execute the functions of all sub-modules.

[0099] This application also provides a storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the first-screen page display method of any embodiment of this application.

[0100] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The aforementioned storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0101] In summary, this application can quickly construct the first screen page, significantly shorten the display time, and improve the user experience.

[0102] Those skilled in the art will understand that the steps, measures, and solutions in the various operations, methods, and processes discussed in this application can be alternated, modified, combined, or deleted. Furthermore, other steps, measures, and solutions in the various operations, methods, and processes discussed in this application can also be alternated, modified, rearranged, decomposed, combined, or deleted. Furthermore, steps, measures, and solutions in the prior art that are similar to those disclosed in this application can also be alternated, modified, rearranged, decomposed, combined, or deleted.

[0103] The above description is only a partial embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for displaying a homepage, characterized in that, Includes the following steps: Respond to the request event for the first screen page, query and retrieve the page resource data of the first screen page from the cache; For page resource data of the first screen page that is not stored in the cache, obtain the page resource data obtained by multiple microservice instances querying the database in parallel; The preset page template engine is enabled to inject the complete page resource data of the first screen page into the preset page template and render the page to obtain the corresponding first screen page file; The first screen page file is returned to the client corresponding to the request event, for displaying the first screen page.

2. The method for displaying the first screen page according to claim 1, characterized in that, Before querying and retrieving the page resource data of the first screen page from the cache, the following steps are included: Receive the client request corresponding to the request acquisition event, and parse the user identity token and requesting user identifier in the client request; Verify whether the user identity token matches the requesting user identifier. If they do not match, terminate the response to the request acquisition event.

3. The method for displaying the first screen page according to claim 2, characterized in that, Receiving the client request corresponding to the requested event includes the following steps: The load balancer receives the client request corresponding to the request acquisition event and determines the target server in the server cluster whose load status meets the preset conditions. The load balancer forwards the client request to the target server, and the target server responds to the request by obtaining an event.

4. The method for displaying the first screen page according to claim 2, characterized in that, After verifying that the user identity token matches the requesting user identifier, the following steps are included: Determine the source information, source page information, and request method information corresponding to the client request; determine whether the source information and source page information are trustworthy; and determine whether the request method information indicates whether the request belongs to a pre-inspection request. When the source information or the source page information is reliable, and the request method information indicates that the client request does not belong to the preflight request, a preset cross-domain response header is configured for the request; When both the source information and the source page information are unreliable, or when the request method information indicates that the client request is a preflight request, the response to the request acquisition event ends.

5. The method for displaying the first screen page according to claim 1, characterized in that, After obtaining the page resource data from multiple microservice instances querying the database in parallel, the following steps are included: Based on the data storage size of the page resource data provided by the microservice instance, determine the expiration time and storage method corresponding to the page resource data; The page resource data and its expiration time are asynchronously stored in the cache according to the storage method.

6. The method for displaying the first screen page according to claim 1, characterized in that, After querying and retrieving the page resource data of the first screen page from the cache, the following steps are included: Update the last access time of the page resource data of the first screen page in the cache, and at the same time determine whether the page resource data belongs to hot data; When the page resource data is considered "hot data", the expiration time of the page resource data is extended.

7. The method for displaying the first screen page according to claim 1, characterized in that, After asynchronously storing the page resource data and its expiration time into the cache according to the storage method, the following steps are included: Determine whether the amount of data stored in the cache has reached a preset threshold. If the amount of data stored has reached the preset threshold, activate the cache cleaner. The cache cleaner uses a preset cleaning strategy to select the target cleaning strategy that yields the best cache cleaning effect and deletes the corresponding page resource data in the cache.

8. A homepage display device, characterized in that, include: The event response module is used to respond to the request to retrieve events of the first screen page, and to query and retrieve the page resource data of the first screen page in the cache; The parallel database query module is used to obtain the page resource data of the first screen page that is not stored in the cache by obtaining the page resource data obtained by multiple microservice instances querying the database in parallel. The page rendering module is used to enable the preset page template engine to inject the complete page resource data of the first screen page into the preset page template and perform page rendering to obtain the corresponding first screen page file. The page display module is used to return the first screen page file to the client corresponding to the request to obtain the event, and to display the first screen page.

9. A computer device comprising a central processing unit and a memory, characterized in that, The central processing unit is used to invoke and run a computer program stored in the memory to perform the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores, in the form of computer-readable instructions, a computer program implemented according to any one of claims 1 to 7, which, when invoked by a computer, executes the steps included in the corresponding method.

Images