Marriage and dating method and system based on relationship management and independent life cycle constraint

Abstract

The application belongs to the technical field of Internet, and relates to a marriage and dating method and system based on relationship management and independent life cycle constraint, which comprises the following steps: unified state coding and initialization, many-to-many relationship establishment and seat allocation, independent life cycle timing and dynamic constraint management, two-way threshold automatic confirmation and state migration, dynamic seat supplement and system closed-loop management, when the relationship is terminated due to expiration or active termination, the seats of both parties are released through an atomic transaction and the global state is updated, a mixed recommendation formula containing a cosine similarity, a Pearson correlation coefficient and an activity factor is used to generate and push new matching objects for the released seat users, and system parameters are dynamically adjusted through monitoring indicators to realize adaptive optimization. The matching efficiency can be significantly improved, the psychological pressure of users can be reduced, the fairness and timeliness of relationship development can be ensured, high automation and low manual intervention can be realized, and high scalability and adaptability are achieved.

Description

Technical Field

[0001] This invention relates to the field of Internet technology, and in particular to a dating and matchmaking method and system based on relationship management and independent lifecycle constraints. Background Technology

[0002] Traditional online dating systems (such as Tantan and Jiayuan.com) primarily employ a one-to-one sequential matching model. Users typically need to complete the entire process of getting to know each other, becoming friends, and establishing a relationship before starting the next relationship. This model has the following technical drawbacks: Inefficient matching: Users must process relationships sequentially, and if a relationship does not go well, the entire process of finding a partner is blocked, resulting in high time costs.

[0003] High psychological pressure: "Confessing your feelings" or "establishing a relationship" is a binary operation with no middle ground, which makes users hesitant to try when they are not completely sure of their feelings, and they are likely to miss out on good opportunities.

[0004] Relationship management is crude: The system manages user status (single, in a relationship) globally and exclusively, which cannot support users to get to know multiple people in parallel with low commitment and low pressure at the same time.

[0005] Lack of quantitative interaction and automatic conversion mechanism: The way to express affection is limited (such as likes and private messages), there is a lack of a unified and quantitative standard to measure the progress of the relationship, and the conversion from "getting to know" to "being in love" requires manual operation by the user, resulting in a low conversion rate.

[0006] Therefore, the industry urgently needs an intelligent dating and matchmaking system that can support many-to-many parallel interactions, quantify favorability, and have an automatic conversion mechanism to solve the above-mentioned technical problems. Summary of the Invention

[0007] To address the aforementioned technical problems, this invention provides a dating and matchmaking method based on relationship management and independent lifecycle constraints, employing the following technical solution, including the following steps: S1: Unified state coding and initialization. By establishing a globally unified state coding system and state transition matrix, and designing a unified state update interface based on optimistic locking, the state of the user before entering the friend-making mode is atomically verified and upgraded. At the same time, through redundant statistical fields and real-time statistical views based on database log capture, a two-way mapping between the user's global state and the number of friend relationships is maintained. S2: Many-to-many relationship establishment and seat allocation. By defining the upper limit of seat capacity and combining Redis counters and database row-level locks for double verification, atomic insertion of friendship relationships and synchronous update of friendship status and count of both users are completed in a single database transaction. After the transaction is committed, asynchronous message notification and front-end status synchronization are performed through the WebSocket protocol. S3: Independent lifecycle timing and dynamic constraint management. It calculates and stores an independent expiration time for each newly established friendship relationship. It performs shard scanning and incremental processing on the expiring relationship through distributed timed tasks. Based on a predefined piecewise function that includes a comparison of the threshold of the number of lights on in both directions, it performs differentiated operations such as automatically upgrading to a romantic relationship or dissolving the relationship on the expiring relationship. S4: Digital expression of favorability and two-way synchronization. By providing a light-up operation interface with optimistic locking control, the two-way favorability counter in the relationship record is updated in real time, and each change is pushed to the other party in the relationship in real time via WebSocket. At the same time, detailed behavior logs are recorded for visualization and subsequent analysis. S5: Bidirectional threshold automatic confirmation and state transition. After each favorability update, a threshold detection task is triggered asynchronously. When it is detected that the favorability of both parties has reached the preset threshold, the relationship is locked through idempotent update, and the interface of the love management module is called synchronously to complete the relationship upgrade. Then, the final cleanup of status, cache and notification is performed. S6: Dynamic seat replenishment and closed-loop system management. When a relationship is terminated due to expiration or active termination, the seats of both parties are released through atomic transactions and their global state is updated. Based on a hybrid recommendation formula that includes cosine similarity, Pearson correlation coefficient and activity factor, new matching objects are generated and pushed to the user who released the seat. At the same time, the system parameters are dynamically adjusted through monitoring indicators to achieve adaptive optimization.

[0008] Preferably, the real-time statistical view based on database log capture in S1 specifically includes: Listen to the binary logs of the dating_relationship table using the Canal component; Send the captured data manipulation language events to the Kafka message queue; These events are consumed by a separate consumer service, which performs atomic increment / decrement operations on the user dating count field user:dating_count:{user_id} stored in Redis based on the event type (INSERT, UPDATE, DELETE). When the front-end interface retrieves user information, it directly reads the count value from Redis, thereby achieving real-time, high-performance statistics on the number of user friendship relationships.

[0009] Preferably, the predefined piecewise function in S3 that includes a comparison of the threshold number of bidirectional lights is specifically expressed as follows: , where L a L represents the accumulated positive feelings that the first user showed towards the second user in their friendship relationship. b The value representing the accumulated favorability of the second user towards the first user is T, where T is a preset automatic confirmation threshold constant.

