A reservation management method and device for smart scenic spots

Abstract

The present application discloses a reservation management method and device for a smart scenic spot, the method comprising: receiving a login instruction from a client, obtaining user information of a user account; determining and distributing a server interface domain name corresponding to each user account according to each user information; receiving a reservation request, determining whether the reservation item corresponding to the reservation request has started; if not started, not returning a reservation submission interface address; if started, generating a hash value corresponding to each user account according to a user feature value, a preset address key and a current timestamp; sending a new reservation submission interface address to the corresponding user account so that the client obtains the reservation information, generates a signature, and sends the reservation information and the reservation submission request to the server; verifying the reservation submission interface address, and after successful verification, verifying whether the signature of the client is correct; if the signature is correct, determining that the signature verification has passed, and completing the reservation of the client corresponding to the reservation submission address according to the reservation information.

Description

Technical Field

[0001] The embodiments of the present application relate to the technical field of scenic spot reservation management, and in particular, to a reservation management method and device for smart scenic spots. Background Art

[0002] At present, people's demand for leisure tourism is becoming more and more vigorous, and the passenger flow of tourist attractions is showing a rapid growth trend. However, the passenger flow of tourist attractions is not evenly distributed, but is affected by many factors and shows obvious volatility. For example, with the arrival of holidays, the number of tourists received by tourist attractions may increase ten times or even more than usual. In order to cope with this passenger flow fluctuation, many scenic spots have adopted a reservation system. At present, the "one guest, one code" system is generally implemented, that is, a user enters the scenic spot with a unique pass. Users make reservations in advance on the official website of the scenic spot or the designated platform, and after the reservation is successful, they can obtain an electronic pass to enter the scenic spot.

[0003] In order to prevent robots from swiping tickets, the existing scenic spot reservation system verifies whether the reservation user is a real person one by one, and adopts the method of verification through image verification code or mobile phone SMS verification code. However, this method often faces huge challenges when dealing with peak passenger flow. During the peak reservation period, users have to complete the additional steps of verification code input or SMS verification, which prolongs the reservation process and increases the complexity of the operation. In addition, for users who make reservations for multiple people for family or team, it is very cumbersome to authenticate the identity of each person one by one, which brings a very poor user experience.

[0004] There is currently no better solution to the above problems. Summary of the invention

[0005] The embodiments of the present application provide a reservation management method and device for a smart scenic spot, which are used to effectively improve the user's reservation experience.

[0006] To achieve the above objectives, the embodiments of the present application adopt the following technical solutions:

[0007] In a first aspect, a reservation management method for a smart scenic spot is provided, which is applied to a server, and a scenic spot reservation platform is deployed on the server. The method includes:

[0008] In response to receiving a login instruction from a client to the scenic spot reservation platform, obtaining user information of a user account of the client to log in to the scenic spot reservation platform;

[0009] According to the user information of each user account, determine and distribute the server interface domain name corresponding to each user account, wherein the server interface domain name is calculated based on the user characteristic value, and the user characteristic value is calculated based on the user information;

[0010] In response to receiving reservation requests for reservation items from m user accounts in the current time period, determining whether the reservation item corresponding to the reservation request has started, where m is an integer greater than 2;

[0011] For each user account, if the reservation item has not started, the reservation submission interface address is not returned;

[0012] When the reservation project starts, a hash value corresponding to each user account is generated using a preset secure hash algorithm according to the user feature value, the preset address key and the current timestamp, and the hash value is used to represent the new reservation submission interface address;

[0013] Sending the new reservation submission interface address to the corresponding user account according to the server interface domain name, so that the client corresponding to the user account responds to the user's reservation information input instruction, obtains the reservation information, and uses the preset key to generate a signature, and sends the reservation information and the reservation submission request to the server;

[0014] Verify the reservation submission interface address corresponding to the reservation submission request, and after the reservation submission interface address is successfully verified, verify whether the signature of the client corresponding to the reservation submission address is correct;

[0015] If the signature of the client corresponding to the reservation submission address is correct, it is determined that the signature verification of the client corresponding to the reservation submission address is passed, and the reservation of the client corresponding to the reservation submission address is completed according to the reservation information.

[0016] In a possible implementation manner of the first aspect, the server is deployed with n sets of services, each set of services corresponds to a server interface domain name, the user information includes a device ID, account data and an IP address, n is a positive integer, and determining and distributing a server interface domain name corresponding to each user account according to the user information of each user account includes:

[0017] For each of the user accounts, obtaining a first weight corresponding to the device ID, a second weight corresponding to the account data, and a third weight corresponding to the IP address;

[0018] Performing weighted summation on the device ID, the account data, and the IP address according to the first weight, the second weight, and the third weight to obtain a user feature value Q;

[0019] The remainder i of the value of dividing the user characteristic value Q by n is calculated, and the server interface domain name corresponding to the user account is determined to be U(i+1) and distributed.

[0020] In another possible implementation of the first aspect, the reservation information includes the user name, the reservation item name, and the traveler name. The client generates a signature using a preset key, which includes:

[0021] The client uses a preset information digest algorithm to splice the user name, the reservation item name, the traveler name, and the preset key K into a string to generate a signature.

[0022] In another possible implementation of the first aspect, the scenic spot reservation platform includes a data cache component and a database. The reservation information further includes an account ID, and the user name corresponds to the account ID one by one. After the client corresponding to the user account responds to the user's reservation information input instruction, obtains the reservation information, generates a signature using a preset key, and sends the reservation information and a reservation submission request to the server, it includes:

[0023] Package m groups of the reservation information to obtain n data packets. Among them, each data packet includes an index structure, and the index structure is used to indicate the position of the user behavior data of each user account in the data packet. m>2, n<m, and both m and n are integers;

[0024] Transmit the n data packets to the data cache component, and based on the index structure of each data packet, determine the caching policy of each data packet in the data cache component;

[0025] Determine the flow nodes of the n data packets according to the caching policy. The flow nodes include the database inflow node and the verification node. Among them, the sum of the number of data packets flowing into the database inflow node and the number of data packets flowing into the verification node is n;

[0026] If the flow node of the data packet is the verification node, decompress the data packet to obtain multiple groups of the reservation information, and obtain the number of reservation items under each account ID in the database according to the account ID in each group of the reservation information;

[0027] In the case where the number of reservation items is less than or equal to a preset quantity threshold, determine that the data packet is a valid data packet, and verify the user account corresponding to the valid data packet;

[0028] In the case where the user account corresponding to the valid data packet passes the verification, generate a reservation success page for the verified user account;

[0029] When the number of the reservation items is greater than the preset threshold, the data packet is determined to be an invalid data packet, and reservation failure feedback information is generated to the user account corresponding to the invalid data packet based on the user name corresponding to the number of the reservation items greater than the preset threshold.

[0030] In another possible implementation of the first aspect, after generating a reservation success page to the user account, the method includes:

[0031] Obtain a target user account corresponding to each account ID in the reservation information of the user account;

[0032] According to the reservation item name of the user account, the user account and all the target user accounts are stored in a reservation database corresponding to the reservation item name, and reservation success feedback information is sent to each target user account;

[0033] Within a preset time period, no further response is given to reservation requests for the currently reserved scenic spot from all the user accounts in the reservation database.

[0034] In another possible implementation of the first aspect, the reservation success page includes reservation success feedback information and a preset link button, and after the reservation success page is generated to the user account, the method further includes:

[0035] In response to a user's click instruction on the link button, a unique evaluation link for the reservation information is generated according to the reservation information of the user account corresponding to the user, and the user is redirected to the unique evaluation link, wherein the unique evaluation link is associated with the link button, and the unique evaluation link includes an account ID, a reservation order number, a reservation item name, and a timestamp;

[0036] Determining whether to respond to a fill-in instruction or a cancel instruction of the user in the unique evaluation link within a preset time period;

[0037] If a user fills in the unique evaluation link within a preset time period, obtaining the user's evaluation information in the unique evaluation link, and storing the evaluation information in association with the user's reservation information;

[0038] If the user's filling instruction or cancel instruction in the unique evaluation link is not responded to within a preset time period, closing the unique evaluation link;

[0039] If a cancellation instruction in the unique evaluation link is responded to within a preset time period, the unique evaluation link is closed.

[0040] In another possible implementation manner of the first aspect, determining, based on the index structure of each data packet, a cache strategy of each data packet in the data cache component includes:

[0041] For any of the data packets, according to the index structure of the data packet, obtaining user behavior data of the user account corresponding to each set of the reservation information in the data packet, the user behavior data including the historical reservation frequency and the historical verification pass number;

[0042] Determine the level of the corresponding user account according to the historical reservation frequency and the number of historical verification passes, the level of the user account including high level, medium level and low level;

