Order thermodynamic diagram calculation method

Abstract

The invention discloses an order thermodynamic diagram calculation method, which does not depend on a distributed database for calculation any more, and improves the calculation performance and reduces the expansion cost by using the resources of service nodes. The data volume is dispersed in the internal memory of each service node, and only the calculation result is finally reserved, so that the calculation pressure of the single node is relatively small, the calculation result is in the internal memory, and the real-time query concurrency amount can be dealt with. The service node cluster can improve the computing performance through horizontal extension. If the data volume in the time period is increased, the flow is increased, and the service cluster needs to horizontally expand and receive the flow. Therefore, the utilization degree of resources of the service nodes is more sufficient, and the expansion cost is natural and relatively low.

Description

Technical Field

[0001] The present invention belongs to the field of order heat map calculation, and specifically, relates to a method for calculating an order heat map. Background Art

[0002] A heat map is a data visualization technology that shows the distribution of data through color changes. In the shared mobility industry, heat maps can be used to display information such as the demand hotspots and driver distribution of online car-hailing services, providing strong support for demand prediction, resource optimization, market analysis, user experience improvement, and operation decision-making. Among them, the order heat Figure 1 map is an important means of presenting demand hotspots. The order heat map shows the quantity distribution of orders generated in different regions over a past period of time (e.g., the past 1 minute) through color changes.

[0003] Currently, in common technical solutions ( Figure 1 ), during the load stage of the service cluster, load balancing is performed according to traffic load or by using calculation methods such as taking the remainder after hashing a certain unique code, and the data processing method mostly utilizes the built-in capabilities of a distributed database for function calculation. In the scenario of order heat maps, mainly aggregate functions are used for aggregation operations. The existing solutions have the following problems:

[0004] The expansion cost and performance bottleneck of the distributed database. As the order data volume increases and the concurrency of heat map queries gradually increases, the distributed database also needs to increase the memory and expand distributed nodes, etc. to meet the performance requirements, and due to the data skew problem of the distributed data itself and the performance disadvantage in dealing with real-time data processing in high-concurrency scenarios, the computing power of the distributed database will gradually become stretched.

[0005] The hit rate of the local cache of the service node is relatively low and fluctuates greatly. With the load balancing method of the service cluster, it is difficult to ensure the hit rate of the local cache of the service node. Although routing using a unique code can ensure that queries are hit as much as possible under normal circumstances, fluctuations in the hit rate will still occur in the event of an exception in the service node.

[0006] Large network IO overhead. Since data collection and calculation are both in the distributed database, network IO will be generated for data storage, calculation requests, and result return. Although the use of local caches by service nodes alleviates this to a certain extent, due to the low and fluctuating hit rate, some network IO cannot be completely avoided.

[0007] In view of this, the present invention is specifically proposed. Summary of the Invention

[0008] The technical problem to be solved by the present invention is to overcome the deficiencies of the prior art and provide a method for calculating an order heat map, which solves the problems raised in the above background art.

[0009] In order to solve the above technical problems, the basic concept of the technical solution adopted by the present invention is:

[0010] A method for calculating an order heat map uses local resources of service nodes combined with a data routing management center and a publish / subscribe mechanism to calculate and present a distributed order heat map, specifically including the following steps:

[0011] When a service node starts, it sends a request to the data routing management center to obtain the topic information it needs to subscribe to. The routing management center assigns a unique subscription topic to each service node based on the dimensional rules of the tenant and operating area to ensure that data is not subscribed or calculated repeatedly.

[0012] The service node receives real-time order data through the message queue; each service node determines the target topic of the order data according to the rules assigned by the routing management center, and actively publishes the data to the corresponding topic through the pub / sub mechanism;

[0013] The service node that has subscribed to the topic receives the order data that matches its topic, processes and aggregates the data, generates the order heat map data according to the H3 grid, and saves the calculation results in the local memory cache;

[0014] When a user initiates a heat map query request, the cluster management center determines the target service node to which the query request should be routed based on the subscription rules of the data routing management center;

[0015] The target service node extracts the heat map data of the corresponding area from the local cache and returns the query results to the user, achieving real-time and accurate heat map query response.

