Front-end and back-end asynchronous request data interaction method and system based on Redis

Abstract

The present invention discloses a front-end and back-end asynchronous request data interaction method and system based on Redis, which belongs to the field of web technology. The technical problems to be solved are low efficiency in the development process, redundancy in application code, and inconsistent data displayed by different functions of the same page. It includes the following steps: extracting the data persistence layer of different business interfaces into a unified processing module as a data persistence layer processing module; for each business interface called by an asynchronous request, creating a hash domain in Redis with the SQL operation statement required by the business interface as the key and the SQL statement required by the business interface as the value, and constructing a hash storage with the hash domain as the value and the interface name of the business interface as the key; after the web front end sends an asynchronous request including form data to the web back end, the form data and the address of the business interface are encapsulated in the format of a key-value pair.

Description

Technical Field

[0001] The present invention relates to the field of web technology, and in particular to a front-end and back-end asynchronous request data interaction method and system based on Redis. Background Art

[0002] In the Web field, the traditional asynchronous data interaction process between the front-end and the back-end is roughly as follows: the front-end submits form data to the back-end program through an Ajax (Axios, Fetch) request. After receiving the request, the back-end program matches the corresponding interface according to the request URL, extracts the form data from the interface, verifies the form data, generates SQL statements based on the form data, executes the corresponding SQL statements to obtain the result set, and finally processes the result set and returns the processing results to the front-end. In this process, if the front-end handles multiple businesses that interact with the back-end, it needs to write multiple asynchronous requests to call the corresponding business processing interface of the back-end to process the corresponding business requests. Executing the business processing interface requires statements that interact with the database, and finally returns the processed data to the front-end.

[0003] The backend is generally divided into the presentation layer, business logic layer, and data persistence layer. The presentation layer and business logic layer have different processes and logics in different business interfaces, but the data persistence layer is very similar in different business interfaces: assembling SQL according to parameter groups, executing SQL, and generating result sets. If each request requires writing a large amount of repetitive program code in the data persistence layer, it will undoubtedly increase the workload of development and the time and manpower cost of code maintenance. When different parts of the code are written by different developers, the difficulty of later maintenance is increased because of each person's different writing habits and styles.

[0004] In the business system, as business needs increase, business data increases day by day, and the number of related database tables becomes larger and larger. Therefore, it is necessary to maintain and manage these business data through interaction between the front-end and the back-end. In this process, the front-end page's operation on the business data directly corresponds to the back-end program's operation on the database.

[0005] Low efficiency in the development process, redundancy in the application code, and inconsistent data displayed by different functions on the same page are technical problems that need to be solved. Summary of the invention

[0006] The technical task of the present invention is to address the above shortcomings and provide a front-end and back-end asynchronous request data interaction method and system based on Redis to solve the technical problems of low efficiency in the development process, redundancy in application code, and inconsistent data displayed by different functions of the same page.

[0007] The front-end and back-end asynchronous request data interaction method based on Redis of the present invention is applied to multiple servers configured with Redis and redis-sentinal, wherein one server is used as a master node and the other servers are used as slave nodes. The method comprises the following steps:

[0008] Extract the data persistence layer of different business interfaces into a unified processing module as the data persistence layer processing module, and all asynchronous requests that need to interact with the database call the data persistence layer processing module;

[0009] For each business interface called by an asynchronous request, a hash domain is created in Redis using the SQL operation statement required by the business interface as the key and the SQL statement required by the business interface as the value, and a hash storage is constructed using the hash domain as the value and the interface name of the business interface as the key. The SQL operation statements include select, from, where, delete, and update.

[0010] After the web front end sends an asynchronous request including form data to the web back end, the web back end verifies and processes the asynchronous request, extracts the form data and the address of the business interface based on the asynchronous request, and encapsulates the form data and the address of the business interface in the format of a key-value pair;

[0011] The data persistence layer processing module is called. The data persistence layer processing module uses the address of the business interface as the Key value, reads the corresponding SQL statement from Redis, and splices it according to the incoming form data to obtain the target SQL statement, executes the target SQL statement and returns the response result to the business interface, and returns the response result to the web front end through the business interface.

