Redis高级特性介绍及实例分析

本文将为你们介绍Redis的一些高级特性以及结合一个具体的实际案例来对Redis进行设计分析。

Redis基础类型回顾

String

Redis中最基本，也是最简单的数据类型。注意，VALUE既能够是简单的String,也能够是复杂的String，如JSON，在实际中经常利用fastjson将对象序列化后存储到Redis中。另外注意mget批量获取能够提升效率。

Hash

Hash结构适用于存储对象，相较于String，存储占用更少的内存。Hash结构可使你像在数据库中Update一个属性同样只修改某一项属性值，并且还能够快速定位数据。好比，若是咱们把表User中的数据能够这样放置到Redis中：Hash存储，KEY：User，Field:USERID，VALUE：user序列化后的string。

List

既能够当作栈、又能够当作队列。实际上，能够利用List的先进先出或者先进后出的特性维护一段列表，好比排行榜、实时列表等，甚至还能够简单的当作消息队列来使用。

Set

Set是String类型的不重复无序集合。Set的特色在于，它提供了集合的一些运算，好比交集、并集、差集等。这些运算特性，很是方便的解决实际场景中的一些问题，如共同关注、共同粉丝等。

ZSet

ZSet就是SortedSet。实际中，不少排序场景均可以考虑ZSet来作。

Redis发展过程当中的三种模式：主从、哨兵、集群

Redis的发展能够从版本的变化看出来，从1.X的主从模式，到2.X的哨兵模式，再到今天3.X的集群模式，能够说这些都是Redis保证数据可靠性、高可用的思路。下面咱们来简单实践下。环境说明：这里准备了4台Centos Linux,装有redis的3.0版本。

主从模式

Redis早期用于保证数据可靠性的一种简单方式。具体来讲，Master可用于写、读，而Slave通常只用于读。

其实在配置上至关简单，只须要在Slave节点配置下Master的IP、PORT、密码便可。

192.168.99.122/123 redis.conf:

Master info

Slave info

注意：

一个Master能够拥有多个Slave

主从复制不会阻塞住Master，在同步数据时Master能够继续处理client端请求

哨兵模式

对于主从复制模式而言，有个明显的缺点：一旦主节点挂了，那么redis服务将不可用。在2.X中，为了确保可高用，因此发展出来哨兵模式。顾名思义，就是哨兵站岗，去监听master心跳，若是master挂了，那么将从slave中选举出一个master来，从而实现了故障自动切换。

实质上，在Master-Slave模式基础上，只须要在启动一个哨兵服务进行监听就能够，这个哨兵服务能够部署在Master/Slave上，也能够部署到其余机器上。固然，在实际中为了不哨兵节点的单点性，也会配置多个哨兵服务。

哨兵节点192.168.99.124  sentinel.conf:

sentinel monitor mymaster 192.168.99.121 6379 1
sentinel down-after-milliseconds mymaster 5000
sentinel parallel-syncs mymaster 2

咱们须要告诉哨兵服务：

监控的主节点的IP,PORT

若是master挂了，那么选举的时候，slave达到多少票就能够成为主节点

监控主节点的心跳频率

主节点下有多少slave

集群模式

Redis集群模式是目前应用很是普遍的，Redis集群模式的出现，也使得之前的一些Redis技术，好比分片、都不在适用了，同时数据的高可靠、数据分布性、服务的高可用性进一步增强。关于Redis集群将在下一篇博客中详细介绍。

Redis的简单事务

目前来看，Redis对事务的支持是比较简单的，在实际应用中，咱们基本上是不会使用的。看一个实例，你就会明白。经过multi开启事务，经过exec来提交事务。能够看到，redis的事务目前是不支持一块儿成功，一块儿失败这种基本要求的，即使在事务中有错误，亦不会回退，和MySQL的事务功能相距甚远吧。

Redis持久化机制

Redis是一个支持持久化的内存数据库，也就是说Redis须要常常将内存中的数据同步到硬盘来保证持久化，有2种方式实现。

RDB

RDB方式，也称做快照snapshotting，将内存中的数据以快照的方式写入到二进制文件dump.rdb中，这种方式也是redis的默认方式。能够在redis.conf中设置保存的策略。一句话：redis在N秒内若是超过M个KEY发生修改则自动作快照保存。

AOF

AOF，即Append-Only File。要知道RDB的方式，是在必定的时间间隔作一次，若是redis意外down掉，这将意味着会丢失最后一次快照后的全部修改数据，这在生产环境将不太可能接受。AOF比RDB有着更好的持久化方式，经过AOF，redis会将每个收到的写命令都经过write函数追加到命令中，当redis从新启动时，会从新执行文件中保存的写命令来重建数据内容。

redis.conf:

在实际应用中，为了确保数据高可靠性，应该使用always策略。

发布与订阅消息

概念上比较简单，若是你订阅了频道，那么这个频道上发布的消息，你都会知道。实际中应用较多的是消息中间件（ActiveMQ,RocketMQ）的订阅发布模式（在之后的消息中间件专题再为你们介绍）。

Redis案例设计分析

咱们先来看一个京东上进行商品搜索的图：

假设一个相似的场景，有几百万，甚至几千万的商品数据，考虑下如何快速实现搜索查询呢？固然，咱们不可能直接查询MySQL，应该须要在MySQL上加一层，能够考虑加一层Redis。

将MySQL中的数据加载至Redis中，给定条件，直接遍历Hash数据进行查询。若是就这样简单的设计的话，对于京东这样的大流量平台，天天有很是多的人进行商品搜索，并且每一个人搜索的条件还不同，根本没法快速响应。

如上图所示，咱们能够这样设计：

1. 咱们事先创建好一系列的SET，实际上这些Set都是各类分类的ProductID集合

2. 用户的搜索条件，实际上就是各类SET进行交、并、补的运算而已

3. 要知道SET进行运算后的结果，就是ProductID集合，此时范围已经有所缩小，比起直接遍历所有商品数据要小很多

上这里也能够看出，Redis虽然用起来简单，可是要综合运用，并根据业务场景进行设计，仍是挺有意思的。到这里就结束了，咱们下期Redis集群再见！