使用 redis-cli 搭建 Redis 集群

参考： Redis 集群教程

redisconf 文件中包含很多信息，如：端口号、持久化方式、持久化的文件等等。

使用写入了不同端口号的配置文件就可以启动多个 Redis 实例。

下面是一个最少选项的集群的配置文件:

文件中的 cluster-enabled 选项用于开实例的集群模式， 而 cluster-conf-file 选项则设定了保存节点配置文件的路径， 默认值为 nodesconf 。节点配置文件无须人为修改， 它由 Redis 集群在启动时创建， 并在有需要时自动进行更新。

要让集群正常运作至少需要三个主节点，不过在刚开始试用集群功能时， 强烈建议使用六个节点： 其中三个为主节点， 而其余三个则是各个主节点的从节点。

首先， 让我们进入一个新目录， 并创建六个以端口号为名字的子目录， 稍后我们在将每个目录中运行一个 Redis 实例： 命令如下:

在文件夹 7000 至 7005 中， 各创建一个 redisconf 文件， 文件的内容可以使用上面的示例配置文件， 但记得将配置中的 port 和 cluster-conf-file 中的端口号数字 从 7000 改为与文件夹名字相同的号码。不同的集群节点要使用不同的 cluster-conf-file 。

配置文件的路径是可以自定义的。创建完毕后分别启动一个实例。

网上看到的教程，包括参考的官方文档里的文章，大多是使用以下方式创建集群。

这个命令在这里用于创建一个新的集群, 选项–replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。

之后跟着的其他参数则是这个集群实例的地址列表，3 个 master 3 个 slave redis-trib 会打印出一份预想中的配置给你看，如果你觉得没问题的话，就可以输入 yes，redis-trib 就会将这份配置应用到集群当中，让各个节点开始互相通讯，最后可以得到如下信息：

这表示集群中的 16384 个槽都有至少一个主节点在处理，集群运作正常。

但是在 Redis 的 github 仓库 中看到，该文件已经不建议使用。

我在 手把手教你实现 Docker 部署 Redis 集群 的评论中看到， 现在 redis-cli --cluster 命令已经可以创建集群，分配槽，分配主从服务器了 ，于是使用以下命令了解到相关的命令。

可以看到，命令的组成形式和旧方式是一致的。

可以看到执行命令后，redis 客户端做了以下工作：

输入 yes 后，redis 客户端做了以下工作：

集群搭建完毕。

因为 Redis Cluster 默认要求所有的槽位被覆盖，可以通过修改 cluster-require-full-coverage yes 配置来改变该行为。

CLUSTERDOWN The cluster is down in redis 这里的回答中提到：我们可以使用 N 个Master 和 N+1 个 Slave，正常情况下多余的一个实例作为随机一个 Master 的 Slave，一旦有实例宕机，可以迅速顶替，以保证每个主节点总是有至少一个从节点保持数据同步。

ps：搜索命令行的输出时，才看到 深入理解Redis系列之集群环境搭建 这篇文章，有时候搜索的关键词不合适容易走弯路啊……

查看集群健康状况：URL+ /GET _cat/health

Cluster

代表一个集群，集群中有多个节点，其中有一个为主节点，这个主节点是可以通过选举产生的，主从节点是对于集群内部来说的。es的一个概念就是去中心化，字面上理解就是无中心节点，这是对于集群外部来说的，因为从外部来看es集群，在逻辑上是个整体，你与任何一个节点的通信和与整个es集群通信是等价的。

Shards

代表索引分片，es可以把一个完整的索引分成多个分片，这样的好处是可以把一个大的索引拆分成多个，分布到不同的节点上。构成分布式搜索。分片的数量只能在索引创建前指定，并且索引创建后不能更改。

replicas

代表索引副本，es可以设置多个索引的副本，副本的作用一是提高系统的容错性，当某个节点某个分片损坏或丢失时可以从副本中恢复。二是提高es的查询效率，es会自动对搜索请求进行负载均衡。

Recovery

代表数据恢复或叫数据重新分布，es在有节点加入或退出时会根据机器的负载对索引分片进行重新分配，挂掉的节点重新启动时也会进行数据恢复。

