Distributed batch request processing method for order guarantee

Abstract

The invention discloses a distributed batch request processing method for order guarantee, and relates to the technical field of cloud computing, and the method comprises the steps: carrying out the standardization and preprocessing of a multi-source updating request through a unified entrance, carrying out the intelligent aggregation and routing optimization based on a preset logic region, merging a large number of discrete requests into a small number of efficient region batch tasks, and carrying out the intelligent aggregation and routing optimization; the communication overhead and the cloud load are obviously reduced; then, an edge node is used as a local execution commander, and the order issuing of a control instruction is strictly followed by a business logic order, so that the accuracy and consistency of key operations such as price synchronization are ensured; and finally, the system continuously monitors performance and quality through full-link state tracking and multi-dimensional analysis reports, and can dynamically adjust region division and task distribution strategies based on data insight, so that adaptive optimization and intelligent load balancing are realized, the overall efficiency and sequence guarantee capability of large-scale electronic price tag updating are effectively improved, and the system is suitable for large-scale electronic price tag updating. And meanwhile, the operability and the long-term evolution potential of the system are enhanced.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, specifically to a distributed batch request processing method oriented towards order assurance. Background Technology

[0002] In existing technologies, price and content updates in large-scale electronic shelf label systems typically employ centralized control or simple edge proxy models, which have numerous limitations. A typical approach involves cloud applications directly sending one-way push commands to a massive number of discrete electronic shelf label devices. In this method, each update request is usually processed independently, resulting in a large number of small data packets flooding the network channel, causing significant protocol overhead, network congestion, and high latency. Especially when tens of thousands of shelf label updates are triggered simultaneously, cloud egress bandwidth and connection count can become bottlenecks.

[0003] Meanwhile, update requests initiated by different business systems (such as marketing and ERP) lack a unified coordination and sorting mechanism in the cloud. When multiple requests for the same price tag arrive almost simultaneously, network jitter or competition among processing threads can easily lead to a discrepancy between the execution order and the business logic sequence, potentially causing serious problems such as price display errors.

[0004] Furthermore, existing solutions typically group devices and allocate gateways based on static, physically proximity principles, lacking dynamic aggregation capabilities based on business logic. This rigid regional division is ill-suited for flexible business scenarios such as promotional bundles and category linkages, and it cannot be optimized based on real-time load. The role of edge gateways is often limited to command forwarding, lacking local scheduling and order guarantee capabilities.

[0005] Therefore, existing technologies struggle to achieve efficient, reliable, and adaptable large-scale electronic price tag batch management while ensuring the correctness of the update order. Summary of the Invention

[0006] The purpose of this invention is to provide a distributed batch request processing method with order-oriented guarantees to solve the problems mentioned in the background art.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a distributed batch request processing method oriented towards order guarantee, comprising the following steps:

[0008] S1. Receive update requests for multiple electronic shelf labels, wherein the update request includes the target electronic shelf label identifier and the content to be updated;

[0009] S2. Based on the preset logical area division rules, update requests for multiple electronic price tags within the same logical area are merged to generate corresponding area batch tasks, where each area batch task is associated with an edge processing node.

[0010] S3. Distribute the batch tasks of each region to its associated edge processing nodes, and each edge processing node controls the electronic price tags in its associated logical region to be updated sequentially according to the business logic order between the update requests.

[0011] S4. During the update process, track and record the execution status information of each update request;

[0012] S5. Based on the recorded execution status information, classify and aggregate the execution results of update requests belonging to the same preset type, and generate an analysis report containing the classification and aggregation results. Based on the generated analysis report, dynamically adjust the preset logical region division rules and distribute the batch tasks of the region to its associated edge processing nodes.

[0013] Preferably, the source of the update request includes at least one of the following: marketing rule engine, manual batch operation interface, scheduled task scheduler and external system integration interface; the update request also includes: unique request ID, request source priority and effective time strategy.

[0014] Preferably, the preset logical region division rule includes the following division dimensions:

[0015] Physical location, including division by shelf group, category zone or store area;

[0016] Based on business logic, it can be divided into categories based on promotional themes or supplier brands.

[0017] Preferably, a logical region-edge processing node mapping table is generated and maintained based on the logical region division rules. When merging update requests to generate a batch of region tasks, the specific steps include:

[0018] The mapping table is queried based on the target electronic price tag identifier to determine its logical region and associated edge processing node;

