Independent station data directional synchronization method, device, equipment, and medium

CN118673080BActive Publication Date: 2026-08-14GUANGZHOU SHANGYUN NETWORK TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-06-05
Publication Date
2026-08-14

AI Technical Summary

Technical Problem

[0003]传统技术中,通常将电商平台中所有在线店铺的数据全部分别同步到插件系统中各个插件的插件数据库,使得每个插件数据库都存有所有在线店铺的数据,这种实现方式,不仅存储成本极其高昂,而且因为存储大部分未选用相应插件的在线店铺的数据,从而导致数据查询和调用的速度极慢,此外,各个独立站对应的在线店铺的数据相互隔离,使得各在线店铺的数据只有自身在线店铺或其授权者可使用,在未经在线店铺选用相应的插件而将这些在线店铺的数据同步到该插件的插件数据库中,会存在安全风险

Benefits of technology

[0015]本申请的技术方案存在多方面优势,包括但不限于如下各方面:

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN118673080B_ABST
    Figure CN118673080B_ABST
Patent Text Reader

Abstract

This application relates to a method, apparatus, and medium for targeted data synchronization of independent websites in the field of e-commerce technology. The method includes: responding to a data source change event of an independent website store; obtaining the change log corresponding to the data source change event and the target store identifier therein; specifying a target worker thread in a worker thread pool based on the target store identifier; distributing the target store identifier and change log to the thread; enabling the target worker thread to determine whether there is a plugin identifier associated with the target store identifier; if so, constructing a change message to be synchronized corresponding to the change log and writing it to a target topic associated with the plugin identifier in a message queue; and enabling the plugin developer thread corresponding to the plugin identifier to consume the change message to be synchronized in the target topic it subscribes to, thereby synchronizing the plugin database associated with the plugin identifier with the data source. This application can efficiently and accurately handle the targeted synchronization needs of large amounts of independent website data, ensuring the accuracy, real-time performance, consistency, and security of the data synchronization.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of e-commerce technology, and in particular to a method for targeted data synchronization of independent websites and the corresponding apparatus, computer equipment, and computer-readable storage medium. Background Technology

[0002] In e-commerce platforms, a plugin system is designed to support various online stores built on independent websites in integrating different functions as needed. Merchants in online stores can choose the plugins they require to enable their corresponding functions. However, all plugins in the system rely on the data of the respective online stores to provide their functions. This necessitates synchronizing the online store's data with the plugin database used by the merchants in that online store.

[0003] In traditional technologies, data from all online stores on an e-commerce platform is typically synchronized separately to the plugin databases of each plugin in a plugin system. This results in each plugin database containing data from all online stores. This approach is not only extremely costly to store, but also results in very slow data retrieval and access speeds because it stores data from most online stores that have not selected the corresponding plugin. Furthermore, the data from online stores on each independent website is isolated from each other, meaning that only the online store itself or its authorized users can access the data. Synchronizing the data of these online stores to the plugin database without the online stores having selected the corresponding plugin poses a security risk.

[0004] Given the shortcomings of traditional approaches, the applicant has long been engaged in research in related fields and has therefore taken a different approach to solve industry problems in the field of e-commerce technology. Summary of the Invention

[0005] The primary objective of this application is to solve at least one of the above-mentioned problems by providing a method for direct data synchronization of independent websites and the corresponding apparatus, computer equipment, and computer program products.

[0006] To achieve the various objectives of this application, the following technical solution is adopted:

[0007] A method for targeted data synchronization of an independent website, provided to serve one of the purposes of this application, includes the following steps:

[0008] Respond to data source change events for independent website stores and obtain the change logs corresponding to the data source change events and the target store identifiers within them;

[0009] Based on the target store identifier, the target worker thread in the worker thread pool is specified, and the target store identifier and the change log are distributed to the target worker thread.

[0010] The target worker thread is activated to determine whether there is a plugin identifier associated with the target store identifier. When the plugin identifier exists, the target worker thread constructs the change message to be synchronized corresponding to the change log and writes it to the target topic associated with the plugin identifier in the message queue.

[0011] Enable the plugin developer thread corresponding to the plugin identifier to consume the pending change messages in the target topic it subscribes to, so that the plugin database associated with the plugin identifier can synchronize data with the data source.

[0012] On the other hand, a data-oriented synchronization device for independent websites, provided to meet one of the purposes of this application, includes an event response module, a thread distribution module, a topic insertion module, and a message consumption module. The event response module is used to respond to data source change events of independent website stores and obtain change logs corresponding to the data source change events, along with the target store identifier within them. The thread distribution module is used to specify a target worker thread in a worker thread pool based on the target store identifier and distribute the target store identifier and the change logs to the target worker thread. The topic insertion module is used to enable the target worker thread to determine whether a plugin identifier associated with the target store identifier exists. When the plugin identifier exists, the target worker thread constructs a change message to be synchronized corresponding to the change logs and writes it to the target topic associated with the plugin identifier in a message queue. The message consumption module is used to enable the plugin developer thread corresponding to the plugin identifier to consume the change message to be synchronized in the target topic it subscribes to, thereby synchronizing the plugin database associated with the plugin identifier with the data source.

[0013] In another aspect, a computer device provided for one of the purposes of this application includes a central processing unit and a memory, the central processing unit being used to invoke and run a computer program stored in the memory to perform the steps of the independent station data-oriented synchronization method described in this application.

[0014] In another aspect, a computer program product provided for another purpose of this application includes a computer program / instructions that, when executed by a processor, implement the steps of the method described in any embodiment of this application.

[0015] The technical solution of this application has many advantages, including but not limited to the following aspects:

[0016] This application first responds to data source change events of independent website stores, obtaining relevant change logs and target store identifiers. Then, based on the target store identifier, it designates the corresponding target worker thread in the worker thread pool, distributing the change logs and target store identifier to it. Next, the target worker thread determines whether a plugin identifier associated with the target store identifier exists. If so, it constructs the corresponding change message to be synchronized for the change log and writes it to the target topic associated with the plugin identifier in the message queue. Furthermore, the plugin developer thread consumes the change message to be synchronized from its subscribed target topic, completing the data synchronization between the plugin database associated with the plugin identifier and the data source. It is evident that the ability to target and synchronize data from independent website stores to the plugin database associated with that independent website store ensures that the plugin database does not store redundant data from unassociated independent website stores, guaranteeing the accuracy, real-time performance, and consistency of data synchronization. Simultaneously, it ensures the data security of each independent website store, ensuring that only the plugin database associated with that independent website store will contain its data. Secondly, by using a worker thread pool combined with a thread distribution mechanism, it can efficiently and accurately handle the targeted synchronization needs of large amounts of independent website data, ensuring high throughput and timely response. Attached Figure Description

