Method, device and equipment for determining closeness between users and storage medium

Abstract

The present disclosure provides a method and device for determining the intimacy between users, and a storage medium. The method acquires a distributed lock for each room when a settlement event is triggered, and stores the state data of all users in each room in a hash structure according to the room identifier, thereby avoiding the square-level overhead caused by maintaining independent timers for each pair of users. The user's entry and exit only need to write their own state data, without traversing other users, thereby greatly reducing the calculation overhead of high-frequency entry and exit scenarios. The distributed lock is released immediately after traversing the user state of the room and determining the online period, thereby minimizing lock contention. Any two users form a user pair, the common online period is determined according to the online period, and a cross-period remainder accumulation mechanism is introduced to combine the insufficient measurement unit of time left in the last period with the current period, and convert it into intimacy integration, thereby avoiding the statistical distortion caused by accumulating a fixed time length only according to the instantaneous state, and achieving high-precision intimacy quantization at low maintenance cost.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a method, apparatus, device, and storage medium for determining the intimacy between users. Background Technology

[0002] For internet social entertainment platforms, voice chat rooms are a core interactive scenario. To enhance the user's social experience, the platform typically needs to calculate and maintain the intimacy level between users based on their interactive behavior within the same room. This intimacy level is then used to implement functions such as displaying intimacy levels, upgrading intimacy relationships, social rankings, and friend recommendations, thereby building and improving the platform's social relationship chain.

[0003] When determining the intimacy level between users, a separate timer is typically maintained for each pair of users in the room; that is, one timer is maintained for every two users. Accordingly, when there are... When there are individual users, maintenance is required. There are multiple timers. In other words, as the user base grows, the number of timers maintained by the platform increases, leading to higher dimensional costs. Furthermore, since each time a user enters or leaves a room, it's necessary to iterate through all other online users in the room to update the timer status for the corresponding user pair, the overall dimensional cost increases quadratically with the number of users. Therefore, to reduce the computational overhead of real-time timer start / stop, related technologies typically employ a periodic settlement strategy, which updates the timers in batches based on the user's online status at the end of a fixed period. Correspondingly, at the intimacy settlement time, it's determined whether the current user is in the room with other users. If both are online, a fixed duration, such as 30 seconds, is added to the timer for that user pair to calculate intimacy. While this avoids complex real-time timing logic, it fails to reflect the actual difference in online time within the settlement period because it only accumulates a fixed duration based on the online status at the settlement time. For example, if one user is online throughout the entire period, while another user only enters the room a few seconds before settlement, both will still have the same duration added, causing the statistical calculation of shared online time to be inconsistent with the actual situation, thus distorting the intimacy statistics. Summary of the Invention

[0004] This disclosure provides a method, apparatus, device, and storage medium for determining the intimacy between users, in order to at least solve the above-mentioned technical problems existing in the prior art.

[0005] A first aspect of this disclosure provides a method for determining the intimacy level between users, the method comprising: In response to the intimacy settlement event, the current settlement time is determined, and a distributed lock is acquired for each room with user status data. The distributed lock is used to indicate that the user status data of the room in the distributed cache has stopped being updated. At the current settlement time, the user status data of the room is obtained from the corresponding hash structure of the distributed cache according to the room identifier of the room; Based on the acquired user status data of the room, determine the online time period of each user in the room within the current settlement period corresponding to the current settlement time, and release the distributed lock of the room; Based on the user status data of all rooms obtained, determine any two users forming a user pair, and determine at least one common online time period of the user pair in the same room; For each user pair, obtain the remaining shared online time of the user pair in the previous settlement period, and calculate the intimacy of the user pair based on the remaining shared online time and the shared online time periods of all the same rooms of the user pair in the current settlement period. The remaining shared online time is the shared online time of the user pair after the intimacy calculation in the previous settlement period that does not meet a unit of measurement.

[0006] In one possible implementation, the user status data of the room includes the time when the user's online status and / or offline status in the room is updated each time, as well as the corresponding user identifier, and the adjacent online time and offline time corresponding to the same user identifier form a status group. The step of determining the online time period of each user in the room within the current settlement period corresponding to the current settlement time, based on the acquired user status data of the room, includes: For each user, determine whether the user is in the room at the current billing time; In response to the user's offline time in the last status group within the current billing cycle being equal to zero, it is determined that the user is in the room at the current billing time. The online time period of the status group is determined based on the current billing time and the online time in the last status group. If other status groups exist, the online time period of the corresponding status group is determined based on the offline time and online time in the other status groups. The online time of the last status group is then updated to the current billing time. In response to the user's offline time being greater than zero in the last status group within the current settlement period, it is determined that the user has left the room at the current settlement time. The online time period of the status group is determined based on the offline time and online time in each status group, and the corresponding user status data of the room is marked as data to be deleted. After determining the online time periods of all users in the room, release the distributed lock for the room and delete the data to be deleted from the distributed cache.

[0007] In one possible implementation, determining that the user has at least one shared online time period in the same room includes: Based on the online time periods of each user in all rooms in the user pair, the intersection of the online time periods of the two users in the user pair in at least one room is determined as the common online time period.

[0008] In one possible implementation, calculating the intimacy of the user pair based on the remaining shared online time and the shared online time periods of all identical rooms for the user pair within the current billing cycle includes: For the user pair, the corresponding common online duration is determined based on the common online time periods of the user pair in all the same rooms within the current settlement cycle; The total shared online time for the current settlement period is summed with the remaining shared online time for the previous settlement period to obtain the cumulative shared online time. The ratio of the cumulative shared online time to the unit of measurement is determined as the intimacy value of the user pair in the current settlement period, and the remaining time in the cumulative shared online time that does not meet the unit of measurement corresponding to the intimacy value is taken as the remaining shared online time of the user pair in the current settlement period. Obtain the existing intimacy value of the user pair, and update the real-time intimacy value of the user pair based on the existing intimacy value and the intimacy value of the current settlement period.

[0009] In one possible implementation, before obtaining the remaining shared online time for each user pair in the previous settlement period, the method further includes: Determine whether the total online time of each user pair in all common online periods in the current settlement period exceeds a safety threshold, and filter out all common online periods of the corresponding user pair that exceed the safety threshold. The safety threshold is determined based on the duration of the settlement period.

[0010] In one possible implementation, the method further includes: In response to the completion of the intimacy calculation for the current settlement period, a corresponding room management strategy is determined based on whether a user exists in each room at the current settlement time.

[0011] In one possible implementation, determining the corresponding room management strategy based on whether a user exists in each room at the current settlement time includes: In response to the presence of at least one user in the room, update the validity period of the corresponding hash structure for that room in the distributed cache; In response to the absence of any user in the room, the last settlement time of the room is determined, and the hash structure of the room in the distributed cache is cleared when the difference between the last settlement time and the current settlement time exceeds the security threshold.

[0012] A second aspect of this disclosure provides an apparatus for determining the intimacy between users, the apparatus comprising: The periodic triggering module is used to respond to the intimacy settlement event, determine the current settlement time, and acquire a distributed lock for each room with user status data; The data acquisition module is used to obtain the user status data of the room from the corresponding hash structure of the distributed cache according to the room identifier at the current settlement time. The time period calculation module is used to determine the online time period of each user in the room within the current settlement period corresponding to the current settlement time based on the acquired user status data of the room, and release the distributed lock of the room; The pairing calculation module is used to determine any two users forming a user pair based on the user status data of all rooms acquired, and to determine at least one common online time period of the user pair in the same room; The intimacy calculation module is used to obtain the remaining shared online time of each user pair in the previous settlement period, and calculate the intimacy of the user pair based on the remaining shared online time and the shared online time periods of all the same rooms of the user pair in the current settlement period. The remaining shared online time is the shared online time of the user pair after the intimacy calculation in the previous settlement period that does not meet a unit of measurement.

