Customer relation information storage and retrieval method and system based on bidirectional graph cache

Abstract

The invention provides a customer relationship information storage and retrieval method and system based on bidirectional graph cache, and the method comprises the steps: constructing a double-layer cache architecture based on graph structure perception, fusing the structural features of a bidirectional graph into a cache strategy, and replacing traditional key value pair cache with sub-graph level cache; constructing a self-adaptive bidirectional atlas index; constructing a distributed consistency collaborative maintenance mechanism based on the graph change transaction log; receiving an operation request of client instance information on the business capability layer, and judging an instance operation type; adding, deleting, modifying and checking the client instance information through the instance object management API in the process data management layer; client instance information changes are recorded through the cache transaction container; and the operation result is persisted to a database. According to the invention, the rapid response client query and order real-time calculation capabilities are greatly improved, the final user experience is greatly improved, the multi-stage service scenes are supported to operate the client relationship data at the same time, and the flexibility and efficiency of service processing are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of telecommunications service support, and particularly to a method and system for storing and retrieving customer relationship information based on a bidirectional graph cache. Background Art

[0002] With the expansion of the business scale and the increase in complexity of telecommunications operators, customer relationship information has shown explosive growth. Traditional relational databases and simple caching technologies are facing increasing challenges. In an environment of high concurrency and high-frequency access, especially in scenarios involving complex customer relationship networks, problems such as reduced system response speed, difficulty in ensuring data consistency, and excessive resource consumption have become increasingly prominent.

[0003] The characteristics of telecommunications services determine that their customer data has a complex relationship structure with multiple levels and dimensions, such as the nested relationship between customers, sales products, and products. The effective management of such data is of great significance for improving business processing efficiency. The traditional key-value pair caching method requires multiple network interactions when processing such relational data, resulting in low query efficiency. At the same time, the different characteristics of specification data (such as sales products, product templates, etc.) and instance data (specific instances ordered by customers) also pose challenges to data storage and access strategies. The former is relatively stable but has a high access frequency, while the latter changes frequently and needs to be shared in a distributed environment. A unified caching strategy is difficult to meet the different needs of these two types of data. In a distributed system architecture, the data consistency problem is particularly prominent. Conventional distributed cache synchronization mechanisms are prone to data inconsistency in high-concurrency scenarios, affecting the accuracy and reliability of business processing. In addition, abnormal situations during the order processing process (such as system failures, business rollbacks, etc.) pose higher requirements for distributed cache transaction management.

[0004] The application layer architecture specification of China Telecom's new-generation BSS3.0 customer relationship management system clearly states that the system architecture should support low-cost elastic expansion and emphasizes the comprehensive management and efficient query and modification capabilities of customer information. In recent years, graph database technology has received extensive attention due to its characteristic of intuitively representing complex relationships between entities, and advanced caching technology has also shown great potential in improving data access speed. However, existing technologies still have deficiencies in deeply integrating graph structures with caching strategies, supporting efficient retrieval of dynamic relationship networks, and ensuring cache data consistency in a distributed environment. This makes it urgent to have an innovative solution in the field of telecommunications customer relationship management to solve the above problems.

[0005] With the continuous improvement of business requirements, customers are demanding an increasingly higher response speed for business services. How to achieve millisecond-level data retrieval and processing in a complex relationship network has become a key factor in enhancing customer satisfaction and market competitiveness. The industry has begun to explore technical routes that combine graph-structured data models, multi-level cache architectures, and distributed consistency protocols. However, in practical applications, many challenges still remain, especially in large-scale, high-concurrency, and complex-structured business scenarios such as telecommunications. Summary of the Invention

[0006] To overcome the deficiencies of the prior art, the present invention proposes a method and system for storing and retrieving customer relationship information based on a bidirectional graph cache. For the first time, the characteristics of bidirectional graphs are deeply integrated into cache, indexing, and transaction management, realizing a hierarchical optimization architecture of "localized acceleration of specification data + distributed sharing of instance data". Through the synergistic effect of a two-layer cache architecture based on graph structure awareness, data preheating, an adaptive bidirectional graph spectrum index, and dynamic relationship traversal optimization technology, a new generation of relationship data processing solutions is provided for the telecommunications BSS system, significantly reducing the system operation and maintenance costs and promoting the development of the telecommunications customer relationship management system towards a more efficient and stable direction.

[0007] To achieve the above object, the present invention proposes a method for improving the storage and retrieval efficiency of complex customer relationship information based on bidirectional graph cache technology, including the following steps: Construct a two-layer cache architecture based on graph structure awareness. Different from traditional key-value pair caches, the structural characteristics of bidirectional graphs are incorporated into the cache strategy, and the network overhead during cross-vertex retrieval is reduced through sub-graph-level caching. The structural characteristics of bidirectional graphs include vertex association degree, relationship type, access frequency, and business attributes; Construct an adaptive bidirectional graph spectrum index. Different from traditional graph traversal technologies, the performance bottleneck of complex relationship operations in high-concurrency scenarios is solved through a hierarchical indexing mechanism and a dynamic path optimization algorithm, realizing the adaptability and efficiency of graph data addition, deletion, modification, and query; Construct a distributed consistency collaborative maintenance mechanism based on graph change transaction logs. Different from traditional distributed transactions, through the collaborative control mechanism of graph transaction logs and the cache layer, a double-closed-loop synchronization system of "local cache transaction - distributed graph log" is realized, ensuring the update consistency and performance balance of complex customer instance relationships in a distributed environment; Receive an operation request for customer instance information at the business capability layer, and determine whether the instance operation type is instance addition, instance deletion, instance modification, or instance query; Execute the addition, deletion, modification, and query operations of customer instance information through the instance object management API at the process data management layer. Among them, instance addition, deletion, and modification are implemented through instance operation classes, and instance query is implemented through instance query classes; Record the changes of customer instance information through the cached transaction container, including the scenario instance container modified in the current cached transaction, the information container related to the customer instance relationship graph, the scenario instance change information, the deleted instances, and the modified instance attribute field names; Ensure data consistency in the distributed environment through the graph change transaction log, and store the corresponding change records in the database when the distributed cache data is updated; Persist the operation results to the database to complete the process of adding, deleting, modifying, and querying customer instance information.

