The social product business has many statistical counting functions, such as:
Users: The total number of praise, attention, number of fans
Post: Number of praise, comments, heat
Message: Read, unread, red dot message number
Topic: Reading number, post number, collection number
The characteristics of statistical counting
High Real time requirements
It's written in a very high frequency.
Write performance is a challenge for MySQL
Redis can be used to optimize performance requirements for high frequency writes.
Redis Optimization Program A
For each entity count, design a hash structure of counter:
//user
Counter:user:{userid}
-> praisecnt:100 //Point of Praise
-> hostcnt: 200 //Heat
-> followcnt:332 //Number of concerns
-> fanscnt:123 //Number of fans
//Post
Counter:topic:{topicid}
-> praisecnt:100 //Point of Praise
-> commentcnt:322 / /Number of comments
Topic
Counter:subject:{subjectid}
-> favocnt:312//Collection number
-> viewcnt:321//reading number
-> searchcnt:212//Search entry times
-> topiccnt:312//topic number of posts
Similar to this counter, as the product features increased, there will be more and more, such as the number of replies, the number of steps, forwarding number of what.
Redis-related commands
Gets all counters for the specified userid
Hgetall Counter:user:{userid}
Gets the specified counter for the specified userid
Hmget Counter:user:{userid} praisecnt hostcnt
Specify the userid point of Praise +1
Hincrby Counter:user:{userid} praisecnt
Disadvantages:
This design, if you want to bulk query the data of multiple users, it is more troublesome, such as the first time to check the specified 20 userid counters? You can only loop through Hgetall Counter:user:{userid}.
Advantages:
Aggregating data in an entity to facilitate data management
Redis Optimization Scheme II
Scheme two is used to solve the shortcomings of the solution one, still using hash, structural design is such:
Counter:user:praiseCnt
-> userid_1001:100
-> userid_1002:200
-> userid_1003:332
-> userid_1004:123
.......
-> userid_9999:213
Counter:user:hostCnt
-> userid_1001:10
-> userid_1002:290
-> userid_1003:322
-> userid_1004:143
.......
-> userid_9999:213
Counter:user:followCnt
-> userid_1001:21
-> userid_1002:10
-> userid_1003:32
-> userid_1004:203
.......
-> userid_9999:130
The command to get multiple points of the specified userid becomes this:
Hmget counter:user:praiseCnt userid_1001 userid_1002
The above command can be used to bulk get multiple users of the point of praise, time complexity of O (n), n is the number of specified userid.
Advantages:
Solve the problem of bulk operation
Disadvantages:
When you want to get more than one counter, such as when you need to praisecnt,hostcnt, read multiple times, but less often than the first scenario.
A hash of the field will be very pet big, hmget may have performance bottlenecks.
Using Redis Pipeline (pipelining) to optimize the scheme a
For the disadvantage of the first scenario, you can optimize by Redis pipeline, sending multiple commands at once to Redis execution:
$userIDArray = Array (1001, 1002, 1003, 1009);
$pipe = $redis->multi (redis::P ipeline);
foreach ($userIDArray as $userID) {
$pipe->hgetall (' Counter:user: '. $userID);
}
$replies = $pipe->exec ();
Print_r ($replies);
Another way is to execute LUA scripts on Redis, if you have to learn to write Lua.