A method, system, and storage medium for processing flight passenger reservation data.

Abstract

This application provides a method, system, and storage medium for processing flight passenger reservation data, relating to the field of communication technology. The method includes: acquiring passenger order data, the passenger order data including an order identifier and a version identifier; acquiring exclusive processing permissions corresponding to the passenger order data based on the order identifier; if the exclusive processing permissions are obtained, comparing the version identifier with a stored version identifier to obtain a comparison result; and processing the passenger order data based on the comparison result to generate business data.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method, system and storage medium for processing flight passenger reservation data. Background Technology

[0002] In the civil aviation passenger transport sector, passenger seat reservation (seat selection) service is a key link in improving user experience and operational efficiency. Among related technologies, airline seat reservation systems typically adopt a distributed architecture, and their request sources are complex and diverse: on the one hand, passengers can directly access the seat management subsystem (such as the SEAT subsystem) to select seats through modern interfaces such as airline official websites and mobile applications; on the other hand, a large number of requests still access the host platform (such as a mainframe system) through traditional ticketing channels (such as travel agency terminals and call centers), and then the host platform calls the seat management subsystem to complete the seat reservation.

[0003] When control of the seating chart switches between the subsystem and the host platform, the host platform and the seating management subsystem may each process requests from different channels based on outdated seating status data. This can lead to data conflicts such as "multiple occupancy of a seat". Summary of the Invention

[0004] This application provides a method, system, and storage medium for processing flight passenger reservation data, which enables the generated civil aviation reports to be not only accurate and logically rigorous, but also strictly compliant with industry standards, significantly improving the reliability and practicality of the reports.

[0005] To achieve the above objectives, this application adopts the following technical solution: In a first aspect, this application provides a method for processing flight passenger reservation data. The method includes: acquiring passenger order data, which includes an order identifier and a version identifier; acquiring exclusive processing rights corresponding to the passenger order data based on the order identifier; comparing the version identifier with a stored version identifier to obtain a comparison result after acquiring exclusive processing rights; and processing the passenger order data based on the comparison result to generate business data.

[0006] In one possible implementation, passenger order data is processed based on the comparison results to generate business data, including: in response to the version identifier being updated to the stored version identifier, sensitive information in the passenger order data is desensitized, and business data is generated.

[0007] In one possible implementation, the method further includes: updating cached data in a cache database based on business data, the cached data being used to respond to real-time query requests for order identifiers.

[0008] In one possible implementation, the method further includes: in response to the version identifier not being updated to the stored version identifier, discarding the passenger order data and releasing exclusive processing rights.

[0009] In one possible implementation, the version identifier includes at least one of the following: timestamp; serial number.

[0010] In one possible implementation, the method further includes: synchronizing frequently queried fields in passenger order data to a search engine to create an index, and / or redundantly storing multiple business fields under the same order identifier in a business table.

[0011] In one possible implementation, the method further includes: periodically migrating business data that meets preset inactive conditions from the cache database to the archive database, and cleaning up the cache data and index data associated with the migrated business data.

[0012] In one possible implementation, exclusive processing permissions are achieved through a data access middleware located between the business system and the cache database. The data access middleware is configured to encrypt sensitive information in passenger order data written to the cache database and decrypt query results.

[0013] Exclusive processing permissions can be implemented using processing tokens, which are digital credentials used in a distributed system to identify that the current service instance has obtained unique authorization to operate on passenger order data. Secondly, a flight passenger reservation data processing system is provided. The system includes: an acquisition module for acquiring passenger order data, which includes an order identifier and a version identifier; a processing module for acquiring exclusive processing permissions corresponding to the passenger order data based on the order identifier; the processing module is further used to compare the version identifier with a stored version identifier after acquiring exclusive processing permissions to obtain a comparison result; and the processing module is further used to process the passenger order data based on the comparison result to generate business data.

[0014] The technical effects of any implementation method in the second aspect can be found in the technical effects of any implementation method in the first aspect mentioned above, and will not be repeated here.

[0015] Thirdly, a computer device is provided, comprising: a processor and a memory, wherein the memory stores at least one computer program, and the at least one computer program is loaded and executed by the processor to implement the above-mentioned report generation method for civil aviation operations.

[0016] Fourthly, a computer-readable storage medium is provided, wherein at least one computer program is stored in the computer-readable storage medium, and the at least one computer program is loaded and executed by a processor to implement the above-mentioned report generation method for civil aviation operations.

[0017] Fifthly, a computer program product is provided, comprising a computer program or instructions, which, when executed by a processor, implement the above-mentioned report generation method for civil aviation operations.

[0018] The solutions provided in aspects three through five above are used to implement the method provided in aspect one above, and their specific implementations will not be described in detail here. The technical effects corresponding to any implementation method of the solutions provided in aspects three through five above can be found in the technical effects corresponding to any implementation method in aspect one above, and will not be described in detail here.

[0019] It should be noted that any of the possible implementations of any of the above aspects can be combined, provided that the solutions do not contradict each other.