[0017] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0018] Figure 1 The network architecture of the e-commerce platform exemplified in this application;

[0019] Figure 2 This is a flowchart illustrating a typical embodiment of the independent website data-oriented synchronization method of this application;

[0020] Figure 3 This is a flowchart illustrating the process of determining the target worker thread in the worker thread pool in an embodiment of this application;

[0021] Figure 4 This is a flowchart illustrating the process of determining the plug-in identifier associated with the target store identifier in an embodiment of this application;

[0022] Figure 5 This is a flowchart illustrating the process of handling plugin change messages related to the target store identifier in an associated topic, as described in an embodiment of this application.

[0023] Figure 6 This is a schematic diagram illustrating the process of constructing a plugin change message and writing it to the associated topic in the message queue, as described in an embodiment of this application.

[0024] Figure 7 This is a schematic diagram illustrating the process of initializing and constructing the store plugin table in an embodiment of this application;

[0025] Figure 8 This is a schematic diagram of the independent station data directional synchronization device of this application;

[0026] Figure 9 This is a schematic diagram of the structure of a computer device used in this application. Detailed Implementation

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

[0028] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this application means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0029] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0030] like Figure 1 In the network architecture shown, the e-commerce platform 82 is deployed on the Internet to provide corresponding services to its users. Similarly, the devices 80 of the merchant users and the devices 81 of the consumer users of the e-commerce platform 82 are also connected to the Internet to use the services provided by the e-commerce platform.

[0031] An exemplary e-commerce platform 82 provides supply and demand matching of products and / or services to the general public through the Internet infrastructure. In e-commerce platform 82, products and / or services are provided as commodity information. For the sake of simplicity, the concepts of commodity and product are used in this application to refer to the products and / or services in e-commerce platform 82. Specifically, these may be physical products, digital products, tickets, service subscriptions, other offline services, etc.

[0032] In reality, various entities can access e-commerce platform 82 as users and utilize its online services to participate in the business activities facilitated by the platform. These entities can be natural persons, legal persons, or social organizations. Corresponding to the two types of entities in business activities—merchants and consumers—e-commerce platform 82 has two corresponding categories of users: merchant users and consumer users. Entities involved in the product distribution chain in business activities, including manufacturers, sellers, retailers, and logistics providers, can all use online services on e-commerce platform 82 as merchant users. Similarly, consumers in business activities, including actual or potential consumers, can use online services on e-commerce platform 82 as consumer users. In actual business activities, the same entity can operate as both a merchant user and a consumer user; this should be interpreted flexibly.

[0033] The infrastructure used to deploy the e-commerce platform 82 mainly includes the backend architecture and frontend devices. The backend architecture runs various online services through a service cluster, including middleware or frontend services for the platform, services for consumers, and services for merchants, to enrich and improve its service functions. The frontend devices mainly cover the terminal devices used by users as clients to access the e-commerce platform 82, including but not limited to various mobile terminals, personal computers, and point-of-sale devices. For example, merchant users can use their terminal device 80 to enter product information for their online stores or use the interfaces opened by the e-commerce platform to generate their product information; consumer users can use their terminal device 81 to access the webpage of the online store implemented by the e-commerce platform 82, trigger the shopping process by clicking the shopping button provided on the webpage, and call various online services provided by the e-commerce platform 82 during the shopping process to achieve the purpose of placing an order.

[0034] In some embodiments, the e-commerce platform 82 may be implemented via a processing facility including a processor and memory, which stores a set of instructions that, when executed, cause the e-commerce platform 82 to perform the e-commerce and support functions as described in this application. The processing facility may be part of a server, client, network infrastructure, mobile computing platform, cloud computing platform, fixed computing platform, or other computing platform, and may provide electronic components, merchant devices, payment gateways, application developers, marketing channels, transportation providers, customer devices, point-of-sale devices, etc., for the e-commerce platform 82.

[0035] E-commerce platform 82 can provide online services such as cloud computing services, Software as a Service (SaaS), Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Desktop as a Service (DaaS), Hosted Software as a Service, Mobile Backend as a Service (MBaaS), and Information Technology Management as a Service (ITMaaS). In some embodiments, the various functional components of e-commerce platform 82 can be implemented to operate on various platforms and operating systems. For example, for an online store, its administrator user enjoys the same or similar functions regardless of whether it is on iOS, Android, HomonyOS, or a web page.

[0036] E-commerce platform 82 enables merchants to create their own independent websites to run their online stores. It provides merchants with corresponding business management engine instances, allowing them to establish, maintain, and operate one or more online stores across these independent websites. The business management engine instance can be used for content management, task automation, and data management for one or more online stores. It can be configured through interfaces or built-in components to support various specific business processes in the online store, supporting business activities. Independent websites are the infrastructure of e-commerce platform 82, which offers cross-border services. Merchants can maintain their online stores relatively independently and centrally based on these independent websites. Independent websites typically have dedicated domain names and storage space, and different independent websites are relatively independent. E-commerce platform 82 can provide standardized or customized technical support for a large number of independent websites, allowing merchants to customize a business management engine instance that suits their needs and use it to maintain one or more online stores.

[0037] Online stores can be configured and maintained in the backend by merchant users logging into their Business Management Engine instance as administrators. Supported by the various online services provided by the e-commerce platform 82's infrastructure, merchant users can configure various functions within their online stores and view various data as administrators. For example, merchant users can manage various aspects of their online stores, such as viewing recent online store activities, updating the online store's product catalog, managing orders, recent visit activity, and total order activity. Merchant users can also view more detailed information about their business and visitors to their online store by obtaining reports or metrics, such as displaying a sales summary of the merchant's overall business, specific sales and engagement data from promotional sales and marketing channels, etc.

[0038] E-commerce platforms 82 can provide communication facilities and associated merchant interfaces for electronic communication and marketing. For example, they can utilize electronic messaging aggregation facilities to collect and analyze communication interactions between merchants, consumers, merchant devices, customer devices, point-of-sale devices, etc., aggregating and analyzing communications to increase the potential for product sales. For instance, a consumer may have product-related questions, which could lead to a dialogue between the consumer and the merchant (or an automated processor-based agent representing the merchant), where the communication facilities handle the interaction and provide the merchant with analysis on how to increase the probability of a sale.

