Real-time transaction record query method and device and computer equipment

Abstract

The invention relates to the field of computer data processing, and discloses a real-time transaction record query method and device and computer equipment, and the method comprises the steps: querying from each second fund sales platform based on a query request through an aggregation layer of a first fund sales platform to obtain a target transaction record corresponding to a query type of the query request, wherein the transaction record comprises a first specified number of transaction records generated by each second fund sales platform before the current system moment. And storing the queried target transaction record in a temporary memory database. And sorting the target transaction records according to a specified screening condition, storing the sorted transaction records in a transaction record database, and then destroying the temporary memory database. And obtaining a second specified number of to-be-displayed transaction records from the sequenced transaction records, and returning the to-be-displayed transaction records to the front end for displaying. Therefore, the latest transaction record data of different platform services can be queried in real time, the query data volume is effectively reduced, and the query efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of computer data processing, and in particular to a real-time transaction record query method, device and computer equipment. Background Art

[0002] With the rapid development of the Internet, the amount of data has shown explosive growth. Especially in the fund industry, with increasingly complex sales business scenarios and growing transaction volumes, how to obtain, store, process and query these massive transaction record data in real time has become an urgent problem to be solved. Summary of the invention

[0003] The present application aims to solve at least one of the technical problems in the related art to a certain extent. To this end, the present application proposes a real-time transaction record query method, device and computer equipment. The main technical solutions adopted by the present application include:

[0004] In a first aspect, an embodiment of the present application provides a real-time transaction record query method, which is applied to a first fund sales platform, and the first fund sales platform is communicatively connected to multiple second fund sales platforms; the method includes: when the first fund sales platform receives a query request, based on the query request, querying from each second fund sales platform through the aggregation layer of the first fund sales platform to obtain a query result corresponding to the query category of the query request; wherein the query result includes a target transaction record, and the target transaction record includes a first specified number of transaction records generated by each second fund sales platform before the current system time, and the current system time is the time when the first fund sales platform receives the query request; storing the queried target transaction records in a temporary memory database; sorting the target transaction records according to specified filtering conditions to obtain sorted transaction records, storing the sorted transaction records in a transaction record database, and destroying the temporary memory database; obtaining a second specified number of transaction records to be displayed from the sorted transaction records, and returning the transaction records to be displayed to the front end for display.

[0005] Optionally, when the query category is continuous paging query, the transaction records to be displayed are the current page transaction records, and the current page transaction records are recorded as the Nth page transaction records; the method also includes: when the first fund sales platform receives a continuous page query request, through the aggregation layer, based on the continuous page query request, query from each second fund sales platform to obtain continuous page transaction records to display the N+1th page transaction records in the continuous page transaction records; wherein, the current page transaction records have a first specified transaction record, and the N+1th page transaction records include a first specified number of transaction records generated before the transaction generation time of the first specified transaction record.

[0006] Optionally, the continuous pages of transaction records include a third specified number of transaction records, which is twice the first specified number, and the continuous pages of transaction records also include the N+2 page of transaction records; the N+1 page of transaction records has the second specified transaction records, and the N+2 page of transaction records includes the first specified number of transaction records generated before the transaction of the second specified transaction record was generated.

[0007] Optionally, when the query category is a jump page query, after storing the queried target transaction record in a temporary memory database, the method also includes: synchronously backing up the target transaction record to the distributed cache of the first fund sales platform, and setting an expiration time for the target transaction record.

[0008] Optionally, when the query category is a jump page query, the transaction records to be displayed are the current page transaction records, and the current page transaction records are recorded as the Nth page transaction records; the query results include the sum of the number of transactions returned by all second fund sales platforms to the first fund sales platform; the method also includes: in the case of jumping from the Nth page of transaction records to the Pth page of transaction records, detecting whether there are Pth page of transaction records in the distributed cache based on the sum of the number of transactions, if not, querying from each second fund sales platform through the aggregation layer to obtain a fourth specified number of transaction records and the total number of transactions of each second fund sales platform, so as to display the Pth page of transaction records; wherein the fourth specified number is P times the first specified number, the P-1th page of transaction records has a third specified transaction record, and the Pth page of transaction records includes the first specified number of transaction records generated before the transaction generation time of the third specified transaction record.

[0009] Optionally, the method further includes: synchronously backing up a fourth specified number of transaction records to a distributed cache of the first fund sales platform, and setting an expiration time for the fourth specified number of transaction records.

[0010] Optionally, when the query category is a jump page query, the transaction records to be displayed are the current page transaction records, and the current page transaction records are recorded as the Nth page transaction records. The query results include the sum of the number of transactions returned by all second fund sales platforms to the first fund sales platform; the method also includes: in the case of jumping from the Nth page of transaction records to the Pth page of transaction records, if it is detected that there are M pages of transaction records in the distributed cache based on the sum of the number of transactions, and the M pages of transaction records do not include the Pth page of transaction records, querying from each second fund sales platform through the aggregation layer to obtain the fifth specified number of transaction records and the total number of transactions of each second fund sales platform, and synchronously backing up the fifth specified number of transaction records to the distributed cache of the first fund sales platform; wherein, an expiration time is set for the fifth specified number of transaction records; the fifth specified number is PM times the first specified number, the Mth page of transaction records has a fourth specified transaction record, and the fifth specified number of transaction records includes PM times the first specified number of transaction records generated before the transaction generation time of the fourth specified transaction record.

[0011] Optionally, when the query category is a jump page query, the transaction records to be displayed are the current page transaction records, and the current page transaction records are recorded as the Nth page transaction records; the query results include the sum of the number of transactions returned by all second fund sales platforms to the first fund sales platform; the method also includes: in the case of jumping from the Nth page of transaction records to the Pth page of transaction records, detecting whether there are Pth page of transaction records in the distributed cache based on the sum of the number of transactions, and if so, updating the expiration time of the Pth page of transaction records, and returning the Pth page of transaction records to the front end for display.

[0012] In a second aspect, an embodiment of the present application provides a real-time transaction record query device, which is applied to a first fund sales platform, and the first fund sales platform is communicatively connected to multiple second fund sales platforms; the device includes: a transaction record query module, which is used to query from each second fund sales platform based on the query request through the aggregation layer of the first fund sales platform when the first fund sales platform receives a query request, and obtain a query result corresponding to the query category of the query request; wherein the query result includes a target transaction record, and the target transaction record includes a first specified number of transaction records generated by each second fund sales platform before the current system time, and the current system time is the time when the first fund sales platform receives the query request; a temporary storage module, which is used to store the queried target transaction records in a temporary memory database; a transaction record storage module, which is used to sort the target transaction records according to specified filtering conditions, obtain sorted transaction records, store the sorted transaction records in the transaction record database, and destroy the temporary memory database; a transaction record return module, which is used to obtain a second specified number of transaction records to be displayed from the sorted transaction records, and return the transaction records to be displayed to the front end for display.