[0010] Preferably, the asynchronous triggering threshold detection task and the idempotent update locking relationship in S5 specifically include: After the transaction for updating the favorability is committed, send an asynchronous detection message containing the relationship identifier to the message queue; After an independent consumer receives a message, it first executes a conditional update statement: UPDATE dating_relationship SET status = 5 WHERE id = :rel_id AND status = 1, where status code 5 represents "locked"; If the number of affected rows of the statement is 1, it means that the current thread has successfully obtained the right to process the relationship and will continue to execute subsequent love interface calls and state transition operations. If the number of affected rows is 0, it means that the relationship has been processed by other threads or the state has been changed, and the current thread terminates directly to ensure the idempotency of the automatic confirmation logic in a distributed environment.

[0011] Preferably, the hybrid recommendation formula in S6, which includes cosine similarity, Pearson correlation coefficient, and activity factor, is specifically expressed as follows: Where u is the target user and v is the candidate recommended user; and These are the personal profile feature vectors of users u and v, respectively. Calculate the cosine similarity between the two to measure the degree of matching of static attributes; and These are the historical behavioral feature vectors of users u and v, respectively. The Pearson correlation coefficient between the two is calculated to measure the similarity of dynamic favorability expression habits; recency(v) is the recent activity score of candidate user v; α, β, γ are dynamically adjustable weight coefficients.

[0012] Preferably, the distributed timed task in S3 performs a sharded scan of the expiration relationship, specifically including: The scheduled task framework adopts a sharding strategy, where each task instance only processes relationship records that satisfy the condition MOD(relation_id,shard_total) = shard_index; When the task is executed, the timestamp of the last scan, last_scan_time, is read from Redis, and an SQL query is executed: SELECT ... FROM dating_relationship WHERE expire_at <= NOW() AND expire_at > :last_scan_time AND status = 1 AND MOD(id, :shard_total) = :shard_indexLIMIT 1000; After processing, the last_scan_time in Redis is updated using the maximum expire_at value detected in this scan, thereby achieving efficient and lock-free incremental scanning.

[0013] Preferably, the dual verification of the Redis counter and the database row-level lock in S2 specifically includes: At the application layer, the user's current number of dating entries is quickly determined by querying the Redis key user:dating_count:{user_id}. If it has not been reached, the process continues. In the relational transaction at the database layer, the statement SELECT dating_count FROM user WHERE user_id = :user_id FOR UPDATE is used again to lock the user row and obtain the latest count for final verification; The relation insertion operation is only performed if both validations pass; otherwise, the transaction is rolled back and an error message indicating that the seats are full is returned to prevent over-limit issues in high-concurrency scenarios.

[0014] Preferably, the synchronous call to the relationship management module interface in S5 to complete the relationship upgrade includes a retry and compensation mechanism: When a call to the relationship creation interface of the dating module fails, the local transaction is not immediately rolled back. Instead, the status of the current dating relationship record is updated to "pending retry". Add the task to an exponential backoff retry queue with a backoff interval sequence of [1, 2, 4, 8, 16] seconds; If the call succeeds within the maximum of 5 retries, the subsequent cleanup process will continue. If the call ultimately fails, the relationship status will be rolled back from pending retry to "dating" status, and an alarm will be sent through the monitoring system for manual intervention.

[0015] To address the aforementioned technical problems, this invention also provides a progressive online dating system based on relationship management and independent lifecycle constraints for implementing the above-described method, comprising: State Management Module: Used to implement unified state coding, optimistic locking-controlled state transitions, configurable management of state transition matrices, and publication of user state change events; Relationship Management Module: Used to perform atomic creation and termination of many-to-many friendship relationships, dynamic verification and updating of seat capacity, and relationship lifecycle management based on independent timers; Favorability Interaction Module: Provides a lighting operation interface with optimistic locking, real-time WebSocket push service, and persistent storage and query of lighting change history; Automatic conversion module: Used to asynchronously listen for changes in favorability, perform bidirectional threshold judgment, lock the relationship with idempotency, and synchronously call the romance module interface to complete the relationship upgrade; The dynamic recommendation module is used to listen for relationship termination events, generate a recommendation list based on a hybrid recommendation algorithm (combining cosine similarity, Pearson correlation coefficient, and activity factor), and push the recommendation results to the client via WebSocket. Monitoring and optimization module: used to collect key system performance and business indicators, dynamically adjust system parameters such as seat limit and lifecycle based on preset rules, and support A / B testing framework for configuration effect comparison.

[0016] Preferably, the hybrid recommendation algorithm in the dynamic recommendation module calculates the final score using the following formula: The values ​​of the weight coefficients α, β, and γ are updated in real time through an online learning algorithm. The module pushes the list of candidate users whose scores are greater than a preset threshold to the client interface of the target user u in JSON format via the WebSocket protocol, and displays it in the form of a recommendation card.

[0017] Compared with the prior art, the present invention has the following main advantages: (1) It can significantly improve matching efficiency: By supporting up to 5 parallel many-to-many dating relationships, users can change from serial matching to parallel matching, and the matching cycle can be shortened by more than 80% in theory.

[0018] (2) It can reduce users’ psychological pressure: The introduction of a 1-5 level digital goodwill expression system replaces the black-and-white confession behavior, providing users with a gradual and adjustable emotional expression gradient and lowering the threshold for communication.

[0019] (3) It ensures fairness and timeliness in relationship development: The independent lifecycle (30-day) constraint ensures that each relationship has equal and sufficient time to develop, avoiding indefinite delays. Two-way threshold (L a ≥3 and L b The automatic confirmation mechanism of ≥3) ensures that relationship upgrades must be bidirectional and mutually beneficial, reflecting the principle of fairness.

[0020] (4) It can achieve high automation and low human intervention: from lighting up, to threshold detection, to calling the love interface, to seat release and supplementary recommendation, the whole process realizes automated closed-loop management, which greatly reduces the system operation cost and user operation cost.

[0021] (5) High scalability and adaptability: Based on the configuration center, dynamic parameter adjustment, A / B testing framework and automatic scaling strategy based on real-time indicators, the system can optimize itself according to actual operation data and adapt to different market environments and user groups. Attached Figure Description

