Ticket price synchronization method and device, equipment and storage medium

Abstract

The invention provides a ticket price synchronization method and device, equipment and a storage medium, and relates to the technical field of traffic transportation management, and the method comprises the steps: obtaining and caching a passenger transport route from a relational database; and obtaining target business scene data from the relational database. The target business scene data comprises identification data of the target business scene and ticket price data in the target business scene. And based on the identification data of the target business scene, obtaining a target passenger transport route associated with the target business scene from the cached passenger transport routes. And based on a preset assembly rule, assembling the ticket price data in the target business scene and the target passenger transport route to obtain the ticket price data of the target passenger transport route in the target business scene. And storing the ticket price data of the target passenger transport route in the target business scene into an index database to complete ticket price synchronization. Therefore, the ticket price query efficiency of the passenger transport route can be improved.

Description

Technical Field

[0001] This application relates to the field of transportation management technology, and in particular to a fare synchronization method, apparatus, device, and storage medium. Background Technology

[0002] In the passenger transport industry, ticket prices are a core element for regulating supply and demand and achieving precise operation. The efficiency and accuracy of their management directly affect the service quality and market response speed of passenger transport companies.

[0003] In traditional fare management, the transaction characteristics of relational databases ensure the consistency of fare data, guaranteeing that fare information accurately corresponds to and is updated in real time with actual operational services.

[0004] However, due to the inherent serial processing mechanism and limited horizontal scaling capabilities of relational databases, they experience performance bottlenecks in large-scale concurrent access scenarios, making it difficult to meet the real-time ticket price query requirements of multiple terminals. This leads to problems such as delayed ticket price release and inconsistent data across sales channels, affecting ticket price operation efficiency and customer experience. Summary of the Invention

[0005] This application provides a fare synchronization method, apparatus, device, and storage medium that can query basic data from a relational database and combine and store the basic data in an indexed database, thereby improving the fare query efficiency for passenger routes in high-concurrency scenarios.

[0006] To address the above problems, the embodiments of this application provide the following technical solutions:

[0007] Firstly, this application provides a fare synchronization method, which includes: retrieving and caching passenger routes from a relational database; retrieving target business scenario data from the relational database; the target business scenario data including identification data of the target business scenario and fare data under the target business scenario; based on the identification data of the target business scenario, retrieving target passenger routes associated with the target business scenario from the cached passenger routes; assembling the fare data and target passenger routes under the target business scenario based on preset assembly rules to obtain fare data for the target passenger routes under the target business scenario; and storing the fare data for the target passenger routes under the target business scenario in an indexed database to complete fare synchronization.

[0008] The fare synchronization method provided in this application first retrieves passenger routes from a relational database. Since passenger routes do not change frequently in the short term, they are cached to reduce input / output operations on the relational database. Simultaneously, target business scenario data is retrieved from the relational database. This data includes identification information for a specific business scenario, along with corresponding fare calculation rules and results. Subsequently, based on the identification data from the target business scenario data, the method identifies target passenger routes associated with the fare data from the cached passenger routes. Then, using preset assembly rules, the fare data is integrated with the target passenger routes to generate complete fare data. Finally, the method stores the assembled fare data in an indexed database. Compared to existing technologies, this application, through the extraction and assembly of passenger routes and target business scenario data, simulates the query logic of a relational database to obtain accurate route fare data while leveraging the efficient querying and distributed storage characteristics of an indexed database to improve the efficiency of fare queries.

[0009] One possible implementation, after retrieving and caching passenger routes from a relational database, further includes: in response to a detected passenger route change event in the relational database, retrieving passenger routes with updated data from the relational database; and updating the cached passenger routes based on the updated passenger routes.

[0010] One possible implementation involves retrieving target business scenario data from a relational database. This includes: acquiring identification data based on the target business scenario and obtaining a business data synchronization lock. The business data synchronization lock represents read access permission for the target business scenario data in the relational database. If acquiring the business data synchronization lock fails, retrieving target business scenario data from the relational database is stopped. If acquiring the business data synchronization lock succeeds, the target business scenario data is retrieved from the relational database.

[0011] One possible implementation involves identifying the target business scenario using data that includes the business area. Based on this data, target passenger routes associated with the target business scenario are retrieved from cached passenger routes. This includes identifying passenger routes that stop within the business area from the cached passenger routes as target passenger routes.

[0012] One possible implementation involves storing the fare data for the target passenger route within the target business scenario into an indexed database to achieve fare synchronization. This includes: generating a business index name based on a pre-defined index naming rule and the identification data of the target business scenario; generating an index mapping based on the data type of the fare data for the target passenger route within the target business scenario if the business index name does not exist in a valid index table in the indexed database; creating an index table in the indexed database based on the business index name and the index mapping; and storing the fare data for the target passenger route within the target business scenario into the index table.