[0016] Optionally, when a service node starts, it sends a request to the data routing management center to obtain the topic information it needs to subscribe to; the routing management center assigns a unique subscription topic to each service node based on the dimensional rules of the tenant and operating area to ensure that data is not repeatedly subscribed or calculated. The steps are as follows:

[0017] After the service node is started, it immediately sends a registration request to the data routing management center. The registration request contains the node's unique identifier, node operating status, the range of tenants that can be processed, and the range of operating areas;

[0018] After receiving the registration request from the service node, the routing management center loads the predefined tenant and operation area dimension rules from the configuration file or database. These rules define each tenant and its corresponding operation area and the unique subscription topics corresponding to these ranges;

[0019] The routing management center performs conflict checks on the matched candidate topic list to ensure that each topic is unique in the current node assignment and does not overlap with other node assignments, excluding the possibility of duplicate assignments;

[0020] The routing management center matches the scope of each node according to the dimension rules based on the tenant and operation area ranges declared by the service nodes, and filters out the candidate topic list corresponding to the node scope;

[0021] After completing the conflict check, the routing management center assigns unique subscription topics to the service nodes and marks these topics as "subscribed" to ensure that other nodes cannot subscribe to them repeatedly;

[0022] The routing management center returns the assigned topic list to the service nodes. The service nodes confirm the received topics and establish a subscription relationship with these topics after confirmation, completing the binding between the service nodes and the topics.

[0023] Optionally, the service nodes receive real-time order data through the message queue; the specific steps for each service node to determine the target topic of the order data according to the rules assigned by the routing management center and actively publish the data to the corresponding topic through the pub / sub mechanism are as follows:

[0024] After the service nodes are started, according to the topic rules assigned by the routing management center, they start the listening service for the message queue (MQ) and only receive order data related to their assigned tenants and operation areas;

[0025] When the service nodes receive the order data pushed by the message queue, they immediately parse the order content, including the tenant identifier of the order, the H3 grid coordinates of the passenger boarding location, and other basic information of the order;

[0026] The service nodes determine the target topic corresponding to the order based on the parsed order information and the topic rules assigned by the routing management center. The matching rules are based on the tenant identifier of the order and the geographical scope of the H3 grid to ensure that each order data corresponds to a unique topic;

[0027] The service nodes classify and package the order data according to the target topic and actively publish it to the corresponding topic through the pub / sub mechanism to ensure that the nodes subscribing to the topic can receive the data in a timely manner;

[0028] After the service nodes complete the publication of the order data, they verify whether the data publication is successful and record the topic and timestamp of the published order data to ensure the integrity and traceability of data processing.

[0029] Optionally, the steps for a subscribed service node to receive order data matching its topic, process and aggregate the data, generate order heatmap data according to the H3 grid, and save the calculation results in the local memory cache are as follows:

[0030] The service node receives order data that matches its allocation rules through the subscribed topic. Each order data includes a tenant identifier, an order timestamp, the H3 grid coordinates of the passenger's boarding location, and other order-related information;

[0031] After receiving the data, the service node classifies the orders into the corresponding H3 grid sets according to the H3 grid coordinates of the orders, and sorts them according to the timestamps for subsequent processing and querying;

[0032] For each H3 grid set, the service node calculates the number of orders within a certain time window (such as 1 minute or 5 minutes) in the grid. The aggregation result is statistically counted in units of time windows to form the basic data unit of the heatmap;

[0033] The number of orders for each H3 grid obtained by calculation and the corresponding time window are stored in the local memory cache of the service node as key-value pairs, and the timestamp is marked for real-time management;

[0034] The service node periodically scans the memory cache and clears the expired H3 grid data according to the preset expiration time policy (such as retaining the data of the last 30 minutes) to ensure the effective utilization of the cache space and the real-time nature of the heatmap data.

[0035] Optionally, when the user initiates a heatmap query request, the specific steps for the cluster management center to determine the target service node to which the query request should be routed according to the subscription rules of the data routing management center are as follows:

[0036] The user sends a heatmap query request through the front-end interface or API. The query request includes clear tenant identifier, time range, and geographical area information. The cluster management center receives the request and parses out the query conditions;

[0037] The cluster management center extracts the corresponding H3 grid sets and tenant operation area information according to the tenant identifier and geographical area range in the query conditions, providing basic data for subsequent routing of the target node;

[0038] The cluster management center sends the parsed H3 grid sets and tenant information to the data routing management center. The data routing management center queries the service node subscription relationships corresponding to each H3 grid and tenant information according to the predefined subscription rules;

[0039] The data routing management center returns a list of all service nodes that match the query conditions, and the cluster management center filters out the preferred target nodes based on the node load status and health status;

[0040] The cluster management center forwards the query request to the selected target service node, along with the query conditions. After receiving the request, the target service node extracts the corresponding data from the local cache for processing and returns it.

[0041] Optionally, the steps for the target service node to extract the heatmap data of the corresponding area from the local cache and return the query result to the user to achieve real-time and accurate heatmap query response are as follows:

[0042] After receiving the query request forwarded by the cluster management center, the target service node parses the request content, including the tenant identifier, time range, and the H3 grid set of the geographical area queried;

[0043] Based on the parsed H3 grid set and time range, the service node retrieves the corresponding heatmap data from the local memory cache. The retrieval uses the H3 grid as the primary key and the time range as the condition to filter the order aggregation data that meets the query conditions;

[0044] For the multiple H3 grid data retrieved, the service node merges them in chronological order and grid distribution to generate a complete heatmap dataset, ensuring that the result covers all matching data within the query range;

[0045] The service node verifies the integrity and real-time nature of the generated heatmap dataset, including checking whether the data covers the requested H3 grid set and ensuring that all data is within the specified time range;

[0046] The service node packages the processed heatmap data into a query response and returns it to the user through the cluster management center, ensuring that the response content is structured and meets the user's query requirements.

[0047] After adopting the above technical solution, the present invention has the following beneficial effects compared with the prior art. Of course, any product implementing the present invention does not necessarily need to achieve all the advantages described below:

[0048] 1. It no longer relies on a distributed database for computing, uses the resources of the service node itself to improve computing performance and reduce expansion costs. The data volume is scattered in the memory of each service node, and finally only the calculation results are retained. Therefore, the computing pressure on a single node is relatively small, and the calculation results are in the memory, enabling it to handle a larger number of real-time query concurrencies. The service node cluster can improve computing performance through horizontal expansion. If the data volume increases within a time period, it inherently means an increase in traffic, and the service cluster itself also needs to horizontally expand to handle the traffic. Therefore, the utilization of the resources of the service node itself is more sufficient, and the expansion cost is naturally relatively low.

[0049] 2. Use the data routing management center and the pub / sub method to increase the cache hit rate to 100%. 1. The data routing management center ensures that requests are routed to the service nodes where the data exists. 2. The service node receives MQ messages (including order information of the passenger boarding location point), determines the topic according to the data routing management center and publishes the data. At the same time, the service node has determined the subscription topic according to the data routing management center, and the hot data within the same area will be sent to the same service node for calculation. Based on the above two points, it can be ensured that the data maintained in the local cache of the service node is 100% consistent with the entire set of data required for the requests reaching this service node, achieving 100% hit rate.

[0050] 3. The increase in cache hit rate and the adoption of the pub / sub method reduce the network I / O overhead (here, the network I / O overhead refers to the network I / O caused by data transmission due to network requests). Since the requested data must be in the local cache of the service node, the service node does not need to request the third-party database anymore, reducing a set of network I / O for requests and responses. The pub / sub method enables the calculated data to be actively broadcast to specific service nodes for calculation, instead of triggering a set of calculation requests and returning data by the service node's request as in the existing solutions, reducing the network I / O for triggering calculation requests.

[0051] The following further describes the specific implementation manners of the present invention in conjunction with the accompanying drawings. Description of the Drawings

[0052] The following drawings in the description are only some embodiments. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts. In the

[0053] In the drawings:

[0054] Figure 1 It is a schematic diagram of the grid dimension of the common technical solution;

[0055] Figure 2 It is a schematic diagram of the grid dimension structure of the present invention;

[0056] Figure 3 It is a flowchart.

[0057] It should be noted that these drawings and text descriptions are not intended to limit the scope of the concept of the present invention in any way, but to illustrate the concept of the present invention to those skilled in the art by referring to specific embodiments. Specific Embodiments

[0058] Now, the present invention will be further described in detail in conjunction with the accompanying drawings.

[0059] Please refer to Figures 1 - 3As shown, in this embodiment, a method for calculating an order heat map is provided, which uses local resources of service nodes combined with a data routing management center and a publish / subscribe mechanism to calculate and present a distributed order heat map, specifically including the following steps:

[0060] When a service node starts, it sends a request to the data routing management center to obtain the topic information it needs to subscribe to. The routing management center assigns a unique subscription topic to each service node based on the dimensional rules of the tenant and operating area to ensure that data is not subscribed or calculated repeatedly.

[0061] The service node receives real-time order data through the message queue; each service node determines the target topic of the order data according to the rules assigned by the routing management center, and actively publishes the data to the corresponding topic through the pub / sub mechanism;

[0062] The service node that has subscribed to the topic receives the order data that matches its topic, processes and aggregates the data, generates the order heat map data according to the H3 grid, and saves the calculation results in the local memory cache;

[0063] When a user initiates a heat map query request, the cluster management center determines the target service node to which the query request should be routed based on the subscription rules of the data routing management center;

[0064] The target service node extracts the heat map data of the corresponding area from the local cache and returns the query results to the user, achieving real-time and accurate heat map query response.

[0065] After the service node of the heat map service cluster is started, it will determine with the routing center which topics the node should subscribe to. The routing center formulates rules to determine the subscription topics according to the dimensions of tenants and operating areas (the principle of formulating rules is that a topic will only be subscribed to by one service node as long as it is met). After the service node determines the topic, it subscribes, and the routing center maintains the subscription relationship.

[0066] The service cluster subscribes to the MQ of the order data message. Any service node that receives the message as a consumer determines the topic according to the rules in the previous step and publishes the data through the pub / sub component. In step 1, a service node has subscribed to the topic. The service node that subscribes to the topic will calculate the data required for the heat map presentation and save it to the local cache of the service node.

[0067] When a driver or tenant queries heat map data, the cluster management center (such as a business gateway, etc.) needs to determine which service nodes the request should be forwarded to based on the routing center. The service node retrieves the data from the local cache and returns it to the querying party.

[0068] A method for calculating an order heat map according to claim 1, characterized in that when the service node starts, it sends a request to the data routing management center to obtain the topic information it needs to subscribe to; the routing management center assigns a unique subscription topic to each service node according to the dimension rules of the tenant and the operation area, and the steps to ensure that data is not subscribed or calculated repeatedly are as follows:

[0069] After the service node starts, it immediately sends a registration request to the data routing management center. The registration request includes the unique node identifier, the node running status, the tenant scope that can be processed, and the operation area scope;

[0070] After receiving the registration request of the service node, the routing management center loads the predefined tenant and operation area dimension rules from the configuration file or database. These rules clarify each tenant and its corresponding operation area, as well as the unique subscription topic corresponding to these scopes;

[0071] The routing management center performs a conflict check on the matching candidate topic list to ensure that each topic is unique in the current node assignment and does not overlap with other node assignments, excluding the possibility of duplicate assignment;

[0072] The routing management center matches the scope of each node according to the dimension rules based on the tenant and operation area scopes declared by the service node, and filters out the candidate topic list corresponding to the node scope;

[0073] After completing the conflict check, the routing management center assigns a unique subscription topic to the service node and marks these topics as "subscribed" to ensure that other nodes cannot subscribe repeatedly;

[0074] The routing management center returns the assigned topic list to the service node. The service node confirms the received topics and establishes a subscription relationship with these topics after confirmation, completing the binding between the service node and the topics.

