zoukankan      html  css  js  c++  java
  • Redis高级特性介绍以及实例分析

    Redis基础类型回顾

    转自:http://www.jianshu.com/p/af7043e6c8f9

    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


    master info

    Slave 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是一个支持持久化的内存数据库,也就是说Redis需要经常将内存中的数据同步到硬盘来保证持久化,有2种方式实现。

    RDB

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


    save机制

    AOF


    aof文件内容

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

    redis.conf:


    aof策略

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


    发布与订阅消息

    概念上比较简单,如果你订阅了频道,那么这个频道上发布的消息,你都会知道。实际中应用较多的是消息中间件(ActiveMQ,RocketMQ)的订阅发布模式(在以后的消息中间件专题再为大家介绍)。


    发布

    订阅

    Redis案例设计分析

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

    假设一个类似的场景,有几百万,甚至几千万的商品数据,考虑下如何快速实现搜索查询呢?当然,我们不可能直接查询MySQL,应该需要在MySQL上加一层,可以考虑加一层Redis。

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

    如上图所示,我们可以这样设计:

    我们事先建立好一系列的SET,实际上这些Set都是各种分类的ProductID集合

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

    要知道SET进行运算后的结果,就是ProductID集合,此时范围已经有所缩小,比起直接遍历全部商品数据要小不少

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

  • 相关阅读:
    poj 3280 Cheapest Palindrome(区间DP)
    POJ 2392 Space Elevator(多重背包)
    HDU 1285 定比赛名次(拓扑排序)
    HDU 2680 Choose the best route(最短路)
    hdu 2899 Strange fuction (三分)
    HDU 4540 威威猫系列故事――打地鼠(DP)
    HDU 3485 Count 101(递推)
    POJ 1315 Don't Get Rooked(dfs)
    脱离eclipse,手动写一个servlet
    解析xml,几种方式
  • 原文地址:https://www.cnblogs.com/badboys/p/9758627.html
Copyright © 2011-2022 走看看