Chat method and system for reversely establishing session, and electronic equipment

Abstract

The invention provides a chat method and system for reversely establishing a session and electronic equipment. The method comprises the following steps executed at a server side: acquiring user behavior log data through a data acquisition interface, calculating intention parameters, screening high-intention users, and writing the screened high-intention users into a database; generating a matching relation record according to the geographic position attribute of the user, the demand feature vector and the sales service capability parameter; persistently storing the matching relationship and the historical active period data of the user into a recommendation pool database, and setting a timeliness mark; pushing the user data to a corresponding sales client according to a historical active period through a timed task thread; and when chatting is initiated during sales, querying the recommendation pool to verify the timeliness mark, and only establishing a session channel for the effective matching relationship. According to the method, the recommendation pool database is adopted as a time synchronization engine and a dynamic permission source at the same time, balance between sales active reaching and user privacy protection is achieved through a timeliness mark driven bidirectional verification mechanism, and the accuracy and safety of message pushing are improved.

Description

Technical Field

[0001] This invention relates to the field of chat technology for reverse session establishment, and more particularly to a chat method, system, and electronic device for reverse session establishment. Background Technology

[0002] With the widespread application of instant messaging technology across various industries, online chat has become a core channel for businesses to serve customers. Traditional instant messaging systems primarily address one-way communication scenarios where users initiate inquiries, preventing sales teams from proactively identifying and reaching high-intent users with potential needs, thus limiting the efficiency of customer resource utilization. If the approach of directly granting sales teams the authority to proactively search for users is adopted, the following technical drawbacks exist:

[0003] First, there is a lack of a precise user demand identification mechanism. Existing systems cannot automatically calculate the intensity of demand based on users' historical behavior patterns, leading to sales staff blindly reaching out to low-intent users, resulting in wasted system resources and a decline in user experience.

[0004] Secondly, the issue of disruption caused by users' time preferences is ignored. Existing push mechanisms mostly send messages according to fixed time windows or real-time triggering strategies, without synchronizing with users' historical active periods. Frequently sending messages during inactive periods significantly increases user resentment and reduces message open rates.

[0005] Third, there is a conflict between privacy protection mechanisms and business flexibility. Traditional access control systems are based on role-based access control (RBAC) or static rules, and the rigidity of sales permissions leads to "all or nothing" access control. If sales users are granted search permissions, it is difficult to prevent malicious access to user privacy data; if permissions are strictly restricted, the business need for sales to proactively acquire customers cannot be met. Existing systems have failed to establish a dynamic balance between protecting user privacy and meeting business flexibility through technical means.

[0006] Fourth, the system modules are highly coupled. Functions such as intent analysis, matching and push, and permission verification are scattered across independent systems. The lack of a unified data layer to coordinate the collaborative work between modules leads to high costs for maintaining data consistency and poor system scalability.

[0007] Therefore, there is an urgent need for a technological means that can enable sales to accurately reach high-intent users, protect user privacy and reduce disturbance rates at the system level through technical architecture design, and improve the overall efficiency of the system. Summary of the Invention

[0008] The purpose of this invention is to provide a chat method, system, and electronic device for reverse session establishment, thereby solving the aforementioned problems existing in the prior art.

[0009] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0010] A method for initiating a chat session in reverse involves performing the following steps on the server side:

[0011] The system acquires user behavior log data on the client through a data acquisition interface, calculates user intention parameters based on the behavior log data, and marks users whose intention parameters are higher than a preset threshold as high-intent users and writes them into the intention user database.

[0012] Based on the geographic location attributes, demand feature vectors, and service capability parameters of highly interested users, a matching algorithm is used to generate records of matching relationships between users and sales personnel.

[0013] The matching relationship records and users' historical active time period data are persistently stored in the recommendation pool database, and a time-sensitive tag is set for each matching relationship record;

[0014] The system uses a scheduled task thread to query the recommendation pool database at preset time intervals, retrieves user data that matches the historical active period with the current server time, and calls the message push interface to send the user data to the corresponding sales client.

[0015] When receiving a chat request initiated by a salesperson, the system queries the recommendation pool database to verify the validity of the timeliness tag. If the matching record is valid, a session connection channel is established; otherwise, the request is rejected and an error code is returned.

[0016] Preferably, the steps for calculating user intention parameters include: assigning weight coefficients to browsing behaviors of different page types, generating scores by combining page dwell time, and obtaining user intention parameters through weighted summation.

[0017] Preferably, the steps for generating matching relationship records include: filtering sales within the service coverage area based on user geographic location attributes, calculating the matching degree based on the similarity between demand feature vectors and service capability parameters, and selecting the sales with the highest matching degree to generate matching relationship records.

[0018] Preferably, the steps for querying the recommendation pool database to verify the expiration mark include: during the client-side verification phase, intercepting the salesperson's access request to the user and querying the recommendation pool database to see if there are any unexpired matching relationship records; during the server-side verification phase, intercepting the message body, querying the matching relationship records again, and verifying the expiration mark.

[0019] Preferably, the scheduled task thread adopts a distributed scheduling framework, and the operation of querying the recommendation pool database includes: retrieving user data that falls within the current time slice in the historical active period by time shard index, completing the data distribution through the batch push interface, and updating the push status bit in the recommendation pool database.

[0020] Preferably, the method further includes: recalculating the intention parameters of all users at a preset period, updating the intention user database, deleting invalid matching relationship records, and releasing database resources.