[0013] One possible implementation method further includes: if a valid index table exists for the business index name in the indexed database, creating a backup table with the same structure as the valid index table, and migrating the data from the valid index table to the backup table. The fare data for the target passenger route under the target business scenario is then stored in the valid index table.

[0014] One possible implementation, after storing the fare data for the target passenger route in the target business scenario into the valid index table, further includes: configuring the valid index table as a table to be recycled in response to an index version switching instruction; and configuring the backup table as a valid index table.

[0015] Secondly, this application provides a fare synchronization device, which includes various functional modules for the method described in the first aspect above.

[0016] Thirdly, this application provides an electronic device comprising a processor and a memory. The memory stores processor-executable instructions, which, when configured to execute the instructions, cause the electronic device to perform the method described in the first aspect above.

[0017] Fourthly, this application provides a readable storage medium comprising software instructions. When the software instructions are executed in an electronic device, they cause the electronic device to perform the method described in the first aspect above.

[0018] Fifthly, this application provides a computer program product comprising computer instructions. When the computer instructions are executed on an electronic device, the electronic device causes the electronic device to perform the method described in the first aspect.

[0019] The beneficial effects of the second to fifth aspects mentioned above can be referred to the first aspect, and will not be repeated here. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0021] Figure 1 A schematic diagram illustrating the architecture of an implementation scenario for a fare synchronization method provided in this application embodiment;

[0022] Figure 2 A flowchart illustrating a fare synchronization method provided in an embodiment of this application;

[0023] Figure 3 A flowchart illustrating a method for updating cached passenger routes provided in an embodiment of this application;

[0024] Figure 4 A flowchart illustrating a method for acquiring data in a target business scenario, provided in an embodiment of this application;

[0025] Figure 5 A flowchart illustrating an indexed database storage method provided in an embodiment of this application;

[0026] Figure 6 A flowchart illustrating another indexed database storage method provided in this application embodiment;

[0027] Figure 7 A flowchart illustrating a method for switching versions of an indexed database provided in this application embodiment;

[0028] Figure 8 This is a schematic diagram illustrating the composition of a fare synchronization device provided in an embodiment of this application;

[0029] Figure 9 This is a schematic diagram of the composition of an electronic device provided in an embodiment of this application. Detailed Implementation

[0030] Hereinafter, the terms "first," "second," and "third," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first," "second," or "third," etc., may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

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

[0032] In addition, for ease of understanding, the technical terms involved in the embodiments of this application will be introduced below.

[0033] 1. Indexed databases (also often called indexed databases or an advanced form of key-value stores) are a type of database with efficient indexing mechanisms at their core, designed to optimize data retrieval speed. Unlike relational databases, they typically store data in a "key-value" or "index-document" structure and create dedicated indexes (such as hash indexes, B-tree indexes, inverted indexes, etc.) for frequently queried fields. This allows queries to locate data directly through the index without scanning the entire table, significantly improving retrieval efficiency.

[0034] 2. Relational databases are a type of database that organizes data in a two-dimensional table format (composed of rows and columns) and links different tables through attributes such as primary keys and foreign keys. Their core features include support for atomic transactions, consistent transactions, isolated transactions, and durable transactions, which strictly guarantee data integrity and consistency. This makes them widely used in scenarios requiring precise data association (such as binding ticket prices with train schedules and seat information in the passenger transport industry).

[0035] As mentioned above, relational databases have significant shortcomings in concurrent query efficiency. Their serialized transaction processing mechanism relies on locking mechanisms to limit concurrent operations, which can easily lead to queuing and waiting when multiple requests access the database simultaneously. Complex queries with fixed table structures often require multi-table joins, and the computational cost increases significantly when the data volume is large or the conditions are complex. At the same time, their horizontal scalability is limited, making it difficult to improve performance by adding nodes. These factors combined result in performance bottlenecks due to insufficient processing capacity in large-scale concurrent query scenarios, making it impossible to meet query response requirements.

[0036] Therefore, how to improve the efficiency of ticket price queries in high-concurrency scenarios is a problem that we urgently need to solve.

[0037] In view of this, this application provides a fare synchronization method. First, it acquires passenger route and specific business scenario data from a relational database, reducing the complexity of relational database queries by decreasing data correlation. Then, it combines the two into complete passenger route fare data and stores it in an indexed database. This leverages the storage and query characteristics of the indexed database to improve the response speed of fare queries.

