Building sale distributed house resource real-time synchronous management method and system based on cloud edge fusion computing

Abstract

The invention discloses a real-time synchronous management method and system for building-selling distributed house resources based on cloud edge fusion computing, and belongs to the technical field of edge computing, and the method specifically comprises the steps: constructing a local data copy for each house resource based on a building-selling total system cloud; based on the local data copy, acquiring a housing resource operation, packaging the housing resource operation into a structured event object, calculating a two-dimensional priority vector and adding the two-dimensional priority vector to the event object, and acquiring a synchronous event with a mark; based on the synchronous event with the mark, executing an edge and cloud double-track mechanism in parallel, and finally generating a scheduling instruction; and issuing a finally generated scheduling instruction to execute data synchronization, and constructing a lightweight analysis mechanism to provide scheduling suggestions. According to the invention, by introducing a bidirectional quantization priority synchronization algorithm and an idle-hotspot edge triggering mechanism, real-time synchronization and cross-node dynamic scheduling of house resource states are realized, and the sales efficiency and customer experience are improved.

Description

Technical Field

[0001] This invention relates to the field of edge computing technology, and in particular to a method and system for real-time synchronous management of distributed housing resources for sales based on cloud-edge fusion computing. Background Technology

[0002] As the real estate industry shifts from extensive growth to refined operation, sales property management, as a core business segment, has seen its technology system continuously iterate and upgrade along with industry development. From single-project operation to cross-regional large-scale deployment, and from traditional offline marketing to online-offline integrated models, the evolution of business models has continuously driven the upgrade of property management systems towards intelligence, networking, and collaboration, providing solid technical support for the efficient operation of the industry. Early sales property management relied on a purely manual record-keeping model. Staff registered property information, sales status, and customer intentions using paper ledgers. Property allocation and information synchronization relied entirely on manual transmission. While this model could meet the most basic management needs, it suffered from problems such as delayed information updates, low query efficiency, and data errors and loss. It was only suitable for small-scale, single-location sales operations and could not meet the needs of the real estate industry's large-scale development. In recent years, the real estate industry has entered a stage of high-quality development, with new business models such as online viewings and intelligent marketing constantly emerging, placing higher demands on the real-time and localized responsiveness of property management.

[0003] However, with the current technology, the housing management model mainly adopts a centralized database. Each sales office interacts with the central server of the headquarters directly through the Internet. Due to the high pressure on the central server, problems such as poor data real-time performance and the reliance on manual experience for cross-regional allocation of housing resources result in insufficient level of intelligence. Summary of the Invention

[0004] The purpose of this invention is to provide a method and system for real-time synchronization management of distributed housing resources in sales offices based on cloud-edge fusion computing. Based on the main system of the sales office, a dual-end data synchronization mechanism is constructed between the cloud and edge nodes. From housing resource data acquisition and priority judgment to idle-hotspot edge triggering mechanism, the real-time synchronization of housing resource status and dynamic scheduling across nodes are realized. This solves the problems of poor data real-time performance caused by high pressure on the central server and insufficient intelligence level caused by reliance on manual experience for cross-regional allocation of housing resources.

[0005] This invention provides the following technical solutions: This invention discloses a method for real-time synchronous management of distributed housing resources for sales based on cloud-edge fusion computing. The method specifically includes: Based on the cloud-based sales system, a local data copy is built for each property and distributed to each edge node; Based on the local data copy, the property listing operation is obtained, and the property listing operation is encapsulated as a structured event object. A two-dimensional priority vector is calculated and appended to the event object to obtain a tagged synchronous event. Based on the tagged synchronization events, a dual-track parallel mechanism of edge and cloud is constructed to process the tagged synchronization events and finally generate scheduling instructions; The scheduling instructions are sent to each edge node to perform data synchronization. At the same time, a lightweight analysis mechanism is built to provide scheduling suggestions and feedback.

[0006] Furthermore, the construction of a local data copy includes the following steps: S1: Obtain the globally unique property identifier, global version number, physical status, belonging edge node ID, base price and synchronization timestamp from the cloud of the sales system to form the core status field set; S2: Based on the cloud and edge nodes of the sales system, local recommendation popularity and estimated transaction cycle are calculated collaboratively to form an edge-derived field set; S3: Merge the core status field set and the edge derived field set to form a local data copy.

[0007] Furthermore, the process of retrieving property listings and encapsulating this process into a structured event object includes the following steps: S1: Capture business requests initiated by staff from the cloud-based sales system, and parse key parameters from the business requests. Key parameters include the target property identifier, the type of operation requested, the new value attached to the operation, and the business context. S2: Edge nodes use the target property identifier in the key parameters to query the set of core status fields in the local data copy; S2: Based on the core status field set in the local data copy, perform pre-business verification and judgment. When the verification passes, the edge node creates a structured event object and encapsulates it. When the verification fails, it returns an error code to the cloud of the sales system.

[0008] Furthermore, calculating the two-dimensional priority vector and appending it to the event object includes the following steps: S1: Deploy the priority calculation engine. Edge nodes call the priority calculation engine to calculate a two-dimensional priority vector for structured event objects, including a comprehensive score of the business priority vector and a time topology priority vector. S2: Append the combined score of the business priority vector and the time topology priority vector to the structured event object to obtain tagged synchronous events, and persist them to the local event log; S3: Using a parallel push method, tagged synchronous events are pushed to the cooperative network.

