A method and device for processing read-write traffic shunting based on a chauffeur SaaS

Abstract

This invention discloses a method and apparatus for read / write traffic splitting in a chauffeur service SaaS (SaaS-based) system, relating to the field of network data processing technology. The method includes: receiving business requests and identifying them as read or write requests; distributing read requests to target nodes in the read service cluster and write requests to the master node in the write service cluster based on node load status; reading nodes querying data from slave databases and writing nodes modifying the master database; synchronizing data from the master database to slave databases using a hybrid strategy combining incremental synchronization and scheduled full synchronization; and monitoring the cluster and data synchronization status in real time, dynamically adjusting routing strategies, the number of nodes, or the synchronization frequency. This invention achieves complete isolation of read / write traffic in chauffeur service scenarios, eliminates read / write resource contention, balances real-time performance and consistency through hybrid synchronization, and possesses automated elastic scaling of service nodes and failover capabilities, significantly improving system throughput and stability.

Description

Technical Field

[0001] This invention relates to the field of network data processing technology, and in particular to a method and apparatus for handling read and write traffic splitting based on a ride-hailing SaaS platform. Background Technology

[0002] As a core support system connecting drivers, users, and platform management, the chauffeur SaaS platform needs to handle massive amounts of business requests. These include read operations such as user order inquiries, driver order status inquiries, order history inquiries, and platform data statistical analysis, as well as write operations such as order creation, status updates, and driver information maintenance. The chauffeur service is typically characterized by read-heavy and write-light operations, with read requests usually accounting for over 90% and write requests accounting for less than 10%.

[0003] Existing ride-hailing SaaS solutions mostly employ a monolithic architecture or a simple service splitting model, without specific optimizations for the read-heavy, write-light business characteristics. On one hand, read and write requests share the same service node and database resources, leading to high-concurrency read requests consuming a large amount of database connection pool and CPU resources, squeezing the write operation processing channel, causing write operation response delays, and even problems such as order creation failures and untimely status updates. On the other hand, the diversity of read requests (such as real-time queries, historical data queries, statistical queries, etc.) is not differentiated and is uniformly routed to the main database, further increasing the database load, reducing the overall system response speed and stability, and failing to meet the core requirements of high availability and low latency for ride-hailing services. Summary of the Invention

[0004] This invention aims to solve the following technical problems existing in current ride-hailing SaaS in read-heavy, write-light scenarios: First, the performance bottleneck cannot be overcome. Although read and write operations are separated at the service layer, all requests ultimately burden the same database, and the database's CPU, I / O, and connection count remain the system bottlenecks. The ride-hailing business involves frequent state updates, and read and write operations on the same database interfere with each other, leading to lock contention and actually slowing down query speeds.

[0005] Second, flexibility is limited. The chauffeur service experiences a surge in orders during peak hours, and the scalability of a single database is very limited, often requiring hardware upgrades rather than elastic scaling. When new features require changes to the database structure, all services share the same database, making partial deployment impossible and impacting the release schedule.

[0006] Third, the business logic is highly coupled. A single database needs to store data for all business operations, such as orders, drivers, and pricing. The table structure is generic, resulting in low query efficiency and an inability to be specifically optimized for different types of read requests.

[0007] Fourth, existing technologies lack closed-loop monitoring and scheduling for the automated elastic scaling of the number of nodes in the read service cluster and the master-slave switching of the write service. Data synchronization delays are uncontrollable, making it difficult to meet the real-time data requirements of the chauffeur service.

[0008] To address the aforementioned technical problems, one aspect of the present invention provides a method for read / write traffic splitting based on a ride-hailing SaaS platform, comprising: Receive business requests from the designated driver SaaS and, based on preset identification rules, identify the business requests as read requests or write requests; Based on the identification results of the business request, combined with the pre-monitored node load status of the read service cluster and the write service cluster, the read request is distributed to the target read service node in the read service cluster and the write request is distributed to the main write service node in the write service cluster according to the predetermined routing and distribution strategy. The target read service node queries data from its associated slave database to process the read request; the master write service node performs data modification operations on its associated master database to process the write request; wherein, the slave database is a replica database of the master database, used to isolate the data query in response to the read request; After processing, the data in the master database is synchronized to the slave database using a hybrid strategy that combines incremental synchronization and timed full synchronization. The system monitors the operational status of the read service cluster and write service cluster in real time, as well as the data synchronization status of the master database and slave database, and dynamically adjusts the routing distribution strategy, the number of cluster nodes, and / or the data synchronization frequency based on the monitoring results.

