Lbs parallel determination method, system, device and storage medium

Abstract

The application discloses an LBS parallel judgment method, system, device and storage medium, comprising obtaining and performing parallel matching on user location information and service text, and performing intersection processing on a first object list and a second object list obtained through matching to obtain a target object list; matching the user location information comprises: obtaining a first data set comprising object identification and location identification from a remote cache; starting multiple processing threads and distributing the first data set to the multiple processing threads after sharding; each processing thread reads geographic range information from a near cache composed of off-heap memory and a shared disk according to the object identification and the location identification, and matches the user location information with the geographic range information to determine a matching object; and the matching objects of the multiple processing threads are summarized to obtain the first object list. The application improves the efficiency of GB-level data geographic screening and takes into account the cost, realizes decoupling of geographic screening and text filtering, and improves the LBS judgment speed.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to an LBS parallel decision-making method, system, device and storage medium. Background Technology

[0002] In modern internet services, especially in e-commerce, travel, and local services, location-based services (LBS) play a crucial role. In traditional practices, geographic information (such as polygon vertex coordinates) and business text information (such as store names and event descriptions) are often coupled and stored in a single search engine (such as Elasticsearch, ES). This architecture exposes serious drawbacks in large-scale applications, leading to the industry's proposal to decouple geographic filtering from text filtering. However, in practical applications, especially when geofencing data reaches gigabyte levels and requires frequent dynamic updates, geographic filtering becomes a new efficiency bottleneck, making it difficult to implement solutions that decouple geographic filtering from text filtering. Summary of the Invention

[0003] This invention aims to address at least one of the technical problems existing in the prior art. To this end, this invention proposes a parallel LBS (Location-Based Service) decision-making method, system, device, and storage medium, which can improve the efficiency of geographic filtering of GB-level data while considering cost, decoupling geographic filtering from text filtering, and thus improving the speed of LBS decision-making.

[0004] In a first aspect, embodiments of the present invention provide a parallel LBS determination method, comprising:

[0005] The system acquires and performs parallel matching of user location information and business text, and performs intersection processing on the first and second object lists obtained from the matching to obtain the target object list.

[0006] The matching of the user location information includes:

[0007] Retrieve the first dataset, including object identifiers and location identifiers, from the remote cache;

[0008] Multiple processing threads are started, and the first dataset is divided into fragments and distributed to the multiple processing threads;

[0009] Each processing thread reads geographic range information from a near cache composed of off-heap memory and shared disk based on the object identifier and the location identifier, and matches the user location information with the geographic range information to determine the matching object;

[0010] The matching objects from the multiple processing threads are aggregated to obtain the first object list.

[0011] According to some embodiments of the present invention, the user location information is latitude and longitude coordinate information, and the step of obtaining the first dataset including object identifier and location identifier from the remote cache is further included before:

[0012] The latitude and longitude coordinate information is converted into H3 grid identifiers with multiple precision levels.

[0013] According to some embodiments of the present invention, the geographic extent information is an H3 grid identifier set. Each processing thread reads the geographic extent information from a near cache composed of off-heap memory and shared disk based on the object identifier and the location identifier, and matches the user location information with the geographic extent information to determine the matching object, including:

[0014] Each processing thread reads the H3 grid identifier set from the near cache, which is composed of off-heap memory and shared disk, based on the object identifier and the location identifier, and matches the H3 grid identifier with the H3 grid identifier set to determine the matching object.

[0015] According to some embodiments of the present invention, each of the processing threads reads geographic range information from a near cache composed of off-heap memory and shared disk based on the object identifier and the location identifier, including:

[0016] Each processing thread combines the object identifier and the location identifier into a combined identifier;

[0017] Geographic range information is read from a near cache consisting of off-heap memory and shared disk based on the combined identifier.

[0018] According to some embodiments of the present invention, the LBS parallel decision method further includes:

[0019] The business text is submitted to a search engine so that the search engine can perform a text query on the business database to obtain a second list of objects.

[0020] According to some embodiments of the present invention, the LBS parallel decision method further includes:

[0021] If the user location information and the geographic range information fail to match, skip the current match and read data from the business database and update the recently cached data.

[0022] According to some embodiments of the present invention, the LBS parallel decision method further includes:

[0023] The system monitors the business database and, upon data updates to the business database, updates at least one of the near cache and the remote cache.

[0024] Secondly, embodiments of the present invention provide an LBS parallel decision-making system, comprising:

[0025] The business database is used to store business text data;

[0026] The server is configured with off-heap memory and a search engine. The server is mounted with a shared disk. The shared disk and the off-heap memory form a near cache. The near cache is used to store geographical range information. The search engine is used to perform text queries in the business database based on business text.

[0027] A remote cache is used to store a first dataset, including object identifiers and location identifiers.

[0028] An application service instance is configured within the server, and the application service instance is used to execute the LBS parallel determination method described above.

[0029] Thirdly, embodiments of the present invention provide an LBS parallel determination device, including a processor and a memory, wherein the memory stores a computer program, and the processor runs the computer program to implement the above-mentioned LBS parallel determination method.

[0030] Fourthly, embodiments of the present invention provide a storage medium storing a computer program that, when run, implements the LBS parallel determination method as described above.

[0031] The embodiments of the present invention have at least the following beneficial effects:

[0032] Parallel matching of user location information and business text decouples geographic filtering from text filtering. The intersection of the first and second object lists obtained from the matching is processed to obtain the target object list. During the matching of user location information, a combined cache is built using remote and near caching to achieve GB-level data caching. The near cache, composed of off-heap memory and shared disk, has low cost and avoids the risk of pauses caused by JVM garbage collection during read and write operations. Sharding the first dataset and starting multiple processing threads improves matching efficiency. This approach improves the efficiency of geographic filtering of GB-level data while maintaining cost-effectiveness, decoupling geographic filtering from text filtering, and thus improving LBS determination speed.

[0033] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0034] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which:

[0035] Figure 1 This is a schematic diagram of the LBS parallel decision system according to an embodiment of the present invention;

[0036] Figure 2 This is one of the flowcharts of the LBS parallel determination method according to an embodiment of the present invention;

[0037] Figure 3 This is the second flowchart of the LBS parallel determination method according to an embodiment of the present invention;

[0038] Figure 4 This is a schematic diagram of the LBS parallel decision-making device according to an embodiment of the present invention. Detailed Implementation

[0039] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0040] In the description of this invention, "several" means one or more, "multiple" means two or more, "greater than," "less than," "exceeding," etc. are understood to exclude the stated number, and "above," "below," "within," etc. are understood to include the stated number. If "first," "second," etc. are used in the description, they are only for the purpose of distinguishing technical features and should not be construed as indicating or implying relative importance or implicitly indicating the number of indicated technical features or the order of the indicated technical features.

[0041] For LBS services, traditional techniques couple geographic information (such as polygon vertex coordinates) with business text information (such as store names and event descriptions) and store them in a single search engine (such as Elasticsearch, ES). While this architecture is easy to implement, it has the following shortcomings in large-scale applications:

[0042] 1) Performance bottleneck: The performance of Elasticsearch's Geo-Shape query drops sharply when the data volume and concurrency are huge, making it difficult to meet the high standard latency requirements of online transaction systems at the 50-millisecond level;

[0043] 2) Resource coupling and competition: Index updates and query loads of geographic data and business text data interfere with each other, leading to complex resource allocation and system optimization;

[0044] 3) Difficult to maintain: The maintenance, scaling up and down and fault recovery of a single cluster are all affected by a single change, resulting in poor system robustness.

[0045] To address the aforementioned coupling issue, an approach has emerged in the industry to decouple geographic filtering from text filtering. However, this approach faces the following technical challenges: how to build a high-performance, highly stable, and low-cost geographic determination service. When the geofence data to be processed reaches the gigabyte level and requires frequent dynamic updates, the backend geographic determination logic becomes a new and more severe performance bottleneck.