[0009] Furthermore, constructing a dual-track parallel mechanism for edge and cloud computing includes the following steps: S1: Build a verification and classification mechanism to verify the data integrity of tagged synchronous events, classify the event versions as new or old, put new version events into the immediate processing queue, and put old version events into the historical patch queue. S2: For events targeting the same property in the real-time processing queue, the cloud will group the events into the same synchronization window and set the synchronization window closing conditions. The synchronization window will be closed when the window opening time exceeds the dynamic threshold Q, the number of events N in the window reaches the upper limit, and a pre-synchronization ready signal is received from any relevant edge node. S3: Switch the window status to "closed" to obtain the synchronized window for each property listing that is now closed.

[0010] Furthermore, building a dual-track parallel mechanism for edge and cloud computing also includes the following steps: S1: Based on tagged synchronization events and local data copies, perform real-time pre-synchronization and conflict prediction at the edge. The process includes causal consistency check, pre-synchronization conflict prediction and synchronization response generation. The obtained synchronization response signal is added to the synchronization window of the corresponding property as additional information. S2: Based on the closed version's synchronization window and related edge pre-synchronization responses, perform cloud-based multi-dimensional arbitration and scheduling instruction generation. The process includes conflict graph construction, arbitration calculation, and scheduling instruction generation to obtain the scheduling instructions for each property.

[0011] Furthermore, the scheduling instructions are sent to each edge node to perform data synchronization, which includes the following steps: S1: For each property's scheduling instruction, perform version verification. If the scheduling instruction passes verification, convert it into a global confirmation event. If it fails verification, discard it directly and store the global confirmation event. S2: Encapsulate the global confirmation event and send it to each edge node. The edge node performs pre-verification. After the pre-verification is passed, it sends a "receive confirmation message" to the cloud to obtain the task queue that has passed the pre-verification. S3: Each edge node will execute the instructions in the pre-verified task queue in order of global sequence number, perform conflict resolution detection and processing and data synchronization and refresh, and finally perform version consistency verification to complete data synchronization.

[0012] Furthermore, constructing a lightweight analysis mechanism includes the following steps: S1: Set up a lightweight analysis mechanism to calculate the housing vacancy index and demand index in real time at the edge nodes, and report the data housing vacancy index, demand index and scheduling requests to the cloud of the sales system; S2: The sales system receives the housing availability index, demand index and scheduling requests in the cloud, and calculates the housing matching degree for each available node A and demand node B. S3: Generate a draft suggestion based on the matching degree of the housing listings, and store the draft in the cloud scheduling suggestion pool.

[0013] Furthermore, building a lightweight analysis mechanism also includes the following steps: S1: Extract draft suggestions from the cloud suggestion pool, and calculate the execution priority for each suggestion in the cloud; S2: Based on execution priority, set up automatic triggering and manual review mechanisms to determine the execution and triggering of scheduling instructions, and record the execution effect of each scheduling instruction.

[0014] Furthermore, a real-time synchronous management system for distributed housing resources based on cloud-edge fusion computing specifically includes: The first module is used to build a local data copy for each property and distribute it to each edge node; The second module is used to obtain housing operations based on local data copies, encapsulate housing operations into a structured event object, calculate a two-dimensional priority vector and attach it to the event object to obtain tagged synchronous events; The third module is used to construct a dual-track parallel mechanism between the edge and the cloud based on the tagged synchronization events, process the tagged synchronization events, and finally generate scheduling instructions. The fourth module is used to send scheduling instructions to each edge node, perform data synchronization, and build a lightweight analysis mechanism to provide scheduling suggestions and feedback.

[0015] Compared with the prior art, the present invention has at least one of the following technical effects: 1. This invention distributes complete data copies to each edge node, with each edge node having an independent data copy. This allows the device to continue providing localized services during short-term network interruptions, eliminating absolute dependence on the central database of the sales office's main system. Compared to traditional methods, this invention offers decentralized and distributed technical advantages, solving the problems of single point of failure risk and excessive dependence on the main system inherent in traditional methods.

[0016] 2. This invention captures all business status changes as immutable event objects through an event source architecture, forming a traceable and complete audit log. At the same time, it introduces a two-way quantitative priority algorithm to transform "scheduling instructions" into the highest priority dimension in the event. Compared with traditional methods, it has the technical advantage of priority change detection and solves the problem that the cross-regional allocation of housing resources in traditional methods relies on human experience, resulting in insufficient intelligence.

[0017] 3. This invention constructs a dual-track mechanism of cloud and edge to perform event analysis and pre-response. At the same time, based on the cloud arbitration algorithm of weighted maximum independent set, it achieves global optimal arbitration that maximizes overall business benefits by solving the maximum weighted independent set. Compared with traditional methods, it has the technical advantage of local response and solves the problem of poor data real-time performance caused by the high pressure on the central server in traditional methods.