[0039] In some embodiments, applications suitable for installation on terminal devices can be provided to serve the access needs of different users, enabling various users to access the e-commerce platform 82 by running the application on their terminal devices. Examples include the merchant backend module of online stores within the e-commerce platform 82. During the process of conducting business activities through these functions, the e-commerce platform 82 can implement various functions related to business activities as middleware or online services and expose corresponding interfaces. Then, toolkits corresponding to the interface access functions are embedded into the application to achieve functional expansion and task completion. The business management engine can include a series of basic functions and expose these functions to online services and / or applications via APIs. Online services and applications use the corresponding functions by remotely calling the corresponding APIs.

[0040] With the support of various components of the Business Management Engine instance, the e-commerce platform 82 can provide online shopping functionality, enabling merchants to connect with customers in a flexible and transparent manner. Consumers can select items online, create orders, provide delivery addresses in the orders, and confirm payment. Merchants can then review and complete or cancel orders. The review component included with the Business Management Engine instance ensures compliant use of business processes, guaranteeing that orders are suitable for fulfillment before actual execution. Orders may sometimes be fraudulent and require verification (e.g., ID checks). Payment methods that require merchants to wait for receipt of funds can mitigate this risk. Order risks may arise from fraud detection tools submitted by third parties through order risk APIs. Before fulfillment, merchants may need to obtain or wait to receive payment information to mark the order as paid before preparing to deliver the product. Such situations can all be reviewed accordingly. The review process can be implemented by the fulfillment component. Merchants can leverage fulfillment components to review and adjust operations, and trigger related fulfillment services. These include: manual fulfillment services, used when merchants select and pack products into boxes, purchase shipping labels and enter tracking numbers, or simply mark items as fulfilled; custom fulfillment services, which can define email notifications; API fulfillment services, which can trigger third-party applications to create fulfillment records; legacy fulfillment services, which can trigger custom API calls from the Commerce Management Engine to third parties; and gift card fulfillment services, which can generate and activate gift cards. Merchants can use an order printer application to print shipping documents. The fulfillment process can be executed once items are packed and ready for shipment, tracked, delivered, and verified by the consumer.

[0041] E-commerce platform 82 can provide plugin services to all its independent website stores. These plugin services are provided by e-commerce platform 82, which develops and maintains its own plugin system. The plugin system offers multiple plugins with varying functions, including but not limited to: Intelligent Customer Service Plugin: This plugin can act as a customer service representative for independent website stores, automatically responding to pre-set inquiries and / or scripts based on the store's pre-defined Q&A data; Product Image Design Plugin: This plugin allows users to further design product header images, product detail images, etc., using the store's own layer template data or default layer template data to enhance the marketing effect of product images; Logistics Transfer Order Search Plugin: This plugin allows users to retrieve corresponding logistics transfer orders using the product title data of independent website stores; Data Analysis Plugin: This plugin helps independent website stores collect, analyze, and display their operational data. Data includes traffic sources, customer behavior, and sales trends, enabling merchants to make more informed business decisions; Inventory Management Plugin: Used to monitor and manage inventory data for independent websites in real time, issuing alerts when inventory is low to avoid overselling and stockouts; Marketing Campaign Management Plugin: Used to create and track various promotional activities, such as coupons, limited-time discounts, and membership points, to attract consumers and increase sales; Marketing Promotion Plugin: Used to construct marketing promotional tweets based on product data and / or marketing campaign data of independent websites using artificial intelligence technology, and send them to promotional channels such as social media, search engines, and product audiences associated with the independent website store; Store Design Plugin: Used to match corresponding front-end design interface templates based on product data and / or marketing campaign data of independent websites to optimize the visual effect of store design and improve the efficiency of store design.

[0042] The independent website data-oriented synchronization method of this application can be programmed into a computer program product and deployed on a client or server to run. For example, in the exemplary application scenario of this application, it can be deployed on the server of an e-commerce customer service platform. In this way, the method can be executed by human-computer interaction with the process of the computer program product through a graphical user interface by accessing the interface opened after the computer program product is run.

[0043] Please see Figure 2 The independent website data-directed synchronization method of this application, in its typical embodiment, includes the following steps:

[0044] Step S1100: Respond to the data source change event of the independent website store and obtain the change log corresponding to the data source change event and the target store identifier in it;

[0045] An independent website refers to a new type of official website (website) built on a SaaS technology platform. It possesses its own domain name, content, data, and private rights, embodies the responsibility of an operating entity, is supported by social cloud computing capabilities, and can independently and freely connect to third-party software tools, promotional media, and channels. Merchants typically build and operate their own independent website stores, allowing these stores to showcase their products and provide consumers with e-commerce services such as browsing products, adding items to their carts, logistics delivery, order placement, and after-sales service. Because independent website stores on different independent websites are independent entities, all their data is isolated, thus ensuring the privacy of all data within each independent website store.

[0046] The e-commerce platform described in this application provides services to all independent website stores, including plugin services, website building services, customer service, and more. The plugin service is a service provided by the e-commerce platform to merchants of independent website stores through its developed and maintained plugin system. This plugin system offers multiple plugins with varying functions, which merchants can choose to subscribe to or unsubscribe from as needed. Furthermore, when a merchant subscribes to a plugin, that plugin requires data from the merchant's independent website stores stored in its plugin database to provide the corresponding functionality. To ensure that the plugin can successfully implement its designed functions, the plugin database needs to contain all data from the merchant's independent website stores.

[0047] For each independent website store, the e-commerce platform associates all data of that store with its store identifier and stores it in the platform database. This platform database can be any relational database, including MySQL, PostgreSQL, Oracle Database, and SQL Server. The data for each independent website store stored in the platform database constitutes the data source for that store. Each independent website store's identifier is unique, meaning each identifier uniquely points to a single independent website store to distinguish it from others. The identifier can be set using any algorithm such as UUID, auto-incrementing ID, GUID, or Snowflake, and can be flexibly adapted by those skilled in the art. The platform database is stored on local persistent storage to ensure long-term storage and data integrity even in the event of a power outage.

[0048] A third-party data collection tool is used to monitor changes to various data sources in the platform database, collecting corresponding change logs in real time. These changes can be INSERT, DELETE, or UPDATE operations. When the platform database is based on MySQL, the third-party data collection tool can be Canal, which subscribes to MySQL's binlog to capture change logs generated by changes to data sources in the platform database. When the platform database is based on any of MySQL, PostgreSQL, Oracle Database, etc., the third-party data collection tool can be Debezium, which captures change logs generated by changes to data sources in the platform database. Accordingly, when a data source in the platform database changes, the e-commerce platform's server responds to the data source change event of the independent website store, obtains the change logs corresponding to the data source change event captured by the third-party data collection tool, and extracts the store identifier as the target store identifier.