[0013] In a third aspect, the present application further provides a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of any of the above methods when executing the computer program.

[0014] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which implements the steps of any of the above methods when the computer program is executed by a processor.

[0015] In a fifth aspect, the present invention provides a computer program product, comprising a computer program, which implements the steps of any of the above methods when executed by a processor.

[0016] In the above embodiment, when the first fund sales platform receives a query request, the aggregation layer of the first fund sales platform queries each second fund sales platform based on the query request to obtain a query result corresponding to the query category of the query request; wherein the query result includes the target transaction record, and the target transaction record includes the first specified number of transaction records generated by each second fund sales platform before the current system time, and the current system time is the time when the first fund sales platform receives the query request; the queried target transaction record is stored in a temporary memory database; the target transaction record is sorted according to the specified screening conditions to obtain the sorted transaction record, the sorted transaction record is stored in the transaction record database, and the temporary memory database is destroyed; the second specified number of transaction records to be displayed are obtained from the sorted transaction record, and the transaction record to be displayed is returned to the front end for display. So far, by establishing and using a temporary memory database, it is displayed to the user according to the specified number of records, so as to achieve real-time query of the latest transaction record data of different platform services, effectively reduce the amount of query data, and improve query efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the specific implementation methods of the present application or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0018] Figure 1a A flowchart of a real-time transaction record query method provided according to an embodiment of the present application;

[0019] Figure 1b A flowchart of a real-time transaction record query method provided according to another embodiment of the present application;

[0020] Figure 2A structural block diagram of a real-time transaction record query device provided according to another embodiment of the present application;

[0021] Figure 3 The figure is a diagram of the internal structure of a computer device according to one embodiment of the present application. DETAILED DESCRIPTION

[0022] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0023] With the rapid development of the Internet, the amount of data has shown explosive growth. In this context, how to effectively acquire, store, process and query these massive data has become an urgent problem to be solved.

[0024] Take the fund industry as an example. With the expansion of fund sales business, the official sales platform of fund companies not only needs to provide query of transaction records of their own funds, but also needs to sell other funds through multiple channels. Faced with increasingly complex sales scenarios and rising transaction volumes, customers have higher requirements for the richness of the platform's query functions and response speed. Among the related technologies, the aggregate query technology currently used in the fund industry can be roughly classified into the following two types: storing data in a centralized database of a service to achieve full-scenario query; distributing data in different services and returning aggregated data after distributed access.

[0025] However, both methods have their limitations. For the first method, it is difficult to achieve real-time query due to the delay in database synchronization. For the second method, it is usually necessary to query data within a specific time range from each system, and then aggregate and sort it by the middle office service. The query efficiency of this method increases linearly with the increase in the query volume. When the number of query pages or the amount of data is large, the efficiency will drop significantly, and it is difficult to achieve paging query. Therefore, improving the aggregation and paging performance of the fund sales system in the real-time transaction record query scenario, while optimizing the user experience and reducing the data query burden of the downstream system has become an urgent problem to be solved.

[0026] Based on this, according to an embodiment of the present application, a real-time transaction record query method embodiment is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0027] In this embodiment, a real-time transaction record query method is provided, which is applied to a first fund sales platform. The first fund sales platform is communicatively connected to a plurality of second fund sales platforms. Figure 1a is a flow chart of a real-time transaction record query method according to an embodiment of the present application. Figure 1a As shown, the process includes the following steps:

[0028] S110. When the first fund sales platform receives a query request, the aggregation layer of the first fund sales platform queries each second fund sales platform based on the query request to obtain a query result corresponding to the query category of the query request.

[0029] The query result includes target transaction records, which include the first specified number of transaction records generated by each second fund sales platform before the current system time. The current system time is the time when the first fund sales platform receives the query request.

[0030] Specifically, the first fund sales platform may refer to a centralized comprehensive financial service platform, on which fund products and services provided by multiple financial institutions may be aggregated, providing users with a comprehensive interface that allows users to browse and compare fund product transaction contents from different financial institutions on a unified platform. The second fund sales platform may refer to the sales platform of each individual financial institution (such as a bank, fund company, etc.), which focuses on providing fund product transactions and services of the institution and is independent of other financial institution platforms. Exemplarily, the second fund sales platform may be a downstream sub-service system, such as direct sales, wealth sub-agent sales, and data centers.

[0031] Furthermore, the first fund sales platform can send query requests from mobile client users or PC users to multiple second fund sales platforms through its aggregation layer component, and then collect the query results of the first specified number of transactions returned by them and aggregate the queried fund transaction records on the first fund sales platform. Among them, the first specified number of transactions can be a pre-defined number of transaction records obtained from each second fund sales platform. Specifically, in order to ensure that users can smoothly view enough transaction records on each page, and avoid loading too much data at one time, resulting in excessive system load or slow response, the upper limit of the transaction records returned from each second fund sales platform can be pre-defined during the preliminary query, that is, the target transaction records queried can be queried and returned in batches by setting the first specified number of transactions. Exemplarily, if the first fund sales platform is set to display 50 transaction records per page, since sorting and filtering are required after the preliminary query, the first specified number of transactions can be set to 100 as the target number of queries during the query, so as to ensure that after subsequent sorting and filtering, even if some transaction records do not meet the user's filtering conditions, at least 50 records can be displayed on the front-end page in the end.

[0032] It should be understood that the user's query request may include the query conditions specified by the user, such as only viewing the transaction records of a certain time period or the transaction records of a specific fund. In addition, the user's query request may also include the user's query category, that is, the user can also choose how they want to view these transaction records, which can be a page jump query method that directly jumps to a specific page number, or a continuous query method that starts from the first page and continuously browses subsequent pages. The query result obtained after the query is the transaction record data that meets the specific query conditions retrieved from the database of each second fund sales platform according to the query request, that is, the target transaction record. These target transaction records are all transaction records that already exist in each second fund sales platform before the current system time based on the query, that is, the time point when the first fund sales platform receives the query request, and contain the transaction information that the user wants to view or analyze.