[0018] 4. This invention utilizes lightweight analyzers deployed at the edge and in the cloud. Edge nodes calculate the "housing availability index" and "demand intensity" in real time, proactively triggering scheduling requests for aggregation and analysis in the cloud to generate scheduling suggestions. Compared to traditional methods, this invention has the technical advantage of intelligent scheduling with conflict resolution, solving the problem that traditional methods rely on human experience for housing scheduling, which leads to the inability to resolve conflicts in scheduling instructions. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments or examples of the present invention, the drawings used in the embodiments or examples will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained according to these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of the process of a real-time synchronous management method for distributed housing resources based on cloud edge fusion computing according to the present invention; Figure 2 This is an architecture diagram of a distributed real-time synchronization management system for housing sales based on cloud-edge fusion computing, as described in this invention. Figure 3 This is a trend chart of the key indicator parameters during the first to sixth weeks of the on-machine testing of this invention. Detailed Implementation

[0021] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0022] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0023] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0024] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0025] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0026] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0027] Specific embodiments of the present invention are as follows: See appendix Figure 1 -Appendix Figure 3 This invention discloses a method for real-time synchronous management of distributed housing resources for sales based on cloud edge fusion computing. The method specifically includes: Based on the cloud-based sales system, a local data copy is built for each property and distributed to each edge node; Based on the local data copy, the property listing operation is obtained, and the property listing operation is encapsulated as a structured event object. A two-dimensional priority vector is calculated and appended to the event object to obtain a tagged synchronous event. Based on the tagged synchronization events, a dual-track parallel mechanism of edge and cloud is constructed to process the tagged synchronization events and finally generate scheduling instructions; The scheduling instructions are sent to each edge node to perform data synchronization. At the same time, a lightweight analysis mechanism is built to provide scheduling suggestions and feedback.

[0028] The above-mentioned method for real-time synchronization management of distributed housing resources based on cloud-edge fusion computing acquires raw data from the cloud-based central sales system, constructs synchronization events from the data using a priority algorithm, and executes the program in a chain-like manner from raw data acquisition → local data copy establishment → data copy distribution → operation acquisition → event encapsulation → priority calculation → dual-track mechanism construction → branch processing → scheduling instruction generation → data synchronization execution → analysis mechanism construction → scheduling suggestion feedback, forming a closed loop.

[0029] In practice, the construction of a local data copy includes the following steps: S1: Obtain the globally unique property identifier, global version number, physical status, belonging edge node ID, base price and synchronization timestamp from the cloud of the sales system to form the core status field set; S2: Based on the cloud and edge nodes of the sales system, local recommendation popularity and estimated transaction cycle are calculated collaboratively to form an edge-derived field set; S3: Merge the core status field set and the edge derived field set to form a local data copy.

[0030] The above collaborative calculation of local recommendation popularity and estimated transaction cycle is performed as follows: Step 1) Calculate the local recommendation popularity, the formula is: ,in α represents the local recommendation popularity score of property i at time t (the higher the value, the more attention the property receives from customers at this sales office, and the stronger its appeal); α, β, and γ represent the adjustable weighting coefficients of page clicks, customer inquiries, and sales duration decay factor, respectively; c i (t) represents the number of page clicks received by property i at this node within a fixed time window in the past; c max (t) represents the maximum number of clicks among all listings in this node within the same time window; ct i (t) represents the number of inquiries for all listings at this node within the same time window; ct max (t) represents the maximum number of inquiries among all listings in this node within the same time window; days i This represents the number of days since property i entered the "available for sale" status. This means converting absolute clicks into a relative proportion (to measure attention). This indicates the relative strength of the deep intention (measure of purchase intention) generated by property i within this node. Represents a nonlinear decay function; Step 2) Calculate the estimated transaction cycle based on Step 1), using the following formula: , where e 周期(i) represents the estimated transaction period for property i (the higher the value, the longer the expected time to sell, the greater the difficulty in selling, and the higher the inventory risk); θ represents the smoothing factor; (1-θ) represents the influence on the final forecast based on the current real-time market signals; e 历史 Indicates the historical average transaction cycle of property listing i; IP 指数 This represents the inventory pressure index of properties of the same type as property i within the current node; This represents the local recommendation popularity score of property i at time t (calculated from step 1 above). This represents the pressure-attractive ratio (reflecting the expected difficulty and time required for property i to break through in the current "market competition pressure" by virtue of its own "popularity"). The fields of this edge-derived field set are independently calculated and maintained by each edge node based on local data, and are used for local intelligent recommendation and business perception. The results are only reported asynchronously to the cloud of the sales system.

[0031] In practice, the process of acquiring property listings and encapsulating this process into a structured event object includes the following steps: S1: Capture business requests initiated by staff from the cloud-based sales system, and parse key parameters from the business requests. Key parameters include the target property identifier, the type of operation requested, the new value attached to the operation, and the business context. S2: Edge nodes use the target property identifier in the key parameters to query the set of core status fields in the local data copy; S2: Based on the core status field set in the local data copy, perform pre-business verification and judgment. When the verification passes, the edge node creates a structured event object and encapsulates it. When the verification fails, it returns an error code to the cloud of the sales system.