[0009] Another aspect of the present invention provides a read / write traffic splitting and processing device based on a ride-hailing SaaS, comprising: The request identification module is used to receive business requests from the ride-hailing SaaS and identify the business requests as read requests or write requests according to preset identification rules. The routing and distribution module is used to distribute the read request to the target read service node in the read service cluster and the write request to the main write service node in the write service cluster according to a predetermined routing and distribution strategy, based on the identification result of the business request and combined with the node load status of the pre-monitored read service cluster and write service cluster. The read / write operation module is used to query data from the associated slave database through the target read service node to process the read request; and to perform data modification operations on the associated master database through the master write service node to process the write request; wherein, the slave database is a replica database of the master database, used to isolate the data query in response to the read request; The data synchronization module is used to synchronize the data of the master database to the slave database after processing is completed using a hybrid strategy that combines incremental synchronization and timed full synchronization. The monitoring and scheduling module is used to monitor the running status of the read service cluster and the write service cluster in real time, as well as the data synchronization status of the master database and the slave database, and dynamically adjust the routing distribution strategy, the number of cluster nodes and / or the data synchronization frequency based on the monitoring results.

[0010] The present invention provides a method and apparatus for handling read / write traffic splitting based on a ride-hailing SaaS platform, which has the following beneficial effects: First, we specifically optimize for scenarios with many reads and few writes. By completely isolating read and write services, read requests query the slave database, while write requests operate on the master database. This avoids read requests consuming write service resources, eliminates read-write lock contention, improves write operation response speed, and simultaneously meets the needs of handling high-concurrency read requests.

[0011] Second, it has strong elastic scalability. The read service cluster supports horizontal scaling, and the monitoring and scheduling module dynamically increases or decreases the number of nodes according to the concurrency of read requests without modifying the core architecture; the write service cluster adopts a master-slave mode and supports automatic failover to ensure high availability.

[0012] Third, data consistency and real-time performance are balanced. A hybrid strategy combining incremental synchronization and periodic full synchronization is adopted. Incremental synchronization ensures real-time data updates, while periodic full synchronization periodically calibrates master-slave data consistency to meet the timeliness requirements of the ride-hailing business.

[0013] Fourth, load balancing and intelligent scheduling. The monitoring and scheduling module achieves load balancing of the read service cluster, avoiding overload of individual nodes; it supports isolated processing of real-time queries and batch statistical queries on different nodes, improving the overall concurrency processing capability and stability of the system.

[0014] Fifth, high availability and disaster recovery mechanism. When the write service master node fails, it automatically switches to the standby node. During the switchover, write requests are temporarily stored in the local message queue and re-executed in the original order after the new master node is ready, ensuring that no write operations are lost. When the database synchronization delay exceeds the threshold, it automatically degrades to ensure data accuracy. Attached Figure Description

[0015] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart illustrating a read / write traffic splitting method based on a ride-hailing SaaS provided in one embodiment of this application; Figure 2This is a schematic diagram of the structure of a read / write traffic splitting and processing device based on a ride-hailing SaaS according to an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] I. Definition of Key Terms To make the technical solution of the present invention clearer, the key technical terms involved in the present invention are first defined and explained.

[0018] Designated driver SaaS: This refers to a dedicated software service platform for designated driver services built on the Software as a Service (SaaS) model. Under this model, designated driver service operators do not need to build and maintain their own underlying hardware and software infrastructure. Instead, they subscribe to and use a designated driver business management system deployed in the cloud via the Internet on demand, and obtain full-process software function services, including order management, driver dispatch, billing and settlement, and data statistics, according to the service level agreement.

[0019] Read requests: These refer to query requests in a ride-hailing SaaS that do not require data modification, including but not limited to order queries, driver information queries, price queries, and historical data statistics.

[0020] Write request: refers to a business request in a ride-hailing SaaS that requires data modification, including but not limited to order creation, order status update, driver information modification, and user account operations.

[0021] Read service cluster: A cluster consisting of multiple read service nodes. Each read service node deploys an independent read service instance (i.e., a read server), shares database resources, and is dedicated to handling read requests. Read service nodes support horizontal scaling, and the number of nodes can be dynamically increased or decreased according to concurrency levels.

[0022] Write service cluster: A cluster consisting of one primary write service node and multiple standby write service nodes. The primary write service node deploys an independent write service instance (i.e., a write server) to handle all write requests. The standby nodes synchronize the status of the primary node in real time to ensure rapid failover in case of primary node failure. The write service nodes deploy the primary database to guarantee the atomicity of write operations and data consistency.

[0023] Primary database: The database associated with the write service cluster, used to persist data generated by write operations, and is the sole entry point for data writing. All write operations (such as create, update, delete, etc.) are performed on the primary database.

[0024] The slave database is a replica of the primary database, associated with the read service cluster. It is used to isolate data queries in response to read requests. The slave database obtains data changes from the primary database through a data synchronization mechanism and does not directly accept write operations.

[0025] Target read service node: The specific read service node that the routing and distribution module dynamically selects from the read service cluster based on the load balancing strategy to handle the current read request.

[0026] Primary write service node: The write service node in the write service cluster that is currently in primary mode and is responsible for handling all write requests.

[0027] Routing and distribution strategy: A set of rules that distribute requests to appropriate service nodes based on factors such as request type and cluster load status. For read requests, strategies such as round-robin, weighted round-robin, and least connections can be used; for write requests, they are always distributed to the current primary write service node.

