Data processing method, device and equipment of railway ticket system and storage medium

Abstract

The application provides a data processing method, device and equipment of a railway ticket system and a storage medium. The method comprises: when personal identity information is contained in a business request, generating a corresponding temporary virtual identifier and establishing a temporary mapping relationship between the temporary virtual identifier and the personal identity information; replacing the personal identity information in the business request with the temporary virtual identifier to obtain a replaced business request; sending the replaced business request to a cloud server to enable the cloud server to determine a business request result according to the replaced business request; receiving the business request result and restoring the temporary virtual identifier in the business request result to the corresponding personal identity information according to the temporary mapping relationship to perform a corresponding business operation. The application enables the cloud server to distinguish between different users and maintain the context continuity of multiple rounds of conversations on the premise of ensuring that the personal identity information does not leave the local server, and takes into account data security and the use of cloud computing power.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and specifically to a data processing method, apparatus, equipment, and storage medium for a railway passenger ticketing system. Background Technology

[0002] The railway passenger ticketing system is a comprehensive business platform provided by the railway to the public for ticket sales, changes, refunds, and itinerary management services. This system is typically deployed on the railway's internal private network and is directly interconnected with the core ticketing database, user identity information database, and order management system. Because railway passenger ticketing involves a large amount of users' personal information, such as names, ID numbers, and contact information, the railway passenger ticketing system has strict requirements for data security and privacy protection. At the same time, the railway passenger ticketing system needs to cope with the instantaneous high-concurrency access pressure during peak periods such as holidays, and its business request volume may increase sharply in a short period of time.

[0003] Currently, railway ticketing systems typically use local servers to handle user requests for ticket purchases, inquiries, and changes. When a user initiates a request, the local server verifies the user's identity information in the request and then calls the relevant business interfaces to complete the ticketing operation. To cope with the computing power demands during peak periods, some related technologies have introduced cloud servers. This involves migrating some computing tasks to cloud servers while maintaining the local server's core business processing capabilities, thus leveraging the cloud server's computing power to alleviate sudden load surges.

[0004] However, if business requests containing personally identifiable information are sent directly to the cloud server, this information leaves the local server, potentially leading to information leakage. Conversely, if personally identifiable information is not included in the business request, the cloud server cannot maintain the contextual continuity of multi-turn conversations.

[0005] It should be noted that the information disclosed in the background section of this application is intended only to enhance the understanding of the general background of this application, and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention

[0006] In view of this, this application provides a data processing method, apparatus, equipment and storage medium for a railway passenger ticketing system, in order to solve the problem that the protection of personal identity information and the continuity of multi-turn dialogue in the cloud cannot be simultaneously achieved in related technologies.

[0007] In a first aspect, embodiments of this application provide a data processing method for a railway passenger ticketing system, applied to a local server, the method comprising: When a business request contains personal identification information, a temporary virtual identifier corresponding to the business request is generated, and a temporary mapping relationship is established between the temporary virtual identifier and the personal identification information; The personal identification information in the business request is replaced with the temporary virtual identifier to obtain the replaced business request; The cloud server sends the replaced service request to the cloud server so that the cloud server determines the service request result containing the temporary virtual identifier based on the replaced service request; The system receives the business request result and restores the temporary virtual identifier in the business request result to the corresponding personal identity information according to the temporary mapping relationship, so as to execute the corresponding business operation.

[0008] In this embodiment, when a business request contains personal identification information, the local server generates a temporary virtual identifier corresponding to the request and establishes a temporary mapping relationship between it and the personal identification information, ensuring that the personal identification information remains on the local server and is not sent out. The replaced business request, obtained by replacing the personal identification information in the business request with the temporary virtual identifier, no longer contains any personal identification information. Therefore, when the replaced business request is sent to the cloud server, the personal identification information does not leave the local server. The cloud server determines the business request result containing the temporary virtual identifier based on the received replaced business request. Since the result carries the temporary virtual identifier, the local server, upon receiving the result, can restore the temporary virtual identifier to the corresponding personal identification information based on the previously established temporary mapping relationship, and then execute subsequent business operations. During this process, the temporary virtual identifier acts as an identity proxy for the same user in the same session, allowing the cloud server to distinguish requests from different users and maintain the contextual association between multiple rounds of dialogue for the same user without obtaining real personal identification information. Therefore, this application, while ensuring that personal identification information does not leave the local server, achieves the maintenance of the context continuity of multi-round dialogues by the cloud server, balancing data security and the utilization of cloud server computing power.

[0009] In one possible implementation, generating a temporary virtual identifier corresponding to the business request when the business request contains personally identifiable information includes: When a business request contains personal identification information, a unique identifier corresponding to the business request is determined; Based on the cryptographic hash algorithm, the unique identifier and timestamp are hashed to determine the temporary virtual identifier.

[0010] In this embodiment, a temporary virtual identifier is obtained by hashing the unique identifier and timestamp using a cryptographic hash algorithm, making it difficult for attackers to deduce the original unique identifier or timestamp from the temporary virtual identifier. Furthermore, different sessions correspond to different timestamps, resulting in the same user generating different temporary virtual identifiers in different sessions. This reduces the difficulty of cross-session user behavior correlation analysis and further enhances privacy protection.

