I haven't updated my blog for a long time, and there are so many chores. In fact, I am lazy. Hahahaha. Closer to home.
Recently, I demanded a ranking list, which was implemented using redis. I vaguely remember that when I went to the interview a few months ago, the interviewer always liked to ask me if I did the ranking list, did I do the ranking list, and I haven’t done it at that time. , I also know that redis did it, I thought it would be a little difficult, but it's not difficult. Technology is like this. It’s difficult if you don’t know it, and it’s easy if you know it. The best way to eliminate fear is to face it, Ori!
In the sorted set of redis, all elements are associated with a double type score. Then use scores to sort the members from small to large. It is simply designed for ranking, but the sorted set is actually a dictionary sort when the element points are the same (that is, in the case of the same score, we use the stored elements for sorting), which does not match Our ideal leaderboard.
The improvements are as follows:
We only need to associate the time with the player's score, for example: the data stored is {uid, score}
1. We need to get a time as a standard, which can be the end time of the leaderboard or any other time. I am using the end time timestamp (end_time).
2. Process the score, new_score = score << 26 + (end_time-now) . The time stamp is added after bit manipulation. In the case of the same score, the later the deposit arrives, the smaller the new_score after processing.
3. The data stored in redis is {uid, new_socre}.
4. Because the bit operation is used, when the score needs to be displayed, new_score >>26 will remove the time stamp and display the score.
Because bit operations are used and timestamps are associated, the probability of the same score is very small. But this is also flawed, that is, if the same time reaches the same integral, it will still be lexicographically sorted according to the elements, but it does not matter, this probability is very low. If my requirements are the same in this case, they can be sorted by uid, so there is no further optimization. If any colleague sees it, there is a better way and welcome to share.