[0022] To more clearly illustrate the solutions in this invention, the accompanying drawings used in the description of the embodiments of this invention will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0023] Figure 1 This is a flowchart of an embodiment of the online dating method based on relationship management and independent lifecycle constraints of the present invention; Figure 2 This is a schematic diagram of the structure of an embodiment of the online dating system based on relationship management and independent lifecycle constraints of the present invention; Figure 3 This is a schematic diagram of the structure of an embodiment of the computer device of the present invention. Detailed Implementation

[0024] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains; the terminology used herein in the specification is for the purpose of describing particular embodiments only and is not intended to limit the invention; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings are used to distinguish different objects and not to describe a particular order.

[0025] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0026] To enable those skilled in the art to better understand the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings.

[0027] It should be noted that the online dating method based on relationship management and independent lifecycle constraints provided in this embodiment of the invention is generally executed by a server / terminal device, and correspondingly, the online dating system based on relationship management and independent lifecycle constraints is generally set up in the server / terminal device.

[0028] It should be understood that the number of terminal devices, networks, and servers is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be used.

[0029] Example 1

[0030] Please refer to Figure 1 The diagram illustrates a flowchart of an embodiment of the online dating method based on relationship management and independent lifecycle constraints of the present invention. The online dating method based on relationship management and independent lifecycle constraints includes the following steps: S1: Unified state coding and user state initialization.

[0031] Step S1 aims to establish a standardized user state machine model to ensure the interoperability of state semantics and the consistency of transactions between the dating module and the romance module.

[0032] In specific implementation, step S1 further includes the following steps: S11: Define a globally unified state coding system.

[0033] Create a dynamic status code table: Create a dictionary table named `sys_status_code` in the database to store and manage global status codes. The table structure is shown in Table 1. Table 1 field name Data types describe id BIGINT Primary key status_code TINYINT Status codes, such as 0, 1, 3 status_name VARCHAR(32) Status name, such as initial status, dating, in a relationship module VARCHAR(32) Belongs to the following modules: General, Social Networking, Dating description TEXT Status Description At the same time, two key fields were added to the core user table: global_status: of type TINYINT, used to store the user's current global status code.

[0034] status_version: An INT type, used as the optimistic locking version number for concurrency control.

[0035] Design a unified state update interface: Design a globally unique state change function `update_user_status`, whose internal logic ensures atomicity through database transactions and row-level locking. An example of the function's code logic is shown below: FUNCTION update_user_status(p_user_id, p_new_status, p_trigger_module, p_relation_id) BEGIN TRANSACTION / / 1. Lock user rows to prevent concurrent modifications SELECT global_status, status_version INTO v_old_status, v_old_version FROM user WHERE user_id = p_user_id FOR UPDATE / / 2. Load the state transition matrix from the configuration center and verify its validity. IF NOT is_transition_allowed(v_old_status, p_new_status) THEN ROLLBACK RETURN ERROR_CODE_INVALID_STATUS_TRANSITION END IF / / 3. Perform updates using optimistic locking UPDATE user SET global_status = p_new_status, status_version = v_old_version+ 1 WHERE user_id = p_user_id AND status_version = v_old_version IF ROW_COUNT = 0 THEN ROLLBACK RETURN ERROR_CODE_OPTIMISTIC_LOCK_CONFLICT END IF / / 4. Record status change logs INSERT INTO user_status_log (user_id, old_status, new_status,change_time, trigger_module, relation_id, request_id) VALUES (p_user_id, v_old_status, p_new_status, NOW(), p_trigger_module, p_relation_id, v_request_id) COMMIT TRANSACTION / / 5. Clear and update the cache redis.del("user:status:" + p_user_id) redis.setex("user:status:" + p_user_id, 3600, p_new_status) / / 6. Publish state change events message_bus.publish("UserStatusChangedEvent", {user_id: p_user_id,old: v_old_status, new: p_new_status}) RETURN SUCCESS END FUNCTION Define a state transition matrix: State transition rules are stored in a configuration center (such as Apollo) in JSON format, supporting dynamic adjustments at runtime without requiring a service restart. Matrix example: { "transitions": [ {"from": 0, "to": 1, "allowed": true, "description": "Initially entering friend-making mode"}, {"from": 1, "to": 0, "allowed": true, "description": "Exiting friend-making mode and returning to the initial state"}, {"from": 1, "to": 3, "allowed": true, "description": "In friend-making mode, automatic confirmation triggers entry into a romantic relationship."} {"from": 3, "to": 1, "allowed": false, "description": "You cannot revert from a dating status to a romantic relationship"} {"from": 0, "to": 3, "allowed": false, "description": "Friendship confirmation is required before entering a romantic relationship"} ] } Step S12: Verify the user's status before entering the dating mode.

[0036] Verification function and atomic state upgrade: The verification function `check_user_can_enter_dating(p_user_id)` is used. This function first retrieves the user's state from the Redis cache. If the state is not 0, the user is rejected directly. If the state is 0, an atomic SQL update statement is executed to prevent concurrent access. UPDATE user SET global_status = 1, dating_count = 0, status_version = status_version + 1 WHERE user_id = :user_id AND global_status = 0; If the number of rows affected by the statement is 1, the status upgrade is successful; otherwise, it indicates that concurrent requests occurred within a very short period of time, causing the status to change, and a conflict error is returned.

[0037] Distributed transaction coordination: This state update operation typically belongs to the same distributed transaction as the subsequent relationship establishment operation. This embodiment uses the TCC (Try-Confirm-Cancel) pattern and employs a distributed transaction coordinator (such as Seata) for management. Try phase: Call check_user_can_enter_dating to reserve state resources and mark the user as dating (reserved) state.

[0038] Confirm Phase: Confirm the status change and officially update the pre-registered status to "Making Friends".

[0039] Cancel phase: If subsequent relationship establishment fails, roll back the state and restore the user's state to 0.

