Online car-hailing driver position caching method and system

Abstract

The invention discloses an online car-hailing driver position caching method, which comprises the following steps of: preprocessing a position message reported by a driver, and mapping the preprocessed position message to a space-time key consisting of a geographic unit identifier and a time bucket number; according to a comparison result of the offset of the original timestamp in the corresponding time bucket and a preset threshold value, writing the driver identifier into a cache position identified by one or more continuous space-time keys, and setting uniform survival time for the cache position; in response to a nearby driver query request of the passenger, determining an associated geographic unit set according to a query position, and determining a target time bucket number according to a query moment; and obtaining and returning a nearby driver identifier set by concurrently reading a cache position jointly determined by the geographic unit set and the target time bucket number. A high-performance and extensible solution is provided for systems needing real-time geographic position management, such as online car-hailing and instant distribution.

Description

Technical Field

[0001] This invention relates to the field of ride-hailing technology, and more specifically to a method and system for caching the location of ride-hailing drivers. Background Technology

[0002] As a crucial component of modern urban transportation, ride-hailing platforms play a core role in matching passengers with nearby drivers in real time. To achieve this, the platform needs to continuously receive and maintain massive amounts of driver location information and support low-latency, high-concurrency queries for "nearby drivers." Traditional location management and query solutions are mostly built on general-purpose geospatial databases or caching systems (such as Redis GEO or Sorted Sets), but they face challenges in handling the high concurrency and real-time requirements unique to the ride-hailing scenario. Specifically, ride-hailing drivers typically report their locations to the server at a high frequency (e.g., every 5 to 15 seconds). This high-frequency writing puts enormous write pressure on the backend storage system (a write bottleneck). Even more challenging is the dynamic change of driver status: when a driver goes offline, ends their service, or their status changes, their location data needs to be promptly removed from the cache to avoid displaying invalid driver information to passengers. In existing technical solutions, this data removal often employs an active deletion mechanism, based on the driver's unique identifier (driver...). id The deletion operation is performed. However, in scenarios with millions or even larger numbers of drivers online concurrently, frequent fine-grained deletion operations themselves become a performance bottleneck for the system, increasing the complexity of the write path and potentially causing data inconsistency due to deletion delays.

[0003] Existing technologies offer several solutions attempting to optimize these issues, but none fundamentally resolve the contradictions. Reliance on fine-grained proactive deletion operations: Deletion operations triggered by identifiers when drivers are offline or their status changes become a bottleneck for system performance and complexity in high-concurrency environments. Complex and inefficient query paths: Queries often require data merging across time windows or timestamp filtering at the application layer, increasing read path complexity and response time; performance may decline as data volume increases. Failure to achieve effective orthogonal sharding across spatiotemporal dimensions: Existing solutions fail to completely decouple and independently shard the time and spatial dimensions, making it difficult to simultaneously achieve automatic data expiration and uniform distribution of storage load. This makes it impossible to ensure query continuity while simultaneously considering the system's horizontal scalability and adaptability to hotspot areas. Summary of the Invention

[0004] To overcome the aforementioned technical shortcomings of being unable to eliminate fine-grained data, delete overhead, and simplify query paths, this invention provides a method and system for caching ride-hailing driver locations.

[0005] To solve the above problems, the present invention is implemented according to the following technical solution:

[0006] This invention provides a method for caching the location of ride-hailing drivers, comprising: preprocessing the location messages reported by drivers, the preprocessing including: deduplicating based on driver identifiers to retain the latest location information, and performing timeliness verification based on the original timestamp of the location messages to discard timed-out data; mapping the preprocessed location messages to a spatiotemporal key composed of a geographic unit identifier and a time bucket number, wherein the geographic unit identifier is obtained by spatial encoding the latitude and longitude of the location, and the time bucket number is determined based on the original timestamp and the time window length; writing the driver identifier into a cache location identified by one or more consecutive spatiotemporal keys according to the comparison result of the offset of the original timestamp in the corresponding time bucket and a preset threshold, and setting a uniform lifetime for the cache location; responding to a passenger's request for a nearby driver query, determining the associated set of geographic units based on the query location, and determining the target time bucket number based on the query time; and obtaining and returning a set of nearby driver identifiers by concurrently reading the cache locations jointly determined by the set of geographic units and the target time bucket number.

[0007] Preferably, mapping the preprocessed location message to a spatiotemporal key composed of a geographic unit identifier and a time bucket number specifically includes: generating a geographic unit identifier representing a fixed geographic area based on the latitude and longitude coordinates in the location message; dividing the original timestamp by a preset time window length and rounding the result down to obtain the time bucket number, wherein the time window length is a fixed number of seconds; concatenating or combining the geographic unit identifier and the time bucket number according to a preset rule to generate a unique spatiotemporal key, which is used to locate and store the driver identifier in the cache.