[0043] Calculating the ratio of user accounts with a high level in the data packet to all user accounts, and determining that the cache strategy is high-speed cache when the ratio is greater than a preset ratio threshold; and

[0044] When the ratio is less than or equal to the ratio threshold, determining the cache strategy as a low-speed cache;

[0045] Among them, when the historical reservation frequency is greater than a preset first threshold and the number of historical verification passes is greater than a preset second threshold, the level of the corresponding user account is determined to be high; when the historical reservation frequency is less than or equal to the first threshold and the number of historical verification passes is greater than the second threshold, the level of the corresponding user account is determined to be intermediate; when the historical reservation frequency is greater than the first threshold and the number of historical verification passes is less than or equal to the second threshold, the level of the corresponding user account is determined to be intermediate; when the historical reservation frequency is less than or equal to the first threshold and the number of historical verification passes is less than or equal to the second threshold, the level of the corresponding user account is determined to be low.

[0046] In another possible implementation manner of the first aspect, determining the flow destination nodes of the n data packets according to the cache strategy includes:

[0047] If the cache strategy of any one or more of the data packets is high-speed cache, determining the flow node of any one or more of the data packets as the verification node;

[0048] If the cache strategy of any one or more of the data packets is the low-speed cache, it is determined that the flow node of any one or more of the data packets is the database inflow node.

[0049] In another possible implementation manner of the first aspect, if the flow destination node of the data packet is the database inflow node, the method further includes:

[0050] Performing format verification on the data packet, and after the format verification of the data packet passes, parsing the index structure of the data packet to obtain at least one user account;

[0051] Establishing a first connection with the database, searching for a corresponding user record in the database according to at least one of the user accounts, and adding 1 to the total reservation amount in each of the user records;

[0052] If one or more of the user accounts in the data packet are verified, a second connection is established with the database, and in the database, the number of successful reservations and the number of verification passes in the user records corresponding to the verified user accounts are both increased by 1;

[0053] Execute the steps of generating a reservation success page to verify the user account.

[0054] In a second aspect, the present application provides an electronic device, including:

[0055] a memory configured to store instructions; and

[0056] The processor is configured to call the instructions from the memory and implement the above-mentioned reservation management method for smart attractions when executing the instructions.

[0057] Through the above technical solution, since the reservation submission interface address is dynamically generated based on the user feature value, the preset address key and the current timestamp, the interface address of each user is unique and will change over time, making it difficult for the robot to predict or reuse the interface address, and the interface address is bound to the user, indicating that even if the robot obtains a valid address, it cannot be used for reservations for other user accounts. Therefore, by assigning a corresponding server interface domain name and a dynamically generated reservation submission interface address to each user, it is possible to effectively prevent robots from batch swiping tickets, thereby increasing the security of reservations; in addition, the user only needs to log in to the scenic spot reservation platform once, and the server can obtain the user information, and determine and distribute the server interface domain name based on the user information, so that the user can use the server interface domain name for subsequent reservation operations after logging in once, so that the user does not need to log in and verify separately for each family member or team member, and does not need to frequently enter the verification code, which effectively simplifies the user's operation process and effectively improves the user's experience.

[0058] Other features and advantages of the embodiments of the present application will be described in detail in the subsequent specific implementation section. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 A flowchart of a reservation management method for a smart scenic spot provided in an embodiment of the present application;

[0060] Figure 2 A flowchart of a reservation management method for off-peak hours provided in an embodiment of the present application;

[0061] Figure 3 A flowchart of an embodiment of the present application after a reservation success page is generated to a user account. DETAILED DESCRIPTION

[0062] In order to make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme 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. It should be understood that the specific implementation methods described herein are only used to illustrate and explain the embodiments of the present application, and are not used to limit the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0063] Note: If the embodiments of the present application involve directional indications (such as up, down, left, right, front, back...), the directional indications are only used to explain the relative position relationship, movement status, etc. between the components under a specific posture (as shown in the accompanying drawings). If the specific posture changes, the directional indication will also change accordingly.

[0064] In addition, if there are descriptions involving "first", "second", etc. in the embodiments of the present application, the descriptions of "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or suggesting their relative importance or implicitly indicating the number of technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In addition, the technical solutions between the various embodiments can be combined with each other, but they must be based on the ability of ordinary technicians in the field to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such combination of technical solutions does not exist and is not within the scope of protection required by this application.

[0065] Figure 1 The following schematically shows a flow chart of a reservation management method for a smart scenic spot according to an embodiment of the present application. Figure 1 As shown, an embodiment of the present application provides a reservation management method for a smart scenic spot, which is applied to a server, and a scenic spot reservation platform is deployed on the server. The method may include the following steps.

[0066] S110, in response to receiving a login instruction from a client to the scenic spot reservation platform, obtaining user information of a user account of the client to log in to the scenic spot reservation platform;

[0067] S120. Determine and distribute a server interface domain name corresponding to each user account according to user information of each user account, where the server interface domain name is calculated based on a user feature value, and the user feature value is calculated based on the user information;

[0068] S130, in response to receiving reservation requests for reservation items from m user accounts in the current time period, determining whether the reservation item corresponding to the reservation request has started, where m is an integer greater than 2;

[0069] S140. For each user account, if the reservation project has not started, the reservation submission interface address is not returned;

[0070] S150: When a reservation project starts, a hash value corresponding to each user account is generated using a preset secure hash algorithm according to the user feature value, the preset address key and the current timestamp. The hash value is used to represent the new reservation submission interface address.

[0071] S160. Send the new reservation submission interface address to the corresponding user account according to the server interface domain name, so that the client corresponding to the user account responds to the user's reservation information input instruction, obtains the reservation information, generates a signature using a preset key, and sends the reservation information and the reservation submission request to the server;

[0072] S170, verifying the reservation submission interface address corresponding to the reservation submission request, and after the reservation submission interface address is successfully verified, verifying whether the signature of the client corresponding to the reservation submission address is correct;

[0073] S180: If the signature of the client corresponding to the reservation submission address is correct, it is determined that the signature verification of the client corresponding to the reservation submission address is passed, and the reservation of the client corresponding to the reservation submission address is completed according to the reservation information.

[0074] When the client sends a login instruction to the server, the server responds to the login instruction and obtains the user information of the user account. The user information may include device ID, account data, IP address, etc.

[0075] Afterwards, the server interface domain name is determined and distributed based on the user information.

[0076] In one implementation, first, a user feature value is calculated based on user information. A unique user feature value can be generated by combining the user's unique identifier (such as user ID, hash value of the mobile phone number) with other information (such as registration time, user level) and through a specific algorithm. Then, the server interface domain name is calculated using the user feature value. The calculation process can include combining the feature value with a predefined domain name prefix or suffix, or using a part of the feature value as a sub-domain name. For example, if the first 8 digits of the feature value are "a1b2c3d4", a domain name in the form of "a1b2c3d4.***.***.com" can be generated. After determining the domain name, the unique server interface domain name is distributed to the corresponding user accounts.

[0077] In another implementation, first, n sets of services are deployed on the server, corresponding to interface domain names U1, U2, …, U(n) respectively. When the client requests the interface domain name Ui, it correspondingly accesses the i-th set of services. For example, in an event, the reservation system server deploys 5 sets of services, and the corresponding interface domain names are Domain Name 1, Domain Name 2, Domain Name 3, Domain Name 4, and Domain Name 5. Accessing each interface domain name will only request the corresponding server. For example, accessing Domain Name 3 will only request the 3rd set of services.

[0078] After the user logs in to the system, the client obtains the user's device information K1, account information K2, IP address (Internet Protocol Address) K3, etc., and records them as user M(id, K1, K2, K3, … Km). According to the weights V1, V2, …, Vm set by the system, the weighted sum is calculated to obtain the user's feature value Q, that is:

[0079] Q = K1×V1 + K2×V2 + K3×V3 + … + Km×Vm.

[0080] Then, the user feature value Q is divided by n to obtain the remainder i, and the user uses the interface domain name U(i + 1) to interact with the server. Where 0 ≦ i < n and i is an integer.

[0081] In this embodiment, the recording methods of various types of user information and the weights of various types of user information are set in advance in the system to calculate the user's feature value. For example, for the reservation project, the following three types of user information are set: K1 is the user device information, and the recording method is the enumeration method, and the enumeration values are (101 represents mobile phone model A, 102 represents mobile phone model B, 103 represents mobile phone model C, 104 represents other models of mobile phones); K2 is the user mobile phone number information, and the recording method is to use the last 4 digits of the mobile phone number; K3 is the user IP address, and the recording method is to add the values of the four segments of the IP address. The weights of these three types of user information are set as V1 = 5, V2 = 1, and V3 = 2 respectively.