[0008] Furthermore, the two-layer cache architecture based on graph structure perception includes: Local cache layer: Store the uninstantiated specification data, optimize it according to the vertex association degree and relationship type, and classify and store it according to the specification type (product, sales product, relationship rule). For example, all package templates under the "sales product specification" (such as the "199 yuan 5G package" specification) are cached in the same subset; Distributed cache layer: Adopt subgraph-level serialization to store customer instance data. Different from the traditional key-value pair method, it is serialized and stored through a graph structure (adjacency list / adjacency matrix) to achieve single-time acquisition of the complete subgraph and avoid multiple network IOs during cross-vertex retrieval; Store the instance data in slices according to the customer dimension, and store the instance data of each customer as an independent subgraph. For example, the instance data of customer ID C001 corresponds to subgraph G(C001), which contains all its scenario instances and customer relationship instances; In the local cache layer, adopt a dual elimination strategy of "least recently used (LRU) + specification association degree", preferentially eliminate the specification data that has not been used for a long time (such as unpopular package specifications), and extend the cache time for the specifications with high association degree (such as the general relationship rules referenced by multiple instances); In the distributed cache layer, ensure cross-node data synchronization through a distributed consistency protocol (such as the Redis Cluster sharding mechanism), so that when the operator operates on the same customer instance, the distributed cache serves as the only data source to avoid local cache inconsistency problems.

[0009] Furthermore, the two-layer cache architecture based on graph structure perception also includes a graph structure-aware dynamic warm-up strategy: For the warm-up of specification data: Identify the associated subgraphs of high-frequency specifications through the breadth-first search (BFS) algorithm. For example, if it is found that the access path of "hot-selling package specification → general preferential specification → main product specification" accounts for 40%, then mark this subgraph as a "hot factor graph"; Load the historical top 100 high-association specification subgraphs at system startup and preload them into the local memory to reduce repeated database queries; Automatically load all sub-graphs associated with the updated specifications after the specification update. For example, after modifying "General Promotion", synchronously load all package specifications associated with it. For instance data preheating: Based on the customer's historical order data, predict the instance sub-graph corresponding to the high-frequency operation scenarios. For example, if a certain customer often handles "Package Upgrade", then pre-load the sub-graph of "Main Package Instance → Main Product Instance → Promotion Instance" for this customer. Analyze the commonly used instance relationship chains according to business scenarios (such as "New Package Installation", "Suspension of Service with Number Preservation"), and pre-load the minimum sub-graph required for the scenario. For example, for the "New Package Installation" scenario, pre-load the package vertex, tariff vertex, accounting customization relationship vertex and their associated edges to reduce the real-time construction overhead.

[0010] Furthermore, the adaptive bidirectional graph index includes the following three-layer index structure with dynamic weight perception ability: Vertex index layer: Establish a global hash index according to the instance type, supporting vertex positioning with a time complexity of O(1). For example, when querying "All package instances associated with Customer A", directly obtain the candidate vertex set from the "package" type index; add business labels (such as "order", "modify", "delete") to the vertices, and quickly filter through combined conditions. For example, when retrieving "Packages for sale and with price < 200 yuan", only traverse the vertices with the corresponding labels, reducing the search scope by 80%. Relationship index layer: Establish sub-indexes according to the relationship types of the edges ("order", "include", "depend"), and store the edges of each type as a bidirectional adjacency list; for the characteristics of the bidirectional graph, simultaneously maintain the forward (u→v) and reverse (v→u) adjacency lists to support fast bidirectional traversal. For example, when querying "Which package is mutually exclusive with Package P001", directly access the reverse list of the "order" relationship index without traversing all customer vertices. Path index layer: Through the analysis of historical operation logs, pre-compute and store the Top-N high-frequency access paths (such as "Customer → Main Package → Optional Package", "Package → Dependent Product → Functional Product"), and each path records the vertex sequence and relationship type sequence; when querying, preferentially match the pre-computed paths to avoid real-time full-graph traversal, reducing the response time from 100ms to 30ms.

[0011] Furthermore, the adaptive bidirectional graph index also includes a dynamic path optimization algorithm: Based on the analysis of historical operation logs, extract and sort the Top-N path patterns with the highest access frequencies, such as taking "Customer → Popular Package → Main Product" as the pre-computed path; For each high-frequency path, record the vertex sequence and relationship type sequence, for example: [Customer C001, order, Package P001, include, Optional Package A001]; Build a path index hash table with the path pattern as the key and the precomputed result as the value to support fast query matching; Path weight calculation: Use the path access frequency, path length, and recent access time as weight factors to regularly update the path importance score; Adaptive path update: Dynamically adjust the precomputed path set according to real-time access statistics, automatically adding hot paths to the index and removing cold paths; When querying, preferentially call the precomputed path through pattern matching, and perform real-time traversal when not hitting, optimizing the query performance.

[0012] Furthermore, the distributed consistency collaborative maintenance mechanism based on the graph change transaction log includes: Local transaction closed-loop: Generate production and sales product vertices (package M001, optional package A001) in the local cache transaction container, and establish a scenario instance relationship (the association between order scenario S001 and the package / optional package) and a customer instance relationship (the "subscription" two-way edge between customer C001 and package M001); Transaction snapshot capture: The container records graph change operations (ADD_VERTEX, ADD_EDGE) in real time to form a transaction snapshot containing vertex attributes (such as package specifications, prices) and two-way edge types (subscription / subscribed, included / included); Order scenario adaptation: For scenarios such as "new installation of sales products" and "package modification", the container isolates transaction data by scenario dimension to avoid cross-scenario data contamination; Graph transaction log generation: Serialize the vertex and edge operation sequences temporarily stored locally into a graph transaction log, which contains all graph change details involved in the order; Distributed log closed-loop: Build a structured transaction log containing two-way graph operation instructions, and use a lightweight consensus algorithm (such as a Raft variant) to synchronize the graph transaction log to ensure that all distributed cache nodes execute the log instructions in order; Batch execution: After receiving the log, the node executes the graph change operations in order, reducing network interaction by 70% compared to traditional single operations; Persistent storage: Write the vertex and relationship data corresponding to the log into the database, and record the log ID for subsequent traceability.