[0046] In the process of decoupling geographic filtering from text filtering, the following challenges were encountered:

[0047] 1) JVM (Java Virtual Machine) GC (Garbage Collection) Performance Dilemma: In pursuit of extreme performance, directly loading gigabytes of geographic data (such as a gridded fence set) into the JVM heap memory of the application service (e.g., using GuavaCache or Caffeine) will inevitably lead to unpredictable "Stop-The-World" Full GC lasting hundreds of milliseconds or even seconds. For online transaction systems requiring stable P99 response times in the millisecond range, such service interruptions caused by GC are unacceptable.

[0048] 2) High storage and maintenance costs: If all the geographic data in GB (gigabytes) is put into a distributed memory cache (such as Redis) to avoid GC problems, although the performance is expected, it requires extremely high memory resources. The hardware procurement cost and long-term maintenance cost are difficult for most enterprises to bear, and the economic feasibility is low.

[0049] For the reasons mentioned above, geographic filtering has become a new efficiency bottleneck, creating a significant "weakest link" effect, making it difficult to implement solutions that decouple geographic filtering from text filtering. Therefore, this embodiment proposes a parallel LBS decision-making method that can improve the efficiency of geographic filtering for GB-level data while considering cost, achieving decoupling of geographic filtering from text filtering, and thus improving LBS decision-making speed.

[0050] Before explaining the LBS parallel decision-making method, this embodiment describes the system architecture for implementing the LBS parallel decision-making method. Please refer to [link / reference]. Figure 1 This embodiment provides an LBS parallel decision-making system, including:

[0051] The business database is used to store business text data;

[0052] The server is configured with off-heap memory and a search engine. The server is mounted with a shared disk. The shared disk and off-heap memory form a near cache. The near cache is used to store geographic range information. The search engine is used to perform text queries in the business database based on business text.

[0053] A remote cache is used to store a first dataset, including object identifiers and location identifiers.

[0054] An application service instance, configured within the server, is used to execute the following LBS parallel decision-making method. This application service instance can include multiple modules, such as... Figure 1 The modules shown include the request interface, geographic filtering, and intersection operation.

[0055] For example, the business database is used to store business text data, such as metadata like store names, dish names, and dish categories. To facilitate storing the relationships between metadata, the business database can use a relational database, such as MySQL. The server is the hardware carrier that hosts software entities such as search engines (e.g., Elasticsearch, ES) and application service instances. Considering the different data access requirements in the business scenario, the server in this embodiment adopts a combination of two caching architectures to form a geolocation caching system, which helps to balance access speed, storage capacity, and economic cost.

[0056] Remote caching is primarily used to store the most frequently accessed and relatively manageable core mapping relationships, i.e., the first dataset, which includes object identifiers and location identifiers. For example, remote caching uses high-performance in-memory databases such as Redis. Redis uses in-memory storage, resulting in extremely fast read and write speeds, reaching tens of thousands of operations per second. Taking a food delivery business scenario as an example, the object identifier is configured as the store ID (Identity Document), and the location identifier is configured as the delivery plan ID. The delivery plan ID identifies the delivery plan, and the delivery plan records the geographical delivery range of different stores. The remote cache uses a Redis Hash structure with the key TakeoutStoreList, which internally stores the mapping relationships of all stores. Each subkey (field) is the store ID (storeId), and the corresponding value is a JSON string containing metadata such as all delivery plan IDs (areaId) associated with that store and the delivery type (dedicated delivery, express delivery, self-delivery, self-pickup). This data is the entry point for subsequent queries and requires extremely high read performance.

[0057] In the food delivery business scenario, the total number of stores on a food delivery platform can reach thousands. Each store is configured with one or more delivery plans, and each plan records the geographical area that can be delivered, i.e., the delivery zone. The total number of delivery zones can reach tens of thousands, and the total data volume after grid processing (such as H3 grid) can exceed 20GB. Such a large data scale far exceeds the capacity of the heap memory of a conventional JVM. Heap memory such as Caffeine cannot support GB-level data, meaning it is impossible to cache all data in the JVM's heap memory. However, if all the data is placed in an in-memory database such as Redis, the cost will be extremely high. Therefore, this embodiment adopts a storage technology based on off-heap memory and shared disk as the implementation scheme for near caching. Among them, near caching is a local caching mechanism used to store hot data on server nodes. By caching hot data locally, near caching can significantly reduce network round-trip time, which is beneficial to improving response speed and performance.

