Brief application scenario redis

A product usage scenario certainly need to characteristics of the product, the first list what features Redis:

• Good read and write performance
• Endurance of
• Rich data types
• Single-threaded
• Data is automatically expired
• Publish and subscribe
• distributed

 

Here are a few scenarios, different dimensions of said application under the Redis.

 

Suitable as high-performance cache

 

Redis cache is the most common scenarios , so use it all, mainly because of excellent Redis read and write performance. And there is a growing replace memcached, as the preferred server-side caching components. Moreover, the internal affairs of Redis is supported in the use of time can effectively ensure data consistency. Use as a cache, there are two ways to save data:

1, before reading, reading Redis go, if there is no data, reading the database, the pull-up data into Redis

2, insert the data, while write Redis

 

Option One: simple to implement, but there are two caveats:

1, avoid caching breakdown. (No need to hit the database data has not led to Redis data, and has been hitting the database.)

2, real-time data will be relatively narrowly.

 

Option Two: real-time data is strong, but not easy to develop a unified processing.

 

Of course, two ways to apply the actual situation. Such as: a program suitable for real-time data requirements are not particularly high scene. Option II applies to dictionary table, the amount of data stored data.

 

More rich data format, feature-rich application scenarios

 

Redis compared to other caches, there is a very big advantage, it is to support multiple data types.

 

Description string data type string, the simplest kv hashhash storage format, value for the field and value, for such a scenario ID-Detail. list simple list, order list, or the first end support insert data set unordered list, fast lookup for intersection and union, difference processing the sorted set ordered set

 

In fact, by the above data types of features, the basic can think of a suitable application scenarios.

• Suitable string-- simplest kv storage memcached similar storage structure, and message authentication code, configuration information, etc., to use this type of storage
• hash-- general key for the ID or unique identifier, value that corresponds to the details. Such as commodity information, personal information details, news and other details
• Because list-- list are ordered, and more suitable for storing data corresponding fixed number of ordered data. As provinces tables, dictionary tables and so on. Because the list is ordered, sorted according to the time for writing, such as: *** The latest, message queues, etc.
• set-- can be simply understood as ID-List mode, such as a micro-blog in which man friends, where the cattle is that SET, SET may provide the intersection of the two, and union, difference operation. For example: Find two people together friends, etc.
• Sorted Set-- is an enhanced version of the set, and adds a score parameters will be automatically sorted based on the value of the score. Compare similar top 10 and the like are not ordered according to the time of insertion data

 

As mentioned above, although not as a relational database Redis less complex data structures, but also for a lot of scenes, to more than the average cache data structure. Understanding of data structures for each business scenario, not only help enhance the development efficiency can be effectively utilized in the performance of Redis.

 

It can be used as single-threaded distributed lock

 

Speaking difference Redis and Memcached, we are talking about more data structures and persistence of these two characteristics, in fact, there is a relatively large difference is:

• Redis is single-threaded, improving the processing efficiency multiplexing
• Memcached is multi-threaded, to improve the processing efficiency by the CPU thread switch

 

So this feature Redis single-threaded, it is actually very important application scenarios, the most commonly used is a distributed lock.

Deal with highly concurrent systems, all with multi-server deployment, each technical framework for data lock has a very good approach, such as .net's lock, java's synchronized, by locking an object can respond to the thread lead the data pollution problems. But after all, this thread can only control server, distributed deployment of data pollution problems in the future, it is more difficult to handle the. Redis is single-threaded this feature, it is very consistent with this demand, the pseudo-code is as follows:

/ Generated Lock

while lock!=1

// expiration time in order to avoid a deadlock 

now = int (time.time ())

lock_timeout = now + LOCK_TIMEOUT + 1

lock = redis_client.setnx(lock_key, lock_timeout)


//真正要处理的业务

doing()

//释放锁

now = int(time.time())

if now < lock_timeout:

redis_client.delete(lock_key)

以上是一个只说明流程的伪代码，其实整体的逻辑是很简单的，只要考虑到死锁时的情况，就比较好处理了。Redis作为分布式锁，因为其性能的优势，不会成为瓶颈，一般会产生瓶颈的是真正的业务处理内容，还是尽量缩小锁的范围来确保系统性能。

 

自动过期能有效提升开发效率

 

Redis针对数据都可以设置过期时间，这个特点也是大家应用比较多的，过期的数据清理无需使用方去关注，所以开发效率也比较高，当然，性能也比较高。最常见的就是：短信验证码、具有时间性的商品展示等。无需像数据库还要去查时间进行对比。因为使用比较简单，就不赘述了。

 

分布式和持久化有效应对海量数据和高并发

 

Redis初期的版本官方只是支持单机或者简单的主从，大多应用则都是自己去开发集群的中间件，但是随着应用越来越广泛，用户关于分布式的呼声越来越高，所以Redis 3.0版本时候官方加入了分布式的支持，主要是两个方面：

• Redis服务器主从热备，确保系统稳定性
• Redis分片应对海量数据和高并发

 

而且Redis虽然是一个内存缓存，数据存在内存，但是Redis支持多种方式将数据持久化，写入硬盘，所有，Redis数据的稳定性也是非常有保障的，结合Redis的集群方案，有的系统已经将Redis当做一种NoSql数据存储来适用。

 

示例：秒杀和Redis的结合

 

秒杀是现在互联网系统中常见的营销模式，作为开发者，其实最不愿意这样的活动，因为非技术人员无法理解到其中的技术难度，导致在资源协调上总是有些偏差。秒杀其实经常会出现的问题包括：

• 并发太高导致程序阻塞
• 库存无法有效控制，出现超卖的情况

 

其实解决这些问题基本就两个方案：

• 数据尽量缓存,阻断用户和数据库的直接交互
• 通过锁来控制避免超卖现象

 

现在说明一下，如果现在做一个秒杀，那么，Redis应该如何结合进行使用?

• 提前预热数据，放入Redis
• 商品列表放入Redis List
• 商品的详情数据 Redis hash保存，设置过期时间
• 商品的库存数据Redis sorted set保存
• 用户的地址信息Redis set保存
• 订单产生扣库存通过Redis制造分布式锁，库存同步扣除
• 订单产生后发货的数据，产生Redis list，通过消息队列处理
• 秒杀结束后，再把Redis数据和数据库进行同步

 

以上是一个简略的秒杀系统和Redis结合的方案，当然实际可能还会引入http缓存，或者将消息对接用MQ代替等方案，也会出现业务遗漏的情况。

 

每个技术都有属于自己的应用场景，只有对技术的特点有一定清晰的认识，才能更好的利用技术，发挥其最大的优势。