[0082] Then, after the user logs in, the user's characteristic value can be calculated based on the user's information obtained by the client. For example, user A logs in to the system using the phone number 139****1212 on the A model phone, and the IP address is 219.140.151.248. It can be determined that user A's device information K1=103, the phone number information K2=1212, and the IP address K3=219+140+151+248=758, that is, user A's record is MA (id1, 103, 1212, 758). Then, based on the set user information weights, the weighted sum is used to calculate the characteristic value of user A Q=K1×V1+K2×V2+K3×V3=103×5+1212×1+758×2=515+1212+1516=3243. The user characteristic value Q is divided by n and the remainder is i, that is, 3243 divided by 5 is 648 and the remainder is 3. The interface domain name U(i+1) used by user A is domain name 4.

[0083] When the server receives reservation requests for a specific scenic spot from m user accounts in the current time period, it determines whether the reservation project corresponding to the current reservation request has started. Specifically, it can be determined by checking whether the current time is within the preset reservation time range, or by querying the status database of the reservation project. A timestamp accurate to milliseconds can be used for comparison to ensure fairness. If the reservation project has not started yet, the reservation submission interface address will not be returned temporarily, which can prevent the user from submitting a reservation in advance. If the reservation project has started, continue with the subsequent steps. This embodiment can ensure that all users have a fair chance when the reservation project starts.

[0084] When it is determined that the appointment project has not started, the appointment submission interface address is not returned to the user. This can be achieved by sending a specific status code or message to the client, such as returning a prompt that "the appointment has not started yet". In another embodiment, a countdown information for the start of the appointment can also be provided to let the user know the appointment waiting time. During the waiting period, the time can be continuously monitored, and a notification is sent to the user when the appointment is about to start. The above scheme can effectively prevent users from submitting appointments before the official appointment time, ensuring the fairness and orderliness of the appointment process. At the same time, it can help control the server load and prevent a large number of concurrent requests from occurring at the moment the appointment starts.

[0085] After the reservation project starts, a new reservation submission interface address is generated for each user. First, the user feature value calculated above is used, combined with the preset address key and the current timestamp. The address key is used to increase the security of the generation process. The current timestamp can ensure that the generated address is timely. Specifically, the current timestamp refers to the total number of seconds from 00:00:00 Greenwich time on January 1, 1970 (08:00:00 Beijing time on January 1, 1970) to the present. The secure hash algorithm can be SHA-1. The hash algorithm outputs a fixed-length hash value, which will be used as part of the new reservation submission interface address. Among them, SHA-1 is a cryptographic hash function that can generate a 160-bit (20-byte) hash value called a message digest, and the hash value is usually presented as 40 hexadecimal numbers.

[0086] In this embodiment, the user characteristic value Q, the address key X and the timestamp TT are combined to obtain the new reservation submission interface address D using SHA-1, which is:

[0087] D=SHA1(Q+X+TT).

[0088] For example, in the reservation activity, the path of the server activity status interface is / api / status, the address key is 202405, and the path to submit the reservation is / api / submit / ***. The activity status interface address requested by user A is the domain name 4 / api / status. After the server determines that the activity has started, the request time is 2024-5-1609:00:00, and the timestamp is 1715821200. Generate the new reservation submission interface address D = SHA1 (3243 + 202405 + 1715821200) = SHA1 (1716026848) = 636*****27b7 for user A. Then the complete new reservation submission interface address returned to user A is the domain name 4 / api / submit / 636*****27b7.

[0089] In summary, a unique, secure and time-sensitive submission interface address can be generated for each user at each reservation. This not only increases security and prevents unauthorized access and replay attacks, but also makes each reservation operation independent, making it easier to track and manage.

[0090] Afterwards, the server returns the user's new reservation submission interface address D to the client. First, the new reservation submission interface address is combined with the previously determined server interface domain name to form a complete URL. This URL will be sent to the corresponding user account through a secure communication channel (such as HTTPS). After the client receives the URL, it will prompt the user to enter the reservation information. The information includes the reservation date, time period, number of people, etc. After the user fills in the reservation information, the client uses the preset key to generate a signature and requests to submit the reservation address D. Specifically, this embodiment uses the MD5 (Message-Digest Algorithm) information digest algorithm to generate a signature S for the string formed by splicing the user M, the scenic spot T selected by the user, the traveler C selected by the user, and the key K, that is:

[0091] S=MD5(MTCK).

[0092] After receiving the reservation submission request, the server verifies the received reservation submission request. First, the server checks whether the reservation submission interface address in the request is valid. If the address verification is successful, the server further verifies the client's signature. By using the same algorithm and key as the client, the signature is regenerated for the received data, and then compared with the signature in the request. If the two signatures match, the signature verification is considered to be successful. This double verification mechanism greatly enhances security. Address verification ensures that the request comes from the correct interface, while signature verification ensures that the data has not been tampered with during transmission and is indeed from an authorized client. It effectively prevents forged requests and man-in-the-middle attacks, ensuring that only legitimate, untampered reservation requests can be accepted and processed. Specifically, the server first determines whether the reservation submission address of the request is consistent with the reservation submission address D generated by the user before. If they are inconsistent, it is marked as a ticket swiping failure. If they are consistent, it verifies whether the signature is correct. The server generates a signature G based on the user M submitted by the client, the scenic spot T selected by the user, the traveler C selected by the user, and the key K. The generation algorithm is consistent with the client. It determines whether the client signature S is consistent with the server signature G. If they are inconsistent, the reservation submission fails. If they are consistent, the verification passes and the reservation is completed.

[0093] For example, the reservation submission key string r**2024 is set in this activity. User A selects scenic spot 1 and traveler Zhang San when making a reservation and submits it. The client generates a signature S=MD5("id1 scenic spot 1 Zhang San r**2024")=14***82 based on user A's record MA(id1, 103, 1212, 758), scenic spot "Scenic Spot 1", traveler "Zhang San", and key r**2024, and then requests to submit the reservation address 636*****27b7. The server compares the submitted reservation interface sent by the server to the domain name 4 / api / submit / 636*****27b7. After the comparison is correct, the submitted parameters user MA(id1, 103, 1212, 758), scenic spot "Scenic Spot 1", traveler "Zhang San", and key r**2024 are used to generate a signature G=MD5("id1 scenic spot 1 Zhang San r**2024")=14***82, verify the signature G=S, and complete the reservation request of user A.

[0094] The purpose of generating a signature in this embodiment is to ensure that the reservation information is not tampered with during transmission, and to verify that the request is indeed from a legitimate client. Finally, the client sends the reservation information and the generated signature to the reservation submission interface address provided by the server through a POST or PUT request, thereby establishing a secure and verifiable reservation information submission channel, ensuring the integrity and authenticity of the reservation process.

[0095] When the server confirms that the reservation submission address and the client signature are correct, it starts to process the reservation information. First, parse the reservation information and extract key data such as reservation date, time, number of people, etc. Then, check whether the information complies with the reservation rules, such as whether it is within the allowed date range, whether it exceeds the number of people for a single reservation, etc. Next, check the current reservation status to confirm whether there are any remaining places. If all conditions are met, a new reservation record will be created in the database, including user information, reservation details and a unique reservation ID. Finally, a reservation confirmation message will be generated, including a notification of successful reservation, reservation details, methods for canceling the reservation, etc., and the information will be returned to the client to complete the entire reservation process, ensuring the accurate recording and processing of reservation information, while providing users with instant reservation confirmation and improving user experience.

[0096] In summary, for traditional reservations, the ticket-swiping software simulates client requests, frequently requests new reservation submission interface addresses before the event starts, assembles and submits reservation parameters, and completes the reservation at the moment the event starts. According to the embodiment of the present application, the new reservation submission interface address cannot be known in advance, and different addresses can only be obtained according to different users to complete the reservation, which increases the difficulty of making ticket-swiping software, reduces the reusability of ticket-swiping software, and increases the cost of ticket-swiping. It can also be monitored when the ticket-swiping software attacks and take other emergency measures.

[0097] In this embodiment, since the reservation submission interface address is dynamically generated based on the user feature value, the preset address key and the current timestamp, the interface address of each user is unique and will change over time, making it difficult for the robot to predict or reuse the interface address, and the interface address is bound to the user, indicating that even if the robot obtains a valid address, it cannot be used for reservations for other user accounts. Therefore, by assigning a corresponding server interface domain name and a dynamically generated reservation submission interface address to each user, it is possible to effectively prevent robots from batch ticket swiping, thereby increasing the security of reservations; in addition, the user only needs to log in to the scenic spot reservation platform once, and the server can obtain the user information, and determine and distribute the server interface domain name based on the user information, so that the user can use the server interface domain name for subsequent reservation operations after logging in once, so that the user does not need to log in and verify separately for each family member or team member, and does not need to frequently enter the verification code, which effectively simplifies the user's operation process and thus effectively improves the user experience.

