An order risk early warning method, device and equipment

Abstract

The application provides an order risk early warning method, device and equipment, and relates to the field of order processing. The method comprises the following steps: acquiring business data of each tenant, wherein the business data comprises order data and logistics data, the order data is order data of each tenant on multiple business platforms, and the logistics data is logistics data of each tenant on multiple logistics platforms; storing the business data of each tenant into a cloud native database corresponding to each tenant; performing early warning calculation on the business data in the cloud native database corresponding to each tenant according to a preset early warning rule to obtain an early warning result of a target order; determining a target tenant according to order data of the target order; and sending the early warning result of the target order to a client of the target tenant. The method not only solves the fragmentation problem of traditional manual cross-platform monitoring, but also ensures that the tenant can master the risks such as order overtime and abnormal track in real time through cloud native database adaptation and accurate early warning pushing.

Description

Technical Field

[0001] This invention relates to the field of order processing technology, and more specifically, to an order risk warning method, apparatus, and device. Background Technology

[0002] With the large-scale development of the e-commerce industry and the increasingly sophisticated platform rules, delivery timeliness has become a key indicator affecting merchant operational compliance and user shopping experience. E-commerce platforms all explicitly require merchants to generate valid logistics tracking within 48 hours of order creation; merchants who fail to ship within this timeframe will face penalties such as fines. In a multi-platform operation model, merchants need to simultaneously manage the delivery timeliness rules of different platforms. The surge in order volume and the dynamic adjustment of rules further increase the difficulty of delivery timeliness management. Developing an efficient and unified order delivery timeliness management solution has become a core requirement for the industry to address merchant operational pain points and ensure stable business operations.

[0003] Currently, merchants primarily rely on a combination of traditional manual operations and simple technical configurations to manage order delivery times across multiple platforms. This typically involves three approaches: First, manual monitoring of each e-commerce platform's backend, logging into multiple business platforms to manually check order status and rule requirements, lacking a unified cross-platform management tool; second, manual setting of fixed delivery time thresholds such as 24-hour and 48-hour periods by business personnel, completing rule settings through static configuration. However, this approach has several significant drawbacks: At the multi-platform management level, because each platform provides independent API interfaces, inconsistent data formats create information silos, requiring merchants to manually switch systems to verify orders. Furthermore, it struggles to adapt to dynamic adjustments in platform rules, leading to rule confusion, omissions, and a high error rate. At the warning mechanism level, the static configuration of the rule engine is based solely on order creation time, failing to integrate real-time logistics data such as courier pickup, resulting in insufficient warning accuracy. At the processing flow level, existing processes rely on manual filtering and sorting, unable to automatically identify order priorities, leading to extremely low processing efficiency and difficulty in handling large-scale order scenarios. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of the prior art by providing an order risk warning method, apparatus, and device, so as to achieve multi-platform order risk warning through end-to-end integration of business data from multiple platforms, tenant-specific storage, real-time warning calculation, precise tenant matching, and warning notification.

[0005] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, embodiments of this application provide an order risk warning method, applied to an order risk warning system, wherein the order risk warning system connects clients of multiple tenants, and the method includes: Obtain business data for each tenant, wherein the business data includes: order data and logistics data, wherein the order data is the order data of each tenant on multiple business platforms, and the logistics data is the logistics data of each tenant on multiple logistics platforms; The business data of each tenant is stored in the cloud-native database corresponding to each tenant. Based on preset early warning rules, early warning calculations are performed on the business data in the cloud-native database corresponding to each tenant to obtain the early warning result for the target order; Based on the order data of the target order, determine the target tenant; The alert results for the target order are sent to the target tenant's client.

[0006] In an optional implementation, obtaining the business data for each tenant includes: A multi-protocol adaptation cluster is constructed using a microservice framework, wherein the multi-protocol adaptation cluster is used to support the application interfaces of multiple business platforms; Based on the multi-protocol adaptive cluster, the order data of each tenant is obtained.

[0007] In an optional implementation, obtaining the order data for each tenant based on the multi-protocol adaptation cluster includes: Based on the multi-protocol adaptation cluster, the system receives transaction order messages from each tenant sent by the multiple business platforms in real time. Incremental data collection is performed on the multiple business platforms according to a preset time interval to obtain incremental collection order messages for each tenant; Based on the transaction order messages and the incrementally collected order messages, the order data for each tenant is determined.

[0008] In an optional implementation, obtaining the business data for each tenant includes: Utilize distributed message middleware to construct logistics message pipelines; Based on the logistics message pipeline, the logistics data of each tenant is obtained.

[0009] In an optional implementation, obtaining the logistics data for each tenant based on the logistics message pipeline includes: Based on the logistics message pipeline, the initial logistics data of each tenant is obtained; The initial logistics data is partitioned according to a preset trajectory type to obtain partitioned logistics data. According to the preset trajectory data format, the logistics data after partitioning is updated to obtain the logistics data for each tenant.

