开发者

how many calls to HINCRBY are reasonable?

开发者 https://www.devze.com 2023-03-24 09:48 出处:网络
I\'m trying to reinvent the wheel and store some stats in Redis. I\'m thinking about aggregating eagerly, and incrementing all related counters right after every new event (it can happen several time

I'm trying to reinvent the wheel and store some stats in Redis.

I'm thinking about aggregating eagerly, and incrementing all related counters right after every new event (it can happen several times per second).

It will require to call HINCRBY like 5-50 times per event, and I'm aiming to 5-100 events per second at first.

Is it too much for Redis? If it is, should I aim for some lower limits (10 times per event? only one?)? If it's not, can it scale in any of these parameters (I'm more interested in scaling to 1000 events? 10000?)?

I'll obviously also have to collect garbage. I'm planning on doing it by calling EXPIRE for ever开发者_运维知识库y hash needed on every event (no more than 2-5 times, since some of counters are in the same hash). Is it ok?


Go nuts. If the hardware is up for it, Redis will be able to handle the load. Obviously you should prototype and try it out as soon as possible, but this is definitely something that Redis should be able to handle.

I suggest you think about scaling already, though. It's much easier to solve the scaling problem up front than waiting for when it becomes an issue. Redis does not (yet) have any clustering solution, and you are limited by RAM (and one CPU), so eventually you will need some way of scaling out to more servers.

The way to do it is client side sharding, i.e. for each operation you hash your key and see which server it lives on, then talk to that server (this obviously makes operations that use more than one key very hard to perform, so you may have to design around that). The Ruby client has some support out of the box, but it isn't hard (although inconvenient) to do yourself if you're using another driver (and Salvatore has a guide, too).

I suggest starting with two or four Redis instances running on the same machine (one per CPU, or something like that), plus another machine running slaves for redundancy and failover (you can also run two masters and two slaves on each server). This way it's not too much work moving instances to other servers if you need to grow. If you have four instances you will be able to move to four machines without much trouble, since all you have to do is set up a slave on the new machine, wait for it to sync and then use that as master. If you don't have four instances to start with, moving to a new machine means manually moving keys, that can be a lot of work.

0

精彩评论

暂无评论...
验证码 换一张
取 消