[0075] A method for calculating an order heat map according to claim 1, characterized in that the service node receives real-time order data through a message queue; the specific steps for each service node to determine the target topic of the order data according to the rules assigned by the routing management center and actively publish the data to the corresponding topic through the pub / sub mechanism are as follows:

[0076] After the service node starts, according to the topic rules assigned by the routing management center, it starts the listening service for the message queue (MQ) and only receives order data related to its assigned tenant and operation area;

[0077] When the service node receives the order data pushed by the message queue, it immediately parses the order content, including the tenant identifier of the order, the H3 grid coordinates of the passenger's boarding location, and other basic information of the order;

[0078] The service node determines the target topic corresponding to the order based on the parsed order information and the topic rules assigned by the routing management center. The matching rules are based on the tenant ID of the order and the geographical scope of the H3 grid to ensure that each order data corresponds to a unique topic;

[0079] The service node classifies and packages the order data according to the target topic, and actively publishes it to the corresponding topic through the pub / sub mechanism to ensure that the nodes subscribed to the topic can receive the data in time;

[0080] After completing the release of order data, the service node verifies whether the data release is successful and records the subject and timestamp of the released order data to ensure the integrity and traceability of data processing.

[0081] According to claim 1, a method for calculating an order heat map is characterized in that the service node that has subscribed to a topic receives order data matching its topic, processes and aggregates the data, generates order heat map data according to the H3 grid, and saves the calculation results in the local memory cache. The specific steps are:

[0082] The service node receives order data that matches its allocation rules through the subscribed topics. Each order data contains the tenant ID, order timestamp, H3 grid coordinates of the passenger boarding location, and other order related information;

[0083] After receiving the data, the service node classifies the order into the corresponding H3 grid set according to the H3 grid coordinates of the order, and sorts it by timestamp for subsequent processing and query;

[0084] For each H3 grid set, the service node calculates the number of orders within a certain time window (such as 1 minute or 5 minutes) in the grid, and the aggregation result is counted in units of time windows to form the basic data unit of the heat map;

[0085] The calculated order quantity and corresponding time window of each H3 grid are stored as key-value pairs in the local memory cache of the service node and timestamped for real-time management.

[0086] The service node periodically scans the memory cache and cleans up expired H3 grid data according to the preset expiration time strategy (such as retaining the data in the last 30 minutes) to ensure the effective use of cache space and the real-time performance of heat map data.

[0087] The order heat map calculation method according to claim 1 is characterized in that when a user initiates a heat map query request, the cluster management center determines the target service node to which the query request should be routed according to the subscription rules of the data routing management center. The specific steps are:

[0088] The user sends a heat map query request through the front-end interface or API. The query request includes clear tenant identification, time range, and geographical area information. The cluster management center receives the request and parses out the query conditions;

[0089] Based on the tenant identification and geographical area range in the query conditions, the cluster management center extracts the corresponding H3 grid set and tenant operation area information, providing basic data for subsequent routing target nodes;

[0090] The cluster management center sends the parsed H3 grid set and tenant information to the data routing management center. The data routing management center queries the service node subscription relationships corresponding to each H3 grid and tenant information according to the predefined subscription rules;

[0091] The data routing management center returns a list of all service nodes that match the query conditions. The cluster management center filters out the preferred target nodes based on the node load status and health status;

[0092] The cluster management center forwards the query request to the selected target service node, along with the query conditions. After receiving the request, the target service node extracts the corresponding data from the local cache for processing and returns it.

[0093] According to the order heat map calculation method described in claim 1, the steps for the target service node to extract the heat map data of the corresponding area from the local cache and return the query result to the user to achieve real-time and accurate heat map query response are as follows:

[0094] After receiving the query request forwarded by the cluster management center, the target service node parses the request content, including the tenant identification, time range, and H3 grid set of the geographical area for the query;

[0095] Based on the parsed H3 grid set and time range, the service node retrieves the corresponding heat map data in the local memory cache. The retrieval uses the H3 grid as the primary key and the time range as the condition to filter out the order aggregation data that meets the query conditions;

[0096] For the multiple H3 grid data retrieved, the service node merges them according to the time sequence and grid distribution to generate a complete heat map data set, ensuring that the result covers all matching data within the query range;