[0010] In an optional implementation, storing the business data of each tenant in the cloud-native database corresponding to each tenant includes: Based on the data characteristics of the business data, the storage mode of the business data is determined, including: row storage mode, column storage mode, and hybrid storage mode; According to the storage mode, the business data is stored in the cloud-native database corresponding to each tenant.

[0011] In an optional implementation, the step of performing early warning calculations on the business data in the cloud-native database corresponding to each tenant according to preset early warning rules to obtain the early warning result for the target order includes: Based on the preset early warning rules and columnar computing nodes, query the query fields corresponding to the business data stored in columnar storage mode; Determine whether the queried field meets the warning conditions; If the target query field meets the warning conditions, the order corresponding to the target query field is determined to be the target order, and a warning result for the target order is generated.

[0012] In an optional implementation, the method further includes: Obtain the access request from the newly added tenant; Based on the access request of the new tenant, an idle database is determined as the database corresponding to the new tenant.

[0013] Secondly, embodiments of this application also provide an order risk warning device, applied to an order risk warning system, wherein the order risk warning system connects clients of multiple tenants, and the device includes: The acquisition module is used to acquire business data for each tenant, wherein the business data includes order data and logistics data, the order data being the order data of each tenant on multiple business platforms, and the logistics data being the logistics data of each tenant on multiple logistics platforms; The storage module is used to store the business data of each tenant into the cloud-native database corresponding to each tenant; The calculation module is used to perform early warning calculations on the business data in the cloud-native database corresponding to each tenant according to preset early warning rules, and obtain the early warning result of the target order; The determination module is used to determine the target tenant based on the order data of the target order; The sending module is used to send the warning results of the target order to the client of the target tenant.

[0014] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores program instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the program instructions to perform the steps of the order risk warning method as described in any of the first aspects.

[0015] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the order risk warning method as described in any of the first aspects.

[0016] The beneficial effects of this application are: This application provides an order risk warning method, apparatus, and device. The method includes: acquiring business data for each tenant, wherein the business data includes order data and logistics data. The order data is order data for each tenant across multiple business platforms, and the logistics data is logistics data for each tenant across multiple logistics platforms. The business data for each tenant is stored in a cloud-native database corresponding to each tenant. According to preset warning rules, warning calculations are performed on the business data in the cloud-native database corresponding to each tenant to obtain the warning result for the target order. Based on the order data of the target order, the target tenant is determined, and the warning result for the target order is sent to the client of the target tenant. This method integrates business data from multiple platforms across the entire chain, provides tenant-specific storage, performs real-time warning calculations, accurately matches tenants, and sends warning notifications. This achieves multi-platform order risk warning, solving the fragmentation and efficiency bottleneck of traditional manual cross-platform monitoring. Furthermore, through cloud-native database adaptation and accurate warning push, it ensures that tenants can monitor risks such as order timeouts and abnormal tracking in real time, significantly reducing order violation rates and manual processing costs, and improving risk management capabilities and response efficiency in multi-platform operations. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 One of the flowcharts for an order risk warning method provided in this application embodiment; Figure 2 A second schematic flowchart illustrating an order risk warning method provided in this application embodiment; Figure 3The third flowchart illustrates an order risk warning method provided in this application embodiment; Figure 4 The fourth flowchart illustrates an order risk warning method provided in this application embodiment; Figure 5 The fifth flowchart illustrates an order risk warning method provided in this application embodiment; Figure 6 A flowchart illustrating an order risk warning method provided in this application embodiment is shown in Figure 6. Figure 7 The seventh flowchart illustrating an order risk warning method provided in this application embodiment; Figure 8 This is the eighth flowchart illustrating an order risk warning method provided in this application embodiment; Figure 9 A schematic diagram of the functional modules of an order risk warning device provided in this application embodiment; Figure 10 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments.

[0020] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0021] In the description of this application, it should be noted that if the terms "upper", "lower", etc. appear to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship that the product of this application is usually placed in, it is only for the convenience of describing this application and simplifying the description, and does not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application.

[0022] Furthermore, the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Additionally, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0023] It should be noted that, where there is no conflict, the features in the embodiments of this application can be combined with each other.

[0024] To enable tenants to monitor risks such as order timeouts and abnormal tracking in real time, this application provides an order risk warning method. By integrating business data from multiple platforms across the entire chain, tenant-specific storage, real-time warning calculation, precise tenant matching, and warning notification, multi-platform order risk warning is achieved. This not only solves the fragmentation problem and efficiency bottleneck of traditional manual cross-platform monitoring, but also ensures that tenants can monitor risks such as order timeouts and abnormal tracking in real time through cloud-native database adaptation and precise warning push.

[0025] The order risk warning method provided in this application embodiment will be explained in detail below with reference to the accompanying drawings and specific examples. The order risk warning method provided in this application embodiment is applied to an order risk warning system, which connects to the clients of multiple tenants. Figure 1 This is one of the flowcharts illustrating an order risk warning method provided in an embodiment of this application; such as Figure 1 As shown, the method includes: S101. Obtain business data for each tenant.