[0011] In one possible implementation, after establishing the temporary mapping relationship between the temporary virtual identifier and the personal identification information, the method further includes: Set a time-to-live (TTL) for the temporary mapping relationship, wherein the TTL is greater than or equal to the expected duration of the service request; When the establishment time of the temporary mapping relationship is greater than or equal to the lifetime, the temporary mapping relationship is deleted.

[0012] In this embodiment, setting a time-to-live (TTL) for temporary mapping relationships and automatically deleting them after the TTL ensures that the mapping relationship is only valid for the expected duration of the business request. After this time, the mapping relationship is cleared, preventing expired sessions from restoring temporary virtual identifiers to personal identity information, thereby reducing the risk of privacy leaks caused by data residue.

[0013] In one possible implementation, after receiving the service request result, the method further includes: If no corresponding temporary mapping relationship is found based on the temporary virtual identifier in the business request result, a timeout error message is output to remind the user to re-initiate the business request.

[0014] In this embodiment, when a temporary mapping relationship cannot be found, a timeout error message is output. This prevents the local server from continuing business operations due to missing mapping information, reducing the risk of data overflow caused by mapping failure. Simultaneously, the message guides the user to re-initiate the request, triggering the establishment of a new temporary mapping relationship, thereby ensuring the normal execution of subsequent business operations.

[0015] In one possible implementation, sending the replaced service request to the cloud server includes: Obtain the real-time load metrics of the local server; When the real-time load metric exceeds a preset load threshold, the replacement service request is sent to the cloud server. When the real-time load metric does not exceed the preset load threshold, the replaced service request is handed over to the local server for processing.

[0016] In this embodiment, based on the comparison between the real-time load metric of the local server and a preset threshold, it is determined whether to send the replaced business request to the cloud server or have it processed by the local server. When the load does not exceed the threshold, the request is processed by the local server, which reduces the risk of information leakage; when the load exceeds the threshold, the request is transferred to the cloud server, which helps to alleviate the processing pressure on the local server and prevents response delays due to excessive load.

[0017] In one possible implementation, after receiving the service request result, the method further includes: A cleanup command is sent to the cloud server, which instructs the cloud server to delete the session data associated with the temporary virtual identifier.

[0018] In this embodiment, after receiving the business request result, a cleanup command is sent to the cloud server to trigger the cloud server to delete session data related to the temporary virtual identifier. This operation helps reduce the accumulation of expired session data in the cloud server, reduces the risk of information leakage that may be caused by data residue, and allows cloud server resources to be released in a timely manner, avoiding the continuous occupation of storage space by useless data.

[0019] In one possible implementation, after executing the corresponding business operation, the method further includes: Detect whether the session corresponding to the service request has ended; When the session corresponding to the service request is detected to have ended, the temporary mapping relationship is deleted.

[0020] In this embodiment, the temporary mapping relationship is deleted immediately upon detecting the end of the session, ensuring that the association between personal identification information and the temporary virtual identifier exists only during the session's validity period. The mapping relationship is not retained after the session ends, which helps reduce the possibility of privacy leaks caused by storage residue, while also freeing up local database storage resources.

[0021] In one possible implementation, sending the replaced service request to the cloud server includes: The replaced business request is sent to the cloud server through a two-way authenticated encrypted channel.

[0022] In this embodiment of the application, sending the replaced business request through a two-way authenticated encrypted channel can verify the legitimacy of the identities of both communicating parties, reduce the probability of the request being intercepted or forged by a fake server, and thus reduce the risk of information leakage and attack.

[0023] Secondly, embodiments of this application provide a data processing apparatus for a railway passenger ticketing system, comprising: The temporary virtual identifier establishment module is used to generate a temporary virtual identifier corresponding to the business request when the business request contains personal identity information, and to establish a temporary mapping relationship between the temporary virtual identifier and the personal identity information; A business request replacement module is used to replace the personal identity information in the business request with the temporary virtual identifier to obtain a replaced business request. A service request sending module is used to send the replaced service request to the cloud server, so that the cloud server determines the service request result containing the temporary virtual identifier based on the replaced service request; The business request result receiving module is used to receive the business request result and restore the temporary virtual identifier in the business request result to the corresponding personal identity information according to the temporary mapping relationship, so as to execute the corresponding business operation.

[0024] Thirdly, embodiments of this application provide an electronic device, including: processor; Memory; And a computer program, wherein the computer program is stored in the memory, the computer program including instructions that, when executed by the processor, cause the electronic device to perform the method described in any one of the first aspects.

[0025] Fourthly, embodiments of this application provide a computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device where the computer-readable storage medium is located to perform the method described in any one of the first aspects.

[0026] Understandably, the data processing device for the railway passenger ticketing system provided in the second aspect, the electronic device provided in the third aspect, and the computer-readable storage medium provided in the fourth aspect are all used to execute some or all of the methods provided in this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of this application.

[0029] Figure 2 This is a flowchart illustrating a data processing method for a railway passenger ticketing system provided in an embodiment of this application.

[0030] Figure 3 This is a schematic diagram of the architecture of a local server and a cloud server provided in an embodiment of this application.

[0031] Figure 4 This is a schematic diagram of the structure of a data processing device for a railway passenger ticketing system provided in an embodiment of this application.

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