[0019] Update requests belonging to the same logical region and associated with the same edge processing node are merged to generate a regional batch task package containing the target region identifier, the associated edge node ID, and the list of price tag updates within this region.

[0020] Preferably, the business logic sequence includes at least one of the following:

[0021] The sequence number explicitly defined in the update request; the implicit order determined by the time in which multiple update requests for the same electronic shelf label are received; and the order determined based on the resource dependencies between the updated content.

[0022] Preferably, the edge processing node controls the electronic shelf labels to be updated sequentially according to the business logic order. Specifically, the edge processing node parses the received regional batch task packets and constructs a linear local update instruction sequence for each electronic shelf label within its logical region. Based on the local update instruction sequence, the edge processing node sends update instructions to each electronic shelf label in an orderly manner through a pipeline or sliding window mechanism using a wireless communication protocol, and confirms that the instructions have been executed.

[0023] Preferably, the execution status information is segmented tracking information, including: the processing status of the update request in the cloud, the execution status of the edge processing node, and the confirmation status of the target electronic price tag terminal; the tracking record includes at least: status change timestamp, request ID, associated entity ID, status code, and error information.

[0024] Preferably, the preset type includes at least one of the following dimensions: business dimension, technology dimension, spatiotemporal dimension, and result dimension; the classification and aggregation includes calculating key indicators, which include: update success rate, end-to-end average latency, failure root cause distribution, and load indicators of each edge processing node.

[0025] Preferably, the adjustment strategy for dynamically adjusting the preset logical region division rules based on the analysis report includes:

[0026] Logical regions can be split, merged, or reconstructed based on regional load or communication quality hotspots.

[0027] Virtual logical regions are dynamically created based on business relevance.

[0028] Preferably, the step of dynamically adjusting the distribution of regional batch tasks to their associated edge processing nodes based on the analysis report includes:

[0029] Based on the updated logical region division rules, the logical region-edge processing node mapping table is updated in real time to guide the distribution of new tasks;

[0030] Based on the real-time load data reported by each edge processing node, dynamic load balancing and rerouting are performed during task distribution.

[0031] In summary, the beneficial effects of this invention are:

[0032] This invention achieves request standardization and end-to-end tracking by establishing a unified entry point, and intelligently aggregates and optimizes requests based on logical regions, merging massive discrete updates into a small number of regional batch tasks, significantly reducing network overhead and cloud scheduling pressure; edge nodes, as local commanders, achieve orderly control of price tag updates within their jurisdiction by identifying the order of business logic, ensuring the correct timing of critical operations such as price changes.

[0033] Meanwhile, through end-to-end status tracking and multi-dimensional analysis reports, performance and quality are continuously monitored, and the regional division rules and task distribution strategies can be dynamically adjusted based on insights to achieve adaptive optimization and load balancing of the system. This improves the efficiency, reliability, order guarantee capability, and long-term evolvability of large-scale electronic price tag updates. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments of the invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 This is a schematic diagram of the overall process framework of the distributed batch request processing method with order guarantee according to the present invention.

[0036] Figure 2 This is a schematic diagram of the task aggregation process framework in the logical region of the distributed batch request processing method with order guarantee in this invention.

[0037] Figure 3 This is a schematic diagram of the process framework structure for edge node processing in the distributed batch request processing method oriented towards order protection of the present invention.

[0038] Figure 4 This is a schematic diagram of the process framework structure for generating analysis reports in the distributed batch request processing method oriented towards order assurance of the present invention.

[0039] Figure 5 This is a schematic diagram of the dynamically controlled process framework structure in the distributed batch request processing method with order guarantee of the present invention. Detailed Implementation

[0040] The present invention will now be described in further detail with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention. These drawings are simplified schematic diagrams, which are only used to illustrate the basic structure of the present invention in a schematic manner, and therefore only show the components related to the present invention.

[0041] To facilitate understanding of the present invention, a more complete description of the invention will be given below with reference to the accompanying drawings, which illustrate several embodiments of the invention. However, the invention can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided so that the disclosure of the invention will be more thorough and complete.

[0042] All features disclosed in this specification, or all steps in all disclosed methods or processes, may be combined in any way, except for mutually exclusive features and / or steps.

[0043] Any feature disclosed in this specification (including any appended claims, abstract, and drawings) may be replaced by other equivalent or similar features for a similar purpose, unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is merely one example of a series of equivalent or similar features.