[0012] Preferably, the web page initiates an asynchronous request by clicking a button on the web page on the web front end;

[0013] Alternatively, on the web front end, the front-end framework scans the web page to see if there is data that needs to be automatically loaded when the web page is loaded. If so, an asynchronous request is constructed through the front-end framework and sent to the web back end.

[0014] Preferably, after the data persistence layer processing module is called, the following operations are performed:

[0015] Determine whether the parameter in the asynchronous request is empty. If so, delete the parameter. If not, extract the address of the business interface in the parameter, and use the address of the business interface as the key value to extract the Hash storage in the corresponding key-value pair format from Redis, and determine whether the corresponding SQL statement is empty. If it is empty, return a prompt message;

[0016] According to the parameters in the received asynchronous request, the SQL operation type corresponding to the business request is divided, and the pre-stored SQL operation statement is retrieved. The SQL statement is checked according to the query check conditions to see if it passes. If the check fails, the reason is returned. If the check passes, the form parameters and the retrieved SQL operation statement are spliced ​​into a complete target SQL statement. If the SQL operation statement is not found, a prompt message is returned.

[0017] If the SQL operation type is a query request, call the database query executor to execute the target SQL statement. If the SQL operation type is another type of request, call the database update executor to execute the target SQL statement.

[0018] When the query request calls the database query executor to execute the target SQL statement, it is determined whether the business request has paging query parameters. If so, the paging query statement is spliced ​​for the query request to make the result set meet the requirements of the web front end.

[0019] Preferably, before the method is executed, application deployment is performed through the following steps:

[0020] Select multiple servers, deploy redis and redis-sentinal in each server, and get multiple Redis servers;

[0021] Select a Redis server as the master node and other Redis servers as slave nodes. The master node has one more slaveof configuration and password than the slave node.

[0022] Configure redis-sentinal based on the sentinel.conf file in the Redis installation directory;

[0023] During operation, when a sentinal finds that a monitored redis node has no response within a specified time, it means that the node has failed. At this time, the node is called subjective offline. When sentinal believes that the number of offline nodes reaches the quonum number, the node becomes objective offline. If the node is also the master, the failover operation is triggered, and the slave node agreed by more than half of sentinals is elected as the master node.

[0024] After all redis nodes and sentinal nodes are started, introduce spring-data, redis, and redis connection pool dependencies into the project, and complete the redis configuration in the configuration file.

[0025] In the second aspect, the front-end and back-end asynchronous request data interaction system based on Redis of the present invention is applied to multiple servers configured with Redis and redis-sentinal, one of which is used as a master node and the other servers are used as slave nodes. The system includes:

[0026] Data persistence layer processing module, which is a unified processing module extracted from the data persistence layers of different business interfaces. All asynchronous requests that need to interact with the database call the data persistence layer processing module;

[0027] A hash construction module, for each business interface called by an asynchronous request, the hash construction module is used to create a hash domain in Redis using the SQL operation statement required by the business interface as the key and the SQL statement required by the business interface as the value, and to construct a hash storage using the hash domain as the value and the interface name of the business interface as the key, wherein the SQL operation statements include select, from, where, delete and update;

[0028] Asynchronous request processing module, after the web front end sends an asynchronous request including form data to the web back end, the web back end calls the asynchronous request processing module to inspect and process the asynchronous request, extracts the form data and the address of the business interface based on the asynchronous request, and encapsulates the form data and the address of the business interface in the format of a key-value pair, and calls the data persistence layer processing module;

[0029] The data persistence layer processing module is used to use the address of the business interface as the Key value, read the corresponding SQL statement from Redis, and splice it according to the incoming form data to obtain the target SQL statement, execute the target SQL statement and return the response result to the business interface, and return the response result to the web front end through the business interface.

[0030] Preferably, a button is configured on the web page of the web front end, and the web page is triggered to initiate an asynchronous request by clicking the button on the web page;