[0049] Step S1200: Distribute the target store identifier and the change log to the target worker thread in the designated worker thread pool according to the target store identifier;

[0050] The worker thread pool contains multiple worker threads, and the specific number of worker threads can be set as needed by those skilled in the art. Each worker thread is pre-marked with a unique thread identifier.

[0051] The server activates the worker thread pool and uses a hash routing algorithm to first obtain the hash value corresponding to the target store identifier. Then, it identifies the single worker thread in the worker thread pool mapped to that hash value and uses it as the target worker thread. The target store identifier and change log are then distributed to the target worker thread. The hash routing algorithm can be any of the following: hash modulo algorithm, consistent hashing algorithm, etc., and can be flexibly adapted by those skilled in the art.

[0052] Step S1300: The target worker thread is activated to determine whether there is a plugin identifier associated with the target store identifier. When the plugin identifier exists, the target worker thread constructs the change message to be synchronized corresponding to the change log and writes it to the target topic associated with the plugin identifier in the message queue.

[0053] In one embodiment, the server enables a target worker thread to traverse all association pairs in the platform database to determine whether there is an association pair containing the target store identifier. When such an association pair exists, the target worker thread obtains the plugin identifier in the association pair and confirms it as a plugin identifier associated with the target store identifier. This means that the merchant of the independent website store pointed to by the target store identifier has subscribed to the plugin pointed to by the plugin identifier. Then, the target worker thread calls the third-party data collection tool to determine the corresponding primary key, change type, changed fields and their assigned values ​​based on the change log. The primary key, change type, changed fields and their assigned values ​​are formatted into a JSON format message to be synchronized. Then, the target worker thread, as the producer of the message queue, takes the topic associated with the plugin identifier in the message queue as the target topic and writes the message to be synchronized into the target topic. The primary key is a globally unique identifier for the changed data in the change log, such as an ID. The change type is a text representation of the change in the changed data in the change log, including one of INSERT, DELETE, and UPDATE. The changed field and its assigned value are the changed field name and the specific value assigned to the field name in the corresponding changed data in the change log.

[0054] The association pairs in the platform database are created and updated by a dedicated maintenance thread on the server. Specifically, when a merchant in an independent website subscribes to a plugin in the first plugin system, the dedicated maintenance thread associates the independent website's store identifier with the plugin's identifier to construct an association pair, thus completing the creation of the pair, which is then written to the platform database. When the merchant subscribes to other plugins in the plugin system, the dedicated maintenance thread adds the plugin's identifier to the association pair and associates it with the store identifier. When the merchant unsubscribes from a plugin, the plugin identifier associated with the unsubscribed plugin is deleted from the association pair. Then, it is determined whether the plugin identifier associated with the store identifier in the association pair is empty. If it is empty, the association pair is deleted from the platform database; otherwise, it is retained in the platform database.

[0055] Each plugin in the plugin system has its own unique plugin identifier, that is, each plugin identifier uniquely points to a single plugin to distinguish it from other plugins. Any algorithm among UU ID, auto-incrementing ID, GU ID, Snowflake, etc. can be used to set each plugin identifier. Those skilled in the art can flexibly adapt and implement it.

[0056] The message queue is built using Kafka, a high-throughput distributed publish-subscribe messaging system. Programs that write messages to Kafka are called Producers. Programs that subscribe to and consume messages in Kafka are called Consumers. Each message in Kafka has a category called a Topic, and each message belongs to one and only one topic.

[0057] Step S1400: Enable the plugin developer thread corresponding to the plugin identifier to consume the message to be synchronized in the target topic it subscribes to, so that the plugin database associated with the plugin identifier can synchronize data with the data source.

[0058] The server enables the plugin developer thread corresponding to the plugin identifier as a consumer of the message queue. This thread subscribes to the target topic associated with the plugin identifier in the message queue and pulls messages from the target topic to be synchronized for consumption. The plugin developer thread uses a JSON deserialization tool to deserialize the messages into corresponding data objects. Then, a parsing algorithm is used to parse these data objects and construct corresponding database operation statements (e.g., SQL statements). Executing these database operation statements in the plugin database associated with the plugin identifier achieves the same changes as the data source, such as performing corresponding insert, delete, or modify operations. This ensures that the data in the plugin database remains synchronized with the data in the data source. The JSON deserialization tool and parsing algorithm can be flexibly implemented by those skilled in the art.

[0059] Each plugin in the plugin system has a corresponding plugin developer thread with its own plugin identifier. Each plugin developer thread subscribes to a topic in the message queue associated with its plugin identifier to consume the update messages to be synchronized within that topic. This ensures that the plugin data associated with the plugin identifier is synchronized with the corresponding data source. Through this process, the plugin system can respond promptly to changes in the data source, guaranteeing the accuracy and effectiveness of plugin functionality. Furthermore, the activation of the plugin developer thread and the consumption of update messages to be synchronized also ensure overall high efficiency and data consistency.

[0060] As can be seen from the typical embodiments of this application, the technical solution of this application has many advantages, including but not limited to the following aspects:

[0061] This application first responds to data source change events of independent website stores, obtaining relevant change logs and target store identifiers. Then, based on the target store identifier, it designates the corresponding target worker thread in the worker thread pool, distributing the change logs and target store identifier to it. Next, the target worker thread determines whether a plugin identifier associated with the target store identifier exists. If so, it constructs the corresponding change message to be synchronized for the change log and writes it to the target topic associated with the plugin identifier in the message queue. Furthermore, the plugin developer thread consumes the change message to be synchronized from its subscribed target topic, completing the data synchronization between the plugin database associated with the plugin identifier and the data source. It is evident that the ability to target and synchronize data from independent website stores to the plugin database associated with that independent website store ensures that the plugin database does not store redundant data from unassociated independent website stores, guaranteeing the accuracy, real-time performance, and consistency of data synchronization. Simultaneously, it ensures the data security of each independent website store, ensuring that only the plugin database associated with that independent website store will contain its data. Secondly, by using a worker thread pool combined with a thread distribution mechanism, it can efficiently and accurately handle the targeted synchronization needs of large amounts of independent website data, ensuring high throughput and timely response.

