简明实用：Redis高级特性与案例介绍

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

Redis基础类型回顾

String

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

Hash

Hash结构适用于存储对象&＃xff0c;相较于String&＃xff0c;存储占用更少的内存。Hash结构可以使你像在数据库中Update一个属性一样只修改某一项属性值&＃xff0c;而且还可以快速定位数据。比如&＃xff0c;如果我们把表User中的数据可以这样放置到Redis中&＃xff1a;Hash存储&＃xff0c;KEY&＃xff1a;User&＃xff0c;Field:USERID&＃xff0c;VALUE&＃xff1a;user序列化后的string。

List

既可以当做栈、又可以当做队列。实际上&＃xff0c;可以利用List的先进先出或者先进后出的特性维护一段列表&＃xff0c;比如排行榜、实时列表等&＃xff0c;甚至还可以简单的当做消息队列来使用。

Set

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

ZSet

ZSet就是SortedSet。实际中&＃xff0c;很多排序场景都可以考虑ZSet来做。

Redis发展过程中的三种模式&＃xff1a;主从、哨兵、集群

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

主从模式

Redis早期用于保证数据可靠性的一种简单方式。具体来说&＃xff0c;Master可用于写、读&＃xff0c;而Slave一般只用于读。

其实在配置上相当简单&＃xff0c;只需要在Slave节点配置下Master的IP、PORT、密码即可。

Master info

Slave info

一个Master可以拥有多个Slave

主从复制不会阻塞住Master&＃xff0c;在同步数据时Master可以继续处理client端请求

哨兵模式

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

实质上&＃xff0c;在Master-Slave模式基础上&＃xff0c;只需要在启动一个哨兵服务进行监听就可以&＃xff0c;这个哨兵服务可以部署在Master/Slave上&＃xff0c;也可以部署到其他机器上。当然&＃xff0c;在实际中为了避免哨兵节点的单点性&＃xff0c;也会配置多个哨兵服务。

哨兵节点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

我们需要告诉哨兵服务&＃xff1a;

监控的主节点的IP&＃xff0c;PORT

如果master挂了&＃xff0c;那么选举的时候&＃xff0c;slave达到多少票就可以成为主节点

监控主节点的心跳频率

主节点下有多少slave

集群模式

Redis集群模式是目前应用非常广泛的&＃xff0c;Redis集群模式的出现&＃xff0c;也使得以前的一些Redis技术&＃xff0c;比如分片、都不在适用了&＃xff0c;同时数据的高可靠、数据分布性、服务的高可用性进一步加强。关于Redis集群将在下一篇博客中详细介绍。

Redis的简单事务

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

Redis持久化机制

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

RDB

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

AOF

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