[0020] The technical solution provided in this application brings at least the following beneficial effects: the system acquires passenger order data containing order identifiers and version identifiers, and obtains exclusive processing permissions based on the order identifiers, effectively preventing concurrent operation conflicts on the same order and ensuring the orderliness of the data processing process; after obtaining permissions, by comparing the version identifier with the stored version identifiers, outdated or duplicate data is automatically identified and filtered, ensuring the timeliness and accuracy of the data status; finally, the order data is processed based on the comparison results to generate business data, thereby improving the overall reliability and consistency of data processing, avoiding data corruption, and optimizing the efficiency of system resource utilization. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the structure of a data processing system provided in an embodiment of this application; Figure 2 This is a schematic diagram of another data processing system provided in an embodiment of this application; Figure 3 A flowchart illustrating a method for processing flight passenger reservation data, provided as an embodiment of this application; Figure 4 A schematic diagram illustrating a method for processing flight passenger reservation data provided in an embodiment of this application; Figure 5 A schematic diagram illustrating another method for processing flight passenger reservation data provided in this application embodiment; Figure 6 A schematic diagram illustrating another method for processing flight passenger reservation data provided in this application embodiment; Figure 7 A schematic diagram illustrating another method for processing flight passenger reservation data provided in this application embodiment; Figure 8 A schematic diagram illustrating another method for processing flight passenger reservation data provided in this application embodiment; Figure 9 A flowchart illustrating another method for processing flight passenger reservation data provided in this application embodiment; Figure 10 A flowchart illustrating another method for processing flight passenger reservation data provided in this application embodiment; Figure 11 An archiving flowchart is provided for an embodiment of this application; Figure 12 A schematic diagram illustrating another method for processing flight passenger reservation data provided in this application embodiment; Figure 13 A schematic diagram illustrating another method for processing flight passenger reservation data provided in this application embodiment; Figure 14 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application; Figure 15 This is a schematic diagram of another data processing system provided in an embodiment of this application. Detailed Implementation

[0022] In the embodiments of this application, in order to clearly describe the technical solutions of the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" are not necessarily different. The technical features described by "first" and "second" have no sequential or size order.

[0023] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner to facilitate understanding.

[0024] In the embodiments of this application, at least one can also be described as one or more, and multiple can be two, three, four or more, and this application does not impose any restrictions.

[0025] Furthermore, the network architecture and scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0026] To facilitate understanding of the embodiments of this application, the terms are explained.

[0027] 1. RocketMQ, a distributed message queue system, is used to decouple data receiving and processing processes, support high-throughput message passing, and ensure the system's asynchronous communication capabilities.

[0028] 2. Memory-level NoSQL database (Redis), used here for distributed locks: controlling the concurrent processing order of the same PNR; short-term cache: storing the latest PNR state to accelerate repeated queries.

[0029] 3. Order Database: A business database designed according to the PNR group dimension, which is different from the traditional order-based (PSS) structure and supports the aggregated management of multiple orders under the same PNR.

[0030] 4. Raw messages: Unprocessed raw data messages sent by external systems are stored in full to support data traceability and auditing.

[0031] 5. The search engine platform (Solr) is used to index key PNR data and achieve millisecond-level complex query response.

[0032] 6. Wide table: A denormalized design that redundantly combines multiple PNR-related fields into a single table, trading space for time and simplifying query logic.

[0033] 7. Desensitization: Sensitive information (such as passenger names and ID numbers) is anonymized to protect data privacy.

[0034] 8. Passenger Name Record (PNR) is a unique number containing complete booking information such as flight, passenger, and contact information.

[0035] 9. The Retrieve command in the CRS / GDS system is used to query PNR details and requires high real-time performance.

[0036] 10. ML command (Manifest List0, used to extract the passenger list of a flight, commonly used in check-in and load control scenarios).

[0037] 11. Asynchronous data import: Upon receiving data, a success response is returned immediately, and subsequent processing (such as parsing and storage) is completed asynchronously in the background, improving system response speed.

[0038] 12. Distributed locks are locking mechanisms that span multiple processes / servers to ensure that shared resources (such as PNR data) are accessed serially in a distributed environment.

[0039] 13. Short-term caching: Set a caching strategy with a shorter TTL (Time To Live) to balance query performance and data real-time performance, mainly to deal with high-frequency repetitive query scenarios.

[0040] 14. IPNRH data, the data source for PNR, is PNR data packets that are periodically packaged and sent by the travel information system.

[0041] 15. Order is irrelevant; message reception is not strictly ordered and out-of-order writing is allowed. The order is subsequently corrected through business logic (Redis locks + timestamps).

[0042] 16. Timestamp comparison: By comparing the timestamps (sequence numbers) of messages, expired messages are discarded to ensure that the final state is consistent with the latest changes, thus achieving eventual consistency.

[0043] In the civil aviation passenger transport sector, passenger seat reservation (seat selection) service is a key link in improving user experience and operational efficiency. Currently, airline seat reservation systems typically adopt a distributed architecture, and their request sources are complex and diverse: on the one hand, passengers can directly access the seat management subsystem (such as the SEAT subsystem) to select seats through modern interfaces such as airline official websites and mobile applications; on the other hand, a large number of requests still access the host platform (such as mainframe systems) through traditional ticketing channels (such as travel agency terminals and call centers), and then the host platform calls the seat management subsystem to complete the seat reservation.

[0044] This hybrid architecture exposes a serious technical problem in actual operation: the risk of inconsistency in seat data between the host platform and the seat management subsystem, which can easily lead to conflicts such as "multiple occupancy of a seat." Specifically, when the seat map for a flight is initially controlled by the seat management subsystem, if a passenger successfully selects a seat through a direct interface, control of the seat map temporarily switches back to the host platform. However, at the moment of or after this control switch, the existing system lacks an effective data synchronization and conflict detection mechanism. The host platform may not be able to promptly and accurately detect changes in seat status that have occurred in the seat management subsystem during this period, and vice versa.

[0045] The main platform might process new booking requests from traditional channels based on an "outdated" seating chart and reallocate already occupied seats; while the seat management subsystem continues to process requests from direct channels. Because the existing system cannot effectively and globally consistent control access to the same seat resource (i.e., shared data) in a distributed environment, nor can it determine whether the data version on which the request is based is up-to-date, two independent system processes may simultaneously and successfully book the same seat, causing data conflicts.

