LBS (Location Based Service) parallel judgment method, system and equipment and storage medium

Abstract

The invention discloses an LBS parallel judgment method, system and device and a storage medium, and the method comprises the steps: obtaining and carrying out the parallel matching of user position information and a business text, and carrying out the intersection processing of a first object list and a second object list obtained through matching, and obtaining a target object list; the matching of the user position information comprises the following steps: acquiring a first data set comprising an object identifier and a position identifier from a remote cache; starting a plurality of processing threads, fragmenting the first data set, and distributing the fragmented first data set to the plurality of processing threads; each processing thread reads geographical range information from a near cache composed of an out-of-heap memory and a shared disk according to the object identifier and the position identifier, and matches the user position information with the geographical range information to determine a matched object; and summarizing the matching objects of the plurality of processing threads to obtain a first object list. According to the method, the GB-level data geographical screening efficiency and cost are improved, geographical screening and text filtering decoupling are achieved, and the LBS judgment speed is increased.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, in particular to a LBS parallel determination method, system, device and storage medium. BACKGROUND

[0002] In modern Internet services, especially in business scenarios such as e-commerce, travel and local life, location-based services (LBS) play a crucial role. In traditional technical practice, geographic information (such as polygon vertex coordinates) and business text information (such as store name, activity description) are often coupled and stored in a single search engine (such as Elasticsearch, ES). This architecture exposes serious drawbacks in large-scale applications, so the industry has proposed the idea of decoupling geographic screening and text filtering. However, in actual applications, especially when the geographic fence data reaches GB level and needs to be updated frequently, geographic screening becomes a new efficiency bottleneck, making it difficult to apply the solution of decoupling geographic screening and text filtering. SUMMARY

[0003] The present application aims to at least solve one of the technical problems existing in the prior art. To this end, the present application provides a LBS parallel determination method, system, device and storage medium, which can improve the efficiency of geographic screening of GB-level data and take into account the cost, realize decoupling of geographic screening and text filtering, and is conducive to improving the LBS determination speed.

[0004] In a first aspect, an embodiment of the present application provides a LBS parallel determination method, comprising: acquiring and performing parallel matching on user location information and business text, and performing intersection processing on the first object list and the second object list obtained by matching to obtain a target object list; wherein, matching the user location information comprises: acquiring a first data set comprising object identifiers and location identifiers from a remote cache; starting a plurality of processing threads and distributing the first data set to the plurality of processing threads after sharding; each processing thread reads geographic range information from a near cache composed of off-heap memory and shared disk according to the object identifier and the location identifier, and matches the user location information with the geographic range information to determine a matching object; aggregating the matching objects of the plurality of processing threads to obtain the first object list.

[0005] According to some embodiments of the present application, the user location information is latitude and longitude coordinate information, and the first data set comprising object identifiers and location identifiers is acquired from a remote cache, which further comprises: convert the latitude and longitude coordinate information into a plurality of precision levels of H3 grid identifiers.

[0006] According to some embodiments of the present application, the geographic range information is a set of H3 grid identifiers, and each processing thread reads geographic range information from a near cache based on off-heap memory and shared disks according to the object identifier and the location identifier, and matches the user location information with the geographic range information to determine a matching object, including: Each processing thread reads the set of H3 grid identifiers from a near cache based on off-heap memory and shared disks according to the object identifier and the location identifier, and matches the H3 grid identifier with the set of H3 grid identifiers to determine a matching object.

[0007] According to some embodiments of the present application, each processing thread reads geographic range information from a near cache based on off-heap memory and shared disks according to the object identifier and the location identifier, including: Each processing thread combines the object identifier and the location identifier into a combined identifier. Read geographic range information from a near cache based on off-heap memory and shared disks according to the combined identifier.

[0008] According to some embodiments of the present application, the LBS parallel determination method further includes: Submit the service text to a search engine to perform a text query on a service database to obtain a second object list.

[0009] According to some embodiments of the present application, the LBS parallel determination method further includes: In the case that the user location information and the geographic range information do not match successfully, skip the current matching and read data from a service database and update data of the near cache.