[0026] The business data includes order data and logistics data. Order data is the order data of each tenant across multiple business platforms, and logistics data is the logistics data of each tenant across multiple logistics platforms.

[0027] In this embodiment, the tenant is a company using the order risk warning system, which has at least one merchant. Each merchant has corresponding order data on at least one business platform and corresponding logistics data on at least one logistics platform. The order data and logistics data are related, which can be understood as each order number being related to a tracking number. Therefore, each order on the business platform has corresponding logistics data on the logistics platform, i.e., the current order is in the pending shipment status, pickup status, transportation status, etc.

[0028] If the business platform is an e-commerce platform, then multiple business platforms generate order data for each tenant based on the purchase records of buyers in each merchant's store within each tenant. The logistics platform can consist of multiple courier companies, and the logistics data is determined across multiple logistics platforms based on the order data.

[0029] S102. Store each tenant's business data in the cloud-native database corresponding to each tenant.

[0030] Specifically, the order risk warning system identifies each tenant ID and determines the corresponding cloud-native database for each tenant. It then routes each tenant's business data to its dedicated cloud-native database (PolarDB) via the DataSource's getConnection interface, which is the database connection interface. PolarDB offers the low-cost advantages of a distributed design while maintaining the ease of use of a centralized architecture. This database achieves elastic scalability through a separate architecture for compute and storage nodes, supporting single-database capacity expansion to hundreds of TB levels, based on a high-speed RDMA network for remote data management and a distributed compute node cluster.

[0031] For example, tenant A, as a critical tenant, has its business data routed to a dedicated PolarDB database instance after its tenant ID is identified by the DataSourceRouter routing component. Tenant B, as a regular tenant, has its business data routed to a separate data partition within a shared PolarDB database. Specifically, tenant A's active orders from the past three months (approximately 50,000 records) are stored in a PolarDB InnoDB row-based storage engine table, supporting high-frequency updates and queries; historical orders from 2023 and earlier (approximately 200,000 records) are automatically archived to a high-compression engine table, reducing storage space usage.

[0032] S103. Based on the preset early warning rules, perform early warning calculations on the business data in the cloud-native database corresponding to each tenant to obtain the early warning results for the target order.

[0033] Specifically, the preset early warning rules include: a timeout warning is triggered if an order from business platform A is not picked up within 48 hours of creation, or an emergency warning is triggered if an order from business platform B is not shipped within 24 hours. The order risk warning system uses a hybrid computing engine to perform real-time queries on fields such as order creation time and logistics pickup status stored in columnar mode in tenant A's PolarDB database. It detects three orders from business platform A that have been uncollected for 45 hours since creation, and one order from business platform B that has not been shipped within 22 hours of creation, generating warnings for impending timeout and emergency timeout respectively. Simultaneously, it identifies two logistics tracks that have not been updated for 12 consecutive hours, generating an abnormal track warning.

[0034] S104. Determine the target tenant based on the order data of the target order.

[0035] Specifically, the order risk warning system extracts tenant identifiers from the order data corresponding to the three orders that are about to expire and matches them to tenant A; it also extracts tenant identifiers from the one urgent expired order and identifies it as tenant A; and it extracts tenant identifiers from the two abnormal trajectory orders and matches them to tenant B. Finally, it identifies the target tenants as tenant A and tenant B.

[0036] S105. Send the alert results of the target order to the target tenant's client.

[0037] Specifically, the order risk warning system sends pop-up warnings to tenant A's client through a multi-channel notification mechanism. At the same time, it pushes information such as the order numbers, remaining timeout time, and corresponding platforms of three orders that are about to expire and one that is urgently expired to tenant A's client through a preset notification robot. It also sends system pop-up warnings to tenant B's client and pushes information such as the logistics tracking numbers, current trajectory nodes, and abnormal duration of two orders with abnormal tracking through a preset notification robot, ensuring that each tenant receives the warnings in a timely manner.

[0038] In summary, this application provides an order risk warning method. The method includes: acquiring business data for each tenant, where the business data includes order data and logistics data. Order data represents order data for each tenant across multiple business platforms, and logistics data represents logistics data for each tenant across multiple logistics platforms. The business data for each tenant is stored in a cloud-native database corresponding to each tenant. Based on preset warning rules, warning calculations are performed on the business data in the cloud-native database corresponding to each tenant to obtain the warning result for the target order. Based on the order data of the target order, the target tenant is determined, and the warning result for the target order is sent to the target tenant's client. This method, by integrating business data from multiple platforms across the entire chain, providing tenant-specific storage, enabling real-time warning calculations, precise tenant matching, and warning notifications, achieves multi-platform order risk warning. It solves the fragmentation and efficiency bottlenecks of traditional manual cross-platform monitoring. Furthermore, through cloud-native database adaptation and precise warning push, it ensures that tenants can monitor risks such as order timeouts and abnormal tracking in real time, significantly reducing order violation rates and manual processing costs, and improving risk management capabilities and response efficiency for multi-platform operations.