[0031] The front-end framework of the web front-end is used to scan whether there is data that needs to be automatically loaded in the web page when the web page is loaded. If so, the front-end framework is used to construct an asynchronous request and send it to the web back-end.

[0032] Preferably, after the data persistence layer processing module is called, the following operations are performed:

[0033] Determine whether the parameter in the asynchronous request is empty. If so, delete the parameter. If not, extract the address of the business interface in the parameter, and use the address of the business interface as the key value to extract the Hash storage in the corresponding key-value pair format from Redis, and determine whether the corresponding SQL statement is empty. If it is empty, return a prompt message;

[0034] According to the parameters in the received asynchronous request, the SQL operation type corresponding to the business request is divided, and the pre-stored SQL operation statement is retrieved. The SQL statement is checked according to the query check conditions to see if it passes. If the check fails, the reason is returned. If the check passes, the form parameters and the retrieved SQL operation statement are spliced ​​into a complete target SQL statement. If the SQL operation statement is not found, a prompt message is returned.

[0035] If the SQL operation type is a query request, call the database query executor to execute the target SQL statement. If the SQL operation type is another type of request, call the database update executor to execute the target SQL statement.

[0036] When the query request calls the database query executor to execute the target SQL statement, it is determined whether the business request has paging query parameters. If so, the paging query statement is spliced ​​for the query request to make the result set meet the requirements of the web front end.

[0037] Preferably, the application further comprises an application deployment module, wherein the application deployment module is configured to perform the following operations:

[0038] Select multiple servers, deploy redis and redis-sentinal in each server, and get multiple Redis servers;

[0039] Select a Redis server as the master node and other Redis servers as slave nodes. The master node has one more slaveof configuration and password than the slave node.

[0040] Configure redis-sentinal based on the sentinel.conf file in the Redis installation directory;

[0041] During operation, when a sentinal finds that a monitored redis node has no response within a specified time, it means that the node has failed. At this time, the node is called subjective offline. When sentinal believes that the number of offline nodes reaches the quonum number, the node becomes objective offline. If the node is also the master, the failover operation is triggered, and the slave node agreed by more than half of sentinals is elected as the master node.

[0042] After all redis nodes and sentinal nodes are started, introduce spring-data, redis, and redis connection pool dependencies into the project, and complete the redis configuration in the configuration file.

[0043] The front-end and back-end asynchronous request data interaction method and system based on Redis of the present invention have the following advantages:

[0044] 1. Manage the target SQL statements through Redis, and use a unified data persistence layer processing module to process data persistence layer services to implement data interaction between the front-end and back-end in asynchronous requests, which greatly reduces the workload of developers, improves development efficiency, and ensures data consistency of different functions on the same page, facilitating subsequent project iterations and later code maintenance;

[0045] 2. Redis has more complex data structures and provides atomic operations on them. It is an evolutionary path different from other databases. Redis data types are based on basic data structures and are transparent to programmers without the need for additional abstraction.

[0046] 3. Redis runs in memory but can persist to disk, so when reading and writing different data sets at high speed, you need to weigh the memory, because the amount of data cannot be larger than the hardware memory. Another advantage of in-memory databases is that compared to the same complex data structure on disk, it is very simple to operate in memory, so Redis can do a lot of things with high internal complexity. At the same time, in terms of disk format, they are compact and generated in an append-only manner, because they do not need random access, and Redis has extremely high performance, with a read speed of 110,000 times / s and a write speed of 81,000 times / s. Therefore, the SQL required for access using Redis is very fast and safe. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0048] The present invention is further described below in conjunction with the accompanying drawings.

[0049] Figure 1 This is a flowchart of the front-end and back-end asynchronous request data interaction method based on Redis in Example 1;

[0050] Figure 2This is the storage format of hash storage in the front-end and back-end asynchronous request data interaction method based on Redis in Example 1. DETAILED DESCRIPTION