[0058] Memory can be divided into on-heap memory and off-heap memory. On-heap memory is allocated by the JVM and fully follows the JVM's memory management mechanism, using a garbage collector for unified memory management. The garbage collector performs a thorough collection at certain specific times, known as Full GC. Garbage collection scans all allocated on-heap memory, which can impact the performance of Java applications and potentially cause "Stop The World" lag. Off-heap memory, on the other hand, is directly allocated from the kernel and is managed by the operating system, not the JVM. This approach avoids the impact of garbage collection on applications.

[0059] This embodiment avoids the lag caused by JVM garbage collection in on-heap memory by using off-heap memory, improving the smoothness and efficiency of data processing. However, considering the limited storage capacity of off-heap memory, the server in this embodiment is equipped with a shared disk, which uses an SSD (Solid State Drive). SSDs have advantages such as fast boot times, low read latency, fragmentation not affecting read times, and fast write speeds. By combining off-heap memory and the shared disk to form a near cache, the storage capacity is increased while avoiding on-heap caching. Furthermore, due to the read / write advantages of SSDs, the impact of read / write latency can be reduced. The near cache uses a MapDB database for data management. MapDB provides high-performance data caching and persistent data storage capabilities. MapDB can serve as a highly efficient data caching tool, providing applications with fast data access. Its persistent data storage function allows applications to store data on the hard drive for continued use upon next startup. Thus, this embodiment uses off-heap memory and a shared disk to form a near cache, and uses MapDB to manage the near cache, enabling applications to operate on datasets much larger than physical memory, just like operating on ordinary on-heap memory. Compared to storing all data in in-memory databases like Redis, the near-caching scheme in this embodiment balances storage cost and data storage volume, achieving a balance between cost-effective near-caching and querying massive amounts of data. The near-caching data structure uses key-value pairs. The key in each key-value pair is a composite string, which can be composed of object identifiers and location identifiers. For example, a composite string could be "storeId:areaId", where storeId represents the store ID and areaId represents the delivery plan ID. The value in each key-value pair is a Java set collection that stores geographic range information. For example, the Java set collection stores all grid IDs covered by the delivery area. Grid IDs identify the geographic area range after gridding (such as H3 gridding). H3 gridding is a globally hierarchical geospatial indexing system. In this embodiment, the original polygonal delivery range of the store is pre-processed with multiple precision levels (e.g., from precision 5 to precision 14) to generate a series of H3 grid IDs, which are then compressed and stored in a set collection in the MapDB database. Using H3 as an alternative to GeoHash helps solve the problems of long strings and index bloat.

[0060] It is worth mentioning that multiple application service instances can be configured within the server of this embodiment. These multiple application service instances can share a shared disk to reduce storage costs and ensure data consistency. Of course, multiple servers can also be deployed in this embodiment, and these servers can also share a shared disk. Thus, the shared disk can be shared by multiple application service instances on the same server, or by multiple application service instances on multiple servers. This helps reduce operational complexity and improve system resilience, avoiding the need for each application service instance to maintain an independent cache, and simplifying system deployment and management.

[0061] Please refer to Figure 2 and Figure 3 This embodiment discloses a parallel LBS determination method, including the following steps. It should be noted that the numbering of the steps in this embodiment is only for ease of review and understanding, and not to limit the execution order of the steps. The details of each step are described below:

[0062] S100: Obtain and perform parallel matching of user location information and business text, and perform intersection processing on the first object list and the second object list obtained by matching to obtain the target object list;

[0063] For details, please refer to Figure 2 Step S100 includes:

[0064] S110. Receive a search request from the client. The search request includes user location information and business text.

[0065] S120. In response to the search request, obtain user location information and business text;

[0066] S130. Based on parallel processing, the user location information is matched to obtain a first object list, and the business text is matched to obtain a second object list.

[0067] S140. Perform intersection processing on the first object list and the second object list to obtain the target object list.

[0068] For example, one instance of a client could be a food delivery app. When a user triggers a search request on the client (e.g., enters and searches for "pizza"), the client sends a search request to the server. An application service instance on the server receives the client's search request, which includes the user's location information (e.g., latitude and longitude coordinates) and business text (e.g., "pizza"). The application service instance responds to the search request by parsing it to obtain the user's location information and business text. The user's location information is used for geographic filtering, and the business text is used for text filtering. Parallel processing of geographic filtering and text filtering improves data processing efficiency. By performing intersection processing on the first and second object lists obtained through processing, objects that simultaneously satisfy both geographic scope and business text can be obtained, such as "pizza" stores whose delivery range covers the user's current location, thus yielding a target object list.

[0069] In theory, parallel processing of geographic filtering and text filtering can improve data processing efficiency. However, the final processing time of parallel data processing depends on the completion time of the slowest task. As mentioned above, in existing technologies, geographic filtering becomes the efficiency bottleneck, leading to a mismatch in processing times between geographic filtering and text filtering, thus failing to achieve true parallel processing. Therefore, this embodiment improves the geographic filtering method based on the aforementioned combined caching architecture. Please refer to... Figure 3 In step S130, matching the user's location information includes:

[0070] S131. Obtain the first dataset including object identifier and location identifier from the remote cache;

[0071] S132. Start multiple processing threads and distribute the first dataset into multiple processing threads after splitting it;

[0072] S133. Each processing thread reads geographic range information from the near cache composed of off-heap memory and shared disk based on the object identifier and location identifier, and matches the user location information with the geographic range information to determine the matching object;

[0073] S134. Summarize the matching objects from multiple processing threads to obtain the first object list.

[0074] For example, a remote cache is used to store the first dataset, which includes object identifiers and location identifiers. These object identifiers and location identifiers represent the most frequently accessed core mapping relationship. The remote cache uses a high-performance Redis in-memory database, enabling fast data retrieval. The application service instance reads the entire first dataset from the remote cache, obtaining the store IDs (storeId) of all active stores and their associated delivery plan IDs (areaId). Concurrent matching is then performed on the first dataset. For instance, multiple processing threads can be started using a Java concurrency library, and the first dataset can be sharded and distributed among multiple processing threads. Each processing thread can then independently match a portion of the first dataset, improving data processing efficiency. Each processing thread retrieves geographic range information from the near cache based on the object identifier and location identifier. For example, as illustrated above, the near cache stores information in key-value pairs, where the key is a string composed of the object identifier and location identifier. Therefore, each processing thread combines the current object identifier and location identifier into a string to be matched, and then searches for the corresponding value in the near cache. The value corresponds to the geographic range information. The user's location information is then matched against the retrieved geographic range information. If the user's location falls within the retrieved geographic range, the object identifier corresponding to the current geographic range information is identified as the matching object. The near cache is based on off-heap memory and shared disk, which avoids the risk of lag caused by JVM garbage collection, ensuring millisecond-level stable performance for the geographic filtering task. After matching, the matched objects from multiple processing threads are aggregated to obtain a first object list for subsequent intersection processing.

[0075] The above scheme performs parallel matching of user location information and business text, decoupling geographic filtering from text filtering. It then performs intersection processing on the first and second object lists obtained from the matching to obtain the target object list. During the matching of user location information, a combined cache is built using remote and near caching to achieve GB-level data caching. Furthermore, the near cache, composed of off-heap memory and shared disk, has low cost and avoids the risk of pauses caused by JVM garbage collection during read and write operations. Sharding the first dataset and starting multiple processing threads improves matching efficiency. This approach improves the efficiency of geographic filtering for GB-level data while maintaining cost-effectiveness, decoupling geographic filtering from text filtering, and thus improving LBS determination speed.