[0013] Furthermore, the structure of the graph transaction log includes: Customer identifier: Uniquely identifies the customer associated with the transaction for sharding routing; Customer instance relationship graph: Contains instance vertex mappings, and the vertex mappings include vertex ID, parent edges connected to the vertex, child edges connected to the vertex, start point ID, end point ID, instance ID, instance type, action type; Modified vertex information: Records all changed vertex attributes and old and new values; Deleted vertex information: includes a complete snapshot of the deleted vertices for rollback; Deleted edge information: includes source instance ID, source instance type, target instance ID, target instance type, action type, relationship type; Reverse operation list: records the operation sequence for rollback, which is the opposite of the forward operation order; The log clearly records the consistency constraints of bidirectional edges. For example, when adding an "order" edge, the operation of adding the reverse "ordered by" edge is automatically recorded.

[0014] Furthermore, the distributed consistency collaborative maintenance mechanism based on the graph change transaction log includes ensuring the consistency of the entire order processing process: Order submission phase: The local cache transaction container generates a scenario instance graph related to the order, including vertices such as "Scenario ID - 123", "5G package", and "Video membership package"; establish bidirectional edges: "Customer A → 5G package" (ordering relationship), "5G package → Video membership package" (dependency relationship) and their reverse edges; before the order calculation is successful, all changes only exist in the local cache transaction container and do not affect the distributed cache and the database; if the calculation fails, directly roll back the local transaction, and the customer instance relationship graph remains unchanged; Order submission successful: Serialize the vertex and edge operation sequences temporarily stored locally into a graph transaction log; the local transaction container sends the log to the distributed log center; each distributed cache node updates the instance relationship graph of Customer A (add vertices and bidirectional edges) in batches through log parsing; the database persists the order information and records the graph transaction ID simultaneously to trace the change history; Batch processing mechanism: Merge multiple vertex and edge changes of the same customer into a single transaction package; package the changes of vertex groups with high correlation for processing; optimize the execution order according to topological sorting to ensure the correctness of the dependency relationship; execute multiple graph operation instructions through a single network transmission; Order rollback scenario: The distributed log center marks this transaction as "failed", and each node restores the customer instance relationship graph according to the reverse operations (such as "DELETE_VERTEX", "DELETE_EDGE") in the log; the local cache transaction container clears the residual data to ensure the final consistency of the distributed cache and the database. For example, the video membership package that was not successfully ordered is removed from the package list of Customer A.

[0015] Furthermore, the operation steps of the cache transaction container include: Store the instance data that needs to be placed in the distributed cache in the local application vertices in terms of one request dimension. After the request thread is completed, if there is no exception, update the changed instance data to the distributed cache at one time; Cache information containers related to the scenario instance container, customer instance relationship diagram, scenario instance change information, deleted instances, modified instance attribute field names, queried scenario instance container cache, queried instance cache, added access product instances, deleted access product instances, and queried access product instances modified in the current cache transaction; If there is an exception during this request process, destroy the local cache instance of this request, and the distributed cache will remain unchanged, ensuring data consistency; Mark the change type according to the instance operation type, including: addition - ActionType = A, deletion - ActionType = D, modification - ActionType = M, no modification - ActionType = K; Generate an instance change object of the corresponding type according to the change type, which is used as the calculation basis for the incoming data generated by the final order; Ensure the integrity and consistency of data updates through the ACID (Atomicity, Consistency, Isolation, Durability) principle. If any step in the scenario change information transaction fails, the entire transaction will roll back to ensure that the data in the database and cache is not in an inconsistent state.

[0016] Furthermore, the application scenarios of the method in the customer relationship management system of telecom operators include: Hierarchical relationship management of production, sales, and products: Process multi-level instance relationship changes of sales products → products → functions, and support complex associations between specification data (such as sales products, products, sales product relationships, etc.) and instance data (such as specific packages ordered by customers, functional products, etc.) in telecom services; Linked update of the scenario instance diagram and the customer instance relationship diagram: Ensure the consistency of cross-scenario data in order processing. For example, in the "package modification" scenario, both the customer relationship diagram and the scenario instance diagram are updated simultaneously; Fast retrieval of complex customer instance relationships in a high-concurrency environment: Support operations such as order entry, order preview, order charging, order collection, and order submission in scenarios such as new installation of sales products, modification of sales products, modification of functional products, and modification of account customization relationships; Order processing and rollback in a distributed architecture: For example, when customer A orders the "5G main package + video membership package" order, the local cache transaction container generates a scenario instance diagram containing vertices such as "Scenario ID - 123", "5G package", and "video membership package", and establishes relationships such as "Customer A → 5G package" (subscription relationship), "5G package → video membership package" (dependency relationship) and their reverse edges to ensure the consistency of customer relationship data; Business functions that support complex customer instance relationships: including customer location, sales product query, order entry for various scenarios, order preview, order billing, order charging, order submission, etc., and provide operations for adding, deleting, modifying, and querying scenarios, gift packages, main packages, optional packages, promotions, main products, functional products, terminal products, account instances, etc. and their instance relationships through the instance object management API.

[0017] A system for storing and retrieving customer relationship information based on a bidirectional graph cache, applicable to the method for storing and retrieving customer relationship information based on a bidirectional graph cache described above, characterized in that the system includes: View layer: As the part of the system directly facing users, it is responsible for presenting data to users in a visual manner, receiving user input and operations, and passing the operations to the business capabilities layer; External API layer: Provides standardized interfaces and related auxiliary classes externally to ensure seamless integration and interoperability between different systems; Common facilities layer: Provides shared code blocks, libraries, frameworks, and services for multiple applications or services within the system, reducing duplicate development; Business capabilities layer: Responsible for defining and implementing the specific business capabilities of the system, processing business logic, and providing functions such as customer location, sales product query, order entry, preview, billing, charging, and submission for various scenarios; Process data management layer: The core layer of the system, which implements three core technologies through the following components: a) Scenario instance container: Caches all instance object information to be submitted for the current scenario, including changes in scenario instances, relationship changes, and attribute changes; b) Cache transaction container: Responsible for caching the cache information that needs to be submitted when operating on customer instance information, and controlling the atomicity of cache transactions; c) Customer instance relationship graph container: Responsible for caching the instance change information of customers associated with the current scenario, and maintaining the integrity of the customer instance relationship graph; d) Instance change information container: Generates corresponding instance change objects according to the instance operation type; Data persistence layer: Processes code related to database operations, including data access objects, SQL statements, and connection pool management, etc.; Infrastructure layer: It provides basic support for the entire system, including distributed cache, database, network communication, and storage management, etc.; among them, the business capability layer realizes business functions by calling the instance object management API of the process data management layer; the process data management layer interacts with the distributed cache of the infrastructure layer through the distributed consistency collaborative maintenance technology based on the graph change transaction log; the data persistence layer loads database data into the distributed cache and local cache through the double-layer cache architecture and data preheating technology based on graph structure awareness, providing a basic data relationship structure for the vertices and edges of the customer relationship graph.