[0051] The present invention is further described below in conjunction with the accompanying drawings and specific embodiments so that those skilled in the art can better understand the present invention and implement it. However, the embodiments are not intended to limit the present invention. In the absence of conflict, the embodiments of the present invention and the technical features in the embodiments may be combined with each other.

[0052] The embodiment of the present invention provides a front-end and back-end asynchronous request data interaction method and system based on Redis, which is used to solve the technical problems of low efficiency in the development process, redundancy in application code, and inconsistent data displayed by different functions of the same page.

[0053] Embodiment 1:

[0054] The present invention is based on a front-end and back-end asynchronous request data interaction method based on Redis, and is applied to multiple servers configured with Redis and redis-sentinal, wherein one server serves as a master node and the other servers serve as slave nodes.

[0055] The method comprises the following steps:

[0056] S100, extracting the data persistence layers of different business interfaces into a unified processing module as a data persistence layer processing module, and all asynchronous requests that need to interact with the database call the data persistence layer processing module;

[0057] S200. For each business interface called by an asynchronous request, a hash domain is created in Redis using the SQL operation statement required by the business interface as the key and the SQL statement required by the business interface as the value, and a hash storage is constructed using the hash domain as the value and the interface name of the business interface as the key. The SQL operation statements include select, from, where, delete, and update.

[0058] S300, after the web front end sends an asynchronous request including form data to the web back end, the web back end verifies and processes the asynchronous request, extracts the form data and the address of the business interface based on the asynchronous request, and encapsulates the form data and the address of the business interface in a key-value pair format;

[0059] S400, calling the data persistence layer processing module. The data persistence layer processing module uses the address of the business interface as the key value, reads the corresponding SQL statement from Redis, and splices it according to the incoming form data to obtain the target SQL statement, executes the target SQL statement and returns the response result to the business interface, and returns the response result to the web front end through the business interface.

[0060] The method of this embodiment is applied to multiple servers, and application configuration needs to be performed before executing step S100. The application deployment includes the following three steps.

[0061] Step 1: Deploy redis and redis-sentinal on three servers respectively. The redis deployment mainly requires modifying the following information:

[0062] #port

[0063] port 6379

[0064] bind 0.0.0.0

[0065] #Configure access password

[0066] Requirepass "myredis"

[0067] #Configure to start in the background

[0068] daemonize yes

[0069] #Log File

[0070] logfile "6379.log"

[0071] #Backup files

[0072] dbfielename "dump-6379.rdb"

[0073] #Data storage address

[0074] dir” / opt / soft / redis / data”

[0075] #Specify the master server. Note: For configuration knowledge about slaveeo, configure the slave server. The master server does not need to be configured.

[0076] salaveof 192.168.11.128.6379

[0077] #Master server password, note: For configuration knowledge about slaveeo, configure the slave server, the master server does not need to be configured

[0078] masterauth 123456

[0079] Step 2: The above content is mainly to configure the Redis server. The slave server has one more slaveof configuration and password than the master server. The slave node has two main functions:

[0080] Function 1: As a backup of the master node, once the master node fails, the slave node can be used as a backup to "take over" and ensure that data is not lost as much as possible (master-slave replication is ultimately consistent);

[0081] Function 2: The slave node can expand the capabilities of the master node. Once the master node cannot support large concurrent read operations, the slave node can help the master node share the read pressure to a certain extent;

[0082] Then start configuring three sentinels. The configuration of each sentinel is the same. There is a sentinel.conf file in the Redis installation directory. Copy a copy and modify it.

[0083] #port

[0084] port26379

[0085] #Configure to start in the background

[0086] daemonize yes

[0087] #Log File

[0088] logfile "26379.log"

[0089] #Data storage directory

[0090] dir” / opt / soft / redis / data”

[0091] #Monitor redis address and quorum

[0092] sentinel monitor mymaster 192.168.11.202 6380 2

[0093] #redis server password

[0094] sentinel auth-pass mymaster myredis

[0095] #How long does it take to become offline after losing contact?

[0096] sentinel down-after-milliseconds mymaster 30000

[0097] #When a master-slave switch occurs, this option specifies how many slaves can synchronize with the new master at the same time

