Redis 集群详解 环境搭建 调用案例

http://www.jianshu.com/p/dbc62ed27f03

这是redis集群介绍的上篇，主要是关于Redis集群的搭建。后续将为大家介绍Redis集群的常用命令、Java操作Redis集群、以及与Spring/Spring MVC的整合等知识。

Redis集群搭建

要想搭建一个最简单的Redis集群，那么至少需要6个节点：3个Master和3个Slave。为什么需要3个Master呢？如果你了解过Hadoop/Storm/Zookeeper这些的话，你就会明白一般分布式要求基数个节点，这样便于选举（少数服从多数的原则）。



Redis集群模型

这里，我将采用一种“偷懒”的方式，在一个Linux虚拟机上搭建6个节点的Redis集群。（因为开启6个Linux虚拟机，我的电脑完全扛不住）

实际上，思路很简单，我将在一台节点上开启6个Redis实例，并且这6个Redis各自有自己的端口。这样的话，相当于模拟出了6台机器了。然后在以这6个实例组建Redis集群就可以了。

第一步：为这6个实例创建好各自存放的目录



想一想，为什么要这样做呢？

第二步：既然是要启动6个Redis实例，自然需要准备各自的配置文件



拷贝redis.conf 6份



6个Redis实例的具体配置

具体来说，需要注意下：由于在一台机器（192.168.99.121）上，因此每个实例应该有不同的端口；同时，每个实例显然会有自己的存放数据的地方；开启AOF模式；开启集群配置；开启后台模式；

第三步：实际上，Redis集群的操作在后文你可以看到是通过Ruby脚本来完成的，因此我们需要安装Ruby相关的RPM包，以及Redis和Ruby的接口包。



yum install ruby



yum install rubygems



gem install redis

第四步：让Redis集群工作起来！



启动6个Redis实例

接下来，我们要通过Ruby脚本来创建集群了。



redis-trib.rb是操作Redis集群的脚本

[root@mydream121 bin]# ./redis-trib.rb create --replicas 1 192.168.99.121:8001 192.168.99.121:8002 192.168.99.121:8003 192.168.99.121:8004 192.168.99.121:8005 192.168.99.121:8006



create redis cluster



redis cluster info

首先，我们来看一下创建集群命令中 --replicas 1，这个代表什么意思呢？1其实代表的是一个比例，就是主节点数/从节点数的比例。那么想一想，在创建集群的时候，哪些节点是主节点呢？哪些节点是从节点呢？答案是将按照命令中IP:PORT的顺序，先是3个主节点，然后是3个从节点。这一点可以通过上面的2张图片印证。

其次，注意到图中slot的概念。slot对于Redis集群而言，就是一个存放数据的地方，就是一个槽。对于每一个Master而言，会存在一个slot的范围，而Slave则没有。在Redis集群中，依然是Master可以读、写，而Slave只读。数据的写入，实际上是分布的存储在slot中，这和以前1.X的主从模式是不一样的（主从模式下Master/Slave数据存储是完全一致的），因为Redis集群中3台Master的数据存储并不一样。这一点将在后续的实验中得到验证。

第五步：验证Redis集群搭建是否成功



cluster info/cluster nodes



搭建起来的Redis集群

到这里，Redis集群的搭建就完毕了，See U~

接上一篇《玩转Redis集群（上）》，我们来继续玩~

Redis集群操作实践

数据的分布性

数据分布性

从上面的操作，你可以看到，当存储某一个数据的时候，会分配一个slot，而这个slot从属于某一个Master，也就是说你需要明白，数据是分布的存储在Redis集群当中的。

在线水平扩容

Redis Cluster有一个非常重要的特点就是可以在线的添加节点，实现不影响业务的水平扩容。在这里，我将会在原来6个redis节点上，再添加2个redis节点。做法和以前一致，注意修改redis.conf，然后在启动8007、8008这2个redis实例。



修改redis.conf配置



启动新添加的2个redis实例



集群状态

其实，目前虽然启动了新加的2个redis实例，但是它们是不属于集群的。下面，我们来让它们加入集群中。



add-node命令

./redis-trib.rb add-node 192.168.99.121:8007 192.168.99.121:8006

./redis-trib.rb add-node 新节点 集群中已经存在的节点

在往集群中添加节点A的时候，需要提供一个在集群中已经存在的节点B的信息。因为知道了B的信息，就知道了整个集群的信息。为什么这么说呢，来，我们看一个文件，你就知道了。



nodes-xxx.conf

要知道集群中的每一个节点都有这么一个文件，存储着集群中每一个节点的信息:节点的角色、节点的ID、连接状态、slot范围、IP/PORT信息等。仔细观察图中，你可以发现，新加入的8007节点，实际上被默认为master节点，并且没有slot分配！这说明，新加入的节点现在还不可以存储数据，因此我们要为新节点分配slot槽。

[root@mydream121 bin]# ./redis-trib.rb reshard 192.168.99.121:8001

要知道slot都分配在master上，因此其实我们要做的就是从集群的masters上进行重新分配。上面的命令需要指定一个master节点进行reshard分片。



slot重新分配

图中要为新加入的节点8007分配500个slot,而且分配的方式是"all"，all是什么意思呢？all代表从已经存在的所有的master上均匀的分配一部分slot给8007。当然你可以通过"done"来指定某一个master进行分配。注意分配给8007是通过节点ID来指定的。



分配后的集群信息

按照上面的操作，我将8008节点也加入集群中，我的想法是让8008成为8007的从节点。既然是从节点，就不需要分配slot槽。注意到add-node方式加入的节点，默认就是master节点，因此这里我们得利用replicate指定主节点。

[root@mydream121 bin]# ./redis-trib.rb add-node 192.168.99.121:8008 192.168.99.121:8001



为从节点指定主节点

那么到现在，我们就在线完成了对Redis集群的水平扩容。那么如何删除节点呢？删除节点时，数据怎么办呢？对于从节点，删除就删除了，并不要紧，关键是主节点，因为主节点上有slot。因此，在删除主节点前，我们要对主节点的slot进行重新分配，完成数据的迁移。这里我就不再演示了，直接给出命令。

删除主节点：先reshard + 后del-node

删除从节点：直接del-node

Redis实现Session共享

Redis可以被用于Session共享，不过现在CAS实现单点登录更容易些。（CAS以后为大家介绍）



redis集群存储session信息

不论是Nginx挂了，还是其中的Tomcat挂掉，都不会丢失Session信息。在实现上，有现成的插件，比如：https://github.com/jcoleman/tomcat-redis-session-manager 

Java操作Redis

在单机Redis环境：Jedis

这个没什么好说的，就是给定IP/PORT实例化Jedis操作即可。

Jedis jedis = new Jedis("192.168.99.121", 8001);

在多台Redis环境：ShardedJedis+ShardedJedisPool



ShardedJedis方式

这是一种切片的方式来操作redis,通过hash而均匀的分配到pool里的redis机器中。

在Redis集群环境：JedisCluster



JedisCluster

与Spring整合

我们直接来看配置文件吧！



redis集群与Spring整合

同上文Java操作Redis集群的代码对比下，其实XML就是代码的映射。只不过通过spring的方式，帮助我们配置生成了一个bean:redisCluster。我们可以通过注入的方式得到redisCluster，然后我们想干啥就可以干啥，就这么简单~

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

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

本文将为大家介绍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

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集群再见！