[0040] Step S13: Perform bidirectional mapping maintenance between states and relationships.

[0041] Redundant statistical fields and intra-transaction updates: Add a `dating_count` field (SMALLINT) to the `user` table to record the number of dating relationships a user is currently in. To ensure strong data consistency, all insert or delete operations on the `dating_relationship` table must synchronously update the `dating_count` field for both users within the same database transaction. Example code is as follows: BEGIN; -- Insert new friendship INSERT INTO dating_relationship (user_id_a, user_id_b, status,created_at, expire_at) VALUES (a, b, 1, NOW(), NOW() + INTERVAL 30 DAY); -- Simultaneously increases the friend count for both parties. UPDATE user SET dating_count = dating_count + 1, status_version =status_version + 1 WHERE user_id IN (a, b); COMMIT; Real-time statistical views based on Canal and Redis: To avoid the performance overhead of frequent querying of relational tables, this embodiment uses MySQL's binlog listening component Canal to capture data change events (INSERT, UPDATE, DELETE) of the `dating_relationship` table in real time. Canal sends the change events to a message queue (Kafka), where a dedicated consumer service consumes these events and updates the counters in Redis. For INSERT events: redis.incr("user:dating_count:" + userId) For DELETE or UPDATE events that become invalid: redis.decr("user:dating_count:"+ userId) The front-end interface directly reads the dating_count from Redis when retrieving user information, ensuring real-time performance and efficiency under high concurrency.

[0042] S2: Allocate and establish relationships for many-to-many social networking.

[0043] Step S21: Define and dynamically verify seat capacity.

[0044] Seat Limit Configuration and Fast Verification: Define the global seat limit in the configuration table sys_config, for example, dating.max_seats = 5. Provide a verification function can_add_dating(p_user_id), which achieves fast verification with O(1) complexity using a Redis counter. Example code is as follows: current_count = redis.get("user:dating_count:" + user_id) if current_count is NULL: current_count = db.query("SELECT dating_count FROM user WHEREuser_id = ?", user_id) redis.setex("user:dating_count:" + user_id, 3600, current_count) return current_count < config.get("dating.max_seats") Final validation to prevent concurrency overruns: To prevent overruns caused by inconsistencies between Redis and the database counts, a final validation is performed within the transaction that establishes the relationship using SELECT ... FOR UPDATE. SELECT dating_count FROM user WHERE user_id = :user_id FOR UPDATE; -- The application checks if dating_count >= max_seats. If it does, it rolls back the transaction and reports an error.

[0045] Step S22: Perform transactional insertion and bidirectional state update for relationship establishment.

[0046] A complete transaction script: The core logic for establishing relationships is encapsulated within a database transaction script, ensuring the atomicity of operations. Example code is as follows: FUNCTION add_relationship(user_a, user_b) BEGIN TRANSACTION / / 1. Lock and verify the status of both parties SELECT global_status INTO v_status_a FROM user WHERE user_id = user_a FOR UPDATE SELECT global_status INTO v_status_b FROM user WHERE user_id = user_b FOR UPDATE IF v_status_a != 0 OR v_status_b != 0 THEN ROLLBACK; RETURN ERROR_USER_STATUS_INVALID END IF / / 2. Lock and verify seats SELECT dating_count INTO v_count_a FROM user WHERE user_id = user_a FOR UPDATE SELECT dating_count INTO v_count_b FROM user WHERE user_id = user_b FOR UPDATE max_seats = config.get("dating.max_seats") IF v_count_a >= max_seats OR v_count_b >= max_seats THEN ROLLBACK; RETURN ERROR_SEAT_LIMIT_EXCEEDED END IF / / 3. Insert relationship record, valid for 30 days INSERT INTO dating_relationship (user_id_a, user_id_b, status, created_at, expire_at) VALUES (user_a, user_b, 1, NOW(), NOW() + INTERVAL 30 DAY) / / 4. Update user status and count UPDATE user SET global_status = 1, dating_count = dating_count +1, status_version = status_version + 1 WHERE user_id IN (user_a, user_b) COMMIT END FUNCTION Step S23: Perform asynchronous notification and front-end synchronization after relationship establishment.

[0047] WebSocket real-time push: Maintain a WebSocket connection pool based on Netty. After the relationship establishment transaction is committed, immediately send a RELATIONSHIP_CREATED event to the message queue. A dedicated notification service consumes this event and pushes JSON messages to the active sessions of both parties through the connection pool. The sample code is as follows: { "type": "NEW_DATING_RELATIONSHIP", "relation_id": 123456, "partner": {"user_id": 456, "nickname": "Xiaoya"}, "expire_at": "2025-04-23T10:00:00Z" } Offline message guarantee: If it is found that the user's WebSocket connection is disconnected during the push, store the message in the offline_message table. When the user establishes a WebSocket connection next time, the client will send a sync request, and the server will pull all the offline messages of this user and send them in batches.

[0048] S3: Perform independent lifecycle timing and dynamic constraint management.

[0049] Step S31: Initialize the lifecycle during relationship establishment.

[0050] Independent expiration time calculation: When creating a dating relationship, use the database function to calculate the expiration time (expire_at) to ensure that each relationship has an independent timer. All times are stored in the UTC time zone to avoid time zone confusion.

[0051] expire_at = CONVERT_TZ(NOW(), '@@session.time_zone', '+00:00') +INTERVAL :lifecycle_days DAY Among them, lifecycle_days is dynamically obtained from the configuration table dating.lifecycle_days, with a default of 30 days.

[0052] Step S32: Perform an independent timer scan and expiration detection.

[0053] Distributed Scheduled Task Shard Scanning: A distributed scheduled task named `scanExpiredRelationships` is built using XXL-Job. The task is configured to run every 5 minutes and a sharding strategy is enabled. Each task instance processes relationship records where `relation_id % shard_total = shard_index` to avoid duplicate scans.