[0098] sentinel parallel-syncs mymaster 1

[0099] #Configure the maximum failover time

[0100] sentinel failover-timeout mymaster 180000

[0101] Step 3. During the operation, when a sentinal finds that a monitored redis node has no response within the specified time, it will consider that the node has failed. At this time, the node is called subjective offline. When sentinal believes that the number of offline nodes has reached the quonum number, the node becomes objectively offline. If the node is also the master, the failover operation is triggered, and the slave nodes agreed by more than half of sentinals are elected as the master nodes. After all redis nodes and sentinal nodes are started, introduce spring-data, redis, and redis connection pool dependencies into the project. The configuration function is as follows:

[0102]

[0103]

[0104] Then complete the redis configuration in the configuration file:

[0105] After the application is deployed, step S100 is executed to set a unified data persistence layer processing module, and all asynchronous requests that need to interact with the database are uniformly called to process the module.

[0106] Step S200 is understood as creating a hash storage in Redis with the interface name of each business interface called by the asynchronous request as Key, and using the SQL operation statements such as select, from, where, delete and update required by the business interface as small Key, and creating a hash domain with the SQL statement required by the business interface as Value. The storage format is shown in the attached Figure 2 .

[0107] Step S300 After the front-end processor of the web front-end initiates an asynchronous request to the back-end processor of the web back-end, the back-end processor processes the form data through the business interface, including but not limited to permission verification and data verification, and then encapsulates the data and the address of the business interface in a key-value pair format, and calls a unified data persistence layer module. The data persistence layer module uses the interface address as the key to retrieve the corresponding select, from, where, update, delete and other SQL operation statements from Redis, and splices them according to the incoming form data to obtain the target SQL statement, execute the target SQL statement and return the response result to the business interface, and finally the business interface processes the returned result and returns the final data to the front-end page of the web front-end.

[0108] Step S300: There are two main ways for the front-end processor of the web front end to send asynchronous requests to the web back end through its processing module. The first is to manually trigger the asynchronous request of the front end: the user clicks a button on the page to trigger the page to initiate an asynchronous request (Ajax, Axios, Fetch). The second is that the front-end framework scans the page when the page is loaded to see if there is data that needs to be loaded automatically. If so, a front-end asynchronous request is constructed through the front-end framework and a request is initiated to the back end. The processing logic of these two types of asynchronous requests initiated at the back end is the same: the business interface first verifies the data, assembles the data, and then calls a unified data persistence layer module, and finally processes the returned results and returns the processed data to the front end.

[0109] After the data persistence layer processing module is called in step S300, the following operations are performed:

[0110] (1) Determine whether the parameter in the asynchronous request is empty. If so, delete the parameter. If not, extract the address of the business interface in the parameter, and use the address of the business interface as the key value to extract the Hash storage in the corresponding key-value pair format from Redis, and determine whether the corresponding SQL statement is empty. If it is empty, return a prompt message;

[0111] (2) According to the parameters in the received asynchronous request, the SQL operation type corresponding to the business request is divided, and the pre-stored SQL operation statements such as select, from, where or delete, update, etc. are retrieved, and the SQL statement is checked according to the query check condition to see whether it passes. If the check fails, the reason is returned. If the check passes, the form parameters and the retrieved SQL operation statement are spliced ​​into a complete target SQL statement. If the SQL operation statement is not found, a prompt message is returned;

[0112] (3) If the SQL operation type is a query request, call the database query executor to execute the target SQL statement; if the SQL operation type is another type of request, call the database update executor to execute the target SQL statement;

[0113] (4) When the query request calls the database query executor to execute the target SQL statement, it is determined whether the business request has a paging query parameter. If so, the paging query statement is spliced ​​for the query request so that the result set meets the requirements of the web front end.

[0114] The method of this embodiment only requires a unified data persistence layer processing module, instead of each business interface in the traditional mode establishing its own data persistence layer interface, thereby reducing a large number of repeated and redundant processes and greatly improving development efficiency. Developers only need to develop front-end views and perform validation encapsulation of form data and database response results, which greatly simplifies the complexity of the code and makes the code easier to maintain.