[0046] Such conflicts involving multiple passengers occupying the same seat are often difficult to detect immediately afterward, and usually only come to light during check-in, which can easily lead to passenger disputes.

[0047] Based on this, this application provides a method for processing flight passenger reservation data. The solutions provided by the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0048] The solution provided in this application can be applied to Figure 1 In the data processing system shown, such as Figure 1 The diagram shows the structure of a data processing system.

[0049] For example, Figure 1 The data processing system shown for civil aviation operations includes an acquisition module 101 and a processing module 102.

[0050] In some embodiments, the acquisition module 101 is used to acquire passenger order data, which includes an order identifier and a version identifier.

[0051] For example, the acquisition module 101 specifically includes a message listening unit, a message parsing unit, and an asynchronous storage unit. The message listening unit continuously listens to the message queue, receiving raw Instant Passenger Name Record History (IPNRH) data packets pushed from an external reservation system in real time. The message parsing unit parses the received raw packets, extracting key business fields, primarily including the Passenger Name Record (PNR) number as the order identifier, and the timestamp or sequence number inherent in the packet as the version identifier. The asynchronous storage unit writes the entire raw packet before parsing to the raw packet database for persistent archiving. This process does not wait for business processing results and immediately returns a successful reception response, thereby supporting high-concurrency transaction processing (Transactions Per Second, TPS) of over 10,000 per second, meeting the message processing needs during peak periods in the aviation industry.

[0052] In some embodiments, the processing module 102 is used to obtain exclusive processing permission corresponding to passenger order data based on the order identifier, and when the exclusive processing permission is obtained, compare the version identifier with the stored version identifier to obtain the comparison result, and then process the passenger order data based on the comparison result to generate business data.

[0053] For example, the processing module 102 specifically includes a distributed lock management unit, a version comparison unit, and a business processing unit. The distributed lock management unit requests a distributed lock for the parsed PNR from the cache database based on that PNR. Exclusive processing permissions are implemented through this distributed lock, ensuring that only one processing thread can perform an update operation on data with the same PNR at any given time, thereby resolving concurrent write conflicts.

[0054] After successfully acquiring the lock, the version comparison unit executes the "discard if later" logic: it queries Redis for the latest version identifier of the PNR record (e.g., the timestamp of the most recently processed message) and compares it with the version identifier of the current message. If the current version identifier is later (e.g., a larger timestamp value), subsequent processing continues; otherwise, it is determined to be an expired duplicate message, discarded directly, and the lock is released. The business processing unit performs business logic processing on the messages that pass the comparison, including de-identifying sensitive personal information such as passenger names, ID numbers, and contact information (e.g., retaining only the surname and partially obscuring the ID number) or encrypting it using encryption algorithms. Finally, it generates standardized, queryable business data records and persists them to the business database. After processing, the business processing unit updates the latest version identifier of the PNR in Redis to the current value and releases the distributed lock.

[0055] In some embodiments, the data processing system further includes a performance optimization module 103, which is used to update short-term cached data in the cache database based on business data; and to synchronize business data to a search engine or a denormalized business wide table.

[0056] For example, the performance optimization module 103 specifically includes a cache management unit and an index building unit. After the business data is generated, the cache management unit immediately writes the latest status of the current PNR (such as key query fields such as flight number, seat number, and de-identified passenger name information) into the Redis cache and sets a time-to-live to cope with high-frequency, real-time queries (such as RT command queries) in scenarios such as check-in and boarding gate.

[0057] The index building unit simultaneously synchronizes queryable fields from business data (such as PNR number, flight number, date, passenger surname, etc.) to the search engine to create inverted indexes, supporting complex multi-condition combined queries with millisecond-level response times. Alternatively, it can redundantly combine related data into a denormalized wide business table, simplifying queries that originally required multi-table joins into single-table queries, greatly improving the efficiency of operations personnel in retrieving and analyzing reservation data. In addition, this module is also responsible for periodically migrating infrequently accessed "cold data" from the main business database to the archive database, achieving separation of hot and cold data for cost management.

[0058] In some embodiments, the data processing system further includes a security encryption module 104, which is deployed in the form of a data access middleware and configured to automatically desensitize and encrypt sensitive business data written to the business database, and automatically decrypt data returned by application queries.

[0059] For example, the security encryption module 104 can be implemented using an open-source distributed database middleware. This module is configured between the application and the business database. On the data write path, the middleware encrypts plaintext sensitive data (such as passenger phone numbers) sent by the application in real time before it is entered into the database; the ciphertext is stored in the ciphertext column of the database. Simultaneously, according to the configured policy, plaintext or a specific de-identified format (such as 138) can be used to encrypt the data. 1234) Stored in plaintext columns or auxiliary query columns to support certain specific query scenarios.

[0060] On the data query path, when an application initiates a query, the middleware automatically parses the SQL: for queries using encrypted fields as conditions, the condition values ​​are first encrypted and then compared with the ciphertext columns; for the result set, the ciphertext data is automatically decrypted and returned to the application in plaintext form. This process is transparent to the application, achieving decoupling of data storage security from business logic. Simultaneously, this configuration supports a smooth migration of existing plaintext data to encrypted data, and encryption rules, algorithms, and keys can be uniformly managed through a configuration center (such as Nacos), effectively separating data ownership from storage management rights (DBAs can only access ciphertext).

[0061] Figure 2 This is a schematic diagram of another data processing system provided in an embodiment of this application. This data processing system is a hierarchical distributed system.