[0076] In some application examples, the user location information is latitude and longitude coordinate information. Step S131, obtaining the first dataset including object identifier and location identifier from the remote cache, also includes: converting the latitude and longitude coordinate information into H3 grid identifiers with multiple precision levels.

[0077] For example, latitude and longitude coordinate information includes longitude and latitude coordinate values. The user location information, composed of these two values, represents a location point on a map. While this representation method provides a precise user location, it is not conducive to matching user location information with geographic range information. For instance, taking the delivery area of ​​a store on a food delivery platform as an example of geographic range information, this delivery area contains multiple vertices forming a polygon. If matching is done using latitude and longitude coordinates, it would require calculating the user's latitude and longitude coordinates against each vertex of the delivery area to determine the relationship between the user's latitude and longitude coordinates and the corresponding polygon, resulting in high computational complexity and hindering rapid calculation. Therefore, latitude and longitude coordinate information is converted into H3 grid identifiers with multiple precision levels. The precision levels can be customized, such as by province, city, street, or district. After conversion to multiple precision levels of H3 grid identifiers, rapid matching can be performed based on the H3 grid identifiers. For example, does the set of grid identifiers corresponding to the delivery area contain the H3 grid identifier corresponding to the user's location information? If so, it means the store's delivery range covers the user's current location; therefore, the store ID can be identified as the matching target.

[0078] Corresponding to the above application example, the geographic extent information is a set of H3 grid identifiers. In step S133, each processing thread reads the geographic extent information from the near cache composed of off-heap memory and shared disk based on the object identifier and location identifier, and matches the user location information with the geographic extent information to determine the matching object, including:

[0079] Each processing thread reads a set of H3 grid identifiers from a near cache consisting of off-heap memory and shared disk based on object identifiers and location identifiers, and matches the H3 grid identifiers with the set of H3 grid identifiers to determine the matching object.

[0080] For example, the near cache, based on off-heap memory and shared disk, can achieve persistent near caching of gigabyte-level data. Moving massive amounts of data out of the JVM's on-heap memory avoids pauses caused by JVM garbage collection. The shared disk uses solid-state drives (SSDs), which can carry massive amounts of data with low-cost media, significantly reducing hardware costs. Furthermore, by avoiding JVM GC, it reduces the risk of pauses, thus improving operational efficiency and system stability. The H3 grid identifier set includes one or more H3 grid identifiers, each representing the store's delivery range. Local caching of gigabyte-level data improves data retrieval efficiency, shortens data processing time, and thus reduces the time required for geographic filtering tasks.

[0081] In other application examples, step S133, where each processing thread reads geographic extent information from a near cache composed of off-heap memory and shared disk based on object identifier and location identifier, includes:

[0082] Each processing thread combines the object identifier and the location identifier into a combined identifier; based on the combined identifier, it reads geographic range information from a near cache composed of off-heap memory and shared disk.

[0083] For example, in a food delivery business, a store may have multiple delivery areas. For instance, the delivery area during emergencies such as heavy rain or large promotions may differ from the usual delivery area. Furthermore, different stores may share the same delivery area. Therefore, in data storage, the mapping between object identifiers and location identifiers may overlap. To facilitate determining the geographical range corresponding to an object identifier, the combined string of the object identifier and location identifier is used as the key of the key-value pair in the near cache, ensuring the key's uniqueness. Correspondingly, each processing thread, when reading geographical range information, combines the object identifier (such as `storeId` in the example above) and the location identifier (such as `areaId` in the example above) into a combined identifier (e.g., `storeId:areaId`), and reads the corresponding geographical range information from the near cache based on this combined identifier.

[0084] In some application examples, the LBS parallel decision method also includes:

[0085] Submit the business text to the search engine so that the search engine can perform a text query on the business database and obtain a second list of objects.