[0054] Incremental scanning and batch processing: The task maintains a global `last_scan_time` (stored in Redis). Each time the task executes, it only scans records whose `expire_at` is within the range [last_scan_time, NOW()]. The SQL query is as follows: SELECT id, user_id_a, user_id_b, light_count_a, light_count_b FROM dating_relationship WHERE expire_at <= NOW() AND expire_at > :last_scan_time AND status =1 AND MOD(id, :shard_total) = :shard_index ORDER BY expire_at LIMIT 1000; The retrieved records are submitted to a thread pool of fixed size 20 for concurrent processing. After processing, last_scan_time is updated to the maximum expire_at of this scan.

[0055] Step S33: Perform status determination and preprocessing after expiration.

[0056] Decision logic formulation and processing: Let L aL represents the cumulative number of lights lit up by the relationship initiator (User A). b This represents the cumulative number of lights lit by the relationship receiver (User B). Let the threshold T = 3. The judgment and processing are based on the following piecewise function: .

[0057] Among them, L a : Variable, representing the total number of "favorability lights" that user A has "lit up" for the other party in the current friendship relationship, with a value range of [0, 5].

[0058] L b : Variable, representing the total number of "favorability lights" that user B has "lit up" for the other party in the current friendship relationship, with a value range of [0, 5].

[0059] T: A constant representing the threshold number of lights required to trigger automatic confirmation; in this example, it is set to 3.

[0060] This piecewise function defines four mutually exclusive expiration handling logics. The relationship can only be automatically upgraded when both parties' expressions of affection reach or exceed the threshold, reflecting the principle of fairness in a two-way process; if only one party meets the threshold, only the qualified party is notified and the relationship is terminated, avoiding one-sided waiting.

[0061] Example code for the function handle_expired_relation is as follows: IF Action == auto_love THEN CALL love_module_api.create_love_relation(user_id_a, user_id_b,source_relation_id) UPDATE dating_relationship SET status = 2, target_love_relation_id = :love_id / / Update the user status to 'in a relationship' (3) and reduce the number of friends. UPDATE user SET global_status = 3, dating_count = dating_count -1 WHERE user_id IN (a, b) ELSE / / Send the corresponding notification IF Action == notify_only_a THEN send_notification(a, "The recipient has not met the requirements") send_notification(b, "You have not met the requirements") ELSE IF Action == notify_only_b THEN / / ... similar logic ELSE send_notification(a, "Neither party has met the requirements") send_notification(b, "Neither party has met the requirements") END IF / / Terminate the relationship and set the status to 3 (Terminated). UPDATE dating_relationship SET status = 3 UPDATE user SET dating_count = dating_count - 1 WHERE user_id IN(a, b) / / If a user's friend count reaches zero and their global state is 1, then reset their state to 0. UPDATE user SET global_status = 0 WHERE user_id = :uid ANDdating_count = 0 AND global_status = 1 END IF S4: Implement digital expression of goodwill and a two-way synchronization mechanism.

[0062] Step S41: Set up the light-up operation interface and data update.

[0063] Optimistic locking for updates and concurrency prevention: A REST API POST to ` / dating / light` is provided. To prevent unnecessary database writes caused by rapid, continuous user clicks, optimistic locking is used for update operations. Updates are only performed when the number of lit lights has actually changed. Example code is as follows: UPDATE dating_relationship SET light_count_a = CASE WHEN user_id_a = :user_id THEN :light_countELSE light_count_a END, light_count_b = CASE WHEN user_id_b = :user_id THEN :light_countELSE light_count_b END, last_light_update = NOW() WHERE id = :relation_id AND status = 1 AND ( (user_id_a = :user_id AND light_count_a != :light_count) OR (user_id_b = :user_id AND light_count_b != :light_count) ) Step S42: Real-time push and two-way sensing of lighting changes.

[0064] Real-time push and history recording: After a successful light update, the server immediately pushes a LIGHT_UPDATE message to the other party in the relationship via WebSocket. Simultaneously, each change is recorded in the light_change_log table for behavioral analysis.

[0065] INSERT INTO light_change_log (relation_id, user_id, old_light, new_light, change_time, ip, device_id) VALUES (:rel_id, :user_id, :old, :new, NOW(), :ip, :device_id); S5: Perform bidirectional threshold automatic confirmation and state transition.

[0066] Step S51: Perform real-time detection of the bidirectional lighting threshold.

[0067] Asynchronous triggering and idempotency guarantee: After each database transaction commit for the light-up update, the checkAutoConfirm task is triggered asynchronously. This task first uses an idempotent update to change the relation state to locked (5) to prevent duplicate processing. Example code is as follows: UPDATE dating_relationship SET status = 5 WHERE id = :rel_id ANDstatus = 1; IF row_count > 0 THEN / / Continue executing the confirmation logic CALL confirm_love_relation(:rel_id); END IF Step S52: Call the unified management interface for dating.

[0068] Synchronous RPC Call and Retry Mechanism: The gRPC protocol is used to synchronously call the CreateLoveRelation interface of the Love module. The call timeout is set to 5 seconds. If the call fails, it is not rolled back immediately, but the task status is set to pending retry and placed in the exponential backoff retry queue (1s, 2s, 4s, 8s, 16s), with a maximum of 5 retries. After all 5 retries fail, the relationship status is rolled back from 5 (locked) to 1 (dating), and an alarm is sent.

[0069] Step S53: Perform cleanup and notification after state transition.

[0070] Eventual consistency cleanup: After a romantic relationship is successfully created, this module performs final cleanup: Update the friendship relationship table, record the associated romantic relationship IDs, and set the status to 2 (transformed). Example code is as follows: UPDATE dating_relationship SET status = 2, target_love_relation_id =:love_rel_id WHERE id = :rel_id; Update the user's global status to 'in a relationship' (3), and decrement the friendship count by 1. Example code is as follows: UPDATE user SET global_status = 3, dating_count = dating_count - 1WHERE user_id IN (a, b); After successful cleanup, delete the corresponding relationship cache and user count cache in Redis, and push a LOVE_CONFIRMED message to notify both front-ends to redirect.