[0032] The aforementioned pre-processing verification includes physical compatibility verification and price change scope and permission verification, as detailed below: Step 1) Perform physical compatibility verification. Pre-set a state transition permission matrix M locally. This matrix is ​​a Boolean mapping matrix that defines whether the operation from the "current state" to the "target state" is allowed. Step 2) Based on Step 1), extract the physical status field from the core status field set. The node is based on the physical status as the row and the captured business request operation initiated by the staff from the sales system cloud as the column. Query the status transition permission matrix M. If the query result is "allowed", the verification passes and continues to the next layer of verification. If the query result is "prohibited", the verification fails and the event is terminated. Return the error message "This property has been sold and cannot be locked" to the sales system cloud. This serves as the first line of defense for verification. Step 3) Based on Step 2) when the verification is successful, perform price change range and permission verification. Predefine an allowed role list and extract the "administrator role" identifier from the above business context. Verify whether the role identifier exists in the allowed role list. If it exists, the identifier verification passes; if it does not exist, the verification fails. Step 4) After the permission verification in Step 3) is passed, set a maximum price fluctuation value (determined by staff, set to a negative value), extract the new price from the new value attached to the above operation, calculate the price fluctuation ratio value. When the result is "price increase", set the price fluctuation ratio value ≥ 0 and ≤ the maximum price fluctuation value. When the result is "price decrease", set the maximum price fluctuation value ≤ the price fluctuation ratio value ≤ 0. When the price fluctuation ratio value exceeds the above range, the verification fails. Step 5) Based on Steps 1)-4), if any step fails, the process is terminated immediately, and an error message is returned to the business system (i.e., the sales system cloud) (such as "Operation failed, your role does not have the right to adjust the price" or "Operation failed, the price adjustment exceeds the 10% limit"). This failure result is not passed to subsequent steps.

[0033] In practice, calculating the two-dimensional priority vector and appending it to the event object includes the following steps: S1: Deploy the priority calculation engine. Edge nodes call the priority calculation engine to calculate a two-dimensional priority vector for structured event objects, including a comprehensive score of the business priority vector and a time topology priority vector. S2: Append the combined score of the business priority vector and the time topology priority vector to the structured event object to obtain tagged synchronous events, and persist them to the local event log; S3: Using a parallel push method, tagged synchronous events are pushed to the cooperative network.

[0034] The above describes the calculation of a two-dimensional priority vector for structured event objects, including a comprehensive score for the business priority vector and a time topology priority vector, as detailed below: The steps for implementing the business priority vector comprehensive score are as follows: Step 1) Define the business priority vector as a three-dimensional vector V=[d1,d2,d3], and perform dimensional calculations; Step 2) Based on Step 1), the formula for calculating dimension d1 is: d1 = f1(customer level), where d1 represents dimension 1; f1 is a mapping function (the purpose is to map the customer level from a string to a number); the customer level is a string (such as "diamond", "platinum", "gold", "silver" or "ordinary"). Step 3) Based on Step 1), the formula for calculating dimension d2 is: d2 = f2(payment method), where d2 represents dimension 2; f2 is a mapping function (the purpose is to map the payment method from a string to a number); the payment method is a string (such as "full payment", "commercial loan" or "housing provident fund loan"). Step 4) Based on Step 1), the formula for calculating dimension d3 is: d3 = f3(intelligent dispatch order), where d3 represents dimension 3; f3 is a decision function (the purpose is to determine whether it is an intelligent dispatch order); intelligent dispatch order is a Boolean flag (True when the event originates from a global intelligent dispatch instruction issued by the cloud (with a special mark in the customer level, such as "diamond"), and False when it is a local ordinary sales order). Step 5) Based on steps 1)-4), calculate the comprehensive score of the business priority vector (in order to facilitate fast comparison by the arbitration engine, the final result of this comprehensive score is a scalar score). The formula for calculating the comprehensive score is: S=w1 d1+w2 d2+w3 d3, where S represents the comprehensive score of the business priority vector (a scalar score); w1, w2 and w3 represent the importance of customer value, transaction quality and global optimization in the final decision (i.e. weight index, which are 0.3, 0.2 and 0.5 respectively in this embodiment). The implementation steps for the time topology priority vector are as follows: Step 1) Increment the local logic clock LC value of the edge node by 1 and assign it to the new logic clock LC-new, and use LC-new as the origin logic clock of this event; Step 2) Based on Step 1), update the local clock array GV of the k edge nodes using the new logical clock LC-new. k The updated local clock array GV k Make a complete copy as a vector clock snapshot of the event to obtain the causal context (VC) at the time the event occurred; Step 3) Based on Steps 1) and 2), combine the new logical clock LC-new and the causal context VC into a time topology priority vector, the structure of which is V. time =[LC-new,VC].

[0035] In practice, building a dual-track parallel mechanism between the edge and the cloud includes the following steps: S1: Build a verification and classification mechanism to verify the data integrity of tagged synchronous events, classify the event versions as new or old, put new version events into the immediate processing queue, and put old version events into the historical patch queue. S2: For events targeting the same property in the real-time processing queue, the cloud will group the events into the same synchronization window and set the synchronization window closing conditions. The synchronization window will be closed when the window opening time exceeds the dynamic threshold Q, the number of events N in the window reaches the upper limit, and a pre-synchronization ready signal is received from any relevant edge node. S3: Switch the window status to "closed" to obtain the synchronized window for each property listing that is now closed.

