Method and system for storing and retrieving customer relationship information based on bidirectional graph cache

Abstract

The present invention provides a method and system for storing and retrieving customer relationship information based on a bidirectional graph cache. The method includes: constructing a two-tiered cache architecture based on graph structure awareness, incorporating the structural characteristics of the bidirectional graph into the cache strategy, and replacing traditional key-value pair caches with subgraph-level caches; constructing an adaptive bidirectional graph index; establishing a distributed consistency collaborative maintenance mechanism based on graph change transaction logs; receiving operation requests for customer instance information at the business capability layer and determining the instance operation type; executing add, delete, modify, and query operations on customer instance information at the process data management layer through the instance object management API; recording changes to customer instance information through a cache transaction container; and persisting the operation results to a database. This invention significantly improves the real-time computing capabilities for rapidly responding to customer inquiries and orders, greatly improving the end-user experience. It also supports multi-level business scenarios that operate on customer relationship data simultaneously, increasing the flexibility and efficiency of business processing.

Description

Technical Field

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

[0002] As telecom operators' businesses expand in scale and complexity, customer relationship information is exploding. Traditional relational databases and simple caching technologies face increasing challenges. In high-concurrency, high-frequency access environments, especially those involving complex customer relationship networks, problems such as slow system response, difficulty ensuring data consistency, and excessive resource consumption are becoming increasingly prominent.

[0003] The characteristics of telecommunications services dictate that customer data possesses complex, multi-layered, and multi-dimensional relationships, such as nested relationships between customers, sales items, and products. Effective management of this type of data is crucial for improving business processing efficiency. Traditional key-value caching approaches require multiple network interactions to process this type of relational data, resulting in inefficient queries. Furthermore, the distinct characteristics of specification data (such as sales items and product templates) and instance data (specific instances of customer orders) pose challenges to data storage and access strategies. While the former is relatively stable but frequently accessed, the latter changes frequently and needs to be shared in a distributed environment. A unified caching strategy struggles to meet the diverse needs of these two data types. Data consistency is particularly problematic in distributed system architectures. Conventional distributed cache synchronization mechanisms can easily lead to data inconsistencies in high-concurrency scenarios, impacting the accuracy and reliability of business processing. Furthermore, exceptions during order processing (such as system failures and business rollbacks) place higher demands on distributed cache transaction management.

[0004] The application layer architecture specifications for China Telecom's next-generation BSS3.0 customer relationship management system clearly state that the system architecture should support low-cost elastic expansion and emphasize comprehensive management of customer information and efficient query and modification capabilities. In recent years, graph database technology has garnered widespread attention for its intuitive representation of complex relationships between entities, and advanced caching technologies have shown great potential in improving data access speed. However, existing technologies still lack the ability to deeply integrate graph structures with caching strategies, support efficient retrieval of dynamic relationship networks, and ensure cached data consistency in distributed environments. This has led to an urgent need for innovative solutions to address these issues in the telecommunications customer relationship management field.

[0005] As business demands continue to grow, customers are demanding faster service responses. Achieving millisecond-level data retrieval and processing within complex networks has become a key factor in improving customer satisfaction and market competitiveness. While the industry has begun exploring technical approaches that combine graph-structured data models, multi-tiered caching architectures, and distributed consistency protocols, practical applications still face numerous challenges, particularly in large-scale, highly concurrent, and complex business scenarios like telecommunications. Summary of the Invention

[0006] To overcome the shortcomings of existing technologies, this paper proposes a method and system for storing and retrieving customer relationship information based on a bidirectional graph cache. This method, for the first time, deeply integrates bidirectional graph features into caching, indexing, and transaction management, achieving a layered optimization architecture characterized by "localized acceleration of specification data and distributed sharing of instance data." Through the synergistic effects of a graph-structure-aware two-tier cache architecture, data pre-warming, adaptive bidirectional graph indexing, and dynamic relationship traversal optimization, this approach provides a next-generation relational data processing solution for telecom BSS systems, significantly reducing system operation and maintenance costs and driving the development of telecom customer relationship management systems towards greater efficiency and stability.

[0007] To achieve the above objectives, the present invention proposes a method for improving the storage and retrieval efficiency of complex customer relationship information based on bidirectional graph caching technology, comprising the following steps:

[0008] A two-tiered cache architecture based on graph structure awareness is built. Different from traditional key-value caches, this architecture incorporates the structural characteristics of bidirectional graphs into its caching strategy, reducing network overhead during cross-vertex retrieval through subgraph-level caching. Bidirectional graph structural characteristics include vertex association, relationship type, access frequency, and business attributes.

[0009] Building an adaptive bidirectional graph index. Different from traditional graph traversal technology, this approach uses a hierarchical indexing mechanism and a dynamic path optimization algorithm to address performance bottlenecks in complex relational operations in high-concurrency scenarios, achieving adaptability and efficiency in adding, deleting, modifying, and querying graph data.

[0010] A distributed consistency collaborative maintenance mechanism based on the graph change transaction log is built. Different from traditional distributed transactions, this mechanism uses the graph transaction log and cache layer collaborative control mechanism to implement a dual closed-loop synchronization system of "local cache transactions-distributed graph logs", ensuring update consistency and performance balance for complex customer instance relationships in a distributed environment.

[0011] Receive the customer's instance information operation request at the business capability layer and determine whether the instance operation type is instance addition, instance deletion, instance modification, or instance query;

[0012] At the process data management level, the instance object management API is used to perform add, delete, modify, and query operations on customer instance information. Instance addition, deletion, and modification are implemented through the instance operation class, and instance query is implemented through the instance query class.