[0038] First, a brief introduction to the application scenarios of the embodiments of this application will be given.

[0039] This application provides a fare synchronization method that can be applied to a computing device, which may be a server cluster consisting of multiple servers, a single server, a computer, or a processor or processing chip in a server or computer. This application does not limit the specific form of the computing device.

[0040] In an exemplary embodiment, the implementation scenario of a fare synchronization method provided in this application is as follows: Figure 1 As shown, this scenario specifically includes the following parts:

[0041] The system includes: an integrated fare management platform 110, a relational database 120, computing devices 130, an index management tool 140, an indexed database 150, a price center 160, and multiple terminals 170.

[0042] Specifically, the integrated fare management platform 110 can be understood as a passenger fare management system, which is responsible for the formulation and adjustment of specific fare strategies, as well as the calculation of fare results.

[0043] Relational database 120 is responsible for storing passenger routes and business scenario data generated by the integrated fare management platform 110.

[0044] The computing device 130 is responsible for retrieving passenger route and target business scenario data from a relational database, assembling the passenger route and target business scenario data, and storing the assembled data into an indexed database 150 through an index management tool 140, which is the fare synchronization method provided in this application embodiment. For a detailed description of this method, please refer to the following text; it will not be elaborated upon here.

[0045] Index management tool 140 is responsible for maintaining the index information of indexed database 150, as well as updating, backing up, and deleting index tables.

[0046] Indexed database 150 is responsible for storing ticket price data for target passenger routes under the target business scenario.

[0047] Price Center 160 internally obtains index update information from Index Database 150 and understands the business indexes stored in Index Database 150; externally, it provides fare query interfaces to multiple terminals 170 and receives fare query requests from multiple terminals.

[0048] Terminal 170, including terminal equipment from different departments within a passenger transport company or terminal equipment from ticket sales channels, obtains ticket price data for the target passenger transport route under the target business scenario by sending a ticket price query request to the price center 160.

[0049] The fare synchronization method provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0050] like Figure 2 As shown, when this method is applied to a computing device, it includes the following:

[0051] S101. Retrieve and cache passenger routes from a relational database.

[0052] One possible implementation is that step S101, as the starting step of the method, can be triggered by the computing device at regular intervals according to a preset execution plan, or it can be manually triggered by the administrator.

[0053] In some embodiments, passenger routes may include shipping routes, land transportation routes, and water transportation routes. Land transportation includes road transport, rail transport, etc. This application does not limit the specific form of passenger routes.

[0054] One possible implementation is to use Structured Query Language (SQL) statements to query a relational database to obtain passenger routes.

[0055] Specifically, since the data dimensions of passenger routes are relatively simple, there may be many single-table queries involved in relational databases, which will not cause a decrease in the query performance of relational databases.

[0056] One possible implementation is that the computing device can store passenger routes in a local file as a structured file.

[0057] For example, passenger routes can be converted into JSON format and stored in a JSON file.

[0058] S102. Obtain target business scenario data from a relational database.

[0059] The target business scenario data includes the identification data of the target business scenario and the ticket price data under the target business scenario.

[0060] The target business scenario refers to the scope of business defined in passenger transport operations based on specific business objectives and constraints.

[0061] For example, if a specific business objective is to "adjust fares for short-distance weekend travelers to increase occupancy rates," the corresponding constraints could include: a time frame of Saturday to Sunday, a spatial scope of passenger routes within 100 kilometers of the city's perimeter, and a mode of transport limited to road passenger transport (such as intercity buses). The defined scope of "weekends + within 100 kilometers of the city's perimeter + road passenger transport + fare adjustment" constitutes the target business scenario under this objective.

[0062] For example, when the business objective is to "ensure transportation capacity between key cities during the Spring Festival travel rush," the constraints can be set as follows: the time range is the start and end dates of the Spring Festival travel rush, the spatial range is routes between national transportation hub cities, and the transportation modes include railways, civil aviation, and long-distance buses. In this case, "Spring Festival travel rush + between key hub cities + multiple transportation modes + transportation capacity guarantee" constitutes the corresponding target business scenario.

[0063] The identification data is used to differentiate between different business scenarios. Ticket price data for the target business scenario includes: ticket price, application constraints on ticket price, and ticket price calculation rules.

[0064] In some embodiments, the identification data includes constraints such as spatial dimension, time dimension, and mode of transportation. The embodiments of this application do not limit the specific constituent dimensions and division forms of the identification data.