[0021] A chat system that establishes conversations in reverse, deployed on a server, includes:

[0022] The data acquisition and processing module is used to acquire user behavior log data, calculate user intention parameters, and manage the database of potential users.

[0023] The matching relationship generation module is used to execute matching algorithms to generate matching relationship records between users and sales.

[0024] The recommendation pool storage module is used to persistently store matching relationship records, historical active period data, and timeliness tags;

[0025] The scheduled push engine is used to execute scheduled task threads to query the recommendation pool storage module and call the message push interface;

[0026] The security verification gateway is used to query the recommendation pool storage module to verify the validity period flag when receiving chat requests, and to control the establishment and rejection of session connection channels.

[0027] Preferably, the security verification gateway includes a client access control layer and a server message interception layer, which respectively perform dual verification operations.

[0028] An electronic device, comprising:

[0029] Memory is used to store executable instructions for a computer;

[0030] A processor is used to execute computer-executable instructions to implement the steps of the above-described methods.

[0031] The beneficial effects of this invention are:

[0032] Firstly, this invention achieves the technical effect of precise two-way matching between sales and users. It acquires behavioral log data through a server-side data collection interface, calculates intent parameters based on user browsing time and page weight, and automatically identifies high-intent users. Combining a matching algorithm with geographic location attributes and demand feature vectors, it quantitatively matches user needs with sales service capabilities. Compared to existing technologies where sales blindly search for customers or rely on static customer allocation rules, this invention improves matching accuracy and resource allocation efficiency through a data-driven dynamic matching mechanism.

[0033] Secondly, the technical effect of reducing user disturbance. This invention persistently stores users' historical active time period information in the recommendation pool database, and periodically retrieves user data matching the current server time through a scheduled task thread, achieving mirrored synchronous push according to user time preferences. This mechanism avoids sending messages during inactive periods at the system level, significantly reducing user disturbance compared to traditional fixed-time window pushes, and improving the naturalness of message reception and user responsiveness.

[0034] Thirdly, the technical effectiveness of end-to-end privacy protection. This invention abandons traditional role-based static access control and sets a time-sensitive marker for each matching relationship in the recommendation pool database. The security verification gateway queries the same recommendation pool data source to verify the validity of the time-sensitive marker during both the client click stage and the server message sending stage, forming a dual technical barrier. This mechanism ensures that sales can only reach users through temporary matching relationships generated by the system, preventing malicious traversal of user data and achieving privacy protection at the architectural level without exposing sensitive user information.

[0035] Fourth, the technical effect of reducing system coupling. This invention stores matching relationships, historical active periods, and timeliness markers uniformly in the recommendation pool database, serving as a shared data hub for all functional modules. The intended user analysis module, matching relationship generation module, timed push engine, and security verification gateway all interact with each other by accessing the recommendation pool, avoiding direct dependencies between modules. This architecture simplifies system complexity, improves module scalability and maintainability, and reduces system reconstruction costs caused by functional expansion.

[0036] Fifth, the technical effect of improving system resource utilization. This invention uses a scheduled task thread to retrieve user data in batches by time-sharded index, reducing the frequency of database access compared to real-time, line-by-line queries. After a push is completed, the push status bit is updated in the recommendation pool database, and combined with an automatic cleanup mechanism for time-sensitive tags, storage resources occupied by invalid data are released in a timely manner. This design reduces the computational and storage overhead during system operation and improves server resource utilization efficiency.

[0037] Sixth, the technical effects of enhancing system security and stability. The security verification gateway of this invention employs a dual authentication mechanism between the client and server. Even if client authentication is bypassed, the server can still intercept invalid requests. The automatic expiration mechanism for time-sensitive tags prevents the malicious exploitation of expired matching relationships. This dual protection mechanism enhances security capabilities at the system level, reduces the risk of unauthorized access, and improves service stability. Attached Figure Description

[0038] Figure 1 This is a flowchart of a chat method for establishing a reverse session according to the present invention;

[0039] Figure 2 This is a structural diagram of a chat system for reverse session establishment according to the present invention. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0041] Reference Figure 1 The method shown involves establishing a chat session in reverse, and the following steps are performed on the server side:

[0042] S1. Obtain user behavior log data on the client through the data collection interface, calculate user intention parameters based on the behavior log data, mark users whose user intention parameters are higher than the preset threshold as high-intent users and write them into the intention user database.

[0043] Specifically, this step involves the server receiving user behavior log data from the client in real time through a predefined data acquisition interface. This interface captures various user activity traces within the application in a standardized format, including page access records, duration of each page visit, click sequence, and interaction depth of functional modules. After the raw behavior logs are received by the interface, they are processed numerically in the parameter calculation unit.

[0044] The parameter calculation unit performs weighted analysis on the behavior log data based on a preset rule engine. The system assigns differentiated weight values ​​to different types of page browsing behavior, and also performs quantitative evaluation based on dwell time. Through cumulative calculation, the multi-dimensional behavioral data is transformed into a single-dimensional user intention parameter.

[0045] After calculation, user intent parameters are compared with preset thresholds. The thresholds are dynamically adjusted according to the business scenario to distinguish the strength of user needs. Users whose parameters exceed the threshold are marked as high-intent users, and the system generates a unique identifier for them and writes it to the intent user database.

[0046] The target user database uses a relational structure for storage. Each record contains a user identifier, intention parameter values, behavioral characteristic tags, and a data update timestamp. Write operations ensure data consistency through a transaction mechanism, and a database connection pool manages concurrent access to guarantee write reliability. The entire process is fully automated, from raw behavioral data to the screening of highly targeted users, providing a high-quality data source for subsequent matching stages.