[0028] Incremental synchronization: A data synchronization method that captures data change operations (such as insert, update, delete, etc.) in the master database in real time and applies these changes to the slave database to achieve near real-time data consistency between the master and slave databases.

[0029] Scheduled full synchronization: A data synchronization method that replicates all data from the master database to the slave database according to a preset time period. This is used to calibrate data deviations that may occur during incremental synchronization and ensure eventual consistency between the master and slave databases.

[0030] Monitoring and scheduling module: This module is responsible for real-time monitoring of the running status of the read service cluster and write service cluster (such as node load, request response time, error rate, etc.) as well as the data synchronization status of the master and slave databases, and dynamically adjusting the routing distribution strategy, the number of cluster nodes and / or the data synchronization frequency based on the monitoring results.

[0031] Failover: When the primary write service node fails, the system automatically elects a new primary write service node from multiple backup write service nodes and transfers the right to receive and process write requests to the new primary node.

[0032] Degraded Node: When the synchronization delay of a slave database exceeds a preset threshold, the read service node corresponding to that slave database is marked as a degraded node, restricting it to only handle non-real-time query requests that do not have high requirements for data real-time performance (such as historical order statistics), while real-time query requests are switched to other slave databases that are synchronized normally.

[0033] II. Method Examples This embodiment details a method for handling read / write traffic splitting based on a ride-hailing SaaS platform. For example... Figure 1 As shown, the method mainly includes the following steps.

[0034] Step S101: Receive and identify the service request.

[0035] In existing ride-hailing SaaS systems, all business requests are received and processed uniformly. The system cannot distinguish between read and write operations, making it impossible to implement targeted routing and resource allocation strategies. In this step, the system receives business requests from the ride-hailing SaaS. These requests can be user-initiated order inquiries and order creation requests, driver-initiated order status inquiries and driver location update requests, or platform management-initiated order statistics and data analysis requests.

[0036] The system identifies the type of each business request based on preset recognition rules. These rules include, but are not limited to: HTTP request method identification: GET method usually corresponds to read request, while POST, PUT, and DELETE methods usually correspond to write request.

[0037] Interface path keyword recognition: Interface paths containing keywords such as "query", "get", "list", and "search" are identified as read requests; those containing keywords such as "create", "update", "delete", "modify", and "cancel" are identified as write requests.

[0038] Request parameter feature identification: For some requests that cannot be distinguished by the above rules, further analysis is conducted to determine whether the request parameters contain modifyable data fields, such as order status change fields or driver information modification fields, and then they are determined to be write requests.

[0039] Using the above identification rules, the system can accurately mark each business request as a "read request" or a "write request", and optionally attach request feature tags, such as real-time requirements (high real-time / low real-time) and request priority (high priority / normal).

[0040] This step enables automatic and accurate identification of business request types, providing a decision-making basis for subsequent routing and service isolation. Compared to existing technologies that manually configure read / write separation or do not differentiate between types, this invention achieves automated, low-latency request classification through a rule engine, with high identification accuracy and support for dynamically expanding identification rules.

[0041] Step S102: Distribute routes based on load status.

[0042] In existing technologies, requests are typically distributed simply by round-robin or randomly, without considering the current load status of each service node. This may result in some nodes being overloaded while others are idle, affecting overall processing capacity. In this step, based on the identification results of step S101 and combined with the pre-monitored node load status of the read service cluster and write service cluster, the system distributes read requests to the target read service node in the read service cluster and write requests to the primary write service node in the write service cluster according to a predetermined routing distribution strategy.

[0043] Specifically: (1) Routing of read requests The system maintains real-time load metrics for each read service node in the read service cluster, including but not limited to: the number of requests currently being processed (active connections), CPU utilization, memory utilization, and average response time. The routing and distribution module selects the optimal target read service node based on the load balancing strategy.

[0044] The load balancing strategies supported by this invention include: Round-robin strategy: Distributes requests sequentially to each read service node, suitable for scenarios where node performance is similar.