[0071] S6: Perform dynamic seat replenishment and closed-loop management.

[0072] Step S61: Release seats and update status when the relationship is terminated.

[0073] Atomic transaction termination: Provides the POST / dating / abandon interface for actively terminating relationships. An example of its core transaction processing code is as follows: BEGIN; SELECT id, user_id_a, user_id_b INTO v_rel_id, v_a, v_b FROM dating_relationship WHERE id = :id AND status = 1 FOR UPDATE; UPDATE dating_relationship SET status = 4 WHERE id = v_rel_id; -- 4 indicates the user has voluntarily given up. UPDATE user SET dating_count = dating_count - 1 WHERE user_id IN (v_a, v_b); -- Atomically reset the user state with a count of zero to 0 UPDATE user SET global_status = 0 WHERE user_id IN (v_a, v_b) ANDdating_count = 0 AND global_status = 1; COMMIT; Step S62: Perform proactive matching and recommendation after seat release.

[0074] Hybrid recommendation based on collaborative filtering and content filtering: Listening for relationship termination events triggers the recommendation task. The recommendation score is calculated using the following formula: .

[0075] Where: u: variable, representing the current user who needs to be recommended a new object.

[0076] v: Variable, representing the candidate recommended user.

[0077] score(u,v): The dependent variable, representing the final matching score of user u for candidate user v. The higher the score, the higher the priority for recommendation.

[0078] : Vector, representing the personal profile of user u, which is a feature vector composed of features such as age, region, educational background, and interest tags after one-hot encoding.

[0079] : Vector, representing the personal profile vector of candidate user v.

[0080] : Function to calculate the cosine similarity between two profile vectors, with a value range of [0, 1], and measures the degree of matching between users u and v on static attributes.

[0081] : Vector, representing the historical behavioral profile of user u, which is aggregated from the feature vectors of all users who have "lit up" it in history.

[0082] : Vector, representing the historical behavior profile vector of candidate user v.

[0083] : Function to calculate the Pearson correlation coefficient between two behavioral vectors, with a range of [-1, 1], used to measure the similarity between two users in their habits of expressing favorability.

[0084] recency(v): A function that calculates the recent activity score of candidate user v, for example, min(1.0, last_active_minutes_ago / 1440), where the more active the user, the higher the score.

[0085] α, β, γ: coefficients representing the weight of each score in the final score. These can be dynamically adjusted through online machine learning (such as the FTRL algorithm) to meet different operational objectives.

[0086] This formula integrates users' static attributes, dynamic behavioral preferences, and real-time activity levels to achieve personalized, multi-dimensional, and accurate recommendations, effectively increasing users' willingness and success rate in establishing new friendships.

[0087] Step S63: Perform closed-loop monitoring and dynamic parameter optimization.

[0088] Metrics Collection and Adaptive Adjustment Based on Prometheus: Integrating the Prometheus client, key business metrics are collected in real time, such as `dating_auto_confirm_total` (total number of automatic confirmations) and `dating_seat_usage_rate` (seat utilization rate). When `dating_seat_usage_rate` > 0.9 for more than one hour, a monitoring alert triggers an automated script that dynamically adjusts the `dating.max_seats` parameter from 5 to 6 by calling the API of the configuration center (Apollo). This change is also recorded in the A / B testing platform to evaluate the impact of capacity expansion on user conversion and retention rates.

[0089] This invention can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This invention can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0090] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0091] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0092] Example 2 Further reference Figure 2 As a response to the above Figure 1 The implementation of the method shown in this invention provides an embodiment of a dating and matchmaking system based on relationship management and independent lifecycle constraints. This system embodiment is similar to... Figure 1 Corresponding to the method embodiments shown, the system can be specifically applied to various electronic devices.

[0093] like Figure 2As shown, the online dating system 70 based on relationship management and independent lifecycle constraints described in this embodiment includes: a status management module 71, a relationship management module 72, a positive impression interaction module 73, an automatic conversion module 74, a dynamic recommendation module 75, and a monitoring and optimization module 76. Wherein: State Management Module 71: Used to implement unified state coding, optimistic locking control of state transitions, configurable management of state transition matrices, and publication of user state change events; Relationship Management Module 72: Used to perform atomic creation and termination of many-to-many friendship relationships, dynamic verification and updating of seat capacity, and relationship lifecycle management based on independent timers; Favorability Interaction Module 73: Provides a lighting operation interface with optimistic locking, real-time WebSocket push service, and persistent storage and query of lighting change history; Automatic conversion module 74: Used to asynchronously listen for favorability change events, perform bidirectional threshold judgment, lock the relationship with idempotency, and synchronously call the love module interface to complete the relationship upgrade; Dynamic Recommendation Module 75: Used to listen for relationship termination events, generate a recommendation list based on a hybrid recommendation algorithm (combining cosine similarity, Pearson correlation coefficient, and activity factor), and push the recommendation results to the client via WebSocket; Monitoring and optimization module 76: Used to collect key system performance and business indicators, dynamically adjust system parameters such as seat limit and lifecycle based on preset rules, and support A / B testing framework for configuration effect comparison.

[0094] The hybrid recommendation algorithm in the dynamic recommendation module 75 calculates the final score using the following formula: The values ​​of the weight coefficients α, β, and γ are updated in real time through an online learning algorithm. The module pushes the list of candidate users whose scores are greater than a preset threshold to the client interface of the target user u in JSON format via the WebSocket protocol, and displays it in the form of a recommendation card.

[0095] Example 3 To address the aforementioned technical problems, embodiments of the present invention also provide a computer device. Please refer to [link / reference needed]. Figure 3 , Figure 3 This is a basic structural block diagram of the computer device in this embodiment.