[0039] This application also provides another possible implementation of the order risk warning method. Figure 2 This is a second flowchart illustrating an order risk warning method provided in an embodiment of this application; as shown below. Figure 2 As shown, the business data for each tenant is obtained, including: S201. Use a microservice framework to build a multi-protocol adaptation cluster.

[0040] Among them, the multi-protocol adaptation cluster is used to support the application interfaces of multiple business platforms.

[0041] S202: Based on a multi-protocol adaptive cluster, obtain order data for each tenant.

[0042] In this embodiment, the microservice framework can be the Dubbo microservice framework. Dubbo is a high-performance, lightweight open-source Java RPC framework. An adaptation cluster supporting multiple data protocols such as JSON and XML is built using the Dubbo microservice framework. This cluster contains 10 adaptation nodes, each dynamically registered and discovered through the Zookeeper registry. Adaptation plugins are developed for the REST protocol of the first e-commerce platform API, the SOAP protocol of the second e-commerce platform API, and the JSON-RPC protocol of the third e-commerce platform API, respectively. This achieves compatibility with heterogeneous APIs from multiple e-commerce platforms, ensuring that order data from different platforms can be recognized and received by the system. Then, based on the multi-protocol adaptation cluster, order data for each tenant is obtained.

[0043] For example, tenant C is a comprehensive retailer covering 10 e-commerce platforms. Its order data from these platforms is pushed in different formats such as XML and JSON. The system's multi-protocol adaptation cluster uses platform-specific adaptation plugins to parse the XML and JSON order data from each platform, extracting core fields such as order number, product information, shipping address, and creation time, and finally integrating them into a unified format order data for tenant C.

[0044] The method provided in this embodiment uses a multi-protocol adaptation cluster built on a microservice framework to overcome the compatibility limitations of heterogeneous APIs (such as JSON / XML format, REST / SOAP protocol) of different e-commerce platforms, enabling unified access to order data from multiple e-commerce platforms without requiring tenants to develop separate interface modules for each platform. At the same time, the clustered architecture ensures the stability of data access and high concurrency processing capabilities, solving the problems of low efficiency and easy interruption of traditional single interface adaptation, and providing reliable technical support for the comprehensive and real-time acquisition of order data from multiple platforms.

[0045] This application also provides another possible implementation of the order risk warning method. Figure 3 This is the third flowchart illustrating an order risk warning method provided in this application embodiment; as shown below. Figure 3 As shown, based on a multi-protocol adaptive cluster, order data for each tenant is obtained, including: S301, based on a multi-protocol adaptive cluster, receives transaction order messages from multiple business platforms for each tenant in real time.

[0046] In this embodiment, the business platform A adaptation node in the multi-protocol adaptation cluster listens to the message push interface of business platform A in real time. When tenant A creates an order on business platform A, business platform A immediately sends an XML-formatted transaction order message containing the order number, buyer information, payment status, etc. The adaptation node receives the message and parses it into an intermediate format that the system can recognize. At the same time, the business platform B adaptation node receives the JSON-formatted transaction order message of the order created by tenant A on business platform B, completing real-time reception and initial format conversion.

[0047] S302. Based on a preset time interval, incremental data collection is performed on multiple business platforms to obtain incremental collection order messages for each tenant.

[0048] The preset time interval can be set to 30 minutes, 1 hour, etc., without any restrictions. The order risk warning system triggers incremental data collection tasks periodically. For business platform A, by calling its incremental order query API and passing in the deadline timestamp of the last collection, it obtains the data of 3 orders from tenants A and C that were not pushed via message within that time period. For business platform B, through the incremental synchronization interface provided by the platform, it collects 2 missing order messages, forming an incremental collection order message set.

[0049] S303. Determine the order data for each tenant based on transaction order messages and incrementally collected order messages.

[0050] The real-time transaction order messages and incrementally collected order messages of tenant A are deduplicated by using the unique order number to exclude duplicate data, thus obtaining valid order data. Similarly, the real-time transaction order messages and incrementally collected order messages of tenant C are merged, and missing fields such as product specifications and discount information are added to form complete order data for tenant C, ensuring that the order data is complete and without omissions or duplications.

[0051] The method provided in this embodiment employs a dual-channel mechanism of real-time message reception and timed incremental data collection. This mechanism utilizes real-time messages to achieve second-level synchronization of order data, avoiding potential omissions due to message delays. Incremental data collection serves as a backup, supplementing order data that was not pushed in real-time or was lost, thereby reducing the rate of missed orders. Simultaneously, by integrating and deduplicating the two types of messages, the integrity and accuracy of tenant order data are ensured, resolving the issues of data loss and inconsistency in the traditional single-message reception model. This provides a high-quality data foundation for subsequent early warning calculations.