[0045] Weighted round-robin strategy: Configure a weight for each read service node (the weight value can be dynamically adjusted based on the node's hardware configuration or real-time performance), and distribute requests according to the weight ratio. This is suitable for scenarios where the nodes have different performance levels.

[0046] Least Connections Strategy: Select the read service node with the fewest active connections to adaptively balance the load, which is especially suitable for scenarios with large differences in request processing time.

[0047] Furthermore, this step also supports fine-grained routing based on request characteristics. For example, for query requests with high real-time requirements (such as "real-time location of nearby drivers"), they are preferentially distributed to high-performance nodes with lower loads; for batch statistical query requests (such as "summary of orders in the past week"), they are distributed to dedicated nodes that handle batch queries to avoid interference with real-time queries.

[0048] (2) Route dispatch of write requests The routing rules for write requests are relatively fixed: all write requests must be distributed to the node currently elected as the primary write service node in the write service cluster. This is because the write service cluster adopts a master-slave mode; only the primary write service node can process write requests and modify the primary database. Standby nodes only serve as hot standby nodes and do not directly process write requests.

[0049] The system maintains the identity information of the current master write service node through a heartbeat detection mechanism and a distributed consensus protocol (such as Raft). When the routing and distribution module receives a write request, it directly queries the local cache of the current master node address and forwards the write request to that node.

[0050] This step enables load-aware distribution of requests, avoiding single-point overload issues; fixed routing for write requests ensures the uniqueness and consistency of data writes; fine-grained routing enables different types of read requests to receive differentiated quality of service guarantees, significantly improving the overall system throughput.

[0051] Step S103: Process the request through the read service node and the write service node respectively.

[0052] This step aims to address the technical problem in existing technologies where read and write operations share the same database resources, leading to lock contention and resource contention. When read and write operations are executed concurrently on the same database, the database's row locks and table locks can cause read operations to be blocked by write operations, or write operations to wait for read operations to release locks, severely impacting system performance. In this step, the requests distributed by the system through step S102 are processed by the corresponding service nodes.

[0053] Specifically: (1) Read request processing Upon receiving a read request, the target read service node directly establishes a connection with its associated slave database and executes the query operation. The slave database is a replica of the master database, storing all or part of the data from the master database. Because the slave database is only used to respond to read requests and does not accept any write operations, read requests are not affected by write operation locks, resulting in fast query response times.

[0054] (2) Write request processing After receiving a write request, the primary write service node performs data modification operations on its associated primary database. The primary database is the sole entry point for data writing; all write operations (insert, update, delete, etc.) are completed here. The primary database must guarantee the atomicity, consistency, isolation, and durability of write operations, ensuring the correctness and reliability of data modifications.

[0055] After the write request is processed, the primary write service node triggers the subsequent data synchronization process (i.e., step S104). Specifically, after the transaction is committed, the primary write service node sends the data change information (change type, data before and after the change, change timestamp, etc.) to the data synchronization module, which is responsible for propagating the changes to the slave database.

[0056] This step achieves physical read-write isolation by distributing read and write operations to different databases, completely eliminating read-write lock contention. The query performance of read service nodes is no longer affected by write operations, and write operations no longer need to wait for read queries to complete, significantly improving the overall system response speed and stability. Using the slave database as a replica of the master database ensures data readability while also providing redundant backups for the master database.

[0057] Step S104: Use a hybrid strategy to synchronize data in the master and slave databases.

[0058] This step aims to address the technical problem of existing technologies having a single data synchronization method that cannot simultaneously guarantee real-time performance and consistency. There are two common synchronization methods: real-time synchronization ensures near real-time data updates, but may lead to data inconsistency under network fluctuations or high slave database load; scheduled batch synchronization guarantees eventual consistency, but has poor real-time performance. The ride-hailing service has high requirements for data real-time performance (e.g., driver location updates need to be seen by passengers as quickly as possible), while also requiring eventual data accuracy (e.g., order amounts must be accurate).

[0059] In this step, the system adopts a hybrid strategy that combines incremental synchronization with timed full synchronization to synchronize data from the master database to the slave database.

[0060] (1) Incremental synchronization strategy Incremental synchronization is used to synchronize data changes generated by write operations in real time. Its working principle is as follows: When the master database performs a write operation, it generates a binary log file that records the details of each data change (such as insert statements, field values ​​before and after updates, delete operations, etc.). The data synchronization module, acting as a client to the master database, pulls these binary logs in real time, parses the data change events within them, and then applies these events to the slave database in the same order, thereby ensuring that the data state of the slave database is consistent with that of the master database.

[0061] This invention employs an incremental synchronization strategy, transmitting only the changed data portions, resulting in low network overhead and high real-time performance. The slave database can reflect the latest state of the master database in near real-time. Furthermore, by optimizing the network transmission efficiency of the synchronization link and implementing a batch application mechanism, the synchronization latency is controlled to within 100ms, meeting the core real-time data requirements of the ride-hailing service.

[0062] (2) Timed full synchronization Scheduled full synchronization is used to periodically calibrate the data consistency between master and slave databases. While incremental synchronization can handle most data changes, it may lead to inconsistency between master and slave data in the following situations: Scenario 1: A network interruption or data packet loss occurs during incremental synchronization, resulting in some changes not being applied; Scenario 2: After recovering from a database failure, there may be omissions in the incremental synchronization breakpoint resume mechanism; Scenario 3: Differences in the table structure or storage engine of the master and slave databases prevent certain changes from being applied correctly incrementally.

[0063] To address the aforementioned issues, the system of this invention performs a full synchronization once every preset time period (e.g., during the early morning off-peak business hours). During the full synchronization process, the data synchronization module exports all data (or data from specified core tables) from the master database and then uses this data to completely replace the corresponding data in the slave database. After the full synchronization is completed, the data in the master and slave databases reaches 100% consistency. By adopting a timed full synchronization strategy, the data deviations accumulated during incremental synchronization can be completely corrected, ensuring eventual data consistency; the frequency of full synchronization can be dynamically adjusted according to the business's sensitivity to consistency.

[0064] The hybrid strategy employed in this step works as follows: incremental synchronization runs continuously, ensuring near real-time propagation of daily data updates; and scheduled full synchronization is executed periodically as a fallback calibration mechanism. These two synchronization methods complement each other, guaranteeing both real-time performance and eventual consistency. In this way, data with high real-time requirements, such as driver location updates and order status changes, is rapidly propagated through incremental synchronization, allowing passengers to see the driver's latest location within one second; while critical data such as order amounts and user account balances are periodically calibrated through full synchronization, ensuring that minor deviations in incremental synchronization do not lead to accounting errors. This hybrid strategy achieves a better balance between consistency and real-time performance, offering greater fault tolerance than a pure incremental synchronization solution and higher real-time performance than a pure full synchronization solution.

[0065] Step S105: Monitoring, scheduling, and dynamic adjustment.

[0066] This step aims to address the technical problem of existing technologies lacking closed-loop monitoring and adaptive tuning capabilities for system operation. In existing solutions, configurations such as routing strategies, cluster size, and synchronization frequency are typically static and cannot be dynamically adjusted based on real-time load changes and fault conditions, leading to insufficient processing capacity during peak periods or resource waste during off-peak periods.

[0067] In this step, the system collects various operational data in real time through the monitoring and scheduling module, and automatically adjusts the system configuration based on preset rules and thresholds. The specific content of the monitoring and scheduling includes: (1) Node load scheduling The monitoring and scheduling module continuously monitors the load metrics of each node in the read service cluster (such as CPU utilization, memory utilization, current request count, and average response time). When the load of any node exceeds a preset threshold (e.g., CPU utilization > 80%), the routing and distribution module will temporarily demote or remove that node from the load balancing pool and automatically distribute subsequent requests to other low-load nodes. Once the node's load returns to normal, it will be added back to the load balancing pool.

[0068] (2) Flexible scaling scheduling The monitoring and scheduling module tracks the overall request concurrency of the read service cluster. When the concurrency continuously increases beyond a predetermined threshold (e.g., requests per second exceed 80% of the node's capacity limit for 5 consecutive minutes), the system automatically triggers a scaling-up command: sending a request to the container orchestration platform or cloud service provider's API to create new read service node instances and registering the new nodes to the read service cluster. Conversely, when the concurrency consistently falls below the scaling-down threshold, the system automatically triggers scaling-down, taking redundant read service nodes offline to conserve resources.

[0069] (3) Adjustment of data synchronization frequency The monitoring and scheduling module monitors the data synchronization latency between the master and slave databases. Under normal conditions, incremental synchronization uses the default frequency parameters (e.g., pulling logs every 100ms). When the synchronization latency is detected to be consistently lower than the target value (e.g., <20ms) and the write load on the master database is low, the synchronization frequency can be appropriately reduced to decrease network overhead. When the synchronization latency is detected to be increased (e.g., >80ms), the synchronization frequency is automatically increased or the number of synchronization threads is increased to accelerate data propagation.

[0070] (4) Exception handling and downgrading When the monitoring and scheduling module detects that the synchronization latency of any slave database exceeds a preset latency threshold (e.g., 200ms), it determines that the slave database is in a stale state. At this time, the system marks the corresponding read service node of that slave database as a degraded node, restricting it to handling only non-real-time query requests with low data real-time requirements, such as historical order statistics and report queries. For real-time query requests, such as real-time driver location and latest order status, the routing and distribution module will automatically switch to other slave databases with normal synchronization latency (i.e., below the preset latency threshold). This degradation mechanism ensures the accuracy of real-time query data while preventing the entire read service from becoming unavailable due to the failure of a single slave database.

[0071] (5) Write service master node failover The monitoring and scheduling module continuously detects the health status of the primary write service node through a heartbeat mechanism. When multiple consecutive heartbeat timeouts occur or a node anomaly report is received, the primary write service node is determined to have failed. The system immediately initiates the failover process. A new primary write service node is automatically elected from multiple backup write service nodes based on a distributed consensus protocol.

[0072] During the switchover, incoming write requests cannot be processed. To prevent write requests from being lost, the system temporarily stores these write requests in a local message queue, with each request being queued in the order of arrival.

[0073] Once the new primary write service node is ready, the system resends the write requests in the message queue to the new primary write service node in the original order, and the new node re-executes these write operations. During the re-execution process, the system handles potential duplicate execution issues, such as ensuring consistent results from multiple executions of the same request through idempotency design.

[0074] This step achieves end-to-end adaptive tuning, enabling the system to automatically adjust resource allocation based on real-time load, maximizing resource utilization while ensuring service quality; automatic failover and request replay mechanisms ensure high system availability, preventing write operations from being lost due to single points of failure; and the database degradation mechanism avoids the impact of outdated data on core business operations.

[0075] To better understand this invention, the following example, using a specific chauffeur service operation scenario, fully demonstrates the entire process of the method of this invention, from request access to processing completion. This embodiment is merely illustrative and does not constitute a limitation on the scope of protection of this invention.

[0076] (1) Scene The applicant deployed the read / write traffic splitting system of this invention on a ride-hailing service platform. The system configuration is as follows: the read service cluster contains 4 read service nodes (nodes R1, R2, R3, and R4), each node is connected to the same slave database cluster (containing 2 slave database instances S1 and S2); the write service cluster contains 1 master write service node. and 2 backup nodes , The main database is The data synchronization module is configured with an incremental synchronization latency target of 100ms and a scheduled full synchronization cycle of 3:00 AM every day; the monitoring and scheduling module has a load threshold of 75% CPU, a capacity expansion threshold of 80% of the node capacity per second when the number of requests per second exceeds 80%, and a synchronization latency degradation threshold of 200ms.

[0077] (2) Timeline 19:00: The evening rush hour begins, and user activity on the ride-hailing platform increases. The system receives a location update request from the driver's app, which reports the driver's current latitude and longitude. The system request identification module parses the HTTP method as POST and the interface path as / driver / location / update, determining it to be a write request. The routing and distribution module queries the current main write service node address... Distribute the request to . Receive request in the main database The update operation is performed, updating the latitude and longitude fields of the corresponding driver, and the transaction is committed. Subsequently, Trigger the data synchronization module. The data synchronization module starts from... The update event was captured in the binary log, and the changes were synchronized to databases S1 and S2 after 45ms via an incremental synchronization mechanism.

[0078] 19:05: The user app initiates a "Nearby Driver Query" request. The request identification module determines it to be a read request. The routing and distribution module obtains the load of each node in the read service cluster: R1 currently has 120 connections and 45% CPU usage; R2 has 115 connections and 43% CPU usage; R3 has 200 connections and 78% CPU usage (exceeding the threshold); R4 has 90 connections and 35% CPU usage. The monitoring and scheduling module has marked R3 as being under high load. The routing and distribution module uses a minimum connection strategy, selecting R4 as the target read service node. R4 queries the database S1 for nearby driver location information. At this time, S1's data has been synchronized with the driver location update from 3 seconds ago, and the query result is accurate. R4 returns the result to the user, with a response time of only 18ms.

[0079] 19:10: The user initiates an order request. The request is identified as a write request and routed to... . In the main database Create a new order record in the slave database, inserting fields such as order number, user ID, origin and destination, and estimated price. After the transaction is committed, the data synchronization module will synchronize the new order record to the slave database within 60ms.

[0080] 19:15: The driver polls the "New Order Notification" interface (read request). The routing module distributes the request to the R2 node with the lowest load. R2 queries the database S2 for the currently assigned unaccounted orders to that driver. Since S2 has already obtained the new order data through incremental synchronization, the driver can see the new orders immediately.

[0081] 19:20: The driver accepts the order and sends an order status update request (write request to change the order status from "pending order" to "order accepted"). The write request is processed, and the primary database is updated. The data synchronization module captures the changes and synchronizes them to the secondary database.

[0082] 19:25: Main write service node The physical machine suddenly crashed. The heartbeat detection of the monitoring and scheduling module timed out three times consecutively (each time with a 1-second interval), and a decision was made. Fault. The system immediately initiates failover: In , China conducts elections based on the Raft protocol. It won the majority of votes and became the new main write service node. The switching process took 2.8 seconds. During this period, the system received 15 write requests (including order status updates, driver location updates, etc.), which were temporarily stored in the local message queue and queued in a first-in, first-out order. Once ready, the system retrieves 15 write requests from the message queue in sequence and resends them to the appropriate department in the original order. . Re-execute these write operations to ensure that no order status changes have been lost.

[0083] 19:30: Due to a surge in read requests during the evening peak, the monitoring and scheduling module reported an average of 3500 requests per second over the past 5 minutes. The total capacity of the four read service nodes was approximately 4000 QPS (1000 QPS per node), resulting in a load of 87.5%. The monitoring and scheduling module determined that the capacity had exceeded the expansion threshold (80%) and automatically sent an API request to the cloud container platform to create two new read service nodes, R5 and R6. The new nodes started up within 30 seconds and automatically registered with the read service cluster. After successful registration, the routing and distribution module began distributing some read requests to R5 and R6, increasing the overall cluster QPS capacity to 6000.

[0084] 19:35: Due to network jitter, the incremental synchronization latency between database S2 and the primary database increased to 250ms, exceeding the degradation threshold of 200ms. Upon detection, the monitoring and scheduling module immediately marked the read service nodes (R2 and R3) corresponding to S2 as degraded nodes. Subsequent real-time query requests received by the routing and distribution module (such as "nearest driver query" and "order real-time status") were no longer distributed to R2 and R3, but instead switched to the nodes R1, R4, R5, and R6 corresponding to S1. R2 and R3 were only allowed to process non-real-time query requests (such as "historical order statistics"). One minute later, the network recovered, the synchronization latency of S2 dropped to 50ms, the monitoring and scheduling module removed the degradation mark, and R2 and R3 resumed normal service.

[0085] 20:00: The evening peak gradually subsided, and the concurrent read requests dropped to 1500 QPS. The monitoring and scheduling module detected that the load had been below the scaling-down threshold (40%) for 15 consecutive minutes, and automatically triggered scaling down, taking two temporary nodes, R5 and R6, offline. The read service cluster was restored to 4 nodes.

[0086] At 3:00 AM the following day: The data synchronization module starts a scheduled full synchronization task. The system retrieves data from the main database. All core table data (order table, driver table, user table, etc.) was exported, totaling approximately 500GB. During the full synchronization, incremental synchronization continued, and new changes were recorded in the change log. After the full synchronization was complete, the system applied the new changes recorded in the change log to the slave database, ensuring that the data in the slave database was completely consistent with the master database. This full synchronization took 35 minutes and corrected three minor data discrepancies caused by an incremental synchronization anomaly the previous day.

[0087] As can be seen from the above embodiments, the method of the present invention can automatically complete request identification, load-aware routing, read-write isolation processing, hybrid strategy data synchronization, and end-to-end monitoring, scheduling, and fault recovery in the real operation scenario of a chauffeur service platform. The average response time for read requests is reduced from 120ms in the original architecture to 25ms, the success rate of write requests is increased from 99.2% to 99.97%, the peak throughput of the system is increased by 3 times, and sub-second synchronization of real-time data such as driver location updates is achieved, fully meeting the high availability and low latency requirements of chauffeur services.

[0088] III. Device Examples See Figure 2 In another embodiment of the present invention, a read / write traffic splitting and processing device 200 based on a ride-hailing SaaS is also provided, including a request identification module 201, a routing distribution module 202, a read / write operation module 203, a data synchronization module 204, and a monitoring and scheduling module 205. The read / write traffic splitting and processing device 200 based on a ride-hailing SaaS can execute the read / write traffic splitting and processing method based on a ride-hailing SaaS in the method embodiment.

[0089] Specifically, the read / write traffic offloading and processing device 200 based on the ride-hailing SaaS includes: The request identification module 201 is used to receive business requests from the ride-hailing SaaS and identify the business requests as read requests or write requests according to preset identification rules. The routing and distribution module 202 is used to distribute the read request to the target read service node in the read service cluster and the write request to the main write service node in the write service cluster according to a predetermined routing and distribution strategy, based on the identification result of the business request and combined with the node load status of the read service cluster and the write service cluster that has been monitored in advance. The read / write operation module 203 is used to query data from the associated slave database through the target read service node to process the read request; and to perform data modification operations on the associated master database through the master write service node to process the write request; wherein, the slave database is a replica database of the master database, used to isolate the data query in response to the read request; The data synchronization module 204 is used to synchronize the data of the master database to the slave database after processing through a hybrid strategy that combines incremental synchronization and timed full synchronization. The monitoring and scheduling module 205 is used to monitor the running status of the read service cluster and the write service cluster in real time, as well as the data synchronization status of the master database and the slave database, and dynamically adjust the routing distribution strategy, the number of cluster nodes and / or the data synchronization frequency based on the monitoring results.

[0090] It should be noted that the technical solutions corresponding to the read / write traffic splitting and processing device 200 based on the chauffeur SaaS provided in this embodiment, which can be used to execute various method embodiments, have similar implementation principles and technical effects to the methods, and will not be repeated here.

[0091] Figure 3 This is a schematic diagram of an electronic device 300 provided in another embodiment of the present invention. The electronic device 300 is used to implement the read / write traffic splitting method based on a ride-hailing SaaS in the method embodiment. The electronic device 300 in the embodiments of the present invention may include, but is not limited to, smartphones, tablets, PCs, laptops, servers, etc. Figure 3 The electronic device 300 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0092] like Figure 3As shown, the electronic device 300 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes to implement the methods of the embodiments described herein, based on a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing device 301, ROM 302, and RAM 303 are interconnected via a bus 305. An input / output (I / O) interface 304 is also connected to the bus 305.

[0093] Typically, the following devices can be connected to I / O interface 304: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0094] The above description is merely a preferred embodiment of the present invention. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to the specific combination of the above-described technical features, but should also cover other technical solutions formed by any combination of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