[0062] In some embodiments, the data processing system includes a presentation layer, an application layer, a data layer, and a support layer. This approach allows each layer to be developed, deployed, and scaled independently, providing core infrastructure to address the challenges of processing massive, real-time data related to civil aviation bookings. Data flows from top to bottom (from user requests to data persistence), while control flow and support services are primarily provided by the support layer on the right.

[0063] For example, the presentation layer includes a Keepalived virtual IP and an Nginx frontend project. There are two Nginx frontend projects. Specifically, Keepalived uses the virtual IP to implement master-slave or load balancing between the two Nginx servers. A unified access point (VIP) is provided externally. When one Nginx server fails, the VIP automatically migrates to the other, ensuring uninterrupted service. Nginx acts as a reverse proxy and web server, receiving all client requests (such as websites and apps) and distributing them evenly to the backend application layer services.

[0064] It should be understood that the presentation layer is the first line of defense for the system in the face of high-concurrency traffic. By distributing the pressure through load balancing, it is the foundation for supporting asynchronous reception and high throughput.

[0065] In some embodiments, the application layer includes multiple data transformation programs and multiple application management programs, such as... Figure 2 Data conversion program 1, data conversion program 2, data conversion program 3; application management program 1, application management program 2, application management program 3.

[0066] This application layer is used to listen to the message queue, parse the raw PNR message, perform version comparison, acquire a distributed lock (from Redis), perform data anonymization / transformation, and write the processed business data to OceanBase. Its multi-instance (N) deployment is specifically designed to handle high-concurrency data streams. It should be understood that the data transformation program corresponds to an asynchronous reception, sequential processing, and consistency-guaranteed workflow; the interaction between the application management program and the cache / search engine corresponds to multi-level query optimization.

[0067] In some embodiments, the data layer includes a distributed relational database, a cache database, a search engine, and file objects. The distributed relational database serves as the main business database, used for persistent storage of processed, structured PNR business data. It meets ACID requirements, guaranteeing eventual data consistency.

[0068] The cache database is used as an implementer of distributed locks (coordinating concurrent processing of the same PNR), and also as a short-term cache to store hot PNR data and support millisecond-level real-time queries.

[0069] The search engine uses an index to store PNR data, which supports complex multi-condition, full-text search queries, transforming complex join queries in the database into efficient index queries.

[0070] File objects are used to store raw, unparsed message files (such as IPNRH messages) to enable full data traceability and auditing, i.e., the raw message library.

[0071] The support layer includes log monitoring, task scheduling, and a registry center. Specifically, task scheduling is used to execute scheduled tasks, such as the PNR data active and inactive data isolation process (cold data archiving), and periodic data comparison tasks.

[0072] Figure 3 This is a flowchart illustrating a method for processing flight passenger reservation data, provided as an embodiment of this application. This method is applied to... Figure 1 The data processing system in China.

[0073] like Figure 3 As shown in the embodiments of this application, a method for processing flight passenger reservation data is provided, which may include: Step S201: Obtain passenger order data.

[0074] Passenger order data includes order identifiers and version identifiers.

[0075] In this embodiment of the application, the order identifier includes a number used to uniquely identify the complete reservation request, preferably a Passenger Name Record (PNR), such as "H3K8M2" consisting of 6 alphanumeric characters; it may also include an internal airline order number or an order identifier from a third-party distribution system.

[0076] For example, such as Figure 4 As shown, external data includes IPNRH data packets and message queues (such as RocketMQ). The data processing program pulls messages from the message queue, i.e., receives MQ messages (regardless of order). After the listening program receives the message, it asynchronously stores the raw message in the database and transmits the message data to the conversion program. The conversion program parses the message to obtain the order identifier and version identifier from the passenger order data.

[0077] For example, Figure 5 As shown, message reception archives the original message (with timestamp) to support business auditing and fault tracing. In the event of an abnormal conversion process, the message MQ is restarted and resumed.

[0078] Specifically, when the system receives an IPNRH data packet from TravelSky via the message queue, the parsing module extracts the core PNR number from the packet header or predefined fields as the master order identifier. For example, PNR: H3K8M2 is parsed from a standard packet.

[0079] Version identifiers include, but are not limited to, timestamps and sequence numbers. The timestamp is preferably Coordinated Universal Time (UTC) with high precision (e.g., milliseconds), such as 2024-01-29 10:00:00.001, to accurately identify the time when data changes occurred. The sequence number is a monotonically increasing globally unique number, for example, starting at 1001 and incrementing by 1 with each change. Its uniqueness and monotony are guaranteed by a sequence number generator (such as a database sequence or Redis atomic operation). Furthermore, version identifiers can also employ more advanced distributed system timing identifier schemes such as Hybrid Logical Clock (HLC).

[0080] In some embodiments, the order identifier and version identifier are stored in specific fields of the received original message and persisted in the original message library (such as object storage or NoSQL database) after parsing for audit traceability. Meanwhile, the latest effective version identifier is cached in a cache database (such as Redis), with the key being the order identifier (such as PNR:H3K8M2) and the value being the latest version identifier, for quick comparison of subsequent messages.

[0081] For example, the complete passenger order data cached in Redis can be represented as key-value pairs: the key is pnr:H3K8M2, and its corresponding value can be a hash containing fields such as latest_version: 2024-01-29 10:00:00.001 or latest_sequence: 1500, used to record the latest status identifier of the PNR. When a new PNR data packet with the same name arrives, the processing module will first query this cache to perform version comparison logic.

[0082] In addition, such as Figure 6 As shown, the receiving program is only responsible for receiving and consuming MQ messages and writing them to the database, while the conversion program is responsible for business processing. The two run asynchronously to avoid message backlog caused by processing delays. The original message writing does not need to wait for the business processing to complete, which can support high-concurrency scenarios with tens of thousands of TPS, which is in line with the high-frequency message characteristics of the aviation industry.