[0013] Record changes in customer instance information through the cache transaction container, including the modified scenario instance container in the current cache transaction, the information container related to the customer instance relationship diagram, scenario instance change information, deleted instances, and modified instance attribute field names;

[0014] Ensure data consistency in a distributed environment through graph change transaction logs. When distributed cache data is updated, the corresponding change records are stored in the database.

[0015] The operation results are persisted to the database to complete the process of adding, deleting, modifying and querying customer instance information.

[0016] Furthermore, the two-layer cache architecture based on graph structure perception includes:

[0017] Local cache layer: Stores uninstantiated specification data, optimizes vertex association and relationship type, and stores data by specification type (product, sales item, relationship rule). For example, all package templates under "sales item specifications" (such as the "199 yuan 5G package" specification) are cached in the same subset.

[0018] Distributed cache layer: This layer uses subgraph-level serialization to store customer instance data. Unlike traditional key-value pair methods, this layer uses graph structures (adjacency lists / adjacency matrices) for serialized storage, enabling single-shot retrieval of the entire subgraph and avoiding multiple network I / O operations during cross-vertex retrieval.

[0019] Instance data is stored in shards based on the customer dimension. Each customer's instance data is stored 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.

[0020] At the local cache layer, a dual elimination strategy of "least recently used (LRU) + specification relevance" is adopted. Specification data that has not been used for a long time (such as specifications of unpopular packages) is eliminated first, and the cache time of highly relevant specifications (such as common relationship rules referenced by multiple instances) is extended.

[0021] At the distributed cache layer, distributed consistency protocols (such as the Redis Cluster sharding mechanism) are used to ensure cross-node data synchronization. This allows sales staff to use the distributed cache as the sole data source when operating the same customer instance, avoiding local cache inconsistencies.

[0022] Furthermore, the graph structure-aware two-layer cache architecture also includes a graph structure-aware dynamic warm-up strategy:

[0023] For specification data preheating: Use the breadth-first search (BFS) algorithm to identify subgraphs related to frequently used specifications. For example, if the access path "Hot-selling package specifications → General discount specifications → Main product specifications" accounts for 40%, mark this subgraph as a "hot factor graph."

[0024] Load the historical TOP100 highly correlated specification subgraphs at system startup and preload them into local memory to reduce repeated database queries;

[0025] After a specification is updated, all sub-graphs associated with the updated specification are automatically loaded. For example, after modifying a "general discount promotion", all associated package specifications are loaded synchronously.

[0026] For instance data preheating: Based on the customer's historical order data, predict the instance subgraph corresponding to the high-frequency operation scenario. For example, if a customer frequently applies for "package upgrades", preload the customer's "main package instance → main product instance → promotion instance" subgraph;

[0027] Analyze common instance relationship chains by business scenarios (such as "New Package Installation" and "Service Suspension Number Retention") and preload the minimum subgraph required for the scenario. For example, for the "New Package Installation" scenario, preload the package vertex, rate vertex, account customization relationship vertex, and their associated edges to reduce real-time construction overhead.

[0028] Furthermore, the adaptive bidirectional graph index includes the following three-layer index structure with dynamic weight perception capability:

[0029] Vertex index layer: A global hash index is established by instance type, supporting vertex positioning with O(1) time complexity. For example, when querying "all package instances associated with customer A", the candidate vertex set is directly obtained from the "package" type index; business tags are added to vertices (such as "order", "modify", and "delete"), and fast filtering is performed through combined conditions. For example, when searching for "packages on sale with a price less than 200 yuan", only vertices with corresponding tags are traversed, narrowing the search range by 80%;

[0030] Relationship index layer: Sub-indexes are created based on edge relationship types ("order," "include," and "depends"), and edges of each type are stored as bidirectional adjacency lists. Taking into account the characteristics of bidirectional graphs, both forward (u→v) and reverse (v→u) adjacency lists are maintained, supporting fast bidirectional traversal. For example, when querying "Which package is mutually exclusive with package P001?", the reverse list of the "order" relationship index is directly accessed without traversing all customer vertices.

[0031] Path indexing layer: By analyzing historical operation logs, the top-N frequently accessed paths (such as "customer → main package → optional package" and "package → dependent product → functional product") are pre-calculated and stored. Each path records the vertex sequence and relationship type sequence. Pre-calculated paths are prioritized during queries to avoid real-time full-graph traversal, reducing response time from 100ms to 30ms.

[0032] Furthermore, the adaptive bidirectional graph index also includes a dynamic path optimization algorithm:

[0033] Based on historical operation log analysis, extract and sort the top-N most frequently accessed path patterns, such as "customer → popular package → main product" as a pre-calculated path;

[0034] For each high-frequency path, record the vertex sequence and relationship type sequence, for example: [Customer C001, Order, Package P001, Includes, Optional Package A001];

[0035] Build a path index hash table with path patterns as keys and pre-calculated results as values, supporting fast query matching;

[0036] Path weight calculation: Path access frequency, path length, and last access time are used as weight factors, and the path importance score is updated regularly;

[0037] Adaptive path update: Dynamically adjust the pre-computed path set based on real-time access statistics, automatically add hot paths to the index, and automatically remove unpopular paths;

[0038] When querying, the pre-calculated path is called first through pattern matching, and real-time traversal is performed if there is no hit, thus optimizing query performance.

[0039] Furthermore, the distributed consistency collaborative maintenance mechanism based on the graph change transaction log includes:

[0040] Local transaction closed loop: Generate product vertices (package M001, optional package A001) in the local cache transaction container, and establish scenario instance relationships (association between order scenario S001 and package / optional package) and customer instance relationships (bidirectional "order" edge between customer C001 and package M001).