Claims

1. A method for handling read / write traffic splitting based on a ride-hailing SaaS platform, characterized in that, Includes the following steps: Receive business requests from the designated driver SaaS and, based on preset identification rules, identify the business requests as read requests or write requests; Based on the identification results of the business request, combined with the pre-monitored node load status of the read service cluster and the write service cluster, the read request is distributed to the target read service node in the read service cluster and the write request is distributed to the main write service node in the write service cluster according to the predetermined routing and distribution strategy. The target read service node queries data from its associated database to process the read request; The primary write service node performs data modification operations on the primary database associated with it to process the write request; wherein, the secondary database is a replica database of the primary database, used to isolate data queries in response to read requests; After processing, the data in the master database is synchronized to the slave database using a hybrid strategy that combines incremental synchronization and timed full synchronization. The system monitors the operational status of the read service cluster and write service cluster in real time, as well as the data synchronization status of the master database and slave database, and dynamically adjusts the routing distribution strategy, the number of cluster nodes, and / or the data synchronization frequency based on the monitoring results.

2. The method for handling read / write traffic splitting based on a ride-hailing SaaS according to claim 1, characterized in that, The step of distributing the read request to the target read service node in the read service cluster according to a predetermined routing distribution strategy includes: Based on the type or real-time requirements of the read request, real-time query requests for designated driver orders are distributed to high-performance nodes in the read service cluster, and historical query requests for designated driver orders are distributed to dedicated nodes in the read service cluster; wherein, the read service cluster uses a round-robin or least-connection strategy to achieve load balancing.