[0052] This application also provides another possible implementation of the order risk warning method. Figure 4 This is the fourth flowchart illustrating an order risk warning method provided in this application embodiment; as shown below. Figure 4As shown, the business data for each tenant is obtained, including: S401. Use distributed message middleware to build logistics message pipelines.

[0053] S402. Obtain logistics data for each tenant based on the logistics message pipeline.

[0054] In this embodiment, the distributed message middleware RocketMQ can be selected, primarily for handling high-concurrency, high-throughput message transmission scenarios. RocketMQ is used to construct a high-concurrency logistics message pipeline. The pipeline contains multiple message topics, corresponding to pickup status updates, transportation trajectory changes, and delivery status confirmations, respectively. Each message topic is configured with multiple message queues to improve concurrent processing capabilities. Simultaneously, standardized message access interfaces are provided for partners such as express delivery companies, clearly defining message formats, push frequencies, and other specifications to ensure stable access to logistics data.

[0055] For example, tenant B's 10 orders are delivered through logistics platform A. Logistics platform A's system pushes logistics trajectory data, including order pickup time, transit points, and delivery personnel information, to the "Transportation Track Change" topic in the logistics message pipeline according to an agreed-upon format. Logistics platform B pushes the logistics data for tenant A's 5 orders to the "Pickup Status Update" topic. Real-time acquisition of logistics data from different tenants is achieved by concurrently pulling messages from various topics through message consumer groups.

[0056] The method provided in this embodiment uses a logistics message pipeline built with a distributed message middleware, which decouples multiple logistics platforms, eliminating the need for hard-coding between the system and each logistics platform individually, thus reducing the complexity of the connection. At the same time, the high concurrency carrying capacity of the distributed message middleware can cope with the traffic fluctuations of logistics trajectory push, avoid system failures due to traffic surges, ensure the stability and real-time performance of logistics data collection, and provide data support for early warning of logistics-related risks.

[0057] This application also provides another possible implementation of the order risk warning method. Figure 5 This is the fifth flowchart illustrating an order risk warning method provided in this application embodiment; as shown below. Figure 5 As shown, the logistics data for each tenant is obtained, including: S501: Based on the logistics message pipeline, obtain the initial logistics data for each tenant.

[0058] In this embodiment, the consumer group of the logistics message pipeline listens to each message topic. When tenant A's three orders are picked up, the initial logistics data pushed by logistics platform A includes: pickup time: 2024-05-20 14:30:22, pickup point: point A, logistics status code: LS001, etc.; tenant B's two orders update their trajectory during transportation, and the initial logistics data includes: transit time: 2024-05-20 16:45:10, transit point: point B, status description: dispatched, etc., non-standardized fields. The system completely acquires and temporarily stores this raw data.

[0059] S502. Divide the initial logistics data into partitions according to the preset trajectory type to obtain partitioned logistics data.

[0060] The preset trajectory types include four categories: pickup, transit, delivery, and receipt. A tag filtering mechanism is used to add corresponding tags to the initial logistics data of different types. Tenant A's three order pickup data are tagged with " / tag / Collect" and partitioned into the pickup data queue; Tenant B's two order transit data are tagged with " / tag / Transfer" and partitioned into the transit data queue; and the initial data of one other delivery order is tagged with " / tag / Delivery" and partitioned into the delivery queue, achieving precise partitioning by trajectory type.

[0061] S503. According to the preset trajectory data format, update the format of the partitioned logistics data to obtain the logistics data of each tenant.

[0062] The preset trajectory data format uniformly specifies the field names as trajectory type, occurrence time, branch name, status code, and associated order number. For tenant A's pickup-type partition data, the format is converted by changing the pickup time to the occurrence time, the pickup branch to the branch name, and the logistics status code LS001 to status code 01 (pickup). For tenant B's transit-type data, the format is converted by changing the transit time to the occurrence time, the transit branch to the branch name, and the status description "sent out" to status code 02 (transit). This results in a unified format for logistics data.

[0063] The method provided in this embodiment first classifies the initial logistics data according to trajectory types such as pickup and transit through a trajectory type partitioning and format unification processing flow. It then uses concurrent retrieval by multiple consumer groups to improve throughput and solve the efficiency bottleneck caused by traditional disordered processing. Next, it unifies the non-standardized data of various logistics platforms through preset format unification, eliminates the parsing chaos caused by data format differences, realizes standardized storage and retrieval of logistics data, provides a consistent data dimension for the unified execution of subsequent early warning rules, and improves the accuracy and efficiency of early warning calculation.

[0064] This application also provides another possible implementation of the order risk warning method. Figure 6 This is a flowchart illustrating an order risk warning method provided in an embodiment of this application; as shown in Figure 6. Figure 6 As shown, each tenant's business data is stored in its corresponding cloud-native database, including: S601. Determine the storage mode of business data based on its characteristics.

[0065] The storage modes include: row storage mode, column storage mode, and hybrid storage mode.

[0066] S602. Based on the storage mode, store business data in the cloud-native database corresponding to each tenant.