[0041] Transaction snapshot capture: The container records graph change operations (ADD_VERTEX, ADD_EDGE) in real time, generating transaction snapshots that include vertex attributes (such as package specifications and prices) and bidirectional edge types (order / ordered, include / be included).

[0042] Order scenario adaptation: For scenarios such as "new product packaging" and "package modification," the container isolates transaction data by scenario dimension to avoid cross-scenario data contamination.

[0043] Graph transaction log generation: Serializes locally stored vertex and edge operations into a graph transaction log, which contains details of all graph changes involved in the order.

[0044] Distributed log closed loop: Build a structured transaction log containing bidirectional graph operation instructions, use a lightweight consensus algorithm (such as Raft variants) to synchronize the graph transaction log, and ensure that all distributed cache nodes execute log instructions in sequence;

[0045] Batch execution: After receiving the log, the node executes the graph change operations in sequence, reducing network interactions by 70% compared to traditional single operations.

[0046] Persistent storage: Write the vertex and relationship data corresponding to the log into the database, and record the log ID for subsequent tracing.

[0047] Furthermore, the structure of the graph transaction log includes:

[0048] Customer ID: uniquely identifies the customer associated with the transaction and is used for shard routing;

[0049] Customer instance relationship graph: contains instance vertex mapping, which includes vertex ID, parent edge connected to the vertex, child edge connected to the vertex, start ID, end ID, instance ID, instance type, and action type;

[0050] Modified vertex information: records all changed vertex attributes and old and new values;

[0051] Deleted vertex information: contains a complete snapshot of deleted vertices for rollback;

[0052] Deleted edge information: includes source instance ID, source instance type, target instance ID, target instance type, action type, and relationship type;

[0053] Reverse operation list: records the operation sequence for rollback, which is opposite to the forward operation sequence;

[0054] The log explicitly records the consistency constraints of bidirectional edges, such as automatically recording the addition of the reverse "ordered" edge when adding an "ordering" edge.

[0055] Furthermore, the distributed consistency collaborative maintenance mechanism based on the graph change transaction log includes the following aspects:

[0056] During the order submission phase, the local cache transaction container generates a scenario instance graph related to the order, including the "Scenario ID-123" vertex, the "5G Package" vertex, and the "Video Membership Package" vertex. Bidirectional edges are established: "Customer A → 5G Package" (order relationship), "5G Package → Video Membership Package" (dependency relationship), and their reverse edges. Before the order is successfully calculated, all changes exist only in the local cache transaction container and do not affect the distributed cache or database. If the calculation fails, the local transaction is rolled back directly, and the customer instance relationship graph remains unchanged.

[0057] Upon successful order submission, the locally stored vertex and edge operations are serialized 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 batch updates customer A's instance relationship graph (adding vertices and bidirectional edges). The database persists the order information and records the graph transaction ID to trace the change history.

[0058] Batch processing mechanism: merge multiple vertex and edge changes for the same customer into a single transaction package; process changes to groups of highly correlated vertices in a batch; optimize execution order based on topological sorting to ensure dependency correctness; execute multiple graph operations through a single network transmission;

[0059] Order rollback scenario: The distributed log center marks the transaction as "failed," and each node restores the customer instance relationship graph based on reverse operations in the log (such as "DELETE_VERTEX" and "DELETE_EDGE"). The local cache transaction container clears residual data to ensure eventual consistency between the distributed cache and the database. For example, the unsuccessful video membership package is removed from Customer A's package list.

[0060] Furthermore, the operation steps of the cache transaction container include:

[0061] The instance data that needs to be put into the distributed cache is first stored in the local application vertex based on the dimension of a single request. After the request thread is completed, if there is no exception, the changed instance data is updated to the distributed cache at once;

[0062] Cache the modified scenario instance containers, customer instance relationship diagram-related information containers, 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 in the current cache transaction;

[0063] If an exception occurs during the request, the local cache instance for the request will be destroyed, and the distributed cache will remain unchanged, ensuring data consistency.

[0064] Mark the change type according to the instance operation type, including: Add - ActionType=A, Delete - ActionType=D, Modify - ActionType=M, and Unmodify - ActionType=K;

[0065] Generate instance change objects of the corresponding type based on the change type, which serve as the calculation basis for the incoming data generated by the final order;

[0066] The integrity and consistency of data updates are ensured through the ACID (atomicity, consistency, isolation, and durability) principle. If any step in the scene change information transaction fails, the entire transaction will be rolled back to ensure that the data in the database and cache will not be in an inconsistent state.

[0067] Furthermore, the application scenarios of the method in the customer relationship management system of telecom operators include:

[0068] Management of product-sales hierarchical relationships: This system handles multi-level instance changes in sales items, products, and functions, supporting complex associations between specification data (such as sales items, products, and sales item relationships) and instance data (such as specific packages and functional products ordered by customers) in telecommunications services.

[0069] Linked updates of the scenario instance graph and the customer instance relationship graph: This ensures data consistency across scenarios during order processing. For example, in the "package modification" scenario, both the customer relationship graph and the scenario instance graph are updated simultaneously.

[0070] Rapid retrieval of complex customer instance relationships in a high-concurrency environment: Supports order entry, order preview, order calculation, order charging, and order submission operations for scenarios such as new product installation, product modification, product function change, and account customization relationship change;

[0071] Order processing and rollback in a distributed architecture: For example, when customer A orders a "5G main package + video membership package," the local cache transaction container generates a scenario instance graph containing the "Scenario ID-123" vertex, the "5G package" vertex, and the "video membership package" vertex. It also establishes the "Customer A → 5G package" (order relationship), the "5G package → video membership package" (dependency relationship), and their reverse edges to ensure the consistency of customer relationship data.