[0047] S2. Based on the geographic location attributes, demand feature vectors, and service capability parameters of highly interested users, a matching algorithm is used to generate a record of matching relationships between users and sales personnel.

[0048] This step specifically involves the system reading records of highly interested users from the database of interested users and extracting the geographic location attribute and demand feature vector for each user. The geographic location attribute is represented in standard geocoding form, and the demand feature vector consists of multiple dimensions derived from the user's browsing behavior, reflecting the strength of the user's preference for specific services or products.

[0049] Simultaneously, the system retrieves the sales service capability parameter database to obtain the service coverage area, professional field tags, and service capability ratings for all sales personnel. Service capability parameters are automatically generated by integrating historical service response time, user satisfaction feedback, and business completion quality.

[0050] After the matching algorithm is activated, it first filters out the set of sales outlets whose service coverage area includes the user's location based on the user's geographic location attribute, completing the first round of spatial matching. Next, the algorithm calculates the similarity between the user's demand feature vector and the sales' professional domain tags, and performs feature comparison through a vector space model to achieve semantic matching of needs and capabilities.

[0051] Building upon this, the algorithm incorporates a service capability score as a ranking criterion, comprehensively ranking the sales representatives who have passed the first two rounds of screening. The sales representative with the highest score who also meets the matching criteria is identified as the optimal match.

[0052] The system generates a record of matching relationships between users and sales representatives. This record includes a unique user identifier, a unique sales representative identifier, a matching timestamp, a matching score, and a validity period marker. The record is written to the recommendation pool database to provide data support for subsequent push notifications and security verification. The entire matching process is automated through algorithms, ensuring accuracy and efficiency.

[0053] S3. Persistently store the matching relationship records and the user's historical active time period data to the recommendation pool database, and set a time-sensitive mark for each matching relationship record;

[0054] Specifically, this step involves the system receiving the matching relationship records generated by the matching algorithm and then structurally encapsulating them with the user's historical active time period data. Historical active time period data is extracted by analyzing the user's login time, page access timestamps, and interaction behavior time distribution over past periods, forming continuous time interval records.

[0055] The encapsulated data is written to the recommendation pool database. This database adopts a relational architecture and contains core data tables for storing matching relationships. Each record corresponds to a unique matching relationship instance. The record has multiple data fields to carry basic information such as user identifier, sales identifier, match establishment time, and match degree value. It also has an independent field for storing time-series data on historical active periods.

[0056] Timeliness markers, as key attributes of records, use timestamps to indicate the effective start and end times of a matching relationship. The marker generation rules are based on pre-defined business strategies, considering the expected lifecycle of the matching relationship and the timeliness characteristics of user needs. Timeliness markers are embedded in each matching record and bound to the record's primary key.

[0057] Write operations are performed by the database persistence layer, employing a transaction management mechanism to ensure data consistency. Before a transaction is committed, the system verifies data integrity, checking the standardization of field formats and the validity of association identifiers. After a successful commit, data is written from the memory buffer to the physical storage medium for long-term storage. Database connection pooling technology manages concurrent write requests, ensuring storage reliability in high-concurrency scenarios. The entire process achieves reliable persistence and manageability of matching relationship data.

[0058] S4. The scheduled task thread queries the recommendation pool database at preset time intervals, retrieves user data that matches the historical active period and the current server time, and calls the message push interface to send the user data to the corresponding sales client.

[0059] Specifically, this step involves the system starting a scheduled task thread, which executes repeatedly according to a preset time period. At the beginning of each period, the thread establishes a connection with the recommendation pool database and initiates a query operation.

[0060] The query criteria are based on the current server time, retrieving user records whose historical active time period field contains the current time. The database engine scans the recommendation pool row by row for records with valid time-sensitive tags and whose time field intersects with the current time, filtering out the user dataset that meets the criteria.

[0061] After acquiring the user dataset, the system extracts the user identifier, demand characteristics, and associated sales identifier from each record, and encapsulates them into a standardized push message structure. The message structure includes the recipient's sales identifier, user summary information, and reach priority flags.

[0062] The system calls the message push interface, which encapsulates network communication protocols and client connection management functions. The interface locates the corresponding client long-connection channel based on the sales identifier, serializes the push message into a network transmission format, and transmits it to the target client through the established channel.

[0063] After receiving the push notification, the sales client displays a summary of user data on the interface, including user ID, demand characteristics, and historical active time periods. Once the push is complete, the scheduled task thread enters a sleep state, waiting for the next preset time interval to repeat the above process. The entire process achieves automated and precise push notifications based on user time preferences.

[0064] S5. When receiving a chat request initiated by a salesperson, query the recommendation pool database to verify the validity of the timeliness tag. If the matching relationship record is valid, establish a session connection channel; otherwise, reject the request and return an error code.

[0065] Specifically, this step involves the following: When a salesperson triggers a chat operation on the client side, the system security verification gateway captures the chat request in real time. The gateway extracts the salesperson's unique identifier, the target user's identifier, and the timestamp information from the request message to form query parameters.

[0066] The system calls the recommendation pool database query interface, passing in the sales identifier and user identifier as search conditions. The database engine locates the corresponding record in the matching relationship record table and reads the record's validity period marker field. The validation logic compares the current system time with the validity period within the validity period marker: if the current time falls within the validity period, the record is considered valid; if the validity period has expired or there is no corresponding record, the validation fails.