[0033] Specifically, the first fund sales platform will first receive a query request from the user, which represents that the user wants to view the transaction records of multiple fund sales platforms, and hopes that these transaction records can be presented in the desired form. When the first fund sales platform receives the query request from the client user, it will distribute the user's query request to multiple second fund sales platforms that are connected to it, so that each second fund sales platform queries the various transaction records contained in its database according to the received query request, and returns the first specified number of transaction records to the aggregation layer system of the first fund sales platform in a certain order for aggregation. Exemplarily, when a mobile client user queries fund transaction records, a specific moment can be used as the starting time, and then a query request can be sent to the first fund sales platform based on the time in the presentation method desired by the user. If the first fund sales platform allows N transaction records to be presented to the user on a single page, the first specified number can be taken as N, and then the first fund sales platform will use its aggregation layer to query the top N records from its database based on the current system moment according to the screening conditions from multiple second fund sales platforms to obtain the target transaction records.

[0034] Optionally, when the aggregation layer queries transaction records from the second fund sales platform, a machine learning model (such as a deep Q network) can be used to evaluate and select the optimal query execution plan. Specifically, the machine model can be trained based on the AutoQuo optimizer. First, for each second fund sales platform, multiple query execution plans including different data retrieval strategies and index usage methods are generated as candidate sets for training the machine model. Then, the candidate set is used to execute the selected query plan, and the execution results are recorded as feedback signals for reinforcement learning. Further, the machine learning model is trained according to the feedback signal to learn how to select the optimal query plan, and the query plan selection strategy is updated according to the training results of the model to optimize future query execution. In this process, the AutoQuo framework can adapt to new query patterns or database state changes, so that the aggregation layer can work effectively under different loads and query environments. By applying the AutoQuo framework to query optimization at the aggregation layer, the efficiency and performance of querying transaction records from the second fund sales platform can be improved, especially when faced with complex and changing query requirements. This approach can reduce query latency, improve resource utilization, and ultimately improve user experience.

[0035] S120: Store the queried target transaction record in a temporary memory database.

[0036] Among them, the temporary memory database may refer to a database table that is established based on each query request during the query period and is used to handle short-term data storage and retrieval needs and stores data as an intermediate result. Exemplarily, in response to the user's query request, the backend service of the first fund sales platform will respond quickly and create a dedicated temporary table in the local temporary memory database for each request. And generate its unique table name according to the UUID algorithm. Furthermore, after performing a query operation to obtain the target transaction record, the SQL language is used to integrate the data from each second fund sales platform, that is, the target transaction record corresponding to each query request is stored in the temporary table created in response to the query request in the temporary memory database for subsequent processing.

[0037] S130. Sort the target transaction records according to the specified screening conditions to obtain sorted transaction records, store the sorted transaction records in a transaction record database, and destroy the temporary memory database.

[0038] Among them, the specified filtering condition may refer to a specific parameter or standard set by the user or the system when querying data, which is used to filter out qualified transaction records from a large number of transaction records. Exemplarily, the specified filtering condition may be a date range, an amount, or a transaction status, etc. Specifically, according to the filtering condition specified by the user, the aggregation layer system will filter the target transaction records stored in the temporary memory database, find the records that meet these conditions, and sort the filtered target transaction records in a certain order (such as time order or amount, etc.). Further, the sorted transaction records are transferred from the temporary memory database to the transaction record database, and the temporary memory database is destroyed to release memory resources. Among them, the transaction record database is different from the temporary memory database, which can be a memory or a database stored on a non-volatile storage medium. It is understandable that before sending the sorted and filtered data to the user, it is necessary to ensure that the data has been securely stored in the persistent transaction record database. Because the purpose of the temporary memory database has been achieved, the data stored in it has been transferred to a safer and more durable storage medium. Once it is confirmed that the data requested by the user is ready to be returned, the temporary memory database previously used to store and process the data can be destroyed. After destroying the temporary memory database, the memory space originally occupied by these data will be released, thus avoiding the waste of memory resources and providing space for responding to the next new query request.

[0039] S140. Obtain a second specified number of transaction records to be displayed from the sorted transaction records, and return the transaction records to be displayed to the front end for display.

[0040] Among them, the second specified number refers to the number of transaction records pre-set for display in the data processing process. Specifically, the second specified number can be set according to the needs of the user or the design of the display interface to help users browse and analyze data more effectively, while avoiding performance problems caused by loading too much data at one time. Exemplarily, if the first fund sales platform allows a maximum of 50 transaction records to be displayed on one page, the second specified number can be 50. The transaction records to be displayed can refer to those transaction records that are sorted and filtered and are ready to be sent to the front-end interface for users to view. Specifically, from the sorted transaction records, according to the parameter of the second specified number, a certain number of sorted transaction records are selected as the transaction records to be displayed returned to the client, so that users can interact with these transaction records on the front-end interface, such as viewing detailed information or performing further filtering.

[0041] Understandably, please refer to Figure 1b , the aggregation layer can be a system component on the first fund sales platform, which can be responsible for receiving user query requests and distributing these requests to different second fund sales platforms. The second fund sales platform can be a downstream sub-service system, such as direct sales, wealth sub-distribution sales, and data center as shown in the figure. The "request query" in the figure is a query request operation initiated by the user on the first fund sales platform. Further, when the aggregation layer receives the query request, it will determine whether an aggregate query is required. If necessary, and the query request is authorized by the user and the service provider, the aggregation layer will distribute the query request to each second fund sales platform (direct sales, wealth sub-distribution sales, data center) to perform the query operation and retrieve relevant transaction record information. The final query results will be returned from each second fund sales platform to the aggregation layer, and the aggregation layer will then integrate these data to form an intuitive query result and display it to the user.

[0042] In the above implementation, when the first fund sales platform receives a query request, the aggregation layer of the first fund sales platform queries each second fund sales platform based on the query request to obtain a query result corresponding to the query category of the query request; wherein the query result includes the target transaction record, and the target transaction record includes the first specified number of transaction records generated by each second fund sales platform before the current system time, and the current system time is the time when the first fund sales platform receives the query request; the queried target transaction record is stored in a temporary memory database; the target transaction record is sorted according to the specified screening conditions to obtain the sorted transaction record, the sorted transaction record is stored in the transaction record database, and the temporary memory database is destroyed; the second specified number of transaction records to be displayed are obtained from the sorted transaction record, and the transaction records to be displayed are returned to the front end for display. So far, by establishing and using a temporary memory database, it is displayed to users according to the specified number of records, so as to achieve real-time query of the latest transaction record data of different platform services, effectively reduce the amount of query data, and improve query efficiency.

[0043] In some implementations, when the query type is a continuous paging query, the transaction records to be displayed are the transaction records of the current page, and the transaction records of the current page are recorded as the transaction records of the Nth page. The method further includes:

[0044] When the first fund sales platform receives a continuous page query request, it queries each second fund sales platform based on the continuous page query request through the aggregation layer to obtain continuous page transaction records to display the N+1th page transaction records in the continuous page transaction records.

[0045] It is understandable that due to the limitation of the display space of the front-end interface, the number of transaction records displayed on each page of the first fund sales platform is not infinite. For example, if the upper limit of the number displayed per page is 50, then the user's first query request can only display 50 transaction records on the page. Because before the data is returned, in order to release memory, the temporary memory database storing the query results has been destroyed, so if the user wants to continue browsing the 51st record in sequence, it is necessary to re-initiate the query request. At this time, in response to the current query request, the page displaying the query results is the current page, and the 50 transaction records displayed on the page are the current page transaction records, which can also be recorded as the Nth page transaction records. The next page that the user wants to continue to query and browse in sequence is the continuous page of the current page, and the 51st to 100th transaction records contained in the continuous page are continuous page transaction records, which can also be recorded as the N+1th page transaction records.

[0046] Specifically, when a mobile client user wants to query fund transaction records, he can set a specific time as the starting time, and then query the historical transaction records continuously based on the time and the user's filtering conditions. That is, when the user queries and obtains the transaction records of the current page through the first fund sales platform for the first time, if he wants to continue to browse more transaction records in sequence, he needs to initiate a continuous page query request. When the first fund sales platform receives a continuous page query request with the query category as continuous paging query, it will query from each second fund sales platform based on the continuous page query request through the aggregation layer to obtain continuous page transaction records to display the N+1th page of transaction records in the continuous page transaction records. Among them, the current page of transaction records has a first specified transaction record, and the N+1th page of transaction records includes a first specified number of transaction records generated before the transaction generation time of the first specified transaction record.

[0047] Exemplarily, the transaction records may be sorted in reverse order of transaction time. If the current page only displays 50 transaction records, then upon receiving a continuous page query request, the aggregation layer system may use the last transaction record of the current page, that is, the 50th transaction record, as the first designated transaction record, and use the transaction time of the transaction record as the starting query time of the continuous page query request. Furthermore, at the starting query time, the transaction records less than or equal to the query time are forward queried from each second fund sales platform to obtain a continuous page of transaction records from the 50th to the 100th that can be displayed on the next page. Similarly, when performing a continuous paging query, for the sake of subsequent sorting and screening, the target number of queries can also be set to 100, that is, the first designated number of transaction records can be queried forward from each second fund sales platform to meet the quantity requirements for display on each page after subsequent screening.

[0048] In the above implementation, by responding to different query requests from users and accurately controlling the number of transaction records displayed on each page, excessive loading and display of data is avoided, and data redundancy on the front-end interface is reduced. Since each time a user triggers a query request, the aggregation layer of the first fund sales platform will perform a real-time query in each second fund sales platform to obtain the latest transaction record data, thereby ensuring that users can obtain the latest transaction information in a timely manner. At the same time, when querying continuously by page, the aggregation layer system will continue to query the transaction records based on the transaction time of the last transaction record on the previous page, thereby ensuring the accuracy and consistency of the data and preventing data from being missed.

[0049] In some embodiments, the continuous pages of transaction records include a third specified number of transaction records, where the third specified number is twice the first specified number, and the continuous pages of transaction records also include the N+2th page of transaction records.

[0050] The N+1th page of transaction records has a second specified transaction record, and the N+2th page of transaction records includes a first specified number of transaction records generated before the transaction generation time of the second specified transaction record.

[0051] Among them, the third specified number may refer to the number of additional transaction records included in the continuous page transaction records, in addition to the transaction records on the N+1 page. Exemplarily, taking the example of displaying 50 transactions per page, for the sake of data redundancy, when querying, the first specified number of queries can be determined as 100 transaction records, so that the number of transaction records that can be displayed on the N+1 page can be satisfied after screening. Furthermore, since the user initiates a continuous page query request, in order to respond to the user's possible further continuous query request, the query quantity can be set to twice the first specified number when querying, that is, the third specified number of continuous page transaction records can be queried. That is, 200 transaction records are queried at a time, while satisfying the number of transaction records displayed on the N+1 page, the transaction records that can be displayed on the N+2 page are pre-loaded to respond faster, thereby reducing the waiting time of users during browsing and improving user experience. It is understandable that if the 50 transaction records on the current page are recorded as the Nth page transaction records, and the 51st to 100th transaction records on the next page are recorded as the N+1th page transaction records, then the 101st to 150th transaction records on the next next page can be recorded as the N+2th page transaction records. Then, when the aggregation layer system receives a continuous page query request, it can also use the last transaction record on the N+1th page, that is, the 100th transaction record, as the second designated transaction record, and use the transaction time of the transaction record as the starting query time of the next continuous page query request. Furthermore, the transaction records less than or equal to this query time are queried from each second fund sales platform at the starting query time, so as to obtain the continuous page transaction records from the 101st to the 150th that can be pre-loaded and displayed on the next next page in response to possible further continuous query requests from users.

[0052] In the above implementation, when the user requests the transaction records on page N+1, the aggregation layer system will query the transaction records on pages N+1 and N+2 to quickly respond to the user's possible further query requests. The query of the transaction records on page N+1 starts from the second specified transaction record and queries the transaction records of the first specified number of transactions. Similarly, the query of the transaction records on page N+2 starts from the time of the second specified transaction record and queries the transaction records of the first specified number of transactions. This preparatory query logic allows the system to preload more transaction records, thereby reducing the waiting time of users during browsing and improving user experience.

[0053] In some implementations, when the query category is a page jump query, after storing the queried target transaction record in the temporary memory database, the method further includes:

[0054] The target transaction record is synchronously backed up to the distributed cache of the first fund sales platform, and an expiration time is set for the target transaction record.

[0055] Among them, page jump query refers to a query category method in which the user does not view the pages in sequence when browsing paginated data, but directly jumps to a specific page number for viewing. It is understandable that when a PC user wants to query fund transaction records, he can choose to view the transaction records page by page, that is, issue a continuous page query request; he can also issue a page jump query request and choose to directly jump to a specific page of interest to view the transaction records of the current page.