[0010] According to some embodiments of the present application, the LBS parallel determination method further includes: Monitor a service database, and in the case that the service database has data updates, perform data updates on at least one of the near cache and the remote cache.

[0011] In a second aspect, embodiments of the present application provide an LBS parallel determination system, including: A service database for storing service text data. A server configured with off-heap memory and a search engine, the server being mounted with a shared disk, the shared disk and the off-heap memory constituting a near cache, the near cache being used to store geographic range information, the search engine being used to perform text query in the service database according to service text; A remote cache used to store a first data set comprising object identification and location identification; An application service instance configured in the server, the application service instance being used to execute the above-mentioned LBS parallel judgment method.

[0012] In a third aspect, an embodiment of the present application provides an LBS parallel judgment device, comprising a processor and a memory, the memory storing a computer program, and the processor being used to implement the above-mentioned LBS parallel judgment method when the computer program is executed.

[0013] In a fourth aspect, an embodiment of the present application provides a storage medium, the storage medium storing a computer program, and the computer program being used to implement the above-mentioned LBS parallel judgment method when executed.

[0014] The embodiment of the present application has at least the following beneficial effects: Parallel matching of user location information and service text is implemented to decouple geographic screening and text filtering, and intersection processing is performed on the first object list and the second object list obtained through matching to obtain a target object list. In the process of matching user location information, a combined cache is constructed through a remote cache and a near cache to realize GB-level data caching. Moreover, the near cache is composed of off-heap memory and a shared disk, which is low in cost and avoids the risk of pause caused by JVM garbage collection during read-write operation. The first data set is fragmented and multiple processing threads are started to improve matching efficiency. In this way, the efficiency of geographic screening of GB-level data is improved, and the decoupling of geographic screening and text filtering is realized, which is conducive to improving the LBS judgment speed.

[0015] Additional aspects and advantages of the present application will be made apparent by the following description and the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0016] The above and / or additional aspects and advantages of the present application will become apparent and be readily understood by considering the following detailed description, from which the novel aspects and features of the present application will become apparent, by referring to the drawings, in which: Figure 1 It is a principle block diagram of the LBS parallel judgment system of the embodiment of the present application; Figure 2 It is one of the step flowcharts of the LBS parallel judgment method of the embodiment of the present application; Figure 3Figure 2 is a flow chart of a step of the LBS parallel determination method of an embodiment of the present application; Figure 4 Figure 3 is a principle block diagram of the LBS parallel determination device of an embodiment of the present application. DETAILED DESCRIPTION

[0017] Embodiments of the present application are described in detail below with reference to examples shown in the attached drawings, wherein the same or similar reference numerals represent the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the attached drawings are exemplary and are only used to explain the present application, and cannot be understood as a limitation of the present application.

[0018] In the description of the present application, the meaning of "several" is one or more, the meaning of "multiple" is two or more, greater than, less than, more than, etc. are understood as not including the number, "above", "below", "within", etc. are understood as including the number. If there is a description of "first", "second", etc. is only used for the purpose of distinguishing technical features, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features or implicitly indicating the order of indicated technical features.

[0019] For LBS services, the traditional technology is to store geographic information (such as polygon vertex coordinates) and business text information (such as store name, activity description) in a single search engine (such as Elasticsearch, ES) in a coupled manner. Although this architecture is easy to implement, it has the following shortcomings in large-scale applications: 1) Performance bottleneck: the Geo-Shape query performance of ES will decrease sharply when the data volume and concurrency volume are huge, and it is difficult to meet the high standard delay requirement of 50 milliseconds level of online transaction system; 2) Resource coupling and competition: index update, query load of geographic data and business text data interfere with each other, leading to complex resource allocation and system optimization; 3) Operation difficulty: the maintenance, expansion and fault recovery of a single cluster are interrelated, and the system robustness is poor.

[0020] In order to solve the above coupling problem, the industry has come up with the idea of decoupling geographic screening and text filtering. However, this idea faces the following technical difficulties: how to build a high-performance, high-stability and low-cost geographic determination service. When the geographic fence data to be processed reaches GB level and needs to be updated dynamically at high frequency, the background geographic determination logic will become a new and more serious performance bottleneck.

