redis的zset有多牛？請把耳朵遞過來

原創：小姐姐味道（微信公衆號ID：xjjdog），歡迎分享，轉載請保留出處。

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

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，歡迎添加好友，​進一步交流。​