这篇文章很短，但包含的信息量很大。这是关于redis的zset。分享一些我遇到的网上资料，或许对大家的决策有帮助。Redis支持一种称为zset的数据结构，它是一个有序列表。当然redis也不能乱用，可以看我之前的规范文章：《这可能是最中肯的Redis规范了》忘了zset是什么的同学可以看看这个gif。通过它可以实现游戏排行榜等功能，或者实现Topx等需求，用户也可以在海量数据中准确找到自己的位置。zset的底层结构是一个跳表，Java中类似有序的Set是TreeSet，它是使用红黑树实现的。在concurrent包中，还有一个类叫ConcurrentSkipListMap，从名字就可以看出，它也是用skiptable实现的，这个和zset最相似。好吧，这是前提。我也在广度访谈中问这个问题。我们的问题是：zset中可以存储多少条记录？网上有没有令人信服的数据？让我先给出一个笼统的答案。zset理论上最多支持2^32-1个元素，约42亿个。如果你的内存足够大，可以容纳中国人。使用redis-benchmark来测试这个效果不是很靠谱，写测试用例也比较费力。测试完你可能不信，那就让网络流量来砸吧。为了满足产品的需求，我把用户按省市划分（geohash）。这样一来，广东省的用户分布最大，就很好了。在广东省的zset里面，存储了将近6000万条数据，我们要计算这6000万里面谁的排名。轻松实现zcard、zrank等一系列操作。运行一段时间后，内存直接飙升到8G左右。这是跳表的特殊结构造成的，额外的辅助信息会占用更多的内存。以下为经验值：最高TPS写入量为1k/sec。同时最高QPS查询量为5k/s。平均时间约为5ms。95%的请求在10毫秒内返回。超过100ms的长尾请求不超过100个。也就是说，zset在保持高写高查询的同时，可以保证低响应时间。不管你想说多少，我都不知道。看看这些数据，说不定还能再升职。但是要让服务尽量稳定，压力尽量分散，不能太苛刻。这个数据我已经很满意了。这只是一个省的数据。合并的话，上层业务需要承载10w/s的请求。这很容易，但没有意义。很多高并发的体验都是这样炸的。你想改变你的简历吗？复杂的业务只有高并发才有价值。10w/s的请求，我两个redis就够了，没必要炸了。但我也被zset的表现震惊了。跳表的结构我也略知一二。没想到在高并发、大数据量的场景下会这么快。测试数据？没有。本文只是分享一个经验值。顺便说一句，redis几乎不占用CPU，你只需要一台2core16gb的服务器。作者简介：品味小姐姐（xjjdog），一个不让程序员走弯路的公众号。专注于基础架构和Linux。十年架构，每天百亿流量，与你探讨高并发世界，给你不一样的滋味。我的个人微信xjjdog0，欢迎加好友进一步交流。