[0021] In the process of realizing "decoupling of geographic screening and text filtering", the following difficulties are found: 1) JVM (Java Virtual Machine) GC (Garbage Collection) performance dilemma: If you want to pursue the ultimate performance, you will load GB-level geographic data (such as the fence set after gridding) directly into the JVM heap memory of the application service (for example, using GuavaCache or Caffeine), which will inevitably cause unpredictable "Stop-The-World" full GC for hundreds of milliseconds or even seconds. For online transaction systems that require P99 response time to be stable in milliseconds, this service interruption caused by GC is unacceptable.

[0022] 2) High storage and operation cost: If you want to avoid the GC problem and put GB-level all geographic data into a distributed memory cache (such as Redis), although the performance can be expected, the high memory resources, hardware procurement costs and long-term operation costs are difficult for most enterprises to bear, and the economic feasibility is low.

[0023] Based on the above reasons, geographic screening has become a new efficiency bottleneck, forming a significant "bottleneck effect", which makes it difficult to apply the solution of decoupling geographic screening and text filtering. Therefore, the embodiment provides an LBS parallel judgment method, which can improve the efficiency of GB-level data geographic screening and consider the cost, realize the decoupling of geographic screening and text filtering, and is beneficial to improve the LBS judgment speed.

[0024] Before describing the LBS parallel judgment method, the embodiment describes the system architecture for implementing the LBS parallel judgment method. Please refer to Figure 1 The embodiment provides an LBS parallel judgment system, which comprises: a business database for storing business text data; a server configured with off-heap memory and a search engine, the server being mounted with a shared disk, the shared disk and the off-heap memory forming a near cache, the near cache being used for storing geographic range information, and the search engine being used for text query in the business database according to business text; a remote cache for storing a first data set comprising object identifiers and location identifiers; an application service instance configured in the server, the application service instance being used for executing the following LBS parallel judgment method. The application service instance can comprise a plurality of modules, such as the request interface, geographic screening and intersection operation modules shown in Figure 1

[0025] ​Exemplarily, the business database is used to store business text data, such as store name, dish name, and dish category, and other metadata. In order to facilitate the storage of the relationship between the metadata, the business database can adopt a relational database, such as a MySQL database. The server is a hardware carrier for carrying software entities such as search engines (such as Elasticsearch, ES) and application service instances. Considering the access requirements of different characteristic data in the business scenario, the server of the embodiment adopts a combination architecture of two caches to constitute a geographic location cache system, which is beneficial to balance the access speed, storage capacity and economic cost.

[0026] The remote cache is mainly used to store the core mapping relationship with the most frequent access and relatively controllable data volume, that is, the first data set. The first data set includes object identifier and location identifier. For example, the remote cache uses a high-performance in-memory database such as Redis. Redis uses in-memory storage data, and the read-write speed is very fast, reaching tens of thousands of operations per second. Taking the takeout business scenario as an example, the object identifier is configured as a store ID (Identity Document, identity identifier), and the location identifier is configured as a delivery scheme ID. The delivery scheme ID is used to identify a delivery scheme, and the delivery scheme is used to record the geographic delivery range of different stores. The Redis Hash structure is set in the remote cache, the key of which is TakeoutStoreList, and the internal storage of which is the mapping relationship of all stores. Each sub-key (field) is a store ID (storeId), and the corresponding value (value) is a JSON string containing all delivery scheme IDs (areaId) and delivery types (express delivery, fast delivery, self-delivery, and self-pickup) associated with the store. This part of data is the entry point of subsequent queries and requires very high read performance.