[0018] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. The present invention provides a method and system for storing and retrieving customer relationship information based on a bidirectional graph cache, which realizes a 200% improvement in transaction capabilities, more than 1.5 times improvement in the operation efficiency of complex scenarios, supports high-concurrency real-time processing of tens of millions of customer instances, a 30% improvement in query processing efficiency, a 70% improvement in traversal efficiency, and optimizes the high-frequency traversal response time to within 100 ms, effectively solving the performance bottleneck problem of traditional relational databases in processing complex customer relationship information.

[0019] 2. The present invention provides a method and system for storing and retrieving customer relationship information based on a bidirectional graph cache, which significantly accelerates the business response time, shortens the online time of small and medium-sized scenarios from the traditional 5 - 7 days to 2 - 3 days, and compresses the customer order processing time to within 3 minutes. The ability to quickly respond to customer queries and perform real-time order calculations has been greatly improved, significantly improving the end-user experience. At the same time, it supports the simultaneous operation of customer relationship data in multiple-level business scenarios, improving the flexibility and efficiency of business processing.

[0020] 3. The present invention provides a method and system for storing and retrieving customer relationship information based on a bidirectional graph cache, which adopts the distributed consistency collaborative maintenance technology of graph change transaction logs, enabling the data consistency to reach 95%, the rollback efficiency to be improved by 90%, and the rollback efficiency of failed order processing to be improved by more than 90%. This technology ensures the atomic change of the production, sales, and product relationships in order processing, significantly reduces the risk of data inconsistency, and ensures the accuracy and consistency of data in a high-concurrency environment, providing a reliable data foundation for the business system. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for the description of the specific embodiments or the prior art. Obviously, the following drawings are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0022] Figure 1 is the schematic diagram of the system architecture of the present invention; Figure 2 is the flow chart of steps; Figure 3 is the system architecture diagram, showing the multi-layer architecture of the system and the dynamic data preheating strategy; Figure 4 Schematic diagram of the relationship between specification data and instance data; Figure 5 is the comparison schematic diagram between sub-graph level cache and traditional key-value pair cache; Figure 6 is the data organization method, including the sales product instance diagram, customer relationship instance diagram and actual storage structure schematic diagram; Figure 7 is the dynamic update schematic diagram of the customer relationship diagram; Figure 8 is an example of the query operation process, showing the query path schematic diagram; Figure 9 is the schematic diagram of scenario isolation and local transaction closed-loop; Figure 10 is the schematic diagram of the full-process consistency guarantee mechanism for order processing. Specific implementation manners

[0023] Next, the technical solution of the present invention will be described more clearly and completely by combining with the accompanying drawings and through the description of the preferred implementation manners of the present invention.

[0024] Term explanation: Graph: In mathematics, a graph is a structure that describes a set of objects, where some objects are "related" in a certain sense. These objects correspond to mathematical abstractions called vertices (also known as nodes or points), and each pair of related vertices is called an edge (also known as a link or line). Usually, a graph is depicted diagrammatically as a set of points or loops of vertices, connected by lines or curves of edges.

[0025] Directed graph: A directed graph is a special graph structure in which each edge has two directions, that is, for any two vertices u and v, if there is an edge from u to v, then there must be an edge from v to u. This structure gives the directed graph significant advantages in representing and processing symmetric relationships. For example, in customer relationship management, the two-way relationship between customers can be intuitively represented and efficiently queried through a directed graph. This characteristic of the directed graph enables it to support both forward and backward traversals when dealing with complex relationship networks, thereby improving the retrieval efficiency and flexibility.

[0026] Specification data: Abbreviated as "specification", it is uniformly agreed upon by the telecommunications company. It has attributes, pricing, and is shared by the entire telecommunications network. Examples include products, sales items, and sales item relationships. Specification data exists logically prior to instance data and serves as the basis for its generation. Specification data is the "precursor" of instance data.

[0027] Instance data: Abbreviated as "instance", it is the vertex in the graph. The relationships between instances are the edges in the graph. It represents the data generated from handling specific business operations. Each piece of data is unique and is exclusive to a particular customer and cannot be shared with others. In the process of a customer handling a business (such as subscribing to a 5G package or adding a new feature product), there will be multiple instances and instance relationships in the customer instance relationship graph and the scenario instance relationship graph.

[0028] Customer relationship graph: The customer relationship graph is a structure based on a bipartite graph, centered around the customer, which records all instances (such as sales item instances, product instances, etc.) under that customer and their mutual relationships. It represents instances through vertices and relationships between instances through edges, supports bidirectional traversal, can efficiently query and manage complex relationship networks related to customers, is suitable for the comprehensive management and analysis of customer operations, and all scenario instances of the same customer share a single customer instance relationship graph.

[0029] Scenario: In this patent, the definition of a scenario aims to encapsulate complex business logic into an independent processing module. Each scenario covers the entire life cycle from when a customer initiates a request to when the system completes processing, facilitating system management and optimization. For example, in telecommunications services, a "new installation of a sales item" scenario may include multiple steps such as customer positioning, package selection, order entry, fee confirmation, and order submission, which together constitute a complete business scenario.

[0030] Scenario instance graph: The scenario instance graph is a graph model constructed for a specific business scenario, which records the basic information of the scenario as well as all instance vertices included in the scenario and the relationships between them. It is based on business scenarios and supports business operations and data management at the scenario level, facilitating efficient business processing and data retrieval by the system. For example, in scenarios such as new installation of a sales item and modification of a sales item, it clearly shows the roles and relationships of each instance.