[0067] In this embodiment, row-based storage mode organizes and stores data by row, with all fields of each row (such as order number, creation time, payment status, shipping address, etc.) stored contiguously in a single physical block on the disk, similar to the storage logic of an Excel spreadsheet. Column-based storage mode organizes and stores data by column, with all values ​​of the same field (such as the creation time of all orders, the logistics status of all orders) stored contiguously in a single physical block on the disk, essentially splitting an Excel spreadsheet "by column" and storing each column separately. Hybrid storage mode combines the advantages of row-based and column-based storage modes, splitting data into hot / cold data and transaction / analysis fields, and storing them using both row-based and column-based storage respectively, achieving collaborative data reading and writing through the database's internal association mechanism.

[0068] For operational data such as order updates and payment status changes that require ensuring transaction consistency, characterized by high-frequency writes and low-latency updates, a row-based storage model is selected. For analytical query data such as order timeout predictions and logistics trajectory statistics, characterized by high-frequency reads and multi-field join queries, a column-based storage model is selected. For tenants' core order data (which needs to support both updates and complex queries), characterized by balanced read and write operations and high real-time requirements, a hybrid storage model of row-based and column-based storage is selected.

[0069] For example, operational data such as order payment status updates and real-time logistics tracking changes for tenant A are stored in a PolarDB InnoDB engine table using a row-based storage model to ensure transactional consistency and low latency in update operations. Analytical data such as order creation time, product category, and timeout statistics for tenant A are stored in a PolarDB column-based storage engine table using a column-based storage model to improve query efficiency. Tenant C's core order data uses a hybrid storage model: basic order information (order number, tenant ID) is stored in a row-based storage table, while order details (product list, logistics tracking history) are stored in a column-based storage table, achieving efficient read and write operations through internal database joins.

[0070] The method provided in this embodiment dynamically selects row storage, column storage, or hybrid storage modes based on business data characteristics (such as high-frequency updates and complex queries), and combines tenant tiering and hot / cold data separation strategies. This ensures low latency for transaction operations such as order updates through row storage, improves the efficiency of early warning queries through column storage, and reduces storage costs through tiered storage and historical data archiving. At the same time, it leverages the elastic scalability of cloud-native databases to adapt to tenant business growth, solving the problems of high cost and read / write performance imbalance in traditional full-volume hot storage, and achieving efficient utilization of storage resources and business adaptation.

[0071] This application also provides another possible implementation of the order risk warning method. Figure 7 A flowchart illustrating an order risk warning method provided in this application embodiment is shown in Figure 7; Figure 7 As shown, based on preset early warning rules, early warning calculations are performed on the business data in the cloud-native database corresponding to each tenant to obtain the early warning result for the target order, including: S701. Based on the preset early warning rules and columnar computing nodes, query the query fields corresponding to the business data stored in columnar mode.

[0072] In this embodiment, the columnar storage compute node is a computing unit specifically designed for columnar storage data. It can be understood as a dedicated processor for columnar storage data and a core component in the HTAP database or distributed computing framework, responsible for computational operations such as querying, filtering, and aggregating columnar storage data. An early warning strategy system is built using the Spring Cloud framework, an ordered collection of frameworks. Preset early warning rules are edited and maintained in real time. These rules can be set to trigger an abnormal track warning if the logistics track has not been updated for more than 12 hours. Query fields include: associated order number, last update time, and current track type. The system calls the columnar storage compute node of the HTAP database to perform batch queries on the logistics data stored in tenant B's columnar storage mode, filtering out logistics records whose last update time is more than 12 hours from the current time, and extracting the corresponding associated order number and current track type.

[0073] S702. Determine whether the query field meets the warning conditions.

[0074] Specifically, if the query yields three logistics records, the first record was last updated on 2024-05-20 08:10:33, and the current time is 2024-05-20 21:20:15, with an interval of 13 hours and 9 minutes, which meets the warning condition of no update for more than 12 hours; the second record has an interval of 14 hours and 20 minutes, which also meets the warning condition of no update for more than 12 hours; the third record has an interval of 10 hours and 30 minutes, which does not meet the warning condition.

[0075] S703. If the target query field meets the warning conditions, the order corresponding to the target query field is determined to be the target order, and the warning result of the target order is generated.

[0076] Among them, the two logistics records that meet the warning conditions correspond to the associated order numbers "DD20240520008" and "DD20240520015", and these two orders are identified as target orders. A warning result is generated based on the warning rules, including: Order Number: DD20240520008, Warning Type: Track Anomaly, Last Update Time: 2024-05-20 08:10:33, Current Track: In Transit, Anomaly Duration: 13 hours and 9 minutes. The warning result for the other order is generated in the same format.

[0077] The method provided in this embodiment relies on the combination of HTAP columnar storage computing nodes and preset early warning rules to achieve sub-second query and early warning judgment of all order data, reduce early warning calculation latency, and improve computing efficiency; at the same time, it ensures the accurate execution of early warning rules, avoids subjective errors and inefficiencies of manual screening, realizes automated and accurate identification of order risks, and buys tenants more time for risk handling.