[0098] In one implementation of this embodiment, the server is deployed with n sets of services, each set of services corresponds to a server interface domain name, the user information includes a device ID, account data and IP address, n is a positive integer, and according to the user information of each user account, the server interface domain name corresponding to each user account is determined and distributed, including the following steps:

[0099] S210. For each user account, obtain a first weight corresponding to the device ID, a second weight corresponding to the account data, and a third weight corresponding to the IP address;

[0100] S220, performing weighted summation on the device ID, the account data, and the IP address according to the first weight, the second weight, and the third weight to obtain a user characteristic value Q;

[0101] S230 , calculate the remainder i of the user characteristic value Q divided by the value of n, determine the server interface domain name corresponding to the user account as U(i+1) and distribute it.

[0102] First, deploy n sets of services on the server, corresponding to interface domain names U1, U2, …, U(n) respectively. When the client requests the interface domain name Ui, it corresponds to accessing the i-th set of services. For example, in an event, the reservation system server deploys 5 sets of services, and the corresponding interface domain names are Domain Name 1, Domain Name 2, Domain Name 3, Domain Name 4, and Domain Name 5. Accessing each interface domain name will only request the corresponding server. For example, accessing Domain Name 3 will only request the 3rd set of services.

[0103] After the user logs in to the system, the client obtains the user's device information K1, account information K2, IP address (Internet Protocol Address) K3, etc., and records them as user M(id, K1, K2, K3, … Km). According to the weights V1, V2, …, Vm set by the system, the weighted sum is calculated to obtain the user's eigenvalue Q, that is:

[0104] Q = K1×V1 + K2×V2 + K3×V3 + … + Km×Vm.

[0105] Then, the user eigenvalue Q is divided by n and the remainder is i. Then the user uses the interface domain name U(i + 1) to interact with the server. Among them, 0 ≤ i < n and i is an integer.

[0106] In this embodiment, the recording methods of various types of user information and the weights of various types of user information are set in advance in the system to calculate the user's eigenvalue. For example, for the reservation project, the following three types of user information are set: K1 is the user device information, and the recording method is the enumeration method. The enumeration values are (101 represents mobile phone model A, 102 represents mobile phone model B, 103 represents mobile phone model C, 104 represents other mobile phone models); K2 is the user mobile phone number information, and the recording method is to use the last 4 digits of the mobile phone number; K3 is the user IP address, and the recording method is to add the values of the four segments of the IP address. The weights of these three types of user information are set as V1 = 5, V2 = 1, and V3 = 2 respectively.

[0107] Then, after the user logs in, the user's characteristic value can be calculated based on the user's information obtained by the client. For example, user A logs in to the system using the phone number 139****1212 on the A model phone, and the IP address is 219.140.151.248. It can be determined that user A's device information K1=103, the phone number information K2=1212, and the IP address K3=219+140+151+248=758, that is, user A's record is MA (id1, 103, 1212, 758). Then, based on the set user information weights, the weighted sum is used to calculate the characteristic value of user A Q=K1×V1+K2×V2+K3×V3=103×5+1212×1+758×2=515+1212+1516=3243. The user characteristic value Q is divided by n and the remainder is i, that is, 3243 divided by 5 is 648 and the remainder is 3. The interface domain name U(i+1) used by user A is domain name 4.

[0108] The server interface domain name allocation method based on user characteristics in this implementation method realizes intelligent load balancing and user management. By comprehensively considering multi-dimensional information such as device ID, account data and IP address, users can be identified and distinguished more accurately, which not only improves performance and reliability, but also reduces the risk of large-scale attacks and enhances security because each user is assigned to a specific service interface.

[0109] In one implementation of this embodiment, the reservation information includes the user name, the reservation item name and the traveler name, and the client generates a signature using a preset key, including the following steps:

[0110] S310. The client uses a preset information digest algorithm to concatenate the user name, reservation item name, traveler name and preset key K to generate a signature.

[0111] After the user fills in the reservation information, the client generates a signature based on the information filled in by the user and requests a new reservation submission interface address D. The MD5 (Message-Digest Algorithm) information digest algorithm is used to generate a signature S for the string composed of the user M, the scenic spot T selected by the user, the traveler C selected by the user, and the key K, which is:

[0112] S=MD5(MTCK).

[0113] After the server receives the submission reservation request, it determines whether the new reservation submission interface address in the request is the same as the new reservation submission interface address D generated by the user before. If they are not the same, it is marked as ticket-scalping and not approved. If they are the same, it verifies whether the signature is correct. The server generates a signature G based on the user M submitted by the client, the scenic spot T selected by the user, the traveler C selected by the user, and the secret key K. The generation algorithm is the same as that of the client. It determines whether the client signature S is the same as the server signature G. If they are not the same, the reservation submission fails. If they are the same, the verification passes and the reservation is completed.

[0114] For example, the submission reservation secret key string r**2024 is set for this event. User A selects scenic spot 1 and traveler Zhang San during the reservation and submits. The client generates a signature S = MD5("id1 scenic spot 1 Zhang San r**2024") = 14***82 based on the record MA (id1, 103, 1212, 758) of user A, the scenic spot "scenic spot 1", the traveler "Zhang San", and the secret key r**2024, and then requests the new reservation submission interface address 636*****27b7. The server compares the issued submission reservation interface as the domain name 4 / api / submit / 636*****27b7. After the comparison is correct, it uses the submitted parameters user MA (id1, 103, 1212, 758), the scenic spot "scenic spot 1", the traveler "Zhang San", and the secret key r**2024 to generate a signature G = MD5("id1 scenic spot 1 Zhang San r**2024") = 14***82, verifies that the signature G = S, and completes the reservation request of user A.

[0115] In this embodiment, by combining the user name, the reservation item name, and the traveler name with a preset secret key and using the information digest algorithm to generate a signature, the authenticity and integrity of the reservation information can be effectively verified. It not only prevents malicious users from tampering with the reservation information but also ensures the security of the data during the transmission process.

[0116] In one implementation manner of this embodiment, the scenic spot reservation platform includes a data cache component and a database. The reservation information further includes an account ID, and the user name corresponds to the account ID one by one. After the client corresponding to the user account responds to the user's reservation information input instruction, obtains the reservation information, generates a signature using the preset secret key, and sends the reservation information and the reservation submission request to the server, the following steps are included:

[0117] S410. Pack m groups of reservation information to obtain n data packets. Among them, each data packet includes an index structure, and the index structure is used to indicate the position of the user behavior data of each user account in the data packet. m > 2, n < m, and both m and n are integers;

[0118] S420, transmitting n data packets to the data cache component, and determining a cache strategy for each data packet in the data cache component based on an index structure of each data packet;

[0119] S430, determining flow nodes of n data packets according to the cache strategy, the flow nodes including the database inflow node and the verification node, wherein the sum of the number of data packets flowing into the database inflow node and the number of data packets flowing into the verification node is n;

[0120] S440, if the node to which the data packet flows is a verification node, decompress the data packet to obtain multiple groups of reservation information, and obtain the number of reservation items under each account ID in the database according to the account ID in each group of reservation information;

[0121] S450, when the number of scheduled items is less than or equal to the preset number threshold, determining that the data packet is a valid data packet, and verifying the user account corresponding to the valid data packet;

[0122] S460, when the user account corresponding to the valid data packet is verified, generating a reservation success page to the verified user account;

[0123] S470. When the number of scheduled items is greater than a preset threshold, determine that the data packet is an invalid data packet, and generate a reservation failure feedback message to the user account corresponding to the invalid data packet according to the user name corresponding to the number of scheduled items greater than the preset threshold.

[0124] In this embodiment, S410 (packing m groups of reservation information to obtain n data packets when the current time period is a peak time period) includes the following steps:

[0125] In the case where the current time period is a peak time period, if m is greater than a preset first quantity threshold, the number p of groups of reservation information to be contained in each data packet is calculated, and the p groups of reservation information are stored in the data packet, wherein p is less than or equal to a preset first maximum packaging quantity and greater than a preset basic packaging quantity, and the basic packaging quantity is less than the first maximum packaging quantity;

[0126] If m is greater than a preset second quantity threshold, multiply the first maximum package quantity by a preset growth parameter k to obtain a second maximum package quantity, wherein k>1, and the second quantity threshold is greater than the first quantity threshold;

[0127] The number q of groups of reservation information to be contained in each data packet is calculated, and the q groups of reservation information are stored in the data packet, wherein q is less than or equal to the second maximum packaging number and greater than the basic packaging number.