[0013] A third aspect of this disclosure provides an electronic device comprising: At least one processor; and a memory connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method for determining user intimacy as described in this disclosure.

[0014] A fourth aspect of this disclosure provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform the method for determining user intimacy described in this disclosure.

[0015] This disclosure discloses a method for determining user intimacy. The current settlement time is determined upon triggering an intimacy settlement event, and a distributed lock is acquired for each room. This ensures that only one service instance processes the same room within the same settlement cycle, avoiding duplicate calculations caused by multiple concurrent instances. Furthermore, the state data of all users within each room is stored in a distributed cache using the room identifier as a hash structure name. This ensures that the maintenance of the total state data within a room is linearly related only to the number of users in that room, effectively preventing the quadratic growth in state data maintenance caused by independent timers for each pair of users in related technologies. Simultaneously, when a user enters a room, they only need to write or update their own state data, eliminating the need to traverse all other users' data to update, as is required in related technologies. This invention addresses the issue of timers, significantly reducing computational overhead in high-frequency entry and exit scenarios. Furthermore, it iterates through user status data within a room, determines each user's online time within the current settlement period, and immediately releases the distributed lock to minimize lock holding time, significantly reducing lock contention overhead and improving overall system throughput. Moreover, by forming user pairs with any two users, the shared online time of the pair is determined based on each user's online time, fully reflecting the actual shared online duration of any two users in the current settlement period. Simultaneously, a cross-period remainder accumulation mechanism is introduced, merging the shared online duration (less than one unit of measurement) left over from the previous period with the total duration of all shared online time periods in the current period, converting it into an intimacy value after meeting the required unit of measurement. The intimacy result obtained in this way is more accurate than that obtained in related technologies, which only accumulate a fixed duration for all users based on the instantaneous room status at settlement, resulting in statistical distortion. This achieves the goal of ensuring both low maintenance costs and accurate intimacy results.

[0016] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0017] The above and other objects, features, and advantages of this disclosure will become readily apparent from the following detailed description of exemplary embodiments, taken in conjunction with the accompanying drawings. Several embodiments of this disclosure are illustrated in the drawings by way of example and not limitation, in which: In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts.

[0018] Figure 1 This illustration shows the implementation flow of a method for determining the intimacy between users according to an embodiment of the present disclosure. Figure 1 ; Figure 2A schematic diagram of the modules of a device for determining the intimacy between users according to an embodiment of the present disclosure is shown; Figure 3 A schematic diagram of the composition structure of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0019] To make the objectives, features, and advantages of this disclosure more apparent and understandable, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0020] Voice chat rooms are a core interactive scenario on current internet social entertainment platforms. Platforms typically determine the intimacy level between users based on their interactions with the room, thereby promoting the construction of internet social relationship chains, such as intimacy rankings and friend recommendations. In related technologies, when determining the intimacy level between users, an independent calculator is usually used for each pair of users within the same voice chat room. That is, each pair of users maintains an independent timer, which is started and stopped when a user enters or leaves the room, achieving real-time statistics on each user's online time. Correspondingly, when multiple users exist in the same room, corresponding timers need to be maintained. There are 1 timer, where N is the number of users in the current room. Each time a user enters or leaves the room, it is necessary to iterate through all other online users in the room to update the timer status of the corresponding user pair. The maintenance cost increases quadratically with the increase in the number of users in the room, which means the maintenance cost is too high.

[0021] To reduce platform maintenance costs, some technologies employ a periodic settlement strategy. Accordingly, at the moment of intimacy settlement, it's determined whether the current user is also in the room with other users. If both are online, a fixed duration, such as 30 seconds, is added to the timer for that pair of users to calculate intimacy. While this avoids complex real-time timing logic, it fails to reflect the actual difference in online time throughout the settlement period because it only accumulates a fixed duration based on online status at the time of settlement. For example, if one user is online throughout the entire period, while another only enters the room a few seconds before settlement, both will still have the same duration added, leading to a discrepancy between the statistically calculated shared online time and the actual situation, thus distorting the intimacy statistics.

[0022] In addition, some technologies employ offline log backtesting: recording all users' room entry and exit logs, periodically analyzing the logs in an offline computing environment, and calculating the common online time of user pairs by calculating the intersection of time periods. While this solution avoids the state explosion problem of real-time timers, its real-time performance is poor, typically producing results on an hourly or daily basis, which cannot support online intimacy display and real-time leaderboard updates, nor can it meet users' needs for immediate feedback.

[0023] This disclosure provides a method for determining the intimacy between users to at least solve the aforementioned technical problems. This method is applied to an electronic device, which can be a smart terminal or server containing a central processing unit. The smart terminal can be a mobile phone, a personal digital assistant (PAD), a tablet computer, a laptop computer, a desktop computer, etc. The server can be a standalone physical server, a server cluster consisting of multiple physical servers, or a distributed system, such as... Figure 1 As shown, the method includes: S101. In response to the intimacy settlement event, determine the current settlement time and acquire a distributed lock for each room with user status data.

[0024] In this step, the intimacy settlement event refers to a timed settlement trigger event that the system periodically sends to each room that records user status data at preset fixed time intervals. The rooms in this step can be voice chat rooms, specifically those rooms that have user status data for the current settlement period. The fixed time interval can be set according to different application scenarios; for example, it can be set to trigger an intimacy settlement event every 30 seconds to periodically count the status of each user in the room, thereby achieving iterative calculation of intimacy between users.

[0025] Accordingly, when the intimacy settlement event is triggered, the current settlement time is determined. It should be noted that the current settlement time in this step refers to the end timestamp of the current settlement period after the intimacy settlement event is triggered. For example, if an intimacy settlement event is triggered every 30 seconds, the current settlement time is 10:00:00, and the current settlement period is 9:59:30-10:00:00. Simultaneously, when the intimacy settlement event is triggered, a distributed lock is acquired for each room containing user state data to ensure that only one service instance performs the settlement operation for that room at the current settlement time, avoiding duplicate calculations or state errors caused by multiple concurrent instances.

[0026] S102. At the current settlement time, retrieve the user status data of the room from the corresponding hash structure of the distributed cache based on the room identifier.

[0027] In this step, after acquiring the distributed lock, the user status data corresponding to each room at the current settlement time is retrieved from the distributed cache based on the room identifier. It should be noted that in this step, all user status data for the same room are stored in the same hash structure, with the room identifier serving as the unique name of this hash structure. This allows for direct location and retrieval of the user status data for the corresponding settlement period at each settlement time using the room identifier.

[0028] It should be noted that the room identifier in this step includes the room type (roomType) and the room number (roomId), such as voiceRoom_12345. Using the room identifier as the name of the hash structure allows direct location of the user status data of the target room in the distributed cache via the key name. Furthermore, it eliminates the need to maintain an independent timer for each user pair; only the corresponding status record, i.e., user status data, needs to be maintained for each user within each room. The total number of statuses within a room is linearly related only to the number of users N, fundamentally avoiding the memory and storage pressure caused by an excessive number of user pairs in related technologies.

[0029] In addition, in related technologies, each time a user enters or leaves a room, it is necessary to iterate through all other users in the current room and update the corresponding N-1 timers. However, this step only scans the status data of all users in the room at the periodic settlement time. The operation of a user entering or leaving the room only needs to write or update one piece of user status data for themselves, without triggering any real-time updates for other users, which significantly reduces the system load in high-frequency entry and exit scenarios.