[0078] This application also provides another possible implementation of the order risk warning method. Figure 8 This is the eighth flowchart illustrating an order risk warning method provided in this application embodiment; as shown below. Figure 8 As shown, the method also includes: S801, Obtain the access request of the new tenant.

[0079] S802. Based on the access request of the new tenant, determine the idle database as the database corresponding to the new tenant.

[0080] In this embodiment, the new tenant D submits an access request through the registration portal provided by the system. The request includes information such as the tenant name, business license information, a list of cooperating e-commerce platforms, the expected daily average order volume (500 orders), contact person and contact information. After receiving the request, the system completes information verification and preliminary registration.

[0081] The DataSourceRouter routing component was used to assess the load status of all current database instances, including the number of tenants, the number of stored orders, and CPU and memory utilization for each instance. It was determined that database instance 3 currently only hosts 8 regular tenants, stores 300,000 orders, has a CPU utilization of 35%, is in an idle state, and meets tenant D's daily business requirement of 500 orders. The system automatically assigned database instance 3 as the database corresponding to tenant D and created an independent data partition for it, completing the database configuration for tenant D.

[0082] It should be noted that when the amount of historical tenant data increases, the computing nodes are horizontally expanded and the ServerLess server configuration is vertically upgraded based on the PolarDB database cluster to support the tenant's business needs.

[0083] The method provided in this application's embodiments automatically evaluates and allocates databases for new tenant access requests. Based on the DataSourceRouter component, it analyzes the load of each database instance in real time, such as the number of tenants and order volume, and matches the optimal idle database for new tenants. This eliminates the need for manual planning of storage resources and reduces operation and maintenance costs. At the same time, the dynamic allocation mechanism supports the horizontal scaling of the number of tenants, solving the problem of resource waste or insufficiency in the traditional fixed storage allocation mode, ensuring the system's adaptability to the growth of the tenant scale, and improving the platform's scalability and commercial potential.

[0084] The following will continue to explain the order risk warning device and electronic device provided in any of the above embodiments of this application. The specific implementation process and the resulting technical effects are the same as those in the corresponding method embodiments. For the sake of brevity, the parts not mentioned in this embodiment can be referred to the corresponding content in the method embodiment.

[0085] Figure 9 This is a schematic diagram of the functional modules of an order risk warning device provided in an embodiment of this application. Figure 9 As shown, an order risk warning system is applied, which connects to clients of multiple tenants. The order risk warning device 100 includes: The acquisition module 110 is used to acquire business data for each tenant. The business data includes order data and logistics data. The order data is the order data of each tenant on multiple business platforms, and the logistics data is the logistics data of each tenant on multiple logistics platforms. Storage module 120 is used to store each tenant's business data in the cloud-native database corresponding to each tenant; The calculation module 130 is used to perform early warning calculations on the business data in the cloud-native database corresponding to each tenant according to preset early warning rules, and obtain the early warning results of the target order; The determination module 140 is used to determine the target tenant based on the order data of the target order; The sending module 150 is used to send the warning results of the target order to the client of the target tenant.

[0086] Optionally, the acquisition module 110 is also used to build a multi-protocol adaptation cluster using a microservice framework, wherein the multi-protocol adaptation cluster is used to support the application interfaces of multiple business platforms; and based on the multi-protocol adaptation cluster, order data of each tenant is acquired.

[0087] Optionally, the acquisition module 110 is also used to receive transaction order messages of each tenant sent by multiple business platforms in real time based on the multi-protocol adaptation cluster; to perform incremental collection on multiple business platforms according to a preset time interval to obtain incremental collection order messages of each tenant; and to determine the order data of each tenant based on the transaction order messages and the incremental collection order messages.

[0088] Optionally, the acquisition module 110 is also used to construct a logistics message pipeline using a distributed message middleware; and to acquire logistics data for each tenant based on the logistics message pipeline.

[0089] Optionally, the acquisition module 110 is also used to acquire the initial logistics data of each tenant based on the logistics message pipeline; partition the initial logistics data according to the preset trajectory type to obtain the partitioned logistics data; and update the format of the partitioned logistics data according to the preset trajectory data format to obtain the logistics data of each tenant.

[0090] Optionally, the storage module 120 is also used to determine the storage mode of the business data based on the data characteristics of the business data. The storage modes include: row storage mode, column storage mode and hybrid storage mode; and to store the business data in the cloud-native database corresponding to each tenant according to the storage mode.

[0091] Optionally, the calculation module 130 is also used to query the query fields corresponding to the business data stored in columnar storage mode according to the preset early warning rules and columnar storage calculation nodes; determine whether the query fields meet the early warning conditions; if the target query field meets the early warning conditions, determine the order corresponding to the target query field as the target order, and generate the early warning result of the target order.

[0092] Optionally, it also includes: The acquisition module 110 is also used to acquire access requests from newly added tenants; The determination module is used to identify an available database as the database corresponding to a new tenant based on the new tenant's access request.