[0036] The above-described data integrity verification for tagged synchronization events is implemented through the following steps: Step 1) Receive the tagged synchronization event, perform basic verification including the integrity of required fields and event signature verification to ensure that the event source is authentic and has not been tampered with, and output the tagged synchronization event that has passed the basic verification. Step 2) Based on Step 1), extract the target property identifier and the global version number of the property before the operation occurred from the tagged synchronization events that have undergone basic verification. Using the target property identifier as the key, query the global status table (cloud data table of the sales system) to obtain the latest global version number of the property. Compare the global version number of the property before the operation with the latest global version number to obtain a triple with the structure [tagged synchronization event, latest global version number, comparison result]. The comparison result can have the following three values: 1. When the global version number of the property before the operation occurs equals the latest global version number, the value is "CURRENT" (i.e., the current version). 2. When the global version number of the property before the operation is less than the current latest global version number, the value is "STALE" (i.e., outdated version). 3. If the global version number of the property before the operation is greater than the latest global version number, the value will be "FUTURE" (this will be considered an exception, and an error will be reported to the sales system cloud). Step 3) Based on Step 2), CURRENT is classified as a new version event and STALE as an old version event, and stored in the above-mentioned categories.

[0037] In practice, building a dual-track parallel mechanism between the edge and the cloud also includes the following steps: S1: Based on tagged synchronization events and local data copies, perform real-time pre-synchronization and conflict prediction at the edge. The process includes causal consistency check, pre-synchronization conflict prediction and synchronization response generation. The obtained synchronization response signal is added to the synchronization window of the corresponding property as additional information. S2: Based on the closed version's synchronization window and related edge pre-synchronization responses, perform cloud-based multi-dimensional arbitration and scheduling instruction generation. The process includes conflict graph construction, arbitration calculation, and scheduling instruction generation to obtain the scheduling instructions for each property.

[0038] The specific implementation steps for the above-mentioned real-time pre-synchronization and conflict prediction at the edge side are as follows: Step 1) Perform causal consistency check. When an edge node receives an event that is not initiated locally, the edge node checks the event’s temporal topology priority vector, extracts a vector clock snapshot from it and compares it with the vector clock recorded locally. If the event is causally earlier than the locally processed event, it is placed in the local queue for sequential processing. If the event is concurrent with the local event, the pre-synchronization conflict prediction is triggered immediately. Step 2) Based on the pre-synchronization conflict prediction triggered in Step 1), for concurrent events, the edge node executes a deterministic prediction function. This prediction function checks whether the physical state in the current core state field set is compatible with the event operation, and compares the comprehensive score of the event's commercial priority vector with the comprehensive score of the commercial priority vector of pending events for the same property that exist locally. Step 3) Based on Step 2) When the return value of the prediction function is "TRUE", the edge node creates a temporary placeholder state locally and sends a pre-synchronization pass signal to the cloud of the sales system. When the return value of the prediction function is "FLASE", a pre-synchronization conflict signal is sent to the cloud of the sales system, and the signal is used as a synchronization response signal.

[0039] The specific implementation steps for the above-mentioned multi-dimensional arbitration and scheduling instruction generation in the cloud are as follows: Step 1) Construct a conflict graph C using events within the window as vertices. When the operation types of two events are mutually exclusive in terms of business logic (such as two LOCKs), add a conflict edge between the two events and assign a weight to each vertex (i.e., event). Step 2) Based on Step 1), perform arbitration calculation, receive a set of event objects from the closed version's synchronization window, create vertices for each event, create conflicting edges according to business rules, and form a C=(V,E) structure, where V represents the set of vertices and E represents the set of edges. Step 3) Based on Step 2), the business priority vector of each event is combined into a score, which is used as the weight of its corresponding vertex; Step 4) Based on Step 3), since the conflict window size is limited and the conflict graph is small, an exact algorithm (backtracking algorithm with pruning) is used to find the globally optimal independent set in a short time, and finally obtain the set of winning events and the set of rejected events. Step 5) Based on Step 4), for each winning event in the winning event set, generate an atomic scheduling instruction and use this atomic scheduling instruction as the scheduling instruction for each property.

[0040] In practice, the scheduling instructions are sent to each edge node, and the data synchronization process includes the following steps: S1: For each property's scheduling instruction, perform version verification. If the scheduling instruction passes verification, convert it into a global confirmation event. If it fails verification, discard it directly and store the global confirmation event. S2: Encapsulate the global confirmation event and send it to each edge node. The edge node performs pre-verification. After the pre-verification is passed, it sends a "receive confirmation message" to the cloud to obtain the task queue that has passed the pre-verification. S3: Each edge node will execute the instructions in the pre-verified task queue in order of global sequence number, perform conflict resolution detection and processing and data synchronization and refresh, and finally perform version consistency verification to complete data synchronization.