[0062] Please see Figure 3 In a further embodiment, step S1200, specifying the target worker thread in the worker thread pool according to the target store identifier, includes the following steps:

[0063] Step S1210: Enable multiple worker threads to form a worker thread pool, and identify the thread identifier corresponding to each worker thread;

[0064] The server uses multiple worker threads to form a worker thread pool, allowing multiple worker thread pools to work simultaneously and improving overall execution efficiency. Then, for each worker thread, a thread identifier is assigned, with each thread identifier uniquely pointing to a single worker thread to distinguish it from other worker threads. Any algorithm among UUID, auto-incrementing ID, GUID, Snowflake, etc., can be used to set each thread identifier; those skilled in the art can flexibly adapt and implement it.

[0065] Step S1220: Using a hash routing algorithm, determine the target thread identifier mapped to the target store identifier based on the hash value corresponding to the target store identifier, and take the worker thread marked with the target thread identifier as the target worker thread.

[0066] The hash routing algorithm can be any one of the hash modulo algorithm, consistent hashing algorithm, etc., and can be flexibly adapted by those skilled in the art.

[0067] In one embodiment, the hash routing algorithm is implemented using a consistent hashing algorithm. Specifically, the hash value corresponding to each thread identifier and the hash value corresponding to the target store identifier are calculated using the MD5 or SHA-1 algorithm. These hash values ​​are mapped onto the same hash ring to determine the position of each hash value on the hash ring. Starting from the hash value position of the target store identifier, the search proceeds clockwise until the hash value position of the first worker thread is found. The thread identifier corresponding to the hash value position of the first worker thread is taken as the target thread identifier, and the worker thread identified by the target thread identifier is taken as the target worker thread. The hash ring is a virtual ring that organizes the entire hash space in a clockwise direction, containing 2^32 positions.

[0068] In this embodiment, a worker thread pool consisting of multiple worker threads is created, and each thread is given a unique identifier. A hash routing algorithm is used to quickly and accurately direct data to a specific worker thread based on the hash value of the target store identifier. This ensures that data with the same target store identifier is processed on the same worker thread, achieving uniform routing across different target store identifiers and improving overall efficiency. Furthermore, the high efficiency of the hash algorithm ensures minimal time overhead for routing. In addition, the scalability of this method guarantees flexibility when the system expands; simply adding threads and updating the mapping relationship can adapt to new workloads. Simultaneously, a pre-determined allocation strategy avoids the overhead of thread contention, ensuring stability and reliability.

[0069] Please see Figure 4 In a further embodiment, step S1300, enabling the target worker thread to determine whether there is a plugin identifier associated with the target store identifier, includes the following steps:

[0070] Step S1310: Activate the target worker thread to query whether there is an association pair containing the target store identifier in the preset store plugin table;

[0071] The server enables a target worker thread to traverse all association pairs in a preset store plugin table to determine whether any of these association pairs contain the target store identifier.

[0072] The store plugin table is created and updated by the server. First, the server initializes and builds the store plugin table. Using a master-slave replication protocol similar to a relational database, all relationship pairs in the platform database are copied to the created store plugin table. Furthermore, when a merchant in any independent website store subscribes to or unsubscribes from a plugin, causing a change in the corresponding relationship pairs in the store plugin table, the server updates the relationship pairs accordingly. This ensures that each relationship pair in the store plugin table accurately and in real-time represents the latest plugins subscribed to by the independent website store. The specific implementation of the server-created and updated store plugin table will be further disclosed in subsequent embodiments. This step will not be detailed here. Of course, those skilled in the art can flexibly adapt the implementation based on the disclosure here. For example, after initializing and building the store plugin table, CDC (Change Data Capture) technology can be used to synchronize the changes of all relationship pairs in the platform database with the store plugin table in real time, ensuring data synchronization between all relationship pairs in the store plugin table and all relationship pairs in the platform database.

[0073] Step S1320: When the association pair exists, the target worker thread confirms that there is a plugin identifier in the association pair associated with the target store identifier.

[0074] When the association pair containing the target store identifier exists, the target worker thread obtains the plugin identifier in the association pair and confirms it as the plugin identifier associated with the target store identifier, which means that the merchant of the independent website store pointed to by the target store identifier subscribes to the plugin pointed to by the plugin identifier.

[0075] In this embodiment, the target worker thread queries the store plugin table to determine the association pairs containing the target store identifier, and identifies the plugin identifiers associated with the target store identifier. This allows for quick and accurate identification of plugin identifiers associated with the target store identifier. Furthermore, it eliminates the need to use the association pairs in the platform database, thus ensuring the security and accuracy of the association pairs in the platform database. Therefore, when necessary, such as when the store plugin table maintained on the server is corrupted or lost during a server restart, the master-slave replication protocol can be used to rebuild the store plugin table based on all current association pairs in the platform database, ensuring robustness.

[0076] Please see Figure 5 In a further embodiment, before step S1200, which specifies the target worker thread in the worker thread pool according to the target store identifier and distributes the target store identifier and the change log to the target worker thread, the following steps are included:

[0077] Step S2210: Respond to the message insertion event of the associated topic in the message queue, obtain the plugin change message corresponding to the message insertion event, and use the plugin change message containing the target store identifier as the target plugin change message;

[0078] The associated topic is a dedicated topic in the message queue for storing all plugin change messages.

[0079] When a merchant in any independent website store on the e-commerce platform subscribes to or unsubscribes from a plugin, a corresponding plugin change message is inserted into the associated topic in the message queue, and a message insertion event is triggered in the associated topic as well. The plugin change message includes a store identifier, a plugin identifier, and a plugin change type, where the plugin change type represents either the store subscribing to a plugin or the store unsubscribing from a plugin. In response to the message insertion event, the server retrieves the corresponding plugin change message from the associated topic, using it as the target plugin change message if it contains the target store identifier.

[0080] Step S2220: Distribute the target plugin change message to the target worker thread in the worker thread pool according to the target store identifier;

[0081] The worker thread pool contains multiple worker threads, and the specific number of worker threads can be set as needed by those skilled in the art. Each worker thread is pre-marked with a unique thread identifier.

[0082] The server activates the worker thread pool and uses a hash routing algorithm to first obtain the hash value corresponding to the target store identifier. Then, it identifies the single worker thread in the worker thread pool mapped to that hash value and uses it as the target worker thread, distributing the target plugin change message to that target worker thread. The hash routing algorithm can be any of the following: hash modulo algorithm, consistent hashing algorithm, etc., and can be flexibly adapted by those skilled in the art.