[0072] The business functions supported by complex customer instance relationships include: locating customers, querying sales products, order entry in various scenarios, order preview, order calculation, order charging, order submission, etc., and providing scenario instances, gift package instances, main package instances, optional package instances, promotion instances, main product instances, functional product instances, terminal product instances, account instances and other instances through the instance object management API, as well as the addition, deletion, modification and query operations of instance relationships.

[0073] A system for storing and retrieving customer relationship information based on a bidirectional graph cache is applicable to the above-mentioned method for storing and retrieving customer relationship information based on a bidirectional graph cache, and is characterized in that the system includes:

[0074] View layer: As the part of the system that directly faces 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;

[0075] External API layer: provides standardized interfaces and related auxiliary classes to ensure seamless integration and interoperability between different systems;

[0076] Public facilities layer: provides shared code blocks, libraries, frameworks, and services for use by multiple applications or services within the system, reducing duplication of development;

[0077] Business capability layer: responsible for defining and implementing the system's specific business capabilities, processing business logic, and providing functions such as locating customers, querying sales products, and order entry, previewing, calculating fees, charging, and submitting orders in various scenarios;

[0078] Process data management layer: The core layer of the system, which implements three core technologies through the following components:

[0079] a) Scene instance container: caches all instance object information that needs to be submitted for the current scene, including changes to scene instances, relationship changes, and attribute changes;

[0080] b) Cache transaction container: responsible for caching the cache information that needs to be submitted when operating customer instance information, and controlling the atomicity of cache transactions;

[0081] c) Customer instance relationship graph container: responsible for caching instance change information of customers associated with the current scenario and maintaining the integrity of the customer instance relationship graph;

[0082] d) Instance change information container: generates corresponding instance change objects according to the instance operation type;

[0083] Data persistence layer: processes codes related to database operations, including data access objects, SQL statements, and connection pool management;

[0084] Infrastructure layer: provides basic support for the entire system, including distributed cache, database, network communication and storage management; the business capability layer implements 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 distributed consistency collaborative maintenance technology based on graph change transaction logs; the data persistence layer loads database data into the distributed cache and local cache through a two-layer cache architecture and data preheating technology based on graph structure perception, providing a basic data relationship structure for the vertices and edges of the customer relationship graph.

[0085] Compared with the prior art, the present invention has the following beneficial effects:

[0086] 1. This invention provides a method and system for storing and retrieving customer relationship information based on a bidirectional graph cache. This system improves transaction capacity by 200%, increases operational efficiency in complex scenarios by over 1.5 times, and supports high-concurrency, real-time processing of tens of millions of customer instances. Query processing efficiency is increased by 30%, traversal efficiency by 70%, and response time for high-frequency traversals is optimized to less than 100ms, effectively addressing the performance bottlenecks of traditional relational databases when processing complex customer relationship information.

[0087] 2. This invention provides a method and system for storing and retrieving customer relationship information based on a bidirectional graph cache. This significantly accelerates service response time, reducing the time it takes to launch small and medium-sized scenarios from the traditional 5-7 days to 2-3 days, and compressing customer order processing time to under 3 minutes. Rapid responses to customer inquiries and real-time order computing capabilities are significantly enhanced, significantly improving the end-user experience. It also supports simultaneous manipulation of customer relationship data across multiple business scenarios, increasing the flexibility and efficiency of business processing.

[0088] 3. This invention provides a method and system for storing and retrieving customer relationship information based on a bidirectional graph cache. This system utilizes distributed consistency collaborative maintenance technology using a graph change transaction log, achieving 95% data consistency and improving rollback efficiency by 90%. This technology also improves rollback efficiency for failed order processing by over 90%. This technology ensures atomic changes to product-seller relationships during order processing, significantly reducing the risk of data inconsistency and ensuring data accuracy and consistency in high-concurrency environments, providing a reliable data foundation for business systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0089] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the specific embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0090] Figure 1 It is a schematic diagram of the system architecture of the present invention;

[0091] Figure 2 It is a flowchart of steps;

[0092] Figure 3 This is a system architecture diagram that shows the system's multi-layer architecture and dynamic data preheating strategy;

[0093] Figure 4 Schematic diagram of the relationship between specification data and instance data;

[0094] Figure 5 This is a comparison diagram of subgraph-level caching and traditional key-value pair caching;

[0095] Figure 6 It is the data organization method, including sales product instance diagram, customer relationship instance diagram and actual storage structure diagram;

[0096] Figure 7 It is a dynamically updated diagram of the customer relationship graph;

[0097] Figure 8 This is an example of the query operation process, showing a query path diagram;

[0098] Figure 9 This is a schematic diagram of scenario isolation and local transaction closed loop;

[0099] Figure 10 This is a schematic diagram of the consistency assurance mechanism for the entire order processing process. DETAILED DESCRIPTION

[0100] The technical solutions of the present invention will be more clearly and completely explained below through description of preferred embodiments of the present invention in conjunction with the accompanying drawings.

[0101] Explanation of terms:

[0102] Graph: In mathematics, a graph is a structure that describes a set of objects, some of which are "related" in some sense. These objects correspond to mathematical abstractions called vertices (also called nodes or points), and each related pair of vertices is called an edge (also called a link or line). Graphs are typically depicted diagrammatically as a set of points or rings called vertices, connected by lines or curves called edges.

[0103] Bidirectional graphs: Bidirectional graphs are a special graph structure in which every edge has two directions. That is, for any two vertices u and v, if there is an edge from u to v, there must also be an edge from v to u. This structure gives bidirectional graphs significant advantages in representing and processing symmetric relationships. For example, in customer relationship management, bidirectional relationships between customers can be intuitively represented and efficiently queried using bidirectional graphs. This property of bidirectional graphs enables them to support both forward and reverse traversal when processing complex relationship networks, thereby improving retrieval efficiency and flexibility.

