此为博主(yjclsx)原创文章，如若转载请标明出处，谢谢！
一、NOSQL
NoSQL(Not Only SQL)，泛指非关系型的数据库。
NoSQL数据库的四大分类：
1、键值(Key-Value)存储数据库：这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。但是如果DBA只对部分值进行查询或更新的时候，Key/value就显得效率低下了。举例如：Redis, Voldemort, Oracle BDB.
2、列存储数据库：这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。如：HBase, Riak.
3、文档型数据库：文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可以看作是键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。如：CouchDB, MongoDb. 国内也有文档型数据库SequoiaDB，已经开源。
4、图形(Graph)数据库：图形结构的数据库同其他行列以及刚性结构的SQL数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。NoSQL数据库没有标准的查询语言(SQL)，因此进行数据库查询需要制定数据模型。许多NoSQL数据库都有REST式的数据接口或者查询API。如：Neo4J, InfoGrid, Infinite Graph.
因此，我们总结NoSQL数据库在以下的这几种情况下比较适用或者说是非关系型数据库的特点：1、数据模型比较简单；2、需要灵活性更强的IT系统；3、对数据库性能要求较高；4、不需要高度的数据一致性，不像关系型数据库拥有ACID四大特性，非关系数据库只有部分特性；5、对于给定key，比较容易映射复杂值的环境。主要1、3、4这三个点需要记住。
|
分类
|
Examples举例
|
典型应用场景
|
数据模型
|
优点
|
缺点
|
|
键值（key-value）
|
Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB
|
内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等等。
|
Key 指向 Value 的键值对，通常用hash table来实现
|
查找速度快
|
数据无结构化，通常只被当作字符串或者二进制数据
|
|
列存储数据库
|
Cassandra, HBase, Riak
|
分布式的文件系统
|
以列簇式存储，将同一列数据存在一起
|
查找速度快，可扩展性强，更容易进行分布式扩展
|
功能相对局限
|
|
文档型数据库
|
CouchDB, MongoDb
|
Web应用（与Key-Value类似，Value是结构化的，不同的是数据库能够了解Value的内容）
|
Key-Value对应的键值对，Value为结构化数据
|
数据结构要求不严格，表结构可变，不需要像关系型数据库一样需要预先定义表结构
|
查询性能不高，而且缺乏统一的查询语法。
|
|
图形(Graph)数据库
|
Neo4J, InfoGrid, Infinite Graph
|
社交网络，推荐系统等。专注于构建关系图谱
|
图结构
|
利用图结构相关算法。比如最短路径寻址，N度关系查找等
|
很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群方案。
|
二、redis简介
redis是一个高性能的key-value数据库。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘（RDB持久化方式）或者把增删改这些DML操作写入追加的记录文件中（AOF持久化方式），并且在此基础上实现了master-slave(主从)同步。
Redis非常轻量级，一个空Redis实例占用的内存很少，所以不用担心多个Redis实例会额外占用很多内存。
RDB持久化方式的可靠性不高，比如每5秒写入一次硬盘，要是在第3秒的时候挂了，就丢失了这3秒的数据，所以RDB方式不适合实时性要求高的场景，一般实际工作中是使用AOF方式的。
优点：对数据高并发读写；对海量数据的高效率存储和访问；对数据的可扩展性和高可用性。
缺点：redis(ACID处理非常简单)无法做到太复杂的关系数据库模型。
redis还有个很好的地方，那就是如果你想在一台机子上启动多个redis非常的简单方便，不需要安装多次redis或者把redis的安装目录copy多份，只要把redis.conf配置文件copy多份并修改好端口等相关配置就可以了。因为启动的时候都是通过安装的那个redis的redis-server配合redis.conf配置文件来启动的，即执行命令"/XX/
redis-server /XX/redis.conf"来启动redis。所以，无论启动几个redis，只要在一台机子上，那使用的都是同一个redis-server，只是配置文件不同而已。
三、redis五种基本数据类型
可以通过type name来获取key为name的数据的类型
1、String类型
对字符串类型的操作有：set、get、setnx、setex、setrange、mset、mget、msetnx、getset、incr、decr、incrby、decrby、append、strlen等。
比如 set yjc lsx，再执行get yjc 返回的就是"lsx"，set命令执行多次会覆盖掉原值。
2、Hash类型
Hash类型在实际工作中是使用最多最常见的数据类型，Hash类型可以看做是String类型的field和value的映射表，或者说一个String类型的集合。它很适合存储对象，相比较而言，将一个对象存储在Hash类型里比存储在String类型里占用更少的内存空间，并方便存取整个对象。比如hset hashName fieldName value，表示存储一个hash类型的数据，hashName是hash集合名称，fieldName是字段名，value是该字段的值。可见，一个hash是个集合，可以存储多个key-value。
比如一张User表有id、name、age等字段，在java中也有对应的封装对象，将这种数据缓存到redis中就很适合使用Hash类型来存取。可以将"Table_User_"+id作为hash集合名称，里面的字段名就是对象的属性名，字段值就是属性值，这样一个Hash代表了一条User表的数据；也可以将"Table_User"作为hash集合名称，每条数据的id作为字段名，字段值是整条数据的json格式字符串，这样一个Hash代表了整个User表的数据。前一种适合表字段多然而只经常取其中个别字段的场景，后一种适合经常取表中大部分字段的场景，这两种设计在日常工作中最为常用，当然还有其他的设计方式。
对Hash类型的操作有：hset、hget、hmset、hmget、hsetnx、hsetex、hincrby、hdecrby、hexists、hlen、hdel、hkeys、hvals、hgetall等。
3、List类型
Redis中的List类型类似于Java中的双端队列Deque，它是一个链表结构的集合，其主要功能有push、pop、获取元素等。更详细的说，List类型是一个双端链表的结构，我们可以通过相关操作进行集合的头部或者尾部添加删除元素，List类型设计非常简单精巧，它既可以作为栈，又可以作为队列，能满足很多需求。List类型集合里面的元素允许重复。
lpush方法：从头部加入元素，先进后出，类似于栈。rpush方法：从尾部加入元素，先进先出，类似于队列。lrange myList 0 -1表示从头到尾遍历myList，-1表示直到取不到为止。
其他操作还有：linsert、lset、lrem、ltrim、lpop、rpop、rpoplpush、lindex、llen等。
有些公司甚至拿Redis作为一个小型的MQ，就是使用的List这种数据类型。
4、set类型
set集合是string类型的无序集合，类似于对java中的List的升级版，set是通过hashtable实现的，对集合我们可以取交集、并集、差集，并且set类型是不允许重复的。
对set类型的操作有：smembers、sadd、srem、spop、sdiff、sdiffstore、sinter、sinterstore、sunion、sunionstore、smove、scard、sismember、srandmember等。
5、zset类型
zset是set的升级版本，他在set的基础上增加了顺序属性，这一属性在添加修改时可以被指定，每次指定后，zset会自动重新按新的值调整顺序。可以理解为有两列，一列存value、一列存顺序。同样，zset的value也是不允许重复的，当执行zadd zset1 0 yjc后再执行zadd zset1 1 yjc，最终顺序为1的yjc会覆盖掉顺序为0的yjc。
zet可以用在打分排行(rank)等场景上。
对zset类型的操作有：zadd、zrange、zrem、zincrby、zrangebyscore、zremrangebyrank、zremrangebyscore、zrank、zrevrank、zcard、zcount等。
四、redis高级命令
上面介绍了redis中的5种基本类型以及对这些类型的常用操作，接下来再说redis中其他的常用命令。
keys * 返回当前数据库中的所有键，可以模糊匹配，比如keys yjc* 返回所有开头是yjc的键，但不支持%等复杂的查询规则，只能是简单的模糊匹配。
exists 用于判断是否存在指定的key。
expire 设置某个key的过期时间，使用ttl可以查看剩余时间，persist可以取消过期时间。
select 选择数据库，redis默认有16个数据库，分别是0到15，这些数据库只是逻辑上的划分，默认进入的是数据库0。比如"keys *"返回了数据库0中的所有键，然后执行"select 1"，再执行"keys *"返回的就是数据库1中的所有键。大部分命令都只是在操作当前数据库，也有命令对该redis服务中的所有数据库有效，比如flushall命令会清空所有数据库的数据。至于为什么redis要有16个数据库，是因为早期的redis没有集群的概念，所以通过这16个数据库进行分片（分片就是将数据拆分存放到多个地方的过程）。比如按范围分片，数据库0专门放id为0到10000的数据，数据库1专门放id为10001到20000的数据...；也可以按类型分片，比如基础数据存数据库0，日志数据存数据库1...。但2015年的redis3.0版本发布之后，redis有了集群的功能，就不需要这种数据库分片的形式了，取而代之的是集群分片，也就是把数据拆分到多个redis实例中，每个redis实例只存放部分数据，同时redis早版本就已支持主从，每个redis主服务器都有自己的从服务器，以备份数据提高可靠性，又因为redis里的从服务器是只读的，所以同时又可以读写分离，即主服务器可写，从服务器只读。redis集群分片后的数据是存放在slot（槽）中的，在后续的redis集群章节中会讲到。
move [key] [数据库下标] 将当期数据库中的指定key转移到其他数据库中。
randomkey 随机返回数据库里的一个key。
rename 重命名key。
echo 打印命令，就是打印输出到终端。
dbsize 查看当前数据库的key数量。
info 查询redis详细信息，包括redis的版本信息、redis已运行了多长时间、连接的客户端数量、从节点服务器数量、redis存储的数据大小和内存CPU使用情况、各个数据库key的数量等等。
config get * 返回redis的所有配置，就是redis.conf配置文件的一个缩影。
flushdb 清空当前数据库。
flushall 清空所有数据库。
五、redis安全性
因为redis速度非常快，所以在一台比较好的服务器下，一个外部用户在一秒内可以进行15W次的密码尝试，这意味着你需要设定非常强大的密码来防止暴力破解。
在redis.conf文件中可进行密码的设置，找到如下位置进行修改保存即可：
#requirepass foobared
requirepass 你的密码
保存后重启redis，进入redis客户端程序，输入"keys *"查询所有键时会返回无权限的提示，输入"auth 你设置的密码"，然后你就可以继续进行其他操作了。也可以在进入客户端的时候直接登录授权，如输入"/usr/local/redis/bin/redis-cli -a 你的密码"，这样进入客户端程序后不用再输入密码可以直接进行操作了。
六、主从复制
在第四节的redis高级命令里我们就讲到了主从，主从就是指一个主服务器（master）下会挂着多个从服务器（slave），主服务器和从服务器的数据是同步的，其中只有主服务器是可以进行写操作的，从服务器只能进行读操作。主从功能在redis 2.X中就已存在。
主从复制：1、master可以拥有多个slave；2、多个slave除了可以连接同一个master外，还可以连接到其他的slave；3、主从复制不会造成阻塞，master在同步数据时，master和slave可以继续处理请求；4、提供系统的伸缩性。
主从复制过程：1、slave与master建立连接，发送sync同步命令；2、master会开启一个后台进程，将数据库快照保存到文件中，同时master主进程会开始收集新的写命令并缓存；3、后台完成保存后，就将文件发送给slave；4、slave将此文件保存到硬盘上。
主从复制配置：修改slave服务器的redis.conf文件，找到"# slaveof <masterip> <masterport>"这一行，在下面加上"slaveof 主服务器ip 主服务器端口"，即可和主服务器建立主从关系。如果主服务器设置了密码，那在"# masterauth <master-password>"下面加上"masterauth 主服务器密码"就可以了，配置非常的简单。
配置完后启动主服务器和从服务器，进入客户端程序输入"info"，可以查看到主从情况：
下图是主服务器看到的信息（我在这台主服务器下挂了两个从服务器），里面显示了它连接的两台从服务器
下图是从服务器看到的信息，里面显示了它连接的主服务器
当你在主服务器进行写操作之后，在从服务器也可以查询到刚写的数据。但是在从服务器不能进行写操作，比如写入一个Sting类型的数据，会提示readonly，如下图所示：
七、哨兵（sentinel）
知道了主从复制之后，还有一个问题，那就是主服务器一旦挂了，从服务器就算没挂也一起跟着没用了。针对这个问题，我们可以对主服务器进行监控，如果发现主服务器挂了，就从它的几个从服务器中选出一个当做主服务器，这样就提高了redis的高可用性。这件事情可以使用其他软件技术来实现，比如提供高可用性最常见的就是使用keepalived，但是redis2.6之后就已经给我们提供了这么一种机制，称为哨兵。在2.6版本中，哨兵是1.0版本，还存在各种各样的问题，并不稳定，在2.8版本之后哨兵功能才稳定起来。
顾名思义，哨兵的含义就是监控redis系统的运行状况，其主要功能有两点：
1、监控主服务器和从服务器是否正常运行；
2、主服务器出现故障时，可以自动将从服务器转换为主服务器，实现自动切换。
实现步骤：
1、复制redis安装目录中的sentinel.conf文件到/usr/local/redis/etc/下；
2、修改sentinel.conf文件，如下：
# 主服务器名称（随便写，比如mymaster ）、主服务器ip、主服务器端口，投票选举次数（表示有几个哨兵认为主服务器挂了才真正认为是挂了，因为我没有进行哨兵集群，就只有一个哨兵，所以设置了1）
sentinel monitor mymaster 192.168.246.130 6379 1
# sentinel会向master发送心跳PING来确认master是否存活，默认每1S发送一次，如果master在“一定时间范围”内不回应PONG或者是回复了一个错误消息，那么这个sentinel会主观地认为这个master已经不可用了，当然最终是否认为主服务器不可用，还要看其他哨兵的投票结果，这里设置这个时间范围为5秒
sentinel down-after-milliseconds mymaster 5000
# 在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步，因为尽管复制过程（replication）的绝大部分步骤都不会阻塞从服务器， 但从服务器在载入新的主服务器发来的RDB文件时，仍然会造成从服务器在一段时间内不能处理命令请求，所以这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着有越多的slave因为replication而不可用，可以通过将这个值设为1来保证每次只有一个slave处于不能处理命令请求的状态。
sentinel parallel-syncs mymaster 2
# 当决定要进行主从切换（failover）时，在一定时间内主从切换操作依然没有完成，则认为切换失败，该时间范围默认为3分钟
sentinel failover-timeout mymaster 180000
3、配置好之后就可以启动哨兵了，执行命令：
/usr/local/redis/bin/redis-server /usr/local/redis/etc/sentinel.conf --sentinel &
4、查看哨兵相关信息，可以不在当前哨兵所在的服务器上进行查看，即远程连接某台机子上的哨兵服务，-h表示哨兵服务的host，-p表示哨兵服务的port：
/usr/local/redis/bin/redis-cli -h 192.168.246.131 -p 26379 info Sentinel
5、你可以尝试关闭一下主服务器，看看哨兵是否帮你切换了一个新的主服务器。
当原来的主服务器修复好重新启动之后，就可以重新加入，但会变更为从服务器，因为已经有了一个新的主服务器了。
哨兵切换主从的过程会修改这些redis服务器的redis.conf配置文件，所以即便你重启这些redis服务，主从关系不会恢复到初始的样子，依然是主从切换后的样子。
由上可见，和redis的数据服务一样，redis的哨兵也是一个服务，默认占用26379端口（当然可以在sentinel.conf里修改），它和数据服务是独立开来的，所以哨兵可以独立部署在另外的机子上来监控其他机子的redis主从运行状况，当然部署在和redis数据服务同一台机子上也可以，只要端口不冲突。
八、redis事务
到目前为止的redis中，它对事务的支持非常简单，或者说非常不完善，在实际工作中几乎派不上用场，使用方法如下：
1、首先使用multi命令打开事务。
2、根据业务进行各种读写操作。
3、最后使用exec命令执行和提交上述操作，或者使用discard命令撤销上述所有操作。
需要注意的是，执行exec提交事务时，当上述操作中有报错，那报错的操作自然不生效，但是不报错的操作依然会生效，也就是redis的事务不能保证同时成功或同时失败，例如：
如上图所示，incr name是对key为name的String数据进行递增操作，但name的值时yjclsx，不可能递增，所以最后exec提交时这个操作报错了，但结果是另外两个正常的操作依然生效了，没有像关系型数据库那样，一个事务内所有操作要么都成功，要么都失败。所以redis的事务相比较于关系型数据库来说太简单了。也许在日后的版本中，redis事务会有所优化吧。
九、redis持久化机制
redis是一个支持持久化的内存数据库，也就是说redis需要经常将内存中的数据同步到硬盘来保证数据的可靠性。
redis的持久化方式在redis简介中也有简单描述，redis的持久化方式有两种：
1、snapshotting（快照）方式，这是默认方式，将内存以快照的方式写入二进制文件中，默认为dump.rdb，可以通过配置设置自动做快照持久化的触发条件，也就是我们可以配置redis在n秒内如果超过m个key被修改就自动做快照。
snapshotting的默认设置如下：
save 900 1 #900秒内如果超过1个key被修改，则发起快照保存
save 300 10 #300秒内如果超过10个key被修改，则发起快照保存
save 60 10000 #60秒内如果超过10000个key被修改，则发起快照保存
可见，默认设置的意图就是在短时间之内想让redis发起快照保存就得有很多写操作，但是如果长时间都没有写操作，那要求就降低了，900秒内只要有1次写操作redis就会发起快照保存。
这种持久化方式缺点很明显，就是数据的可靠性不高，万一哪次down机了，那还没保存的数据就没了。
2、append-only file（aof）方式，这种方式比快照方式有更好的持久化性，是由于在使用aof时，redis会将每一个收到的写命令都通过write函数追加到文件中，当redis重新启动时就会重新执行文件中保存的写命令来在内存中重建这个数据库的内容，这个文件默认名为appendonly.aof。aof虽然默认不是立即写到硬盘上，不过可以通过修改配置文件强制写到硬盘中。
aof设置：
appendonly yes //启动aof持久化方式，默认是no，不开启的。
#针对aof有三种写入硬盘的方式：
#appendfsync always //收到写命令就立即写入到磁盘，效率最慢，但能保证完全的持久化，是实际工作中最常用的方式。
#appendfsync everysec //每秒钟写入磁盘一次，在性能和持久化方面做了折中，是默认的方式。
#appendfsync no //完全依然os，性能最好，但持久化没保证，实际工作中肯定不会用。
在redis3.0之后有了集群，性能就问题不大了，所以实际工作中都是选择appendfsync always方式的。
十、发布和订阅消息
redis提供了简单的发布订阅功能。使用subscribe [频道] 进行订阅监听。使用publish [频道] [发布内容] 进行发布消息广播。例如：
1、订阅cctv频道。
2、另一个客户端向cctv频道发送信息，返回1表示有一个订阅者收到了消息。
3、订阅者收到了消息
十一、redis集群
redis3.0之后提供了集群(cluster)功能，但要求至少三个主节点，也就是三个主服务器。
redis cluster在设计的时候，就考虑到了去中心化，去中间件，也就是说，集群中的每个节点(node)都是平等的关系，都是对等的，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。
redis集群没有并使用传统的一致性哈希来分配数据，而是采用另外一种叫做哈希槽 (hash slot)的方式来分配的。redis cluster默认分配了16384个slot(槽)，当我们set一个key 时，会用CRC16算法来取模得到所属的slot，然后将这个key分到哈希槽区间的节点上，具体算法就是：CRC16(key) % 16384。简单点理解就比如，一共有10个槽，如果有0~11这12条数据该怎么放呢：1%10=1，那就分配在1号槽上，10%10=0，那就分配在0号槽上。所以，一个槽上可能被分配多条数据。
redis集群要保证16384个槽对应的节点都正常工作，如果某个节点发生故障，那它所负责的所有槽也就失效了，整个集群将不能工作。所以为了增加集群的可靠性，官方推荐的方案是将节点配置成主从结构，即一个master主节点，挂n个slave从节点。这样如果主节点失效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务。这点非常类似之前提到的哨兵，只是Redis Cluster本身提供了故障转移容错的能力。
redis集群步骤（以3主节点、3从节点、全都部署在一台centos系统的机子上为例）：
1、因为都在一个机子上，所以在/usr/local/下创建一个文件夹redis-cluster，并在下面创建6个文件夹7001~7006，以分别表示6个节点，同时名字就是每个节点的端口号，这样比较好记。
2、把redis.conf配置文件分别copy到这6个文件夹下，并分别进行如下修改：
（1）daemonlze yes #后台运行
（2）port 700X #分别对应每个节点的端口。
（3）bind 192.168.246.130 #必须要绑定当前机器的ip，因为我都是一个机子，所以6个节点都这么配。
（4）dir /usr/local/redis-cluster/700X/ #指定数据文件的存放目录，每个节点的目录不能相同，不然会丢失数据。
（5）cluster-enabled yes #启动集群模式
（6）cluster-config-file nodes700X.conf #集群的配置，配置文件首次启动自动生成
（7）cluster-node-timeout 5000 #节点超时时间
（8）appendonly yes #开启aof持久化方式
3、由于redis集群需要使用ruby命令，所以需要先按照ruby
（1）yum install ruby
（2）yum install rubygems
（3）gem install redis （按照redis和ruby的接口）
4、启动6个redis实例并检查是否启动成功
（1）/usr/local/redis/bin/redis-server /usr/local/redis-cluster/700X/redis.conf
（2）ps -ef | grep redis #查看是否启动成功
5、进入到redis的安装目录，执行redis-trib.rb命令，其中--replicas后面的1表示主节点数量/从节点数量为1，即3个主节点和3个从节点，7001、7002、7003是主节点，7004、7005、7006依次分别是这三个的从节点：
./redis-trib.rb create --replicas 1 192.168.246.130:7001 192.168.246.130:7002 192.168.246.130:7003 192.168.246.130:7004 192.168.246.130:7005 192.168.246.130:7006
如果出现上图所示结果表示集群启动成功！
在看看每个节点文件夹下有哪些文件，以7001为例：
appendonly.aof和dump.rdb分别是aof和快照两种持久化方式的数据文件，nodes-7001.conf是集群自动生成的配置文件，redis.conf是redis的配置文件。
6、至此集群已经搭建完成！接下来进行验证：
（1）连接任意一个客户端：./redis-cli -c -h -p（-c表示集群模式，-h表示ip地址，-p表示端口号），如：
/usr/local/redis/bin/redis-cli -c -h 192.168.246.130 -p 7001
（2）进行验证：cluster info（查看集群信息）、cluster nodes（查看节点列表）
（3）进行数据操作验证
如上，放入一个String类型的数据key为name，value为1，结果被分配到了7002节点上，分配到的槽下标是5798，同时它把原来连接的7001的客户端换成了7002的客户端。
如果我们断开这个客户端连接，还是去连接7001，再查询数据会如何呢：
查询之前放入的name数据，显示要去7002的5798槽获取，并返回了结果"1"，同时又把客户端换成了7002的客户端。
由上可见，集群之后，各个节点是相通的。
7、如果你想关闭集群则需要对节点逐个进行关闭，使用命令：
/usr/local/redis/bin/redis-cli -c -h 192.168.246.130 -p 700X shutdown
如果你想再打开集群就对节点逐个启动就行了：/usr/local/redis/bin/redis-server /usr/local/redis-cluster/700X/redis.conf，已经不需要再执行redis-trib.rb命令，因为每个节点下面已经有了nodes-700X.conf配置文件了，里面记录了集群的配置。
如果你想重新进行集群部署，删除之前的集群配置，那就删除各个节点下面的nodes-700X.conf配置文件即可。
十二、集群操作
上一节已经成功搭建了集群，如果现在原本的集群不够用了，要在集群中水平扩展，也就是新加几个主从节点，那该怎么做呢？笨一点的方法就是把之前的集群配置全删了，然后加几个节点，再重新配置集群。但是这样不仅很麻烦，而且会导致服务暂不可用。
redis提供了集群操作命令，集群服务不需要关闭也可以直接对节点进行增删改，方便进行扩展。
集群操作的详细步骤见我的博文“redis集群操作”。
此为博主(yjclsx)原创文章，如若转载请标明出处，谢谢！
再分享一下我老师大神的人工智能教程吧。零基础！通俗易懂！风趣幽默！希望你也加入到我们人工智能的队伍中来！http://www.captainbed.net