3. The method for handling read / write traffic splitting based on a ride-hailing SaaS according to claim 1, characterized in that, Also includes: When a failure of the primary write service node is detected, a new primary write service node is automatically determined from multiple backup write service nodes to take over the write requests. During the failover period between the old and new primary write service nodes, the write requests are temporarily stored in a local message queue. Once the new primary write service node is ready, the write requests in the local message queue are resent to the new primary write service node in the original order.

4. The method for read / write traffic splitting based on a ride-hailing SaaS according to claim 1, characterized in that, The incremental synchronization is used to synchronize data changes generated by write operations in real time, and the timed full synchronization is used to periodically calibrate the data consistency of the master and slave databases.

5. The method for read / write traffic splitting based on a ride-hailing SaaS according to claim 1, characterized in that, The steps of dynamically adjusting the routing distribution strategy, the number of cluster nodes, and / or the data change synchronization frequency based on monitoring results include: When the load of any node in the read service cluster exceeds the threshold, subsequent read requests will be automatically distributed to other low-load nodes; When the concurrent read requests continue to grow beyond a predetermined threshold, an expansion command for the read service cluster is automatically triggered to increase the number of read service nodes. When the synchronization latency of any slave database exceeds the preset latency threshold, the read service node corresponding to that slave database is marked as a degraded node, which is restricted to handling only non-real-time query requests, and real-time query requests are switched to other slave databases whose synchronization latency does not exceed the preset latency threshold.

