Domestic and foreign giants in three fields tell you how to use redis

With the surge in data volumes, MySQL + memcache can no longer meet the needs of large-scale Internet applications, and many organizations have chosen redis as a supplement to their architecture. Here we will share with you the redis practices brought by social media giant Sina Weibo, media giant Viacom, and Pinterest, a leader in the image sharing field.

Sina Weibo: the largest redis cluster in history

Tape is dead, disk is tape, Flash is disk, Ram locality is king.-Jim Gray

Redis is not a mature alternative to memcache or MySQL, but a good complement to the architecture of large-scale Internet applications. More and more applications are also making architecture changes based on redis. First, let's briefly announce the actual situation of the redis platform:

2200 + 500 billion commands/day 50 billion read/day write/day

18 TB + Memory

500 + servers in 6 IDC 2000 + instances

It should be a big redis platform at home and abroad. Today we will talk about the redis service platform from the application perspective.

Redis application scenarios

1. Counting (count)

The Application of counting is described in more detail in another article, the optimization of counting scene http://www.xdata.me /? P = 262 I will not describe it here.

It is foreseeable that many people think that the cost of storing all the counts in the memory is very high. Here I will use a chart to express my point of view:

In many cases, you may imagine that the memory-only solution will be very costly, but the actual situation may be somewhat different:

For applications with certain throughput requirements, cost will apply for dB and cache resources separately. Many students who are worried about dB write performance will also take the initiative to log dB updates to the asynchronous queue, the utilization of these three resources is generally not too high. After calculating the resources, you are surprised to find that the pure memory solution will be simpler!

The kiss principle is very friendly for development. I only need to establish a set of connection pools without worrying about Data Consistency Maintenance and asynchronous queue maintenance.

The risk of cache penetration. If the backend uses a database, it will certainly not provide high throughput capacity. If the cache is down and not properly handled, it will be a tragedy.

Most of the initial storage requirements are small.

2. Reverse cache (reverse cache)

In the face of the hot spots that often appear on Weibo, such as the recent popularity of Short chains, tens of thousands of people click and jump in a short time, and there will often be some demand here, for example, we have displayed different content or information to determine the user level, whether there are some account bindings, Gender hobbies, and so on during a quick jump.

Generally, memcache + MySQL is used. When the call ID is valid, it can support large throughput. However, when the call ID is uncontrollable and many spam users call it, memcache will penetrate into the MySQL server in large quantities because memcache does not hit the call ID. This results in a high connection length and a low overall throughput, slow response time.

Here, we can use redis to record all user judgment information, such as string key: uid INT: type, for reverse cache. After a user quickly obtains information such as his or her level in redis, go to the MC + MySQL layer to obtain full information.

Of course, this is not the optimal scenario. For example, using redis for bloomfilter may save more memory usage.

3. top 10 list

Product Operations always show you the top list with the latest, most popular, highest click rate, and highest activity. If you use MC + MYSQL to maintain a list of frequently updated items, the possibility of cache invalidation will be relatively high. In view of the small memory usage, using redis for storage is also quite good.

4. Last Index

Recent user access records are also a good application scenario for redis list. lpush lpop automatically expires old login records, which is very friendly for development.

5. Relation List/Message Queue

Here we put the two functions at the end, because these two functions encountered some difficulties in the real problem, but at a certain stage they did solve many of our problems, so here we will only explain them.

Message Queue writes and consumes queues through the lpop and lpush interfaces of the list. Because of its good performance, it can also solve most problems.

6. Fast transaction with Lua

The expansion of redis Lua has actually brought more application scenarios to redis. You can write several command combinations as a small non-blocking transaction or update logic, such: when receiving the message push. add an unread Dialog for yourself. add an unread message to your private message. finally, send the sender a receipt to complete the PUSH message. This layer of logic can be fully implemented on the redis server.

However, it should be noted that redis will record all content of Lua script in aof and send it to slave, which will also be a great overhead for the disk and nic.

7. Instead of memcache

Many tests and applications have proved that,

Redis does not lag behind memcache in terms of performance, but the single-thread model has brought strong scalability to redis.