[0008] Preferably, the step of writing the driver identifier into a cache location identified by one or more consecutive spatiotemporal keys based on the comparison result of the offset of the original timestamp within the corresponding time bucket and a preset threshold specifically includes: calculating the offset by taking the modulo operation result of the original timestamp with respect to the length of the time window; if the offset is not greater than the preset threshold, then writing the driver identifier into a first cache location composed of the current time bucket number and the geographic unit identifier; if the offset is greater than the preset threshold, then simultaneously writing the driver identifier into the first cache location composed of the current time bucket number and the geographic unit identifier, and a second cache location composed of the next time bucket number and the geographic unit identifier.

[0009] Preferably, the geographic unit identifier is generated using an H3 grid coding system, an S2 grid coding system, or a GeoHash coding system.

[0010] Preferably, the lifetime of the cache location is set as the sum of the time window length, the preset threshold, and a safety margin, wherein the safety margin is used to compensate for the non-real-time nature of the cache expiration mechanism and network processing latency.

[0011] Preferably, the step of determining the associated set of geographic units based on the query location and obtaining and returning the set of nearby driver identifiers specifically includes: obtaining the geographic unit where the query location is located and its adjacent geographic units within a preset range, which together constitute the set of geographic units; creating concurrent cache read tasks for each spatiotemporal key formed by combining each geographic unit identifier in the set of geographic units with the target time bucket number; aggregating the driver identifiers returned by all concurrent read tasks, performing deduplication, and generating the final set of nearby driver identifiers.

[0012] Another aspect of the present invention provides a ride-hailing driver location caching system for implementing a ride-hailing driver location caching method as described in any one of the preceding aspects, comprising: a preprocessing module, wherein the preprocessing includes: deduplication based on driver identifiers to retain the latest location information, and timeliness verification based on the original timestamp of the location message to discard expired data; and a spatiotemporal mapping module, wherein the preprocessed location message is mapped to a spatiotemporal key composed of a geographic unit identifier and a time bucket number, wherein the geographic unit identifier is obtained by spatial encoding of the location latitude and longitude, and the time bucket number is based on the original timestamp. The time window length is determined; the cache writing module is used to write the driver identifier into a cache location identified by one or more consecutive spatiotemporal keys based on the comparison result of the offset of the original timestamp in the corresponding time bucket and a preset threshold, and set a uniform lifetime for the cache location; the query processing module is used to respond to the passenger's nearby driver query request, determine the associated set of geographic units based on the query location, and determine the target time bucket number based on the query time; and obtain and return the set of nearby driver identifiers by concurrently reading the cache location determined by the set of geographic units and the target time bucket number.

[0013] Preferably, the spatiotemporal mapping module is used to map the preprocessed location message to a spatiotemporal key composed of a geographic unit identifier and a time bucket number. Specifically, it includes: generating a geographic unit identifier representing a fixed geographic area based on the latitude and longitude coordinates in the location message; dividing the original timestamp by a preset time window length and rounding the result down to obtain the time bucket number, wherein the time window length is a fixed number of seconds; and concatenating or combining the geographic unit identifier and the time bucket number according to a preset rule to generate a unique spatiotemporal key for locating and storing the driver identifier in the cache.

[0014] Preferably, the cache writing module is used to write the driver identifier into a cache location identified by one or more consecutive spatiotemporal keys based on a comparison result of the offset of the original timestamp within the corresponding time bucket and a preset threshold. Specifically, this includes: calculating the offset by taking the modulo operation result of the original timestamp with respect to the time window length; if the offset is not greater than the preset threshold, writing the driver identifier into a first cache location composed of the current time bucket number and the geographic unit identifier; if the offset is greater than the preset threshold, writing the driver identifier into both the first cache location composed of the current time bucket number and the geographic unit identifier, and a second cache location composed of the next time bucket number and the geographic unit identifier; the geographic unit identifier is generated using an H3 grid encoding system, an S2 grid encoding system, or a GeoHash encoding system; the lifetime of the cache location is set as the sum of the time window length, the preset threshold, and a safety margin, wherein the safety margin is used to compensate for the non-real-time nature of the cache expiration mechanism and network processing latency.

[0015] Preferably, the query processing module, used to determine the associated set of geographic units based on the query location and obtain and return a set of nearby driver identifiers, specifically includes: obtaining the geographic unit where the query location is located and its adjacent geographic units within a preset range, which together constitute the set of geographic units; creating concurrent cache read tasks for each spatiotemporal key formed by combining each geographic unit identifier in the set of geographic units with the target time bucket number; aggregating the driver identifiers returned by all concurrent read tasks, performing deduplication, and generating the final set of nearby driver identifiers.