[0030] S103. Based on the obtained user status data of the room, determine the online time period of each user in the room within the current settlement period corresponding to the current settlement time, and release the distributed lock of the room.

[0031] In this step, for each room, after successfully retrieving user status data from the corresponding hash structure, each user status record for each user in that room is traversed to determine each user's online time period in that room within the current settlement period. It should be noted that the same user may enter multiple rooms within the current settlement period. For example, in one scenario, user A enters room 1 in the current settlement period, exits, and then re-enters room 1 after a few seconds. In this case, user A has two online time periods in the hash structure corresponding to room 1. Both need to be determined to serve as the data basis for subsequent intimacy calculations. In another scenario, user A has corresponding user status data in both room 1 and room 2 within the current settlement period. Accordingly, the user's online time period in room 1 is determined based on the user status data in the hash structure corresponding to room 1, and the user's online time period in room 2 is determined based on the user status data in the hash structure corresponding to room 2. The online time periods in both rooms are used to subsequently determine intimacy.

[0032] It should be noted that the distributed lock of the room is released immediately after determining the online time of each user within the current settlement period. This step of releasing the distributed lock is preferably performed before other time-consuming operations, including user pairing calculations, deletion of user status data after leaving the room, or intimacy conversion calculations. This minimizes the holding time of the distributed lock, avoids blocking other concurrent events, such as user entry and exit write operations within the room, significantly reduces the contention overhead of the distributed lock, and improves the overall system throughput.

[0033] S104. Based on the user status data of all rooms obtained, determine any two users forming a user pair, and determine at least one common online time period of the user pair in the same room.

[0034] In this step, for the current settlement cycle, each user determines at least one online time period based on their corresponding user status data, thus obtaining the set of online time periods for all users participating in the settlement in this round. Accordingly, among all users participating in the settlement, any two users form a user pair, and at least one common online time period is determined for each user pair in the same room.

[0035] For example, if the current settlement period is 9:59:30-10:00:00, in one scenario, user A is online in room 1 from 9:59:30 to 10:00:00, which is the entire current settlement period. User B is online in room 1 from 9:59:42 to 10:00:00, meaning they entered room 1 midway. Accordingly, the shared online period for users A and B in room 1 is 9:59:42-10:00:00, which serves as the data basis for subsequently determining the intimacy between users A and B. In another scenario, user A is online in room 1 from 9:59:30 to 9:59:42 and in room 2 from 9:59:30 to 10:00:00. From 9:48 to 10:00:00, User B's online time in Room 1 was 9:59:30-9:59:42, and in Room 2 it was 9:59:50-10:00:00. Correspondingly, User A and User B's shared online time in Room 1 was 9:59:30-9:59:42, and in Room 2 it was 9:59:50-10:00:00. This means that User A and User B each had a shared online time in two different rooms during the current settlement period. These shared online time periods form the data basis for calculating the intimacy level between User A and User B, ensuring accurate calculation of the intimacy level for this user pair. In other words, multiple shared online time periods for the same user pair in different rooms are included in subsequent intimacy calculations, comprehensively reflecting the actual time a user pair spends together in all rooms and avoiding omissions due to room isolation.

[0036] S105. For each user pair, obtain the remaining shared online time of the user pair in the previous settlement period, and calculate the intimacy of the user pair based on the remaining shared online time and the shared online time periods of all the same rooms of the user pair in the current settlement period. The remaining shared online time is the shared online time of the user pair after the intimacy calculation in the previous settlement period that does not meet one unit of measurement.

[0037] In this step, the intimacy level of each user pair is determined based on the duration of their shared online time within the current settlement period. Simultaneously, for each user pair, the remaining shared online time from the previous settlement period is retrieved from storage and combined with the shared online time in the current settlement period to ultimately determine the intimacy value for that user pair.

[0038] It should be noted that the remaining shared online time in this step refers to the shared online time that does not meet one unit of intimacy measurement after the intimacy calculation of the user pair in the previous settlement period. For example, if one unit of measurement is 60 seconds, then for every 60 seconds of shared online time of a user pair, the corresponding intimacy value increases by one point. If the shared online time of a user pair in the current settlement period is 30 seconds, and the remaining shared online time in the previous settlement period is also 30 seconds, then it can be determined that the intimacy value of the user pair will increase by one point in the current settlement period. Through the above-mentioned cross-period remainder accumulation mechanism, it can be ensured that shared online time less than one unit of measurement is not lost, but continues to accumulate in subsequent periods until it reaches one unit of measurement, and is converted into intimacy points, thus ensuring the continuity and accuracy of intimacy statistics.

[0039] The method for determining user intimacy disclosed herein determines the current settlement time upon triggering an intimacy settlement event and acquires a distributed lock for each room, ensuring that only one service instance processes the same room within the same settlement cycle, thus avoiding duplicate calculations caused by multiple concurrent instances. Furthermore, the state data of all users within each room is stored in a distributed cache using the room identifier as the hash structure name. This ensures that the maintenance of the total state data within a room is linearly related only to the number of users in that room, effectively preventing the quadratic growth in state data maintenance caused by independent timers for each pair of users in related technologies. Simultaneously, when a user enters a room, they only need to write or update their own state data, eliminating the need to traverse all other users' data to update, as is required in related technologies. This addresses the issue of timers, significantly reducing computational overhead in high-frequency entry and exit scenarios. Furthermore, this disclosure iterates through user status data within a room, determines each user's online time period within the current settlement cycle, and immediately releases the distributed lock to minimize lock holding time, significantly reducing lock contention overhead and improving overall system throughput. Moreover, by forming user pairs with any two users, the shared online time period of the user pair is determined based on each user's online time period, fully reflecting the actual shared online duration of any two users in the current settlement cycle. Simultaneously, a cross-cycle remainder accumulation mechanism is introduced, merging the shared online duration less than one unit from the previous cycle with the total duration of all shared online time periods in the current cycle, converting it into an intimacy value after meeting the unit requirement. The intimacy result obtained in this way is more accurate than the statistical distortion caused by simply accumulating a fixed duration for all users based on the instantaneous room status at settlement time in related technologies, thus achieving the goal of ensuring both low maintenance costs and accurate intimacy results.

[0040] In one possible implementation, the user status data of the room includes the time when the user's online status and / or offline status in the room is updated each time, as well as the corresponding user identifier, and the adjacent online time and offline time corresponding to the same user identifier form a status group. Based on the acquired user status data for the room, determine the online time period of each user in that room within the current billing cycle at the current billing time, including: For each user, determine whether the user is in the room at the current billing time; In response to the fact that the user's offline time in the last status group during the current billing cycle is equal to zero, it is determined that the user is in the room at the current billing time. The online time period of the status group is determined based on the current billing time and the online time in the last status group. If other status groups exist, the online time period of the corresponding status group is determined based on the offline time and online time in the other status groups. The online time of the last status group is updated to the current billing time. In response to the fact that the user's offline time in the last status group within the current settlement period is greater than zero, it is determined that the user has left the room at the current settlement time. Based on the offline time and online time in each status group, the online time period of that status group is determined, and the corresponding user status data of the room is marked as data to be deleted. After determining the online time periods of all users in the room, release the distributed lock for the room and delete the data to be deleted from the distributed cache.

[0041] In this embodiment, the user status data stored in the hash structure of each room includes the time of each update of the user's online and / or offline status in that room, as well as the corresponding user identifier. Specifically, the user identifier (userId) in this embodiment is used to distinguish different individual users. Each user is configured with an independent and unique user identifier. In the distributed cache hash structure, the user identifier serves as the distinguishing identifier for a single user status record (UserRoomInfoBean), thereby independently recording the entry and offline times of each user in different rooms.