[0104] Specification data, also known as "specifications," is a set of data agreed upon by telecom companies, with attributes and pricing, shared across the entire telecom network. Examples include products, sales items, and relationships between sales items. Specification data logically precedes instance data and serves as the basis for its generation. Specification data is the "predecessor" of instance data.

[0105] Instance data, abbreviated as "instance," is a vertex in the graph, and the relationships between instances are edges. It represents the data generated by a specific business transaction. Each piece of data is unique and unique to a customer, not shared with others. Each customer's business transaction (such as subscribing to a 5G plan or adding new features) will have multiple instances and multiple instance relationships in the customer instance relationship graph and scenario instance relationship graph.

[0106] Customer Relationship Graph: A customer relationship graph is a bidirectional graph-based structure centered around a customer, recording all instances associated with that customer (such as sales item instances and product instances) and their relationships. It represents instances using vertices and relationships between instances using edges. It supports bidirectional traversal and efficiently queries and manages complex customer-related relationship networks. It is suitable for comprehensive management and analysis of customer businesses. All scenario instances for the same customer share a single customer instance relationship graph.

[0107] Scenarios: In this patent, scenarios are defined to encapsulate complex business logic into an independent processing module. Each scenario covers the entire lifecycle, from customer request initiation to system completion, facilitating system management and optimization. For example, in telecommunications services, a "sales new product" scenario might include multiple steps, such as customer location, package selection, order entry, charge confirmation, and order submission. Together, these steps constitute a complete business scenario.

[0108] Scenario Instance Graph: A scenario instance graph is a graph model built for specific business scenarios. It records basic scenario information, including all instance vertices and their relationships. Based on business scenarios, it supports scenario-level business operations and data management, facilitating efficient business processing and data retrieval. For example, in scenarios such as product repackaging and product modification, the roles and relationships of each instance are clearly displayed.

[0109] Distributed cache: A cache system deployed across multiple nodes, enabling data sharing through network connections, providing greater storage capacity and high availability. In this patent, it is primarily used to store specification data and instance data, supporting data sharing and high-concurrency access. Instance data is primarily stored in the distributed cache to enable data sharing, as instance data changes frequently. In a distributed architecture, each application node needs to share a copy of instance data. Examples include customer relationship diagrams and scenario instance diagrams.

[0110] Local cache: A cache deployed in the application server or client's memory, offering fast access and low latency. In this patent, it is primarily used to store frequently accessed specification data, further improving data access speed.

[0111] Secondary cache: A two-tiered cache architecture combining distributed and local caches. In this patent, this is primarily used to store specification data, with the loading order being: database -> distributed cache -> local cache, hence the name "secondary cache." Since specification data changes infrequently, the secondary cache mechanism optimizes access efficiency.

[0112] like Figure 1 As shown, the system includes:

[0113] View layer: As the part of the system that directly faces 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;

[0114] External API layer: provides standardized interfaces and related auxiliary classes to ensure seamless integration and interoperability between different systems;

[0115] Public facilities layer: provides shared code blocks, libraries, frameworks, and services for use by multiple applications or services within the system, reducing duplication of development;

[0116] Business capability layer: responsible for defining and implementing the system's specific business capabilities, processing business logic, and providing functions such as locating customers, querying sales products, and order entry, previewing, calculating fees, charging, and submitting orders in various scenarios;

[0117] Process data management layer: The core layer of the system, which implements three core technologies through the following components:

[0118] a) Scene instance container: caches all instance object information that needs to be submitted for the current scene, including changes to scene instances, relationship changes, and attribute changes;

[0119] b) Cache transaction container: responsible for caching the cache information that needs to be submitted when operating customer instance information, and controlling the atomicity of cache transactions;

[0120] c) Customer instance relationship graph container: responsible for caching instance change information of customers associated with the current scenario and maintaining the integrity of the customer instance relationship graph;

[0121] d) Instance change information container: generates corresponding instance change objects according to the instance operation type;

[0122] Data persistence layer: processes codes related to database operations, including data access objects, SQL statements, and connection pool management;

[0123] Infrastructure layer: provides basic support for the entire system, including distributed cache, database, network communication and storage management; the business capability layer implements 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 distributed consistency collaborative maintenance technology based on graph change transaction logs; the data persistence layer loads database data into the distributed cache and local cache through a two-layer cache architecture and data preheating technology based on graph structure perception, providing a basic data relationship structure for the vertices and edges of the customer relationship graph.

[0124] A method based on bidirectional graph caching technology to improve the storage and retrieval efficiency of complex customer relationship information is mainly used in the process data management layer. Starting from the business capability layer, the addition, deletion, modification and query of instance data are in the process data management layer. The main process of this method is as follows: Figure 2 As shown:

[0125] Step S1: Build a two-layer cache architecture based on graph structure awareness, integrate the structural characteristics of the bidirectional graph into the cache strategy, and replace the traditional key-value pair cache with subgraph-level cache;

[0126] Step S2: Build an adaptive bidirectional graph index to support dynamic weight perception and efficient traversal of complex relationships;

[0127] Step S3: Build a distributed consistency collaborative maintenance mechanism based on the graph change transaction log to implement a dual closed-loop synchronization system of "local cache transaction-distributed graph log";

[0128] Step S4: receiving the operation request of the customer instance information at the business capability layer and determining the instance operation type;

[0129] 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;

[0130] Step S6: Record changes in customer instance information through the cache transaction container;