（2）、ES为什么要实现集群

在单台ES服务器节点上，随着业务量的发展索引文件慢慢增多，会影响到效率和内存存储问题等。

我们可以采用ES集群，将单个索引的分片到多个不同分布式物理机器上存储，从而可以实现高可用、容错性等。

ES集群中索引可能由多个分片构成，并且每个分片可以拥有多个副本。通过将一个单独的索引分为多个分片，我们可以处理不能在一个单一的服务器上面运行的大型索引，简单的说就是索引的大小过大，导致效率问题。不能运行的原因可能是内存也可能是存储。由于每个分片可以有多个副本，通过将副本分配到多个服务器，可以提高查询的负载能力。

（3）、ES是如何解决高并发

ES是一个分布式全文检索框架，隐藏了复杂的处理机制，内部使用 分片机制、集群发现、分片负载均衡请求路由。

Shards 分片:代表索引分片，es可以把一个完整的索引分成多个分片，这样的好处是可以把一个大的索引拆分成多个，分布到不同的节点上。构成分布式搜索。分片的数量只能在索引创建前指定，并且索引创建后不能更改。

Replicas分片:代表索引副本，es可以设置多个索引的副本，副本的作用一是提高系统的容错性，当某个节点某个分片损坏或丢失时可以从副本中恢复。二是提高es的查询效率，es会自动对搜索请求进行负载均衡。

1、每个索引会被分成多个分片shards进行存储，默认创建索引是分配5个分片进行存储。每个分片都会分布式部署在多个不同的节点上进行部署，该分片成为primary shards。

注意：索引的主分片primary shards定义好后，后面不能做修改。

2、为了实现高可用数据的高可用，主分片可以有对应的备分片replics shards，replic shards分片承载了负责容错、以及请求的负载均衡。

注意: 每一个主分片为了实现高可用，都会有自己对应的备分片，主分片对应的备分片不能存放同一台服务器上。主分片primary shards可以和其他replics shards存放在同一个node节点上。

3、documnet routing（数据路由）

当客户端发起创建document的时候，es需要确定这个document放在该index哪个shard上。这个过程就是数据路由。

路由算法：shard = hash(routing) % number_of_primary_shards

如果number_of_primary_shards在查询的时候取余发生的变化，无法获取到该数据

注意：索引的主分片数量定义好后，不能被修改

高可用视图分析（下图所示：上面的图，如果节点1与节点2宕机了，es集群数据就不完整了。下面图，如果节点1与节点2宕机了，es集群数据还是完整的）

（1）、服务器环境

准备三台服务器集群

| 服务器名称 | IP地址 |

| node-1 | 192168212182 |

| node-2 | 192168212183 |

| node-3 | 192168212184 |

（2）、关闭防火墙

（3）、 http://192168212185:9200/_cat/nodespretty

号表示为master节点

注意：

注意克隆data文件会导致数据不同步

报该错误解决办法 ：

failed to send join request to master

因为克隆导致data文件也克隆呢，直接清除每台服务器data文件。

多个主从节点群组成的分布式服务器群，它具有复制、高可用和分片特性。Redis集群不需要sentinel哨兵也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式，这种集群模式没有中心节点，可水平扩展

redis集群需要至少要三个master节点，我们这里搭建三个master节点，并且给每个master再搭建一个slave节点，总共6个redis节点构成三主三从

redis 多节点启动 使用 /redis-server xxxxconf 指定不同的配置文件即可

确定下你的集群提供哪个协议服务，比如TCP服务。（当然也可以多协议混搭，我的就是HTTP提供主服务，TCP提供命令管理）。然后选择一个消息格式用于RPC通信(JSON,XML,ProtocolBuffer等)，这个很关键，(encode,decode)直接影响你集群的处理速度。当这些都确定后，你可以用mina写一个Slave,比如就是很简单的HelloWorld,消息格式为JSON。测试ok后将这个Slave复制多份，那么这就是一个Slave群了。

很多组织机构慢慢的在不同的服务器和地点部署SQL Server数据库——为各种应用和目的——开始考虑通过SQL Server集群的方式来合并。