[0083] Step S2230: When the plugin change type in the target plugin change message represents a store subscription plugin, the target worker thread is activated to retrieve all store data associated with the target store identifier from the platform database, construct a pending change message representing the insertion change for each store data, and write each pending change message to the target topic associated with the plugin identifier in the target plugin change message in the message queue.

[0084] The target worker thread retrieves all associated data (i.e., all store data) from the platform database based on the target store identifier. For each retrieved data point, the change type is set to INSERT, the changed fields are configured with their assigned values ​​(the field names and their assigned values), and the primary key is set as a globally unique identifier. A JSON serialization tool is used to format this primary key, change type, changed fields, and their assigned values ​​into a JSON-formatted message to be synchronized. The target worker thread, acting as a message queue producer, uses the topic associated with the plugin identifier in the message queue as the target topic and writes the message to be synchronized into the target topic. The JSON serialization tool can be flexibly implemented by those skilled in the art.

[0085] Step S2240: When the plugin change type in the target plugin change message indicates that the store has unsubscribed from the plugin, the target worker thread is activated to retrieve all store data associated with the target store identifier from the platform database, construct a pending change message for each store data corresponding to the deletion change, and write each pending change message to the target topic associated with the plugin identifier in the target plugin change message in the message queue.

[0086] The target worker thread retrieves all associated data (i.e., all store data) from the platform database based on the target store identifier. For each retrieved data, the change type is set to DELETE, the changed fields and their assigned values ​​are set to the current field name and the specific values ​​assigned to the field name, and the primary key is set to the globally unique identifier of the current data. The JSON serialization tool is used to format the primary key, change type, changed fields and their assigned values ​​into a JSON format message to be synchronized. Then, the target worker thread, acting as a message queue producer, uses the topic associated with the plugin identifier in the message queue as the target topic and writes the message to be synchronized into the target topic.

[0087] In this embodiment, when a message insertion event occurs in the message queue, the corresponding plugin change message is first retrieved, and it is checked whether the message contains a target store identifier. If it does, it is considered a target plugin change message and distributed to the corresponding target worker thread for processing. Depending on the change type in the plugin change message, the target worker thread performs different operations. If the change type indicates that the store has subscribed to the plugin, the target worker thread retrieves all store data associated with the target store identifier from the platform database, constructs a synchronization message for each store data item representing an insertion change, and then writes these messages to the target topic in the message queue associated with the plugin identifier. Conversely, if the change type indicates that the store has unsubscribed from the plugin, the target worker thread constructs a synchronization message representing a deletion change and writes them to the target topic. This ensures that data synchronization between the plugin database and the data source is dynamic and real-time. By responding in real-time to the subscription and unsubscription behaviors of independent website stores, the synchronization messages in the message queue can be updated promptly, thus ensuring the consistency and accuracy of synchronization. Furthermore, it improves the efficiency of synchronization processing because the worker thread pool can process plugin changes for multiple independent website stores in parallel, reducing the total synchronization time. In summary, this embodiment achieves efficient and real-time synchronization of the relationship between independent website stores and plugins through its targeted synchronization mechanism.

[0088] Please see Figure 6 In a further embodiment, before step S2210, which involves inserting a message into the associated topic in the response message queue, the following steps are included:

[0089] Step S2200: Respond to the plugin change event and enable an independent service thread to obtain the store identifier, plugin identifier, and plugin change type corresponding to the plugin change event to construct a plugin change message;

[0090] When a merchant in any independent website store on an e-commerce platform subscribes to or unsubscribes from a plugin, a corresponding plugin change message is inserted into the associated topic in the message queue. Specifically, the server responds to the plugin change event by activating an independent service thread to obtain the store identifier (i.e., the independent website store's identifier at this time), the plugin identifier (i.e., the plugin's identifier at this time), and the plugin change type (i.e., if the merchant is subscribing to a plugin, it indicates that the store is subscribing to the plugin; if the merchant is unsubscribing to a plugin, it indicates that the store is unsubscribing to the plugin). This store identifier, plugin identifier, and plugin change type constitute the plugin change message.

[0091] Step S2201: The independent service thread writes the plugin change message to the associated topic in the message queue.

[0092] Furthermore, an independent service thread acts as a producer of the message queue, writing plugin change messages to the associated topic in the message queue. The associated topic is a dedicated topic in the message queue for storing all plugin change messages.

[0093] In this embodiment, an independent service thread proactively acquires the relevant store identifier, plugin identifier, and change type when a plugin change event occurs. Based on this, it constructs a plugin change message. Subsequently, the thread writes the constructed plugin change message to the associated topic in the message queue, ensuring that subsequent worker threads can perform corresponding data synchronization operations based on these messages. This demonstrates a mechanism for rapidly responding to plugin change events, enabling timely insertion of the corresponding plugin change message into the associated topic in the message queue, guaranteeing the timeliness and accuracy of subsequent data synchronization. With the intervention of the independent service thread, subsequent worker threads can handle plugin subscription and unsubscription events more flexibly, improving the automation and efficiency of the data synchronization process. Furthermore, this method enhances scalability and maintainability, as the independent service thread can be developed and optimized as a separate module without requiring large-scale modifications to the entire synchronization process. This modular design not only ensures stability and reliability but also facilitates future functional expansion.

[0094] In a further embodiment, after step S2230 or step S2240, which involves writing each change message to be synchronized into the target topic associated with the plugin identifier in the target plugin change message in the message queue, the following steps are included:

[0095] Step S3200: The target worker thread is enabled to modify the association between the target store identifier and the plugin identifier in the preset store plugin table according to the plugin change type in the target plugin change message.

[0096] The store plugin table is created and updated by the server. First, the server initializes and builds the store plugin table. Using a master-slave replication protocol similar to a relational database, all relationship pairs in the platform database are copied to the created store plugin table. Then, when a merchant in any independent website store subscribes to or unsubscribes from a plugin, causing a change in the corresponding relationship pair in the store plugin table, the server updates the relationship pairs accordingly. This ensures that each relationship pair in the store plugin table accurately and in real-time represents the latest plugin subscribed to by the independent website store. Specifically, for the update of the store plugin table, taking the example of a merchant in an independent website store pointed to by a target store identifier subscribing to or unsubscribing from a plugin, causing a change in the corresponding relationship pair in the store plugin table, if the target worker thread confirms that the plugin change type in the target plugin change message indicates that the store has subscribed to a plugin, then the plugin identifier associated with the target store identifier is added to the relationship pair containing the target store identifier in the store plugin table. If the target worker thread confirms that the plugin change type in the target plugin change message indicates that the store has unsubscribed from a plugin, then the plugin identifier associated with the target store identifier is deleted from the relationship pair containing the target store identifier in the store plugin table.