[0033] To better understand the technical solution of this application, the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0034] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0035] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0036] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0037] See Figure 1 This is a schematic diagram illustrating an application scenario provided by an embodiment of this application. For example... Figure 1As shown, this application scenario includes a user terminal 101 and a local server 102 for the railway ticketing system. The railway ticketing system is a comprehensive business platform provided by railway transportation companies to the public for ticket sales, changes, refunds, and itinerary management services, typically deployed on a dedicated railway network. This system stores personal identification information submitted by users during registration, such as name, ID number, and contact information, as well as business data such as purchase records and itinerary orders. Users initiate business requests through user terminal 101 (e.g., mobile phone or PC), which are transmitted over the network to local server 102. Local server 102 is responsible for verifying the personal identification information in the request, querying the core ticketing database, calling relevant business interfaces to complete the purchase, change, or refund operation, and returning the processing result to user terminal 101. During peak periods such as holidays, the number of business requests initiated by user terminal 101 increases dramatically in a short period, placing significant pressure on the computing power and response speed of local server 102.

[0038] To address peak computing demands, some related technologies attempt to introduce cloud servers in addition to the local server 102, leveraging their computing power to alleviate sudden load spikes. Specifically, the local server 102 forwards some business requests to the cloud server for processing. After the cloud server completes the computation, it returns the results to the local server 102, which then feeds them back to the user terminal 101. However, this approach faces several challenges in practical application. Firstly, if the local server 102 directly sends business requests containing personal identification information to the cloud server, this information leaves the railway's internal private network, potentially leading to information leakage. Secondly, if the local server 102 does not include personal identification information in the business requests, the data received by the cloud server cannot distinguish between requests from different users, nor can it link multiple requests from the same user, making it difficult for the cloud server to maintain the contextual continuity of multi-turn conversations.

[0039] To address the aforementioned issues, in this embodiment, when a business request contains personal identification information, the local server generates a temporary virtual identifier corresponding to the request and establishes a temporary mapping relationship between it and the personal identification information. This ensures that the personal identification information remains on the local server and is not sent externally. The replaced business request, obtained by replacing the personal identification information in the business request with the temporary virtual identifier, no longer contains any personal identification information. Therefore, when sending the replaced business request to the cloud server, the personal identification information does not leave the local server. The cloud server determines the business request result containing the temporary virtual identifier based on the received replaced business request. Since this result carries the temporary virtual identifier, the local server, upon receiving the result, can restore the temporary virtual identifier to the corresponding personal identification information based on the previously established temporary mapping relationship, and then execute subsequent business operations. In this process, the temporary virtual identifier acts as an identity proxy for the same user in the same session, allowing the cloud server to distinguish requests from different users and maintain the contextual association between multiple rounds of dialogue for the same user without obtaining real personal identification information. Therefore, this application, while ensuring that personal identification information does not leave the local server, achieves the maintenance of the continuity of the context of multiple rounds of dialogue by the cloud server, balancing data security and the utilization of cloud server computing power.

[0040] Specifically, the following detailed description is provided in conjunction with the accompanying drawings and specific embodiments.

[0041] See Figure 2 This is a flowchart illustrating a data processing method for a railway passenger ticketing system provided in an embodiment of this application. This method can be applied to the application scenarios described above, such as... Figure 2 As shown, it mainly includes the following steps.

[0042] Step S201: When a business request contains personal identification information, generate a temporary virtual identifier corresponding to the business request and establish a temporary mapping relationship between the temporary virtual identifier and the personal identification information.

[0043] In practical applications, the local server first parses the received business requests and checks whether they contain personal identification information. Personal identification information refers to data that can identify a specific user, such as the user's name, ID number, and contact information.

[0044] When a business request contains personally identifiable information, the local server generates a temporary virtual identifier for that request. This temporary virtual identifier is a temporary, valid only for the current session, used to represent the user in subsequent interactions with the cloud server without exposing the original personally identifiable information.

[0045] For example, if user A initiates a ticket purchase request through a mobile application, and the request includes user A's ID number, the local server will generate a temporary virtual identifier for this request, for example, named "ID_ABC123".

[0046] After generating a temporary virtual identifier, the local server establishes a temporary mapping relationship between the temporary virtual identifier and the personal identification information in its local storage system. This mapping relationship can be recorded in the form of key-value pairs, where the temporary virtual identifier is the key and the corresponding personal identification information is the value. Continuing with the example above, the local server records the ID number of user A corresponding to "ID_ABC123" in its local database.

[0047] Understandably, the purpose of establishing a temporary mapping relationship is that when the cloud server returns a processing result containing a temporary virtual identifier, the local server can use this mapping relationship to restore the temporary virtual identifier to the real personal identity information, thereby executing the actual ticketing operations such as booking or changing tickets. Through this method, personal identity information remains always stored on the local server and is not sent to the cloud server, reducing the risk of information leakage at the source. At the same time, the temporary virtual identifier acts as a user identity proxy, allowing the cloud server to distinguish between different users' requests without obtaining the real identity information.

[0048] It should be noted that there are multiple ways to generate the above-mentioned temporary virtual identifier, and this embodiment provides a preferred generation method.

[0049] Specifically, the local server first determines a unique identifier corresponding to the service request. A unique identifier is a globally unique string that can distinguish different service requests or different sessions, such as a sequence number assigned by the local server to each session or each request. Specifically, when a user initiates a request containing personally identifiable information for the first time, the local server can generate a unique identifier bound to the user's current session, and this identifier remains unchanged throughout the entire session.