6. A read / write traffic splitting and processing device based on a ride-hailing SaaS platform, characterized in that, include: The request identification module is used to receive business requests from the ride-hailing SaaS and identify the business requests as read requests or write requests according to preset identification rules. The routing and distribution module is used to distribute the read request to the target read service node in the read service cluster and the write request to the main write service node in the write service cluster according to a predetermined routing and distribution strategy, based on the identification result of the business request and combined with the node load status of the pre-monitored read service cluster and write service cluster. The read / write operation module is used to query data from the associated database through the target read service node to process the read request; The primary write service node performs data modification operations on the primary database associated with it to process the write request; wherein, the secondary database is a replica database of the primary database, used to isolate data queries in response to read requests; The data synchronization module is used to synchronize the data of the master database to the slave database after processing is completed using a hybrid strategy that combines incremental synchronization and timed full synchronization. The monitoring and scheduling module is used to monitor the running status of the read service cluster and the write service cluster in real time, as well as the data synchronization status of the master database and the slave database, and dynamically adjust the routing distribution strategy, the number of cluster nodes and / or the data synchronization frequency based on the monitoring results.

7. The read / write traffic splitting and processing device based on chauffeur SaaS according to claim 6, characterized in that, The routing distribution module is further used for: Based on the type or real-time requirements of the read request, real-time query requests for designated driver orders are distributed to high-performance nodes in the read service cluster, and historical query requests for designated driver orders are distributed to dedicated nodes in the read service cluster; wherein, the read service cluster uses a round-robin or least-connection strategy to achieve load balancing.

