共计 3607 个字符，预计需要花费 10 分钟才能阅读完成。
本文将为大家介绍 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:
1
2
3
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 数据进行查询。如果就这样简单的设计的话，对于京东这样的大流量平台，每天有非常多的人进行商品搜索，而且每个人搜索的条件还不一样，根本无法快速响应。
如上图所示，我们可以这样设计：
我们事先建立好一系列的 SET，实际上这些 Set 都是各种分类的 ProductID 集合
用户的搜索条件，实际上就是各种 SET 进行交、并、补的运算而已
要知道 SET 进行运算后的结果，就是 ProductID 集合，此时范围已经有所缩小，比起直接遍历全部商品数据要小不少
上这里也可以看出，Redis 虽然用起来简单，但是要综合运用，并根据业务场景进行设计，还是挺有意思的。到这里就结束了，我们下期 Redis 集群再见！
下面关于 Redis 的文章您也可能喜欢，不妨参考下：
Ubuntu 14.04 下 Redis 安装及简单测试 http://www.linuxidc.com/Linux/2014-05/101544.htm
Redis 主从复制基本配置 http://www.linuxidc.com/Linux/2015-03/115610.htm
CentOS 7 下 Redis 的安装与配置 http://www.linuxidc.com/Linux/2017-02/140363.htm
Ubuntu 14.04 安装 Redis 与简单配置 http://www.linuxidc.com/Linux/2017-01/139075.htm
Ubuntu 16.04 环境中安装 PHP7.0 Redis 扩展 http://www.linuxidc.com/Linux/2016-09/135631.htm
Redis 单机 & 集群离线安装部署 http://www.linuxidc.com/Linux/2017-03/141403.htm
CentOS 7.0 安装 Redis 3.2.1 详细过程和使用常见问题 http://www.linuxidc.com/Linux/2016-09/135071.htm
Ubuntu 16.04 环境中安装 PHP7.0 Redis 扩展 http://www.linuxidc.com/Linux/2016-09/135631.htm
Ubuntu 15.10 下 Redis 集群部署文档 http://www.linuxidc.com/Linux/2016-06/132340.htm
Redis 实战 中文 PDF http://www.linuxidc.com/Linux/2016-04/129932.htm
Redis 热迁移实战总结 http://www.linuxidc.com/Linux/2017-02/141083.htm
Redis3.0 配置文件详解 http://www.linuxidc.com/Linux/2017-03/141369.htm
Redis 的详细介绍：请点这里
Redis 的下载地址：请点这里
本文永久更新链接地址：http://www.linuxidc.com/Linux/2017-03/141682.htm