[0131] Step S7: Ensure data consistency in a distributed environment through graph change transaction logs;

[0132] Step S8: Persist the operation result in the database.

[0133] As a specific embodiment of the present invention, it is applied to a telecom operator's customer relationship management system. In this embodiment, 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 utility layer, an external API layer, and a view layer. The core technology of the present invention lies primarily in the process data management layer, which effectively addresses the core challenges of telecom customer relationship management by implementing three key technological innovations.

[0134] like Figure 3 As shown in the figure, the system adopts a multi-layered architecture. The left side displays business function modules, the upper middle section shows the dynamic data pre-warming strategy and the relationship network of the specification layer, and the lower middle section shows the distributed cache structure, which illustrates the data flow path from the specification layer to the instance layer. The system supports business functions (such as "New Product Installation" and "Product Modification") through dynamic data pre-warming strategies, achieving efficient data access and processing.

[0135] In a specific hardware environment, this system is deployed on a telecommunications business hall network, comprising several application servers, cache servers, and database servers. The infrastructure layer utilizes a distributed cache cluster and database cluster. The data persistence layer is responsible for data access and mapping. The process data management layer implements core business logic. The business capability layer provides specific business functions such as package processing and customer inquiries.

[0136] In this embodiment, the specific implementation of the two-layer cache architecture based on graph structure perception is as follows: Figure 4As shown, the system is divided into two layers: the specification layer and the instance layer. The specification layer primarily stores frequently accessed specification data and uses dynamic data pre-warming technology to load the top 100 most relevant specifications. The instance layer includes gift package instances, package instances, promotional instances, and product instances, and uses order analysis to predict and pre-warm instance data. The local cache layer uses in-memory caching technology to store uninstantiated specification data. Specification data is grouped and stored by type. For example, product specifications, sales item specifications, and relationship rules are stored in separate cache partitions. Each specification object contains basic attributes and metadata. For example, the "199 yuan 5G package" specification includes attributes such as price, data traffic, and call duration, as well as compatibility rules with optional services. The system identifies frequently used specifications based on historical access logs and prioritizes loading them into the local cache to improve hit rates. Cache eviction utilizes a dual strategy of "LRU + specification relevance," prioritizing long-unused specification data (such as discontinued packages) and extending the cache life of highly relevant specifications (such as basic package rules).

[0137] like Figure 5 As shown, the subgraph-level cache of the present invention is significantly different from the traditional key-value cache. The traditional key-value cache uses a single instance ID as the key to store the value, while the present invention stores it in the form of source point + subgraph (such as CustomerID:Subgraph); the traditional method requires multiple reads of the vertex-adjacent relationship (requiring N network IO), while the present invention obtains the entire subgraph in a single pass (1 network IO); the traditional method does not utilize the graph structure and only accesses simple data, while the present invention supports graph access and access, and supports graph operation functions; in terms of complex query efficiency, the traditional method averages about 800ms (when N=5 network accesses), while the present invention averages about 500ms (speed increased by 37.5%, network overhead reduced); in terms of preheating strategy, the traditional method is based on random access to the same database, while the present invention is based on the preheating function loading of the correlation degree.

[0138] The distributed cache layer stores instance data, sharded by customer. For each customer, the system stores all relevant instance data (vertices and edges) as a complete subgraph. The subgraph is serialized using an adjacency list structure. Vertices contain instance IDs, types, and attribute sets, while edges contain source and destination vertex IDs, relationship types, and attribute sets. This subgraph-level serialized storage allows the system to retrieve the complete customer relationship graph in a single network request, significantly reducing the overhead of multiple network interactions required by traditional key-value storage methods.

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

[0140] Dynamic data pre-warming strategies are implemented separately for specification data and instance data. For specification data, the system loads the top 100 most highly correlated specification subgraphs at startup. Using a breadth-first search algorithm, the system analyzes the relationships between specifications and identifies frequently accessed sets of specifications. For example, if the access path "Hot-selling Package Specifications → General Discount Specifications → Main Product Specifications" accounts for 40%, this subgraph is marked as a "hot factor graph" and loaded first. When specifications are updated, the system automatically loads the affected related specifications. For instance data, the system predicts high-frequency operation scenarios based on historical customer behavior. For example, if a customer frequently upgrades a package, the system pre-loads the "Main Package Instance → Main Product Instance → Promotional Instance" subgraph for that customer. The system also pre-loads relevant data based on business scenarios. For example, for a "New Package Installation" scenario, the system pre-loads package vertices, price vertices, and account customization relationship vertices and their associated edges.

[0141] 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 establishes a global hash index based on the instance type, supporting O(1) time to locate all vertices of a specific type. The system predefines common telecommunications business entity types, such as "customer", "package", "optional package", etc. Each vertex is also accompanied by a business label, such as "on sale", "disabled", "hot selling", etc., supporting fast filtering by combined conditions. For example, when querying "packages on sale with a price lower than 200 yuan", the system first obtains all vertices of the "package" type, then filters the vertices with the "on sale" label, and finally filters the vertices whose price attributes meet the conditions, greatly narrowing the search scope.

[0142] The relationship index layer establishes sub-indexes based on relationship type, with each relationship type corresponding to a bidirectional adjacency list. The system predefines common relationships in telecommunications services, such as "subscription," "include," and "dependency." To address the characteristics of bidirectional graphs, the system maintains both forward and reverse adjacency lists, 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, eliminating the need to traverse all customer vertices.

[0143] The path indexing layer precomputes and stores frequently accessed paths. By analyzing historical operation logs, the system identifies the top-N most frequently accessed paths, such as "customer → main package → optional package" and "package → dependent product → feature product." Each path records the vertex sequence and relationship type sequence, prioritizing precomputed paths during queries to avoid full-graph traversal in real time. The system regularly updates path weights and dynamically adjusts the cached path set, reducing query response times from 100 milliseconds to 30 milliseconds.