[0115] Embodiment 2:

[0116] The present invention is based on the front-end and back-end asynchronous request data interaction system of Redis, which is applied to multiple servers configured with Redis and redis-sentinal, one of which is used as the master node and the other servers are used as slave nodes. The system includes a data persistence layer processing module, a hash construction module, and an asynchronous request processing module. The system can execute the method disclosed in Example 1,

[0117] The data persistence layer processing module is a unified processing module that extracts the data persistence layers of different business interfaces. All asynchronous requests that need to interact with the database call the data persistence layer processing module.

[0118] For each business interface called by an asynchronous request, the hash construction module is used to create a hash domain in Redis with the SQL operation statement required by the business interface as the key and the SQL statement required by the business interface as the value, and to construct a hash storage with the hash domain as the value and the interface name of the business interface as the key. The SQL operation statements include select, from, where, delete and update.

[0119] The above is understood as: the interface name of the business interface called by each asynchronous request is used as Key to create a hash storage in Redis, and the SQL operation statements such as select, from, where, delete and update required by the business interface are used as small keys, and the SQL statements required by the business interface are used as Value to create a hash domain.

[0120] After the web front end sends an asynchronous request including form data to the web back end, the web back end calls the asynchronous request processing module to inspect and process the asynchronous request, extracts the form data and the address of the business interface based on the asynchronous request, encapsulates the form data and the address of the business interface in the format of a key-value pair, and calls the data persistence layer processing module.

[0121] The data persistence layer processing module of this embodiment is used to use the address of the business interface as the Key value, read the corresponding SQL statement from Redis, and splice it according to the incoming form data to obtain the target SQL statement, execute the target SQL statement and return the response result to the business interface, and return the response result to the web front end through the business interface.

[0122] A button is configured on the web page of the web front end, and clicking the button on the web page triggers the web page to initiate an asynchronous request; the front-end framework of the web front end is used to scan whether there is data in the web page that needs to be loaded automatically when the web page is loaded. If so, the front-end framework is used to construct an asynchronous request and send it to the web back end.

[0123] Based on the above, there are two main ways for the front-end processor of the web front end to send asynchronous requests to the web back end through its processing module. The first is to manually trigger the asynchronous request of the front end: the user clicks a button on the page to trigger the page to initiate an asynchronous request (Ajax, Axios, Fetch). The second is that the front-end framework scans the page when the page is loaded to see if there is data that needs to be loaded automatically. If so, a front-end asynchronous request is constructed through the front-end framework and a request is initiated to the back end. The processing logic of these two types of asynchronous requests initiated is the same on the back end: the business interface first verifies the data, assembles the data, then calls the unified data persistence layer module, and finally processes the returned results and returns the processed data to the front end.

[0124] After the data persistence layer processing module is called, the following operations are performed:

[0125] (1) Determine whether the parameter in the asynchronous request is empty. If so, delete the parameter. If not, extract the address of the business interface in the parameter, and use the address of the business interface as the key value to extract the Hash storage in the corresponding key-value pair format from Redis, and determine whether the corresponding SQL statement is empty. If it is empty, return a prompt message;

[0126] (2) According to the parameters in the received asynchronous request, the SQL operation type corresponding to the business request is divided, and the pre-stored SQL operation statements such as select, from, where or delete, update, etc. are retrieved, and the SQL statement is checked according to the query check condition to see whether it passes. If the check fails, the reason is returned. If the check passes, the form parameters and the retrieved SQL operation statement are spliced ​​into a complete target SQL statement. If the SQL operation statement is not found, a prompt message is returned;

[0127] (3) If the SQL operation type is a query request, call the database query executor to execute the target SQL statement; if the SQL operation type is another type of request, call the database update executor to execute the target SQL statement;

[0128] (4) When the query request calls the database query executor to execute the target SQL statement, it is determined whether the business request has a paging query parameter. If so, the paging query statement is spliced ​​for the query request so that the result set meets the requirements of the web front end.