[0041] The above process encapsulates the global confirmation event and sends it to each edge node. The edge nodes then perform pre-verification. The specific implementation steps are as follows: Step 1) Encapsulate the global confirmation event into a transmission message and attach a digital signature SKC=Sign(GCE,SK), where Sign represents the digital signature generation function (a specific function used to construct the digital signature); GCE represents the global confirmation event; SK represents the cloud private key; its message structure is M=[GCE,SKC,Seq], where GCE represents the global confirmation event; SKC represents the digital signature (obtained from the above digital signature generation); and Seq represents the globally incrementing sequence number of the message. Step 2) Based on Step 1), a global confirmation event is sent out, and its channels include: 1. Main channel (i.e., TCP long connection, sent individually to each relevant edge node, requiring each edge node to return an acknowledgment); 2. Broadcast channel (i.e., message queue multicast, which publishes global confirmation events to the topic corresponding to the property, and all nodes subscribed to the topic can receive them, for redundancy backup). Step 3) After receiving the global confirmation event in step 2), perform pre-verification, including: 1. Signature Verification: Verify the validity of the digital signature SKC using the cloud public key PK; 2. Version Compatibility Verification: Compare the checksum field in the global confirmation event (denoted as GCE-tv) with the global version number of this property recorded locally (denoted as Q). When GCE-tv = Q, it is determined that the verification passes and execution is prepared; when GCE-tv < Q, it is judged that the instruction has expired, and it is discarded and "ACK_OLD" is replied; when GCE-tv > Q, it indicates a version jump, and the cloud is requested to retransmit the missing instruction. 3. Business Logic Pre-Verification: Evaluate whether the local current state meets the execution prerequisite according to a business rule verification field (denoted as GCE-ec) in the global confirmation event.

[0042] The conflict resolution detection and processing, data synchronization and refresh, and version consistency verification are specifically implemented as follows: Step 1): The edge node starts an atomic transaction for each global confirmation event GCE and performs the following operations: 1. Check again whether the global version number Q of the local property meets GCE-tv = Q. When it does not meet, the atomic transaction is interrupted and the status is changed to "pending retry"; 2. Update the core status field set of the local data copy according to the operation type and operation value in the global confirmation event GCE (a structured value object, derived from the inheritance winning event and confirmed by the cloud arbitration). 3. Write the global confirmation event GCE and the timestamp of the event execution into the local committed instruction log, and set the status flag to "COMMITTED"; 4. Finally, commit the atomic transaction and release the relevant locks; When a version inconsistency is detected in operation 1 of the atomic transaction, it indicates that a higher version of the instruction has been executed locally. At this time, the edge node immediately stops executing the instruction and sends a version conflict report to the cloud of the general sales system. After receiving the version conflict report, when the cloud of the general sales system judges that it is a duplicate instruction caused by network retransmission, it is ignored; when it is judged as an abnormal state, it triggers a data repair process (operation and maintenance intervention); Step 2): After the atomic transaction in step 1) is successfully executed, the edge node updates the local cache and notifies all online clients of this edge node (such as the sales APP) to update the interface in real time through a communication network (such as WebSocket) mechanism to complete data synchronization. Step 3) After the edge node successfully submits the atomic transaction in Step 2), it sends a final execution confirmation message to the sales system cloud. The sales system cloud collects the execution confirmation messages, verifies the consistency of the actual effective new version number reported by all edge nodes, and randomly selects some edge nodes to request them to return more detailed status snapshots for comparison and verification. When one of the following conditions is met, the sales system cloud marks the instruction as globally completed, as follows: 1. Received checksums from all relevant nodes and verified successfully; 2. Once the checksums of most (e.g., more than 2 / 3) of the relevant nodes are received and verified, the remaining nodes will be added in subsequent synchronizations to complete the data synchronization.

[0043] In practice, building a lightweight analysis mechanism includes the following steps: S1: Set up a lightweight analysis mechanism to calculate the housing vacancy index and demand index in real time at the edge nodes, and report the data housing vacancy index, demand index and scheduling requests to the cloud of the sales system; S2: The sales system receives the housing availability index, demand index and scheduling requests in the cloud, and calculates the housing matching degree for each available node A and demand node B. S3: Generate a draft suggestion based on the matching degree of the housing listings, and store the draft in the cloud scheduling suggestion pool.

[0044] The calculation process for the above-mentioned real-time calculation of the housing availability index and demand index at the edge nodes is as follows: Step 1) Calculate the vacancy index, the formula is: , where I 空闲(k) The vacancy index represents the housing availability index of edge node k (ranging from 0 to 1; the closer the value is to 0, the higher the risk of overstocking); i∈Available Housing represents the calculation for all housing units at edge node k that are in the "available for sale" state; w i λ represents the weight of property i (based on the total price of the property); λ represents the decay rate coefficient (controlling the sensitivity of time to the impact on value; the initial value in this example is a typical value of λ=0.05, the larger the value, the faster the decay over time); days i This indicates the number of days that property i has been on the market since it became available for sale; N represents the exponentially decaying function; k This represents the total number of currently available properties within edge node k; Step 2) Calculate the demand index, the formula is: ; Where D 需求(k) (t) represents the real-time demand popularity of node k at time t; a and b represent weight coefficients (which measure the importance of clicks and inquiries, respectively, and are set to a=0.4 and b=0.6 in this embodiment). This represents the total number of clicks on all listings on the edge node over the past hour; avg 平均 This represents the historical average number of clicks; avg1 平均 Indicates the historical average number of inquiries; I 总 This represents the total number of valid inquiries initiated by customers in the past hour. This represents the relative ratio of clicks (a value greater than 1 indicates that the current click volume is higher than the historical average). This represents the relative ratio of consultation volume (a value greater than 1 indicates that current consultations are higher than the historical average).