[0144] like Figure 7 As 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 status after modification. Through the index linkage mechanism, the system can efficiently handle the add, delete, and modify operations of instances. Add, delete, modify, and query operations are linked to the index in real time. When adding a vertex, the system adds the vertex to the corresponding index by type and label; 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 related indexes, deletes all edges related to the vertex, and marks the path containing the vertex as invalid. When modifying vertex attributes, if the type or label changes are involved, the system will update the corresponding index grouping.

[0145] like Figure 8 As shown in the figure, query operations utilize three layers of indexes working together. When executing a query, the system first obtains query conditions from the scenario instance graph, then analyzes the associated relationships using the customer relationship instance graph (the red arrow in the figure indicates the query path), and finally retrieves the result data from the instance store. The figure shows multiple relationship edges (such as Relationship 1, Relationship 2, etc.), demonstrating how the system optimizes query efficiency by pre-calculating paths.

[0146] The distributed consistency collaborative maintenance technology based on the graph change transaction log builds a "local cache transaction-distributed graph log" dual closed-loop synchronization system in this implementation. Figure 9 As shown in the figure, the system implements scenario isolation and local transaction closure. The upper part shows the vertex and relationship structure of scenario S001, while the lower part shows the vertex and relationship structure of scenario S002. Scenario IDs isolate different business operations to prevent data interference. The distributed log center on the right records the status of each scenario (success / failure) and related graph change operations, including vertex addition / deletion and edge addition / deletion. Local transaction closure ensures scenario atomicity, while distributed log closure guarantees cross-node consistency. When a business operation triggers a graph change, the system first generates product vertices (e.g., package M001, optional package A001) in the local cache transaction container and establishes related relationship edges. The container records graph change operations (e.g., ADD_VERTEX and ADD_EDGE) in real time, generating transaction snapshots that include vertex attributes and bidirectional edge types. The system isolates transaction data by scenario dimension to prevent cross-scenario data contamination.

[0147] The graph transaction log structure includes the customer identifier, the customer instance relationship graph, modified vertex information, deleted vertex information, deleted edge information, and more. Log entries explicitly record the consistency constraints of bidirectional edges. For example, when adding a "dependent" edge, the addition of the reverse "dependent" edge is automatically recorded. The distributed coordination protocol uses a lightweight consensus algorithm (such as a Raft variant) to synchronize the graph transaction log, ensuring that all distributed cache nodes execute log instructions in sequence. After receiving the log, the node executes the graph modification operations in batches, reducing network interactions by 70% compared to traditional single SQL operations. Finally, the system persists the vertex and relationship data corresponding to the log in the database and records the log ID for subsequent tracing.

[0148] like Figure 10 As shown in the figure, the system implements a consistency assurance mechanism for the entire order processing process. The left side shows multiple scenario instances (such as "Scenario S001 - Customer M001 adds promotion A001" and "Scenario S002 - Main product P001 modifies customer S001"), which are synchronized to the central customer C001 instance relationship graph via the distributed log center. The right side shows the contents of the graph transaction log and the persistence storage process. Relationships marked in red in the figure are modified or invalidated. For example, when customer A orders a "5G Main Package + Video Membership Package" order, during the order submission phase, the local cache transaction container generates a scenario instance graph containing vertices for "Scenario ID-123," "5G Package," and "Video Membership Package," and establishes related bidirectional edges. Before the order is successfully calculated, all changes exist only in the local cache transaction container and do not affect the distributed cache or database. If the calculation fails, the system rolls back the local transaction, leaving the customer instance relationship graph unchanged. After a successful order submission, the system serializes the locally stored vertex and edge operations into a graph transaction log. The local transaction container then sends the log to the distributed log center. Each distributed cache node parses the log and batch updates Customer A's instance relationship graph. The database persists the order information and records the graph transaction ID. If a system failure occurs after an order is submitted and a rollback is required, the distributed log center marks the transaction as "failed." Each node then restores the customer instance relationship graph based on the reverse operation in the log. The local cache transaction container then clears any remaining data, ensuring eventual consistency between the distributed cache and the database.

[0149] The specific implementation of the cache transaction container uses thread-local storage technology to isolate changed data based on a single request. The container caches scenario instances, customer instance relationship diagram information, instance change information, and other information that have been modified in the current transaction. The system marks the change type based on 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 are no exceptions, 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.

[0150] The entire system flow 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, including scenario instances, gift package instances, main package instances, optional package instances, promotional instances, main product instances, and feature product instances, as well as their relationships. The process data management layer utilizes a cache transaction container, a scenario instance container, and a customer instance relationship graph container to process requests, record changes, and ensure data consistency through a graph change transaction log. The data persistence layer persists the final results to the database and simultaneously updates the distributed cache.

[0151] This invention is applicable to various business scenarios of telecom operators, including hierarchical relationship management of products and services, linked updates of scenario instance diagrams and customer instance relationship diagrams, rapid retrieval of complex customer relationships in high-concurrency environments, and order processing and rollback in a distributed architecture. The system supports order entry, preview, billing, charging, and submission operations for scenarios such as new product installations, product modifications, changes to product features, and changes to account customization relationships.

[0152] In actual application at a provincial telecom operator, the system implemented by the present invention reduced the average query response time from 1.2 seconds to 0.3 seconds compared with traditional methods, increased the concurrent processing capacity during peak periods by three times, improved the rollback efficiency of failed order processing by 90%, achieved a cache hit rate for hot data of over 95%, and increased system resource utilization by approximately 40%, significantly reducing hardware costs and providing telecom operators with an efficient and reliable customer relationship management solution.