[0097] The service node verifies the integrity and real-time nature of the generated heat map data set, including checking whether the data covers the requested H3 grid set and ensuring that all data is within the specified time range;

[0098] The service node packages the processed heat map data into a query response and returns it to the user through the cluster management center, ensuring that the response content is structured and meets the user's query requirements.

[0099] Explanation of related terms

[0100] ① Node: A service node in the service cluster, which can be understood as a specific physical machine or a container in container technology.

[0101] ② H3 grid: A grid in the Uber hexagonal hierarchical indexing grid system.

[0102] ③ H3 grid aggregation result: The number of orders whose passenger boarding locations in the order information belong to this H3 grid in the past period of time.

[0103] ④ Data routing management center: Abbreviated as the routing center, which stores the routing relationship between data and service nodes.

[0104] ⑤ pub / sub: Publish-subscribe mode. In the present invention, the pub / sub mode of Redis is used as an illustration.

[0105] ⑥ zk: zookeeper, which is used as an example of the implementation of the data routing management center in the present invention. It can be simply understood as storing key-value data, where the key is an identifier that can represent tenants and operation area dimensions, and the value is the service node.

[0106] ⑦ MQ: Message queue

[0107] The present invention is not limited to the above embodiments. Anyone should know that structural changes made under the inspiration of the present invention, as long as they have the same or similar technical solutions as the present invention, fall within the protection scope of the present invention. The technologies, shapes, and structures not described in detail in the present invention are all well-known technologies.

Claims

1. A method for calculating an order heat map, characterized in that, The calculation and presentation of the distributed order heat map are carried out by combining the local resources of the service node with the data routing management center and the publish / subscribe mechanism, which specifically includes the following steps: When the service node starts, it sends a request to the data routing management center to obtain the topic information it needs to subscribe to; the routing management center assigns a unique subscription topic to each service node according to the dimension rules of the tenant and the operation area to ensure that data is not subscribed or calculated repeatedly; The service node receives real-time order data through the message queue; each service node determines the target topic of the order data according to the rules assigned by the routing management center and actively publishes the data to the corresponding topic through the pub / sub mechanism; The service node that has subscribed to the topic receives the order data matching its topic, processes and aggregates the data, generates order heat map data according to the H3 grid, and saves the calculation result in the local memory cache; When the user initiates a heat map query request, the cluster management center determines the target service node to which the query request should be routed according to the subscription rules of the data routing management center; The target service node extracts the heat map data of the corresponding area from the local cache and returns the query result to the user to achieve real-time and accurate heat map query response.

2. The method for calculating an order heat map according to claim 1, wherein When the service node starts, it sends a request to the data routing management center to obtain the topic information it needs to subscribe to; the steps for the routing management center to assign a unique subscription topic to each service node according to the dimension rules of the tenant and the operation area to ensure that data is not subscribed or calculated repeatedly are as follows: After the service node starts, it immediately sends a registration request to the data routing management center. The registration request contains the node unique identifier, the node running status, the tenant range that can be processed, and the operation area range; After receiving the registration request of the service node, the routing management center loads the predefined tenant and operation area dimension rules from the configuration file or database. These rules clarify each tenant and its corresponding operation area, as well as the unique subscription topic corresponding to these ranges; The routing management center performs a conflict check on the matching candidate topic list to ensure that each topic is unique in the current node assignment and does not overlap with other node assignments, excluding the possibility of duplicate assignment; The routing management center matches the range of each node according to the dimension rules based on the tenant and operation area ranges declared by the service node and filters out the candidate topic list corresponding to the node range; After completing the conflict check, the routing management center assigns a unique subscription topic to the service node and marks these topics as "subscribed" to ensure that other nodes cannot subscribe repeatedly; The routing management center returns the assigned topic list to the service node. The service node confirms the received topics and establishes a subscription relationship with these topics after confirmation to complete the binding between the service node and the topics.