[0093] The above-described device is used to execute the method provided in the foregoing embodiments, and its implementation principle and technical effect are similar, so they will not be described again here.

[0094] These modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more microprocessors, or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a system-on-a-chip (SoC).

[0095] Figure 10 This is a schematic diagram of an electronic device provided in an embodiment of this application. This electronic device can be used for order risk warning. Figure 10 As shown, the electronic device includes: a processor 210, a storage medium 220, and a bus 230.

[0096] Storage medium 220 stores machine-readable instructions executable by processor 210. When the electronic device is running, processor 210 communicates with storage medium 220 via bus 230, and processor 210 executes the machine-readable instructions to perform the steps of the above method embodiment. The specific implementation and technical effects are similar and will not be described again here.

[0097] Optionally, this application also provides a storage medium 220, on which a computer program is stored. When the computer program is run by a processor, it executes the steps of the above-described method embodiments. The specific implementation and technical effects are similar, and will not be repeated here.

[0098] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0099] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0100] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0101] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0102] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for early warning of order risks, characterized in that, The method, applied to an order risk warning system that connects to clients of multiple tenants, includes: Obtain business data for each tenant, wherein the business data includes: order data and logistics data, wherein the order data is the order data of each tenant on multiple business platforms, and the logistics data is the logistics data of each tenant on multiple logistics platforms; The business data of each tenant is stored in the cloud-native database corresponding to each tenant. Based on preset early warning rules, early warning calculations are performed on the business data in the cloud-native database corresponding to each tenant to obtain the early warning result for the target order; Based on the order data of the target order, determine the target tenant; The alert results for the target order are sent to the target tenant's client.

2. The method as described in claim 1, characterized in that, The acquisition of business data for each tenant includes: A multi-protocol adaptation cluster is constructed using a microservice framework, wherein the multi-protocol adaptation cluster is used to support the application interfaces of multiple business platforms; Based on the multi-protocol adaptive cluster, the order data of each tenant is obtained.

3. The method as described in claim 2, characterized in that, The step of obtaining the order data for each tenant based on the multi-protocol adaptation cluster includes: Based on the multi-protocol adaptation cluster, the system receives transaction order messages from each tenant sent by the multiple business platforms in real time. Incremental data collection is performed on the multiple business platforms according to a preset time interval to obtain incremental collection order messages for each tenant; Based on the transaction order messages and the incrementally collected order messages, the order data for each tenant is determined.

4. The method as described in claim 1, characterized in that, The acquisition of business data for each tenant includes: Utilize distributed message middleware to construct logistics message pipelines; Based on the logistics message pipeline, the logistics data of each tenant is obtained.

5. The method as described in claim 4, characterized in that, The process of obtaining the logistics data for each tenant based on the logistics message pipeline includes: Based on the logistics message pipeline, the initial logistics data of each tenant is obtained; The initial logistics data is partitioned according to a preset trajectory type to obtain partitioned logistics data. According to the preset trajectory data format, the logistics data after partitioning is updated to obtain the logistics data for each tenant.

6. The method as described in claim 1, characterized in that, The step of storing the business data of each tenant into the cloud-native database corresponding to each tenant includes: Based on the data characteristics of the business data, the storage mode of the business data is determined, including: row storage mode, column storage mode, and hybrid storage mode; According to the storage mode, the business data is stored in the cloud-native database corresponding to each tenant.

7. The method as described in claim 1, characterized in that, The step of performing early warning calculations on the business data in the cloud-native database corresponding to each tenant according to preset early warning rules to obtain the early warning result for the target order includes: Based on the preset early warning rules and columnar computing nodes, query the query fields corresponding to the business data stored in columnar storage mode; Determine whether the queried field meets the warning conditions; If the target query field meets the warning conditions, the order corresponding to the target query field is determined to be the target order, and a warning result for the target order is generated.

8. The method as described in claim 1, characterized in that, The method further includes: Obtain the access request from the newly added tenant; Based on the access request of the new tenant, an idle database is determined as the database corresponding to the new tenant.

9. An order risk warning device, characterized in that, An device for use in an order risk warning system, wherein the order risk warning system connects to clients of multiple tenants, the device comprising: The acquisition module is used to acquire business data for each tenant, wherein the business data includes order data and logistics data, the order data being the order data of each tenant on multiple business platforms, and the logistics data being the logistics data of each tenant on multiple logistics platforms; The storage module is used to store the business data of each tenant into the cloud-native database corresponding to each tenant; The calculation module is used to perform early warning calculations on the business data in the cloud-native database corresponding to each tenant according to preset early warning rules, and obtain the early warning result of the target order; The determination module is used to determine the target tenant based on the order data of the target order; The sending module is used to send the warning results of the target order to the client of the target tenant.

10. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus. The storage medium stores program instructions executable by the processor. When the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the program instructions to perform the steps of the order risk warning method as described in any one of claims 1 to 8.

Images