[0083] Step S202: Obtain exclusive processing permissions corresponding to passenger order data based on the order identifier.

[0084] In some embodiments, exclusive processing permissions are implemented through a data access middleware located between the business system and the cache database. The data access middleware is configured to encrypt sensitive information in passenger order data written to the cache database and decrypt query results.

[0085] For example, the data access middleware establishes a transparent and secure channel between the business system and the cached database (such as Redis). When a process needs to acquire exclusive permissions, the data access middleware caches the database to execute operation commands, such as `SET resource_key token NX PX 30000`. In this command, `resource_key` is a unique key generated from an order identifier (such as PNR number "ABC123"); `token` is a globally unique randomly generated value used as a processing token; the `NX` (Not eXists) parameter ensures that the setting succeeds only if the key does not exist, thus achieving mutual exclusion; `PX 30000` sets an automatic expiration time of 30 seconds to prevent permanent deadlocks caused by program exceptions.

[0086] This application embodiment achieves distributed coordination of exclusive processing permissions in this way. Simultaneously, before writing any data containing sensitive information (such as passenger ID numbers) into the cache, the data access middleware automatically encrypts it using a configured encryption algorithm (such as the national standard SM4 algorithm), and automatically decrypts it when data is retrieved from the cache, making it completely transparent to the application and achieving a "usable but invisible" data security effect.

[0087] In some embodiments, exclusive processing rights are specifically manifested as processing tokens, which are digital credentials used in a distributed system to identify that the current service instance has obtained unique authorization to operate on passenger order data.

[0088] For example, the processing token is a data object with a specific data structure, containing at least the following fields: (1) instance_id: application instance identifier, uniquely identifying the service instance currently granted permission (e.g., IP address "192.168.1.10:8080" combined with container ID); (2) timestamp: timestamp, recording the token issuance time (e.g., "2024-01-30T10:00:00Z"); (3) ttl: time to live, defining the token's validity period (e.g., 30000 milliseconds); (4) signature: digital signature, a digest obtained by hashing the aforementioned fields using a key (e.g., SHA-256), used to prevent the token from being tampered with.

[0089] In one scenario, when service instance A needs to process an order with the order identifier "ABC123", the processing token that can be successfully obtained might be {"resource": "lock:PNR:ABC123", "instance": "192.168.1.10:8080", "timestamp": 1738224000000, "ttl": 30000, "signature": "a1b2c3..."}. In all subsequent operations targeting this PNR, service instance A must include this token in the request. The cache database will verify the validity of the token and the identity of the holder, ensuring that only the token holder can perform modification operations, thereby achieving strict exclusivity control.

[0090] Step S203: With exclusive processing permission obtained, compare the version identifier with the stored version identifier to obtain the comparison result.

[0091] For example, taking the version identifier as the timestamp, after the processing service obtains the distributed lock for the PNR number "ABC123", it first parses the timestamp T_current (such as 2024-01-30T10:00:05.123Z) from the currently processed order data, and then queries the cache database for the latest stored timestamp T_stored corresponding to the PNR number.

[0092] It should be understood that the comparison logic follows the "process if later" principle: if T_current is later than T_stored (i.e., T_current > T_stored), it is considered a valid update, and the subsequent processing continues, atomically updating the timestamp in Redis to T_current (using the SET PNR:ABC123:timestamp T_current command); if T_current is earlier than or equal to T_stored, it is considered an expired or duplicate message, immediately releasing the distributed lock and discarding the current message. This mechanism leverages the monotonically increasing characteristic of physical time, logically ensuring the forward evolution of data state and effectively solving the message out-of-order problem that may be caused by network latency or node clock differences. For example, Figure 7 As shown, messages are filtered by timestamps to ensure that the final database state is consistent with the latest PNR change. Because this application uses a distributed lock, it ensures that only one thread can process the same data at any given time. This completely solves the data race and update overwriting problems that can result from multiple concurrent requests. Regardless of the message arrival order, the processing order is controllable and ordered. Ordered message updates are written to one or more backend databases (eventually consistent).

[0093] It should be understood that because distributed locks guarantee the seriality of update operations themselves, and each update is based on the latest state, all databases will eventually receive the same sequence of updates and converge to the same final state.

[0094] Another example, using version identifiers as sequence numbers, when the system uses globally monotonically increasing sequence numbers as version identifiers, the comparison logic is based on numerical comparison. After acquiring the lock, the processing service retrieves the current sequence number S_current (e.g., 1672531200001) from the message, and simultaneously retrieves the latest recorded sequence number S_stored (e.g., 1672531200000) from Redis. Due to the global uniqueness and monotonically increasing nature of the sequence number, the comparison rule simplifies to numerical comparison: if S_current is greater than S_stored (i.e., S_current > S_stored), it indicates that the current message represents an updated business state, and the system will process the message and update the sequence number in Redis; if S_current is less than or equal to S_stored, it indicates that the message is outdated or a duplicate message, and the system will discard the message. This scheme does not rely on a physical clock, guarantees order through logical sequence numbers, and is particularly suitable for distributed system environments, effectively avoiding clock rollback or cross-node time synchronization issues. The generation of serial numbers can rely on distributed sequence generation services (such as database sequences, Redis atomic operation INCR) to ensure global uniqueness and monotonicity.

[0095] Step S204: Process passenger order data based on the comparison results to generate business data.

[0096] In some embodiments, in response to the version identifier being updated to a stored version identifier, sensitive information in the passenger order data is de-identified, and business data is generated.