[0065] In some embodiments, fares include the following types: base fare (original fare, used to display the difference between the original price and the current price in the user's visual representation), adjusted fare (final fare, the final price after discounts, surcharges, or business rule calculations), differentiated service fares (e.g., different seat / cabin class), special group fares, and combined fares. This application does not limit the specific types of fare data included in its embodiments.

[0066] S103. Based on the identification data of the target business scenario, obtain the target passenger route associated with the target business scenario from the cached passenger routes.

[0067] As can be seen from step S102, the fare data is calculated based on the business scope and specific business rules, but it is not actually connected to the specific passenger routes. Therefore, it is necessary to identify the specific scope of use of the fare data through the aforementioned identification data, and obtain the target passenger route from the cached passenger routes based on the scope of use.

[0068] Specifically, the implementation method of step S103 can be found in step S401 below, which will not be elaborated here.

[0069] S104. Based on the preset assembly rules, assemble the ticket price data and the target passenger route under the target business scenario to obtain the ticket price data of the target passenger route under the target business scenario.

[0070] One possible implementation method, which involves assembling fare data and target passenger routes for the target business scenario, can be specifically implemented as follows:

[0071] First, extract the inherent features (such as transport type, operating station sequence, seat class, etc.) and route identifiers for each target passenger route. Then, match fare data with the inherent features of each passenger route to construct temporary "passenger route identifier-fare" data. For example, the application constraint for fare A is: "Transport type = High-speed rail AND Seat class = Second class AND Stops include Beijing South." Substitute the inherent features of passenger route B into the conditional expression of the fare calculation rule. If all conditions are met, fare A is considered the actual fare for passenger route B. Then, if multiple fare data can be matched for the same passenger route, a range judgment can be performed on the application constraints of multiple fare data, selecting the fare data with the smallest range for the business scenario as the final fare. Finally, supplement the temporary "passenger route identifier-fare" data with the detailed features of the passenger route to obtain the fare data for the target passenger route under the target business scenario.

[0072] S105. Store the fare data of the target passenger route in the target business scenario into an indexed database to complete the fare synchronization.

[0073] An indexed database maintains multiple index tables, each with an index name (which can also be understood as an index node). By using the index name, you can query the fare data for the passenger routes corresponding to the business scenario data.

[0074] For a detailed explanation of step S105, please refer to the following text. Figure 5 .

[0075] The fare synchronization method provided in this application first retrieves passenger routes from a relational database. Since passenger routes do not change frequently in the short term, they are cached to reduce input / output operations on the relational database. Simultaneously, target business scenario data is retrieved from the relational database. This data includes identification information for a specific business scenario, along with corresponding fare calculation rules and results. Subsequently, based on the identification data from the target business scenario data, the method identifies target passenger routes associated with the fare data from the cached passenger routes. Then, using preset assembly rules, the fare data is integrated with the target passenger routes to generate complete fare data. Finally, the method stores the assembled fare data in an indexed database. Compared to existing technologies, this application, through the extraction and assembly of passenger routes and target business scenario data, simulates the query logic of a relational database to obtain accurate route fare data while leveraging the efficient querying and distributed storage characteristics of an indexed database to improve the efficiency of fare queries.

[0076] In some embodiments, after caching passenger routes in step S101, it is also necessary to maintain the consistency of the cached passenger routes, that is, to update the passenger routes cached in the computing device based on the passenger routes in the relational database. This process is as follows: Figure 3 As shown, after step S101, the following steps may also be included:

[0077] S201. In response to a detected passenger route change event in the relational database, retrieve the passenger route with updated data from the relational database.

[0078] One possible implementation is that the computing device can monitor change events (including additions, modifications, and deletions) in the passenger route table in real time by setting triggers in the relational database or enabling a change data capture mechanism. When a change event is detected, step S201 can be triggered to extract the operation type (such as insert, update, delete) and the affected passenger routes from the relational database.

[0079] Specifically, if the change event is an addition, all fields of the newly added passenger route are directly retrieved. If it is a modification event, the updated complete route data and the key fields before the modification are retrieved. If it is a deletion event, the unique identifier of the deleted route (such as the primary key of the passenger route in the database) is retrieved.

[0080] S202. Based on passenger routes with updated data, update the cached passenger routes.

[0081] One possible implementation involves extracting the passenger route identifier (hereinafter referred to as the route identifier) ​​from passenger routes that have undergone data updates, and using this identifier as an index to locate the corresponding original passenger route in the cache. Then, the cached passenger routes are updated according to different operation types.

[0082] Specifically, taking a passenger route that is being updated as an example, we will introduce different ways to update cached passenger routes.

[0083] If it is a new operation (i.e. there is no record corresponding to the route identifier in the cache), the complete data of the new passenger route is directly written to the cache, and a key-value pair of "route identifier-route data" is established.

[0084] If it is a modification operation (the route identifier exists in the cache), compare the route data before and after the update, replace only the changed fields (such as station adjustments, changes in operating hours, etc.), and retain the unchanged fields (such as transportation type, seat class, etc.) to avoid full overwrite;

[0085] If it is a deletion operation, the corresponding passenger route is removed from the cache based on the route identifier to ensure that the deletion operation in the cache is consistent with that in the relational database.

[0086] As can be seen from steps S201-S202, since the frequency and scope of changes in passenger route data in actual operation scenarios are not too large, incremental updates can be used to maintain existing data change operations.

[0087] In some embodiments, while a computing device is acquiring data related to a target business scenario, other computing devices may also be accessing that data. In this case, to reduce resource waste and data conflicts, a data synchronization lock can be configured to restrict access to the target business scenario data by multiple devices. The process is as follows: Figure 4 As shown, the specific steps include the following:

[0088] S301. Based on the identification data of the target business scenario, obtain the business data synchronization lock.

[0089] Among them, the business data synchronization lock is used to represent the read permission of the target business scenario data in the relational database.

[0090] One possible implementation, step S301 can be specifically implemented as follows:

[0091] First, identification information (such as business scenario ID, associated geographic region code, time range hash value, etc.) is generated from the identification data of the target business scenario. This identification information is then combined to generate a unique "lock identifier string." Next, the computing device sends a lock request to the lock management module of the relational database, carrying the aforementioned "lock identifier string" and its own device identifier (such as device IP or process ID). The lock management module checks the synchronization lock status corresponding to the "lock identifier string": if the business data synchronization lock is unoccupied, it marks the lock as "occupied," records the identifier of the requesting device and the time the lock was acquired, and then returns a "business data synchronization lock acquired successfully" response to the computing device. If the lock is already occupied by another device, it returns "business data synchronization lock acquired failed."

[0092] S302. If the result of acquiring the business data synchronization lock fails, stop acquiring the target business scenario data from the relational database.

[0093] In some embodiments, when a computing device fails to acquire a business data synchronization lock, it may attempt to reacquire the business data synchronization lock according to a preset retry strategy.

[0094] For example, a retry policy could be a retry count policy: setting a maximum retry threshold for the computing device. If the actual number of retries does not reach this threshold, attempts to acquire the lock are allowed to continue; otherwise, retries are stopped.

[0095] For example, a retry strategy can be a retry timing strategy: setting a time window as a retry time threshold. Within this time window, the computing device can attempt to acquire the lock multiple times; once this time range is exceeded, retrying stops.

[0096] Furthermore, if the computing device fails to acquire the business data synchronization lock after the retry strategy has been executed, it needs to issue an anomaly alarm based on the identification data of the target business scenario, and notify manual maintenance.

[0097] S303. If the result of acquiring the business data synchronization lock is successful, retrieve the target business scenario data from the relational database.

[0098] As can be seen from steps S301-S303, by introducing a business data synchronization lock as an access control mechanism for data access, the mutual exclusion and security of multiple computing devices concurrently accessing the target business scenario data can be ensured.

[0099] In some embodiments, if the identification data of the target business scenario includes a business (geographic) area, then step S103 can be specifically implemented as follows:

[0100] S401. From the cached passenger routes, record the passenger routes that stop within the business area as the target passenger routes.

[0101] When the identification data includes a business area, it means that the target business scenario is limited to a specific geographical area (such as the "Yangtze River Delta region"). In this case, the passenger routes associated with this scenario must be directly related to this region—and "stopping within the business area" is the most direct form of association.

[0102] For example, if the business area is "Beijing-Tianjin-Hebei", then all passenger routes passing through stations in Beijing, Tianjin, and Hebei (regardless of whether the origin / destination is within the region) fall within the service scope that needs to be covered in this scenario.

[0103] In addition to the business area, time limits can be set in the identification data, such as "during the Spring Festival holiday", "weekday morning rush hour", "summer dates", etc., to filter passenger routes corresponding to different business scenarios.

[0104] In some embodiments, in addition to searching for target passenger routes within the actual geographical and temporal ranges described above, target passenger routes can also be extracted from the target business scenario identification data using the following information: transportation vehicle type constraints, service registration constraints, operating entity constraints, sales channel constraints, route constraints, original fare constraints, etc. This application embodiment does not limit the specific screening conditions for target passenger routes.

[0105] In some embodiments, such as Figure 5 As shown, step S105 specifically includes the following steps:

[0106] S501. Generate business index names based on preset index naming rules and identification data of target business scenarios.

[0107] By using preset index naming rules, it can be ensured that the business index names generated from the identification data of the same target business scenario are the same at different times, so that the index-based database can identify the fare data of passenger routes in the corresponding business scenario based on the business index name.

[0108] One possible implementation is to pre-define the index naming rules by concatenating the identification data of the business scenario data according to a fixed field order.

[0109] For example, the transportation type, geographical scope, time dimension, and customer group type are converted into codes, and the codes are concatenated into a business index name.

[0110] S502. If the business index name does not exist in a valid index table in the indexed database, generate an index mapping based on the data type of the ticket price data of the target passenger route in the target business scenario.

[0111] Index mapping refers to the predefined, structured configuration of the field structure, data type, and indexing rules of ticket price data in the target business scenario. This is used to guide the creation of new index tables in indexed databases and ensure that stored data can be stored in a uniform format.

[0112] If no valid index table corresponding to the business index name is found in the indexed database, it indicates that the indexed database has not stored fare data for the target passenger route under the target business scenario. Therefore, it is necessary to define the index mapping based on the data type of the fare data for the target passenger route under the target business scenario.

[0113] For example, if the ticket price data contains three fields: "route_id (string), price (numeric), and valid_time (timestamp)," the index mapping will explicitly specify the type constraints of these three fields and designate "route_id" as the base index key and "valid_time" as the sorting index key, ensuring that the newly created index table can quickly locate data by route identifier and efficiently filter results by time order.

[0114] S503. Create an index table in the indexed database based on the business index name and index mapping.

[0115] In an indexed database, an index table is a structured container for storing data. Its structure is defined by the index mapping, and its name is uniquely identified by the business index name.

[0116] S504. Store the fare data for the target passenger route in the target business scenario into an index table.

[0117] In some embodiments, the process when a valid index table corresponding to the business index name can be retrieved in the indexed database is as follows: Figure 6 As shown, the specific steps include the following:

[0118] S601. If a valid index table exists in the indexed database for the business index name, create a backup table with the same structure as the valid index table, and migrate the data from the valid index table to the backup table.

[0119] A backup table is a redundant storage table that is completely identical to the valid index table in terms of fields, types, constraints, and indexing rules. It can be used for data rollback and recovery during system or data version switching in the target business scenario. For example, when the new version of data is abnormal, the backup table can be used to quickly roll back to the valid data state before the switch, ensuring business continuity.

[0120] S602. Store the fare data for the target passenger route in the target business scenario into a valid index table.

[0121] In some embodiments, after step S502, if ticket price data anomalies occur during the use of the valid index table, a backup table containing previously stored historical data can be used as the new valid index table. This process is as follows: Figure 7 As shown, the method also includes the following steps:

[0122] S701, In response to the index version switching command, configure the valid index table as a table to be recycled.

[0123] S702. Configure the backup table as a valid index table.

[0124] In some embodiments, the computing device sends instructions to the index management tool, causing the index management tool to execute a specific process of switching versions of the valid index table and the backup index table.

[0125] One possible implementation is that when a computing device receives an index version switching instruction, it can locate the corresponding valid index table and backup table based on the business index name and the specified backup table version in the version switching instruction. Then, the valid index table is configured as a table to be recycled, and the corresponding backup table is configured as a new valid index table.

[0126] In addition, for tables awaiting recycling, the computing device can retain them first, and then destroy them after the management personnel have traced the source of the anomalies.

[0127] As can be seen from steps S701-702, by switching between the backup table and the valid index table, version backtracking of abnormal ticket price data can be achieved, ensuring the accuracy of ticket price data.

[0128] The foregoing mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, the fare synchronization device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in 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 may 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.

[0129] In an exemplary embodiment, this application also provides a fare synchronization device. This fare synchronization device may include one or more functional modules for implementing the fare synchronization method of the above method embodiments.

[0130] For example, such as Figure 8 As shown, the fare synchronization device includes an acquisition module 810 and a processing module 820.

[0131] The acquisition module 810 is used to retrieve and cache passenger routes from a relational database. It retrieves target business scenario data from the relational database. Target business scenario data includes identification data for the target business scenario and fare data for that scenario.

[0132] The processing module 820 is used to retrieve the target passenger routes associated with the target business scenario from the cached passenger routes based on the identification data of the target business scenario. Based on preset assembly rules, it assembles the fare data and target passenger routes under the target business scenario to obtain the fare data for the target passenger routes under the target business scenario. The fare data for the target passenger routes under the target business scenario is then stored in an indexed database to complete fare synchronization.

[0133] In one possible implementation, the processing module 820 is further configured to, in response to a detected passenger route change event in the relational database, retrieve passenger routes with updated data from the relational database. Based on the passenger routes with updated data, update the cached passenger routes.

[0134] One possible implementation involves the target business scenario being any one of multiple business scenarios. Specifically, the acquisition module 810 acquires a business data synchronization lock based on the identification data of the target business scenario. The business data synchronization lock represents the read permission for the target business scenario data in the relational database. If acquiring the business data synchronization lock fails, retrieving the target business scenario data from the relational database is stopped. If acquiring the business data synchronization lock succeeds, the target business scenario data is retrieved from the relational database.

[0135] One possible implementation is that the processing module 820 is specifically used to record the passenger routes that stop within the business area from the cached passenger routes as the target passenger routes.

[0136] One possible implementation involves the processing module 820 specifically used to generate a business index name based on preset index naming rules and the identification data of the target business scenario. If the business index name does not have a valid index table in the indexed database, an index mapping is generated based on the data type of the fare data for the target passenger route under the target business scenario. An index table is then created in the indexed database based on the business index name and the index mapping. Finally, the fare data for the target passenger route under the target business scenario is stored in the index table.

[0137] In one possible implementation, the processing module 820 is further configured to, if a valid index table exists in the indexed database for the business index name, create a backup table with the same structure as the valid index table, and migrate the data from the valid index table to the backup table. This stores the fare data for the target passenger route under the target business scenario in the valid index table.

[0138] In one possible implementation, the processing module 820 is also configured to, in response to an index version switching instruction, configure the valid index table as a table to be recycled, and configure the backup table as a valid index table.

[0139] It should be noted that, Figure 8 The module division shown is illustrative and represents only one logical functional division; in actual implementation, other division methods are possible. For example, two or more functions can be integrated into a single processing module. These integrated modules can be implemented either in hardware or as software functional modules.

[0140] In exemplary embodiments, as described above, the computing device may specifically be an electronic device with computing processing capabilities, such as a computer or service. In this case, embodiments of this application also provide an electronic device. Figure 9 This is a schematic diagram illustrating the composition of an electronic device provided in an embodiment of this application. For example... Figure 9 As shown, the electronic device includes: a processor 10, a memory 20, a communication line 30, a communication interface 40, and an input / output interface 50.

[0141] The processor 10, memory 20, communication interface 40, and input / output interface 50 can be connected via communication line 30.

[0142] Processor 10 is used to execute instructions stored in memory 20 to implement the fare synchronization method provided in the above embodiments of this application. Processor 10 can be a CPU, a network processor (NP), a digital signal processor (DSP), a microprocessor, a microcontroller (MCU) / single-chip microcomputer / microcontroller, a programmable logic device (PLD), or any combination thereof. Processor 10 can also be any other device with processing capabilities, such as a circuit, device, or software module; this application embodiment does not limit this. In one example, processor 10 may include one or more CPUs, for example... Figure 9 CPU0 and CPU1 are mentioned. As an optional implementation, the electronic device may include multiple processors; for example, in addition to processor 10, it may also include processor 60. Figure 9 (The example shown is a dashed line).

[0143] The memory 20 is used to store instructions. For example, the instructions may be computer programs. Optionally, the memory 20 may be a read-only memory (ROM) or other types of static storage devices that can store static information and / or instructions; it may also be a random access memory (RAM) or other types of dynamic storage devices that can store information and / or instructions; it may also be an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, or other magnetic storage devices, etc. The embodiments of this application do not limit this.

[0144] It should be noted that the memory 20 can exist independently of the processor 10 or it can be integrated with the processor 10. The memory 20 can be located inside or outside the electronic device, and this application embodiment does not impose any restrictions on this.

[0145] Communication route 30 is used to transmit information between the components included in the electronic device.

[0146] Communication interface 40 is used to communicate with other devices or other communication networks. These other communication networks can be Ethernet, radio access network (RAN), wireless local area networks (WLAN), etc. Communication interface 40 can be a module, circuit, transceiver, or any device capable of enabling communication.

[0147] Input / output interface 50 is used to enable human-computer interaction between users and electronic devices. For example, it enables action interaction or information exchange between users and electronic devices.

[0148] For example, the input / output interface 50 can be a mouse, keyboard, display screen, or touch screen. Action or information interaction between the user and the electronic device can be achieved through a mouse, keyboard, display screen, or touch screen.

[0149] It should be noted that, Figure 9 The structures shown do not constitute a limitation on electronic devices, except... Figure 9 In addition to the components shown, electronic devices may include more or fewer components than illustrated, or combinations of certain components, or different component arrangements.

[0150] In an exemplary embodiment, this application also provides a readable storage medium including software instructions that, when run on an electronic device, cause the electronic device to perform any of the methods provided in the above embodiments.

[0151] In an exemplary embodiment, this application also provides a computer program product containing computer execution instructions, which, when run on an electronic device, causes the electronic device to perform any of the methods provided in the above embodiments.

[0152] 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 programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer-executable instructions. When these computer-executable instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer-executable instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer-executable instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device containing one or more servers, data centers, etc., that can be integrated with the medium. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state disks, SSDs).