[0016] Compared with the prior art, the beneficial effects of the present invention are:

[0017] The traditional driver-identity-based active deletion mechanism has been abandoned in favor of a coarse-grained data organization method based on spatiotemporal keys, with a uniform lifetime set for each cache location. When a driver goes offline or their status changes, no deletion command needs to be executed; their old data is automatically and batch-cleaned by the caching system. This solves the performance bottlenecks, write amplification, and system complexity issues caused by frequent deletion operations in scenarios with millions of concurrent connections, making the write path simple, efficient, and stable. The complex "nearby drivers" query is transformed into directly calculating a set of deterministic "spatiotemporal keys" based on the query location and time, and then concurrently reading and simply aggregating these keys. Query performance is no longer related to the total number of online drivers, but only to the number of geographical units covered by the query radius (i.e., the number of spatiotemporal keys that need to be read). Complex time window merging or real-time timestamp filtering is eliminated during queries, simplifying business logic and reducing the probability of errors. Based on the offset of the reported time within the time bucket, the driver identifier may be written to the current and next time buckets to cover time boundaries. The spatiotemporal key sharding method allows data to be evenly distributed across the cache cluster, making it easy to expand system capacity by adding nodes and effectively avoiding hotspot issues. Different geographical regions (grids) and time slices are mapped to different cache keys, achieving a natural distribution of storage and access pressure. This method transforms the massive, high-frequency writes, high-concurrency, low-latency queries, and dynamic real-time data invalidation in ride-hailing scenarios into batch read and write operations on a limited number of cache keys with fixed structures. Attached Figure Description

[0018] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings, wherein:

[0019] Figure 1 This is a flowchart of a ride-hailing driver location caching method according to the present invention. Detailed Implementation

[0020] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0021] Example 1:

[0022] like Figure 1As shown, the present invention provides a method for caching the location of ride-hailing drivers, comprising: preprocessing the location messages reported by drivers, the preprocessing including: deduplicating based on driver identifiers to retain the latest location information, and performing timeliness verification based on the original timestamp of the location messages to discard timed-out data; mapping the preprocessed location messages to a spatiotemporal key composed of a geographic unit identifier and a time bucket number, wherein the geographic unit identifier is obtained by spatial encoding of the location's latitude and longitude, and the time bucket number is determined based on the original timestamp and the time window length; writing the driver identifier into a cache location identified by one or more consecutive spatiotemporal keys according to the comparison result of the offset of the original timestamp within the corresponding time bucket and a preset threshold, and setting a uniform lifetime for the cache location; responding to a passenger's request for a nearby driver query, determining the associated set of geographic units based on the query location, and determining the target time bucket number based on the query time; and obtaining and returning a set of nearby driver identifiers by concurrently reading the cache locations jointly determined by the set of geographic units and the target time bucket number.

[0023] Specifically, the traditional driver-based active deletion mechanism is abandoned in favor of a coarse-grained data organization method based on spatiotemporal keys, and a uniform lifetime is set for each cache location. This completely eliminates high-frequency fine-grained deletion operations, improving system write performance and stability. When a driver goes offline or changes status, no deletion command needs to be executed. Their old data will be automatically and batch-cleaned by the cache system. This solves the performance bottleneck, write amplification, and system complexity problems caused by frequent deletion operations in scenarios with millions of concurrent connections, making the write path simple, efficient, and stable. The complex "nearby drivers" query is transformed into directly calculating a set of definite "spatiotemporal keys" based on the query location and query time, and then concurrently reading and simply aggregating these keys. The query performance is no longer related to the total number of online drivers, but only depends on the number of geographical units covered by the query radius (i.e., the number of spatiotemporal keys that need to be read), achieving a stable query with an approximate O(1) time complexity. Reading multiple spatiotemporal keys can be performed in parallel, making full use of system resources, significantly reducing response time, and easily handling instantaneous high-concurrency query requests. Eliminating the need for complex time window merging or real-time timestamp filtering during queries simplifies business logic and reduces the probability of errors. It achieves extremely simplified query paths and predictable low latency, ensuring high-concurrency query performance. Through "spatiotemporal orthogonal sharding" and "interleaved writing" strategies, it cleverly balances data continuity, accuracy, and automatic expiration requirements. Decoupling space (geographic grid) and time (time window) into two-dimensional shards naturally distributes data load. Based on the offset of the reporting time within the time bucket, the driver's identifier may be written to the current and next time bucket to cover time boundaries. "Interleaved writing" ensures that the driver's reported position near the time bucket boundary remains visible in the next query cycle, avoiding data "holes" caused by the reporting rhythm not synchronizing with time bucket segmentation, thus improving the continuity and accuracy of query results. The spatiotemporal key sharding method allows data to be evenly distributed across the cache cluster, easily expanding system capacity by adding nodes and effectively avoiding hotspot issues. Different geographical regions (grids) and time slices are mapped to different cache keys, achieving a natural distribution of storage and access pressure. This method transforms the massive, high-frequency writes, high-concurrency, low-latency queries, and real-time dynamic data invalidation in ride-hailing scenarios into batch read and write operations on a limited number of cache keys with fixed structures.