[0097] For example, when the system confirms that the current message version identifier (e.g., timestamp 2024-01-30T10:00:05.123Z) is newer than the stored version identifier, it initiates the data masking pipeline processing. In specific implementation, the system calls the data masking engine to transform sensitive fields in the original order data according to predefined masking rules: for the passenger name field "Zhang Sanfeng", the "retain first and last characters" rule is used to mask it as "Zhang Feng"; for the mobile phone number "13800138000", the "mask the middle four digits" rule is used to mask it as "138". For the ID number "110101199001011234", the SHA-256 hash algorithm is used to generate an irreversible ciphertext digest "5d6e8f...b9a2c1". Simultaneously, the original ID number is encrypted using the national cryptographic standard SM4 algorithm through the encryption module of a data access middleware (such as ShardingSphere). After processing, the system generates a standardized business data object, which contains anonymized display data, encrypted ciphertext data, and related metadata such as flight information and order status, forming a complete queryable business entity.

[0098] For example, Figure 8 As shown, passenger order data is irreversibly encrypted (hash storage) and anonymized (source control + short-term caching) to ensure secure storage and use. In other words, combining... Figure 4 As shown, passenger order data is saved to the PNR order database.

[0099] Furthermore, the cached data in the cache database is updated based on business data, and the cached data is used to respond to real-time query requests for order identifiers.

[0100] For example, after the business data is generated, the system immediately performs a cache update operation. Taking the aforementioned PNR number "ABC123" as an example, the system constructs the key query fields in the business data into a cache data structure and writes it to a hash table using the Redis HSET command: Executing HSET pnr:ABC123 passenger_name "Zhang Feng "phone "138 The cached record, "flight "CA1234" status "CONFIRMED", is set to 8000, and its time-to-live (TTL) is set to 300 seconds via the EXPIRE command. This cached record can be immediately used to respond to high-frequency real-time queries (such as RT command queries) in scenarios such as check-in counters and boarding gates. During queries, the cached, de-identified data is directly returned, ensuring both query performance (response time < 10 milliseconds) and meeting privacy protection requirements. The cache update operation and the database write operation together constitute a dual-write strategy, and data consistency is ensured through an exception rollback mechanism.

[0101] In addition, if the version identifier is not updated to the stored version identifier, the passenger order data is discarded and exclusive processing rights are released.

[0102] For example, when the system detects that the current message version identifier (e.g., sequence number 1005) is not greater than the stored latest version identifier (e.g., sequence number 1006), it triggers a message discarding process. The system first records an audit log of the discarding operation, including key information such as the discard reason "version identifier expired," the PNR number "ABC123," and a timestamp. Then, resource cleanup is performed: the corresponding distributed lock key is deleted using the Redis DEL command (e.g., DEL lock:PNR:ABC123), ensuring the lock resource is released immediately. Simultaneously, the monitoring system collects statistical metrics for such discarding events (e.g., discard rate, version difference distribution), providing data support for system optimization. This mechanism effectively avoids resource waste caused by duplicate processing and ensures system throughput by quickly releasing lock resources, achieving efficient filtering of invalid messages.

[0103] Based on this, the system acquires passenger order data containing order identifiers and version identifiers, and obtains exclusive processing permissions based on the order identifiers, effectively preventing concurrent operation conflicts on the same order and ensuring the orderliness of the data processing process. After obtaining permissions, the system automatically identifies and filters outdated or duplicate data by comparing the version identifier with stored version identifiers, ensuring the timeliness and accuracy of the data status. Finally, the system processes the order data based on the comparison results to generate business data, thereby improving the overall reliability and consistency of data processing, avoiding data corruption, and optimizing the efficiency of system resource utilization.

[0104] In some embodiments, such as Figure 9 As shown in the embodiment of this application, the flight passenger reservation data processing method further includes the following step S301.

[0105] S301. Synchronize frequently queried fields in passenger order data to the search engine to create an index, and / or redundantly store multiple business fields under the same order identifier in the business table.

[0106] For example, synchronization is achieved near real-time through message queues or database change data capture (CDC) technology. The system first extracts frequently queried fields from successfully processed business data to build an index document. These fields include: PNR number for exact queries (e.g., "H3K8M2"), flight number (e.g., "CA1234") and flight date (e.g., "2024-01-30") for flight-level queries, passenger surname pinyin (e.g., "ZHANG") and the last four digits of ID number (e.g., "1234") for passenger-level queries, order status (e.g., "confirmed"), and last update timestamp. This document is then pushed to a search engine (e.g., Elasticsearch) to build an inverted index. Simultaneously, to optimize complex join queries, the system redundantly merges business fields (e.g., passenger basic information, flight segment information, contact information) scattered across multiple normalized tables into a denormalized pnr_wide_table business wide table. This wide table contains 30+ fields, where the search_key is a composite index (PNR number + flight date). For example, a query with the condition "find all PNRs of passengers with the surname Zhang on flight CA1234 on January 30, 2024" can be completed directly on the wide table through a single-table index scan, reducing the query time from 200ms in the original multi-table join to less than 20ms, improving query efficiency by 10 times.

[0107] For example, combining Figure 4 As shown, key data is synchronized to the search engine for easy querying.

[0108] In addition, such as Figure 4 As shown, embodiments of this application also include updating cached data in the cache database based on business data, the cached data being used to respond to real-time query requests for order identifiers.

[0109] In some embodiments, such as Figure 10 As shown, the flight passenger reservation data processing method provided in this application embodiment also includes processing inactive data, as detailed in steps S401-S402.

[0110] Step S401: Periodically migrate business data that meets the preset inactive conditions in the cache database to the archive database.