[0128] In this embodiment, first, m groups of reservation information are collected, and the reservation information comes from reservation requests of different users. Each group of reservation information contains detailed information such as the user's account ID, the reserved scenic spots, and the time. In order to improve the efficiency of data transmission and processing, these m groups of information are packaged into n data packets, where n is less than m. The above packaging strategy can reduce the number of network transmissions and reduce the load. Each data packet contains an index structure, which is a key component of the data packet, and records the specific location of the behavior data of each user account in the data packet. The index structure can be implemented using a hash table or a tree structure to quickly locate and retrieve the data of a specific user. For example, the index can record the information that "the data of user A starts at byte offset 100 and is 200 bytes long." The design enables the data of a specific user to be quickly accessed without decompressing the entire data packet, greatly improving the efficiency of data processing. In addition, the index structure can also contain the overall information of the data packet, such as the creation time, the total number of reservation information contained, etc., which is helpful for subsequent data management and processing.

[0129] Then, the packaged n data packets are transmitted to the data cache component. The transmission process can use a secure transmission protocol, such as HTTPS, to ensure the security of the data. The data cache component is a high-speed memory storage, such as Redis or Memcached, which can provide faster read and write speeds than traditional databases. When the data packet arrives at the data cache component, its caching strategy is determined based on the index structure of each data packet.

[0130] Specifically, we first analyze the metadata in the index structure, such as the creation time of the data packet, the number of reservation information contained, etc., to determine the priority of the data packet. Secondly, we will consider the distribution of the behavioral data of each user account in the data packet, and set a longer cache time for frequently accessed user data. Thirdly, we can dynamically adjust the cache strategy based on the current load and available resources. For example, when the load is light, more data packets can be cached. The cache strategy can include cache time, cache priority, whether to perform shard storage, etc. For example, for a data packet containing a large amount of reservation information for popular attractions, you can set a longer cache time and a higher priority.

[0131] According to the cache strategy determined in the above steps, a flow node is selected for each data packet. There are two types of flow nodes: database inflow node and verification node. The database inflow node is a path that directly imports data packets into persistent storage, which is suitable for data packets that are not processed or verified immediately. The verification node is a path for further processing and verification. When selecting a flow node, multiple factors are considered: First, it will be determined based on the priority and importance of the data packet. For example, a data packet containing a large amount of new user reservation information can be sent to the verification node first. Secondly, the current load of each node will be considered to achieve load balancing. Thirdly, the timeliness of the reservation information in the data packet can be considered, and the upcoming reservation can be sent to the verification node first. It will ensure that the sum of the number of data packets flowing into the database inflow node and the verification node is equal to n, that is, all data packets are assigned a destination.

[0132] After that, the data packets flowing to the verification node are processed. First, the data packets are decompressed. After decompression, multiple groups of appointment information are obtained, each of which contains the appointment details of a user. Next, the account ID in each group of appointment information is extracted. The account ID is the key information that uniquely identifies the user, which can be a string of numbers or letters. Then, based on the account ID, the number of existing appointment items under each account is queried in the database. The query process can use indexes to speed up the query, or use caches to reduce the access pressure of the database. The query can use SQL statements or specific query languages. For example, an SQL query statement can be: SELECTCOUNT(*)FROM****. Queries can be executed in batches to improve efficiency. The query results will be temporarily stored for use in subsequent steps.

[0133] Next, the number of reservation items under each account ID obtained in the above steps is compared with the preset number threshold. This preset number threshold is pre-set by the administrator based on factors such as the capacity and management strategy of the scenic spot, and is used to limit the maximum number of items that a single user can reserve. If the number of reservation items for an account is less than or equal to the preset number threshold, the data corresponding to this account is judged to be valid. At this time, the data packet is marked as a valid data packet. For valid data packets, the corresponding user account will be further verified. This verification process may include checking the user's login status, account permissions, credit score, etc. Verification can call other services or modules, such as identity authentication services, credit scores, etc. If the number of reservation items is greater than the preset number threshold, the data packet will be marked as an invalid data packet, skipping the verification step and directly entering the process of processing invalid data.

[0134] For valid data packets that have passed verification, first, confirm the user account that has passed verification, which can be determined by checking the flag bit of the verification result. For each user account that has passed verification, generate a successful reservation page. The page generation process may include the following steps: First, extract the user's specific reservation information from the data packet, such as the reserved attractions, time, number of people, etc. Then, use a predefined template to build the page content. The template can be in HTML format and contain the basic structure and style of the page. Fill the user's reservation information into the corresponding position in the template. Next, dynamic content such as QR code, reservation number, etc. can be added, which can be generated by calling a specific service or algorithm. The generated page can contain some additional information, such as precautions for attractions, weather forecasts, etc., and the information can be obtained from other data sources. Finally, the generated successful reservation page is sent to the user. The sending process may involve pushing the page content to the user's client application, or generating an accessible URL link to send to the user. The user's reservation record can be updated at the same time, and the new reservation information can be saved in the database.

[0135] For invalid data packets, it can be determined by identifying user accounts whose number of scheduled items is greater than a preset number threshold. For each user who exceeds the reservation limit, feedback information of failed reservation is generated. The process of generating feedback information may include the following steps: First, prepare a predefined message template, which may contain basic failure notification content. Then, insert the user's specific information, such as user name, current number of scheduled items, preset number threshold, etc., into the corresponding position in the template. At the same time, a mark can be added to the user's account record to indicate that the user has attempted to make a reservation beyond the limit, which can be used for subsequent user behavior analysis or risk control.

[0136] It should be noted that the current time period of S410-S470 is the peak time period. Figure 2 A flowchart of a reservation management method for off-peak hours provided in an embodiment of the present application is shown. Figure 2 As shown, when the current time period is a non-peak time period, after obtaining the reservation information corresponding to each reservation request, the following steps are also included:

[0137] According to the account ID (identity identifier) ​​in each set of reservation information, the number of reservation items under each account ID is obtained in the database;

[0138] When the number of scheduled items is less than or equal to the preset number threshold, the corresponding reservation information is determined to be valid, and the user account (current personal account) corresponding to the valid reservation information is verified;

[0139] When the user account corresponding to the valid reservation information is verified, a reservation success page is generated to the user account;

[0140] When the number of scheduled items is greater than a preset threshold, the corresponding scheduled information is determined to be invalid, and based on the user name corresponding to the number of scheduled items greater than the preset threshold, a scheduled failure feedback message is generated to the user account corresponding to the invalid scheduled information.

[0141] This implementation method can efficiently process a large number of reservation requests through intelligent packaging and diversion of data packets. Dynamic adjustment of cache strategy improves response speed. Strict verification mechanism and reservation quantity control ensure fairness in resource allocation and prevent malicious reservations. Real-time success feedback and failure notifications improve user experience. The whole process not only optimizes performance, but also provides strong support for scenic spot management and realizes the rational allocation and utilization of resources. At the same time, it can effectively control the number of reservations for a single user to prevent excessive occupation of resources, and can also provide clear feedback to users in a timely manner, which helps to maintain the fairness of reservations and user experience.

[0142] In one implementation of this embodiment, after generating a reservation success page to the user account, the following steps are included:

[0143] S510, obtaining a target user account corresponding to each account ID in the reservation information of the user account;

[0144] S520, according to the reservation project name of the user account, storing the user account and all target user accounts in a reservation database corresponding to the reservation project name, and sending reservation success feedback information to each target user account;

[0145] S530: Within a preset time period, no longer respond to reservation requests for the current reservation scenic spot from all user accounts in the reservation database.

[0146] First, access the reservation information of the user account. The information is usually stored in a database, and a relational database such as MySQL can be used. The reservation information contains multiple account IDs. The account ID can be the account information of the companions filled in by the user when making a reservation. Traverse the account IDs and perform a query operation on each ID to obtain the corresponding target user account details. The query process may involve multiple database operations, so batch query or parallel query technology can be used to improve efficiency. For example, if an SQL database is used, an IN clause can be constructed to query multiple account IDs at a time. The query results can include basic information of the target user, such as user name, contact information, etc. If some account IDs do not have corresponding user accounts, error handling can be performed, such as logging or notifying the main reservation user. In addition, the validity of the target user account can be verified, such as checking whether the account status is normal and whether it has the authority to participate in the reservation. The verification process may involve calling the user management API. The obtained target user account information is temporarily stored, and a memory cache or a temporary data table can be used for subsequent steps.