[0024] In a preferred embodiment, mapping the preprocessed location message to a spatiotemporal key composed of a geographic unit identifier and a time bucket number specifically includes: generating a geographic unit identifier representing a fixed geographic area based on the latitude and longitude coordinates in the location message; dividing the original timestamp by a preset time window length and rounding the result down to obtain the time bucket number, wherein the time window length is a fixed number of seconds; and concatenating or combining the geographic unit identifier and the time bucket number according to a preset rule to generate a unique spatiotemporal key for locating and storing the driver identifier in the cache.

[0025] In a preferred embodiment, the step of writing the driver identifier into a cache location identified by one or more consecutive spatiotemporal keys based on the comparison result of the offset of the original timestamp within the corresponding time bucket and a preset threshold specifically includes: calculating the offset by taking the modulo operation result of the original timestamp with respect to the length of the time window; if the offset is not greater than the preset threshold, then writing the driver identifier into a first cache location composed of the current time bucket number and the geographic unit identifier; if the offset is greater than the preset threshold, then simultaneously writing the driver identifier into the first cache location composed of the current time bucket number and the geographic unit identifier, and a second cache location composed of the next time bucket number and the geographic unit identifier.

[0026] In a preferred embodiment, the geographic unit identifier is generated using an H3 grid encoding system, an S2 grid encoding system, or a GeoHash encoding system. The lifetime of the cached location is set as the sum of the time window length, the preset threshold, and a safety margin, wherein the safety margin is used to compensate for the non-real-time nature of the cache expiration mechanism and network processing latency.

[0027] Understandably, H3 is chosen as an example of a geocoding system in this embodiment. The H3 grid coding system possesses characteristics such as hexagonal grids, multi-level resolution, and good spatial locality, which are beneficial for achieving uniform spatial partitioning and neighborhood queries. Alternatively, S2 grid coding systems, Geometry, GeoHash grid coding systems, QTM, or other spatial indexing methods with hierarchical, deterministic, and computable neighborhood characteristics can also be selected. This invention is based on a coding system that can arbitrarily divide the Earth's surface into discrete, indexable geographic units with neighborhood relationships.

[0028] In a preferred embodiment, the step of determining the associated set of geographic units based on the query location and obtaining and returning a set of nearby driver identifiers specifically includes: obtaining the geographic unit where the query location is located and its adjacent geographic units within a preset range, which together constitute the set of geographic units; creating concurrent cache read tasks for each spatiotemporal key formed by combining each geographic unit identifier in the set of geographic units with the target time bucket number; aggregating the driver identifiers returned by all concurrent read tasks, performing deduplication, and generating the final set of nearby driver identifiers.

[0029] Understandably, in one specific embodiment, the location messages reported by drivers are preprocessed. This preprocessing includes: deduplication based on the driver's identifier to retain the latest location information, and timeliness verification based on the original timestamp of the location message to discard expired data. Specifically, the location reporting preprocessing involves the ride-hailing driver's terminal (e.g., a mobile app) reporting its current location information to the server at a fixed frequency (e.g., every 5-15 seconds). Each location message contains at least the following fields: a unique driver identifier (driver...). id Longitude, latitude, and original timestamp ts ).

[0030] After receiving the location message, the server first performs preprocessing to remove duplicates, ensure freshness, and prevent delays and contamination. Specifically, this includes:

[0031] Deduplication based on driver identifier: In the same batch or within a short period, multiple reports from the same driver may be received (e.g., network retransmissions, batch sending from the client). The system categorizes reports by driver. id Aggregate the records, keeping only the record with the latest original timestamp and discarding the rest of the older records.

[0032] Timeliness verification: To prevent "stale" data from polluting the cache due to network latency or client malfunctions, the system compares the cache with the server's current time. ts ) and the original timestamp in the reported message ts If the difference between the two exceeds the preset maximum delay threshold (e.g., T), max If the time limit is 30 seconds, the message will be discarded and will not proceed to the next processing step.

[0033] The preprocessed valid location data will be mapped to a "spatiotemporal cache key" consisting of a "geographic unit identifier" and a "time bucket number", and whether to write across time buckets will be determined based on the time offset.