[0050] After obtaining the unique identifier, the local server retrieves the current timestamp. The timestamp can be the current system time. Subsequently, the local server performs a hash calculation on the unique identifier and the timestamp based on a cryptographic hash algorithm, using the private key as the hash key, and uses the calculated result as a temporary virtual identifier. The cryptographic hash algorithm is a one-way hash function; common algorithm types include Message Digest Algorithm Version 5 (CDP5) and the Secure Hash Algorithm series, etc., and this embodiment does not limit the specific algorithms used.

[0051] The temporary virtual identifier determined by the cryptographic hash algorithm is irreversible, meaning it is difficult to deduce the original unique identifier and timestamp from the temporary virtual identifier, thus protecting user identity information from being recovered. Furthermore, because different requests or different sessions have different timestamps, even if the same user uses the same unique identifier in two different sessions, the calculated temporary virtual identifiers will be different. This prevents the cloud server from associating requests from different sessions with the same user, further enhancing privacy protection.

[0052] The above generation method is merely an example. In practical applications, the local server can also use other methods to generate temporary virtual identifiers. For example, the local server can generate temporary virtual identifiers based on random numbers, as long as it ensures that the identifier is unique and irreversible within the current session. This application does not impose specific restrictions on this.

[0053] As described above, the local server establishes a temporary mapping relationship between a temporary virtual identifier and personal identification information. Since this temporary mapping relationship is only useful during the current session, retaining it after the session ends could lead to wasted storage resources and the risk of residual personal identification information. Therefore, this application embodiment further sets a lifespan for the temporary mapping relationship.

[0054] As you can understand, lifetime refers to the maximum duration a temporary mapping relationship is allowed to exist from the moment it is established. Typically, lifetime is set to be greater than or equal to the expected duration of the current business request. The expected duration of a business request can be estimated based on the request type; for example, the session time for a ticket purchase request from initiation to completion is estimated to be thirty minutes. The purpose of setting lifetime is to ensure that temporary mapping relationships can be deleted when the session ends.

[0055] For example, when user A initiates a ticket purchase request, the local server generates a temporary virtual identifier "ID_ABC123" for him and establishes a mapping relationship recording "ID_ABC123" corresponding to user A's ID card number. The local server also sets a ten-minute timeout for this mapping relationship. If user A completes the ticket purchase operation within ten minutes, the mapping relationship remains valid during this period; if user A's operation takes more than ten minutes, the mapping relationship will time out and expire.

[0056] When the creation time of a temporary mapping relationship is greater than or equal to its time-to-live (TTL), the local server automatically deletes the temporary mapping relationship. The deletion operation can either directly remove the record from the local database or mark it as invalid.

[0057] It should be noted that the lifetime value can be dynamically adjusted based on the business scenario. For example, for query requests with a shorter expected duration, the lifetime can be set to a shorter value; for ticket purchase requests involving multiple rounds of interaction with a longer expected duration, the lifetime can be set to a longer value. The local server can also dynamically adjust the lifetime length based on the user's historical behavior or the overall system load.

[0058] In this embodiment, setting a time-to-live (TTL) for temporary mapping relationships and automatically deleting them after the TTL ensures that the mapping relationship is only valid for the expected duration of the business request. After this time, the mapping relationship is cleared, preventing expired sessions from restoring temporary virtual identifiers to personal identity information, thereby reducing the risk of privacy leaks caused by data residue.

[0059] Step S202: Replace the personal identification information in the business request with a temporary virtual identifier to obtain the replaced business request.

[0060] In this embodiment of the application, after the generation of the temporary virtual identifier and the establishment of the temporary mapping relationship are completed, the local server replaces the personal identity information in the business request with the corresponding temporary virtual identifier to obtain the replaced business request.

[0061] For example, user A initiates a ticket purchase request. The original request includes "Name: User A" and "ID Card Number: 1234567890". The local server has already generated a temporary virtual identifier "ID_ABC123" for user A. The local server modifies the value of the "Name" field to "ID_ABC123" and also modifies the value of the "ID Card Number" field to "ID_ABC123", or replaces the entire personal identification information section with this temporary virtual identifier. After the above replacement operation, the business request no longer contains any information that can directly identify the user, but it still retains other non-sensitive information required for business operations, such as departure station, arrival station, and travel date.

[0062] Step S203: Send the replaced service request to the cloud server so that the cloud server can determine the service request result containing the temporary virtual identifier based on the replaced service request.

[0063] In this embodiment of the application, after obtaining the replaced service request, the replaced service request is sent to the cloud server so that the cloud server can determine the service request result containing the temporary virtual identifier based on the replaced service request.

[0064] Understandably, after receiving the replaced business request, the cloud server processes it. Since the replaced request does not contain any personally identifiable information, only a temporary virtual identifier and other parameters required for the business operation, the cloud server cannot determine the user's true identity. The cloud server executes the corresponding processing logic based on the business parameters in the request, such as querying train information, calculating fares, or simulating ticket booking. During processing, the cloud server needs to associate the processing result with the user who initiated the request to ensure the correct return of the result. Therefore, the cloud server extracts the temporary virtual identifier from the replaced business request and includes this identifier as the user identifier in the processing result. Finally, the cloud server generates a business request result containing this temporary virtual identifier, which also carries the business data obtained after the cloud server's processing, such as train timetables, fare information, or booking confirmation numbers.