[0097] In this embodiment, the target worker thread modifies the association between the target store identifier and the plugin identifier in the preset store plugin table according to the plugin change type in the target plugin change message, thereby updating the store plugin table. This ensures the data consistency and accuracy of the store plugin table.

[0098] Please see Figure 7 In a further embodiment, before step S1100, which responds to the data source change event of the independent website store, the following steps are included:

[0099] Step S1000: Respond to the initialization construction event of the store plugin table, and retrieve all relationship pairs from the platform database. Each relationship pair includes the associated store identifier and plugin identifier.

[0100] In order to avoid using the relationship pairs in the platform database, the server responds to the initialization and construction event of the store plugin table by adopting the master-slave replication protocol of relational database, that is, replicating all relationship pairs in the platform database.

[0101] Step S1010: Create a store plugin table and store all the aforementioned relationship pairs in it.

[0102] Furthermore, a new store plugin table is created, and all the copied association pairs are stored in this store plugin table. In a recommended embodiment, this store plugin table is cached in local memory to ensure high-speed read and write operations.

[0103] This embodiment reveals the process of initializing and constructing the store plugin table, laying the foundation for subsequent independent use of the relationship pairs in the platform database. This ensures the consistency between the relationship pairs in the store plugin table and the relationship pairs in the platform database, and avoids affecting the accuracy of the relationship pairs in the platform database.

[0104] Please see Figure 8 This application provides a data-oriented synchronization device for independent websites, which is a functional embodiment of the data-oriented synchronization method for independent websites. On another note, this device, also for one of the purposes of this application, includes an event response module 1100, a thread distribution module 1200, a topic insertion module 1300, and a message consumption module 1400. The event response module 1100 is used to respond to data source change events of independent website stores and obtain the change logs corresponding to the data source change events and the target store identifier therein. The thread distribution module 1200 is used to specify a worker thread pool based on the target store identifier. The target worker thread distributes the target store identifier and the change log to the target worker thread; the topic insertion module 1300 is used to enable the target worker thread to determine whether there is a plugin identifier associated with the target store identifier. When the plugin identifier exists, the target worker thread constructs the change message to be synchronized corresponding to the change log and writes it to the target topic associated with the plugin identifier in the message queue; the message consumption module 1400 is used to enable the plugin developer thread corresponding to the plugin identifier to consume the change message to be synchronized in the target topic it subscribes to, so that the plugin database associated with the plugin identifier is synchronized with the data source.

[0105] In a further embodiment, the thread distribution module 1200 includes: a thread identification submodule, used to enable multiple worker threads to form a worker thread pool and identify the thread identifier corresponding to each worker thread; and a hash routing submodule, used to use a hash routing algorithm to determine the target thread identifier mapped to the target store identifier based on the hash value corresponding to the target store identifier, and to use the worker thread marked with the target thread identifier as the target worker thread.

[0106] In a further embodiment, the topic insertion module 1300 includes: a first thread enabling submodule, used to enable the target worker thread to query whether there is an association pair containing the target store identifier in a preset store plugin table; and a relationship pair existence confirmation submodule, used to confirm, when the association pair exists, that there is a plugin identifier in the association pair associated with the target store identifier.

[0107] In a further embodiment, before the thread distribution module 1200, there are: a first event response submodule, used to respond to a message insertion event of an associated topic in the message queue, obtain the plugin change message corresponding to the message insertion event, and use the plugin change message containing the target store identifier as the target plugin change message; a first thread distribution submodule, used to specify a target worker thread in the worker thread pool according to the target store identifier, and distribute the target plugin change message to the target worker thread; and a second thread activation submodule, used to enable the target worker thread to retrieve the associated plugin from the platform database when the plugin change type in the target plugin change message represents a store subscription plugin. For all store data associated with the target store identifier, a corresponding synchronization message representing an insertion change is constructed for each store data. Each synchronization message is written to a message queue associated with the target topic of the plugin identifier in the target plugin change message. A third thread enable submodule is used to enable the target worker thread to retrieve all store data associated with the target store identifier from the platform database when the plugin change type in the target plugin change message represents a store unsubscribing from the plugin. This enables the thread to construct a synchronization message representing a deletion change for each store data and write each synchronization message to a message queue associated with the target topic of the plugin identifier in the target plugin change message.

[0108] In a further embodiment, before the first event response submodule, there is a second event response submodule, used to respond to a plugin change event, and to enable an independent service thread to obtain the store identifier, plugin identifier and plugin change type corresponding to the plugin change event to construct a plugin change message; and a first topic insertion submodule, used by the independent service thread to write the plugin change message to an associated topic in the message queue.

[0109] In a further embodiment, after the second thread enables the submodule or the third thread enables the submodule, a fourth thread enables the submodule, which is used to enable the target worker thread to make corresponding changes to the association between the target store identifier and the plugin identifier in a preset store plugin table according to the plugin change type in the target plugin change message.

[0110] In a further embodiment, before the event response module 1100, there are: a third event response submodule, used to respond to the initialization construction event of the store plugin table, obtain all association pairs from the platform database, each association pair including the associated store identifier and plugin identifier; and a table creation submodule, used to create the store plugin table and store all the association pairs therein.

[0111] To address the aforementioned technical problems, embodiments of this application also provide computer equipment. For example... Figure 9 The diagram shows the internal structure of a computer device. The computer device includes a processor, a computer-readable storage medium, a memory, and a network interface connected via a system bus. The computer-readable storage medium stores an operating system, a database, and computer-readable instructions. The database may store control information sequences. When the computer-readable instructions are executed by the processor, they enable the processor to implement an independent station data-oriented synchronization method. The processor of the computer device provides computing and control capabilities to support the operation of the entire computer device. The memory of the computer device may store computer-readable instructions. When these computer-readable instructions are executed by the processor, they enable the processor to execute the independent station data-oriented synchronization method of this application. The network interface of the computer device is used for communication with a terminal. Those skilled in the art will understand that… Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0112] In this embodiment, the processor is used to execute... Figure 8 The system contains the specific functions of each module and its sub-modules, and the memory stores the program code and various data required to execute these modules or sub-modules. The network interface is used for data transmission between user terminals and the server. In this embodiment, the memory stores the program code and data required to execute all modules / sub-modules in the independent station data-oriented synchronization device of this application, and the server can call the server's program code and data to execute the functions of all sub-modules.