[0044] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection, a direct connection, or an indirect connection through an intermediate medium; they can refer to the internal communication of at least two elements or the interaction relationship of at least two elements, unless otherwise explicitly limited. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0045] Please see Figure 1-3 The present invention provides an embodiment of a distributed batch request processing method with order guarantee, comprising the following steps:

[0046] Step 1: Receiving and Preprocessing Multiple Price Tag Update Requests

[0047] Establish a unified "Update Request Receiving API" or message queue entry point. All internal or external systems that need to change the price tag display must submit requests through this entry point.

[0048] The main sources of requests include:

[0049] Marketing rules engine: Automatically generates batch update requests when a promotional campaign takes effect or ends.

[0050] Manual batch operation interface: Operation staff can manually select a batch of products or price tags in the backend and uniformly modify the prices or display content.

[0051] Scheduled task scheduler: Executes preset timed price change plans.

[0052] External system integration: such as global price adjustment instructions initiated by the headquarters ERP.

[0053] Standardized structure of request data packets: Each valid update request must be encapsulated as a structured data packet, whose core fields include:

[0054] Request a unique ID: used for end-to-end tracing and deduplication.

[0055] Request source and priority: Identify the source of the request (e.g., "Emergency Flash Sale", "Daily Price Adjustment") and attach its business priority.

[0056] Target device identifier list: Unique identifiers for one or more electronic shelf labels (such as an array of device IDs). A more common approach is to provide a "product SKU list" and a "target store list," which the system then uses to automatically parse out the specific set of shelf label device IDs that need to be updated based on internal mapping relationships.

[0057] Content to be updated: A structured "display instruction". It includes:

[0058] Interface data reference: A link or identifier pointing to the latest price tag interface description file (data format) generated by the "Intelligent Interface Generation Engine".

[0059] Direct field updates: For minor updates that only require modifying a small amount of information such as price figures, key-value pairs can be directly included, such as {"current_price": "￥29.9"}.

[0060] Effective time strategy:

[0061] Effective immediately: Issued as soon as possible.

[0062] Scheduled activation: Activates at a specified future time (e.g., 00:00 the next day).

[0063] Conditions take effect: After the edge gateway confirms receipt of the instruction, the cloud or gateway will trigger the activation at a specified time.

[0064] Step 2: Task aggregation and route optimization based on logical regions

[0065] Based on preset logical region division rules, update requests for multiple electronic price tags within the same logical region are merged to generate corresponding regional batch tasks. Each regional batch task is associated with an edge processing node. Specifically:

[0066] I. Preset logical region division rules:

[0067] Rule definition and configuration: Each rule specifies a method for grouping physical devices into a certain "logical region", and each logical region is pre-bound to an "edge processing node" (i.e., edge computing gateway) responsible for managing it.

[0068] The dimensions for logical region division include the following:

[0069] Physical location aggregation:

[0070] By shelf group: All price tags in the same row or the same island cabinet belong to one area (e.g., "Fresh Produce Section A Row Shelf").

[0071] By category zone: All price tags in the entire "Dairy Products Refrigerated Display Case" or "Stationery Shelf Area" constitute one zone.

[0072] By store floor / zone: For large supermarkets, the "first floor supermarket area" and the "second floor clothing area" can be divided into different areas.

[0073] Business logic aggregation:

[0074] By promotion theme: Price tags for all products participating in the "Summer Coolness" promotion can be dynamically assigned to a temporary logical area.

[0075] By supplier / brand: Price tags on all products from the same brand can be considered as one area.

[0076] Mixed dimensions: Rules can be a combination of multiple dimensions, such as "Store A + Fresh Produce Category + Refrigeration Equipment" forming a logical area.

[0077] Region-Node Mapping Table:

[0078] All these partitioning rules ultimately generate and maintain a core "logical region-edge node mapping table". This table is defined statically or dynamically as follows: Region A is managed by edge gateway G1; Region B is managed by edge gateway G2.

[0079] II. Merging and generating batch tasks in different regions:

[0080] Intelligent parsing and region merging of requests: The system takes the received "target price tag ID list" as input and queries the preset logical region to which each price tag ID belongs (through the above mapping relationship).

[0081] Subsequently, the system executes a "merge sort" logic: it aggregates all price tag IDs belonging to the same logical area and their corresponding "content to be updated".

[0082] For example, suppose an update request needs to modify 1000 price tags, and these 1000 price tags are distributed in 50 different logical regions according to rules. Then, the system will classify these 1000 discrete targets into at most 50 groups.