[0065] For example, user A queries high-speed train schedules from station A to station B using a modified business request. The modified request includes a temporary virtual identifier "ID_ABC123" and parameters such as departure station, arrival station, and travel date. Upon receiving this request, the cloud server queries the ticketing database to obtain a list of train schedules that meet the criteria. The cloud server combines this list with the temporary virtual identifier "ID_ABC123" to generate the business request result. The cloud server then returns this result to the local server.

[0066] It's important to note that when generating the results of a business request, the cloud server does not need to know the mapping relationship between the temporary virtual identifier and the real user identity. The cloud server only needs to ensure that the same temporary virtual identifier is included in the returned result; the local server will then use this identifier to complete the restoration operation.

[0067] In real-world operating environments, not all business requests require the computing resources of cloud servers. When the local server's processing power is sufficient, sending requests to the cloud can actually increase network transmission overhead and cloud usage costs. Therefore, this embodiment provides a sending method that dynamically decides based on the real-time load of the local server. This method allows requests to be processed locally when the load is low, and cloud resources are only activated when the load is high.

[0068] Specifically, the local server first obtains its own real-time load metrics. When the real-time load metrics exceed a preset load threshold, it sends a replacement service request to the cloud server; when the real-time load metrics do not exceed the preset load threshold, the replacement service request is handled by the local server.

[0069] Real-time load metrics are parameters used to quantify the current workload of the local server, and can include various measurement dimensions such as CPU utilization, memory utilization, number of requests processed per second, and request queue length. The local server can obtain these metrics through interfaces provided by the operating system or by collecting them manually. Different metrics can be selected as the basis for judgment in different business scenarios, and this embodiment does not impose any restrictions on this.

[0070] The load threshold is a pre-configured value used to determine whether a local server is overloaded. For example, the load threshold can be set as a percentage of CPU utilization or as an upper limit on the request queue length. This threshold can be adjusted based on the local server's hardware configuration and business needs.

[0071] In practical applications, when the real-time load metric exceeds the preset load threshold, it indicates that the local server is currently under high load and its processing capacity may be insufficient to handle new business requests. In this case, the local server sends the replacement business request to the cloud server, which then handles the processing, thereby alleviating the pressure on the local server and reducing the risk of information leakage. When the real-time load metric does not exceed the preset load threshold, it indicates that the local server's load is within the normal range and its processing capacity is sufficient. In this case, the local server continues to process the request itself, which helps alleviate the processing pressure on the local server and prevents response delays due to excessive load.

[0072] In practical applications, although the replaced business request does not contain personally identifiable information, it still carries a temporary virtual identifier and business-related parameters. If intercepted or tampered with by a third party during transmission, the temporary virtual identifier may be leaked or used to forge requests. Therefore, one possible implementation involves sending the request through a two-way authenticated encrypted channel.

[0073] A two-way authenticated encrypted channel refers to a network connection established between two communicating parties that simultaneously possesses encrypted transmission and two-way authentication capabilities. Two-way authentication means that when establishing a connection, not only does the cloud server need to verify the identity certificate of the local server, but the local server also needs to verify the identity certificate of the cloud server, ensuring that both communicating parties are pre-authorized legitimate entities.

[0074] Understandably, sending the replaced business request through a two-way authenticated encrypted channel can verify the legitimacy of the identities of both communicating parties, reduce the probability of the request being intercepted or forged by a fake server, and thus reduce the risk of information leakage and attacks.

[0075] In addition to the certificate-based two-way authentication encrypted channel described above, this embodiment can also employ other equivalent secure transmission methods. For example, the local server and the cloud server can share a key in advance, use this key to encrypt the communication content, and thus achieve authentication through the shared key method. It is understood that regardless of the specific implementation method used, the core is to ensure the confidentiality and integrity of data during transmission and the reliability of the identities of both communicating parties.

[0076] Step S204: Receive the business request result and restore the temporary virtual identifier in the business request result to the corresponding personal identity information according to the temporary mapping relationship, so as to execute the corresponding business operation.

[0077] In this embodiment of the application, after the cloud server completes the processing and returns the business request result, the local server receives the business request result and restores the temporary virtual identifier in the business request result to the corresponding personal identity information according to the temporary mapping relationship, so as to execute the corresponding business operation.

[0078] The business request result is a data packet generated by the cloud server based on the replaced business request. This data packet contains at least two parts: the first part is a temporary virtual identifier extracted by the cloud server upon receiving the request, which is returned verbatim without any modification; the second part is the business data obtained by the cloud server after performing business processing, such as train schedule query results, fare calculation results, or ticket confirmation information. The business request result does not contain any personally identifiable information, only the temporary virtual identifier and the business data.

[0079] After receiving the business request result, the local server first extracts the temporary virtual identifier. Then, based on the previously established temporary mapping relationship, the local server searches for the personal identification information corresponding to the temporary virtual identifier in the local storage system.