[0067] After successful verification, the system activates the session management module, creates a session connection channel instance on the server side, allocates communication resources, establishes a two-way message transmission link between the sales client and the user client, and allows the normal flow of subsequent chat messages.

[0068] If verification fails, the session management module refuses to establish a connection, and the system generates a standardized error code. The error code carries a clear indication of the failure reason and is returned to the sales client via the network. The client displays the corresponding prompt message based on the error code, preventing the sales representative from sending further messages. The entire process is completed within milliseconds, ensuring real-time performance and security.

[0069] Preferably, the steps for calculating user intention parameters include: assigning weight coefficients to browsing behaviors of different page types, generating scores by combining page dwell time, and obtaining user intention parameters through weighted summation.

[0070] Preferably, the steps for generating matching relationship records include: filtering sales within the service coverage area based on user geographic location attributes, calculating the matching degree based on the similarity between demand feature vectors and service capability parameters, and selecting the sales with the highest matching degree to generate matching relationship records.

[0071] Preferably, the steps for querying the recommendation pool database to verify the expiration mark include: during the client-side verification phase, intercepting the salesperson's access request to the user and querying the recommendation pool database to see if there are any unexpired matching relationship records; during the server-side verification phase, intercepting the message body, querying the matching relationship records again, and verifying the expiration mark.

[0072] Preferably, the scheduled task thread adopts a distributed scheduling framework, and the operation of querying the recommendation pool database includes: retrieving user data that falls within the current time slice in the historical active period by time shard index, completing the data distribution through the batch push interface, and updating the push status bit in the recommendation pool database.

[0073] Preferably, the method further includes: recalculating the intention parameters of all users at a preset period, updating the intention user database, deleting invalid matching relationship records, and releasing database resources.

[0074] Reference Figure 2 The system shown is a chat system that establishes a reverse session. The system is deployed on the server side and includes:

[0075] The data acquisition and processing module is used to acquire user behavior log data, calculate user intention parameters, and manage the database of potential users.

[0076] The matching relationship generation module is used to execute matching algorithms to generate matching relationship records between users and sales.

[0077] The recommendation pool storage module is used to persistently store matching relationship records, historical active period data, and timeliness tags;

[0078] The scheduled push engine is used to execute scheduled task threads to query the recommendation pool storage module and call the message push interface;

[0079] The security verification gateway is used to query the recommendation pool storage module to verify the validity period flag when receiving chat requests, and to control the establishment and rejection of session connection channels.

[0080] Preferably, the security verification gateway includes a client access control layer and a server message interception layer, which respectively perform dual verification operations.

[0081] An electronic device, comprising:

[0082] Memory is used to store executable instructions for a computer;

[0083] A processor is used to execute computer-executable instructions to implement the steps of the above-described methods.

[0084] In this embodiment, the present invention provides a chat system for reverse session establishment. The system is deployed on the server side and adopts a modular architecture design. The modules interact with each other and coordinate functions through standard interfaces.

[0085] The data acquisition and processing module is responsible for task distribution and raw data acquisition. This module establishes a long-lived connection with the client through a network interface layer to receive real-time log data streams generated by user behavior. The received log data is parsed and then enters the parameter calculation unit. The system converts behavioral features into quantified parameters based on preset rule mapping relationships. After calculation, the module performs threshold judgment on the parameters and writes user data that meets the high intent standard into a dedicated database. Simultaneously, it manages resource scheduling in the database connection pool to ensure stability and consistency under high-concurrency write scenarios.

[0086] The matching relationship generation module is responsible for the intelligent matching of users and sales personnel. The module reads high-intent user data from the potential user database, extracting user geographic location attributes and demand feature vectors. Simultaneously, it reads the service capability parameters of all sales personnel from the sales capability database. During the matching algorithm execution, spatial matching is first performed based on geographic location encoding; then, the semantic similarity between the demand feature vector and service capability is calculated; finally, the optimal matching object is determined by comprehensively considering the service capability score, generating a complete matching relationship record.

[0087] The recommendation pool storage module, serving as the core data hub, employs a relational database for long-term data persistence. The module's storage structure contains multiple data fields, each carrying basic information such as user identifier, sales identifier, and matching timestamp. A separate field stores historical active time period data, and a dedicated time-sensitive marker field is also included. During write operations, the module initiates a transaction management mechanism to verify data integrity, ensuring the consistency and reliability of data persistence to disk.

[0088] The scheduled push engine enables precise targeting based on time preferences. Internally, the engine runs a scheduled task thread that executes repeatedly according to a preset cycle. Within each cycle, the thread establishes a database connection and queries the recommendation pool storage module using the current server time as the baseline. After the search results are processed, the engine calls the message push interface to transmit the user data over the network to the corresponding sales client. Once the push is complete, the engine releases the database connection, and the thread enters a sleep state, awaiting the next cycle.

[0089] The security verification gateway is responsible for the security management of session establishment. Deployed at the server-side network ingress, the gateway listens for all chat requests. When a request arrives, the gateway extracts the sales identifier and user identifier from the request message, constructs query conditions, and accesses the recommendation pool storage module. The gateway reads the expiration date flag field from the matching relationship record and compares the current system time with the flag's validity period. If the verification passes, the gateway triggers the session management module to establish a connection channel; if the verification fails, the gateway rejects the request and generates a standardized error code to return to the client.

