Original: Taste of Little Sister (wechat official ID: XjjDog), welcome to share, please reserve the source.

This short but informative article is about Redis’ Zset. Let me share a bit of online data I’ve come across that might help you in your decision making.

Redis supports a data structure called zset, or ordered list. Of course, Redis can not be abused, you can see my previous specification article: this is probably the most pertinent Redis specification.

This is a GIF for those of you who have forgotten what zset is.

Through it, it can realize functions such as game leaderboards, or achieve the needs of Topx, and also accurately let users find their position in the mass of data.

The underlying structure of a Zset is a skip list, whereas a similar ordered Set in Java is a TreeSet, implemented using a red-black tree.

The concurrent package also contains a class called ConcurrentSkipListMap, which, as its name suggests, is also implemented using skip lists, and is most similar to Zset.

All right, that’s the premise. I ask the same thing in breadth interviews.

Our question was: How many records can a Zset hold? Is there any convincing data on the line?

Just to give a general answer, zSet theoretically supports up to 2^32-1 elements, about 4.2 billion, which is more than enough memory to hold people.

Using Redis-benchmark to measure this effect is not very reliable, and the test case is a bit of a drag to write. Finished testing is not sure, then let the online flow to impact it.

In order to meet the demand of the product, I geohash the users according to provinces and cities. As a result, guangdong province has the largest distribution of users, which is very good.

In Zset in Guangdong Province, there are nearly 60 million pieces of data stored, and we need to rank everyone within those 60 million. Zcard, Zrank and a series of operations, easy implementation.

After running for a period of time, the memory directly soared to about 8GB. This is due to the special structure of the hop table, and additional auxiliary information takes up more memory.

Here are the lessons:

  1. Maximum TPS write volume1 k/SEC.
  2. Maximum QPS query volume5 k/SEC.
  3. The average time5msThe left and right sides.
  4. Per cent95The request is in10msReturn within.
  5. Long tail request exceeded100msNo more than100The article.

That is, zSET ensures low response time while maintaining high writes and high queries.

You say more, I don’t know, look at these numbers, maybe I can go up a notch. But to make the service as steady as possible, the pressure as diffuse as possible, can not be too harsh, I have been very satisfied with this data.

That’s just for one province. If combined, the upper-layer business needs to carry 10W /s of requests. This is easy, but it doesn’t make sense. Many of the most successful resumes are written this way.

Complex business with high concurrency is valuable, 10W /s request, give me two Redis is enough, there is no need to blow.

But I was also shocked by the performance of zset. I understand the structure of the hop table, but I didn’t expect it to be so fast in the scenario of high concurrency and large data volume.

Test data? No. This article is just to share a rule of thumb. Oh, and redis uses almost no CPU, all you need is a 2core16gb server.

Xjjdog is a public account that doesn’t allow programmers to get sidetracked. Focus on infrastructure and Linux. Ten years architecture, ten billion daily flow, and you discuss the world of high concurrency, give you a different taste. My personal wechat xjjdog0, welcome to add friends, further communication.