Redis应用场景

NoSQL技术（not only sql）

日常的开发中基本都是使用传统数据库来进行数据存储，由于一般系统通常不会存在高并发，所以这样看起来并没有什么问题，可一旦涉及大数据量的需求，比如一些商品抢购的情景，或者主页访问量瞬间较大的时候，磁盘读/写速度比较慢的问题而存在严重的性能弊端，可能最终导致服务宕机的严重生产问题。为了克服上述的问题，项目通常会引入NoSQL技术

Nosql技术对比

从以下几个方面，对redis、memcache、mongoDB 做了对比

1、性能

都比较高，性能对我们来说应该都不是瓶颈

总体来讲，redis和memcache差不多，要大于mongodb。

2、操作的便利性

memcache数据结构单一

redis丰富一些，数据操作方面，redis更好一些，较少的网络IO次数

mongodb支持丰富的数据表达，索引，最类似关系型数据库，支持的查询语言丰富

3、可用性（单点问题）

redis的集群方式共有三种：主从模式，哨兵模式，cluster(集群)模式

Memcache本身没有数据冗余机制，（1.本地备份缓存，2.缓存代理服务器）

mongoDB支持master-slave；

4、可靠性（持久化）

对于数据持久化和数据恢复，

redis支持（RDB、AOF）个性化的持久化方案

memcache不支持，通常用在做缓存,提升性能；

MongoDB从1.8版本开始采用binlog方式支持持久化的可靠性

5、数据一致性（事务支持）

Memcache 在并发场景下，用cas保证一致性

redis事务支持比较弱，只能保证事务中的每个操作连续执行

mongoDB不支持事务,(4.0支持)

为什么选择Redis

1.对比mysql

redis读写性能测试redis官网测试读写能到10万左右

mysql读能力5K/s、写能力为3K/s

数据上看redis性能碾压mysql

2.自身优点

I/O多路复用

I/O多路复用机制，简单打一个比方：张三开了一家快递店，负责同城快送服务。因为资金限制，雇佣了一批快递员，只够买一辆车送快递。

经营方式一

客户每送来一份快递就让一个快递员盯着，然后快递员开车去送快递。慢慢的就发现了这种经营方式存在下述问题

几十个快递员基本上时间都花在了抢车上了，大部分快递员都处在闲置状态，谁抢到了车，谁就能去送快递

随着快递的增多，快递员也越来越多快递店里越来越挤，没办法雇佣新的快递员了

快递员之间的协调很花时间

经营方式二

只雇佣一个快递员。客户送来的快递，按送达地点标注好，然后依次放在一个地方。最后，那个快递员依次的去取快递，一次拿一个，然后开着车去送快递，送好了就回来拿下一个快递。

于是有如下结论

1、经营方式一就是传统的并发模型，每个I/O流(快递)都有一个新的线程(快递员)管理。

2、经营方式二就是I/O多路复用。只有单个线程(一个快递员)，通过跟踪每个I/O流的状态(每个快递的送达地点)，来管理多个I/O流。

Redis五种数据类型及适用业务场景

1. String:可以认为是一个键值对

适用场景：

1.存储验证码,2.共享session实现，3.计数器功能

2. Hash:类似于java中的hashMap，是一个 string 类型的 field 和 value 的映射

适用场景：

1. 缓存业务对象;例如存储用户对象数据

2. 存储购物车数据:这里的key为用户id，value为商品列表(这里字符串代替)

3. List:字符串列表，按插入顺序排序,特点是可以自己选择添加元素到头还是尾；

应用场景:

1.构造数据结构

lpush + lpop 栈

lpush + rpop 队列

2.消息队列

4. Set:无顺无重复元素集合,集合是通过哈希表实现的,所以增删查的复杂度都是 O(1)。

应用场景:

1.全局去重的功能。(为什么不用JVM自带的Set进行去重？因为如果系统是集群部署，需要再起一个公共服务，较繁琐），

2还可利用交集、并集、差集等操作，可以计算共同喜好，全部的喜好，自己独有的喜好等功能。

如图求差集：返回的为set2相对于set3的差集

5. Zset:和set类似无重复元素集合,且可以通过人为设置score来进行排序。

应用场景:

1.业务排行榜

2.获取分数排行榜