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