Why redis redis application scenarios

First, is not a panacea Philippine relations department database redis

In the interview, the comparison is often asked at the advantages and disadvantages of Redis and Memcache, both personally feel is not suitable for comparison with, redis: a non-relational database cache is also capable not only can do other things, Memcache: caching is only done . Often let us compare these two, it is largely due to the widest range of application scenarios Redis is Cache.

1.2 redis Why can

1. Cache, there is no doubt it is best known today Redis usage scenarios. Further enhance server performance is very effective;

2. Charts, using a traditional relational database (like MySQL Oracle) thing to do this is very troublesome, and the use of Redis SortSet (ordered set) to get the data structure can be simple;

3. Calculator / speed limiter, Redis use in atomic increment operation, we can count the number of similar user point of praise, such as the number of users to access, if such operations with MySQL, frequent reading and writing will bring considerable pressure; governor typical usage scenario is to limit a user to access an API of frequency commonly used when buying, to prevent users from unnecessary clicks crazy pressure;

4. Friendship, use a set of commands, such as seeking the intersection, union, difference and so on. It can easily get some common friends, common interests such functions;

5. Simple message queue, in addition to its own Redis publish / subscribe model, we can also use List to implement a queuing mechanism, such as: notice of arrival, demand to send the message class, does not require high reliability, but will bring a very large DB pressure, can be done with List asynchronous decoupling;

6. Session sharing to PHP, for example, the default Session is stored in the file server, if a cluster service, the same user may fall over on different machines, which can lead to frequent user login; using Redis Save Session after, regardless of the user falls on that machine will be able to obtain information corresponding to the Session.

7. Some frequently accessed data, the data frequently accessed if placed in a relational database, the cost of each query will be great, but in redis because redis is placed in memory can be very efficient access

Better not to do with 1.3 redis

With Redis to save the user's basic information, although it can support persistence, but its persistence solution does not guarantee its floor, and could also bring performance degradation Redis, because too often will increase the persistence Redis service pressure.

Conclusion is too much data, data access frequency is very low traffic are not suitable for use Redis, data is too large increase in cost, access frequency is too low, stored in memory is a waste of resources.

The reason for using redis

Some scenarios mentioned above, the cache can Memcache, Session sharing MySql can be implemented, the message queue and the like can be used RabbitMQ,

Reason:
based entirely on memory so fast, using the C language, the network layer using epoll address the high concurrency problems, single-threaded model avoids unnecessary context switches and competitive conditions; Note: only single-threaded network is said in this request the client request processing module with a request, when it will reopen persistent thread / process to be processed

Rich data types, Redis there are eight kinds of data types, commonly used with String, Hash, List, Set, SortSet these five, all based on a key way of organizing data. Each type of data provides a wealth of operational command to meet the needs of the vast majority of

Redis open source code at GitHub, the code is very simple and elegant, will be able to take the time to read; it's also very simple to compile and install, there is no other system-dependent; various client language support is also very well. It also supports transactions, persistence, master-slave replication allows highly available, distributed as possible.

Life still make sense. It must have been still looking for a reason to exist

 

Original Address: https://www.cnblogs.com/shiqi17/p/9581752.html

First, is not a panacea Philippine relations department database redis

In the interview, the comparison is often asked at the advantages and disadvantages of Redis and Memcache, both personally feel is not suitable for comparison with, redis: a non-relational database cache is also capable not only can do other things, Memcache: caching is only done . Often let us compare these two, it is largely due to the widest range of application scenarios Redis is Cache.

1.2 redis Why can

1. 缓存，毫无疑问这是Redis当今最为人熟知的使用场景。再提升服务器性能方面非常有效；

2. 排行榜，在使用传统的关系型数据库（mysql oracle 等）来做这个事儿，非常的麻烦，而利用Redis的SortSet(有序集合)数据结构能够简单的搞定；

3. 计算器/限速器，利用Redis中原子性的自增操作，我们可以统计类似用户点赞数、用户访问数等，这类操作如果用MySQL，频繁的读写会带来相当大的压力；限速器比较典型的使用场景是限制某个用户访问某个API的频率，常用的有抢购时，防止用户疯狂点击带来不必要的压力；

4. 好友关系，利用集合的一些命令，比如求交集、并集、差集等。可以方便搞定一些共同好友、共同爱好之类的功能；

5. 简单消息队列，除了Redis自身的发布/订阅模式，我们也可以利用List来实现一个队列机制，比如：到货通知、邮件发送之类的需求，不需要高可靠，但是会带来非常大的DB压力，完全可以用List来完成异步解耦；

6. Session共享，以PHP为例，默认Session是保存在服务器的文件中，如果是集群服务，同一个用户过来可能落在不同机器上，这就会导致用户频繁登陆；采用Redis保存Session后，无论用户落在那台机器上都能够获取到对应的Session信息。

7. 一些频繁被访问的数据，经常被访问的数据如果放在关系型数据库，每次查询的开销都会很大，而放在redis中，因为redis 是放在内存中的可以很高效的访问

1.3 最好别用redis 来做

用Redis去保存用户的基本信息，虽然它能够支持持久化，但是它的持久化方案并不能保证数据绝对的落地，并且还可能带来Redis性能下降，因为持久化太过频繁会增大Redis服务的压力。

总结就是数据量太大、数据访问频率非常低的业务都不适合使用Redis，数据太大会增加成本，访问频率太低，保存在内存中纯属浪费资源。

使用redis的理由

上面所说的一些场景， 缓存可以用Memcache，Session共享能用MySql来实现，消息队列可以用RabbitMQ等，

理由：
完全基于内存所以速度很快，使用C语言实现，网络层使用epoll解决高并发问题，单线程模型避免了不必要的上下文切换及竞争条件； 注意：单线程仅仅是说在网络请求这一模块上用一个请求处理客户端的请求，在持久化时它就会重开一个线程/进程去进行处理

丰富的数据类型，Redis有8种数据类型，常用的有 String、Hash、List、Set、 SortSet 这5种，都是基于键值的方式组织数据。每一种数据类型提供了非常丰富的操作命令，可以满足绝大部分需求

Redis的代码开源在GitHub，代码非常简单优雅，愿意花时间就能去看懂；它的编译安装也很简单，不存在其他系统依赖；各种客户端的语言支持也是非常完善。另外它还支持事务、持久化、主从复制让高可用、分布式成为可能。