[0042] It should be noted that, in one scenario, the updateTime corresponding to a user's online status in a room is the time when the user entered the room within the current settlement period. That is, if the user enters the room in the middle of the current settlement period, the online time in the user status data is the time when the user entered the room in the middle. In another scenario, the updateTime corresponding to a user's online status in a room is the start timestamp of the current settlement period. That is, the user was already in the room at the beginning of the current settlement period, which also means that the user did not leave the room in the previous settlement period. Accordingly, the online time in the user status data is the settlement time of the previous settlement period. Moreover, when the calculation of the previous settlement period is completed, the online time in the user's status data has been updated to the settlement time of the previous settlement period. Thus, when settling in the current period, the online time in the process of determining the online time period of the status group is the settlement time of the previous calculation period.

[0043] It should also be noted that, in one scenario, the update time (outTime) corresponding to a user's offline status in the room is the time when the user leaves the room during the current billing cycle. That is, if the user leaves the room in the middle of the current billing cycle, the offline time in the user status data is the time when the user leaves the room in the middle, and correspondingly, the outTime in the user status data is greater than 0. Substituting it into the online time period determined by the corresponding status group gives the actual offline time. In another scenario, the update time corresponding to a user's offline status in the room is the end timestamp of the current billing cycle. That is, if the user is in the room the whole time during the current billing cycle, the outTime in the user status data is 0, and substituting it into the online time period determined by the corresponding status group gives the current billing time.

[0044] Therefore, the specific situations of a user in a room can be categorized into at least the following four types: 1. The user is in the room from the beginning of the current settlement period until its end, with the corresponding user status data including online time (updateTime) equal to the settlement time of the previous settlement period and offline time (outTime=0); 2. The user is in the room from the beginning of the current settlement period but leaves midway, with the corresponding user status data including online time (updateTime) equal to the settlement time of the previous settlement period and offline time (outTime>0); 3. The user enters the room midway through the current settlement period and remains in the room until its end, with the corresponding user status data including online time (updateTime) equal to the actual entry time and offline time (outTime=0); 4. The user enters the room midway through the current settlement period and then leaves midway, with the corresponding user status data including online time (updateTime) equal to the actual entry time and offline time (outTime>0).

[0045] In addition, if a user enters a room multiple times within the same billing cycle, that user will have multiple status records. Each status record corresponds to the user's online status update time (online time) and offline status update time (offline time), recorded according to the user's actual entry and exit from the room in the current billing cycle. For the same user, adjacent online and offline times form a status group, which is one status record.

[0046] It should be noted that for each user, the decision to delete their status data depends on whether they are still in the room at the current settlement time. Specifically, if the user's offline time record in the last status group within the current settlement period is equal to 0, it can be determined that the user is still in the room at the current settlement time. Conversely, if the user's offline time record in the last status group within the current settlement period is greater than 0, it can be determined that the user has left the room at the current settlement time. Accordingly, all status data of that user within the room is marked as data to be deleted. For example, if the current settlement period is 9:59:30-10:00:00, and user A leaves the room at 9:59:58, i.e., outTime>0, then user A's status data is marked as data to be deleted. After determining the online time periods of all users, the room's distributed lock is released, and the data to be deleted is removed from the distributed cache. In other words, the deletion of the status data of users who have left the room at the time of settlement is performed after the lock is released, thereby shortening the lock holding time. During the holding of the distributed lock, only the online time of each user in the current settlement cycle and the update of the user status data are completed, reducing the blocking impact of the distributed lock on operations in high-concurrency scenarios.

[0047] In addition, for each user, the system determines whether to update the user's status data to reflect the last online time (i.e., the online time in the last status group within the current settlement period) based on whether the user is still in the room at the current settlement time. If the user is still in the room at the current settlement time, the system updates the user's last online time (updateTime) within the current settlement period to the current settlement time (now) after determining the user's online time period within the current settlement period.

[0048] It should also be noted that when determining the duration of the corresponding online period based on the user's status data, the calculation method is determined based on the offline time in the status data. If the offline time outTime in a status data entry is 0, the online duration of that status data, i.e., the online duration of the corresponding status group, is determined by the difference between the current settlement time and the online time in that status data entry. If the offline time outTime in a status data entry is greater than 0, the online duration of the corresponding status group is determined by the difference between the offline time and the online time in that data entry.

[0049] For example, if user B enters room 1 at 9:59:50 within the current settlement period and is still in room 1 when settling at 10:00:00, then user B's online time (updateTime) is 9:59:50, and their offline time (outTime) is 0. Accordingly, user B's online time in room 1 during the current settlement period = current settlement time (now) - online time (updateTime) = 10:00:00 - 9:59:50 = 10 seconds. Furthermore, after determining the online duration, user B's user status data is updated with the current settlement time (now), that is, from 9:59:50 to 10:00:00, for use in the calculation of the next settlement period.

[0050] Furthermore, in the next settlement cycle, if user B has not left the room by the end of the next settlement cycle, then in user B's status data, outTime=0 and updateTime=10:00:00. Therefore, the duration of user B's online time in the next settlement cycle = settlement time of the next settlement cycle - online time updateTime = 10:00:30 - 10:00:00 = 30 seconds. In other words, the online time updateTime in the user status data at this time is 10:00:00. After the calculation, the online time updateTime in the user status data at this time is updated with 10:00:30 to be substituted into the calculation for the next cycle, and so on. Repeated steps will not be elaborated further. Similarly, in the next settlement cycle, if user B leaves the room midway through the cycle, such as at 10:00:20, then user B's status data will have outTime > 0, indicating the actual exit time of 10:00:20, and the corresponding online time updateTime in the status data will be 10:00:00. Accordingly, the duration of user B's online time in the next settlement cycle = outTime - updateTime = 10:00:20 - 10:00:00 = 20 seconds. Since user B is no longer in the room at this time, the updateTime in the status data will no longer be updated with the current settlement time, but will be marked as data to be deleted and deleted after the distributed lock is released.

[0051] Similarly, if user B did not enter during the current settlement period but remained in the room, such as being in the room at 9:59:30, it indicates that user B did not leave the room during the previous settlement period. Accordingly, after the duration of the online time in the previous settlement period is determined, the online time updateTime in user B's status data will be updated with the settlement time of the previous settlement period, which is 9:59:30, and then substituted into the current settlement period for calculation.

[0052] Therefore, for each user, if the last offline time (outTime) in the user's status data is 0, it means that the user is still in the room at the current settlement time. In this case, the duration of the user's online time is calculated as the current settlement time (now) minus the last online status update time (updateTime). After calculation, updateTime is updated to now for use in the next cycle. If the last offline time (outTime) in the user's status data is greater than 0, it means that the user has exited at the current settlement time. In this case, the duration of the user's online time is calculated as the actual exit time (outTime) minus the last online status update time (updateTime). After calculation, the user's status data is marked as pending deletion.

[0053] In other words, this embodiment advances the last online status update time in the user's data to the current settlement time after each settlement. This ensures that the next cycle only calculates the newly added online time from that time, without repeatedly counting previously settled historical online periods. This eliminates the need to maintain a separate settled duration field, ensuring that each settlement cycle only calculates unsettled new duration, not the total duration since the user entered the room. This avoids duplicate calculations while ensuring the accuracy of shared online time and intimacy calculations. Furthermore, for users who have logged out, after calculating the corresponding online period, they are marked for deletion, and the deletion operation is moved outside the lock, effectively shortening the holding time of the distributed lock and reducing the blocking risk in high-concurrency scenarios.