[0096] The aforementioned computer device 8 includes a memory 81, a processor 82, and a network interface 83 that are interconnected via a system bus. It should be noted that only the computer device 8 with components 81, 82, and 83 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described herein is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0097] The aforementioned computer devices can be desktop computers, laptops, handheld computers, and cloud servers, among other computing devices. These devices can facilitate human-computer interaction with users through keyboards, mice, remote controls, touchpads, or voice-activated devices.

[0098] The aforementioned memory 81 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the aforementioned memory 81 may be an internal storage unit of the aforementioned computer device 8, such as the hard disk or memory of the computer device 8. In other embodiments, the aforementioned memory 81 may also be an external storage device of the aforementioned computer device 8, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 8. Of course, the aforementioned memory 81 may also include both the internal storage unit and its external storage device of the aforementioned computer device 8. In this embodiment, the aforementioned memory 81 is typically used to store the operating system and various application software installed on the aforementioned computer device 8, such as computer-readable instructions for dating and matchmaking methods based on relationship management and independent lifecycle constraints. In addition, the aforementioned memory 81 can also be used to temporarily store various types of data that have been output or will be output.

[0099] In some embodiments, the processor 82 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip. The processor 82 is typically used to control the overall operation of the computer device 8. In this embodiment, the processor 82 is used to execute computer-readable instructions stored in the memory 81 or to process data, for example, to execute computer-readable instructions for the relationship management and independent lifecycle constraint-based online dating method.

[0100] The network interface 83 may include a wireless network interface or a wired network interface, which is typically used to establish a communication connection between the computer device 8 and other electronic devices.

[0101] The beneficial effects of implementing the above embodiments are as follows: (1) It can significantly improve matching efficiency: By supporting up to 5 parallel many-to-many dating relationships, users can change from serial matching to parallel matching, and the matching cycle can be shortened by more than 80% in theory.

[0102] (2) It can reduce users’ psychological pressure: The introduction of a 1-5 level digital goodwill expression system replaces the black-and-white confession behavior, providing users with a gradual and adjustable emotional expression gradient and lowering the threshold for communication.

[0103] (3) It can guarantee the fairness and timeliness of relationship development: The independent life cycle (30 days) constraint ensures that each relationship has equal and sufficient time to develop, avoiding indefinite delays. The automatic confirmation mechanism of the two-way threshold (and) ensures that relationship upgrades must be two-way and mutually beneficial, reflecting the principle of fairness.

[0104] (4) It can achieve high automation and low human intervention: from lighting up, to threshold detection, to calling the love interface, to seat release and supplementary recommendation, the whole process realizes automated closed-loop management, which greatly reduces the system operation cost and user operation cost.

[0105] (5) High scalability and adaptability: Based on the configuration center, dynamic parameter adjustment, A / B testing framework and automatic scaling strategy based on real-time indicators, the system can optimize itself according to actual operation data and adapt to different market environments and user groups.

[0106] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of the various embodiments of the present invention.

[0107] Obviously, the embodiments described above are merely some embodiments of the present invention, not all embodiments. The accompanying drawings show preferred embodiments of the present invention, but do not limit the patent scope of the present invention. The present invention can be implemented in many different forms; rather, these embodiments are provided to provide a more thorough and complete understanding of the disclosure of the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the patent protection scope of this invention.

Claims

1. A dating and matchmaking method based on relationship management and independent lifecycle constraints, characterized in that, Includes the following steps: S1: Unified state coding and initialization. By establishing a globally unified state coding system and state transition matrix, and designing a unified state update interface based on optimistic locking, the state of the user before entering the friend-making mode is atomically verified and upgraded. At the same time, through redundant statistical fields and real-time statistical views based on database log capture, a two-way mapping between the user's global state and the number of friend relationships is maintained. S2: Many-to-many relationship establishment and seat allocation. By defining the upper limit of seat capacity and combining Redis counters and database row-level locks for double verification, atomic insertion of friendship relationships and synchronous update of friendship status and count of both users are completed in a single database transaction. After the transaction is committed, asynchronous message notification and front-end status synchronization are performed through the WebSocket protocol. S3: Independent lifecycle timing and dynamic constraint management. It calculates and stores an independent expiration time for each newly established friendship relationship. It performs shard scanning and incremental processing on the expiring relationship through distributed timed tasks. Based on a predefined piecewise function that includes a comparison of the threshold of the number of lights on in both directions, it performs differentiated operations such as automatically upgrading to a romantic relationship or dissolving the relationship on the expiring relationship. S4: Digital expression of favorability and two-way synchronization. By providing a light-up operation interface with optimistic locking control, the two-way favorability counter in the relationship record is updated in real time, and each change is pushed to the other party in the relationship in real time via WebSocket. At the same time, detailed behavior logs are recorded for visualization and subsequent analysis. S5: Bidirectional threshold automatic confirmation and state transition. After each favorability update, a threshold detection task is triggered asynchronously. When it is detected that the favorability of both parties has reached the preset threshold, the relationship is locked through idempotent update, and the interface of the love management module is called synchronously to complete the relationship upgrade. Then, the final cleanup of status, cache and notification is performed. S6: Dynamic seat replenishment and closed-loop system management. When a relationship is terminated due to expiration or active termination, the seats of both parties are released through atomic transactions and their global state is updated. Based on a hybrid recommendation formula that includes cosine similarity, Pearson correlation coefficient and activity factor, new matching objects are generated and pushed to the user who released the seat. At the same time, the system parameters are dynamically adjusted through monitoring indicators to achieve adaptive optimization.

2. The online dating method based on relationship management and independent lifecycle constraints according to claim 1, characterized in that, The real-time statistical view based on database log capture in S1 specifically includes: Listen to the binary logs of the dating_relationship table using the Canal component; Send the captured data manipulation language events to the Kafka message queue; These events are consumed by a separate consumer service, which performs atomic increment / decrement operations on the user dating count field user:dating_count:{user_id} stored in Redis based on the event type (INSERT, UPDATE, DELETE). When the front-end interface retrieves user information, it directly reads the count value from Redis, thereby achieving real-time, high-performance statistics on the number of user friendship relationships.