[0027] In the takeout business scenario, the total number of stores of the takeout platform can reach thousands, and each store can be configured with one or more delivery schemes. The delivery scheme records the range of the deliverable geographic location, that is, the delivery circle. The total number of delivery circles can reach tens of thousands, and the total data volume after grid processing (such as H3 grid) can reach more than 20 GB. Such a large data scale has far exceeded the capacity of the heap memory of the conventional JVM. The heap memory such as Caffeine cannot support GB-level data, that is, it cannot cache all data in the heap memory of the JVM. If all data is placed in an in-memory database such as Redis, the cost will be extremely high. Therefore, the embodiment adopts a storage technology based on off-heap memory and shared disk as an implementation scheme of near cache. The near cache (Near Cache) is a local cache mechanism used to store hot data on the server node. By caching hot data locally, the near cache can significantly reduce the network round trip time, which is beneficial to improve the response speed and performance.

[0028] Among them, the memory can be divided into on-heap memory and off-heap memory, wherein the on-heap memory is the memory applied for using JVM, the on-heap memory completely follows the memory management mechanism of JVM, adopts a garbage collector to uniformly manage the memory, the garbage collector will be thoroughly recycled at a certain time point, that is, Full GC, the garbage collection will scan all the allocated on-heap memory, which will cause a certain impact on the performance of the JAVA application in the process, and may also produce "Stop The World" type of lag. The off-heap memory is the memory directly applied to the kernel, which is directly managed by the operating system rather than JVM, so that the impact of garbage collection on the application can be avoided.

[0029] The off-heap memory is used to avoid the lag caused by the garbage collection of the JVM in the in-heap memory, and to improve the fluency and processing efficiency of data processing. However, considering the limited storage capacity of the off-heap memory, the server of the embodiment is mounted with a shared disk. The shared disk uses an SSD (Solid State Disk), which has the advantages of fast startup, small read delay, no impact of fragmentation on read time, and fast writing speed. The off-heap memory and the shared disk form a near cache, which avoids the in-heap cache while increasing the storage capacity of the data. In addition, due to the read-write advantages of the SSD, the impact of read-write delay can be reduced. The near cache uses a MapDB database for data management. The MapDB database provides high-performance data caching and persistent data storage functions. The MapDB database can be used as an efficient data caching tool to provide fast data access for application programs. The MapDB database provides persistent data storage functions to help application programs store data on the hard disk for future use. In this way, the off-heap memory and the shared disk form a near cache, and the MapDB database is used to manage the data of the near cache, so that the application program can operate a data set much larger than the physical memory as if it were operating ordinary in-heap memory. Compared with storing all data in a memory database such as Redis, the near cache solution of the embodiment takes into account the storage cost and data storage capacity, achieving a balance between economical and efficient near cache and querying massive data. The data structure of the near cache uses a key-value pair. The key of the key-value pair is a combined string, which can be combined with an object identifier and a location identifier, for example, the example of the combined string is "storeId: areaId". The storeId is used to represent the store ID, and the areaId is used to represent the distribution scheme ID. The value of the key-value pair is a Java set collection, which stores geographic range information. For example, the Java set collection stores all grid IDs covered by the distribution circle after grid processing (such as H3 grid processing). The grid ID is used to identify the grid obtained by grid processing (such as H3 grid processing) of the geographic area range. H3 grid is a global hierarchical geospatial indexing system. In the embodiment, the original polygon distribution range of the store is pre-processed by multi-precision level (for example, from precision 5 to precision 14) grid processing to generate a series of H3 grid IDs and compress them, and then store them in the set collection of the MapDB database. Using H3 instead of GeoHash helps to solve the problem of long string and index expansion.

[0030] It is worth mentioning that a plurality of application service instances can be configured in the server of the embodiment, and the plurality of application service instances can jointly use the shared disk to reduce storage cost and ensure data consistency. Of course, the server of the embodiment can also be deployed in multiple servers, and the shared disk can be jointly used between the plurality of servers. In this way, the shared hard disk can be shared by the plurality of application service instances in the same server or the plurality of application service instances in the plurality of servers, which is beneficial to reduce operation and maintenance complexity and improve system flexibility, avoids maintaining an independent cache for each application service instance, and simplifies system deployment and management.