[0090] In the preferred design, the security verification gateway adopts a layered architecture. The client access control layer is deployed at the network access layer to perform pre-verification on the first access request from the sales client. The server-side message interception layer is embedded in the message processing pipeline to perform secondary verification on the actual chat messages. The two layers perform independent query verification operations, forming a dual technical barrier. Even if one layer of verification is bypassed, the other layer can still ensure system security.

[0091] This invention also provides an electronic device comprising two core components: a memory and a processor. The memory uses a non-volatile storage medium to store a set of executable computer instructions. The memory is connected to the processor via a bus interface, supporting fast instruction retrieval. The processor is a general-purpose computing unit that loads instructions from the memory and executes logical operations, data read / write operations, and network communication operations according to the instruction sequence, fully implementing all steps of the aforementioned chat method. The electronic device connects to an external network via a network interface card (NIC), receives client requests, and returns processing results, forming a complete physical implementation.

[0092] Example 1: (Core Method Example)

[0093] This embodiment provides a complete method for establishing a reverse session, which is applied to the server side of an automotive information service platform.

[0094] The server receives user behavior logs from the mobile app in real time via the Flume data acquisition interface. The logs are in JSON format and include fields such as user ID, page encoding, dwell time, and timestamp. The log data is buffered in a Kafka message queue and then consumed by the Spark Streaming engine.

[0095] The stream processing engine maps page types to weight values ​​(e.g., a car details page has a weight of 0.4, a reputation page has a weight of 0.3, and a competitor comparison page has a weight of 0.3). It then calculates a linearly weighted value based on dwell time, accumulating this value every 15-minute window to generate user intent parameters. When a user intent parameter exceeds a threshold of 75, it is marked as a high-intent user and written to a Redis cache database. Simultaneously, it is asynchronously persisted to a MySQL intent user table, which includes fields for user_id, intent_score, and last_update_time.

[0096] The matching relationship generation module reads a list of highly interested users from Redis, extracts the latitude and longitude coordinates of the users' GPS locations, and encodes them into geographic location strings using the Geohash algorithm. Simultaneously, the system reads the sales service radius (e.g., 50 kilometers) and service vehicle tags from the PostgreSQL sales database. The matching algorithm first filters the set of sales whose service radius covers the user's location, then calculates the Jaccard similarity between the user's viewed vehicle tags and the sales service tags, and finally selects the sales with the highest similarity and an online status of "available for order" to generate a matching relationship record, which is then written to the recommendation pool database.

[0097] The recommendation pool database uses a sharded design with the primary key `match_id`, and includes fields such as `user_id`, `seller_id`, `match_time`, `geo_location`, `intent_tags`, `active_time_range`, and `expire_time`. The `active_time_range` field stores the user's most frequent active time periods over the past 7 days (e.g., ["14:00-15:00", "20:00-21:00"]) as a JSON array, and the `expire_time` field is set to 24 hours after the match creation time.

[0098] The scheduled push engine, based on the XXL-JOB distributed scheduling platform, is configured with the Cron expression "* / 5 * * * * ?", triggering a push task every 5 minutes. During task execution, the current server time is retrieved, formatted as HH:MM, and a SQL query is used to retrieve records from the recommendation pool table whose active_time_range contains the current time. For example, if the task is executed at 14:03, user data with an active_time_range containing "14:00-15:00" is matched. The query results are serialized using Protobuf and then pushed in batches to the corresponding sales client via a Netty long-connection channel. After the push is complete, the record status is updated to "pushed".

[0099] When a salesperson initiates a chat by clicking on a user's avatar on the client side, the security verification gateway intercepts the request, extracts the seller_id and user_id parameters from the URL, constructs a query to retrieve a matching record that has not expired from the recommendation pool database. If a valid record exists and the expire_time is greater than the current time, the gateway allows the request and writes the session ID to the Redis session table; if the record does not exist or has expired, the gateway returns an HTTP 403 error code and a JSON body {"error_code":"MATCH_EXPIRED","message":"Match relationship has expired"}, and refuses to establish a WebSocket connection.

[0100] Example 2: (Example of Intended Parameter Calculation)

[0101] This embodiment describes in detail the calculation process of the intention parameters.

[0102] The server deploys Flink tasks to continuously consume user behavior event streams. The event stream includes two types: `page_view_event` and `stay_time_event`. For `page_view_event`, the system queries a pre-configured page weight table to obtain weight values: homepage 0.1, vehicle series page 0.2, vehicle series details page 0.4, configuration comparison page 0.3, and dealer query page 0.3. For `stay_time_event`, the system maps the dwell time to a score: 0-30 seconds = 1 point, 30-60 seconds = 2 points, 60-120 seconds = 3 points, and over 120 seconds = 4 points.

[0103] Each user maintains a sliding window state, with a window duration of 24 hours. When a new event arrives, the system extracts the page_id from the event to query its weight, multiplies it by the duration score, and adds it to the user's cumulative intention parameter value. For example, if user A browses a car series details page and stays for 90 seconds, the contribution value is calculated as 0.4 × 3 = 1.2. When the cumulative value exceeds the threshold of 100, a state transition is triggered, marking the user as a high-intent state and writing it to the MySQL intention user table via the Sink interface. At the same time, the user's window state is cleared to release memory resources.

[0104] Example 3: (Matching Algorithm Example)

[0105] This embodiment describes the execution details of the multi-dimensional matching algorithm.

