background

As we all know, in Internet projects, we use Redis a lot of scenarios, Redis, to a large extent, to compensate for memcached key/value storage deficiencies, in some cases can play a very good supplement to relational database, is very convenient to use. A variety of data structures let you can be more elegant, easy to face a variety of scenes, the company mainly do live industry, pure Redis instance has hundreds, so here with Redis is also very frequent, the following will introduce how to use Redis simple, easy to achieve a variety of lists.

Scenario simulation

1. Daily list implementation

If you had a campaign requirement that required you to count the number of gifts received by each studio and the number of contributors per day, think about it: What would you do? Well, it took you less than 3 seconds to think of using the ordered list of Redis for statistics. Yes, the ordered list of Redis can basically achieve most of the list statistics functions. Let’s start with this simple requirement.

1. Design data structure field name definition (member) : {live roomId :roomId, contributor ID:userId} although contributors can be listed in each room, the roomId is unique, So the combination of these two ids ensures uniqueness according to the local time as the KEY(e.g. 20210630) to ensure the total value of each day's list gift (score): this thing is processed asynchronously, so make sure that each calculation is ok 2. ZADD key score member Query ZREVRANGE key start stop to query the list for each day, so easy!Copy the code

2. Weekly list implementation

According to the statistics of nature week, it is no different from the daily list. If it is the latest N days list, suppose to continue the above activities, not only the daily list, but also need to see the recent N days list, then what will you do? If you exist in the database, this problem is very easy to do, direct SQL according to the time cycle check is done, of course, this high frequency hot data you repeatedly in the database reading and writing is simply looking for death. And since Redis is a non-relational thing, boy you might look up the data for each day and sort it, right? Of course, this method is not advisable. Firstly, every day's data list is an independent KEY, and the member and score of each KEY are different. Although this method can be implemented, the overall interface response time... Early data less may have no impact, but a large amount, this is digging a hole, back to fill their own. The correct way to do this is to use the redis ordered list's own merge operation command: ZUNIONSTORE destination numkeys key [key... [WEIGHTS weight [weight...]] [AGGREGATE SUM | MIN | MAX] don't command so long ah, actually very simple: destination: [KEY...] [KEY...] [KEY...] [KEY...] [KEY...] : want to merge the KEY names in addition to the KEY array N days ago WEIGHTS: multiplication factor AGGREGATE: aggregation, we calculated the total list so the SUM, of course, you use redis encapsulation library API to use more simple and elegantCopy the code

Time complexity of merge operation: O(N)+O(M log(M)), where N is the sum of the cardinality of a given ordered set and M is the cardinality of the result set.

conclusion

Using Redis to achieve the list has natural advantages, its rich data structure, easy to use API so that we can easily achieve a list function, of course, when using the following problems should be paid attention to

  1. Cache breakdown and cache penetration issues when used
  2. Redis downtime (primary/secondary, cluster architecture is basically rare) and Redis service is unavailable
  3. Cache consistency issues

I see a long way to go, I would like to work with you up and down, thank you very much for your handsome boys and beautiful girls’ thumbs up, favorites and comments, pay attention to me, only practice not theory, we will see you next time