[0054] It should also be noted that since the same user may enter the same room multiple times within the current billing cycle, and each entry or exit time corresponds to the writing or updating of the user's status data in the distributed cache. For example, in the current billing cycle of 9:59:30-10:00:00, user A enters room 1 at 9:59:32, leaves at 9:59:45, re-enters room 1 at 9:59:50, and leaves again at 9:59:58. Accordingly, user A has two online status update times within the current billing cycle, namely online times updateTime9:59:32 and updateTime9:59:50, and two offline status update times, namely offline times outTime9:59:45 and outTime9:59:58. For the same user A, adjacent online and offline times form a state group. For example, online time 9:59:32 and offline time 9:59:45 form one state group, and online time 9:59:50 and offline time 9:59:58 form another. The duration of the online period is determined by selecting the appropriate calculation method based on whether the offline time in each state group is equal to 0. In the above example, the offline times in both state groups for user A are greater than 0, so the online duration is determined accordingly based on the difference between the offline and online times in each state group.

[0055] If user A enters room 1 at 9:59:32, leaves at 9:59:45, re-enters room 1 at 9:59:50, and remains there until 10:00:00, then user A's two status data points for the current settlement period correspond to the online time updateTime9:59:32 and offline time outTime9:59:45, and the online time updateTime9:59:50 and offline time outTime=0. Based on these two status data points, the duration of user A's two periods in the current settlement period is determined. The duration of the online period in the first status group = outTime9:59:45 - updateTime9:59:32 = 13s, and the duration of the online period in the second status group = now10:00:00 - updateTime9:59:50 = 10s. After calculation, updateTime9:59:50 in the second status group is updated with now10:00:00, that is, the last online time is updated to the current settlement time for use in the calculation of the next period. In other words, if a user is still in a room at the current settlement time, only the online time in the last status group will be updated with the current settlement time for that user. The online time of the user's other status groups will be calculated based on the offline and online times recorded in the status group, without needing to update the online time accordingly.

[0056] Each user status data point corresponds to an online time period. When calculating intimacy, the duration of each online time period is accumulated to determine the user's total effective online time within the current period. This avoids the loss of time due to users frequently entering and leaving rooms, and also merges multiple records into a single incremental value, simplifying subsequent pairing calculations.

[0057] In one possible implementation, determining at least one shared online time period for users in the same room includes: Based on all online time periods of each user in all rooms in a user pair, determine the intersection of the online time periods of the two users in the user pair in at least one room as the common online time period.

[0058] In this embodiment, let the set of users participating in the settlement for the current settlement period be . Any two users in this user set form a user pair, for example... and For a user pair, and This also constitutes a user pair, and so on. Furthermore, each user in the user set is assigned an online time period in each room during the current billing cycle, and the common online time period of the user pair during the current billing cycle is determined based on the intersection of the online time periods of the two users in each user pair in at least one room.

[0059] For example, the current settlement period is 9:59:30-10:00:00, and the user... If a user enters room 1 at 9:59:32, leaves room 1 at 9:59:40, enters room 2 at 9:59:45, and remains in room 2 until 10:00:00, then for the user... Specifically, within the current settlement period, the online time in Room 1 is from 9:59:32 to 9:59:40, and the online time in Room 2 is from 9:59:45 to 10:00:00 (the current settlement time). For users... In this case, if the user was in room 1 at 9:59:30, left room 1 at 9:59:45, entered room 2 at 9:59:50, and remained in room 2 until 10:00:00, then for the user... In the current settlement period, the online time in Room 1 is from 9:59:30 to 9:59:45, and the online time in Room 2 is from 9:59:50 to the current settlement time of 10:00:00.

[0060] Therefore, it can be concluded that within the current settlement period, the user and users There is an overlap in online time periods in both Room 1 and Room 2. Specifically, in Room 1, the overlap is from online time 9:59:32 to offline time 9:59:40, while in Room 2, it's from online time 9:59:50 to the current settlement time 10:00:00. Both of these overlaps represent user interactions. The system calculates the total time a user spends online together in all social scenarios, and then adds up the duration of the two shared online periods when calculating the user's intimacy score. This is done to ensure that the user's total shared online time in the current settlement period can be accumulated across rooms, making the intimacy score calculation more accurate in reflecting the actual time the two people spend together in all social scenarios and avoiding the omission of time due to room isolation.

[0061] In one possible implementation, the intimacy of the user pair is calculated based on the remaining shared online time and the shared online time of all identical rooms within the current billing cycle, including: For a user pair, the corresponding common online duration is determined based on the common online time period of the user pair in all the same rooms within the current settlement cycle; The total shared online time for the current settlement period is summed up with the remaining shared online time for the previous settlement period to obtain the cumulative shared online time. The ratio of cumulative shared online time to unit of measurement is determined as the intimacy value of the user pair in the current settlement period, and the remaining time in the cumulative shared online time that does not meet the unit of measurement corresponding to the intimacy value is taken as the remaining shared online time of the user pair in the current settlement period. Get the existing intimacy value of the user pair, and update the real-time intimacy value of the user pair based on the existing intimacy value and the intimacy value of the current settlement period.

[0062] In this embodiment, for each user pair, the corresponding shared online duration is determined based on the shared online time periods of the user pair in all the same rooms within the current calculation period. Accordingly, if the two users in a user pair have shared online time periods only in one same room, then the shared online duration of the user pair is the duration of that shared online time period; if the two users in a user pair have shared online time periods in different rooms, then the shared online duration of the user pair is the sum of the durations of the two shared online time periods.

[0063] Furthermore, for each user pair, the remaining shared online time (remainder) in the previous settlement period is obtained and added to the shared online time in the current settlement period to obtain the cumulative shared online time used to determine the intimacy value for the current settlement period. For example, if the remaining shared online time for the user pair in the previous settlement period was 30 seconds, and the shared online time for the user pair in the current settlement period is also 30 seconds, then for this user pair, the data basis for calculating the intimacy value is 30 seconds + 30 seconds = 60 seconds. The remaining shared online time (remainder) in the previous settlement period is preferably set to expire after 24 hours. Accordingly, if it is the first settlement, or the remaining shared online time has expired, then the remaining time is 0.

[0064] Furthermore, the user's affinity score for the current settlement period is determined based on the ratio of the cumulative shared online time to the calculation unit, using the following formula:

[0065] In the formula, This represents the intimacy value generated during the current settlement period. The remaining common online time for the previous settlement period. The common online duration for the current settlement period, This is the rounding down symbol. One point is counted for every full minute, and fractions of a minute are not counted.

[0066] In addition, the remaining common online time for the current settlement period is expressed by the following formula:

[0067] In the formula, This represents the remaining common online time for the current settlement period, in milliseconds. mod60000 is the modulo operation, which means retaining the remainder after dividing the total time by 60000, i.e., the time less than 1 minute.

[0068] Therefore, this embodiment combines the remaining time (less than one unit of measurement) from the previous settlement period with the newly added shared online time in the current period. The combined total time is rounded down to the nearest whole number (1 minute) to obtain the intimacy score. The remainder of the combined total time (less than one unit of measurement) is used as the new remaining time to be carried over to the next period for continuous accumulation, ensuring continuous and lossless calculation of time. The remaining shared online time in the current settlement period is set to expire in 24 hours and automatically reset to zero upon crossing a day.

[0069] It should be noted that the intimacy calculation for the current settlement period is the intimacy increment corresponding to the current settlement period. This intimacy increment is added to the user's existing intimacy value to obtain the real-time intimacy of the user pair. This enables the periodic iterative update of intimacy points, supporting near real-time response for functions such as real-time leaderboard refresh, intimacy display, and friend recommendation on social platforms.

[0070] In one possible implementation, for each user pair, before obtaining the remaining shared online time of that user pair in the previous settlement period, the method further includes: Determine whether the total online time of each user pair in all common online periods during the current settlement period exceeds the safety threshold, and filter out all common online periods of the corresponding user pair that exceed the safety threshold. The safety threshold is determined based on the duration of the settlement period.