[0147] Then, the user account and the target user account are stored in the reservation database, and feedback information is sent to the target user. First, the corresponding reservation database is determined according to the reservation project name of the user account. The reservation database can be a database instance or table dedicated to storing specific reservation project information. The information of the user account and all target user accounts is inserted into the database. The insert operation can use batch insert technology to improve efficiency. The inserted data may include user ID, reservation time, reservation project details and other information. If the reservation involves multiple time periods or multiple attractions, multiple insert operations can be performed. After the storage is completed, a reservation success feedback message is sent to each target user account. Different notification methods can be selected according to the user's preferences, such as App push, SMS, email, etc. During the sending process, handle possible sending failures, such as a retry mechanism or logging failure information in the log.

[0148] In order to implement reservation restrictions, a preset time period can be set, which can be 30 minutes, 1 hour or longer. During the preset time period, special treatment is implemented for all user accounts in the reservation database. Specifically, when a user account tries to make a reservation for the same attraction again, the response request is rejected. The implementation of this function may include: first, maintaining a fast query structure, which can be a memory cache or a high-speed database, for storing the user account and the corresponding attraction information that have recently completed the reservation. Whenever a reservation request is received, first check whether the user account that initiated the request is in the structure and whether it is a request for the same attraction. If it matches, the request is directly rejected without further processing. Secondly, a timed cleanup mechanism is implemented. After the preset time period ends, the corresponding user account is removed from the fast query structure, allowing the user to make a reservation again. The cleanup process can be implemented using a scheduled task or a lazy deletion strategy. When rejecting a request, clear feedback should be provided to the user to explain the reason for the request being rejected. The above method can effectively prevent users from repeatedly reserving the same attraction in a short period of time, avoid waste of resources and suspicious malicious operations, and also provide more opportunities for other users to make reservations, thereby improving the fairness and efficiency of the entire reservation.

[0149] This implementation ensures the integrity and accuracy of reservation data by accurately acquiring and storing all relevant user information. The real-time feedback mechanism allows all participants to obtain reservation confirmation in a timely manner, enhancing reliability. The reservation restriction function effectively prevents duplicate reservations in a short period of time and improves the fairness and efficiency of resource allocation. Overall, the method not only optimizes the reservation process, but also provides strong support for scenic spot management and realizes the rational allocation and utilization of resources.

[0150] In one implementation of this embodiment, the reservation success page includes reservation success feedback information and a preset link button. After the reservation success page is generated to the user account, the following steps are also included:

[0151] S610, in response to a user's click instruction on a link button, generating a unique evaluation link for the reservation information according to the reservation information of the user account corresponding to the user and jumping to the unique evaluation link, the unique evaluation link being associated with the link button, and the unique evaluation link including the account ID, the reservation order number, the reservation item name, and the timestamp;

[0152] S620, determining whether to respond to the filling instruction or canceling instruction of the user in the unique evaluation link within a preset time period;

[0153] S630: If the user fills in the unique evaluation link in response to the user's instruction within the preset time period, obtain the user's evaluation information in the unique evaluation link, and store the evaluation information in association with the user's reservation information;

[0154] S640: If the user's fill-in instruction or cancel instruction in the unique evaluation link is not responded to within a preset time period, the unique evaluation link is closed;

[0155] S650: If a cancel instruction in the unique evaluation link is responded to within a preset time period, the unique evaluation link is closed.

[0156] Figure 3 The flowchart of the embodiment of the present application after generating a reservation success page to a user account is shown as follows: Figure 3 As shown, when the user clicks the link button on the reservation success page, the click event is captured. Subsequently, the database or cache is accessed to obtain the reservation information related to the user account. The information may include detailed data such as the specific content, time, and location of the reservation. Based on the reservation information, a unique evaluation link is generated. The process of generating a unique link can involve multiple steps: First, information such as the account ID, reservation order number, reservation item name, and current timestamp are combined together. Then, the information can be hashed using an encryption algorithm (such as SHA-256) to generate a unique string. The string is used as part of the link. For example, the link can be: https: / / ***.com / *** / [generated unique string].

[0157] After the link is generated, the link is associated with the user's reservation information and stored in the database, so that the validity of the link can be verified later and the user's evaluation can be correctly associated with the corresponding reservation.

[0158] Finally, trigger the page jump and direct the user to the unique evaluation link page. The jump process can be achieved using HTTP redirection or front-end routing jump. After jumping to the evaluation page, pre-fill part of the form content according to the information contained in the link (account ID, reservation order number, etc.) to improve the user experience.

[0159] The above method enables each user to obtain a unique evaluation entry corresponding to their reservation, which not only ensures the accuracy and traceability of the evaluation data, but also improves the convenience of users filling out the evaluation. At the same time, since the link is dynamically generated, it also enhances security and prevents unauthorized evaluation submission.

[0160] Afterwards, a preset time period is set. The time period can be determined based on business needs. The starting point of the time period is usually the moment when the unique evaluation link is generated, and the time point is recorded in the database.

[0161] When a user accesses a unique evaluation link, first check whether the current time is within the preset time period. The checking process may include the following steps: 1. Get the current time, which may be the server time or a unified time service. 2. Read the generation time of the evaluation link from the database. 3. Calculate the difference between the current time and the link generation time. 4. Compare the difference with the preset time period.

[0162] If the current time is within the preset time period, continue to monitor the user's operations. For example, the instructions for filling in the evaluation and the instructions for canceling the evaluation. You can use event listeners to capture user operations. For filling in instructions, you can monitor the form submission event or the specific "Submit" button click event. When the event is captured, enter the evaluation information processing flow. For cancel instructions, you can monitor the specific "Cancel" button click event or the page closing event. When the event is captured, enter the cancellation processing flow. If no operation is captured within the preset time period, you can use a scheduled task or check the next time the user visits to handle the timeout.

[0163] When it is detected that the user has submitted an evaluation within the preset time period, the process of obtaining and storing the evaluation information is immediately started. First, capture the evaluation information submitted by the user. The information can include multiple aspects, such as service quality score, environment score, overall satisfaction, and text evaluation. Perform preliminary verification and cleaning of the information, such as checking whether the required fields are filled in, removing suspicious malicious code or inappropriate content, formatting text, etc. Next, associate the evaluation information with the user's reservation information. The association process includes: 1. Create a new record in the evaluation table, containing the evaluation content and the corresponding reservation ID. 2. Add evaluation-related fields to the reservation table and store the evaluation information directly in the reservation record. 3. Create a separate association table to store the correspondence between the reservation ID and the evaluation ID.

[0164] Finally, close or mark the unique evaluation link as used to prevent duplicate evaluation submissions.

[0165] In summary, the user's evaluation information is accurately captured and stored, and is closely associated with the corresponding reservation information.

[0166] If the user does not respond to the unique evaluation link within the preset time period, indicating that the evaluation link has timed out, the following operations are performed:

[0167] 1. Update the link status to "Expired". 2. Generate a log record to record the reason and time when the link was closed.

[0168] In this embodiment, it is necessary to ensure that the closing operation is irreversible. Once the link is closed, the user can no longer submit a review through the link. This can be achieved by adding link status verification to the permission check on the review page.

[0169] When it is detected that the user clicks the cancel button or performs other cancellation operations, the cancellation step is triggered. That is, the unique evaluation link is closed. At this time, the link will no longer be used to submit a review. If the user tries to access the link again, a prompt message will be returned, indicating that the review has been cancelled.

[0170] This implementation ensures the accuracy of one evaluation per reservation by generating a unique evaluation link. The time control mechanism ensures the timeliness of the evaluation while giving users sufficient time to provide feedback. The associated storage of evaluation information enhances the integrity and traceability of the data, and can automatically close expired links and respond to cancellation requests, optimizing the user experience.

[0171] In one implementation of this embodiment, determining a cache strategy for each data packet in a data cache component based on an index structure of each data packet includes the following steps:

[0172] S710. For any data packet, according to the index structure of the data packet, obtain the user behavior data of the user account corresponding to each set of reservation information in the data packet, the user behavior data including the historical reservation frequency and the historical verification pass number;

[0173] S720, determining the level of the corresponding user account according to the historical reservation frequency and the number of historical verification passes, where the user account levels include high, medium and low;

[0174] S730, calculating the ratio of high-level user accounts in the data packet to all user accounts, and if the ratio is greater than a preset ratio threshold, determining the cache strategy to be high-speed cache; and

[0175] S740: When the ratio is less than or equal to the ratio threshold, determine that the cache strategy is a low-speed cache;

[0176] Among them, when the historical reservation frequency is greater than a preset first threshold and the number of historical verification passes is greater than a preset second threshold, the level of the corresponding user account is determined to be advanced; when the historical reservation frequency is less than or equal to the first threshold and the number of historical verification passes is greater than the second threshold, the level of the corresponding user account is determined to be intermediate; when the historical reservation frequency is greater than the first threshold and the number of historical verification passes is less than or equal to the second threshold, the level of the corresponding user account is determined to be intermediate; when the historical reservation frequency is less than or equal to the first threshold and the number of historical verification passes is less than or equal to the second threshold, the level of the corresponding user account is determined to be low.

