Design: A Distributed Counter
Q: Why we need distributed counters?
Counter represents a single integer value waving up so fast you can tolerate incorrect values.
- Number of likes on Facebook - Number of retweets on Twitter - Number of shares traded on an exchange - Clicks, views, etc
Q: What about using RDMBS to support counters?
Prior to counters, solutions for counting looked like this: - one column per increment, with a batch background job - external synchronization (Zookeeper, through Cages) - use another database (Redis, PostgreSQL, . . . )
Yes, with one update SQL statement, it’s done.
But this design will have severe performance issues, if the data volume is big. You physically can’t issue new updates if the last one hasn’t finished.
Besides the design can’t scale easily.
Q: What about using queue to support counters via async updates?
Q: What about using vector clocks to accept distributed writes, then merge them?
Q: How to implement counters via Redis
A: Use Redis INCR command. The counter pattern is the most obvious thing you can do with Redis atomic increment operations.
- Concepts For System Design
- Distributed Counters in Cassandra
- JGroups CounterService
- Highly Available Counters Using Cassandra