[0111] Exemplarily, the system configures a scheduled task through a distributed task scheduling framework (such as XXL-JOB) to execute the data archiving process at 2:00 am every day. The inactive conditions are defined through SQL query conditions. For example, WHERE last_update_time < CURRENT_DATE - INTERVAL 180 DAY (the last update time is earlier than 180 days before the current date) and order_status IN ('Used', 'Canceled') (the order status is Used or Canceled). The migration process adopts a batch processing mechanism, processing 1000 records in each batch. First, insert data into the archive database by INSERT INTO archive_db.pnr_history SELECT FROM live_db.pnr WHERE... Then delete the data in the original table by DELETE FROM live_db.pnr WHERE id IN (...), and set an interval of 100 milliseconds between each batch to avoid performance impact on online services. The archive database uses a compressed storage engine, reducing the storage cost by 70%. At the same time, CREATE_TIMESTAMP (creation timestamp) and ARCHIVE_TIMESTAMP (archive timestamp) are retained for full life cycle tracking.

[0112] Step S402: Clean the cache data and index data associated with the migrated business data.

[0113] Exemplarily, after completing the database migration, the system performs associated data cleaning: First, construct a list of PNR numbers to be cleaned, and batch execute the DEL pnr:H3K8M2 command through a Redis pipeline (Pipeline) to delete the cache data; at the same time, send a batch delete request to the search engine to clear the index documents by DELETE FROM pnr_index WHERE pnr_no IN ('H3K8M2', 'K8H2M3',...). To ensure the traceability of the cleaning process, the system records an audit log in the format of ARCHIVE_CLEAN|TIMESTAMP:2024-01-30T02:30:00Z|PNR_COUNT:1532|REDIS_DEL:1532|ES_DEL:1532, and reports the archive.clean.success.count and archive.clean.duration metrics through the monitoring platform. This process ensures the efficient utilization of storage resources, maintains data consistency, and avoids querying expired archived data.

[0114] Combined with Figure 11As shown in the figure, this application embodiment provides an archiving flowchart, which is a "hot and cold data separation" process for data lifecycle management in a flight reservation data processing system. Firstly, it includes a scheduled task configuration layer, a parameter parsing layer, a query service layer, an archiving service layer, and an archive log layer.

[0115] In the scheduled task configuration layer, scheduled tasks are created by XXL-JOB. These tasks support custom parameters, such as: / / Custom parameters { / / Day offset.

[0116] Offset: 180 / / Number of archived data entries (unit: thousands) Count: 8 } This parameterization approach makes archiving strategies (how long data is considered cold data, how much data to migrate each time) highly configurable and flexible, and can be adjusted without modifying the code.

[0117] After the task starts, check if there are duplicate instances of the same task. If there are running scheduled tasks, terminate the task directly.

[0118] If it is the first time or a normal trigger, the configuration parameters (offset and count) of the scheduled task are parsed and the parameters are verified to prepare conditions for subsequent queries.

[0119] Next, the query service layer constructs a query statement based on the parsed parameters (such as offset=180) and retrieves data from the main business database that meets the archiving criteria. If no data needs to be archived, the process ends.

[0120] Next, the archiving service layer reads the data from the original table, inserts it into the history table, that is, writes the data read in this batch into the archive database (historical table), and deletes the data from the original table. Finally, the archive log layer records the archive result log.

[0121] In addition, the system can retrieve currently effective PNR data comparison strategies from a preset configuration library. These strategies define the rules, scope, and frequency of comparison. Next, the system checks for the existence of a preset delay execution flag for this task. This mechanism is typically used for off-peak processing or following specific business time windows; if a delay flag exists, the task ends early.

[0122] Once everything is ready, the system will, based on the acquired strategy, select the PNR data to be compared from the source database and execute the core data comparison logic (the specific comparison rules and algorithms are explained in a separate detailed comparison flowchart). After the comparison is completed, the system will write the resulting difference results or consistency reports to the results database, thus completing the data persistence.

[0123] The process finally enters the post-processing layer. At this stage, the system presets a delay flag for the next task execution, thus automating the management of task cycles and intervals. After all tasks are completed, the distributed task locks (Job Locks) they occupied are released, ensuring timely cleanup of system resources and allowing the next task cycle to be triggered normally, thereby forming a closed-loop, controllable automated task lifecycle.

[0124] For example, this application also provides a scenario illustration of another method for processing flight passenger reservation data, such as... Figure 12 As shown, firstly, the IPNRH real-time data stream is received. The listening program asynchronously saves the IPNRH real-time data stream to the message database and then calls the conversion program to the conversion program. The conversion program first performs operations such as parsing, cleaning, and de-identification / encryption on the real-time data stream to make it complete and standardized passenger order data, and writes the passenger order data into the PNR order database. Secondly, frequently accessed data is stored in the Redis cache for querying by client applications. Finally, the conversion program synchronizes the fields that need to be used for multi-dimensional and complex condition retrieval (such as passenger name, flight number, date, etc.) to the Solr search engine to create an index for querying by the background management program, and then transfers them to the PNR archive.

[0125] For example, this application also provides a data processing apparatus for civil aviation operations, which is used to implement the above-described method embodiments.

[0126] In some embodiments, such as Figure 13 As shown in the illustration, this application also provides a scenario diagram of another method for processing flight passenger reservation data. This flowchart is divided into two parts: writing and querying. First, on the data writing side, the middleware acts as a proxy between the application and the database, receiving plaintext business data submitted by the user and automatically performing encryption operations, storing the ciphertext in a designated cipher column. Based on a balance strategy between security and business performance, it is configurable to choose whether to store the original plaintext or the de-identified version in the plaintext column simultaneously, and finally, the processed data is completely stored in the database.