[0177] First, extract the user behavior data from the index structure of the data packet. Specifically, you can access the index structure of the data packet. The index structure can be a mapping table containing pointers to specific data locations or a more complex data structure. Through the index structure, you can quickly locate the location of each set of appointment information in the data packet. For each set of appointment information, extract the user account information associated with it. After obtaining the user account information, query the user behavior database or cache to obtain the user's historical appointment frequency and historical verification pass count. The historical appointment frequency can be calculated by counting the number of appointments made by the user in a certain period of time in the past (such as the past year). The sliding window technology can be used to calculate the appointment frequency in the recent period. The historical verification pass count can be a cumulative value, recording the total number of times the user successfully passed the identity authentication or other verification process.

[0178] In actual implementation, you may face the situation of incomplete or inconsistent data. For example, a new user may not have enough historical data. For the above situation, you can set default values ​​or adopt special processing logic.

[0179] Afterwards, the level of the user account is determined based on the user's historical appointment frequency and historical verification pass count. First, two key thresholds are predefined: the first threshold is used to determine the historical appointment frequency, and the second threshold is used to determine the historical verification pass count. Next, the historical appointment frequency and historical verification pass count of each user account are evaluated. The process may involve the following steps: 1. Read the user's historical appointment frequency and historical verification pass count. 2. Compare the historical appointment frequency with the first threshold. 3. Compare the historical verification pass count with the second threshold.

[0180] If the historical reservation frequency is greater than the first threshold, and the number of historical verification passes is greater than the second threshold, the user level is determined to be high. If the historical reservation frequency is less than or equal to the first threshold, but the number of historical verification passes is greater than the second threshold, the user level is determined to be intermediate. If the historical reservation frequency is greater than the first threshold, but the number of historical verification passes is less than or equal to the second threshold, the user level is also determined to be intermediate. If the historical reservation frequency is less than or equal to the first threshold, and the number of historical verification passes is also less than or equal to the second threshold, the user level is determined to be low. In actual implementation, a temporary level identification implementation can be created for each user.

[0181] After that, the proportion of high-level user accounts in the data packet is calculated, and based on the proportion, whether to adopt a cache strategy is determined. First, the user accounts in the data packet are counted. Specifically, two counters can be initialized, one for recording the number of high-level user accounts and the other for recording the total number of all user accounts. Then, each user account in the data packet is traversed. Finally, for each user account, its level is checked. If it is a high-level account, the high-level user counter is increased; regardless of the level, the total user counter is increased.

[0182] Next, calculate the proportion of advanced user accounts. The calculation formula can be:

[0183] The ratio of advanced users = the number of advanced user accounts / the total number of user accounts. Then, the calculated ratio is compared with the preset ratio threshold. If the calculated ratio of advanced users is greater than the preset ratio threshold, a high-speed cache strategy is adopted for the data packet.

[0184] If the proportion of advanced users does not reach the preset threshold, a low-speed cache strategy is adopted.

[0185] This implementation method can accurately classify users by analyzing their historical reservation frequency and verification pass times, thereby determining a high-speed cache strategy or a low-speed cache strategy, which not only ensures fast access to important data but also optimizes resource utilization. Intelligent cache management not only improves overall performance, but also enhances user experience.

[0186] In one implementation of this embodiment, determining the flow nodes of n data packets according to the cache strategy includes the following steps:

[0187] S810, if the cache strategy of any one or more data packets is high-speed cache, determining the flow node of any one or more data packets as a verification node;

[0188] S820: If the cache strategy of any one or more data packets is low-speed cache, determine that the flow node of any one or more data packets is a database inflow node.

[0189] Verification nodes are high-performance computing units responsible for data verification, processing or analysis. Routing cache packets to verification nodes can take advantage of the high-performance processing capabilities of verification nodes to quickly complete data verification and processing. The routing process can involve the following two steps: 1. Create a routing tag for each cache packet, indicating that its destination is the verification node. 2. Put the packet into a high-priority queue to ensure that it is processed first.

[0190] For packets marked as low-speed cache, their flow direction is determined to be the database inflow node. The database inflow node is usually the component responsible for writing data to persistent storage. The reason for routing low-speed cache packets to the database inflow node is that the data may not be processed immediately or has a lower processing priority. The routing process may involve the following two steps: 1. Create a routing tag for each low-speed cache packet, indicating that its destination is the database inflow node. 2. Put the packet into a low-priority queue to ensure that high-priority packets can be processed first.

[0191] This implementation method can quickly process important or urgent data by routing cache data packets to verification nodes, improving response speed and service quality. At the same time, it directs low-speed cache data packets to the database inflow node, ensuring that all data is properly stored and laying the foundation for future analysis and processing. Intelligent data flow management not only optimizes resource utilization, but also enhances scalability and performance, dynamically adjusts processing strategies according to data characteristics and load, and effectively improves data processing efficiency and flexibility.

[0192] In one implementation of this embodiment, if the flow node of the data packet is a database inflow node, the following steps are also included:

[0193] S910, performing format verification on the data packet, and after the format verification of the data packet passes, parsing the index structure of the data packet to obtain at least one user account;

[0194] S920, establishing a first connection with a database, searching for corresponding user records in the database according to at least one user account, and adding 1 to the total reservation quantity in each user record;

[0195] S930, if one or more user accounts in the data packet are verified, a second connection is established with the database, and in the database, the number of successful reservations and the number of verification passes in the user record corresponding to the verified user account are both increased by 1;

[0196] S940, executing the step of generating a reservation success page to the user account that has passed the verification.

[0197] In this embodiment, if one or more user accounts in the data packet fail to pass verification, a second connection is established with the database, and in the database, the number of successful reservations and the number of verifications in the user records corresponding to the user accounts that failed to pass verification are both reduced by 1;

[0198] Generate a reservation failure page to user accounts that have not been verified.

[0199] First, the data packet is format verified and the index structure is parsed to ensure data integrity and availability. Format verification of the data packet means checking whether the data packet conforms to the predefined structure and specifications. It can include verifying whether the header information, checksum, length, etc. of the data packet are correct. The specific implementation of format verification can involve the following steps: 1) Check the modulus or version number of the data packet to ensure that it is a processable type; 2) Verify whether the length of the data packet is as expected; 3) Check whether the required fields exist and are in the correct format; 4) Verify the checksum of the data packet to ensure that the data has not been damaged during transmission.

[0200] After the format verification is passed, the index structure of the data packet is parsed to extract the user account information. The index structure is usually the part of the data packet used to quickly locate specific information. The parsing process may involve the following steps: 1) locate the starting position of the index structure; 2) read the header information of the index structure to understand how the index is organized; 3) traverse the index structure to extract all user account information; 4) store the extracted user account information in memory for subsequent use.

[0201] After that, the first connection is established with the database. The connection process usually includes: 1) obtaining an available database connection from the connection pool. If there is no available connection in the connection pool, a new connection is created; 2) verifying the validity of the connection to ensure that it can work properly; 3) if the connection fails, try to re-establish the connection within a certain number of times.

[0202] After the connection is established, the corresponding user record is searched in the database according to the previously parsed user account. The search process may involve the following operations: 1) Construct a SQL query statement, using the user account as the query condition; 2) Execute the query operation, and consider using indexes to improve query efficiency; 3) Process the query results, including processing multiple results or no results. For each user record found, add 1 to the total reservation amount. The update operation may involve the following steps: 1) Construct a SQL update statement, add 1 to the value of the total reservation amount field; 2) Execute the update operation; 3) Verify whether the update is successful, and check the number of rows affected.

[0203] After that, the user account in the data packet is verified. The verification process may include the following steps: 1) Check whether the format of the user account is correct; 2) Verify whether the user account is registered; 3) Check the status of the user account to ensure that it is not disabled or locked; 4) Additional security checks may be performed, such as verifying the user's permission level or checking for abnormal login behavior.

[0204] For the authenticated user account, a second connection is established with the database. The connection process is similar to that described above, but the following points can be considered: 1) Use a connection pool to manage database connections to improve efficiency and reduce resource consumption; 2) Implement a connection retry mechanism to deal with suspected network failures; 3) Consider using a read-write separation strategy to route update operations to the primary database.

[0205] After the connection is established, the user record corresponding to the verified user account is updated in the database. The update operation involves two fields: the number of successful reservations and the number of verifications, both of which are increased by 1. The specific update process may include the following steps: 1) construct an SQL update statement to update these two fields at the same time; 2) execute the update operation.