[0083] Generate a batch task package for each identified logical region: For each identified logical region, the system generates a "batch task package for the region." This task package is a highly integrated instruction unit that includes:

[0084] Target region identifier: Specifies which logical region this task applies to.

[0085] Associated edge node ID: Directly indicates the specific edge gateway responsible for performing this task.

[0086] Price tag update list for this area: A structured list that shows all price tag IDs in this area that need to be updated, as well as the exact update content for each price tag (such as new price, image, color scheme, etc.).

[0087] Unified task metadata: such as priority, effective time, retry policy, etc., these attributes are consistent across all price tags in this area.

[0088] What used to require sending dozens or even hundreds of separate update commands to an edge gateway can now be consolidated into a single "batch command packet" containing all the information. This significantly reduces network protocol overhead, the number of connection establishments, and the total number of data packets.

[0089] An edge gateway only needs to receive, parse, and process a single task packet to update the relevant devices in the entire area under its jurisdiction, reducing the computational and scheduling complexity at the edge.

[0090] III. Relationship with edge processing nodes:

[0091] The generation of "regional batch tasks" is naturally strongly associated with edge processing nodes (gateways).

[0092] Since each "regional batch task package" has a clearly defined "associated edge node ID" when it is generated, the cloud scheduler can send the task package directly to the designated edge gateway without any ambiguity.

[0093] This avoids the need for gateways to process device commands that are not within their jurisdiction, and also avoids the inefficient pattern where the cloud needs to broadcast the same command to a large number of gateways.

[0094] After receiving the "regional batch task package", the edge gateway's role is upgraded from a simple "forwarder" to the "local dispatch and execution commander" of the region.

[0095] After the gateway parses the task packet, it can further optimize the local update strategy based on its built-in finer-grained device connection topology for the area, such as knowing which price tag is in which communication subnet segment, for example, by updating serially according to the cargo channel order to avoid wireless conflicts.

[0096] Step 3: Task distribution and ordered execution control at edge nodes

[0097] The batch tasks for each region are distributed to their associated edge processing nodes. Each edge processing node controls the electronic price tags within its associated logical region to be updated sequentially according to the business logic order between the update requests. Specifically:

[0098] The edge gateway receives "regional batch task packages" from the cloud via a secure communication link.

[0099] The gateway first performs integrity checks on the data packet, such as digital signature verification and format parsing, to confirm that it is a legitimate instruction sent to this node and prevent the execution of illegal or erroneous instructions.

[0100] Successfully parsed task packages are loaded into the gateway's memory, forming a "task queue to be executed".

[0101] The gateway creates an execution context for each task, recording its status (pending execution, in execution, partially completed, completed, failed), the list of associated price tag devices, and the business logic sequence requirements.

[0102] Cloud-based task packages may contain implicit dependencies or sequence requirements between update requests, which edge nodes need to identify and arrange in order of execution.

[0103] Sequence rule recognition:

[0104] Display order: The cloud may directly mark the sequence number of each sub-update request in the task package (for example, the price of the same product needs to be switched step by step in different promotional stages).

[0105] Implicit ordering: Default rules based on business common sense. The most common and core rule is that "multiple update requests for the same electronic price tag must be executed strictly in the order they are received." This ensures the correct timing of price changes and avoids the mishap of "the new price being displayed first, then overwritten by the old price."

[0106] Resource dependency order: Some updates may depend on the gateway completing another operation first (such as updating a global template first, and then applying it to multiple price tags).

[0107] Build a local execution sequence:

[0108] The gateway analyzes all tasks in the current queue to be executed, especially multiple pending update requests for the same price tag device.

[0109] It generates a linear, ordered sequence of local update instructions for each physical price tag device according to the above sequence rules.

[0110] For update requests that have no dependencies and target different price tags, the gateway can plan to execute them in parallel or interleaved order to improve overall efficiency.

[0111] The gateway maintains a low-power wireless connectivity status table (such as Bluetooth Mesh or LoRa-based) for all electronic shelf labels within its logical area. Before performing an update, it verifies that the target shelf label is online and communicable.

[0112] For offline devices, the gateway will mark them and record "failure" in the task execution report, while it may attempt to wake them up or leave them for a later retry.

[0113] Ordered instruction issuance:

[0114] The gateway strictly follows the locally executed sequence arranged for each price tag, sending update commands one by one via wireless protocol.