[0129] The present invention is shown and described in detail above through the accompanying drawings and preferred embodiments. However, the present invention is not limited to these disclosed embodiments. Based on the above multiple embodiments, those skilled in the art can know that the code review methods in the above different embodiments can be combined to obtain more embodiments of the present invention, and these embodiments are also within the protection scope of the present invention.

Claims

1. A front-end and back-end asynchronous request data interaction method based on Redis, characterized by Applied to multiple servers configured with Redis and redis-sentinal, one of the servers is used as a master node and the other servers are used as slave nodes, the method comprises the following steps: Extract the data persistence layer of different business interfaces into a unified processing module as the data persistence layer processing module, and all asynchronous requests that need to interact with the database call the data persistence layer processing module; For each business interface called by an asynchronous request, the interface name of each business interface called by the asynchronous request is used as the key to create a hash storage in Redis, and the SQL operation statement required by the business interface is used as the small key, and the SQL statement required by the business interface is used as the value to create a hash domain. The SQL operation statement includes select, from, where, delete and update; After the web front end sends an asynchronous request including form data to the web back end, the web back end verifies and processes the asynchronous request, extracts the form data and the address of the business interface based on the asynchronous request, and encapsulates the form data and the address of the business interface in the format of a key-value pair; The data persistence layer processing module is called. The data persistence layer processing module uses the address of the business interface as the Key value, reads the corresponding SQL statement from Redis, and splices it according to the incoming form data to obtain the target SQL statement, executes the target SQL statement and returns the response result to the business interface, and returns the response result to the web front end through the business interface.

2. The front-end and back-end asynchronous request data interaction method based on Redis according to claim 1 is characterized in that On the web front end, click a button on the web page to trigger an asynchronous request on the web page. Alternatively, on the web front end, the front-end framework scans the web page to see if there is data that needs to be automatically loaded when the web page is loaded. If so, an asynchronous request is constructed through the front-end framework and sent to the web back end.

3. The front-end and back-end asynchronous request data interaction method based on Redis according to claim 1 is characterized in that After the data persistence layer processing module is called, the following operations are performed: Determine whether the parameter in the asynchronous request is empty. If so, delete the parameter. If not, extract the address of the business interface in the parameter, and use the address of the business interface as the key value to extract the Hash storage in the corresponding key-value pair format from Redis, and determine whether the corresponding SQL statement is empty. If it is empty, return a prompt message; According to the parameters in the received asynchronous request, the SQL operation type corresponding to the business request is divided, and the pre-stored SQL operation statement is retrieved. The SQL statement is checked according to the query check conditions to see if it passes. If the check fails, the reason is returned. If the check passes, the form parameters and the retrieved SQL operation statement are spliced ​​into a complete target SQL statement. If the SQL operation statement is not found, a prompt message is returned. If the SQL operation type is a query request, call the database query executor to execute the target SQL statement. If the SQL operation type is another type of request, call the database update executor to execute the target SQL statement. When the query request calls the database query executor to execute the target SQL statement, it is determined whether the business request has paging query parameters. If so, the paging query statement is spliced ​​for the query request to make the result set meet the requirements of the web front end.

4. The front-end and back-end asynchronous request data interaction method based on Redis according to any one of claims 1 to 3, characterized in that Before the method is executed, the application is deployed through the following steps: Select multiple servers, deploy redis and redis-sentinal in each server, and get multiple Redis servers; Select a Redis server as the master node and other Redis servers as slave nodes. The master node has one more slaveof configuration and password than the slave node. Configure redis-sentinal based on the sentinel.conf file in the Redis installation directory; During operation, when a sentinal finds that a monitored redis node has no response within a specified time, it means that the node has failed. At this time, the node is called subjective offline. When sentinal believes that the number of offline nodes reaches the quonum number, the node becomes objective offline. If the node is also the master, the failover operation is triggered, and the slave node agreed by more than half of sentinals is elected as the master node. After all redis nodes and sentinal nodes are started, introduce spring-data, redis, and redis connection pool dependencies into the project, and complete the redis configuration in the configuration file.