[0031] Please refer to Figure 2 and Figure 3 The embodiment discloses a kind of LBS parallel determination method, comprising the following steps.It should be noted that the step of the embodiment is only for the convenience of review understanding, not to limit the execution order of step.The content of each step is described in detail as follows: S100, user location information and service text are obtained and parallel matched, and the intersection of the first object list and the second object list obtained by matching is handled to obtain the target object list; Specifically, please refer to Figure 2 , step S100 includes: S110, receiving the search request of client, and the search request includes user location information and service text; S120, in response to the search request, user location information and service text are obtained; S130, based on parallel processing mode, user location information is matched to obtain the first object list, and service text is matched to obtain the second object list; S140, the intersection of the first object list and the second object list is handled to obtain the target object list.

[0032] Illustratively, one of the examples of client can be take-out APP, when user triggers a search request (such as input and search "pizza") on client, client sends search request to server, and the application service instance in server receives the search request of client, and the search request includes user location information (such as longitude and latitude coordinates) and service text (such as "pizza"). Application service instance responds to the search request, parses the search request to obtain user location information and service text, wherein the user location information is used for geographical screening, and the service text is used for text filtering. Geographical screening and text filtering based on parallel processing mode can improve data processing efficiency. The intersection of the first object list and the second object list obtained by processing can obtain the object that meets geographical range and service text at the same time, for example, "pizza" store in the delivery range covering the current location of user, so as to obtain the target object list.

[0033] In theory, geographic screening and text filtering can be processed in parallel to improve data processing efficiency. However, the final processing time of data parallel processing depends on the completion time of the slowest task. As described above, geographic screening becomes the efficiency bottleneck in the prior art, resulting in a mismatch between the processing times of geographic screening and text filtering, and the true parallel processing cannot be achieved. Therefore, the present embodiment improves the method of geographic screening based on the above combined cache architecture. Wherein, please refer to Figure 3 In step S130, matching the user location information includes: S131, obtaining a first data set including object identifier and location identifier from the remote cache; S132, starting multiple processing threads and distributing the first data set to the multiple processing threads after sharding; S133, each processing thread reads the geographic range information from the near cache composed of off-heap memory and shared disk according to the object identifier and the location identifier, and matches the user location information with the geographic range information to determine the matching object; S134, aggregating the matching objects of the multiple processing threads to obtain a first object list.

[0034] Exemplarily, the remote cache is used to store the first data set, the first data set includes object identifiers and location identifiers, which are the core mapping relationship of the most frequent access, and the remote cache adopts a high-performance Redis memory database, which can realize fast reading of data. The application service instance reads the first data set from the remote cache in full, and obtains the store ID (storeId) of all active stores and the associated distribution scheme ID (areaId). The first data set is matched concurrently, for example, multiple processing threads are started by using a Java concurrency library, and the first data set is divided and distributed to multiple processing threads after being sharded, so that each processing thread respectively matches part of the data of the first data set, which is beneficial to improve the data processing efficiency. Each processing thread obtains the geographic range information from the near cache according to the object identifier and the location identifier, for example, as exemplified above, the near cache stores information in the form of key-value pairs, and the key of the key-value pair is a combined string formed by the object identifier and the location identifier. Therefore, each processing thread forms a combined string to be matched by combining the current object identifier and the location identifier, and finds the corresponding value from the near cache according to the combined string to be matched. The value corresponds to the geographic range information. The user location information is matched with the found geographic range information, and if the user location is located within the found geographic range, the object identifier corresponding to the current geographic range information is determined as the matching object. The near cache is composed of off-heap memory and shared disk, which can avoid the risk of lag caused by JVM garbage collection, and ensure the stable performance of the geographic screening task in milliseconds. After matching, the matching objects of multiple processing threads are summarized to obtain a first object list, so as to facilitate subsequent intersection processing.

[0035] The above scheme performs parallel matching on user location information and business text, realizes decoupling of geographic screening and text filtering, and performs intersection processing on the first object list and the second object list obtained by matching to obtain a target object list. In the process of matching the user location information, a combined cache is constructed by using the remote cache and the near cache, GB-level data caching is realized, and the near cache is composed of off-heap memory and shared disk, which has low cost and avoids the risk of pause caused by JVM garbage collection during read and write operations. The first data set is sharded and multiple processing threads are started, which can improve the matching efficiency. In this way, the efficiency of geographic screening of GB-level data can be improved while the cost is taken into account, the geographic screening and the text filtering are decoupled, and the LBS determination speed is improved.