[0106] The recommendation pool storage module reads records of highly interested users from the database of interested users and parses the geographic location attribute and demand feature vector for each record. The geographic location attribute is the latitude and longitude coordinates reported by the user's client, such as (116.4074, 39.9042). The demand feature vector is a sparse vector, and its dimensions include the intended car series ID, price range, color preference, etc., for example, {"series_id":"BMW_3","price_range":"300,000-400,000"}.

[0107] The system reads the service capability parameters of all sales from the sales database. These parameters include the service geofence (a circular area with a radius of 50 kilometers centered on the sales representative's permanent location), the set of vehicle models available for service, and the service rating (0-100 points). The sales representative's permanent location is also represented by latitude and longitude coordinates.

[0108] The matching algorithm performs a three-level filtering process: The first level of filtering calls MongoDB's geospatial query interface and uses the $geoWithin operator to filter out a subset of sales where the service geofence covers the user's location; the second level of filtering calculates the text similarity between the demand feature vector and the set of sales service vehicle series, and uses the TF-IDF vector cosine similarity algorithm to retain sales with a similarity greater than 0.6; the third level of filtering sorts the remaining sales in descending order of service score and selects the one with the highest score as the final matching object.

[0109] When generating matching relationship records, the system creates a UUID as match_id and writes user_id, seller_id, match_time, geo_hash, similarity value, and expire_time (current time + 24 hours) into the match_record table in the recommendation pool database. The table structure uses the InnoDB engine to support transactions.

[0110] Example 4: (Dual Validation Example)

[0111] This embodiment describes the dual authentication mechanism of a security verification gateway.

[0112] The security verification gateway is deployed between the Nginx reverse proxy layer and the business logic layer, and Lua scripts based on OpenResty are used to intercept requests.

[0113] When a salesperson clicks on a user's profile on the client side, the client initiates an HTTP GET request to ` / api / chat / init?user_id=xxx`. The Nginx layer triggers the `access_by_lua_block` script, which extracts the `seller_id` (decoded from the JWT token) and `user_id` parameters from the request and constructs the SQL statement: `SELECT COUNT(*) FROM match_record WHERE user_id=xxx AND seller_id=yyy AND expire_time> NOW()`. If the query result is 0, the script returns `ngx.exit(403)`, rejecting the request; if it is greater than 0, the script sets `ngx.var.target_user=xxx` and allows the request to proceed to the upstream business service.

[0114] When a salesperson sends a chat message, the application layer service receives the WebSocket message frame and calls the `verify_message()` method of the security verification gateway. This method executes the same SQL query again (the query results are cached in Redis, TTL=10 seconds) to verify the validity of the match. If the verification fails, the method returns false, the business layer sends a WebSocket close frame to the client (Close Code: 3403, Reason: "Invalid Match"), and logs the audit log to Elasticsearch, including seller_id, user_id, attempt_time, and error_type.

[0115] Example 5: (Optimized Example of Timed Push Notification)

[0116] This embodiment describes the optimization of distributed scheduled tasks and batch push.

[0117] The recommendation pool storage module employs a database sharding strategy, hashing user IDs across 16 database instances. In each instance, the `match_record` table has a functional index created on the `active_time_range` field, with the index expression `EXTRACT(HOUR FROM active_time_range)`.

[0118] The XXL-JOB scheduling center is configured with 5 executor instances, each responsible for 3-4 database shards. When a task is triggered, the executor retrieves the current hour (e.g., 14) and initiates a parallel query to all shards: `SELECT * FROM match_record_{shard} WHERE active_hour=14 AND status='pending' AND expire_time>NOW() LIMIT 1000`. After merging the query results, they are grouped by seller_id, and each group of user data is encapsulated as a `BatchPushMessage` object.

[0119] The message push interface uses the Netty framework to implement long-connection management and maintains the mapping relationship between seller_id and Channel. The interface uses Protobuf to encode BatchPushMessages and writes them in batches via Channel.writeAndFlush(). After all Channels have been written, an ACK confirmation is received asynchronously, and finally, the recommendation pool database status is updated to "pushed". This batching mechanism reduces the number of database queries from N to the number of shards, and the number of network I / O operations from N to the order of sellers, significantly improving throughput.

[0120] Example 6: (Example of Periodic Updates and Resource Cleanup)

[0121] This embodiment describes the data update and failure cleanup mechanism.

[0122] The server is configured with a Cron job to execute a data update task daily at 2 AM. When the task starts, it recalculates the intent parameters for all users: it reads the past 7 days' behavior logs from HDFS, groups the data by user ID using a MapReduce job, performs a weighted calculation on each group, and outputs new intent parameters. The Reducer adds user IDs with parameters below a threshold to a deletion list, and overwrites user data with parameters above the threshold in the intent user database (Redis).

[0123] The cleanup task then begins, reading the list of records to be deleted and executing a Lua script for each record. The script queries the recommendation pool database for matching records associated with the user. If `expire_time < NOW()`, it performs a `DELETE` operation. If the record is still valid but the user's interest has decreased, the script marks the matching record as "inactive" and sets the TTL to 24 hours for automatic deletion. Simultaneously, the script releases the user's cached data in Redis and notifies Elasticsearch to delete the user profile document.

[0124] The resource monitoring module periodically checks the database tablespace usage. When the fragmentation rate exceeds 30%, it triggers the OPTIMIZETABLE operation to reorganize the data files, reclaim the disk space occupied by deleted records, and ensure the long-term performance stability of the system.

[0125] Example 7: (System Architecture Example)

[0126] This embodiment describes a server-side modular system deployment architecture.

[0127] The system adopts a microservice architecture and is deployed on a Kubernetes cluster, with each module serving an independent Pod.

[0128] The data acquisition and processing module is deployed as a Flink job cluster, with 3 TaskManager Pods, each allocated 4 CPU cores and 8GB of memory. The module consumes data through the Kafka Topic "user-behavior-log," and after computation, writes high-intent user data to a Redis Cluster (3-master 3-slave architecture). The module is configured with a checkpoint mechanism, taking a snapshot of the processing status to HDFS every 5 minutes to ensure fault recovery capabilities.

[0129] The matching relationship generation module is deployed as a Spring Boot application with two Pod instances, registered with Nacos via service discovery. The module listens for Redis KeySpace notifications, triggering matching logic when new high-intent user data is written. During matching algorithm execution, it queries the sales service capability parameters in a PostgreSQL database (master-slave architecture, 1 master, 2 slaves), and writes the generated matching relationship records to a MySQL recommendation pool database (sharded and partitioned, 16 shards).

[0130] The recommendation pool storage module consists of a MySQL database cluster and a Redis caching layer. The MySQL database uses the InnoDB engine and is configured with binlog master-slave synchronization; the Redis caches hot-spot matching records with an expiration time of 10 minutes to reduce database query pressure.

[0131] The scheduled push engine is deployed as an XXL-JOB executor with 5 Pods, and Cron expressions are configured uniformly through the scheduling center. After querying the MySQL recommendation pool, the executor calls the Netty push service (deployed independently, 2 Pods, maintaining a long-lived connection).

[0132] The security verification gateway runs as a Lua plugin for the Nginx Ingress Controller. Each Ingress node loads a verification script to ensure that all chat requests are verified by the gateway. Gateway logs are collected by Filebeat to Kafka, parsed by Logstash, and stored in Elasticsearch for security auditing.

[0133] Each module exposes its internal interface through Kubernetes Service, communicates using the gRPC protocol, and is configured with Istio service mesh to implement circuit breaking and rate limiting, ensuring the overall stability of the system.

[0134] Example 8: (Layered Example of Security Verification Gateway)

[0135] This embodiment describes in detail the layered architecture of the security verification gateway.

[0136] The client access control layer is implemented as a Lua script for Nginx Ingress, with the script file located at ` / etc / nginx / lua / access_check.lua`. When Nginx configures the location ` / api / chat / {}`, it loads the script via the `access_by_lua_file` directive. The script execution flow is as follows: extract the Authorization field from the request header, decode the JWT to obtain the seller_id; extract the user_id from the QueryString; construct an SQL statement to query the MySQL recommendation pool; if the query fails or there are no valid records, call `ngx.say` to return a JSON error body and execute `ngx.exit(403)`.

[0137] If the query is successful, set ngx.req.set_header("X-Match-Valid", "true") and allow the query.

[0138] The server-side message interception layer serves as an AOP aspect implementation in the Spring Boot application, with the `@Around` annotation on the `chatMessage()` method. The method execution flow is as follows: The `seller_id` is retrieved from the WebSocket Session, and the `user_id` is parsed from the message body; the `MatchCacheService` is called to query the Redis cache (key format: `match:{seller_id}:{user_id}`). If the cache misses, the MySQL recommendation pool is checked; if the query result is null or the `expire_time` has expired, the aspect throws an `InvalidMatchException`, which is caught by the global exception handler and an error frame is sent to the WebSocket Session; if the query succeeds, the aspect allows `proceed()` to execute subsequent business logic and writes the query result to the Redis cache (TTL=60 seconds). This layered design ensures that even if the Nginx layer is bypassed, the application layer can still intercept illegal requests.

[0139] Example 9: (Electronic Device Example)

[0140] This embodiment describes a physical electronic device that carries the method of the present invention.

[0141] The electronic equipment uses a Dell PowerEdge R740 rack server, configured with dual Intel Xeon Gold5218 processors, each with 16 cores and 32 threads, a base frequency of 2.3GHz, and support for Hyper-Threading technology. The server is equipped with 128GB of DDR4 ECC memory at a frequency of 2933MHz, supporting memory mirroring and hot-swapping technology to ensure data reliability.

[0142] The storage system adopts a hybrid architecture: the system disk is configured with two 480GB SATA SSDs, forming a RAID1 array, and runs CentOS 7.9 operating system and Kubernetes container runtime; the data disk is configured with six 2TB SAS hard drives, forming a RAID10 array, mounted to the / var / lib / mysql directory to store the recommended pool database and log files; the cache layer is configured with one 1.6TB NVMe SSD as the persistent storage medium for Redis.

[0143] The network interface is configured with four Gigabit Ethernet ports, two of which are bound as bond0 for cluster management network, and the other two as bond1 for business network, supporting load balancing and failover. The server is powered by dual independent PDUs and is equipped with a 550W redundant power supply.

[0144] When the processor executes computer-executable instructions, it first loads the Flink runtime environment and starts the TaskManager process of the data acquisition and processing module; then it loads the Spring Boot framework and starts the Java process of the matching relationship generation module; next, it initializes the MySQL and Redis service processes and loads the data files of the recommendation pool storage module; then it starts the XXL-JOB executor process and the Netty push service process; finally, it loads the Nginx and Lua scripts and starts the security verification gateway. All processes are orchestrated through Kubernetes, sharing processor resources and memory space, and collaboratively complete the full functionality of reverse session establishment.

[0145] By adopting the above-disclosed technical solution of this invention, the following beneficial effects are obtained:

[0146] This invention achieves a technical balance between proactive sales outreach and user privacy protection through a modular system architecture deployed on the server side and a recommendation pool database mechanism, resulting in significant comprehensive technical effects.

[0147] The system captures user behavior logs in real time through a data acquisition and processing module. Through parameter calculation and threshold filtering, it automatically identifies high-intent users, improving data processing efficiency and enhancing coverage compared to traditional manual screening. The matching relationship generation module uses a vector similarity algorithm based on geographic location and demand characteristics to perform quantitative matching between sales and users on the server side. The matching results directly drive subsequent push notifications and verification processes, avoiding data inconsistencies between modules.

[0148] The recommendation pool storage module serves as the core data hub, persistently storing matching relationships, historical active periods, and timeliness markers, enabling a single data source to support multi-module collaboration. The scheduled push engine mirrors historical active periods, pinpointing message delivery times to the user's preference window at the system level, significantly reducing disruptions during inactive periods. This time synchronization mechanism is tightly integrated with the recommendation pool storage, replacing an independent scheduling system and reducing architectural complexity.

[0149] The security verification gateway sets up a dual verification layer at the critical path of session establishment. Both the client access control layer and the server message interception layer query the same recommendation pool storage, dynamically verifying the matching validity based on time-sensitive tags. This design abandons the static permission model, binding permission control to the business matching lifecycle, forming a temporary, automatically invalidating security barrier. This prevents malicious traversal of user data while avoiding excessive permission restrictions that could lead to a loss of business flexibility.

[0150] Overall, this invention, through the reuse design of the recommendation pool storage module, simultaneously achieves three functions at the system level: accurate matching, time-synchronized push notifications, and dynamic access control. This reduces coupling between modules, decreases database query frequency, and improves server resource utilization. A timeliness-based marking mechanism is implemented throughout the matching, push, and verification processes, enabling automatic data expiration and cleanup, ensuring long-term system performance. This architectural design produces unexpected collaborative technical effects, improving sales outreach efficiency while protecting user privacy, enhancing system security and stability, and providing a scalable technical solution for instant messaging platforms.

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

Claims

1. A chat method for initiating a conversation in reverse, characterized in that, Perform the following steps on the server side: The system acquires user behavior log data on the client through a data acquisition interface, calculates user intention parameters based on the behavior log data, and marks users whose user intention parameters are higher than a preset threshold as high-intent users and writes them into the intention user database. Based on the geographic location attributes, demand feature vectors, and sales service capability parameters of the highly interested users, a matching algorithm is used to generate a record of matching relationships between users and sales personnel. The matching relationship records and the user's historical active time period data are persistently stored in the recommendation pool database, and a time-sensitive tag is set for each matching relationship record; The system queries the recommendation pool database at preset time intervals using a scheduled task thread, retrieves user data that matches the historical active period with the current server time, and calls the message push interface to send the user data to the corresponding sales client. When a chat request initiated by a salesperson is received, the system queries the recommendation pool database to verify the validity of the timeliness tag. If the matching relationship record is valid, a session connection channel is established; otherwise, the request is rejected and an error code is returned.

2. The method according to claim 1, characterized in that, The steps for calculating user intention parameters include: assigning weight coefficients to browsing behaviors of different page types, generating scores by combining page dwell time, and obtaining the user intention parameters through weighted summation.

3. The method according to claim 1, characterized in that, The steps for generating matching relationship records include: filtering sales within the service coverage area based on user geographic location attributes, calculating the matching degree based on the similarity between demand feature vectors and service capability parameters, and selecting the sales with the highest matching degree to generate matching relationship records.

4. The method according to claim 1, characterized in that, The steps for querying the recommendation pool database to verify the timeliness mark include: in the client verification stage, intercepting the salesperson's access request to the user and querying whether there are any unexpired matching relationship records in the recommendation pool database; in the server verification stage, intercepting the message body, querying the matching relationship record again, and verifying the timeliness mark.

5. The method according to claim 1, characterized in that, The scheduled task thread adopts a distributed scheduling framework. The operation of querying the recommendation pool database includes: retrieving user data that falls within the current time slice based on the time shard index, sending the data through the batch push interface, and updating the push status bit in the recommendation pool database.

6. The method according to claim 1, characterized in that, The method further includes: recalculating the intention parameters of all users at a preset period, updating the intention user database, deleting invalid matching relationship records, and releasing database resources.

7. A chat system for initiating conversations in reverse, characterized in that, The system is deployed on the server side and includes: The data acquisition and processing module is used to acquire user behavior log data, calculate user intention parameters, and manage the database of potential users. The matching relationship generation module is used to execute matching algorithms to generate matching relationship records between users and sales. The recommendation pool storage module is used to persistently store the matching relationship records, historical active period data, and timeliness tags; The scheduled push engine is used to execute scheduled task threads to query the recommendation pool storage module and call the message push interface; The security verification gateway is used to query the recommendation pool storage module to verify the validity period flag when receiving chat requests, and to control the establishment and rejection of session connection channels.

8. The system according to claim 7, characterized in that, The security verification gateway includes a client access control layer and a server message interception layer, which respectively perform dual verification operations.

9. An electronic device, characterized in that, include: Memory is used to store executable instructions for a computer; A processor for executing the computer-executable instructions to implement the steps of the method as claimed in any one of claims 1-6.

Images