[0056] Further, in the case where the query category is a page jump query, after the queried target transaction record is stored in the temporary memory database, before the temporary memory database is destroyed, the target transaction record can be synchronously backed up to the distributed cache of the first fund sales platform, and an expiration time can be set for the target transaction record. Among them, the distributed cache can be a solution for storing data on multiple servers or nodes, allowing data to be distributed to multiple nodes to achieve fast access. Specifically, before the queried target transaction record is returned to the front end for display, these target transaction records can be additionally backed up to the distributed cache Redis, and the data is stored in the form of key-value pairs. Exemplarily, in response to the user's page jump query request, the first fund sales platform backend service will create a dedicated temporary table in the local temporary memory database for each request and insert the queried target transaction record into the temporary table. At the same time, these target transaction records will also be synchronously backed up to the distributed cache of the first fund sales platform, stored in the cache in the manner that the key value is the table name and the value value is the target transaction record, and the cache expiration time corresponding to the temporary table is set accordingly. The expiration time can refer to the maximum time that the cached data is stored in the cache, which can be determined based on business needs and data update frequency. When the storage time of the target transaction record stored in the distributed cache exceeds the expiration time limit, the system can automatically mark the corresponding data as expired data from the cache and delete it to ensure the timeliness and accuracy of the target transaction record.

[0057] Optionally, the expiration time can be configured through the Distributed Cache Entry Options, where you can set an absolute expiration time (Absolute Expiration) or a relative expiration time (Absolute ExpirationRelative To Now), as well as a sliding expiration time (Sliding Expiration). Specifically, the absolute expiration time means that the cache item will expire and be removed after a specified date and time. Exemplarily, it can be set that certain target transaction records stored in the distributed cache will be removed after a specific year, month, and date. The relative expiration time means that the cache item will expire and be removed after a specified time from now. Exemplarily, it can be set that certain target transaction records will be removed after a specific period of time after being stored in the distributed cache. The sliding expiration time means that if the cache item is not accessed within a specified period of time, the cache item will expire and be removed. If the cache item is accessed within the sliding expiration time, the expiration time will be recalculated. For example, if certain target transaction records are not accessed within 10 minutes, they will be removed. However, if these target transaction records are accessed and called again within 10 minutes, their sliding expiration time will be refreshed accordingly based on the access time.

[0058] In the above implementation, by storing the target transaction record of the query result in the distributed cache when executing the page jump query operation, the repeated query of the database is effectively reduced, thereby improving the query efficiency. In addition, the data is stored in the cache in the form of key-value pairs, which optimizes the data retrieval speed and enables the data to be quickly located and extracted. In addition, the system sets a specific expiration time for the data in the cache, ensuring the timeliness of the target transaction record and ensuring that users can access the latest data in real time, which helps to optimize system performance and improve user experience.

[0059] In some embodiments, when the query category is a page jump query, the transaction record to be displayed is the transaction record of the current page, and the transaction record of the current page is recorded as the transaction record of page N. The query result includes the sum of the number of transactions returned by all second fund sales platforms to the first fund sales platform. The method also includes:

[0060] In the case of jumping from page N of transaction records to page P of transaction records, check whether page P of transaction records exists in the distributed cache based on the total number of transactions. If not, query from each second fund sales platform through the aggregation layer to obtain the fourth specified number of transaction records and the total number of transactions on each second fund sales platform to display page P of transaction records.

[0061] Among them, the fourth specified number is P times the first specified number, the P-1th page of transaction records has the third specified transaction record, and the Pth page of transaction records includes the first specified number of transaction records generated before the transaction generation time of the third specified transaction record.

[0062] Similarly, the fourth designated number may refer to the number of transaction records that the system needs to query from each second fund sales platform in order to display the transaction records of a specific page (page P). Specifically, this number is calculated based on the first designated number, that is, the number of transaction records required to query the homepage multiplied by the target page number P. Exemplarily, taking the first designated number of 100 as an example, when P is 4, that is, it is necessary to jump from the homepage to the 4th page, the fourth designated number can be 4 times 100, that is, 400. Similarly, the transaction records can still be sorted in reverse order of transaction time. Then the last transaction record on page 3 can be used as the third designated transaction record, and the first transaction record on page 4 should all meet the transaction generation time earlier than the third designated transaction record.

[0063] It is understandable that when jumping to the page for query, in addition to determining the transaction records of the fourth specified number, it is also necessary to obtain the total number of transactions of each second fund sales platform. Among them, the sum of the number of transactions can be used to refer to the cumulative number of transaction records returned by all second fund sales platforms to the first fund sales platform in any query operation. Exemplarily, taking the first specified number of 100 in a query as an example, if you need to jump to page 2, then the cumulative number of transaction records returned by all second fund sales platforms to the first fund sales platform can be twice the number at the time of query, that is, 200, that is, the sum of the number of transactions is 200; if you need to jump to page 4, then the cumulative number of transaction records returned by all second fund sales platforms to the first fund sales platform can be 4 times the number at the time of query, that is, 400, that is, the sum of the number of transactions is 400.

[0064] Specifically, in the case of page jump query, when the aggregation layer system receives a page jump query request to jump to page P, that is, when it needs to jump from the current Nth page of transaction records to the Pth page of transaction records, it will first check whether there is a Pth page of transaction records in the distributed cache. If not, it will query each second fund sales platform through the aggregation layer to obtain the fourth specified number of transaction records and the total number of transactions of each second fund sales platform to display the Pth page of transaction records.

[0065] Similarly, the transaction records can still be sorted in reverse order of transaction time. For example, if the first specified number of transactions in a query is 100, if you want to jump from the home page to the 4th page, the system will first determine whether the transaction records on page 4 are included based on the total number of transactions stored in the cache. Since the previous query only queried the transaction records on the home page, there are only 100 transaction records in the distributed cache at this time, and the total number of transactions is much smaller than the 400 transactions on page 4. The system can then determine that there are no transaction records on page 4 in the distributed cache at this time, and then query each second fund sales platform through the aggregation layer to obtain 400 transaction records, so that there is enough data to display the transaction records of page 4 and the previous pages to the user after screening.

[0066] In the above implementation, by storing transaction records in the distributed cache, the need for direct queries to the backend database is reduced, thereby speeding up the query response speed. When users jump to any page, they can immediately see the required transaction records without having to wait for a long time for data loading. Thus, not only can the real-time nature of the target transaction records obtained by the user's current query be ensured, but also the query efficiency is improved as much as possible, reducing the pressure on the backend database and optimizing the user experience.

[0067] In some embodiments, the method further comprises:

[0068] The transaction records of the fourth specified number are synchronously backed up to the distributed cache of the first fund sales platform, and an expiration time is set for the transaction records of the fourth specified number.

[0069] Also, taking the first specified number of 100 in a query as an example, for example, if the jump from the home page to the fourth page has been completed, that is, the first fund sales platform has queried from each second fund sales platform through the aggregation layer, obtained 400 target transaction records and stored them in the temporary memory database, these 400 transaction records can be instantly synchronized and backed up, and also stored in the distributed cache of the first fund sales platform, and an expiration time is set, so that when you need to jump to the fourth page again in the future, you can immediately call and access this part of the data from the distributed cache.