[0034] Encode the longitude and latitude of the driver's location using a geospatial coding system (such as H3, S2, or GeoHash) to obtain a fixed-length string as the geospatial unit identifier (denoted as h3_id). For example, using the H3 coding system with a precision of level 10, the Earth's surface can be divided into hexagonal grids with an area of approximately 0.1 square meters, and each grid corresponds to a unique h3_id.

[0035] Define the location valid window time as T (for example, T = 60 seconds). Based on the original timestamp (original ts ) calculate the time bucket number it belongs to:

[0036]

[0037] At the same time, calculate the offset of this timestamp within the bucket:

[0038] M = orginal ts %T

[0039] Set a critical threshold N (for example, N = 10 seconds and N < T). The threshold N is a key parameter of the critical write-ahead mechanism, used to ensure that data reported near the time window switching critical point is not missed. Its setting is based on the following considerations:

[0040] Collect the end-to-end delay of the driver location report through online monitoring (from GPS collection to server reception), and take the 95th percentile (P95) or 99th percentile (P99) delay value (for example, 1.8 seconds) as the basic value of N; N can be set as a certain proportion of the time bucket length T, for example, N = α × T, where α ranges from 0.05 to 0.2. When T is 10 seconds, N can be set to 1 to 2 seconds; the larger N is, the higher the data continuity, but the higher the redundant write ratio (approximately equal to N divided by T). Therefore, the system supports dynamically adjusting the value of N according to the actual load.

[0041] According to the comparison result of the offset M and N, decide whether to write the cache key of one or two time buckets:

[0042] If M ≤ N: It means that the location data is close to the start of the time bucket, and the data is still valid in the next time bucket. At this time, only write the driver id to the cache key corresponding to the current time bucket B (the first cache location).

[0043] If M > N: It means that the location data is close to the end of the time bucket. To ensure that data is not lost during query when the time bucket switches, redundant writing to the next time bucket is required. At this time, write the driver id to the cache key corresponding to the current time bucket B (the first cache location) and the cache key corresponding to the next time bucket B + 1 (the second cache location) simultaneously.

[0044] The naming format for cache keys is standardized as follows: geo:h3:{h3_id}:ts:{B}

[0045] Where {h3_id} is the geographic unit identifier and {B} is the time bucket number.

[0046] Each cache key corresponds to a Redis storage unit, preferably using a Sorted Set as the data structure, with the member being the driver. id The score can be set to the original timestamp or 0 (since sorting is not required during the query).

[0047] Set a uniform Time-to-Live (TTL) for each cache key: TTL = T + N + δ; where δ is a safety margin (e.g., 5 seconds) to compensate for the non-real-time nature of cache system expiration deletion and network processing latency, ensuring that data can be automatically cleaned up after its effective time window ends, without manual or triggered deletion.

[0048] The TTL expiration mechanism of caching systems such as Redis is not strictly precise (it may be affected by expire queue delays, master-slave synchronization, system clock drift, etc.). If the TTL is strictly equal to T+N, then when querying near the window boundary, the valid data may be prematurely eliminated due to microsecond-level delays.

[0049] Therefore, δ is typically set to 1–5 seconds (configurable) to ensure that in B q When querying within a time bucket, all items in [B] q ·TN,(B q The valid location data reported within the +1)·T) interval are still alive.

[0050] When a passenger initiates a "nearby driver" search, the system performs the following steps:

[0051] 3.1 Determine the spatiotemporal range of the query: Based on the passenger's query location (latitude and longitude), calculate the H3 unit (central unit) where the passenger is located, and obtain the identifiers of all units in the k-ring neighborhood of that unit to form a set of geographic units. The k value can be dynamically calculated based on the query radius (e.g., 1-ring corresponds to a range of approximately 500 meters).

[0052] Time range: Calculate the query time bucket number to which it belongs based on the query time (now):

[0053]

[0054] 3.2 Concurrent Reading and Result Merging

[0055] For each h3_id in the set of geographic units, construct a query cache key:

[0056] geo:h3:{h3_id}:ts:{B q}

[0057] The system concurrently reads the Sorted Set corresponding to all these cached keys and extracts all drivers from them. id After merging and deduplicating, we obtain a set of driver identifiers that are "within the current time window and near the passenger", which is then returned to the front-end application.

