引子
直播運營活動中經(jīng)常會有這樣的需求秕豫，根據(jù)用戶送禮情況做排名。這個排行榜具有以下特點：
- 用戶每次請求會返回用戶的排名
- 送禮金額越多粉絲排名越靠前
- 相同金額送禮越早越靠前
- 排行榜會隨著粉絲送禮變化而不斷變化
排行榜的實現(xiàn)方式
表結(jié)構(gòu)
CREATE TABLE `user` (
`id` int(10) NOT NULL COMMENT '編號',
`uid` varchar(32) NOT NULL COMMENT '用戶',
`coin` int(10) NOT NULL COMMENT '用戶送出金額',
`create_time` datetime NOT NULL COMMENT '創(chuàng)建時間',
`update_time` datetime NOT NULL COMMENT '更新時間',
PRIMARY KEY (`id`),
UNIQUE KEY `uid` (`uid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用戶表';
1. sql查詢
EXPLAIN SELECT
*
FROM
(
SELECT
@rank := @rank + 1 AS rank,
s.uid AS uid,
s.coin AS coin
FROM
`user` s,
(SELECT @rank := 0) r
ORDER BY
coin DESC,
create_time
) q
WHERE
q.uid = 'xiaoming';
根據(jù) select @rank 與 user表結(jié)合起來作為一張有排名的新表观蓄，然后再從中找出某個用戶的排名混移。這種方法的優(yōu)點是簡單，每次用戶來請求侮穿，只要用這個SQL查一下即可歌径；缺點是這個算是比較復(fù)雜的SQL，查起來太慢亲茅，每次都要全表查詢回铛，試了幾次都要0.5s左右。用explain分析如下：
explain
2. user中添加rank字段
在user中添加rank字段克锣，寫個計劃任務(wù)每隔2分鐘全表掃描茵肃，然后更新rank名次字段。這個方法最殘暴袭祟，但是也是最不可取的验残。首先會產(chǎn)生延遲，因為2分鐘才更新一次名次巾乳，其次您没，每次都要更新全部數(shù)據(jù)，給數(shù)據(jù)庫很大的壓力胆绊，最后氨鹏，計劃任務(wù)更新數(shù)據(jù)的時候，用戶送禮也在更新數(shù)據(jù)辑舷，稍微不注意就會出現(xiàn)臟讀的情況。
3. 用Redis的zset數(shù)據(jù)結(jié)構(gòu)
ZSet實現(xiàn)排行榜
zset的相關(guān)api (PipelineCluster/Jedis)
- 插入或者更新數(shù)據(jù)
Long zadd(final String key, final double score, final String member)
key : 排行榜的名字
memeber : 用戶
score : 用戶的分數(shù) - 獲取用戶分數(shù)
Double zscore(String key, final String member) - 獲取用戶的排名
Long zrevrank(final String key, final String member)：（score從大到小槽片，從0開始何缓，所以需要加1）
Long zrank(final String key, final String member)：（score從小到大肢础，從0開始，所以需要加1） - 獲取某個范圍內(nèi)的用戶排名
Set<Tuple> zrevrangeWithScoresBytes(String key, final long start, final long end) （從大到新道）
Set<Tuple> zrangeWithScoresBytes(String key, final long start, final long end) （從小到大）
start ： 開始排名
end ： 結(jié)束排名
Tuple :
public class Tuple implements Comparable<Tuple> {
// 用戶
private byte[] element;
//分數(shù)
private Double score;
}
比如我們想查1-10的排名传轰，我們可以zrevrangeWithScoresBytes(key, 0, 9)
排行榜的實現(xiàn)
- 簡單
簡單的排行榜就是每次用戶信息更新后，把用戶uid和用戶coin都更新到zset中谷婆，這個的好處是比較簡單慨蛙，有一點不好的就是他不能實現(xiàn)先到先得，即先相同金額送禮越早越靠前纪挎。 - 較復(fù)雜（可實現(xiàn)先到先得）
- 較復(fù)雜的zset和簡單的不同的是score存的不僅僅是用戶的coin期贫，而是用戶coin 和時間戳(秒)ts的組合。為了實現(xiàn)先到先得的zset异袄，可設(shè)置存進去的
score = (coin * 10000000000(十次方)) + (100000000000(十一次方) - ts)通砍。 - 表面上好像是解決了先到先得這個難題，但是實際上這樣子還不是最優(yōu)解烤蜕，因為存進去的score長度是有限的封孙，據(jù)我所測，好像是18位數(shù)左右讽营，除掉時間戳10位以后虎忌，只能存8位的coin了。這很明顯還不夠橱鹏。那該怎么辦呢膜蠢？
- 我們縮短一下coin或者ts的長度不就OK了嗎？首先coin是改不了的蚀瘸，因為這是核心數(shù)據(jù)狡蝶，所以能夠下手的就只有ts了。ts這個時間戳贮勃，其實包括了年月日分時秒贪惹，某一段相近時間內(nèi)，他們的ts前幾位都是相同的寂嘉。比如2018-08-01 00:00:00 的時間戳為
1533052800, 2018-09-01 00:00:00 的時間戳為1535731200,相隔一個月的兩個時間奏瞬，他們的前三位都是相同的，所以我們只需要取后面7位參與計算即可泉孩。取多少位取決于我們的活動要舉辦多久硼端。我們根據(jù)開始時間和結(jié)束時間的時間戳，取出不同部分參與計算寓搬。 - 如果ts被我們壓縮到了3位珍昨，也就是說我們的coin可以增加三位 11位的coin差不多人民幣億元起，我們歡迎砸錢超過10億的土豪讓我們的程序出現(xiàn)bug。
- 以下是對coin轉(zhuǎn)score的封裝：
/**
* 將coin加密成可以存在zset的值镣典，實際上就是 coin * 10000000 + now % 10000000
* @param coin
* @return
*/
public static Double encrypt(Long coin){
Long value = coin * KEY + (KEY - DateUtil.getInt() % KEY);
return value.doubleValue();
}
/**
* 將zset的值轉(zhuǎn)成long型的coin
* @param value
* @return
*/
public static Long decrypt(Double value){
Double coin = value / KEY;
return coin.longValue();
}
