本篇文章很短，但信息量很大，是關于redis的zset。我來分享一點遇到過的線上數據，或許對你的決策有幫助。

[[331832]]

redis支持一個數據結構，叫做 zset，也就是有序的列表。當然redis也不能濫用，可以看我以前的規范文章：《這可能是最中肯的Redis規范了》

忘了zset是個啥的同學可以看這張gif圖。

通過它，可以實現游戲排行榜一類的功能，或者實現Topx這樣的需求，也能精準的讓用戶在海量數據中找到自己的位置。

zset的底層結構是跳躍表，而與之類似的Java中的有序Set是TreeSet，使用紅黑樹實現的。

concurrent包里面，還有一個類叫做ConcurrentSkipListMap，從它的名字就可以看出來，也是用跳躍表實現的，這個和zset最像。

好了，這是前提。廣度面試的時候我也會這么問。

我們的問題是：zset中能存放多少條記錄?線上有沒有有說服力的數據?

先籠統的回答一下，zset理論上支持的元素最多是2^32-1個，約42億，如果你的內存夠大，放下國人綽綽有余。

使用redis-benchmark去測這個效果，不是很可信，測試用例寫起來也比較費勁。測完了也不一定信，那就讓線上流量去沖擊吧。

為了應付產品的需求，我把用戶按照省市進行了劃分(geohash)，結果，用戶分布最大的就是廣東省，非常棒。

在廣東省的zset里，存放了接近6千萬的數據，我們就要算在這6千萬內任何人的排行。zcard、zrank等一系列操作，easy實現。

運行一段時間后，內存直接飆升到了8G左右。這是由于跳表的特殊結構所引起的，額外的輔助信息會占用更多的內存。

以下是經驗值：

1. 最高TPS寫入量1k/秒。
2. 同時最高QPS查詢量5k/秒。
3. 平均耗時5ms左右。
4. 百分之95的請求都在10ms以內返回。
5. 長尾請求超過100ms的不超過100條。

也就是說，在保持高寫入和高查詢的同時，zset能夠保證較低的響應耗時。

你要說再多，我就不知道了，看這些數據，或許還能夠再升一把。但要讓服務要盡量的穩，壓力盡量的分散，就不能太過苛刻，對這個數據我已經很滿意了。

這只是一個省份的數據。如果綜合起來，上層的業務，就需要承載10w/s的請求。這是非常容易的，但也沒有意義，許多高并發經驗都是這么吹上去的，要不要去改改簡歷?

復雜業務高并發才有價值，10w/s請求，給我兩臺redis就夠了，沒必要拿來吹。

但也是被zset的性能震驚了一把。跳表的結構，也了解一些，沒想到在高并發大數據量場景下，能這么快。

測試數據?沒有。本文只是分享一個經驗值。對了，redis幾乎不占用CPU，你只需要一臺2core16gb的服務器就可以了。

作者簡介：小姐姐味道 (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高并發世界，給你不一樣的味道。我的個人微信xjjdog0，歡迎添加好友，進一步交流。