3. The method for calculating an order heat map according to claim 1, characterized in that, The service node receives real-time order data through the message queue; the specific steps for each service node to determine the target topic of the order data according to the rules assigned by the routing management center and actively publish the data to the corresponding topic are as follows: After the service node is started, it starts the monitoring service for the message queue according to the topic rules assigned by the routing management center, and only receives order data related to the tenant and operation area assigned to it; When the service node receives the order data pushed by the message queue, it immediately parses the order content, including the tenant ID of the order, the H3 grid coordinates of the passenger boarding location, and other basic information of the order; The service node determines the target topic corresponding to the order based on the parsed order information and the topic rules assigned by the routing management center. The matching rules are based on the tenant ID of the order and the geographical scope of the H3 grid to ensure that each order data corresponds to a unique topic; The service node classifies and packages the order data according to the target topic, and actively publishes it to the corresponding topic through the pub / sub mechanism to ensure that the nodes subscribed to the topic can receive the data in time; After completing the release of order data, the service node verifies whether the data release is successful and records the subject and timestamp of the released order data to ensure the integrity and traceability of data processing.

4. The method for calculating an order heat map according to claim 1, wherein, The specific steps for a service node that has subscribed to a topic to receive order data that matches its topic, process and aggregate the data, generate order heat map data according to the H3 grid, and save the calculation results in the local memory cache are as follows: The service node receives order data that matches its allocation rules through the subscribed topics. Each order data contains the tenant ID, order timestamp, H3 grid coordinates of the passenger boarding location, and other order related information; After receiving the data, the service node classifies the order into the corresponding H3 grid set according to the H3 grid coordinates of the order, and sorts it by timestamp for subsequent processing and query; For each H3 grid set, the service node calculates the number of orders within a certain time window in the grid, and the aggregation result is counted in units of time windows to form the basic data unit of the heat map; The calculated order quantity and corresponding time window of each H3 grid are stored as key-value pairs in the local memory cache of the service node and timestamped for real-time management. The service node periodically scans the memory cache and cleans up expired H3 grid data according to the preset expiration time strategy to ensure the effective use of cache space and the real-time nature of heat map data.

5. The method for calculating an order heat map according to claim 1, wherein, When a user initiates a heat map query request, the cluster management center determines the target service node to which the query request should be routed according to the subscription rules of the data routing management center. The specific steps are as follows: The user sends a heat map query request through the front-end interface or API. The query request contains a clear tenant ID, time range, and geographic area information. The cluster management center receives the request and parses the query conditions. The cluster management center extracts the corresponding H3 grid set and tenant operation area information based on the tenant ID and geographic area range in the query conditions, providing basic data for subsequent routing target nodes; The cluster management center sends the parsed H3 grid set and tenant information to the data routing management center. The data routing management center queries the service node subscription relationship corresponding to each H3 grid and tenant information according to the predefined subscription rules; The data routing management center returns a list of all service nodes that match the query conditions, and the cluster management center filters out the preferred target nodes based on the node load status and health status; The cluster management center forwards the query request to the selected target service node, along with the query conditions. After receiving the request, the target service node extracts the corresponding data from the local cache for processing and returns it.

6. The method for calculating an order heat map according to claim 1, wherein, The steps for the target service node to extract the heatmap data for the corresponding area from the local cache and return the query result to the user to achieve real-time and accurate heatmap query response are as follows: After receiving the query request forwarded by the cluster management center, the target service node parses the request content, including the tenant identifier, time range, and the H3 grid set of the geographical area queried; Based on the parsed H3 grid set and time range, the service node retrieves the corresponding heatmap data in the local memory cache. The retrieval uses the H3 grid as the primary key and the time range as the condition to filter the order aggregation data that meets the query conditions; For the multiple H3 grid data retrieved, the service node merges them according to the time sequence and grid distribution to generate a complete heatmap data set, ensuring that the result covers all the matching data within the query range; The service node verifies the integrity and real-time nature of the generated heatmap data set, including checking whether the data covers the requested H3 grid set and ensuring that all data is within the specified time range; The service node packages the processed heatmap data into a query response and returns it to the user through the cluster management center, ensuring that the response content is structured and meets the user's query requirements.

Images