3. The online dating method based on relationship management and independent lifecycle constraints according to claim 1, characterized in that, The predefined piecewise function in S3, which includes a comparison of the threshold for the number of lights on in both directions, is specifically expressed as follows: , where L a L represents the accumulated positive feelings that the first user showed towards the second user in their friendship relationship. b T represents the cumulative favorability expression of the second user towards the first user, and T is a preset automatic confirmation threshold constant.

4. The online dating method based on relationship management and independent lifecycle constraints according to claim 1, characterized in that, The asynchronous triggering threshold detection task and the idempotent update locking relationship in S5 specifically include: After the transaction for updating the favorability is committed, send an asynchronous detection message containing the relationship identifier to the message queue; After an independent consumer receives a message, it first executes a conditional update statement: UPDATE dating_relationship SET status = 5 WHERE id = :rel_id AND status = 1, where status code 5 represents "locked"; If the number of affected rows of the statement is 1, it means that the current thread has successfully obtained the right to process the relationship and will continue to execute subsequent love interface calls and state transition operations. If the number of affected rows is 0, it means that the relationship has been processed by other threads or the state has been changed, and the current thread terminates directly to ensure the idempotency of the automatic confirmation logic in a distributed environment.

5. The online dating method based on relationship management and independent lifecycle constraints according to claim 1, characterized in that, The hybrid recommendation formula in S6, which includes cosine similarity, Pearson correlation coefficient, and activity factor, is specifically expressed as follows: Where u is the target user and v is the candidate recommended user; and These are the personal profile feature vectors of users u and v, respectively. Calculate the cosine similarity between the two to measure the degree of matching of static attributes; and These are the historical behavioral feature vectors of users u and v, respectively, and pearson( , The Pearson correlation coefficient between the two is calculated to measure the similarity of dynamic favorability expression habits; recency(v) is the recent activity score of candidate user v; α, β, γ are dynamically adjustable weight coefficients.

6. The online dating method based on relationship management and independent lifecycle constraints according to claim 1, characterized in that, The distributed timed task in S3 performs a sharded scan of the expiration relationship, specifically including: The scheduled task framework adopts a sharding strategy, where each task instance only processes relationship records that satisfy the condition MOD(relation_id,shard_total) = shard_index; When the task is executed, the timestamp of the last scan, last_scan_time, is read from Redis, and an SQL query is executed: SELECT ... FROM dating_relationship WHERE expire_at <= NOW() AND expire_at >:last_scan_time AND status = 1 AND MOD(id, :shard_total) = :shard_index LIMIT1000; After processing, the last_scan_time in Redis is updated using the maximum expire_at value detected in this scan, thereby achieving efficient and lock-free incremental scanning.

7. The online dating method based on relationship management and independent lifecycle constraints according to claim 1, characterized in that, The dual verification of the Redis counter and the database row-level lock in S2 specifically includes... At the application layer, the user's current number of dating entries is quickly determined by querying the Redis key user:dating_count:{user_id}. If it has not been reached, the process continues. In the relational transaction at the database layer, the statement SELECT dating_count FROM user WHERE user_id = :user_id FOR UPDATE is used again to lock the user row and obtain the latest count for final verification; The relation insertion operation is only performed if both validations pass; otherwise, the transaction is rolled back and an error message indicating that the seats are full is returned to prevent over-limit issues in high-concurrency scenarios.

8. The online dating method based on relationship management and independent lifecycle constraints according to claim 1, characterized in that, The synchronous call to the relationship management module interface in S5 to complete the relationship upgrade includes a retry and compensation mechanism: When a call to the relationship creation interface of the dating module fails, the local transaction is not immediately rolled back. Instead, the status of the current dating relationship record is updated to "pending retry". Add the task to an exponential backoff retry queue with a backoff interval sequence of [1, 2, 4, 8, 16] seconds; If the call succeeds within the maximum of 5 retries, the subsequent cleanup process will continue. If the call ultimately fails, the relationship status will be rolled back from pending retry to "dating" status, and an alarm will be sent through the monitoring system for manual intervention.

9. A progressive online dating system based on many-to-many relationship management and independent lifecycle constraints for performing the method of any one of claims 1 to 8, characterized in that, include: State Management Module: Used to implement unified state coding, optimistic locking-controlled state transitions, configurable management of state transition matrices, and publication of user state change events; Relationship Management Module: Used to perform atomic creation and termination of many-to-many friendship relationships, dynamic verification and updating of seat capacity, and relationship lifecycle management based on independent timers; Favorability Interaction Module: Provides a lighting operation interface with optimistic locking, real-time WebSocket push service, and persistent storage and query of lighting change history; Automatic conversion module: Used to asynchronously listen for changes in favorability, perform bidirectional threshold judgment, lock the relationship with idempotency, and synchronously call the romance module interface to complete the relationship upgrade; The dynamic recommendation module is used to listen for relationship termination events, generate a recommendation list based on a hybrid recommendation algorithm (combining cosine similarity, Pearson correlation coefficient, and activity factor), and push the recommendation results to the client via WebSocket. Monitoring and optimization module: used to collect key system performance and business indicators, dynamically adjust the seat limit and lifecycle system parameters based on preset rules, and support A / B testing framework for configuration effect comparison.

10. The system according to claim 9, characterized in that, The hybrid recommendation algorithm in the dynamic recommendation module calculates the final score using the following formula: The values ​​of the weight coefficients α, β, and γ are updated in real time through an online learning algorithm. The module pushes the list of candidate users whose scores are greater than a preset threshold to the client interface of the target user u in JSON format via the WebSocket protocol, and displays it in the form of a recommendation card.

Images