[0071] In this embodiment, before performing the actual calculation of intimacy, it is necessary to verify the legality of the shared online time of the user pairs participating in this round of settlement. Accordingly, let the current settlement period be stayTime, in milliseconds, and the security threshold in this embodiment be 3 × stayTime.

[0072] Furthermore, for each user pair, the total duration of their shared online time obtained from all the same rooms within the current billing cycle. Compare with the aforementioned security thresholds. If... Then determine If the data is valid, it will be retained for subsequent intimacy value calculations; otherwise, if... Then determine If the data is considered abnormal, discard all shared online periods for that user during this period, and the user will not participate in the points calculation for this period or any subsequent periods.

[0073] It should be noted that the preferred safety threshold in this embodiment is [value missing]. The reason is that, within a normal settlement cycle, the total duration of shared online time for any user pair cannot exceed three times the length of that cycle. However, abnormal situations such as cache remnants, clock drift, or server restarts without clearing historical states can lead to calculated durations far exceeding the normal range. Specifically, cache remnants refer to situations where a user's historical online status records are not deleted in time due to program malfunctions, causing their user status data to remain several hours in advance. The shared online time calculated based on this user's status data far exceeds the safety threshold. Clock drift refers to slight differences in system clocks between different server nodes in a distributed environment, which may cause timestamp calculation errors, resulting in abnormally large durations. Server restarts without clearing historical states refer to situations where, after a service instance restarts, the distributed cache still retains the settlement status from the previous round that was not properly completed, resulting in excessively long durations when mixed with the new cycle data.

[0074] By performing the aforementioned anomaly data verification, we can effectively prevent the injection of excessively large duration data into the intimacy points system due to system anomalies, such as data residue in the distributed cache or historical states not cleared after service restarts. This prevents abnormal jumps in intimacy values. The filtered, legitimate data is used in subsequent steps to accumulate and convert the shared online time from the previous period, thus ensuring the stability and reliability of the intimacy measurement results. Furthermore, the aforementioned legitimate data, as well as other legitimate data calculated subsequently, including user identifiers, shared online time, generated point increments, and timestamps, can be asynchronously written to persistent storage for historical record queries and backtracking.

[0075] In one possible implementation, the method further includes: In response to the completion of the intimacy calculation for the current settlement period, the corresponding room management strategy is determined based on whether there are users in each room at the current settlement time.

[0076] In this embodiment, after the intimacy calculation is completed in each settlement cycle, including user verification of shared online time, point conversion, and remaining balance updates, the system needs to perform lifecycle management on the state of each room in the distributed cache. Accordingly, based on the current settlement time, it is determined whether each room still has at least one valid user at the current time, meaning that the hash structure corresponding to that room contains at least one user state data entry with outTime=0. Based on the determination result, a differentiated room management strategy is executed.

[0077] It should be noted that if a room has at least one active user, it indicates that the room is still active, and the lifespan of its user status data in the distributed cache needs to be extended to prevent accidental deletion of user records in use due to automatic cache expiration. If a room has no active users, meaning all users have logged out, or the room's hash structure is empty, it indicates that the room has entered an inactive state, and further assessment is needed to determine whether it is safe to clear all user status data for that room from the cache to free up storage resources. Through this management strategy based on the current existence of users in a room, the system can dynamically maintain the lifecycle of each room, ensuring that the status data of active rooms is not lost due to cache expiration, and promptly clearing data from rooms with no users, avoiding unnecessary occupation of cache space.

[0078] In one possible implementation, a corresponding room management strategy is determined based on whether a user exists in each room at the current settlement time, including: In response to the presence of at least one user in a room, update the validity period of the corresponding hash structure for that room in the distributed cache; In response to the absence of any user in a room, determine the last settlement time for that room, and clear the hash structure of that room in the distributed cache when the difference between the last settlement time and the current settlement time exceeds a safety threshold.

[0079] In this embodiment, for rooms with at least one user, the system performs a renewal operation on that room. Accordingly, the renewal operation in this embodiment refers to updating the time-to-live (TTL) validity period of the hash structure corresponding to the room in the distributed cache to a preset security threshold, such as 3 × stayTime, where stayTime is the settlement period in milliseconds. Simultaneously, it is preferable to update the room's last settlement timestamp to the current settlement time.

[0080] It's important to note that for rooms with active users, even if the settlement event is delayed by one or two cycles (e.g., 30-60 seconds), the room's user status data remains, and subsequent settlements can proceed normally. For example, if a brief delay occurs due to network jitter or high service load, meaning the next settlement cycle doesn't trigger on time, as long as the delay doesn't exceed 3×stayTime, the room's user status data remains in the cache. Once the settlement service recovers, it can resume normal operation without manual reconstruction of the room status. This prevents accidental deletion of room status due to system scheduling jitter or brief failures, thus improving the system's fault tolerance and self-healing capabilities. If the safety threshold is set to 1×stayTime, the cache expires after one settlement cycle, e.g., 30 seconds, starting from the renewal date after the last settlement completion. If, due to network jitter, a sudden spike in service load, or scheduling delay, the next settlement event is delayed by a few seconds, the cache may have already expired and been deleted. This would prevent the settlement service from reading user status data, even if the user is still in the room. This could result in lost user online time or even incorrect room status. In this embodiment, a safety threshold of 3×stayTime is preferably set so that the room's user status data needs to be kept in the distributed cache for a certain period of time so that it can still be found when the next settlement cycle arrives, thus preventing the problem of incorrect room status management.

[0081] Accordingly, for rooms with no users, the system reads the last settlement time recorded in the cache, i.e., the settlement timestamp when the room was last online. It then calculates the difference between the current settlement time and the last settlement time. If the difference exceeds 3 × stayTime, it means the room has had no users for several consecutive settlement cycles, and the waiting time has exceeded the safety tolerance window. In this case, the system proactively deletes the entire hash structure corresponding to the room in the distributed cache, completely clearing its user status data and freeing up storage space. If the difference does not exceed 3 × stayTime, the room's hash structure is temporarily retained, awaiting re-checking in subsequent settlement cycles. This avoids frequent rebuilding due to immediate deletion caused by a momentary lack of users, allowing the system to automatically recover after a brief unavailability of the settlement service without manual intervention to repair the room status.

[0082] The method disclosed herein will be explained in detail below by applying it to specific scenarios.

[0083] Scenario 1: Standard Settlement Scenario The current settlement period stayTime = 30 seconds. At the current settlement time, there are users A, B and C in room 1. Users A and B were already in room 1 during the last settlement, and user C entered midway through this settlement period.

[0084] Accordingly, in response to the triggering of the settlement event, the hash structure of Room 1 in the distributed cache is scanned to determine the status data of users A, B, and C at the current settlement time, and the online duration of each user in the current settlement period is determined accordingly, as follows: For user A, their status data includes outTimeA=0 and updateTimeA. The duration of the online period in the current settlement cycle is now-updateTimeA=30s, corresponding to the updateTimeA=now. For user B, their status data includes outTimeB=0 and updateTimeB. The duration of the online period in the current settlement cycle is now-updateTimeB=30s, corresponding to the updateTimeB=now. For user C, their status data includes outTimeC=0 and updateTimeC. The duration of the online period in the current settlement cycle is now-updateTimeC=12s. User C enters room 1 12s before the current settlement time, which corresponds to updating updateTimeC=now. The users are paired up. For user A and B, the shared online time during the current settlement period is represented as min(30,30) = 30s, meaning they are online together for the entire duration. For user C and AC, the shared online time during the current settlement period is represented as min(30,12) = 12s, meaning that user C enters room 1 after the user C, and the overlap of their online time periods is only 12s. For user B and BC, the shared online time during the current settlement period is represented as min(30,12) = 12s, meaning that user C enters room 1 after the user C, and the overlap of their online time periods is only 12s.