[0036] In some application examples, the user location information is latitude and longitude coordinate information, and the step S131 of obtaining the first data set including object identifiers and location identifiers from the remote cache further includes: converting the latitude and longitude coordinate information into a plurality of precision levels of H3 grid identifiers.

[0037] For example, the longitude and latitude coordinate information includes a longitude coordinate value and a latitude coordinate value, both of which constitute user position information representing a position point on a map. Although this representation can accurately represent the user's position, it is not conducive to matching the user's position information with the geographic range information. For example, taking the delivery area of a store of a takeout platform as an example, the delivery area includes multiple vertices, and the multiple vertices form a polygon. If the longitude and latitude coordinates are matched, the longitude and latitude coordinates of the user need to be calculated with each vertex of the delivery area to determine the relationship between the longitude and latitude coordinates of the user and the polygon corresponding to the delivery area, which has a high calculation complexity and is not conducive to fast calculation. Therefore, the longitude and latitude coordinate information is converted into a plurality of precision levels of H3 grid identifiers, and the precision levels can be customized, such as division according to provinces, cities, streets, or districts. After being converted into a plurality of precision levels of H3 grid identifiers, the H3 grid identifiers can be quickly matched, for example, whether the H3 grid identifier corresponding to the user's position information is included in the grid identifier set corresponding to the delivery area. If so, it indicates that the delivery range of the store can cover the current position of the user, and therefore, the store ID of the store can be determined as the matching object.

[0038] Matching the above application examples, the geographic range information is an H3 grid identifier set, and step S133, each processing thread reads the geographic range information from the near cache based on the off-heap memory and the shared disk according to the object identifier and the position identifier, and matches the user position information with the geographic range information to determine the matching object, including: Each processing thread reads the H3 grid identifier set from the near cache based on the off-heap memory and the shared disk according to the object identifier and the position identifier, and matches the H3 grid identifier with the H3 grid identifier set to determine the matching object.

[0039] For example, the near cache is composed of off-heap memory and shared disk, which can realize a persistent near cache of GB-level data, and can move massive data out of the heap memory of the JVM to avoid the pause caused by JVM garbage collection. The shared disk uses a solid state disk (SSD) to carry massive data through a low-cost medium, which significantly reduces the hardware cost and reduces the pause risk due to the avoidance of JVM GC, thereby improving the running efficiency and system stability. The H3 grid identifier set includes one or more H3 grid identifiers, and each H3 grid identifier is used to represent the delivery range of a store. Local caching of GB-level data can improve data reading efficiency and shorten data processing time, thereby shortening the time of the geographic screening task.

[0040] In some other application examples, step S133, each processing thread reads the geographic range information from the near cache based on the off-heap memory and the shared disk according to the object identifier and the position identifier, including: Each processing thread combines the object identifier and the location identifier into a combined identifier; based on the combined identifier, it reads the geographic range information from the near cache composed of off-heap memory and shared disk.

[0041] For example, in a takeout business, a store may have multiple delivery ranges. For example, the delivery range during emergencies such as heavy rain or large-scale promotions may be different from the daily delivery range. In addition, different stores may have the same delivery range. Therefore, in data storage, the mapping relationship between object identifiers and location identifiers may overlap. In order to facilitate the determination of the geographic range corresponding to the object identifier, in the near cache, the combined string consisting of the object identifier and the location identifier is used as the key of the key-value pair to ensure the uniqueness of the key. Accordingly, in the process of reading the geographic range information, each processing thread combines the object identifier (such as the storeId in the example above) and the location identifier (such as the areaId in the example above) into a combined identifier (such as storeId:areaId), and reads the corresponding geographic range information from the near cache based on the combined identifier.

[0042] In some application examples, the LBS parallel determination method further includes: The business text is submitted to a search engine, so that the search engine performs a text query on a business database to obtain a second object list.

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