8. The read / write traffic splitting and processing device based on chauffeur SaaS according to claim 6, characterized in that, The monitoring and scheduling module is also used for: When a failure of the primary write service node is detected, a new primary write service node is automatically determined from multiple backup write service nodes to take over the write requests. During the failover period between the old and new primary write service nodes, the write requests are temporarily stored in a local message queue. Once the new primary write service node is ready, the write requests in the local message queue are resent to the new primary write service node in the original order.

9. The read / write traffic splitting and processing device based on chauffeur SaaS according to claim 6, characterized in that, The incremental synchronization is used to synchronize data changes generated by write operations in real time, and the timed full synchronization is used to periodically calibrate the data consistency of the master and slave databases.

10. The read / write traffic splitting and processing device based on chauffeur SaaS according to claim 6, characterized in that, The monitoring and scheduling module is further used for: When the load of any node in the read service cluster exceeds the threshold, subsequent read requests will be automatically distributed to other low-load nodes; When the concurrent read requests continue to grow beyond a predetermined threshold, an expansion command for the read service cluster is automatically triggered to increase the number of read service nodes. When the synchronization latency of any slave database exceeds the preset latency threshold, the read service node corresponding to that slave database is marked as a degraded node, which is restricted to handling only non-real-time query requests, and real-time query requests are switched to other slave databases whose synchronization latency does not exceed the preset latency threshold.

Images