[0115] To improve efficiency, gateways typically employ a "pipeline" or "window" mechanism: instead of waiting for one price tag to be fully updated before sending the next, they immediately send the next instruction after confirming that the previous instruction has been reliably delivered (receiving confirmation from the link layer), while simultaneously waiting for the previous price tag to complete its screen refresh and return confirmation to the application layer. This ensures efficient utilization of the communication channel.

[0116] The gateway requires each electronic shelf label to send a confirmation receipt after receiving the instruction and completing the screen refresh. If no confirmation is received within a specified time, the gateway will resend the instruction according to a policy (such as a maximum of 3 retries).

[0117] For updates to individual price tags, the gateway ensures their integrity. For example, an update may include multiple elements such as price, color, and icon. The gateway ensures that these elements are received and applied to the price tag as a whole, avoiding fragmented information displayed on the screen.

[0118] The gateway has local storage capabilities, so even after a brief loss of connection to the cloud or an unexpected power outage and restart, it can resume unfinished task queues from non-volatile memory and continue execution, ensuring that critical updates are not lost.

[0119] For example, suppose an edge gateway manages 100 price tags in a "beverage section". A task is issued from the cloud: update the price tags of 50 beverages A from "original price 5 yuan" to "promotional price 3 yuan", and then update them back to "original price 5 yuan" after 1 hour.

[0120] Gateway receives two regional batch task packets with a timing relationship (T1: promotion starts; T2: promotion ends).

[0121] Local sorting: The gateway establishes a sorting order for these 50 beverage price tags: execute T1 first, and execute T2 1 hour later.

[0122] Ordered execution: At the start of the promotion, the gateway sends T1 update commands sequentially to these 50 price tags. At the end of the promotion, T2 commands are sent sequentially.

[0123] Ensuring timing: Even if a price tag responds slowly or retryes during a T1 update, the gateway will ensure that the T2 instruction for that price tag is issued only after its T1 update is successful, strictly adhering to the business timing.

[0124] Step 4: Generate an analysis report

[0125] During the update process, the execution status information of each update request is tracked and recorded. Based on the recorded execution status information, the execution results of update requests belonging to the same preset type are categorized and aggregated, and an analysis report containing the categorization and aggregation results is generated. Based on the generated analysis report, the preset logical region division rules and the batch task distribution of the region are dynamically adjusted to their associated edge processing nodes. Specifically:

[0126] I. Update status tracking and recording during execution

[0127] The system tracks the lifecycle of each update request in segments, covering the entire process from its generation in the cloud to its display on the terminal.

[0128] Phase 1: Cloud Processing Status: Records the time and status of request reception, verification, decomposition into regional tasks, and entry into the distribution queue. Key statuses include: "Successfully Received", "Verification Passed", "Task Decomposed", "Queued for Distribution", and "Distributed to Gateway".

[0129] Phase Two: Edge Execution Status: The progress of the task at the edge is tracked through a real-time heartbeat and reporting mechanism with the edge gateway. Key statuses include: "Gateway received", "Command parsing completed", "Local scheduling started", "Command sent to device X", and "Device X returns success / failure / retry".

[0130] Phase 3: Terminal Status Confirmation: Finally, the final screen status of each target electronic price tag is recorded via reporting through the edge gateway or direct feedback from the price tag (if possible). The ideal state is: "Screen refresh completed and verification passed".

[0131] Each state change generates a structured log entry, which includes:

[0132] Timestamp (accurate to milliseconds);

[0133] Request a unique ID and a task ID (used to connect the entire link);

[0134] Entity ID (which gateway or price tag is involved);

[0135] Status codes and descriptions (e.g., STATUS_EDGE_SENT_SUCCESS).

[0136] Key contexts include: number of retries, network latency, packet size, and error codes on failure (ERR_DEVICE_OFFLINE, ERR_BATTERY_LOW).

[0137] These logs are not only written to the database, but also flow into the real-time stream processing pipeline for use on the monitoring dashboard.

[0138] The operations dashboard provides a "flight trajectory" style tracking view. By entering an update request ID, you can see a Gantt chart or timeline that clearly shows the current status and historical status changes of each subtask and each target tag under the request, accurately locating bottlenecks, such as "queuing at the edge gateway".

[0139] II. Categorization and aggregation of execution results based on preset types

[0140] Definition of preset classification dimensions:

[0141] Several aggregation dimensions are predefined, which form the skeleton of the analysis report. These dimensions include:

[0142] Business dimensions: Promotional activity types (spend more, discount, member price), product categories (fresh food, daily necessities, home appliances).

[0143] Technical dimensions: edge gateway model, price tag firmware version, and communication protocol version.

[0144] Spatiotemporal dimensions: store area, execution time (peak / off-peak), task priority.

[0145] Results dimensions: success rate, failure type (network timeout, device unresponsive, data verification error).

[0146] Intelligent classification and aggregation engine:

[0147] When a report needs to be generated, the aggregation engine scans all execution status logs within a specified time period.

[0148] Multi-dimensional cross-aggregation: The engine supports cross-combination analysis of multiple dimensions. For example, it can analyze "the success rate of updates issued through the V2.0 gateway for emergency promotional activities of fresh produce by store A during the evening peak period".

[0149] Key performance indicator calculation:

[0150] Total metrics: total number of update requests, total number of price tags involved, and total data throughput.

[0151] Efficiency metrics: end-to-end average latency (from cloud trigger to terminal refresh), average edge processing time, and 99th percentile latency (reflecting tail experience).

[0152] Quality metrics: overall success rate, success rate by dimension, failure cause distribution chart (e.g., 30% failures due to device offline, 50% due to signal interference).

[0153] Capacity metrics: peak concurrent task processing capacity of each edge gateway and wireless channel utilization.

[0154] III. Generation and Value Extraction of the Analysis Report

[0155] Structured generation of reports:

[0156] The report typically adopts a "general-specific" structure, first presenting the core KPI dashboard and overall conclusions, and then drilling down layer by layer according to each dimension.

[0157] Executive Summary: Summarize the overall effect of this update in one or two sentences (e.g., "Prices were synchronized across all channels during this promotion, with an overall success rate of 99.2%, up 0.5% from last month, but stores in the eastern region experienced higher latency due to network fluctuations").

[0158] Detailed analysis of the chapter:

[0159] Business execution performance analysis: The "Qixi Festival Beauty Promotion" achieved a 100% success rate in updating price tags, ensuring timely delivery and contributing to a 15% month-on-month increase in sales for this category.

[0160] Network and device health analysis: Identify the "Top 5 edge gateways with the highest failure rates" and the "Top 10 gateways with the highest offline rates", and recommend maintenance schedules.

[0161] Performance bottleneck analysis: Identify system bottlenecks using latency distribution graphs. For example: "90% of requests are completed within 1 second, but 5% of requests are delayed for more than 10 seconds, mainly concentrated on price tags using 'legacy protocols'."

[0162] For abnormal patterns, the system will attempt to make intelligent inferences by combining multi-dimensional data. For example, if "the failure rate of fresh food updates increases sharply from 3 to 5 pm on Saturday" and "the number of Wi-Fi terminals surges during this period" are highly overlapping in time, the report will indicate "there may be wireless interference in the 2.4GHz band".

[0163] The evolution of reports towards automation and intelligence:

[0164] Scheduled reports: Automatically generated daily / weekly / monthly and emailed to relevant personnel.

[0165] Anomaly Trigger Report: When the system detects that a key indicator (such as the overall success rate) is below a threshold, it automatically generates an "Anomaly Event Analysis Report" with an alarm.

[0166] Predictive insights: Based on historical data, the report can begin to provide predictive recommendations, such as "Based on historical growth curves, the current edge gateway capacity will reach saturation in 3 months, and expansion planning is recommended."

[0167] IV. Dynamic Self-Optimization Strategy Based on Analysis Reports

[0168] The generated in-depth analysis report triggers dynamic adjustment conditions, including the following analysis points:

[0169] Performance bottlenecks and hotspot identification:

[0170] Uneven regional load: The report shows that update latency and failure rates in certain logical regions (such as the "fresh produce zone") are consistently higher than in other regions, while the edge gateway CPU / memory utilization in these regions remains high for extended periods. This indicates that the existing regional division may be too coarse-grained, with too many devices managed by a single edge node or an overload of tasks.

[0171] Communication Quality Map: The report can generate heatmaps of update failure rates for different physical locations. It may reveal poor signal coverage at the edge gateway in a particular area, causing frequent disconnections or update failures of price tags on remote shelves under its jurisdiction.

[0172] New discoveries regarding business relevance:

[0173] Cross-regional collaboration needs: Analysis reports may reveal through correlation sales data that in promotional activities involving "product A + product B bundled purchases," although the two products are in different physical category areas (such as the beverage section and the snack section), their price tag update needs are completely synchronized and strongly correlated in time. The current regional division (based on physical location) necessitates the collaboration of two gateways, increasing complexity and latency.