[0206] Finally, the step of generating a reservation success page to the user account that has passed the verification in S460 is executed.

[0207] This implementation ensures the integrity and security of data by verifying the format of the data packet and the user account, and improves the user experience and enhances user satisfaction by generating a personalized reservation success page.

[0208] The present application also provides an electronic device, including:

[0209] a memory configured to store instructions; and

[0210] The processor is configured to call instructions from the memory and implement the above-mentioned reservation management method for smart attractions when executing the instructions.

[0211] 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 take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0212] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. 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 generate a machine, so that instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the process in the flowchart. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0213] Computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, the instruction device being implemented in the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0214] 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 the instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0215] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0216] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0217] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0218] 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.

[0219] The above are only embodiments of the present application and are 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 within the scope of the claims of the present application.

Claims

1. A reservation management method for smart scenic spots, characterized in that: Applied to a server, on which a scenic spot reservation platform is deployed, the method comprises: In response to receiving a login instruction from a client to the scenic spot reservation platform, obtaining user information of a user account of the client to log in to the scenic spot reservation platform; According to the user information of each user account, determine and distribute the server interface domain name corresponding to each user account, wherein the server interface domain name is calculated based on the user characteristic value, and the user characteristic value is calculated based on the user information; In response to receiving reservation requests for reservation items from m user accounts in the current time period, determining whether the reservation item corresponding to the reservation request has started, where m is an integer greater than 2; For each user account, if the reservation item has not started, the reservation submission interface address is not returned; When the reservation project starts, a hash value corresponding to each user account is generated using a preset secure hash algorithm according to the user feature value, the preset address key and the current timestamp, and the hash value is used to represent the new reservation submission interface address; Sending the new reservation submission interface address to the corresponding user account according to the server interface domain name, so that the client corresponding to the user account responds to the user's reservation information input instruction, obtains the reservation information, generates a signature using a preset key, and sends the reservation information and reservation submission request to the server; Verifying the reservation submission interface address corresponding to the reservation submission request, and after the reservation submission interface address is successfully verified, verifying whether the signature of the client corresponding to the reservation submission interface address is correct; If the signature of the client corresponding to the reservation submission interface address is correct, it is determined that the signature verification of the client corresponding to the reservation submission interface address has passed, and the reservation of the client corresponding to the reservation submission interface address is completed according to the reservation information.

2. The method according to claim 1, characterized in that The server is deployed with n sets of services, each set of services corresponds to a server interface domain name, the user information includes a device ID, account data and an IP address, n is a positive integer, and the server interface domain name corresponding to each user account is determined and distributed according to the user information of each user account, including: For each of the user accounts, obtaining a first weight corresponding to the device ID, a second weight corresponding to the account data, and a third weight corresponding to the IP address; Performing weighted summation on the device ID, the account data, and the IP address according to the first weight, the second weight, and the third weight to obtain a user feature value Q; The remainder i of the value of dividing the user characteristic value Q by n is calculated, and the server interface domain name corresponding to the user account is determined to be U(i+1) and distributed.

3. The method according to claim 1, characterized in that The reservation information includes the user name, the reservation item name and the traveler name. The client generates a signature using a preset key, including: The client uses a preset information digest algorithm to perform string concatenation on the user name, the reservation item name, the traveler name and a preset key K to generate a signature.

4. The method according to claim 3, characterized in that The scenic spot reservation platform includes a data cache component and a database. The reservation information further includes an account ID, and the user name corresponds to the account ID one by one. After the client corresponding to the user account responds to the user's reservation information input instruction, obtains the reservation information, generates a signature using a preset key, and sends the reservation information and a reservation submission request to the server, it includes: Pack m groups of the reservation information to obtain n data packets. Among them, each data packet includes an index structure, and the index structure is used to indicate the position of the user behavior data of each user account in the data packet. m > 2, n < m, and both m and n are integers; Transmit the n data packets to the data cache component, and based on the index structure of each data packet, determine the caching policy of each data packet in the data cache component; Determine the flow nodes of the n data packets according to the caching policy. The flow nodes include the database inflow node and the verification node. Among them, the sum of the number of data packets flowing into the database inflow node and the number of data packets flowing into the verification node is n; If the flow node of the data packet is the verification node, decompress the data packet to obtain multiple groups of the reservation information, and obtain the number of reservation items under each account ID in the database according to the account ID in each group of the reservation information; In the case where the number of reservation items is less than or equal to a preset quantity threshold, determine the data packet as a valid data packet, and verify the user account corresponding to the valid data packet; In the case where the user account corresponding to the valid data packet passes the verification, generate a reservation success page for the user account that has passed the verification; In the case where the number of reservation items is greater than the preset quantity threshold, determine the data packet as an invalid data packet, and generate a reservation failure feedback message to the user account corresponding to the invalid data packet according to the user name corresponding to the number of reservation items greater than the preset quantity threshold; 5. The method according to claim 4, characterized in that After generating the reservation success page for the user account, it includes: Obtain the target user account corresponding to each account ID in the reservation information of the user account; According to the reservation item name of the user account, store the user account and all the target user accounts in the reservation database corresponding to the reservation item name, and send a reservation success feedback message to each target user account; Within a preset time period, no longer respond to the reservation requests of all the user accounts in the reservation database for the current reserved scenic spot; 6. The method according to claim 4, characterized in that The reservation success page includes a reservation success feedback message and a preset link button. After generating the reservation success page for the user account, it further includes: In response to the user's click instruction on the link button, generate a unique evaluation link for the reservation information according to the reservation information of the user account corresponding to the user, and jump to the unique evaluation link. The unique evaluation link is associated with the link button, and the unique evaluation link includes an account ID, a reservation order number, a reservation item name, and a timestamp; Determining whether to respond to a fill-in instruction or a cancel instruction of the user in the unique evaluation link within a preset time period; If a user fills in the unique evaluation link within a preset time period, obtaining the user's evaluation information in the unique evaluation link, and storing the evaluation information in association with the user's reservation information; If the user's filling instruction or cancel instruction in the unique evaluation link is not responded to within a preset time period, closing the unique evaluation link; If a cancellation instruction in the unique evaluation link is responded to within a preset time period, the unique evaluation link is closed.

7. The method according to claim 4, characterized in that Determining a cache strategy of each data packet in the data cache component based on the index structure of each data packet includes: For any of the data packets, according to the index structure of the data packet, obtaining user behavior data of the user account corresponding to each set of the reservation information in the data packet, the user behavior data including the historical reservation frequency and the historical verification pass number; Determine the level of the corresponding user account according to the historical reservation frequency and the number of historical verification passes, the level of the user account including high level, medium level and low level; Calculating the ratio of user accounts with a high level in the data packet to all user accounts, and determining that the cache strategy is high-speed cache when the ratio is greater than a preset ratio threshold; and When the ratio is less than or equal to the ratio threshold, determining the cache strategy as a low-speed cache; Among them, when the historical reservation frequency is greater than a preset first threshold and the number of historical verification passes is greater than a preset second threshold, the level of the corresponding user account is determined to be high; when the historical reservation frequency is less than or equal to the first threshold and the number of historical verification passes is greater than the second threshold, the level of the corresponding user account is determined to be intermediate; when the historical reservation frequency is greater than the first threshold and the number of historical verification passes is less than or equal to the second threshold, the level of the corresponding user account is determined to be intermediate; when the historical reservation frequency is less than or equal to the first threshold and the number of historical verification passes is less than or equal to the second threshold, the level of the corresponding user account is determined to be low.

8. The method according to claim 7, characterized in that The step of determining the flow nodes of the n data packets according to the cache strategy includes: If the cache strategy of any one or more of the data packets is high-speed cache, determining the flow node of any one or more of the data packets as the verification node; If the cache strategy of any one or more of the data packets is the low-speed cache, it is determined that the flow node of any one or more of the data packets is the database inflow node.

9. The method according to claim 8, characterized in that If the flow node of the data packet is the database inflow node, the method further includes: Performing format verification on the data packet, and after the format verification of the data packet passes, parsing the index structure of the data packet to obtain at least one user account; Establishing a first connection with the database, searching for a corresponding user record in the database according to at least one of the user accounts, and adding 1 to the total reservation amount in each of the user records; If one or more of the user accounts in the data packet are verified, a second connection is established with the database, and in the database, the number of successful reservations and the number of verification passes in the user records corresponding to the verified user accounts are both increased by 1; Execute the steps of generating a reservation success page to verify the user account.

10. An electronic device, characterized in that: include: a memory configured to store instructions; as well as A processor is configured to call the instructions from the memory and implement the reservation management method for a smart scenic spot according to any one of claims 1 to 9 when executing the instructions.

Images