[0085] Assuming the remaining shared online time in the previous settlement period is 0, calculate the intimacy value for the above user pairs. For user pair AB, the intimacy value is... =0, the remaining shared online time for the current settlement period is 30 seconds, stored back in the cache; similarly, the user's affinity value for AC is =0, the remaining shared online time for the current settlement period is 12s, stored back in the cache; the user's affinity value for BC is =0, the remaining common online time for the current settlement cycle is 12s, and it is stored back in the cache.

[0086] For the next settlement cycle, taking user A and B as an example, if user A and B calculate another 30 seconds of online time together, then this 30 seconds, together with the 30 seconds in the cache, will be added to a total of 60 seconds, which can generate 1 point of intimacy score, and thus update the user's real-time intimacy score with A and B.

[0087] Scenario 2: Scenarios where user logout occurs User A remained in room 1 throughout the current settlement period, while User B left midway. Accordingly, in response to the triggering of the settlement event, the hash structure of room 1 in the distributed cache is scanned to determine the status data of user A and user B at the current settlement time, and the online duration of each user in the current settlement period is determined accordingly, as follows: For user A, their status data includes outTimeA=0 and updateTimeA. The duration of the online period in the current settlement cycle is now-updateTimeA=30s, corresponding to the updateTimeA=now. For user B, their status data includes outTimeB>0 and updateTimeB. The duration of the online period in the current settlement cycle is outTimeB-updateTimeB=18s. This user status data is marked as data to be deleted. After releasing the distributed lock, the data to be deleted is deleted. For user pair A and B, the common online time during the current settlement period is represented as min(30,18) = 18s.

[0088] Scenario 3: Users frequently entering and exiting the same room User D enters room 1 (updateTimeD1) during the current settlement period, exits after 10 seconds (outTimeD1>0), re-enters room 1 after 5 seconds (updateTimeD2), and waits for 8 seconds until the current settlement time (outTimeD2=0). Correspondingly, user D has two state data: state data one includes outTimeD1>0 and updateTimeD1, and state data two includes outTimeD2=0 and updateTimeD2. The duration of the online period for state data one is outTimeD1 - updateTimeD1 = 10s, and the duration of the online period for state data two is now - updateTimeD2 = 8s. The sum of the two durations is 10 + 8 = 18 seconds, which serves as the data basis for calculating the intimacy value between user D and other users. The 5 seconds spent exiting the room are not included in the calculation; only the actual time spent in the room is counted. Scenario 4: Abnormal Data Filtering Because of residual data in the distributed cache, the updateTime in a user's status data is a value from several hours ago. As a result, the user's online time in the current settlement period is 3600s, which is far beyond the 30s of the calculation period. That is, 3600 > 3 × 30s = 90s. Therefore, the user's status data is judged to be abnormal, and the status data is discarded and not included in the intimacy calculation to avoid abnormal jumps in intimacy points caused by a single abnormal data.

[0089] In summary, the method disclosed herein maintains the status data of each user in each room, specifically maintaining the online status update time (updateTime) and offline status update time (outTime) records. This eliminates the need for a separate timer for each user, resulting in a system maintenance quantity of O(N) rather than O(N). 2Furthermore, after each settlement, the last offline time of the current settlement period is updated to the current settlement time, ensuring that status data within the same time period is not repeatedly calculated. The length of the settlement period can be freely configured according to actual business needs; for example, shortening the period can improve statistical accuracy by simply modifying the running parameters, without altering the core algorithm logic. At the end of each settlement period, the system instantly generates the incremental intimacy points for all user pairs within that period, supporting near real-time updates to the real-time leaderboard and online intimacy display. During the intimacy point calculation process, a cross-period remainder accumulation mechanism merges the shared online time (less than one unit of measurement) left over from the previous period with the current period's time, avoiding accuracy loss due to settlement boundary truncation. Simultaneously, an independent lifecycle management strategy is set for each room: when there are active users in the room, the room's cache validity is dynamically renewed; when a room has no active users for several consecutive periods, all its status data is automatically cleared, thus ensuring that active room data is not lost while promptly reclaiming idle cache resources. In addition, during the holding of the distributed lock, only lightweight operations such as determining the online time period and updating user status data are performed, while the deletion operation of the exited user record is moved to be executed asynchronously outside the lock, which minimizes the lock holding time and improves the system throughput in high-concurrency scenarios.

[0090] To implement the above method, one example of this application also provides a device 200 for determining the intimacy between users, such as... Figure 2 As shown, the device includes: The periodic triggering module 201 is used to respond to the intimacy settlement event, determine the current settlement time, and acquire a distributed lock for each room with user status data; The data acquisition module 202 is used to obtain the user status data of the room from the corresponding hash structure of the distributed cache according to the room identifier at the current settlement time. The time period calculation module 203 is used to determine the online time period of each user in the room within the current settlement period corresponding to the current settlement time based on the acquired room user status data, and release the room's distributed lock; The pairing calculation module 204 is used to determine any two users forming a user pair based on the user status data of all rooms acquired, and to determine at least one common online time period of the user pair in the same room; The intimacy calculation module 205 is used to obtain the remaining shared online time of each user pair in the previous settlement period, and calculate the intimacy of the user pair based on the remaining shared online time and the shared online time periods of all the same rooms of the user pair in the current settlement period. The remaining shared online time is the shared online time of the user pair after the intimacy calculation in the previous settlement period that does not meet one unit of measurement.

[0091] In one possible implementation, the time period calculation module 203 is used to determine, for each user, whether the user is in the room at the current settlement time; In response to the fact that the user's offline time in the last status group during the current billing cycle is equal to zero, it is determined that the user is in the room at the current billing time. The online time period of the status group is determined based on the current billing time and the online time in the last status group. If other status groups exist, the online time period of the corresponding status group is determined based on the offline time and online time in the other status groups. The online time of the last status group is updated to the current billing time. In response to the fact that the user's offline time in the last status group within the current settlement period is greater than zero, it is determined that the user has left the room at the current settlement time. Based on the offline time and online time in each status group, the online time period of that status group is determined, and the corresponding user status data of the room is marked as data to be deleted. After determining the online time periods of all users in the room, release the distributed lock for the room and delete the data to be deleted from the distributed cache.

[0092] In one embodiment, the pairing calculation module 204 is used to determine the intersection of the online time periods of the two users in at least one same room as a common online time period, based on the online time periods of each user in all rooms.

[0093] In one embodiment, the intimacy calculation module 205 is used to determine the corresponding common online time for a user pair based on the common online time of the user pair in all the same rooms during the current settlement period; The total shared online time for the current settlement period is summed up with the remaining shared online time for the previous settlement period to obtain the cumulative shared online time. The ratio of cumulative shared online time to unit of measurement is determined as the intimacy value of the user pair in the current settlement period, and the remaining time in the cumulative shared online time that does not meet the unit of measurement corresponding to the intimacy value is taken as the remaining shared online time of the user pair in the current settlement period. Get the existing intimacy value of the user pair, and update the real-time intimacy value of the user pair based on the existing intimacy value and the intimacy value of the current settlement period.

[0094] In one possible implementation, an abnormal data filtering module is also included, which is used to determine whether the total duration of all common online periods of each user pair in the current settlement period exceeds a safety threshold, and to filter out all common online periods of the corresponding user pair that exceed the safety threshold. The safety threshold is determined based on the duration of the settlement period.