[0080] After successfully retrieving the corresponding personal identification information, the local server replaces the temporary virtual identifier in the business request result with the real personal identification information. After restoration, the local server obtains a complete business result containing the real user's identity. Finally, the local server executes the corresponding business operation based on the restored business result. The type of business operation depends on the content of the original request. For example, if the original request is a ticket purchase request, the local server calls the ticketing system's booking interface to complete the ticket reservation for the user; if the original request is a query request, the local server returns the query result to the user's terminal; if the original request is a rescheduling or refund request, the local server calls the corresponding business interface to complete the operation. The specific implementation of the business operation depends on the railway passenger ticketing system's own business logic, which is not limited in this embodiment.

[0081] In actual operation, mapping relationships may be lost or expired for various reasons, such as the mapping relationship being deleted due to a user's inability to complete the operation after a long period of time. To address these situations, one possible implementation is to output a timeout error message when no corresponding temporary mapping relationship is found based on the temporary virtual identifier in the business request result, reminding the user to re-initiate the business request.

[0082] For example, user A initiated a ticket purchase request ten minutes ago. The local server generated a temporary virtual identifier "ID_ABC123" for A and set a ten-minute lifespan for it. However, for some reason, user A did not complete the ticket purchase within ten minutes, but instead submitted subsequent information ten minutes later. At this time, the business request result returned by the cloud server still carries "ID_ABC123", but the local server finds that the record has been deleted due to timeout when checking the mapping relationship. Therefore, the local server outputs "Your operation has timed out, please re-initiate the ticket purchase request" to the user's terminal.

[0083] In addition to the method of directly outputting error messages and allowing the user to retry manually, this embodiment can also be extended to other parallel schemes, and this application does not impose specific limitations on them.

[0084] Understandably, the above-mentioned exception handling mechanism outputs a timeout error message when a temporary mapping relationship cannot be found. This prevents the local server from continuing business operations due to missing mapping information, reducing the risk of data out-of-bounds errors caused by mapping failure. Simultaneously, this message guides the user to re-initiate the request, triggering the establishment of a new temporary mapping relationship, thereby ensuring the normal execution of subsequent business operations.

[0085] After completing the restore operation and business execution in step S204, the data interaction between the local server and the cloud server for the current session has ended. However, during the process of processing the replaced business requests, the cloud server may temporarily retain session data related to the temporary virtual identifier in its own storage, such as request logs, cached results, or intermediate states.

[0086] To further reduce the risk of data residue, one possible implementation involves sending a cleanup command to the cloud server after the local server receives the result of the business request. This cleanup command instructs the cloud server to delete the session data associated with the temporary virtual identity.

[0087] Besides sending cleanup commands after normal business operations have concluded, cleanup commands can also be triggered at other times. For example, when the local server detects that a temporary mapping relationship no longer exists, it can proactively send a cleanup command to the cloud server, informing the cloud server that the temporary virtual identifier has expired and suggesting that the cloud delete the relevant data. This application does not impose specific restrictions on this.

[0088] In this embodiment, after receiving the business request result, a cleanup command is sent to the cloud server to trigger the cloud server to delete session data related to the temporary virtual identifier. This operation helps reduce the accumulation of expired session data in the cloud server, reduces the risk of information leakage that may be caused by data residue, and allows cloud server resources to be released in a timely manner, avoiding the continuous occupation of storage space by useless data.

[0089] In one possible implementation, after executing the corresponding business operation, the local server checks whether the session corresponding to the current business request has ended. Session termination can be determined in several ways, such as receiving a logout signal from the user terminal, detecting a disconnection of the network connection with the user terminal, or based on a preset inactivity timeout.

[0090] For example, after a user completes a ticket purchase through a mobile application and clicks the "Exit" button, the mobile application sends a session end notification to the local server. Upon receiving this notification, the local server determines that the session has ended.

[0091] When the local server detects that the current session has ended, it immediately deletes the temporary mapping relationship corresponding to that session. The deletion operation refers to permanently removing the association record between the temporary virtual identifier and the personal identification information from the local storage system; for example, deleting the record of "ID_ABC123" corresponding to user A's ID card number from the database. This method allows for the timely release of local storage resources after the session actually ends and shortens the retention time of personal identification information on the local server, reducing the risk of privacy leaks.

[0092] In this embodiment, the temporary mapping relationship is deleted immediately upon detecting the end of the session, ensuring that the association between personal identification information and the temporary virtual identifier exists only during the session's validity period. The mapping relationship is not retained after the session ends, which helps reduce the possibility of privacy leaks caused by storage residue, while also freeing up local database storage resources.

[0093] In this embodiment, when a business request contains personal identification information, the local server generates a temporary virtual identifier corresponding to the request and establishes a temporary mapping relationship between it and the personal identification information, ensuring that the personal identification information remains on the local server and is not sent out. The replaced business request, obtained by replacing the personal identification information in the business request with the temporary virtual identifier, no longer contains any personal identification information. Therefore, when the replaced business request is sent to the cloud server, the personal identification information does not leave the local server. The cloud server determines the business request result containing the temporary virtual identifier based on the received replaced business request. Since the result carries the temporary virtual identifier, the local server, upon receiving the result, can restore the temporary virtual identifier to the corresponding personal identification information based on the previously established temporary mapping relationship, and then execute subsequent business operations. During this process, the temporary virtual identifier acts as an identity proxy for the same user in the same session, allowing the cloud server to distinguish requests from different users and maintain the contextual association between multiple rounds of dialogue for the same user without obtaining real personal identification information. Therefore, this application, while ensuring that personal identification information does not leave the local server, achieves the maintenance of the context continuity of multi-round dialogues by the cloud server, balancing data security and the utilization of cloud server computing power.