[0174] Update pattern clustering: The system analyzes the spatiotemporal patterns of update requests through machine learning and may automatically identify a group of products whose price change frequency and time period are highly consistent (such as fresh produce with multiple price changes per day), but which are scattered across multiple logical regions.

[0175] Changes in infrastructure status: new or replaced edge gateways, physical layout modifications to stores, and large-scale adjustments to shelving.

[0176] Dynamic adjustment of logical region partitioning rules: Based on the above analysis, the system optimizes and adjusts the core "logical region partitioning rule base," and the adjustment strategy types include:

[0177] Region splitting: Splitting a large, overloaded region into two or more smaller regions. For example, splitting a large "daily chemical products region" into a "personal care region" and a "paper products region," and potentially assigning them to two different edge gateways to distribute the load and improve parallelism.

[0178] Region merging: Merging two closely related business areas that are physically adjacent. For example, merging the "Imported Beer Counter" and the "Regular Beverage Area" under the same gateway ensures the atomicity and synchronicity of update instructions when combining promotions.

[0179] Region Restructuring: Based on business models (such as promotional relevance) rather than simply physical location, regions are redefined, and the system can create "virtual logical regions".

[0180] For example, a virtual area called "Weekend Promotional Bundle" contains 20 product price tags from different physical shelves. This virtual area is temporarily active during the promotion period and is managed centrally by an optimal edge gateway intelligently assigned by the system.

[0181] Node reassignment: This does not change the area boundaries, but adjusts the binding relationship between the area and the edge gateway. For example, it reassigns an area managed by a gateway with a weak signal to a gateway located in a central position with a stronger signal.

[0182] The adjustment implementation mechanism:

[0183] Review Mode: The system first generates a "Regional Optimization Proposal," detailing the adjustment plan, expected benefits (e.g., latency reduction of X%, success rate improvement of Y%), and potential risks (e.g., the need for a brief gateway switching interruption). After review by the administrator, execution is confirmed with a single click.

[0184] Fully automatic mode: For fine-tuning of preset thresholds (such as temporarily switching a single price tag that has failed to update three times in a row to a backup gateway), the system can automatically execute and record logs.

[0185] Gray rollout and activation: Major adjustments can adopt a gray rollout strategy, first running it in a store or a region to verify the effect before promoting it to the entire network.

[0186] Intelligent rerouting for regional batch task distribution: As the regional division rules are dynamically adjusted, the task distribution strategy must adapt to the new topology in real time and seamlessly.

[0187] Dynamic mapping table update: After the region division is adjusted, the core "logical region-edge node dynamic mapping table" of the system will be updated immediately. This table is the general outline for the routing of all task distribution.

[0188] Updates must be transactionally consistent to ensure that the old and new mappings do not conflict at the moment of adjustment, preventing tasks from being sent to the wrong gateway or one that is no longer responsible for the area.

[0189] Intelligent adaptation of task distribution:

[0190] New task routing: For newly received update requests, the cloud scheduler will directly query the latest dynamic mapping table and distribute the task to the edge node currently responsible for that area.

[0191] Handling tasks in progress:

[0192] If a task is already being executed in a certain area during the adjustment, the system usually allows it to continue to complete at the original gateway to avoid forced interruption and resulting in inconsistent states.

[0193] A smarter system would assess task status and, for tasks in the queue that haven't started execution, transparently migrate them to a new responsible gateway. This requires that task status can be safely transferred between gateways.

[0194] Connectivity and Session Management: The edge gateway needs to manage its connections to price tags. When an area is reassigned, the original gateway should smoothly release the connections to the relevant price tags, and the new gateway should establish and take over the connections. This process requires protocol support to ensure that price tags do not go offline due to gateway switching.

[0195] Dynamic load balancing based on real-time load:

[0196] In addition to static rule-based distribution, the system can also achieve more advanced dynamic load balancing.

[0197] The edge gateway periodically reports its real-time load (CPU, memory, queue length, wireless channel occupancy).

[0198] When distributing batch tasks to regions, the cloud scheduler not only relies on the mapping table but also refers to real-time load data.

[0199] In special circumstances, such as a gateway being temporarily overloaded, some non-critical tasks that should have been sent to it can be temporarily redirected to a neighboring gateway in the same store that has a lighter load and is within signal coverage, thus enabling cross-regional emergency support.