[0127] On the data query side, when a user initiates a query request, the middleware's SQL parsing engine will intelligently analyze the request: for conditions involving encrypted fields, it will automatically convert and process them; for result sets, it will seamlessly decrypt from the ciphertext column or read directly from the plaintext column according to the storage strategy, and finally return a unified plaintext result to the application.

[0128] like Figure 14 This is a schematic diagram of a data processing apparatus provided in an embodiment of this application. The data processing apparatus includes an acquisition unit 1401 and a processing unit 1402. The acquisition unit 1401 is used to perform... Figure 3 The illustrated method includes step S201; the processing unit 1401 is used to execute... Figure 3 The illustrated method includes steps S202, S203, and S204.

[0129] In some embodiments, the processing unit 1401 is further configured to perform Figure 9 In the illustrated method, step S301 and Figure 10 The illustrated method includes steps S401 and S402.

[0130] In some embodiments, the data processing apparatus described above includes hardware structures and / or software modules corresponding to the execution of each function in order to achieve the above-described functions. Those skilled in the art will readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware 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.

[0131] This application embodiment can divide the data processing device into functional modules according to the above method embodiment. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0132] like Figure 15 As shown, the data processing system provided in this application embodiment may include a processor 1101, a bus 1102, a communication interface 1103, and a memory 1104. The processor 1101, the memory 1104, and the communication interface 1103 communicate with each other via the bus 1102. It should be understood that this application does not limit the number of processors and memories in the network device.

[0133] Bus 1102 can be a PCI bus, an Extended Industry Standard Architecture (EISA) bus, or a UB bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 15 The bus 1102 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 1102 may include a path for transmitting information between various components of the network device (e.g., memory 1104, processor 1101, communication interface 1103).

[0134] Processor 1101 may include any one or more processors such as CPU, graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP).

[0135] The memory 1104 may include volatile memory, such as random access memory (RAM). The processor 1101 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0136] The communication interface 1103 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between network devices and other devices or communication networks.

[0137] The memory 1104 stores executable program code, and the processor 1101 executes the executable program code to implement the functions of the aforementioned method embodiments. That is, the memory 1104 stores instructions for executing the aforementioned report generation method for civil aviation operations.

[0138] On the one hand, a computer-readable storage medium is provided, in which at least one computer program is stored, the at least one computer program being loaded and executed by a processor to implement the report generation method for civil aviation operations as provided in the above-described method embodiments.

[0139] In another aspect, a computer program product is provided, which includes a computer program or instructions that, when executed by a processor, implement the report generation method for civil aviation operations provided in the above-described method embodiments.

[0140] Through the above description of the implementation methods, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the module can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, modules, and units described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0141] Since the indicator generation module, computer-readable storage medium, and computer program product in the embodiments of the present invention can be applied to the above method, the technical effects obtained can also be referred to the above method embodiments, and the embodiments of the present invention will not be repeated here.

[0142] The method steps in this embodiment can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Alternatively, the ASIC can reside in a network device. Of course, the processor and storage medium can also exist as discrete components in the network device.

[0143] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer programs or instructions. When a computer program or instruction is loaded and executed on a computer, the processes or functions of the embodiments of this application are performed, in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable module. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, a computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video disc (DVD); or it can be a semiconductor medium, such as a solid-state drive (SSD). The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for processing flight passenger reservation data, characterized in that, The method includes: Obtain passenger order data, which includes an order identifier and a version identifier; Based on the order identifier, obtain exclusive processing permissions corresponding to the passenger order data; If the exclusive processing permission is obtained, the version identifier is compared with the stored version identifier to obtain the comparison result; The passenger order data is processed based on the comparison results to generate business data.

2. The method according to claim 1, characterized in that, The process of processing the passenger order data based on the comparison results to generate business data includes: In response to the version identifier being updated to the stored version identifier, sensitive information in the passenger order data is anonymized, and the business data is generated.

3. The method according to claim 2, characterized in that, The method further includes: The cached data in the cache database is updated based on the business data, and the cached data is used to respond to real-time query requests for the order identifier.

4. The method according to claim 1, characterized in that, The method further includes: If the version identifier is not updated to the stored version identifier, the passenger order data is discarded and the exclusive processing permission is released.

5. The method according to any one of claims 2 to 4, characterized in that, The version identifier includes at least one of the following: Timestamp; Serial number.

6. The method according to claim 1, characterized in that, The method further includes: The frequently queried fields in the passenger order data are synchronized to the search engine to build an index, and / or multiple business fields under the same order identifier are redundantly stored in the business table.

7. The method according to claim 1, characterized in that, The method further includes: Periodically migrate business data that meets the preset inactive conditions in the cache database to the archive database, and clean up the cache data and index data associated with the migrated business data.

8. The method according to claim 1, characterized in that, The exclusive processing permission is implemented through a data access middleware located between the business system and the cache database. The data access middleware is configured to encrypt sensitive information of the passenger order data written to the cache database and decrypt the query results.

9. A flight passenger reservation data processing system, characterized in that, The system includes: The acquisition module is used to acquire passenger order data, which includes an order identifier and a version identifier; The processing module is used to obtain exclusive processing permissions corresponding to the passenger order data based on the order identifier; The processing module is also used to compare the version identifier with the stored version identifier when the exclusive processing permission is obtained, and to obtain the comparison result; The processing module is also used to process the passenger order data based on the comparison results to generate business data.

10. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to implement the method as claimed in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program, which is loaded and executed by a processor to implement the method as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, The computer program product includes a computer program or instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 8.

Images