[0070] In the above implementation, the data results obtained from each query are stored in the distributed cache, so that when the data needs to be accessed next time, it can be directly obtained from the cache without having to perform a time-consuming query operation again. At the same time, an expiration time is set for the data in the cache to ensure the timeliness of the data and prevent the accumulation of outdated data. Once the data expires, they will be automatically cleared from the cache, which not only ensures the freshness of the data, but also helps to free up cache space, thereby improving the operating efficiency of the entire system and the utilization rate of resources.

[0071] In some implementations, when the query type is a page jump query, the transaction record to be displayed is the transaction record of the current page, the transaction record of the current page is recorded as the transaction record of the Nth page, and the query result includes the sum of the number of transactions returned by all second fund sales platforms to the first fund sales platform. The method also includes:

[0072] In the case of jumping from the Nth page of transaction records to the Pth page of transaction records, if it is detected that there are M pages of transaction records in the distributed cache based on the total number of transactions, and the M pages of transaction records do not include the Pth page of transaction records, query from each second fund sales platform through the aggregation layer to obtain the fifth specified number of transaction records and the total number of transactions of each second fund sales platform, and synchronize the fifth specified number of transaction records to the distributed cache of the first fund sales platform.

[0073] Among them, an expiration time is set for the transaction records of the fifth specified number. The fifth specified number is PM times the first specified number, the transaction records on the Mth page have the fourth specified transaction records, and the transaction records of the fifth specified number include PM times the first specified number of transaction records generated before the transaction generation time of the fourth specified transaction record. Exemplarily, taking the first specified number of 100 as an example, when N is 1, M is 4, and P is 5, that is, after jumping from the home page to the 4th page, it is necessary to jump to the 5th page at this time. At this time, since the previous query has queried enough transaction records to display the 4th page (Mth page), and when these data are not expired, these 400 transaction records can be obtained from the direct distributed cache. At this time, if you want to display the transaction records of the 5th page (Pth page), you only need to leave the 100 transaction records between the 400th and 500th. Therefore, the fifth specified number can be PM times the first specified number, that is, the difference between the target page number P and the cached maximum page number M is 100. If N is 1, M is 4, and P is 6, that is, after jumping from the home page to the 4th page, you need to jump to the 6th page. At this time, the fifth specified number of entries is also PM times the first specified number of entries, that is, 200 entries.

[0074] It is also understandable that the transaction records can still be sorted in reverse order of transaction time. Exemplarily, taking the first specified number of 100 in a query as an example, if you just jump from page 1 to page 4, you need to jump to page 5 at this time, that is, if N is 1, M is 4, and P is 5, then the system will first determine whether the transaction records on page 5 (page P) are included based on the total number of transactions stored in the cache. Since the previous query only queried the transaction records on page 4 (page M), there are only 400 transaction records in the distributed cache, and the total number of transactions is less than the 500 required for page 5. Therefore, the system can judge that there are no transaction records on page 5 in the distributed cache at this time, and then query from each second fund sales platform through the aggregation layer. However, it should be noted that since the previous query has queried enough transaction records to display page 4 (page M), and these data are not expired, these 400 transaction records can be obtained from the direct distributed cache. At this time, if you want to display the transaction records on page 5 (page P), you only need the 100 transaction records from the 400th to the 500th. Therefore, the 400th transaction record in the transaction records on page 4 (page M) in the distributed cache can be used as the fourth designated transaction record, and the transaction time of the transaction record is used as the starting query time of the page jump query request. Further, the 100 transaction records less than or equal to the query time are queried from each second fund sales platform at the starting query time to obtain the transaction records that can be displayed on page 5.

[0075] Furthermore, after obtaining the first five pages of target transaction records totaling 500 and storing them in a temporary memory database, these 500 transaction records can also be instantly synchronized and backed up, and the expiration time can be refreshed so that when jumping to page 5 is needed again in the future, this part of the data can be immediately called from the distributed cache to access it.

[0076] In the above implementation, when some transaction records already exist in the distributed cache, the existing transaction data is directly obtained from the cache, so as to determine the query time to query the missing data, thereby saving the amount of data to be queried from the second fund sales platform and speeding up the query response speed. At the same time, the query pressure on the back-end database is reduced, thereby improving the efficiency and performance of the entire system.

[0077] In some embodiments, when the query category is a page jump query, the transaction record to be displayed is the transaction record of the current page, and the transaction record of the current page is recorded as the transaction record of page N. The query result includes the sum of the number of transactions returned by all second fund sales platforms to the first fund sales platform. The method also includes:

[0078] When jumping from page N of transaction records to page P of transaction records, check whether page P of transaction records exists in the distributed cache based on the total number of transactions. If so, update the expiration time of page P of transaction records, and return page P of transaction records to the front end for display.

[0079] Similarly, take P as 4, that is, you have just jumped from page 4 to page 6, and now you want to jump back to page 4. At this time, since enough transaction records to display page 4 (page P) have been queried in the previous query process, and these data are not expired, you can get these 400 transaction records from the direct distributed cache and return the transaction records of page P to the front end for display.

[0080] It should be noted that in this case, since the data stored in the distributed cache is applied again, its sliding expiration time in the cache can be updated before the call returns, that is, the expiration time of these data is refreshed at the current call time.

[0081] In the above implementation, by directly obtaining the transaction records of page P from the distributed cache, the system can quickly respond to the user's page jump request without re-querying data from the backend database, which greatly improves the response speed. At the same time, since these data are reused, the system will update their sliding expiration time to ensure the real-time nature of the data.

[0082] The present specification also provides a real-time transaction record query device 200, which is applied to a first fund sales platform, and the first fund sales platform is communicatively connected to a plurality of second fund sales platforms. Figure 2 As shown, the device includes: a transaction record query module 210, a temporary storage module 220, a transaction record storage module 230 and a transaction record return module 240, wherein:

[0083] The transaction record query module 210 is used to query from each second fund sales platform based on the query request through the aggregation layer of the first fund sales platform when the first fund sales platform receives the query request, and obtain the query result corresponding to the query category of the query request; wherein the query result includes the target transaction record, and the target transaction record includes the first specified number of transaction records generated by each second fund sales platform before the current system time, and the current system time is the time when the first fund sales platform receives the query request.

[0084] The temporary storage module 220 is used to store the queried target transaction record in a temporary memory database.

