Brief introduction of the application of Redis count in Sina Weibo

The rapid development of micro-blogging business is becoming more and more demanding on the infrastructure level. Sina as the earliest use of Redis, and is the largest Redis users, in the Redis use, is also gradually optimized and improved.

As one of the important data in Weibo, the proportion and importance of counting business in micro-blogging business is increasing gradually. The accuracy of the counting result directly affects the user experience, and it can easily cause the user's complaint. In the counting business, in the continuous optimization and improvement, we mainly experienced the following three stages:

Primary Stage

Starting from 2010, use the redis-2.0 version. When the initial business data is relatively small, the performance is quite good. However, as the amount of data and the number of requests to increase, some problems gradually exposed.

Master-Slave synchronization problem

First of all, the master-slave synchronization problem is encountered. The principle is that when master receives the slave synchronization request, it dumps the memory data fork a subprocess, forms the Rdb file, and then uploads it to the slave,slave and loads the file into memory. Subsequent incremental updates are synchronized to slave by master immediately after each modification command is executed. In the case of a network problem, such as the instantaneous break, will cause the data in the slave all retransmission. For a single port, if the amount of data is small, this effect is not significant, and if the amount of data is large, the network traffic will increase, and slave can not respond to any requests when loading RDB.

Persistence issues

This column more highlights: http://www.bianceng.cnhttp://www.bianceng.cn/webkf/tools/

Most of the counting business uses Redis as storage, so all the aof are turned on and configured to do a Fsync operation per second to flush the write to disk. With the growth of aof, regular rewrite is required. The mechanism of rewrite is similar to the process of generating RDB, which is done by fork a subprocess, which causes the fsync operation of the parent process to block, causing a large number of requests to timeout for the continuous write of the disk.

Version upgrade issues

Because Redis has more bugs at the beginning of its use and has frequent version iterations, version upgrades need to shut down the Redis process and reload the AOF. For a large number of use of redis microblogging business, such upgrade costs are increasingly difficult to bear.

Memory usage Issues

2.0 version of the Redis, in memory usage is relatively extensive, for counting such a simple key-value, occupy more than 100 bytes of memory, there are more optimization space.

Advanced Stage

We have improved one by one, aiming at the problems in the early Redis use. Master-slave copy reference MySQL synchronization mode, using rdb+aof combination of the way to solve the network transient caused by retransmission problem, while restricting the child process to do background dump when the disk writes, during the suspension of the main process of the fsync operation, solve the problem of slow request.

For the counting business, we developed a dedicated version of the Redisscounter, a single key-value occupied by the length of the memory key plus 4 bytes of value, the use of memory reduced to the original 1/4 below. By allocating memory array and double hash technique, the large amount of pointer overhead of hash table in Redis is eliminated.

For the issue of version upgrade, we will redis core processing logic into the dynamic library, the data in memory in the global variable, through the external program to call the dynamic library of the corresponding functions to read and write data. Version upgrades require only new dynamic library files to be replaced without the need to reload the data. In this way, a version upgrade requires only one instruction to complete the code upgrade at the millisecond level without any impact on the client request.

With the above improvements, the new version starts to be heavily used, and most businesses can replace the previous mysql+memcached combination as a complete storage. For Weibo comments and forwarding number, because the microblogging entries are increasing, unable to save the full amount of data, so using the mysql+redisscounter combination, MySQL Save the full amount of data, using two groups of Redisscounter to save the last few months of hot data, Clean cold data by periodically rolling the data in two groups of Redisscounter.

Advanced Stage

With the development of micro-BO, the count for a single micro-blog has been increasing, from the original comments, forwarding number, but also increased the number of statements, 2013 also on-line reading number. Redisscounter can not solve this kind of expansion problem very well, at the same time the mysql+redisscounter rolling way is too complex, the regular rolling operation is very easy to have problems. In response to this type of problem, we are again making improvements, the key from the original string to the microblog ID, as well as the number of comments forwarded for each tweet count, we found that most of the Weibo count can be used 10~15 bit to save, so you can save multiple counts in a 4-byte value, The too large count value in the memory in addition to open up a space to save. This allows you to get all the count of the microblog by using a getting command. At the same time for the characteristics of micro-blog business, the older Weibo will be accessed fewer times, in memory using multiple arrays to save a wide range of micro-blogging, memory is not enough to the oldest group of micro-blog dump to SSDs, the internal automatic implementation of the rolling can ensure that the hot micro bo all in memory. For the access to the old data on the SSD, read and write through the asynchronous IO thread, after this improvement, removed the original MySQL storage, reduce the cost of business development and operation and maintenance costs.

From the development experience of Redis in counting business, we can see that the technological progress is driven by the demand of the business. As the business progresses, more new challenges will be encountered. Hopefully, these improvements will help readers in the process of using Redis.