[0044] In some application examples, the LBS parallel determination method further includes: If the user location information fails to match the geographic range information, the current match is skipped and data is read from the business database and the recently cached data is updated.

[0045] For example, during the geographic screening task, there may be a situation where the user's geographic location information and geographic range information are not matched successfully. At this time, a fault tolerance and cache write-back mechanism can be added. For example, during the matching process, if the corresponding matching object cannot be matched based on the user's location information, it may be because the recent cache information has not been updated in time. At this time, the grade matching is skipped to ensure the overall response speed, and a cache write-back task is triggered asynchronously. The cache write-back task reads the latest data from the business database and updates the recent cached data to ensure the hit rate of subsequent queries.

[0046] In some application examples, the LBS parallel judgment method further comprises: monitoring the service database, and updating at least one of the near cache and the remote cache in the case of data update in the service database.

[0047] For example, in order to ensure the timeliness of the data of the geographic screening, especially in the scenario of rainstorm and the like which needs to quickly adjust the delivery range, a Kafka-based message consumer application program can be deployed, which subscribes to a message topic related to the change of the store delivery range. Once there is a change message, for example, an operator modifies the range of a certain delivery station in the background, the application program will immediately receive the message, parse the change content, and update the mapping relationship between the store ID and the delivery scheme ID in the remote cache and the specific grid data of the delivery scheme in the near cache. This asynchronous data synchronization link is beneficial to ensure that the data change can take effect in the remote cache and the near cache in a near real-time manner.

[0048] The above scheme builds a combined cache through the remote cache and the near cache in terms of storage structure, wherein the hot data (such as the core mapping relationship) is migrated from the service database to the remote cache, the read-write frequency of the service database is reduced, and the pressure of the service database is reduced; moreover, the memory read-write speed (microsecond level) of the remote cache is much faster than the disk IO read-write speed (millisecond level), which is beneficial to improve the system response speed, and the remote cache can share data across application nodes, solving the inconsistency problem of the local cache; the near cache is built based on the off-heap memory and the mounted shared disk, avoiding the pause risk of JVM garbage collection and reducing the influence of network latency on data reading, and the near cache realizes data sharing through the shared disk, which is beneficial to solve the inconsistency problem of the local cache. The remote cache is used to store data with relatively controllable data volume, and the near cache realizes the storage of GB-level data through the shared disk, avoiding the configuration of large memory for each application service instance or the use of expensive distributed cache, and the combination of the remote cache and the near cache can avoid storing massive data in the remote cache, thereby increasing the storage cost of the remote cache. In addition to using the combined cache, the above scheme starts multiple processing threads in the process of the geographic screening task, matches the first data set read from the remote cache after sharding, changes the serial processing logic to parallel processing logic, which is beneficial to improve the processing efficiency, matches the processing efficiency of the geographic screening task with that of the text filtering task, and thus realizes the true parallel processing of the geographic screening and the text filtering.

[0049] Please refer to Figure 4The embodiment also provides an LBS parallel judgment device, which comprises a processor 210 and a memory 220, and the memory 220 stores a computer program, and the processor 210 is used for realizing the LBS parallel judgment method when the computer program is run. The LBS parallel judgment method is described above, and details are not described herein. The user location information and the service text are matched in parallel, the geographic screening and the text filtering are decoupled, the first object list and the second object list obtained through matching are processed by intersection, and the target object list is obtained. In the process of matching the user location information, a combined cache is constructed through a remote cache and a near cache, GB-level data caching is realized, the near cache is composed of off-heap memory and shared disks, the cost is low, and the risk of pause caused by JVM garbage collection is avoided when read and write operations are performed. The matching efficiency can be improved by sharding the first data set and starting multiple processing threads. In this way, the efficiency of geographic screening of GB-level data can be improved, the cost is taken into account, the geographic screening and the text filtering are decoupled, and the LBS judgment speed is improved.