[0085] The transaction record storage module 230 is used to sort the target transaction records according to the specified screening conditions, obtain sorted transaction records, store the sorted transaction records in the transaction record database, and destroy the temporary memory database.

[0086] The transaction record returning module 240 is used to obtain a second specified number of transaction records to be displayed from the sorted transaction records, and return the transaction records to be displayed to the front end for display.

[0087] In some embodiments, when the query category is a continuous paging query, the transaction record to be displayed is the current page transaction record, and the current page transaction record is recorded as the Nth page transaction record. A real-time transaction record query device 200 also includes a continuous paging query module, which is used to query from each second fund sales platform based on the continuous page query request through the aggregation layer when the first fund sales platform receives a continuous page query request, and obtain the continuous page transaction record to display the N+1th page transaction record in the continuous page transaction record; wherein the current page transaction record has a first specified transaction record, and the N+1th page transaction record includes a first specified number of transaction records generated before the transaction generation time of the first specified transaction record.

[0088] In some embodiments, the continuous page transaction records include a third specified number of transaction records, the third specified number is twice the first specified number, and the continuous page transaction records also include the N+2th page transaction records. The continuous paging query module is further used to determine that the N+1th page transaction records have the second specified transaction records, and the N+2th page transaction records include the first specified number of transaction records generated before the transaction generation time of the second specified transaction record.

[0089] In some embodiments, when the query category is a jump page query, after storing the queried target transaction record in a temporary memory database, a real-time transaction record query device 200 also includes a jump page query module for synchronously backing up the target transaction record to the distributed cache of the first fund sales platform, and setting an expiration time for the target transaction record.

[0090] In some embodiments, when the query category is a page jump query, the transaction record to be displayed is the current page transaction record, and the current page transaction record is recorded as the Nth page transaction record; the query result includes the sum of the number of transactions returned by all second fund sales platforms to the first fund sales platform. The page jump query module is also used to detect whether there is a Pth page transaction record in the distributed cache according to the sum of the number of transactions when jumping from the Nth page transaction record to the Pth page transaction record. If not, query each second fund sales platform through the aggregation layer to obtain the fourth specified number of transaction records and the total number of transactions of each second fund sales platform to display the Pth page transaction record; wherein the fourth specified number is P times the first specified number, the P-1th page transaction record has the third specified transaction record, and the Pth page transaction record includes the first specified number of transaction records generated before the transaction generation time of the third specified transaction record.

[0091] In some embodiments, the page jump query module is also used to synchronously back up the fourth specified number of transaction records to the distributed cache of the first fund sales platform, and set an expiration time for the fourth specified number of transaction records.

[0092] In some embodiments, when the query category is a page jump query, the transaction record to be displayed is the current page transaction record, the current page transaction record is recorded as the Nth page transaction record, and the query result includes the sum of the number of transactions returned by all second fund sales platforms to the first fund sales platform. The page jump query module is also used for, when jumping from the Nth page transaction record to the Pth page transaction record, if it is detected according to the sum of the number of transactions that there are M pages of transaction records in the distributed cache, and the M pages of transaction records do not include the Pth page transaction record, querying from each second fund sales platform through the aggregation layer, obtaining the fifth specified number of transaction records and the total number of transactions of each second fund sales platform, and synchronously backing up the fifth specified number of transaction records to the distributed cache of the first fund sales platform; wherein, an expiration time is set for the fifth specified number of transaction records; the fifth specified number is PM times the first specified number, the Mth page transaction record has a fourth specified transaction record, and the fifth specified number of transaction records includes PM times the first specified number of transaction records generated before the transaction generation time of the fourth specified transaction record.

[0093] In some embodiments, when the query category is a page jump query, the transaction record to be displayed is the current page transaction record, and the current page transaction record is recorded as the Nth page transaction record; the query result includes the sum of the number of transactions returned by all second fund sales platforms to the first fund sales platform. The page jump query module is also used to detect whether there is a Pth page transaction record in the distributed cache based on the sum of the number of transactions when jumping from the Nth page transaction record to the Pth page transaction record. If so, update the expiration time of the Pth page transaction record, and return the Pth page transaction record to the front end for display.

[0094] For the specific definition of a real-time transaction record query device, please refer to the definition of a real-time transaction record query method above, which will not be repeated here. Each module in the above-mentioned real-time transaction record query device can be implemented in whole or in part by software, hardware and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0095] A real-time transaction record query device in this embodiment is presented in the form of a functional unit, where the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that executes one or more software or fixed programs, and / or other devices that can provide the above functions.

[0096] The embodiment of the present application also provides a computer device, which may be a terminal, and its internal structure diagram may be as follows: Figure 3 As shown. The computer device includes a processor, a memory, a communication interface, a display screen and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be achieved through WIFI, a mobile cellular network, NFC (near field communication) or other technologies. When the computer program is executed by the processor, a real-time transaction record query method is implemented. The display screen of the computer device can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covered on the display screen, or a key, trackball or touchpad set on the computer device housing, or an external keyboard, touchpad or mouse, etc.

[0097] Those skilled in the art will understand that Figure 3 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0098] The embodiment of the present application also provides a computer-readable storage medium. The above method according to the embodiment of the present application can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0099] The embodiment of the present application provides a computer program product, which includes computer instructions, which are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method of any embodiment of the present application.

[0100] The real-time transaction record query method, apparatus, and computer device described in the above embodiments can be implemented by a computer chip or entity, or by a product with a certain function. A typical implementation device is a computer. Specifically, the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0101] For the convenience of description, the above device is described in various units according to their functions. Of course, when implementing the present application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0102] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0103] The present application is described with reference to the flowchart and / or block diagram of the method, device (system) and computer program product according to the embodiment of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, and the combination of the process and / or box in the flowchart and / or block diagram can be realized by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for realizing the function specified in one process or multiple processes in the flowchart and / or one box or multiple boxes in the block diagram.

[0104] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0105] These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0106] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0107] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In the description of this application, the meaning of "plurality" is at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0108] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0109] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. Since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0110] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

[0111] Although the embodiments of the present application are described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present application, and such modifications and variations are all within the scope defined by the appended claims.

[0112] It is understandable that before using the technical solutions disclosed in the embodiments of the present disclosure, the types, scope of use, usage scenarios, etc. of the personal information involved in the present disclosure should be informed to the user and the user's authorization should be obtained in an appropriate manner in accordance with relevant laws and regulations.

[0113] For example, in response to receiving an active request from a user, a prompt message is sent to the user to clearly prompt the user that the operation requested to be performed will require obtaining and using the user's personal information. Thus, the user can autonomously choose whether to provide personal information to software or hardware such as an electronic device, application, server, or storage medium that performs the operation of the technical solution of the present disclosure according to the prompt message.