[0058] The query process only needs to read a single time bucket (B q The data does not require merging across time buckets, nor does it require filtering the timestamp validity of each driver's location at the application layer. The read path complexity is constant and the latency is stable.

[0059] In high-concurrency write scenarios (such as morning and evening peak hours), to reduce the direct write pressure on Redis, a buffer layer can be introduced before cache writes:

[0060] The buffer layer receives the preprocessed location message and aggregates it according to "(h3_id,time_bucket)", merging multiple driver updates within the same spatiotemporal unit into a single write operation.

[0061] You can set a timed trigger (such as every 100 milliseconds) or a quantitative trigger (such as accumulating 100 updates) to write buffered data to Redis in batches.

[0062] This mechanism reduces Redis's write QPS and improves the overall system throughput without affecting data timeliness.

[0063] Example 2:

[0064] Another aspect of the present invention provides a ride-hailing driver location caching system for implementing a ride-hailing driver location caching method as described in any one of the preceding aspects, comprising: a preprocessing module, wherein the preprocessing includes: deduplication based on driver identifiers to retain the latest location information, and timeliness verification based on the original timestamp of the location message to discard expired data; and a spatiotemporal mapping module, wherein the preprocessed location message is mapped to a spatiotemporal key composed of a geographic unit identifier and a time bucket number, wherein the geographic unit identifier is obtained by spatial encoding of the location latitude and longitude, and the time bucket number is based on the original timestamp. The time window length is determined; the cache writing module is used to write the driver identifier into a cache location identified by one or more consecutive spatiotemporal keys based on the comparison result of the offset of the original timestamp in the corresponding time bucket and a preset threshold, and set a uniform lifetime for the cache location; the query processing module is used to respond to the passenger's nearby driver query request, determine the associated set of geographic units based on the query location, and determine the target time bucket number based on the query time; and obtain and return the set of nearby driver identifiers by concurrently reading the cache location determined by the set of geographic units and the target time bucket number.

[0065] In a preferred embodiment, the spatiotemporal mapping module is used to map the preprocessed location message to a spatiotemporal key composed of a geographic unit identifier and a time bucket number. Specifically, this includes: generating a geographic unit identifier representing a fixed geographic area based on the latitude and longitude coordinates in the location message; dividing the original timestamp by a preset time window length and rounding the result down to obtain the time bucket number, wherein the time window length is a fixed number of seconds; and concatenating or combining the geographic unit identifier and the time bucket number according to a preset rule to generate a unique spatiotemporal key for locating and storing the driver identifier in the cache.

[0066] In a preferred embodiment, the cache writing module is used to write the driver identifier into a cache location identified by one or more consecutive spatiotemporal keys based on a comparison between the offset of the original timestamp within the corresponding time bucket and a preset threshold. Specifically, this includes: calculating the offset by taking the modulo operation result of the original timestamp with respect to the time window length; if the offset is not greater than the preset threshold, writing the driver identifier into a first cache location composed of the current time bucket number and the geographic unit identifier; if the offset is greater than the preset threshold, simultaneously writing the driver identifier into both the first cache location composed of the current time bucket number and the geographic unit identifier, and a second cache location composed of the next time bucket number and the geographic unit identifier; the geographic unit identifier is generated using an H3 grid encoding system, an S2 grid encoding system, or a GeoHash encoding system; the lifetime of the cache location is set as the sum of the time window length, the preset threshold, and a safety margin, where the safety margin is used to compensate for the non-real-time nature of the cache expiration mechanism and network processing latency.

[0067] In a preferred embodiment, the query processing module is used to determine the associated set of geographic units based on the query location, obtain and return a set of nearby driver identifiers, specifically including: obtaining the geographic unit where the query location is located and its adjacent geographic units within a preset range, which together constitute the set of geographic units; creating concurrent cache read tasks for each spatiotemporal key formed by combining each geographic unit identifier in the set of geographic units with the target time bucket number; aggregating the driver identifiers returned by all concurrent read tasks, performing deduplication processing, and generating the final set of nearby driver identifiers.

[0068] Understandably, the preprocessing module is responsible for receiving and processing the raw location messages reported by the driver's terminal. Each location message contains at least a driver identifier. id The preprocessing module takes latitude and longitude coordinates and the original timestamp as input. It performs two key operations: First, deduplication based on driver identifiers, aggregating multiple reports from the same driver within the same time period and retaining only the record with the latest original timestamp, ensuring that each driver in the cache corresponds to only one latest location. Second, timeliness verification based on the original timestamp, comparing the message's original timestamp with the server's current time. If the difference exceeds a preset maximum delay threshold (e.g., 30 seconds), the message is considered expired and discarded to prevent network latency or abnormal data from polluting the cache. The preprocessing module outputs cleaned and verified valid location data, providing clean and reliable input for subsequent spatiotemporal mapping and cache writing.

[0069] The spatio-temporal mapping module maps the preprocessed location messages to a unique "spatio-temporal key" jointly composed of a "geographical unit identifier" and a "time bucket number", thereby logically establishing the storage coordinates of location data in the two-dimensional spatio-temporal space. Specifically, it includes: Generation of geographical unit identifier. A mature industrial geospatial coding system (such as H3, S2 or GeoHash) is used to encode the longitude and latitude coordinates of the location, generating a unique string identifier (such as h3_id obtained by H3 coding) representing a fixed geographical area (such as a hexagonal or rectangular grid). This realizes the discretization and fragmentation of the spatial dimension. Calculation of time bucket number. A fixed time window length T (such as 60 seconds) is defined. The original timestamp of the location message is divided by T and the quotient is rounded down to obtain the time bucket number (time_bucket) to which the location belongs. This realizes the segmentation of the time dimension. The spatio-temporal key synthesis is to splice the generated geographical unit identifier and the time bucket number according to a predetermined format rule (such as geo:h3:{h3_id}:ts:{time_bucket}) to form a globally unique cache key. This key directly corresponds to a storage unit in the cache system (such as Redis).

[0070] The cache writing module makes a writing strategy decision based on the time offset and manages the survival period of the cache. Offset calculation and writing decision. Calculate the offset M = original ts %T within the time bucket to which the original timestamp belongs. Compare M with a preset critical threshold N (N < T, such as 10 seconds):

[0071] If M <= N, it means that the location data is close to the start of the time bucket and its validity is mainly within the current bucket. The module only writes the driver identifier to the first cache location (corresponding spatio-temporal key) composed of the current time bucket number and the geographical unit identifier.

[0072] If M > N, it means that the location data is close to the end of the time bucket. To ensure that the data can still be queried when the time bucket switches (such as the query just falls into the next time bucket), the module writes the driver identifier to two cache locations corresponding to the current time bucket and the next time bucket (i.e., the first and second cache locations). Cache setting and TTL management. The cache writing module sets a unified survival time for each written cache location (such as Redis Sorted Set). The calculation formula for TTL is: TTL = T + N + δ; where δ is a small safety margin (such as 5 seconds) used to compensate for the execution delay of the cache system expiration mechanism and network jitter. By setting a unified TTL slightly longer than the actual valid window of the data, the system realizes the automatic expiration cleaning of the data, completely eliminating the cumbersome operations and high costs of active deletion by driver ID in the traditional scheme.

[0073] The query processing module provides low-latency, high-concurrency read services for "nearby drivers" query requests from passengers. It performs spatiotemporal range resolution, receiving passenger query requests containing the query location (latitude and longitude) and query time. The module first calculates the central geographic unit identifier based on the query location and then obtains the identifiers of all geographic units within the k-ring neighborhood of that central unit, collectively forming the set of geographic units to be queried. The k value can be dynamically determined based on the implicit or explicit search radius in the request. Simultaneously, it calculates the target time bucket number based on the query time.

[0074] Concurrent Reading and Result Aggregation: The query processing module assigns an identifier to each geographic unit in the geographic unit set and the target time bucket number B. q The system combines these keys to construct a corresponding list of query keys. Then, it concurrently sends read requests for these keys to the caching system. This design ensures that the read operation complexity depends only on the geographic range (neighborhood size) of the query, and not on the total number of drivers in the system. Finally, the module aggregates the driver identifier sets returned by all concurrent reads, performs deduplication, and generates and returns the final "nearby drivers" list to the passenger. The entire read path is simple, efficient, and has stable latency.

[0075] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Therefore, any modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A method for caching the location of ride-hailing drivers, characterized in that, include: The location messages reported by the driver are preprocessed, including: deduplication based on the driver identifier to retain the latest location information, and timeliness verification based on the original timestamp of the location message to discard expired data; The preprocessed location message is mapped to a spatiotemporal key consisting of a geographic unit identifier and a time bucket number, wherein the geographic unit identifier is obtained by spatial encoding the location latitude and longitude, and the time bucket number is determined based on the original timestamp and the time window length; Based on the comparison result between the offset of the original timestamp in the corresponding time bucket and the preset threshold, the driver identifier is written into the cache location identified by one or more consecutive time keys, and a uniform lifespan is set for the cache location. In response to a passenger's request to find nearby drivers, the system determines the set of associated geographic units based on the query location and the target time bucket number based on the query time. By concurrently reading the cache location determined by the set of geographic units and the target time bucket number, a set of nearby driver identifiers is obtained and returned.

2. The ride-hailing driver location caching method according to claim 1, characterized in that, The step of mapping the preprocessed location message to a spatiotemporal key consisting of a geographic unit identifier and a time bucket number specifically includes: Based on the latitude and longitude coordinates in the location message, generate the geographic unit identifier representing a fixed geographic area; Divide the original timestamp by the preset time window length and round the result down to obtain the time bucket number, wherein the time window length is a fixed number of seconds; The geographic unit identifier and the time bucket number are concatenated or combined according to a preset rule to generate a unique spatiotemporal key, which is used to locate and store the driver identifier in the cache.

3. The ride-hailing driver location caching method according to claim 1, characterized in that, The step of writing the driver identifier into a cache location identified by one or more consecutive time keys based on the comparison result of the offset of the original timestamp within the corresponding time bucket and a preset threshold specifically includes: The offset is obtained by calculating the modulo operation result of the original timestamp with the length of the time window; If the offset is not greater than the preset threshold, the driver identifier is written to the first cache location consisting of the current time bucket number and the geographic unit identifier; If the offset is greater than the preset threshold, the driver identifier is simultaneously written to the first cache location consisting of the current time bucket number and the geographic unit identifier, and the second cache location consisting of the next time bucket number and the geographic unit identifier.

4. The ride-hailing driver location caching method according to claim 1, characterized in that: The geographic unit identifier is generated using the H3 grid coding system, the S2 grid coding system, or the GeoHash coding system.

5. The ride-hailing driver location caching method according to claim 1, characterized in that: The lifetime of the cache location is set as the sum of the time window length, the preset threshold, and a safety margin. The safety margin is used to compensate for the non-real-time nature of the cache expiration mechanism and network processing latency.

6. The ride-hailing driver location caching method according to claim 1, characterized in that, The step of determining the associated set of geographical units based on the query location and obtaining and returning the set of nearby driver identifiers specifically includes: Based on the queried location, the geographical unit where it is located and the adjacent geographical units within a preset range are obtained, which together constitute the set of geographical units; For each spatiotemporal key formed by combining the geographic unit identifier in the geographic unit set with the target time bucket number, create concurrent cache read tasks; After aggregating the driver identifiers returned by all concurrent read tasks and performing deduplication, the final set of nearby driver identifiers is generated.

7. A ride-hailing driver location caching system, characterized in that, include: The preprocessing module is used for the preprocessing including: deduplication based on driver identifier to retain the latest location information, and timeliness verification based on the original timestamp of the location message to discard timed-out data; The spatiotemporal mapping module is used to map the preprocessed location message to a spatiotemporal key consisting of a geographic unit identifier and a time bucket number. The geographic unit identifier is obtained by spatial encoding the location's latitude and longitude, and the time bucket number is determined based on the original timestamp and the time window length. The cache writing module is used to write the driver identifier into a cache location identified by one or more consecutive time keys based on the comparison result of the offset of the original timestamp in the corresponding time bucket and a preset threshold, and to set a uniform lifetime for the cache location. The query processing module is used to respond to passengers' nearby driver query requests, determine the associated set of geographical units based on the query location, and determine the target time bucket number based on the query time. By concurrently reading the cache location determined by the set of geographic units and the target time bucket number, a set of nearby driver identifiers is obtained and returned.

8. The ride-hailing driver location caching system according to claim 7, characterized in that, The spatiotemporal mapping module is used to map the preprocessed location messages to a spatiotemporal key composed of a geographic unit identifier and a time bucket number, specifically including: Based on the latitude and longitude coordinates in the location message, generate the geographic unit identifier representing a fixed geographic area; Divide the original timestamp by the preset time window length and round the result down to obtain the time bucket number, wherein the time window length is a fixed number of seconds; The geographic unit identifier and the time bucket number are concatenated or combined according to a preset rule to generate a unique spatiotemporal key, which is used to locate and store the driver identifier in the cache.

9. The ride-hailing driver location caching system according to claim 7, characterized in that, The cache writing module is used to write the driver identifier into a cache location identified by one or more consecutive time keys based on the comparison result of the offset of the original timestamp within the corresponding time bucket and a preset threshold, specifically including: The offset is obtained by calculating the modulo operation result of the original timestamp with the length of the time window; If the offset is not greater than the preset threshold, the driver identifier is written to the first cache location consisting of the current time bucket number and the geographic unit identifier; If the offset is greater than the preset threshold, the driver identifier is simultaneously written to the first cache location consisting of the current time bucket number and the geographic unit identifier, and the second cache location consisting of the next time bucket number and the geographic unit identifier. The geographic unit identifier is generated using the H3 grid coding system, the S2 grid coding system, or the GeoHash coding system. The lifetime of the cache location is set as the sum of the time window length, the preset threshold, and a safety margin. The safety margin is used to compensate for the non-real-time nature of the cache expiration mechanism and network processing latency.

10. The ride-hailing driver location caching system according to claim 7, characterized in that, The query processing module is used to determine the set of associated geographical units based on the query location, obtain and return a set of nearby driver identifiers, specifically including: Based on the queried location, the geographical unit where it is located and the adjacent geographical units within a preset range are obtained, which together constitute the set of geographical units; For each spatiotemporal key formed by combining the geographic unit identifier in the geographic unit set with the target time bucket number, create concurrent cache read tasks; After aggregating the driver identifiers returned by all concurrent read tasks and performing deduplication, the final set of nearby driver identifiers is generated.

Images