[0153] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, disclosure, and appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple components. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0154] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely exemplary illustrations of this application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from the spirit and scope of this application. Thus, if such modifications and modifications of this application fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and modifications.

[0155] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included 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 of ticket price synchronization, characterized by, The method comprises: obtaining and caching passenger routes from a relational database; obtaining target business scenario data from the relational database; the target business scenario data comprises identification data of a target business scenario and ticket price data under the target business scenario; based on the identification data of the target business scenario, obtaining a target passenger route associated with the target business scenario from the cached passenger routes; based on a preset assembly rule, assembling the ticket price data under the target business scenario and the target passenger route to obtain ticket price data of the target passenger route under the target business scenario; storing the ticket price data of the target passenger route under the target business scenario into an index database to complete ticket price synchronization.

2. The method of claim 1, wherein, After the step of obtaining and caching passenger routes from the relational database, the method further comprises: in response to a passenger route change event of the relational database being monitored, obtaining a passenger route with data update from the relational database; based on the passenger route with data update, updating the cached passenger routes.

3. The method of claim 1, wherein, The target business scenario is any one of a plurality of business scenarios, and the step of obtaining target business scenario data from the relational database comprises: based on the identification data of the target business scenario, obtaining a business data synchronization lock; the business data synchronization lock is used to indicate the read permission of the target business scenario data in the relational database; if the result of obtaining the business data synchronization lock is failure, stopping obtaining the target business scenario data from the relational database; if the result of obtaining the business data synchronization lock is success, obtaining the target business scenario data from the relational database.