[0114] As an optional but non-limiting implementation, in response to receiving an active request from the user, the prompt information may be sent to the user in the form of a pop-up window, in which the prompt information may be presented in text form. In addition, the pop-up window may also carry a selection control for the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0115] It is understandable that the above notification and the process of obtaining user authorization are merely illustrative and do not constitute a limitation on the implementation of the present disclosure. Other methods that meet the relevant laws and regulations may also be applied to the implementation of the present disclosure.

[0116] It is understandable that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and relevant provisions.

[0117] It is understandable that in the specific implementation of the present application, related data such as user information, location information, navigation data, etc. are involved. When the above embodiments of the present application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of relevant countries and regions.

Claims

1. A real-time transaction record query method, characterized in that: Applied to a first fund sales platform, the first fund sales platform is communicatively connected to a plurality of second fund sales platforms; the method comprises: In the case where the first fund sales platform receives the query request, querying each second fund sales platform based on the query request through the aggregation layer of the first fund sales platform to obtain a query result corresponding to the query category of the query request; wherein the query result includes target transaction records, and the target transaction records include a first specified number of transaction records generated by each second fund sales platform before the current system time, and the current system time is the time when the first fund sales platform receives the query request; The queried target transaction record is stored in a temporary memory database; Sorting the target transaction records according to the specified screening conditions to obtain sorted transaction records, storing the sorted transaction records in a transaction record database, and destroying the temporary memory database; A second specified number of transaction records to be displayed are obtained from the sorted transaction records, and the transaction records to be displayed are returned to the front end for display.

2. The method according to claim 1, characterized in that In the case where the query category is a continuous paging query, the transaction record to be displayed is the transaction record of the current page, and the transaction record of the current page is recorded as the transaction record of the Nth page; the method further includes: When the first fund sales platform receives a continuous page query request, the aggregation layer queries each of the second fund sales platforms based on the continuous page query request to obtain continuous page transaction records to display the N+1th page transaction records in the continuous page transaction records; wherein the current page transaction records have a first specified transaction record, and the N+1th page transaction records include the first specified number of transaction records generated before the transaction generation time of the first specified transaction record.

3. The method according to claim 2, characterized in that The continuous pages of transaction records include transaction records of a third specified number of transactions, the third specified number of transactions is twice the first specified number of transactions, and the continuous pages of transaction records also include transaction records on page N+2; The N+1th page of transaction records has a second specified transaction record, and the N+2th page of transaction records includes the first specified number of transaction records generated before the transaction generation time of the second specified transaction record.

4. The method according to claim 1, characterized in that: In the case where the query category is a page jump query, after storing the queried target transaction record in a temporary memory database, the method further includes: The target transaction record is synchronously backed up to the distributed cache of the first fund sales platform, and an expiration time is set for the target transaction record.

5. The method according to claim 4, characterized in that In the case where the query category is a page jump query, the transaction record to be displayed is the transaction record of the current page, and the transaction record of the current page is recorded as the transaction record of the Nth page; the query result includes the sum of the number of transactions returned by all second fund sales platforms to the first fund sales platform; the method also includes: In the case of jumping from the Nth page of transaction records to the Pth page of transaction records, it is detected whether the Pth page of transaction records exists in the distributed cache according to the total number of transactions. If not, the aggregation layer is used to query each second fund sales platform to obtain the fourth specified number of transaction records and the total number of transactions of each second fund sales platform to display the Pth page of transaction records; wherein the fourth specified number is P times the first specified number, the P-1th page of transaction records has the third specified transaction records, and the Pth page of transaction records includes the first specified number of transaction records generated before the transaction generation time of the third specified transaction record.

6. The method according to claim 5, characterized in that The method further comprises: The transaction records of the fourth specified number are synchronously backed up in the distributed cache of the first fund sales platform, and an expiration time is set for the transaction records of the fourth specified number.

7. The method according to claim 4, characterized in that In the case where the query category is a page jump query, the transaction record to be displayed is the transaction record of the current page, the transaction record of the current page is recorded as the transaction record of the Nth page, and the query result includes the sum of the number of transactions returned by all second fund sales platforms to the first fund sales platform; The method further comprises: In the case of jumping from the Nth page of transaction records to the Pth page of transaction records, if it is detected that there are M pages of transaction records in the distributed cache based on the sum of the number of transactions, and the M pages of transaction records do not include the Pth page of transaction records, the fifth specified number of transaction records and the total number of transactions of each second fund sales platform are queried from each second fund sales platform through the aggregation layer, and the fifth specified number of transaction records are synchronously backed up to the distributed cache of the first fund sales platform; wherein, an expiration time is set for the fifth specified number of transaction records; the fifth specified number is PM times the first specified number, the Mth page of transaction records has a fourth specified transaction record, and the fifth specified number of transaction records includes PM times the first specified number of transaction records generated before the transaction generation time of the fourth specified transaction record.

8. The method according to claim 4, characterized in that In the case where the query category is a page jump query, the transaction record to be displayed is the transaction record of the current page, and the transaction record of the current page is recorded as the transaction record of the Nth page; the query result includes the sum of the number of transactions returned by all second fund sales platforms to the first fund sales platform; the method also includes: In the case of jumping from the Nth page of transaction records to the Pth page of transaction records, it is detected whether the Pth page of transaction records exists in the distributed cache based on the total number of transactions. If so, the expiration time of the Pth page of transaction records is updated, and the Pth page of transaction records is returned to the front end for display.

9. A real-time transaction record query device, characterized in that: Applied to a first fund sales platform, the first fund sales platform is communicatively connected to a plurality of second fund sales platforms; the device comprises: a transaction record query module, configured to, when the first fund sales platform receives a query request, query each second fund sales platform based on the query request through the aggregation layer of the first fund sales platform to obtain a query result corresponding to the query category of the query request; wherein the query result includes a target transaction record, and the target transaction record includes a first specified number of transaction records generated by each second fund sales platform before a current system time, and the current system time is the time when the first fund sales platform receives the query request; A temporary storage module, used for storing the queried target transaction record in a temporary memory database; A transaction record storage module, used to sort the target transaction records according to the specified screening conditions, obtain sorted transaction records, store the sorted transaction records in a transaction record database, and destroy the temporary memory database; The transaction record returning module is used to obtain a second specified number of transaction records to be displayed from the sorted transaction records, and return the transaction records to be displayed to the front end for display.

10. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the method according to any one of claims 1 to 8 by executing the computer instructions.

Images