[0045] The above calculation of the property matching degree for each idle node A and high-demand node B is implemented using a supply and demand matching algorithm.

[0046] In practice, building a lightweight analysis mechanism also includes the following steps: S1: Extract draft suggestions from the cloud suggestion pool, and calculate the execution priority for each suggestion in the cloud; S2: Based on execution priority, set up automatic triggering and manual review mechanisms to determine the execution and triggering of scheduling instructions, and record the execution effect of each scheduling instruction.

[0047] The above extracts draft suggestions from the cloud suggestion pool. The cloud calculates the execution priority for each suggestion, and the priority calculation formula is: E 优先 =Match degree (1 + urgency level coefficient) System load factor, where E 优先 This indicates the priority of the scheduling suggestion; the matching degree (calculated from the matching degree mentioned above); the urgency coefficient (quantified by the housing availability index and demand index, the more acute the supply and demand contradiction, the larger this coefficient); and the system load factor (calculated based on the number of pending events in the cloud and the network load, the busier the system, the smaller this factor, used to suppress the generation of new scheduling).

[0048] In practical implementation, a distributed real-time synchronization management system for sales properties based on cloud-edge fusion computing specifically includes: The first module is used to build a local data copy for each property and distribute it to each edge node; The second module is used to obtain housing operations based on local data copies, encapsulate housing operations into a structured event object, calculate a two-dimensional priority vector and attach it to the event object to obtain tagged synchronous events; The third module is used to construct a dual-track parallel mechanism between the edge and the cloud based on the tagged synchronization events, process the tagged synchronization events, and finally generate scheduling instructions. The fourth module is used to send scheduling instructions to each edge node, perform data synchronization, and build a lightweight analysis mechanism to provide scheduling suggestions and feedback.

[0049] Working Principle: This invention begins by establishing a unified data model (data copy) in the cloud of the sales center's main system and synchronizing it to each edge node, laying the foundation for distributed collaboration. When any sales office performs a property-related business operation, the local edge node immediately captures the operation, performs dual business verification, and encapsulates it into a tagged synchronization event rich in intelligent and causal information by calculating a "business priority vector" and a "time topology priority vector." This event is simultaneously sent to the main sales center's main system and other relevant edge nodes. The main sales center's main system aggregates and organizes concurrent events from different nodes through a "version window" mechanism and acts as the "final arbitrator." Based on the event's business priority, topology priority vector, and pre-synchronization feedback collected from the edge nodes, it performs intelligent conflict resolution and generates a globally consistent scheduling instruction. This instruction is sent to all relevant edge nodes, thereby updating the local property core status and achieving data consistency synchronization.

[0050] Meanwhile, each edge node continuously runs a lightweight analyzer to calculate the local "idle index" and "demand intensity," and proactively sends a scheduling request to the cloud when the conditions are met. The cloud merges the request with global data to generate an "intelligent scheduling order" that optimizes resource allocation. This scheduling order is injected into the above synchronization process as a high-priority event, thus forming a complete, autonomous, and closed-loop cloud-edge converged computing system from real-time data synchronization and intelligent conflict arbitration to proactive resource scheduling.

[0051] The above description is merely a partial embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for real-time synchronous management of distributed housing resources for sales based on cloud-edge fusion computing, characterized in that, The methods specifically include: Based on the cloud-based sales system, a local data copy is built for each property and distributed to each edge node; Based on the local data copy, the property listing operation is obtained, and the property listing operation is encapsulated into a structured event object. A two-dimensional priority vector is calculated and appended to the event object to obtain a tagged synchronous event. Based on the tagged synchronization events, a dual-track parallel mechanism of edge and cloud is constructed to process the tagged synchronization events and finally generate scheduling instructions; The scheduling instructions are sent to each edge node to perform data synchronization. At the same time, a lightweight analysis mechanism is built to provide scheduling suggestions and feedback.

2. The method for real-time synchronous management of distributed housing resources based on cloud edge fusion computing according to claim 1, characterized in that, Building a local data copy involves the following steps: S1: Obtain the globally unique property identifier, global version number, physical status, belonging edge node ID, base price and synchronization timestamp from the cloud of the sales system to form the core status field set; S2: Based on the cloud and edge nodes of the sales system, local recommendation popularity and estimated transaction cycle are calculated collaboratively to form an edge-derived field set; S3: Merge the core status field set and the edge derived field set to form a local data copy.