[0094] Corresponding to the above method embodiments, this application also provides an architectural diagram of a local server and a cloud server. Specifically, see... Figure 3 This figure illustrates an architecture of a local server and a cloud server provided in an embodiment of this application. As shown, the architecture includes a local server 301 and a cloud server 302, which interact with each other via a network connection.

[0095] The local server 301 further includes an access layer 3011, a data processing layer 3012, and a local inference layer 3013. The access layer 3011 is responsible for receiving service requests initiated by user terminals and performing preliminary processing. This layer specifically includes an AI gateway, which integrates multiple functional units. A protocol parsing unit parses the communication protocols used by different user terminals, converting the original requests into an internally unified format. An identity authentication unit verifies the legitimacy of the request source, such as verifying the user terminal's login token. A session identification unit determines whether the current request belongs to a new or existing session and detects whether the request contains personal identification information. A temporary virtual identifier generation unit generates a corresponding temporary virtual identifier for the new session based on the session identification result; this identifier is obtained by performing a hash calculation based on a unique identifier and a timestamp. A load metric detection unit collects various load metrics of the local server 301 in real time, such as requests per second, inference latency, or CPU utilization. The routing decision unit compares the real-time load provided by the load indicator detection unit with the preset load threshold to decide whether to send the replaced business request to the cloud server 302 or hand it over to the local inference layer 3013 for processing.

[0096] The data processing layer 3012 is responsible for storing and managing data related to user identity and business operations. This layer includes a temporary mapping relationship database, a user identity management system, a core business database, and a data management service unit. The temporary mapping relationship database stores temporary mapping relationships between temporary virtual identifiers and personal identity information. These mapping relationships have a preset lifespan and are automatically deleted after expiration. The user identity management system maintains user registration information and authentication credentials. The core business database stores ticketing operation data such as train schedules, ticket prices, and order records. The data management service unit is responsible for querying, updating, and maintaining the above databases, and provides auxiliary functions such as data encryption, backup, and cleanup.

[0097] The local inference layer 3013 is used to handle local processing of business requests when the load is low. This layer includes a local inference unit and a local knowledge base. The local inference unit is used to execute rule-based business logic or lightweight algorithm models, such as train schedule queries, fare calculations, or trip planning. The local knowledge base stores static information that can be accessed by the inference unit, such as railway line data, station information, and fare rules. After processing the request, the local inference layer 3013 returns the result to the access layer 3011, which then feeds it back to the user terminal.

[0098] The cloud server 302 includes a cloud inference layer 3021, which further comprises a cloud load balancer, cloud inference units, and an elastic scaling unit. The cloud load balancer receives replaced business requests from the local server 301 and distributes them to multiple backend cloud inference instances to achieve even request distribution and load sharing. The cloud inference unit performs actual computational tasks, such as intelligent question answering based on a large language model or complex trip planning. This unit processes requests only based on temporary virtual identifiers and business parameters, without accessing any personally identifiable information. The elastic scaling unit monitors the real-time load of the cloud inference unit, automatically increasing the number of inference instances when request volume increases and automatically decreasing the number of instances when request volume decreases, thereby achieving dynamic adjustment of computing resources.

[0099] Through the above architecture, a clearly defined collaborative working mechanism is established between the local server 301 and the cloud server 302. Personal identification information is always retained in the data processing layer 3012 and is not sent to the cloud via the access layer 3011. The cloud server 302 only processes business requests that have been replaced without personal identification information. Its calculation results, carrying a temporary virtual identifier, are returned to the local server 301, which then completes the identity restoration and final business operation. This architecture effectively resolves the conflict between personal identification information protection and cloud computing power utilization, while also enabling on-demand use of cloud resources through elastic scaling units.

[0100] Corresponding to the above embodiments, this application also provides a schematic diagram of the structure of a data processing device for a railway passenger ticketing system. Specifically, see... Figure 4 This figure shows a schematic diagram of a data processing device for a railway passenger ticketing system provided in an embodiment of this application. Specifically, the data processing device 400 for the railway passenger ticketing system includes a temporary virtual identifier creation module 401, used to generate a temporary virtual identifier corresponding to a business request when the business request contains personal identification information, and to establish a temporary mapping relationship between the temporary virtual identifier and the personal identification information; a business request replacement module 402, used to replace the personal identification information in the business request with the temporary virtual identifier to obtain a replaced business request; a business request sending module 403, used to send the replaced business request to a cloud server so that the cloud server can determine the business request result containing the temporary virtual identifier based on the replaced business request; and a business request result receiving module 404, used to receive the business request result and restore the temporary virtual identifier in the business request result to the corresponding personal identification information according to the temporary mapping relationship, so as to execute the corresponding business operation.

[0101] For details, please refer to the description in the above-described method implementation section. For the sake of brevity, this application does not impose any specific limitations.