将SQL Server实例和数据库合并到一个中心的地点可以减低成本，尤其是维护和软硬件许可证。此外，在合并之后，可以减低所需机器的数量，这些机器就可以用于备用。

当寻找一个备用，比如高可用性的环境，企业常常决定部署Microsoft的集群架构。我常常被问到小的集群(由较少的节点组成)SQL Server实例和作为中心解决方案的大的集群哪一种更好。在我们比较了这两个集群架构之后，我让你们自己做决定。

什么是Microsoft集群服务器

MSCS是一个Windows Server企业版中的内建功能。这个软件支持两个或者更多服务器节点连接起来形成一个“集群”，来获得更高的可用性和对数据和应用更简便的管理。MSCS可以自动的检查到服务器或者应用的失效，并从中恢复。你也可以使用它来(手动)移动服务器之间的负载来平衡利用率以及无需停机时间来调度计划中的维护任务。

这种集群设计使用软件“心跳”来检测应用或者服务器的失效。在服务器失效的事件中，它会自动将资源(比如磁盘和IP地址)的所有权从失效的服务器转移到活动的服务器。注意还有方法可以保持心跳连接的更高的可用性，比如站点全面失效的情况下。

MSCS不要求在客户计算机上安装任何特殊软件，因此用户在灾难恢复的经历依赖于客户-服务器应用中客户一方的本质。客户的重新连接常常是透明的，因为MSCS在相同的IP地址上重启应用、文件共享等等。进一步，为了灾难恢复，集群的节点可以处于分离的、遥远的地点。

在集群服务器上的SQL Server

SQL Server 2000可以配置为最多4个节点的集群，而SQL Server 2005可以配置为最多8个节点的集群。当一个SQL Server实例被配置为集群之后，它的磁盘资源、IP地址和服务就形成了集群组来实现灾难恢复。

SQL Server 2000允许在一个集群上安装16个实例。根据在线帮助，“SQL Server 2005在一个服务器或者处理器上可以支持最多50个SQL Server实例，”但是，“只能使用25个硬盘驱动器符，因此如果你需要更多的实例，那么需要预先规划。”

注意SQL Server实例的灾难恢复阶段是指SQL Server服务开始所需要的时间，这可能从几秒钟到几分钟。如果你需要更高的可用性，考虑使用其他的方法，比如log shipping和数据库镜像。

单个的大的SQL Server集群还是小的集群

下面是大的、由更多的节点组成的集群的优点：

◆更高的可用新(更多的节点来灾难恢复)。

◆更多的负载均衡选择(更多的节点)。

◆更低廉的维护成本。

◆增长的敏捷性。多达4个或者8个节点，依赖于SQL版本。

◆增强的管理性和简化环境(需要管理的少了)。

◆更少的停机时间(灾难恢复更多的选择)。

◆灾难恢复性能不受集群中的节点数目影响。

下面是单个大的集群的缺点：

◆集群节点数目有限(如果需要第9个节点怎么办)。

◆在集群中SQL实例数目有限。

◆没有对失效的防护——如果磁盘阵列失效了，就不会发生灾难恢复。

◆使用灾难恢复集群，无法在数据库级别或者数据库对象级别，比如表，创建灾难恢复集群。

虚拟化和集群

虚拟机也可以参与到集群中，虚拟和物理机器可以集群在一起，不会发生问题。SQL Server实例可以在虚拟机上，但是性能可能会受用影响，这依赖于实例所消耗的资源。在虚拟机上安装SQL Server实例之前，你需要进行压力测试来验证它是否可以承受必要的负载。

在这种灵活的架构中，如果虚拟机和物理机器集群在一起，你可以在虚拟机和物理机器之间对SQL Server进行负载均衡。比如，使用虚拟机上的SQL Server实例开发应用。然后在你需要对开发实例进行压力测试的时候，将它灾难恢复到集群中更强的物理机器上。

集群服务器可以用于SQL Server的高可用性、灾难恢复、可扩展性和负载均衡。单个更大的、由更多的节点组成的集群往往比小的、只有少数节点的集群更好。大个集群允许更灵活环境，为了负载均衡和维护，实例可以从一个节点移动到另外的节点。