3. The method for real-time synchronous management of distributed housing resources based on cloud edge fusion computing according to claim 2, characterized in that, The process of retrieving property listings and encapsulating this process into a structured event object includes the following steps: S1: Capture business requests initiated by staff from the cloud-based sales system, and parse key parameters from the business requests. Key parameters include the target property identifier, the type of operation requested, the new value attached to the operation, and the business context. S2: Edge nodes use the target property identifier in the key parameters to query the set of core status fields in the local data copy; S2: Based on the core status field set in the local data copy, perform pre-business verification and judgment. When the verification passes, the edge node creates a structured event object and encapsulates it. When the verification fails, it returns an error code to the cloud of the sales system.

4. The method for real-time synchronous management of distributed housing resources based on cloud edge fusion computing according to claim 3, characterized in that, Calculating the two-dimensional priority vector and appending it to the event object involves the following steps: S1: Deploy the priority calculation engine. Edge nodes call the priority calculation engine to calculate a two-dimensional priority vector for structured event objects, including a comprehensive score of the business priority vector and a time topology priority vector. S2: Append the combined score of the business priority vector and the time topology priority vector to the structured event object to obtain tagged synchronous events, and persist them to the local event log; S3: Using a parallel push method, tagged synchronous events are pushed to the cooperative network.

5. The method for real-time synchronous management of distributed housing resources based on cloud edge fusion computing according to claim 4, characterized in that, Building a dual-track mechanism that operates at both the edge and the cloud includes the following steps: S1: Build a verification and classification mechanism to verify the data integrity of tagged synchronous events, classify the event versions as new or old, put new version events into the immediate processing queue, and put old version events into the historical patch queue. S2: For events targeting the same property in the real-time processing queue, the cloud will group the events into the same synchronization window and set the synchronization window closing conditions. The synchronization window will be closed when the window opening time exceeds the dynamic threshold Q, the number of events N in the window reaches the upper limit, and a pre-synchronization ready signal is received from any relevant edge node. S3: Switch the window status to "closed" to finally obtain the synchronized window of each property that is now closed.

6. The method for real-time synchronous management of distributed housing resources based on cloud edge fusion computing according to claim 5, characterized in that, Building a dual-track mechanism that combines edge and cloud computing also includes the following steps: S1: Based on tagged synchronization events and local data copies, perform real-time pre-synchronization and conflict prediction at the edge. The process includes causal consistency check, pre-synchronization conflict prediction and synchronization response generation. The obtained synchronization response signal is added to the synchronization window of the corresponding property as additional information. S2: Based on the closed version's synchronization window and related edge pre-synchronization responses, perform cloud-based multi-dimensional arbitration and scheduling instruction generation. The process includes conflict graph construction, arbitration calculation, and scheduling instruction generation to obtain the scheduling instructions for each property.

7. The method for real-time synchronous management of distributed housing resources based on cloud edge fusion computing according to claim 6, characterized in that, Sending scheduling instructions to each edge node and performing data synchronization includes the following steps: S1: For each property's scheduling instruction, perform version verification. If the scheduling instruction passes verification, convert it into a global confirmation event. If it fails verification, discard it directly and store the global confirmation event. S2: Encapsulate the global confirmation event and send it to each edge node. The edge node performs pre-verification. After the pre-verification is passed, it sends a "receive confirmation message" to the cloud to obtain the task queue that has passed the pre-verification. S3: Each edge node will execute the instructions in the pre-verified task queue in order of global sequence number, perform conflict resolution detection and processing and data synchronization and refresh, and finally perform version consistency verification to complete data synchronization.

8. The method for real-time synchronous management of distributed housing resources based on cloud edge fusion computing according to claim 7, characterized in that, Building a lightweight analytics mechanism involves the following steps: S1: Set up a lightweight analysis mechanism to calculate the housing vacancy index and demand index in real time at the edge nodes, and report the data housing vacancy index, demand index and scheduling requests to the cloud of the sales system; S2: The sales system receives the housing availability index, demand index and scheduling requests in the cloud, and calculates the housing matching degree for each available node A and high-demand node B. S3: Generate a draft suggestion based on the matching degree of the housing listings, and store the draft in the cloud scheduling suggestion pool.

9. A method for real-time synchronous management of distributed housing resources based on cloud edge fusion computing as described in claim 8, characterized in that, Building a lightweight analytics mechanism also includes the following steps: S1: Extract draft suggestions from the cloud suggestion pool, and calculate the execution priority for each suggestion in the cloud; S2: Based on execution priority, set up automatic triggering and manual review mechanisms to determine the execution and triggering of scheduling instructions, and record the execution effect of each scheduling instruction.

10. A real-time synchronous management system for distributed housing listings based on cloud-edge fusion computing, characterized in that, Specifically, it includes: The first module is used to build a local data copy for each property and distribute it to each edge node; The second module is used to obtain housing operations based on local data copies, encapsulate housing operations into a structured event object, calculate a two-dimensional priority vector and attach it to the event object to obtain tagged synchronous events; The third module is used to construct a dual-track parallel mechanism between the edge and the cloud based on the tagged synchronization events, process the tagged synchronization events, and finally generate scheduling instructions. The fourth module is used to send scheduling instructions to each edge node, perform data synchronization, and build a lightweight analysis mechanism to provide scheduling suggestions and feedback.

Images