[0086] For example, in a text filtering task, the business text is submitted to a search engine, which performs full-text search, relevance ranking, and other operations. The search engine matches the business text with text in a business database to retrieve the corresponding objects. For instance, for the business text "pizza," the search engine queries the business database for all stores related to the text "pizza," and then organizes the store IDs (objects) of these stores to obtain a second object list.

[0087] In some application examples, the LBS parallel decision method also includes:

[0088] If the user's location information and geographic range information fail to match, skip the current match and read data from the business database and update the recently cached data.

[0089] For example, during the geographic filtering task, there may be situations where the user's geographic location information and geographic range information fail to match. In this case, a fault tolerance and cache write-back mechanism can be added. For instance, if no matching object can be found based on the user's location information during the matching process, it may be because the information in the recently cached database has not been updated in time. In this case, skip the tier matching to ensure the overall response speed, and at the same time, trigger a cache write-back task asynchronously. This cache write-back task reads the latest data from the business database and updates the data in the recently cached database to ensure the hit rate of subsequent queries.

[0090] In some application examples, the LBS parallel decision method also includes:

[0091] Monitor the business database and, if data is updated in the business database, update at least one of the near cache and the remote cache.

[0092] For example, to ensure the timeliness of geographic filtering data, especially in scenarios requiring rapid adjustments to delivery areas such as heavy rain, a Kafka-based message consumer application can be deployed. This application subscribes to message topics related to changes in store delivery areas. Once a change message is generated, such as an operations staff member modifying the area of ​​a delivery station in the background, the application immediately receives the message, parses the change content, and updates the mapping between the store ID and delivery plan ID in the remote cache, as well as the specific grid data of the delivery plan in the near cache. This asynchronous data synchronization chain helps ensure that data changes take effect in both the remote and near caches in near real-time.

[0093] The above solution employs a combined cache architecture, utilizing both remote and near caches. Hot data (such as core mapping relationships) is migrated from the business database to the remote cache, reducing the read / write frequency of the business database and alleviating its pressure. Furthermore, the remote cache's memory read / write speed (microseconds) is significantly faster than disk I / O (milliseconds), improving system response speed. The remote cache also allows data sharing across application nodes, resolving local cache inconsistency issues. The near cache, built on off-heap memory and mounted shared disks, avoids the risk of JVM garbage collection pauses and reduces the impact of network latency on data reading. Near cache achieves data sharing through shared disks, further mitigating local cache inconsistency. The remote cache stores relatively manageable amounts of data, while the near cache stores gigabytes of data via shared disks, avoiding the need to configure large amounts of memory or use expensive distributed caches for each application service instance. This combination of remote and near caches prevents the storage of massive amounts of data in the remote cache, thus avoiding increased storage costs. In addition to using a combined cache, the above scheme also starts multiple processing threads during the geographic filtering task, performs matching on the first dataset read from the remote cache after sharding, and changes the serial processing logic to parallel processing logic, which helps to improve processing efficiency and make the processing efficiency of geographic filtering task match that of text filtering task, thus enabling geographic filtering and text filtering to achieve true parallel processing.

[0094] Please refer to Figure 4 This embodiment also provides an LBS parallel determination device, including a processor 210 and a memory 220. The memory 220 stores a computer program, and the processor 210 executes the computer program to implement the above-mentioned LBS parallel determination method. The LBS parallel determination method is detailed above and will not be repeated here. Parallel matching of user location information and business text decouples geographic filtering from text filtering. The intersection of the first and second object lists obtained from the matching is processed to obtain the target object list. During the matching of user location information, a combined cache is constructed using remote and near caches to achieve GB-level data caching. Furthermore, the near cache, based on off-heap memory and shared disk, has low cost and avoids the risk of pauses caused by JVM garbage collection during read and write operations. Sharding the first dataset and starting multiple processing threads can improve matching efficiency. This improves the efficiency of geographic filtering of GB-level data while considering cost, decoupling geographic filtering from text filtering, and thus improving LBS determination speed.