4. The method of claim 1, wherein, The identification data of the target business scenario comprises a business area, and the step of obtaining a target passenger route associated with the target business scenario from the cached passenger routes based on the identification data of the target business scenario comprises: from the cached passenger routes, marking a passenger route that stops in the business area as a target passenger route.

5. The method of claim 1, wherein, The step of storing the ticket price data of the target passenger route under the target business scenario into an index database to complete ticket price synchronization comprises: based on a preset index naming rule and the identification data of the target business scenario, generating a business index name; if the business index name does not exist in an effective index table in the index database, based on the data type of the ticket price data of the target passenger route under the target business scenario, generating an index mapping; based on the business index name and the index mapping, creating an index table in the index database; storing the ticket price data of the target passenger route under the target business scenario into the index table.

6. The method of claim 5, wherein, The method further comprises: if the business index name exists in an effective index table in the index database, creating a backup table with the same structure as the effective index table, and migrating the data in the effective index table to the backup table; storing the ticket price data of the target passenger route under the target business scenario into the effective index table.

7. The method of claim 6, wherein, After storing the ticket price data of the target passenger transport route in the target business scenario into the effective index table, the method further comprises: In response to an index version switching instruction, configuring the effective index table as a table to be recycled; Configuring the backup table as the effective index table.

8. A ticket price synchronizing apparatus characterized by comprising: The device comprises an acquisition module and a processing module. The acquisition module is configured to: acquire and cache passenger transport routes from a relational database; and acquire target business scenario data from the relational database, wherein the target business scenario data comprises identification data of a target business scenario and ticket price data in the target business scenario; The processing module is configured to: based on the identification data of the target business scenario, acquire a target passenger transport route associated with the target business scenario from the cached passenger transport routes; based on a preset assembly rule, assemble the ticket price data in the target business scenario and the target passenger transport route to obtain ticket price data of the target passenger transport route in the target business scenario; and store the ticket price data of the target passenger transport route in the target business scenario into an index database to complete ticket price synchronization.

9. An electronic device, comprising: comprise: a processor and a memory; the memory stores instructions executable by the processor; the processor is configured to execute the instructions, so that the electronic device implements the method of any one of claims 1-7.

10. A readable storage medium, characterized by, comprise: software instructions; when the software instructions run in the electronic device, so that the electronic device implements the method of any one of claims 1-7.

11. A computer program product, characterised in that, comprise: computer instructions; when the computer instructions run in the electronic device, so that the electronic device implements the method of any one of claims 1-7.

Images