[0200] The above description is merely a specific embodiment of the invention, but the scope of protection of the invention is not limited thereto. Any variations or substitutions conceived without inventive effort should be included within the scope of protection of the invention. Therefore, the scope of protection of the invention should be determined by the scope defined in the claims.

Claims

1. A distributed batch request processing method with order-guaranteed processing, characterized in that: Includes the following steps: S1. Receive update requests for multiple electronic shelf labels, wherein the update request includes the target electronic shelf label identifier and the content to be updated; S2. Based on the preset logical area division rules, update requests for multiple electronic price tags within the same logical area are merged to generate corresponding area batch tasks, where each area batch task is associated with an edge processing node. S3. Distribute the batch tasks of each region to its associated edge processing nodes, and each edge processing node controls the electronic price tags in its associated logical region to be updated sequentially according to the business logic order between the update requests. S4. During the update process, track and record the execution status information of each update request; S5. Based on the recorded execution status information, classify and aggregate the execution results of update requests belonging to the same preset type, and generate an analysis report containing the classification and aggregation results. Based on the generated analysis report, dynamically adjust the preset logical region division rules and distribute the batch tasks of the region to its associated edge processing nodes.

2. The distributed batch request processing method with order guarantee as described in claim 1, characterized in that: The sources of the update requests include at least one of the following: marketing rule engine, manual batch operation interface, scheduled task scheduler and external system integration interface; the update requests also include: unique request ID, request source priority and effective time strategy.

3. The distributed batch request processing method with order guarantee as described in claim 1, characterized in that: The preset logical region division rules include the following division dimensions: Physical location, including division by shelf group, category zone or store area; Based on business logic, it can be divided into categories based on promotional themes or supplier brands.

4. The distributed batch request processing method with order guarantee as described in claim 3, characterized in that: Based on the logical region division rules, a logical region-edge processing node mapping table is generated and maintained. When merging update requests to generate a batch task for a region, the specific steps include: The mapping table is queried based on the target electronic price tag identifier to determine its logical region and associated edge processing node; Update requests belonging to the same logical region and associated with the same edge processing node are merged to generate a regional batch task package containing the target region identifier, the associated edge node ID, and the list of price tag updates within this region.

5. The distributed batch request processing method with order guarantee as described in claim 4, characterized in that: The business logic sequence includes at least one of the following: The sequence number explicitly defined in the update request; the implicit order determined by the time in which multiple update requests for the same electronic shelf label are received. And the order determined based on the resource dependencies between the updated content.

6. The distributed batch request processing method with order guarantee as described in claim 1, characterized in that: The edge processing node controls the electronic shelf labels to be updated sequentially according to the business logic order. Specifically, the edge processing node parses the received regional batch task packets and constructs a linear local update instruction sequence for each electronic shelf label within its logical region. Based on the local update instruction sequence, the edge processing node sends update instructions to each electronic shelf label in an orderly manner through a pipeline or sliding window mechanism via a wireless communication protocol, and confirms that the instructions have been executed.

7. The distributed batch request processing method with order guarantee as described in claim 6, characterized in that: The execution status information is segmented tracking information, including: the processing status of the update request in the cloud, the execution status at the edge processing node, and the confirmation status at the target electronic price tag terminal; the tracking record includes at least: status change timestamp, request ID, associated entity ID, status code, and error information.

8. The distributed batch request processing method with order guarantee as described in claim 7, characterized in that: The preset type includes at least one of the following dimensions: business dimension, technology dimension, spatiotemporal dimension, and result dimension; The classification and aggregation includes calculating key metrics, which include: update success rate, end-to-end average latency, failure root cause distribution, and load metrics for each edge processing node.

9. The distributed batch request processing method with order guarantee as described in claim 8, characterized in that: The adjustment strategy for dynamically adjusting the preset logical region division rules based on the analysis report includes: Logical regions can be split, merged, or reconstructed based on regional load or communication quality hotspots. Virtual logical regions are dynamically created based on business relevance.

10. The distributed batch request processing method with order guarantee as described in claim 9, characterized in that: The step of dynamically adjusting the distribution of regional batch tasks to their associated edge processing nodes based on the analysis report includes: Based on the updated logical region division rules, the logical region-edge processing node mapping table is updated in real time to guide the distribution of new tasks; Based on the real-time load data reported by each edge processing node, dynamic load balancing and rerouting are performed during task distribution.

Images