[0050] The embodiment also provides a storage medium, which stores a computer program, and the computer program realizes the LBS parallel judgment method when the computer program is run. The LBS parallel judgment method is described above, and details are not described herein. The user location information and the service text are matched in parallel, the geographic screening and the text filtering are decoupled, the first object list and the second object list obtained through matching are processed by intersection, and the target object list is obtained. In the process of matching the user location information, a combined cache is constructed through a remote cache and a near cache, GB-level data caching is realized, the near cache is composed of off-heap memory and shared disks, the cost is low, and the risk of pause caused by JVM garbage collection is avoided when read and write operations are performed. The matching efficiency can be improved by sharding the first data set and starting multiple processing threads. In this way, the efficiency of geographic screening of GB-level data can be improved, the cost is taken into account, the geographic screening and the text filtering are decoupled, and the LBS judgment speed is improved.

[0051] The embodiment of the application is described in detail above with reference to the drawings, but the application is not limited to the above-described embodiment, and various changes can be made within the knowledge of those skilled in the art without departing from the purpose of the application.

Claims

1. A method for parallel determination of LBS, characterized in that, The method comprises the following steps: acquiring and performing parallel matching on user location information and service text, and performing intersection processing on the first object list and the second object list obtained by matching to obtain a target object list; wherein the matching on the user location information comprises: acquiring a first data set comprising object identifiers and location identifiers 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 based on off-heap memory and shared disks according to the object identifiers and the location identifiers, and matches the user location information with the geographic range information to determine matching objects; the matching objects of the multiple processing threads are summarized to obtain the first object list.

2. The LBS parallel decision method of claim 1, wherein, The user location information is latitude and longitude coordinate information, and the first data set comprising object identifiers and location identifiers is acquired from the remote cache, which further comprises the following steps: convert the latitude and longitude coordinate information into H3 grid identifiers of multiple precision levels.

3. The LBS parallel decision method of claim 2, wherein, The geographic range information is an H3 grid identifier set, and each processing thread reads the H3 grid identifier set from the near cache based on off-heap memory and shared disks according to the object identifiers and the location identifiers, and matches the user location information with the geographic range information to determine matching objects, which comprises the following steps: each processing thread reads the H3 grid identifier set from the near cache based on off-heap memory and shared disks according to the object identifiers and the location identifiers, and matches the H3 grid identifier with the H3 grid identifier set to determine matching objects.

4. The LBS parallel decision method according to claim 1 or 2, characterized by, Each processing thread reads geographic range information from the near cache based on off-heap memory and shared disks according to the object identifiers and the location identifiers, which comprises the following steps: each processing thread combines the object identifiers and the location identifiers into a combined identifier; read geographic range information from the near cache based on off-heap memory and shared disks according to the combined identifier.

5. The LBS parallel decision method of claim 1, wherein, The LBS parallel determination method further comprises the following steps: submit the service text to a search engine to enable the search engine to perform text query on a service database to obtain a second object list.

6. The LBS parallel decision method of claim 1, wherein, The LBS parallel determination method further comprises the following steps: in the case that the matching of the user location information with the geographic range information is unsuccessful, skip the current matching and read data from the service database and update the data of the near cache.

7. The LBS parallel decision method of claim 1, wherein, The LBS parallel determination method further comprises the following steps: monitor the service database, and in the case that data update occurs in the service database, perform data update on at least one of the near cache and the remote cache.

8. An LBS parallel decision system, characterized by, The method comprises the following steps: a service database for storing service text data; a server configured with off-heap memory and a search engine, wherein 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 geographic range information, and the search engine is used to perform text query in the service database according to service text; a remote cache for storing a first data set comprising object identifiers and location identifiers; An application service instance is configured in the server, and the application service instance is used to execute the LBS parallel judgment method in any one of claims 1 to 7.

9. An LBS parallel decision device comprising a processor and a memory, the memory having stored therein a computer program, characterized by, The processor, when running the computer program, is configured to implement the LBS parallel judgment method in any one of claims 1 to 7.

10. A storage medium having stored therein a computer program, characterized in that The computer program, when running, implements the LBS parallel judgment method in any one of claims 1 to 7.

Images