[0095] In one possible implementation, a room management module is also included, which, in response to the completion of the intimacy calculation for the current settlement period, determines the corresponding room management strategy based on whether there is a user in each room at the current settlement time.

[0096] In one implementation, the room management module is further configured to update the validity period of the hash structure corresponding to the room in the distributed cache in response to the presence of at least one user in the room; In response to the absence of any user in a room, determine the last settlement time for that room, and clear the hash structure of that room in the distributed cache when the difference between the last settlement time and the current settlement time exceeds a safety threshold.

[0097] By way of example, this application also provides an electronic device, including: processor; Memory used to store processor-executable instructions; The processor is used to read executable instructions from memory and execute the instructions to implement the aforementioned method for determining the intimacy between users.

[0098] By way of example, this application also provides a computer-readable storage medium storing a computer program for performing the above-described method for determining the intimacy between users.

[0099] Figure 3 A schematic block diagram of an example electronic device 300 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0100] like Figure 3 As shown, device 300 includes a computing unit 301, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 302 or a computer program loaded from storage unit 308 into random access memory (RAM) 303. The RAM 303 may also store various programs and data required for the operation of device 300. The computing unit 301, ROM 302, and RAM 303 are interconnected via bus 303. Input / output (I / O) interface 305 is also connected to bus 304.

[0101] Multiple components in device 300 are connected to I / O interface 305, including: input unit 306, such as keyboard, mouse, etc.; output unit 307, such as various types of monitors, speakers, etc.; storage unit 308, such as disk, optical disk, etc.; and communication unit 309, such as network card, modem, wireless transceiver, etc. Communication unit 309 allows device 300 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0102] The computing unit 301 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 301 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 301 performs the various methods and processes described above, such as a method for determining inter-user intimacy. For example, in some embodiments, a method for determining inter-user intimacy may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 308. In some embodiments, part or all of the computer program may be loaded and / or installed on device 300 via ROM 302 and / or communication unit 309. When the computer program is loaded into RAM 303 and executed by the computing unit 301, one or more steps of a method for determining inter-user intimacy described above may be performed. Alternatively, in other embodiments, the computing unit 301 may be configured, by any other suitable means (e.g., by means of firmware), to perform a method for determining user intimacy.

[0103] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0104] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0105] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0106] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.

[0107] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this disclosure, "a plurality of" means two or more, unless otherwise explicitly specified.

[0108] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A method for determining the intimacy level between users, characterized in that, The method includes: In response to the intimacy settlement event, determine the current settlement time and acquire a distributed lock for each room with user status data; At the current settlement time, the user status data of the room is obtained from the corresponding hash structure of the distributed cache according to the room identifier of the room; Based on the acquired user status data of the room, determine the online time period of each user in the room within the current settlement period corresponding to the current settlement time, and release the distributed lock of the room; Based on the user status data of all rooms obtained, determine any two users forming a user pair, and determine at least one common online time period of the user pair in the same room; For each user pair, obtain the remaining shared online time of the user pair in the previous settlement period, and calculate the intimacy of the user pair based on the remaining shared online time and the shared online time periods of all the same rooms of the user pair in the current settlement period. The remaining shared online time is the shared online time of the user pair after the intimacy calculation in the previous settlement period that does not meet a unit of measurement.

2. The method for determining user intimacy according to claim 1, characterized in that, The user status data of the room includes the time when the user's online status and / or offline status in the room is updated each time, as well as the corresponding user identifier. The adjacent online time and offline time corresponding to the same user identifier form a status group. The step of determining the online time period of each user in the room within the current settlement period corresponding to the current settlement time, based on the acquired user status data of the room, includes: For each user, determine whether the user is in the room at the current billing time; In response to the user's offline time in the last status group within the current billing cycle being equal to zero, it is determined that the user is in the room at the current billing time. The online time period of the status group is determined based on the current billing time and the online time in the last status group. If other status groups exist, the online time period of the corresponding status group is determined based on the offline time and online time in the other status groups. The online time of the last status group is then updated to the current billing time. In response to the user's offline time being greater than zero in the last status group within the current settlement period, it is determined that the user has left the room at the current settlement time. The online time period of the status group is determined based on the offline time and online time in each status group, and the corresponding user status data of the room is marked as data to be deleted. After determining the online time periods of all users in the room, release the distributed lock for the room and delete the data to be deleted from the distributed cache.

3. The method for determining the intimacy between users according to claim 1, characterized in that, Determining that the user has at least one shared online time period in the same room includes: Based on the online time periods of each user in all rooms in the user pair, the intersection of the online time periods of the two users in the user pair in at least one room is determined as the common online time period.

4. The method for determining user intimacy according to claim 1, characterized in that, The calculation of the intimacy of the user pair based on the remaining shared online time and the shared online time periods of all identical rooms within the current settlement period includes: For the user pair, the corresponding common online duration is determined based on the common online time periods of the user pair in all the same rooms within the current settlement cycle; The total shared online time for the current settlement period is summed with the remaining shared online time for the previous settlement period to obtain the cumulative shared online time. The ratio of the cumulative shared online time to the unit of measurement is determined as the intimacy value of the user pair in the current settlement period, and the remaining time in the cumulative shared online time that does not meet the unit of measurement corresponding to the intimacy value is taken as the remaining shared online time of the user pair in the current settlement period. Obtain the existing intimacy value of the user pair, and update the real-time intimacy value of the user pair based on the existing intimacy value and the intimacy value of the current settlement period.

5. The method for determining user intimacy according to any one of claims 1-4, characterized in that, Before obtaining the remaining shared online time for each user pair in the previous settlement period, the method further includes: Determine whether the total online time of each user pair in all common online periods in the current settlement period exceeds a safety threshold, and filter out all common online periods of the corresponding user pair that exceed the safety threshold. The safety threshold is determined based on the duration of the settlement period.

6. The method for determining user intimacy according to claim 5, characterized in that, The method further includes: In response to the completion of the intimacy calculation for the current settlement period, a corresponding room management strategy is determined based on whether a user exists in each room at the current settlement time.

7. The method for determining user intimacy according to claim 6, characterized in that, The step of determining the corresponding room management strategy based on whether there is a user in each room at the current settlement time includes: In response to the presence of at least one user in the room, update the validity period of the corresponding hash structure for that room in the distributed cache; In response to the absence of any user in the room, the last settlement time of the room is determined, and the hash structure of the room in the distributed cache is cleared when the difference between the last settlement time and the current settlement time exceeds the security threshold.

8. A device for determining the intimacy between users, characterized in that, The device includes: The periodic triggering module is used to respond to the intimacy settlement event, determine the current settlement time, and acquire a distributed lock for each room with user status data; The data acquisition module is used to obtain the user status data of the room from the corresponding hash structure of the distributed cache according to the room identifier at the current settlement time. The time period calculation module is used to determine the online time period of each user in the room within the current settlement period corresponding to the current settlement time based on the acquired user status data of the room, and release the distributed lock of the room; The pairing calculation module is used to determine any two users forming a user pair based on the user status data of all rooms acquired, and to determine at least one common online time period of the user pair in the same room; The intimacy calculation module is used to obtain the remaining shared online time of each user pair in the previous settlement period, and calculate the intimacy of the user pair based on the remaining shared online time and the shared online time periods of all the same rooms of the user pair in the current settlement period. The remaining shared online time is the shared online time of the user pair after the intimacy calculation in the previous settlement period that does not meet a unit of measurement.

9. An electronic device, characterized in that, include: At least one processor; and a memory connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform claim 1. The method for determining the intimacy between users as described in any one of the 7.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to execute the method for determining the intimacy between users according to any one of claims 1-7.

Images