[0031] Distributed cache: A cache system deployed across multiple nodes that enables data sharing through network connections, providing a larger storage capacity and high availability. In this patent, it is mainly used to store specification data and instance data, supporting data sharing and high-concurrency access. Instance data is mainly stored in the distributed cache to achieve data sharing because instance data changes frequently, and in a distributed architecture, each application node needs to share a single copy of the instance data. Examples include the customer relationship graph and the scenario instance graph.

[0032] Local cache: A cache deployed in the memory of the application server or client, characterized by fast access speed and low latency. In this patent, it is mainly used to store frequently accessed specification data to further improve the data access speed.

[0033] Secondary cache: A two-layer cache architecture that combines distributed cache and local cache. In this patent, it is mainly used to store specification data, and its loading order is: database --> distributed cache --> local cache, so it is called "secondary cache". The specification data changes infrequently, and the access efficiency is optimized through the secondary cache mechanism.

[0034] As Figure 1 shown, the system includes: View layer: As the part of the system directly facing the user, it is responsible for presenting data to the user in a visual way, receiving user input and operations, and passing the operations to the business capability layer; External API layer: Provides standardized interfaces and related auxiliary classes externally to ensure seamless integration and interoperability between different systems; Common facilities layer: Provides shared code blocks, libraries, frameworks and services for multiple applications or services within the system, reducing duplicate development; Business capability layer: Responsible for defining and implementing the specific business capabilities of the system, processing business logic, and providing functions such as locating customers, querying sales products, order entry, preview, fee calculation, charging and submission in various scenarios; Process data management layer: The core layer of the system, which realizes three core technologies through the following components: a) Scenario instance container: Caches all instance object information to be submitted in the current scenario, including changes in scenario instances, relationship changes and attribute changes; b) Cache transaction container: Responsible for caching the cache information to be submitted when operating on customer instance information, and controlling the atomicity of cache transactions; c) Customer instance relationship graph container: Responsible for caching the instance change information of the customers associated with the current scenario, and maintaining the integrity of the customer instance relationship graph; d) Instance change information container: Generates corresponding instance change objects according to the instance operation type; Data persistence layer: Processes code related to database operations, including data access objects, SQL statements and connection pool management, etc.; Infrastructure layer: It provides basic support for the entire system, including distributed cache, database, network communication, and storage management, etc.; among them, the business capability layer realizes business functions by invoking the instance object management API of the process data management layer; the process data management layer interacts with the distributed cache of the infrastructure layer through the distributed consistency collaborative maintenance technology based on the graph change transaction log; the data persistence layer loads database data into the distributed cache and local cache through the double-layer cache architecture and data preheating technology based on graph structure perception, providing the basic data relationship structure for the vertices and edges of the customer relationship graph.

[0035] A method for improving the storage and retrieval efficiency of complex customer relationship information based on bidirectional graph caching technology is mainly applied in the process data management layer. Starting from the business capability layer, the main processes of adding, deleting, modifying, and querying instance data in the process data management layer are as Figure 2 shown: Step S1: Build a double-layer cache architecture based on graph structure perception, integrate the structural features of the bidirectional graph into the cache strategy, and replace the traditional key-value pair cache with subgraph-level cache; Step S2: Build an adaptive bidirectional graph index to support dynamic weight perception and efficient traversal of complex relationships; Step S3: Build a distributed consistency collaborative maintenance mechanism based on the graph change transaction log to achieve a "local cache transaction - distributed graph log" double-closed-loop synchronization system; Step S4: Receive the operation request of the customer instance information at the business capability layer and judge the instance operation type; Step S5: Execute the add, delete, modify, and query operations of the customer instance information through the instance object management API at the process data management layer; Step S6: Record the changes of the customer instance information through the cache transaction container; Step S7: Ensure data consistency in the distributed environment through the graph change transaction log; Step S8: Persist the operation result to the database.

[0036] As a specific implementation manner of the present invention, it is applied to the customer relationship management system of a telecom operator. In this implementation manner, the system adopts a layered architecture design, including an infrastructure layer, a data persistence layer, a process data management layer, a business capability layer, a public facility layer, an external API layer, and a view layer. The core technology implementation of the present invention is mainly located in the process data management layer, and this layer effectively solves the core challenges in telecom customer relationship management by implementing three key technological innovations.

[0037] Such as Figure 3As shown in the figure, the system adopts a multi-layer architecture design. The business function modules are displayed on the left side. In the upper-middle part, there is a relational network of dynamic data preheating strategies and specifications layer. In the lower-middle part, there is a distributed cache structure, presenting the data flow path from the specifications layer to the instance layer. The system supports business functions (such as "new installation of sales products", "modification of sales products", etc.) to achieve efficient data access and processing through dynamic data preheating strategies.

[0038] In a specific hardware environment, this system is deployed in the telecommunications business hall network, including several application servers, cache servers, and database servers. The infrastructure layer uses a distributed cache cluster and a database cluster. The data persistence layer is responsible for data access and mapping. The process data management layer implements the core business logic. The business capabilities layer provides specific business functions such as package handling and customer query.

[0039] In this embodiment, the specific implementation method of the double-layer cache architecture based on graph structure perception is as follows: As Figure 4 shown in the figure, the system is divided into two parts: the specifications layer and the instance layer. The specifications layer mainly stores the frequently accessed specification data, and loads the TOP100 highly correlated specifications through dynamic data preheating technology. The instance layer includes gift package instances, package instances, promotion instances, and product instances, etc., and performs instance data prediction and preheating through order analysis. The local cache layer uses in-memory cache technology to store the un-instantiated specification data. The specification data is grouped and stored by type. For example, product specifications, sales product specifications, and relationship rules are stored in independent cache partitions respectively. Each specification object contains its basic attributes and metadata. For example, the specification of the "199 yuan 5G package" contains attributes such as price, traffic, and call duration, as well as compatibility rules with optional services. The system identifies the frequently used specifications according to the historical access logs and preferentially loads them into the local cache to improve the hit rate. The cache eviction adopts a dual strategy of "LRU + specification correlation degree", preferentially evicting the specification data that has not been used for a long time (such as the discontinued package), while extending the cache time for the highly correlated specifications (such as the basic package rules).