[0102] Corresponding to the above embodiments, this application also provides a schematic diagram of the structure of an electronic device. See also Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 500 may include a processor 501, a memory 502, and a communication unit 503. These components communicate through one or more buses. Those skilled in the art will understand that the structure of the electronic device shown in the figure does not constitute a limitation on the embodiments of the present invention. It may be a bus-shaped structure or a star-shaped structure, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0103] The communication unit 503 is used to establish a communication channel, enabling the electronic device to communicate with other devices. It can receive user data sent by other devices or send user data to other devices.

[0104] The processor 501 serves as the control center of the electronic device, connecting various parts of the device via interfaces and lines. It executes software programs, instructions, and / or modules stored in the memory 502, and calls data stored in the memory to perform various functions and / or process data. The processor may be composed of integrated circuits (ICs), such as a single packaged IC or multiple packaged ICs with the same or different functions connected together. For example, the processor 501 may consist only of a central processing unit (CPU). In this embodiment, the CPU may have a single processing core or include multiple processing cores.

[0105] The memory 502 is used to store the execution instructions of the processor 501. The memory 502 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0106] When the execution instructions in memory 502 are executed by processor 501, the electronic device 500 is able to perform operations. Figure 2 Some or all of the steps in the illustrated embodiments.

[0107] In a specific implementation, this application also provides a computer storage medium, wherein the computer storage medium may store a program, and when the program is executed, it may include some or all of the steps in the various embodiments of the simulation scene generation method provided by this invention. The storage medium may be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0108] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent the existence of A alone, the simultaneous existence of A and B, or the existence of B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects have an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, and c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0109] Those skilled in the art will recognize that the units and algorithm steps described in the embodiments disclosed herein can be implemented using electronic hardware, computer software, or a combination of electronic hardware and software. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0110] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0111] In the several embodiments provided in this application, any function, if implemented as a software functional unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0112] The same or similar parts between the various embodiments in this specification can be referred to mutually. In particular, the device embodiments and terminal embodiments are basically similar to the method embodiments, so the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

Claims

1. A data processing method for a railway passenger ticketing system, characterized in that, Applied to a local server, the method includes: When a business request contains personal identification information, a temporary virtual identifier corresponding to the business request is generated, and a temporary mapping relationship is established between the temporary virtual identifier and the personal identification information; The personal identification information in the business request is replaced with the temporary virtual identifier to obtain the replaced business request; The cloud server sends the replaced service request to the cloud server so that the cloud server determines the service request result containing the temporary virtual identifier based on the replaced service request; The system receives the business request result and restores the temporary virtual identifier in the business request result to the corresponding personal identity information according to the temporary mapping relationship, so as to execute the corresponding business operation.

2. The method according to claim 1, characterized in that, When a business request contains personal identification information, generating a temporary virtual identifier corresponding to the business request includes: When a business request contains personal identification information, a unique identifier corresponding to the business request is determined; Based on the cryptographic hash algorithm, the unique identifier and timestamp are hashed to determine the temporary virtual identifier.

3. The method according to claim 1, characterized in that, After establishing the temporary mapping relationship between the temporary virtual identifier and the personal identity information, the method further includes: Set a time-to-live (TTL) for the temporary mapping relationship, wherein the TTL is greater than or equal to the expected duration of the service request; When the establishment time of the temporary mapping relationship is greater than or equal to the lifetime, the temporary mapping relationship is deleted.

4. The method according to claim 1, characterized in that, After receiving the service request result, the method further includes: If no corresponding temporary mapping relationship is found based on the temporary virtual identifier in the business request result, a timeout error message is output to remind the user to re-initiate the business request.

5. The method according to claim 1, characterized in that, Sending the replaced service request to the cloud server includes: Obtain the real-time load metrics of the local server; When the real-time load metric exceeds a preset load threshold, the replacement service request is sent to the cloud server. When the real-time load metric does not exceed the preset load threshold, the replaced service request is handed over to the local server for processing.

6. The method according to claim 1, characterized in that, After receiving the result of the service request, the process further includes: A cleanup command is sent to the cloud server, which instructs the cloud server to delete the session data associated with the temporary virtual identifier.

7. The method according to claim 1, characterized in that, After executing the corresponding business operation, the process also includes: Detect whether the session corresponding to the service request has ended; When the session corresponding to the service request is detected to have ended, the temporary mapping relationship is deleted.

8. The method according to claim 1, characterized in that, Sending the replaced service request to the cloud server includes: The replaced business request is sent to the cloud server through a two-way authenticated encrypted channel.

9. A data processing device for a railway passenger ticketing system, characterized in that, include: The temporary virtual identifier establishment module is used to generate a temporary virtual identifier corresponding to the business request when the business request contains personal identity information, and to establish a temporary mapping relationship between the temporary virtual identifier and the personal identity information; A business request replacement module is used to replace the personal identity information in the business request with the temporary virtual identifier to obtain a replaced business request. A service request sending module is used to send the replaced service request to the cloud server, so that the cloud server determines the service request result containing the temporary virtual identifier based on the replaced service request; The business request result receiving module is used to receive the business request result and restore the temporary virtual identifier in the business request result to the corresponding personal identity information according to the temporary mapping relationship, so as to execute the corresponding business operation.

10. An electronic device, characterized in that, include: processor; Memory; And a computer program, wherein the computer program is stored in the memory, the computer program including instructions that, when executed by the processor, cause the electronic device to perform the method of any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform the method according to any one of claims 1 to 8.

Images