[0113] This application also provides a storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the stand-alone station data-oriented synchronization method of any embodiment of this application.

[0114] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The aforementioned storage medium can be a computer-readable storage medium such as a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM).

[0115] In summary, this application can efficiently and accurately handle the targeted synchronization needs of large amounts of independent website data, ensuring the accuracy, real-time performance, consistency, and security of data synchronization for independent websites.

[0116] Those skilled in the art will understand that the steps, measures, and solutions in the various operations, methods, and processes discussed in this application can be alternated, modified, combined, or deleted. Furthermore, other steps, measures, and solutions in the various operations, methods, and processes discussed in this application can also be alternated, modified, rearranged, decomposed, combined, or deleted. Furthermore, steps, measures, and solutions in the prior art that are similar to those in the open-source operations, methods, and processes of this application can also be alternated, modified, rearranged, decomposed, combined, or deleted.

[0117] The above description is only a partial embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for targeted data synchronization of independent stations, characterized in that, Includes the following steps: Respond to data source change events for independent website stores and obtain the change logs corresponding to the data source change events and the target store identifiers within them; Based on the target store identifier, the target worker thread in the worker thread pool is specified, and the target store identifier and the change log are distributed to the target worker thread. This includes: enabling multiple worker threads to form a worker thread pool, and marking the thread identifier corresponding to each worker thread; using a hash routing algorithm to determine the target thread identifier mapped to the target store identifier based on the hash value corresponding to the target store identifier, and using the worker thread marked with the target thread identifier as the target worker thread. The target worker thread is activated to determine whether there is a plugin identifier associated with the target store identifier. When the plugin identifier exists, the target worker thread constructs the change message to be synchronized corresponding to the change log and writes it to the target topic associated with the plugin identifier in the message queue. Enable the plugin developer thread corresponding to the plugin identifier to consume the pending change messages in the target topic it subscribes to, so that the plugin database associated with the plugin identifier can synchronize data with the data source.

2. The independent station data directional synchronization method according to claim 1, characterized in that, The process of enabling the target worker thread to determine whether there is a plugin identifier associated with the target store identifier includes the following steps: The target worker thread is activated to query the preset store plugin table to see if there is an association pair containing the target store identifier; When the association pair exists, the target worker thread confirms the existence of a plugin identifier in the association pair associated with the target store identifier.

3. The independent station data directional synchronization method according to claim 1, characterized in that, Before distributing the target store identifier and the change log to the target worker thread in the worker thread pool based on the target store identifier, the following steps are included: Respond to the message insertion event of the associated topic in the message queue, obtain the plugin change message corresponding to the message insertion event, and use the plugin change message containing the target store identifier as the target plugin change message; The target plugin change message is distributed to the target worker thread in the worker thread pool according to the target store identifier. When the plugin change type in the target plugin change message represents a store subscription plugin, the target worker thread is activated to retrieve all store data associated with the target store identifier from the platform database, construct a pending change message representing the insertion change for each store data, and write each pending change message to the target topic associated with the plugin identifier in the target plugin change message in the message queue. When the plugin change type in the target plugin change message indicates that the store has unsubscribed from the plugin, the target worker thread is activated to retrieve all store data associated with the target store identifier from the platform database, construct a pending change message for each store data corresponding to the deletion change, and write each pending change message to the target topic associated with the plugin identifier in the target plugin change message in the message queue.

4. The independent station data directional synchronization method according to claim 3, characterized in that, Before responding to a message insertion event for the associated topic in the message queue, the following steps are included: In response to a plugin change event, a separate service thread is activated to obtain the store identifier, plugin identifier, and plugin change type corresponding to the plugin change event and construct a plugin change message. The independent service thread writes the plugin change message to the associated topic in the message queue.

5. The independent station data directional synchronization method according to claim 3, characterized in that, After writing each change message to be synchronized into the target topic associated with the plugin identifier in the target plugin change message in the message queue, the process includes: The target worker thread is activated to modify the association between the target store identifier and the plugin identifier in the preset store plugin table according to the plugin change type in the target plugin change message.

6. The independent station data directional synchronization method according to claim 1, characterized in that, Before responding to data source change events for an independent website store, the following steps are included: In response to the initialization and construction event of the store plugin table, retrieve all relationship pairs from the platform database. Each relationship pair includes the associated store identifier and plugin identifier. Create a store plugin table and store all the aforementioned relationship pairs in it.

7. A data-oriented synchronization device for independent stations, characterized in that, include: The event response module is used to respond to data source change events for independent website stores and obtain the change logs corresponding to the data source change events and the target store identifiers therein. The thread distribution module is used to specify the target worker thread in the worker thread pool according to the target store identifier, and distribute the target store identifier and the change log to the target worker thread. The module includes: enabling multiple worker threads to form a worker thread pool, and marking the thread identifier corresponding to each worker thread; using a hash routing algorithm to determine the target thread identifier mapped to the target store identifier according to the hash value corresponding to the target store identifier, and using the worker thread marked with the target thread identifier as the target worker thread. The topic insertion module is used to enable the target worker thread to determine whether there is a plugin identifier associated with the target store identifier. When the plugin identifier exists, the target worker thread constructs the change message to be synchronized corresponding to the change log and writes it to the target topic associated with the plugin identifier in the message queue. The message consumption module is used to enable the plugin developer thread corresponding to the plugin identifier to consume the message to be synchronized in the target topic it subscribes to, so that the plugin database associated with the plugin identifier can synchronize data with the data source.

8. The independent station data directional synchronization device according to claim 7, characterized in that, The thread distribution module includes: a thread identification submodule, used to enable multiple worker threads to form a worker thread pool and identify the thread identifier corresponding to each worker thread; and a hash routing submodule, used to use a hash routing algorithm to determine the target thread identifier mapped to the target store identifier based on the hash value corresponding to the target store identifier, and to use the worker thread marked with the target thread identifier as the target worker thread.

9. A computer device comprising a central processing unit and a memory, characterized in that, The central processing unit is used to invoke and run a computer program stored in the memory to perform the steps of the method as described in any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, It stores, in the form of computer-readable instructions, a computer program implemented according to any one of claims 1 to 6, which, when invoked by a computer, executes the steps included in the corresponding method.

Citation Information

Patent Citations

  • Workflow engine data synchronization method and device, medium and electronic equipment

    CN111339186A

  • Data synchronization method and device, electronic equipment and storage medium

    CN113760920A