In many scenarios, the memory overhead of apsaradb for redis for the same data set is smaller than that allocated by Slab of apsaradb for memcache.

The data synchronization feature provided by redis is actually a powerful extension of the cache function.

Key Points of using redis

1. Rdb/AOF backup!

More than 95% of our online redis instances provide backend storage functions. We are not only used for cache, but also for K-V storage. It completely replaces the backend storage service (MySQL ), therefore, the data is very important, such as data pollution and loss, misoperation, and other situations, it will be difficult to recover. Therefore, backup is necessary! To this end, we have shared HDFS resources as our backup pool, hoping to restore the data required by the business at any time.

2. Small item & Small instance!

Because redis single-thread (not a single-thread strictly, but considers request processing as a single-thread) model, large data structure list, sorted set, batch Processing of hash sets means waiting for other requests. Therefore, you must control the size of a single key-struct when using the complex data structure of redis.

In addition, the memory capacity of a single redis instance should be strictly limited. When the memory capacity of a single instance is large, the direct problem is that the fault recovery or rebuild slave database takes a long time. What's worse, when redis rewrite aof and save RDB, this will bring about a very large and long system pressure and occupy additional memory, which may lead to online faults that seriously affect performance, such as insufficient system memory. We do not recommend that the capacity of a single instance be larger than 20/30 GB for 96g/g memory servers online.

3. Been available!

Redis sentinel (Sentinel) is widely used in the industry)

Http://www.huangz.me/en/latest/storage/redis_code_analysis/sentinel.html

Http://qiita.com/wellflat/items/8935016fdee25d4866d9

Row 3 C provides functions such as server status detection and automatic failover.

However, because the actual architecture is often complicated, or there are many perspectives to consider, @ Xu Qi eryk and I have done the Hypnos project together.

Hypnos is a mythical sleep, literally hoping that our engineers do not have to deal with any faults at rest. :-)

The working principle is as follows:

Talk is cheap, show me your code! I will write a blog later to elaborate on the implementation of Hypnos.

4. In memory or not?

It is found that when developing backend resources, developers often learn about product positioning due to habits and errors, while ignoring the evaluation of real users. Maybe this is a historical data. Only the data of the last day can be accessed. However, it is unreasonable to throw the capacity of historical data and the Request volume of the last day to the memory storage.

So when you are actually using what kind of data structure storage, please be sure to measure the cost first. How much data needs to be stored in the memory? The amount of data is meaningful to users. This is actually crucial to the design of backend resources. The 1 GB Data capacity and 1 TB data capacity are completely different from the design concept.

Plans in future?

1. Slave sync Transformation

The online master-slave data synchronization mechanism was transformed. We used the MySQL replication idea and RDB + aof + POS as the basis for data synchronization, here is a brief description of why the official psync does not meet our needs:

Assume that a has two slave databases, B and C, and a'-B & C. At this time, we find that the master a server has the potential to crash and needs to be restarted or node A goes down directly, switch B to the new master database. If A, B, and C do not share the RDB and aof information, C will still clear its own data when it acts as the slave database of B, because node C only records the synchronization with node.

Therefore, we need a synchronization mechanism to switch the'-B & C structure to the'-B '-C structure. Although psync supports resumable data transfer, however, it still cannot support smooth master failover.

In fact, we have used the synchronization of the above functions on our customized redis counting service, which has a very good effect and solves the O & M burden, but still need to be promoted to all redis services, if possible, we will also propose improvements to sync slave to official redis.

2. More suitable for redis name-system or proxy

Careful colleagues found that apart from using DNS as the naming system, we also have a record in zookeeper. Why don't users directly access a system?

In fact, it is still very simple. The naming system is a very important component, and DNS is a set of well-developed naming systems. We have made many improvements and trial and error to this end. The implementation of ZK is still relatively complicated, we do not have a strong granularity for control. We are also thinking about what to use as a naming system to better meet our needs.

3. backend Data Storage

The use of large memory is certainly an important direction for cost optimization. flash disks and distributed storage are also under our future plan.