[0040] As Figure 5As shown, the subgraph-level cache of the present invention has significant differences from traditional key-value pair caches. Traditional key-value pair caches store values with a single instance ID as the key, while the present invention stores them in the form of source point + subgraph (such as CustomerID:Subgraph); the traditional method requires multiple reads of vertex-adjacent relationships (requiring N network I / Os), while the present invention obtains a complete subgraph in a single time (1 network I / O); the traditional method does not utilize the graph structure and only stores and accesses simple data, while the present invention supports graph-based storage and access and supports graph operation functions; in terms of the efficiency of complex queries, the traditional method averages about 800 ms (when N = 5 network accesses), while the present invention averages about 500 ms (a 37.5% speed increase and a reduction in network overhead); in terms of the warm-up strategy, the traditional method is based on random access to the same database, while the present invention is based on a warm-up function loading based on the degree of association.

[0041] The distributed cache layer stores instance data, sharded by customer dimension. For each customer, the system stores all the relevant instance data (vertices and edges) as a complete subgraph. The subgraph is serialized using an adjacency list structure, where vertices contain instance ID, type, and a set of attributes, and edges contain source vertex ID, target vertex ID, relationship type, and a set of attributes. This subgraph-level serialized storage method allows the system to obtain a complete customer relationship graph in a single network request, significantly reducing the overhead of multiple network interactions required by the traditional key-value pair storage method.

[0042] As Figure 6 shown, the data organization method of the system is divided into three parts: on the left is the sales product instance graph, which includes package specifications, promotion specifications, product specifications, etc.; in the middle is the customer relationship instance graph, which shows the relationship network between customers and various instances; on the right is the actual storage structure, corresponding to various instances on the left. The figure clearly shows the process of how instance data is transformed from the specification graph into the customer relationship graph and then mapped to the storage layer.

[0043] The dynamic data warm-up strategy is implemented separately for specification data and instance data. For specification data, the system loads the TOP100 highly associated specification subgraphs at startup. The system analyzes the association relationships between specifications through a breadth-first search algorithm to identify the set of specifications with high access frequencies. For example, when it is found that the access path of "hot-selling package specification → general preferential specification → main product specification" accounts for 40%, this subgraph will be marked as a "hot factor graph" and preferentially loaded. When the specifications are updated, the system will automatically load the affected associated specifications. For instance data, the system predicts high-frequency operation scenarios based on the customer's historical behavior. For example, if a certain customer often handles "package upgrades", then the subgraph of "main package instance → main product instance → promotion instance" of this customer is pre-loaded. The system will also pre-load relevant data according to the business scenario. For example, in the "package installation" scenario, the package vertex, tariff vertex, and accounting customization relationship vertex and their associated edges will be pre-loaded.

[0044] The specific implementation of the adaptive bidirectional graph index and dynamic relationship traversal optimization technology in this embodiment includes a three-layer index architecture. The vertex index layer builds a global hash index according to instance types, supporting O(1) time positioning of all vertices of a specific type. The system has predefined common types of telecommunications business entities, such as "customers", "packages", "optional packages", etc. Each vertex is also attached with business tags, such as "on sale", "deactivated", "hot selling", etc., supporting quick filtering through combined conditions. For example, when querying for "packages that are on sale and priced below 200 yuan", the system first obtains all vertices of the "package" type, then filters the vertices with the "on sale" tag, and finally filters the vertices whose price attributes meet the conditions, greatly narrowing the search scope.

[0045] The relationship index layer builds sub-indexes according to relationship types, with each relationship type corresponding to a bidirectional adjacency list. The system has predefined common relationships in telecommunications business, such as "subscription", "containment", "dependency", etc. For the characteristics of the bidirectional graph, the system maintains both forward and reverse adjacency lists simultaneously, supporting efficient bidirectional traversal. For example, when querying "which packages are mutually exclusive with package P001", the system directly accesses the reverse list of the "mutually exclusive" relationship index without traversing all customer vertices.

[0046] The path index layer pre-computes and stores frequently accessed paths. The system analyzes historical operation logs to identify the TOP-N frequently queried paths, such as "customer → main package → optional package", "package → dependent product → functional product", etc. Each path records the vertex sequence and the relationship type sequence. When querying, it preferentially matches the pre-computed paths to avoid real-time full-graph traversal. The system will regularly update the path weights and dynamically adjust the cached path set, reducing the query response time from 100 milliseconds to 30 milliseconds.

[0047] As Figure 7 shown, the system supports dynamic updates of the customer relationship graph. The left side shows the customer relationship graph before modification, and the right side shows the modified state. Through the index linkage mechanism, the system can efficiently handle addition, deletion, and modification operations of instances. The addition, deletion, modification, and query operations are in real-time linkage with the index. When adding a vertex, the system adds the vertex to the corresponding index according to the type and tag; when adding an edge, the system records the edge information in the bidirectional adjacency list of the relationship index. When deleting a vertex, the system removes the vertex from all relevant indexes, simultaneously deletes all edges related to the vertex, and marks the paths containing the vertex as invalid. When modifying the vertex attributes, if the type or tag is involved in the change, the system will update the corresponding index group.

[0048] As Figure 8As shown, the query operation utilizes three - layer indexes to work together. When the system executes a query, it first obtains the query conditions from the scenario instance graph, then analyzes the association relationships through the customer - relationship instance graph (the query path is marked by the red arrow in the figure), and finally obtains the result data from the instance storage. Multiple relationship edges (such as Relationship 1, Relationship 2, etc.) are shown in the figure, demonstrating how the system optimizes the query efficiency through pre - calculated paths.

[0049] In this embodiment, the distributed consistency collaborative maintenance technology based on the graph change transaction log constructs a "local cache transaction - distributed graph log" double - loop synchronization system. As Figure 9 shown, the system realizes scenario isolation and local transaction closure. The upper part shows the vertices and relationships of Scenario S001, and the lower part shows the vertices and relationships of Scenario S002. Different business operations are isolated by the scenario ID to ensure that data does not interfere with each other. The distributed log center on the right records the status (success / failure) of each scenario and related graph change operations, including vertex addition / deletion and edge addition / deletion and other information. The local transaction closure ensures scenario atomicity, and the distributed log closure guarantees cross - node consistency. When a business operation triggers a graph change, the system first generates production and sales product vertices (such as Package M001, Option Package A001) in the local cache transaction container and establishes relevant relationship edges. The container records graph change operations (such as ADD_VERTEX, ADD_EDGE) in real - time, forming a transaction snapshot containing vertex attributes and bidirectional edge types. The system isolates transaction data by scenario dimension to avoid cross - scenario data pollution.