5. The front-end and back-end asynchronous request data interaction system based on Redis is characterized by Applied to multiple servers configured with Redis and redis-sentinal, one of the servers is used as a master node and the other servers are used as slave nodes, the system includes: Data persistence layer processing module, which is a unified processing module extracted from the data persistence layers of different business interfaces. All asynchronous requests that need to interact with the database call the data persistence layer processing module; A hash construction module, for each business interface called by an asynchronous request, the hash construction module is used to establish a hash storage in Redis with the interface name of the business interface called by each asynchronous request as the Key, and use the SQL operation statement required by the business interface as the small Key, and create a hash domain with the SQL statement required by the business interface as the Value, wherein the SQL operation statement includes select, from, where, delete and update; Asynchronous request processing module, after the web front end sends an asynchronous request including form data to the web back end, the web back end calls the asynchronous request processing module to inspect and process the asynchronous request, extracts the form data and the address of the business interface based on the asynchronous request, and encapsulates the form data and the address of the business interface in the format of a key-value pair, and calls the data persistence layer processing module; The data persistence layer processing module is used to use the address of the business interface as the Key value, read the corresponding SQL statement from Redis, and splice it according to the incoming form data to obtain the target SQL statement, execute the target SQL statement and return the response result to the business interface, and return the response result to the web front end through the business interface.

6. The front-end and back-end asynchronous request data interaction system based on Redis according to claim 5 is characterized in that A button is configured on the web page of the web front end, and the web page is triggered to initiate an asynchronous request by clicking the button of the web page; The front-end framework of the web front-end is used to scan whether there is data that needs to be automatically loaded in the web page when the web page is loaded. If so, the front-end framework is used to construct an asynchronous request and send it to the web back-end.

7. The front-end and back-end asynchronous request data interaction system based on Redis according to claim 5 is characterized in that After the data persistence layer processing module is called, the following operations are performed: Determine whether the parameter in the asynchronous request is empty. If so, delete the parameter. If not, extract the address of the business interface in the parameter, and use the address of the business interface as the key value to extract the Hash storage in the corresponding key-value pair format from Redis, and determine whether the corresponding SQL statement is empty. If it is empty, return a prompt message; According to the parameters in the received asynchronous request, the SQL operation type corresponding to the business request is divided, and the pre-stored SQL operation statement is retrieved. The SQL statement is checked according to the query check conditions to see if it passes. If the check fails, the reason is returned. If the check passes, the form parameters and the retrieved SQL operation statement are spliced ​​into a complete target SQL statement. If the SQL operation statement is not found, a prompt message is returned. If the SQL operation type is a query request, call the database query executor to execute the target SQL statement. If the SQL operation type is another type of request, call the database update executor to execute the target SQL statement. When the query request calls the database query executor to execute the target SQL statement, it is determined whether the business request has paging query parameters. If so, the paging query statement is spliced ​​for the query request to make the result set meet the requirements of the web front end.

8. The front-end and back-end asynchronous request data interaction system based on Redis according to any one of claims 5 to 7, characterized in that It also includes an application deployment module, which is used to perform the following operations: Select multiple servers, deploy redis and redis-sentinal in each server, and get multiple Redis servers; Select a Redis server as the master node and other Redis servers as slave nodes. The master node has one more slaveof configuration and password than the slave node. Configure redis-sentinal based on the sentinel.conf file in the Redis installation directory; During operation, when a sentinal finds that a monitored redis node has no response within a specified time, it means that the node has failed. At this time, the node is called subjective offline. When sentinal believes that the number of offline nodes reaches the quonum number, the node becomes objective offline. If the node is also the master, the failover operation is triggered, and the slave node agreed by more than half of sentinals is elected as the master node. After all redis nodes and sentinal nodes are started, introduce spring-data, redis, and redis connection pool dependencies into the project, and complete the redis configuration in the configuration file.

Images