[0153] The above-described specific embodiments merely describe preferred embodiments of the present invention and do not limit the scope of protection of the present invention. Any modifications, substitutions, and improvements made to the technical solution of the present invention by a person skilled in the art based on the textual description and drawings provided herein, without departing from the design concept and spirit of the present invention, shall fall within the scope of protection of the present invention. The scope of protection 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: The following steps are involved: Step S1: Build a two-layer cache architecture based on graph structure awareness, integrate the structural characteristics of the bidirectional graph into the cache strategy, and replace the traditional key-value pair cache with subgraph-level cache; The two-layer cache architecture based on graph structure perception includes: The local cache layer is used to store uninstantiated specification data. It optimizes vertex affinity and relationship types, and adopts a dual elimination strategy of "LRU + specification affinity"; The distributed cache layer uses subgraph-level serialization to store customer instance data, which is different from the traditional key-value pair method and enables single-time retrieval of the entire subgraph; Instance data is stored in shards by customer dimension, and each customer's instance data is stored as an independent subgraph to reduce network overhead during cross-vertex retrieval. The graph structure-aware two-layer cache architecture also includes a graph structure-aware dynamic warm-up strategy, as follows: Identify high-frequency subgraphs through breadth-first search and mark the strongly correlated subgraphs as "hot factor graphs"; Predicting instance subgraphs corresponding to high-frequency operation scenarios based on customer behavior; Preload the minimum necessary subgraphs according to business scenarios to reduce real-time construction overhead; 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 implement a dual closed-loop synchronization system of "local cache transaction-distributed graph log"; The distributed consistency collaborative maintenance mechanism based on the graph change transaction log 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 build a structured transaction log containing bidirectional graph operation instructions, and synchronized to distributed nodes through a lightweight consensus algorithm based on a Raft variant; Different from traditional distributed transactions, it is used to encapsulate the change operations of bidirectional graph vertices and edges into graph transaction logs to ensure the atomicity of graph data. Step S4: receiving the operation request of the customer instance information at the business capability layer and determining 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 changes in customer instance information through the cache transaction container; Step S7: Ensure data consistency in a distributed environment through graph change transaction logs; Step S8: Persist the operation result in the database.

2. The method for storing and retrieving customer relationship information based on bidirectional graph caching according to claim 1, characterized in that: The adaptive bidirectional graph index includes the following three-layer index structure with dynamic weight perception capability: Vertex index layer: establishes a global hash index by instance type, supporting vertex positioning with O(1) time complexity; Relationship index layer: Based on the characteristics of bidirectional graphs, it maintains both forward and reverse adjacency lists, supporting efficient bidirectional traversal; Path indexing layer: Precomputes and caches frequently accessed paths, reducing query response time from the traditional 100ms to 30ms.

3. The method for storing and retrieving customer relationship information based on bidirectional graph caching according to claim 2, characterized in that: The adaptive bidirectional graph index also includes a dynamic path optimization algorithm: Step S21: Based on historical operation log analysis, 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-calculated result as the value; Step S24: when querying, the pre-calculated path is preferentially called through pattern matching, and real-time traversal is performed if no hit is found; Step S25: Dynamically adjust the pre-calculated path set according to real-time access statistics and regularly update the hot paths.

4. The method for storing and retrieving customer relationship information based on bidirectional graph caching according to claim 1, characterized in that: The structure of the graph transaction log includes a customer identifier, a bidirectional structure representation of a customer instance relationship graph, and an instance vertex map, wherein the instance vertex map includes vertex attributes and association relationships.

5. The method for storing and retrieving customer relationship information based on bidirectional graph caching according to claim 1, characterized in that: The distributed consistency collaborative maintenance mechanism based on the graph change transaction log includes the following aspects: During the order submission phase, changes only exist in the local cache transaction container, achieving scenario-level isolation. After the order is submitted successfully, the graph change operation is executed in batches, which reduces network interaction compared to traditional single operations. The batch processing mechanism includes: merging multiple vertex and edge changes for the same customer into a single transaction package; processing changes to groups of highly correlated vertices in a batch; optimizing the execution order based on topological sorting to ensure dependency correctness; and executing multiple graph operations through a single network transmission. In order rollback scenarios, reverse operations are performed based on the graph transaction log, improving rollback efficiency by over 90%.

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

7. A system for storing and retrieving customer relationship information based on a bidirectional graph cache, applicable to a method for storing and retrieving customer relationship information based on a bidirectional graph cache according to any one of claims 1 to 6, characterized in that: The system includes: View layer: As the part of the system that directly faces 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 to ensure seamless integration and interoperability between different systems; Public facilities layer: provides shared code blocks, libraries, frameworks, and services for use by multiple applications or services within the system, reducing duplication of development; Business capability layer: responsible for defining and implementing the system's specific business capabilities and processing business logic; Process data management layer: the core layer of the system, including: a) Scene instance container: caches all instance object information that needs to be submitted for the current scene, including changes to scene instances, relationship changes, and attribute changes; b) Cache transaction container: responsible for caching the cache information that needs to be submitted when operating customer instance information, and controlling the atomicity of cache transactions; c) Customer instance relationship graph container: responsible for caching 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: handles codes related to database operations; Infrastructure layer: provides basic support for the entire system; The business capability layer implements 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 distributed consistency collaborative maintenance technology based on graph change transaction logs; The data persistence layer loads database data into the distributed cache and local cache through a two-layer cache architecture and data preheating technology based on graph structure perception, providing a basic data relationship structure for the vertices and edges of the customer relationship graph.

Images