[0050] The graph transaction log structure includes customer identification, customer instance relationship graph, modified vertex information, deleted vertex information, deleted edge information, etc. The log entries clearly record the consistency constraints of bidirectional edges. For example, when adding a "dependency" edge, the operation of adding the reverse "dependent" edge is automatically recorded. The distributed collaboration protocol uses a lightweight consensus algorithm (such as a Raft variant) to synchronize the graph transaction log, ensuring that all distributed cache nodes execute the log instructions in order. After receiving the log, the node batch - executes graph change operations, reducing network interactions by 70% compared to traditional single - SQL operations. Finally, the system persists the vertex and relationship data corresponding to the log to the database and records the log ID for subsequent traceability.

[0051] As Figure 10As shown in the figure, the system implements a consistency guarantee mechanism for the entire order processing process. The left side shows multiple scenario instances (such as "Scenario S001-Customer M001 adds promotion A001", "Scenario S002-Main product P001 modifies customer S001", etc.), which are synchronized to the customer C001 instance relationship diagram in the middle through the distributed log center. The right side shows the content of the graph transaction log and the persistent storage process. The red mark in the figure is the relationship that has changed or expired. Taking customer A's order of "5G main package + video membership package" as an example, during the order submission stage, the local cache transaction container generates a scenario instance graph, including the "Scenario ID-123" vertex, the "5G package" vertex, and the "video membership package" vertex, and establishes related bidirectional edges. Before the order is successfully calculated, all changes only exist in the local cache transaction container and do not affect the distributed cache and database. If the calculation fails, the system directly rolls back the local transaction and the customer instance relationship graph remains unchanged. After the order is submitted successfully, the system serializes the locally stored vertex and edge operations into a graph transaction log. The local transaction container sends the log to the distributed log center. Each distributed cache node parses the log and updates the instance relationship graph of customer A in batches. The database persists the order information and records the graph transaction ID. If a system failure occurs after the order is submitted and needs to be rolled back, the distributed log center will mark the transaction as "failed". Each node restores the customer instance relationship graph according to the reverse operation in the log, and the local cache transaction container clears the residual data to ensure that the distributed cache and the database are eventually consistent.

[0052] The specific implementation of the cache transaction container uses thread local storage technology to isolate the changed data in the dimension of a single request. The container caches the modified scene instances, customer instance relationship diagram information, instance change information, etc. in the current transaction. The system marks the change type according to the instance operation type: add (A), delete (D), modify (M) or unmodified (K), and generates the corresponding instance change object. After the request thread is completed, if there is no exception, the system will update the changed data to the distributed cache at one time; if an exception occurs during the request process, the system will destroy the local cache instance and keep the distributed cache unchanged. Cache transaction control follows the ACID principle to ensure the integrity and consistency of data updates.

[0053] The entire system process from the business capability layer to the data persistence layer is as follows: The business capability layer receives customer operation requests, determines the instance operation type (add, delete, modify or query), and processes the request through the instance object management API. The instance object management API provides operations for adding, deleting, modifying and querying various instances and their relationships, such as scene instances, gift package instances, main package instances, optional package instances, promotional instances, main product instances, functional product instances, etc. The process data management layer uses the cache transaction container, scene instance container and customer instance relationship graph container to process requests, record change information, and ensure data consistency through the graph change transaction log. The data persistence layer persists the final results to the database and updates the distributed cache at the same time.

[0054] The present invention is applicable to various business scenarios of telecom operators, including management of hierarchical relationships between products and sales, linkage update of scenario instance diagrams and customer instance relationship diagrams, rapid retrieval of complex customer relationships in a high-concurrency environment, order processing and rollback under a distributed architecture, etc. The system supports order entry, preview, fee calculation, charging and submission operations for scenarios such as new installation of sales products, modification of sales products, modification of functional products, and modification of account customization relationships.

[0055] In actual application of a provincial telecommunications operator, compared with the traditional method, the system implemented by the present invention reduced the average query response time from 1.2 seconds to 0.3 seconds, increased the concurrent processing capacity during peak hours by 3 times, increased the efficiency of order processing failure rollback by 90%, achieved a hot data cache hit rate of more than 95%, and increased system resource utilization by about 40%, which greatly reduced hardware costs and provided telecommunications operators with an efficient and reliable customer relationship management solution.

[0056] The above specific implementations are only descriptions of the preferred implementations of the present invention, and do not limit the protection scope of the present invention. Without departing from the design concept and spirit of the present invention, various modifications, substitutions and improvements made by ordinary technicians in this field to the technical solution of the present invention based on the text description and drawings provided by the present invention should all fall within the protection scope of the present invention. The protection scope of the present invention is determined by the claims.

Claims

1. A method for storing and retrieving customer relationship information based on a bidirectional graph cache, characterized in that, It includes the following steps: Step S1: Construct a two-layer cache architecture based on graph structure perception, integrate the structural features of the bidirectional graph into the cache policy, and replace the traditional key-value pair cache with subgraph-level caching; Step S2: Construct an adaptive bidirectional graph index to support dynamic weight perception and efficient traversal of complex relationships; Step S3: Construct a distributed consistency collaborative maintenance mechanism based on graph change transaction logs to implement a "local cache transaction - distributed graph log" double-closed-loop synchronization system; Step S4: Receive the operation request of the customer instance information at the business capability layer and judge the instance operation type; Step S5: Perform addition, deletion, modification, and query operations on the customer instance information through the instance object management API at the process data management layer; Step S6: Record the changes in the customer instance information through the cache transaction container; Step S7: Ensure data consistency in the distributed environment through graph change transaction logs; Step S8: Persist the operation result to the database.