[0095] This embodiment also provides a storage medium storing a computer program. When the computer program is run, it implements the LBS parallel determination method described above. The LBS parallel determination method is detailed above and will not be repeated here. Parallel matching of user location information and business text decouples geographic filtering from text filtering. The intersection of the first and second object lists obtained from the matching is processed to obtain the target object list. During the matching of user location information, a combined cache is constructed using remote and near caches to achieve GB-level data caching. Furthermore, the near cache, composed of off-heap memory and shared disk, has low cost and avoids the risk of pauses caused by JVM garbage collection during read and write operations. Sharding the first dataset and starting multiple processing threads improves matching efficiency. This improves the efficiency of geographic filtering of GB-level data while considering cost, decoupling geographic filtering from text filtering, and thus improving LBS determination speed.

[0096] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of the present invention.

Claims

1. A parallel decision-making method for LBS, characterized in that, include: The system acquires and performs parallel matching of user location information and business text, and performs intersection processing on the first and second object lists obtained from the matching to obtain the target object list. The matching of the user location information includes: Retrieve the first dataset, including object identifiers and location identifiers, from the remote cache; Multiple processing threads are started, and the first dataset is divided into fragments and distributed to the multiple processing threads; Each processing thread reads geographic range information from a near cache composed of off-heap memory and shared disk based on the object identifier and the location identifier, and matches the user location information with the geographic range information to determine the matching object; The matching objects from the multiple processing threads are aggregated to obtain the first object list.

2. The LBS parallel decision-making method according to claim 1, characterized in that, The user location information is latitude and longitude coordinate information. Prior to obtaining the first dataset including object identifiers and location identifiers from the remote cache, the process also includes: The latitude and longitude coordinate information is converted into H3 grid identifiers with multiple precision levels.

3. The LBS parallel decision-making method according to claim 2, characterized in that, The geographic extent information is an H3 grid identifier set. Each processing thread reads the geographic extent information from a near cache composed of off-heap memory and shared disk based on the object identifier and the location identifier, and matches the user location information with the geographic extent information to determine the matching object, including: Each processing thread reads the H3 grid identifier set from the near cache composed of off-heap memory and shared disk according to the object identifier and the location identifier, and matches the H3 grid identifier with the H3 grid identifier set to determine the matching object.

4. The LBS parallel decision-making method according to claim 1 or 2, characterized in that, Each of the processing threads reads geographic range information from a near cache composed of off-heap memory and shared disk based on the object identifier and the location identifier, including: Each processing thread combines the object identifier and the location identifier into a combined identifier; Geographic range information is read from a near cache consisting of off-heap memory and shared disk based on the combined identifier.

5. The LBS parallel decision-making method according to claim 1, characterized in that, The LBS parallel decision method further includes: The business text is submitted to a search engine so that the search engine can perform a text query on the business database to obtain a second list of objects.

6. The LBS parallel decision-making method according to claim 1, characterized in that, The LBS parallel decision method further includes: If the user location information and the geographic range information fail to match, skip the current match and read data from the business database and update the recently cached data.

7. The LBS parallel decision-making method according to claim 1, characterized in that, The LBS parallel decision method further includes: The system monitors the business database and, upon data updates to the business database, updates at least one of the near cache and the remote cache.

8. A parallel decision-making system for LBS, characterized in that, include: The business database is used to store business text data; The server is configured with off-heap memory and a search engine. The server is mounted with a shared disk. The shared disk and the off-heap memory form a near cache. The near cache is used to store geographical range information. The search engine is used to perform text queries in the business database based on business text. A remote cache is used to store a first dataset, including object identifiers and location identifiers. An application service instance is configured within the server, and the application service instance is used to execute the LBS parallel decision method as described in any one of claims 1 to 7.

9. A parallel decision-making device for LBS (Location-Based Services), comprising a processor and a memory, wherein the memory stores a computer program, characterized in that, When the processor runs the computer program, it is used to implement the LBS parallel decision method as described in any one of claims 1 to 7.

10. A storage medium storing a computer program, characterized in that, When the computer program is run, it implements the LBS parallel decision method as described in any one of claims 1 to 7.

Images