2. The method for storing and retrieving customer relationship information based on a bidirectional graph cache according to claim 1, characterized in that, The two-layer cache architecture based on graph structure perception includes: The local cache layer is used to store uninstantiated specification data, optimized for vertex association degree and relationship type, and adopts a double elimination strategy of "LRU + specification association degree"; The distributed cache layer uses subgraph-level serialization to store customer instance data, different from the traditional key-value pair method, and realizes the single-time acquisition of the complete subgraph; The instance data is stored in slices according to the customer dimension, and the instance data of each customer is stored as an independent subgraph, reducing the network overhead during cross-vertex retrieval.

3. The method for storing and retrieving customer relationship information based on a bidirectional graph cache according to claim 2, characterized in that, The two-layer cache architecture based on graph structure perception also includes a graph structure-aware dynamic warm-up strategy, specifically as follows: Identify the associated subgraphs of high-frequency specifications through the breadth-first search algorithm, and mark the strongly associated subgraphs as "hot factor graphs"; Predict the instance subgraph corresponding to the high-frequency operation scenario based on customer behavior; Preload the minimum necessary subgraphs according to the business scenario to reduce the real-time construction overhead.

4. The method for storing and retrieving customer relationship information based on a bidirectional graph cache according to claim 1, characterized in that, The adaptive bidirectional graph index includes the following three-layer index structure with dynamic weight perception ability: Vertex index layer: Establish a global hash index according to the instance type, supporting vertex positioning with an O(1) time complexity; Relationship index layer: For the characteristics of the bidirectional graph, maintain both the forward and reverse adjacency lists at the same time, supporting bidirectional efficient traversal; Path index layer: Pre-compute and cache the frequently accessed paths, reducing the query response time from the traditional 100ms to 30ms.

5. The method for storing and retrieving customer relationship information based on a bidirectional graph cache according to claim 4, characterized in that, The adaptive bidirectional graph index also includes a dynamic path optimization algorithm: Step S21: Based on the analysis of historical operation logs, extract and sort the Top-N path patterns with the highest access frequency; Step S22: Record the vertex sequence and relationship type sequence for each high-frequency path; Step S23: Construct a path index hash table, with the path pattern as the key and the pre-computed result as the value; Step S24: When querying, preferentially call the pre-computed path through pattern matching, and perform real-time traversal when not hit; Step S25: Dynamically adjust the set of pre-computed paths according to real-time access statistics, and regularly update the popular paths.

6. The method for storing and retrieving customer relationship information based on a bidirectional graph cache according to claim 1, characterized in that, The distributed consistency collaborative maintenance mechanism based on graph change transaction logs includes: Local Transaction Closed Loop: Used to capture graph change operations in the local cache transaction container, forming a transaction snapshot that includes vertex attributes and bidirectional edge types; Distributed Log Closed Loop: Used to construct a structured transaction log that includes bidirectional graph operation instructions and synchronize it to distributed nodes through a Raft variant lightweight consensus algorithm; Different from traditional distributed transactions, it is used to encapsulate the change operations of bidirectional graph vertices and edges into a graph transaction log to achieve atomicity guarantee for graph data.

7. The method for storing and retrieving customer relationship information based on a bidirectional graph cache according to claim 6, wherein, The structure of the graph transaction log includes a customer identifier, a bidirectional structure representation of the customer instance relationship graph, and an instance vertex mapping, where the instance vertex mapping includes vertex attributes and association relationships.

8. The method for storing and retrieving customer relationship information based on a bidirectional graph cache according to claim 6, wherein, The distributed consistency collaborative maintenance mechanism based on the graph change transaction log includes ensuring the consistency of the entire order processing process: In the order submission stage, the changes only exist in the local cache transaction container, achieving scenario-level isolation; When the order submission is successful, by batch executing graph change operations, it reduces network interactions compared to traditional single operations; The batch processing mechanism includes: merging multiple vertex and edge changes of the same customer into a single transaction package; packing and processing vertex group changes with high correlation; optimizing the execution order according to topological sorting to ensure the correctness of the dependency relationship; executing multiple graph operation instructions through a single network transmission; In the order rollback scenario, reverse operations are executed based on the graph transaction log, and the rollback efficiency is increased by more than 90%.

9. The method for storing and retrieving customer relationship information based on a bidirectional graph cache according to claim 1, wherein, The operation steps of the cache transaction container include: Step S61: Isolate the changed data by request dimension to ensure transaction atomicity; Step S62: Distinguish the ActionType type and record the graph change operation; Step S63: Implement request-level transaction control to ensure the consistency of distributed cache data in case of exceptions.

10. A system for storing and retrieving customer relationship information based on a bidirectional graph cache, applicable to the method for storing and retrieving customer relationship information based on a bidirectional graph cache according to claims 1-9, wherein, The system includes: View Layer: As the part of the system directly facing users, it is responsible for presenting data to users in a visual way, receiving user input and operations, and passing the operations to the business capability layer; External API Layer: Provides standardized interfaces and related auxiliary classes externally to ensure seamless integration and interoperability between different systems; Common Facilities Layer: Provides shared code blocks, libraries, frameworks, and services for multiple applications or services within the system, reducing duplicate development; Business Capability Layer: Responsible for defining and implementing the specific business capabilities of the system and handling business logic; Process Data Management Layer: The core layer of the system, including: a) Scenario Instance Container: Caches all instance object information to be submitted in the current scenario, including changes in scenario instances, relationship changes, and attribute changes; b) Cache Transaction Container: Responsible for caching the cache information that needs to be submitted when operating on customer instance information and controlling the atomicity of cache transactions; c) Customer Instance Relationship Graph Container: Responsible for caching the instance change information of the customers associated with the current scenario and maintaining the integrity of the customer instance relationship graph; d) Instance Change Information Container: Generates corresponding instance change objects according to the instance operation type; Data Persistence Layer: Handles code related to database operations; Infrastructure Layer: Provides basic support for the entire system; among them, The business capability layer realizes business functions by calling the instance object management API of the process data management layer; The process data management layer interacts with the distributed cache in the infrastructure layer through a distributed consistency collaborative maintenance technology based on graph change transaction logs; The data persistence layer loads database data into the distributed cache and the local cache through a two-layer cache architecture and data preheating technology based on graph structure awareness, providing a basic data relationship structure for the vertices and edges of the customer relationship graph.

Images