在服务开发中，单机会有单点故障，如果服务部署在服务器上，一旦服务器宕机，服务将不可用。因此，为了使服务高可用，出现了分布式服务。同一个服务部署在多台机器上，即使多台服务器宕机一致性hash算法php开源，只要一台服务器可用，服务就可用。

同样如此。为了解决单机故障，引入了主从模式，但是主从模式存在一个问题：节点出现故障后，需要手动切换服务到节点才能服务恢复。为了解决这个问题，引入了哨兵模式。哨兵模式可以在节点故障后自动将节点升级为节点，无需人工干预即可恢复服务。

但是，主从模式和哨兵模式还没有达到真正的数据存储，每个实例都存储了全量的数据，因此诞生并实现了真正的数据分片存储。不过由于发布比较晚（2015年正式版发布），各大厂迫不及待，纷纷开发了自己的数据分片集群模型，如：等。

1.主从模式

虽然单个节点可以通过RDB和AOF的持久化机制将数据持久化到硬盘，但是数据是存储在服务器上的。如果服务器出现硬盘故障或其他问题，将导致数据不可用，读写无法分离，读写都在同一台服务器上。当请求量很大时，就会出现 I/O 瓶颈。

为了避免单点故障和读写不分离，提供()函数，实现数据库中数据更新后，更新后的数据会自动同步到其他数据库。

以上主从结构特点：一个可以有多个节点；节点可以有节点，从节点是级联结构。

主从模式的优缺点

优点：主从结构具有读写分离、提高效率、数据备份、提供多副本等优点。

不足：最大的缺点是主从模式没有自动容错和恢复功能。如果主节点出现故障，集群就无法工作，可用性比较低。从节点升级为主节点需要人工干预。

普通主从模式，当主库崩溃时，需要手动切换从库成为主库：

在从库中使用NO ONE命令将数据库提升到主库继续服务。

启动之前崩溃的主库，然后使用命令将其设置为新主库的从库进行数据同步。

2.哨兵模式

第一种主从同步/复制模式，当主服务器宕机时，需要手动将一台从服务器切换为主服务器，需要人工干预，费力费力，而且会导致服务在一段时间内无法使用。 ,这时候就需要哨兵模式了。

哨兵模式是从2.6版本开始提供的，但是当时这个版本的模式不稳定，直到2.8版本才稳定。

哨兵模式的核心还是主从复制，但是在主节点宕机无法写入的情况下，相比主从模式，多了一个选举机制：一个新的主节点从所有从节点中选出。选举机制的实现依赖于在系统中启动一个进程。

如上图所示，本身也存在单点故障的问题，所以在一个主多从的系统中，可以使用多个进行监控。监视器。每个哨兵都是一个独立的进程，作为一个进程，它会独立运行。

(1)哨兵模式的作用：

监控所有服务器是否正常运行：发送命令返回监控服务器运行状态，主从服务器进程监控，哨兵之间相互监控。

：当哨兵检测到宕机时，会自动切换到它，然后通过发布-订阅的方式通知其他从服务器，修改配置文件，让他们切换。同时，有问题的老主人也会成为新主人的奴隶，也就是说，当老主人恢复时，它不会恢复原来的主人身份，而是会充当新主人的奴隶。 .

(2)哨兵实现原理

哨兵启动进程时，会读取配置文件的内容，通过如下配置找到要监控的主库：

-name ip 端口

#-name 是主数据库的名称

#ip和port是当前主库地址和端口号

# 表示在执行故障转移操作之前需要多少个哨兵节点同意。

这里之所以只需要连接主节点，是通过主节点的info命令获取从节点信息，从而与从节点建立连接，同时，通过主节点的info信息可以知道新的从节点的信息。 .

一个哨兵节点可以监控多个主节点，但不建议这样做，因为当一个哨兵节点崩溃时，多个集群切换会同时失效。 启动后，与主数据库建立两个连接。

订阅主数据库：获取有关监视数据库的哨兵节点信息的通道

定期向数据库发送info命令，获取数据库本身的信息。

与主库建立连接后，会定期执行以下三个操作：

(1）每隔10s发送一次info命令，作用是获取当前数据库信息，比如发现新的节点时，会建立连接并加入监控列表.当主从数据库的角色发生变化时更新信息。

(2）每隔2s发送自己的信息到主从数据库的。作用是把自己的监控数据分享给。每个都会订阅: ，当其他哨兵收到消息后，会判断该哨兵是否为新哨兵，如果是，则将其加入哨兵列表并建立连接。

(3）每隔1s向所有主从节点和所有哨兵节点发送ping命令，监控节点是否存活。

(3)主观客观离线

当哨兵节点发送ping命令时，经过一定时间（down--），如果节点没有回复，哨兵认为主观下线。主观下线是指当前哨兵认为节点已经宕机。如果节点是主库， 会进一步判断故障转移就够了。此时会发送命令（is--down-by-addr）询问其他哨兵节点是否主观认为主节点下线，当达到指定数（）时哨兵会认为成为一个离线的目标。

主节点客观下线时，需要进行主从切换。主从切换步骤为：

哨兵选择一个从库后，发送no one命令升级主库，并发送命令将其他从节点的主库设置为新的主库。

(4)哨兵模式的优缺点

1.优势

2.不足问题

主从模式或哨兵模式存储在每个节点中的数据是全量数据。当数据量过大时，存储的数据需要分片存储在多个实例上。这就是技术发挥作用的地方。

3.各大厂群解决方案

3.0 版本之前只支持单实例模式。虽然正式版的开发者要到2015年才会发布，各大企业已经等不及了。在3.0版本发布之前，为了解决存储瓶颈，他们推出了自己的集群解决方案。这些方案的核心思想是将数据 () 存储在多个实例中，每个 就是一个实例。

(1)客户端片段

客户端分片是在客户端实现分片逻辑，（例如：支持的功能，也就是），通过客户端预定义的路由规则（使用一致性哈希），将key的访问转发到不同的实例，并在查询数据时汇总返回的结果。该方案的架构如图所示。

客户端分片的优缺点：

优点：客户端技术使用哈希共识算法分片的优点是所有逻辑可控，不依赖第三方分布式中间件。服务器的实例相互独立，互不相关。每个实例都像单台服务器一样运行，非常容易线性扩展，系统非常灵活。开发者知道如何实现分片和路由规则，不用担心踩坑。

1.一致性哈希算法：

是分布式系统中常用的算法。例如，在分布式存储系统中，要将数据存储在特定的节点上，如果使用常用的哈希方法将数据映射到特定的节点，比如mod(key,d)，key就是数据的key，d 是机器节点的数量。如果一台机器加入或离开集群网站开发，所有的数据映射都是无效的。

一致性哈希算法解决了普通余数哈希算法扩展性差的问题，可以保证在服务器在线或离线时尽可能多的请求命中原路由服务器。

2.实现方式：一致性哈希算法，如哈希算法、算法

例如在实现中，使用了一致性哈希算法（ ），同时对key和节点名进行映射匹配。使用的算法是。

使用一致性哈希而不是简单的类似哈希的模映射的主要原因是，当添加或减去节点时，不会有重新匹配。一致性哈希只影响相邻节点的密钥分布，影响量很小。

不足：

客户端分片最大的问题之一是当服务器实例组的拓扑发生变化时，每个客户端都需要更新和调整。如果可以将客户端分片模块单独取出，形成一个单独的模块（中间件），作为连接客户端和服务端的桥梁解决这个问题，那么代理分片就出现了。

(2)代理片段

最常用的代理分片是开源代理。基本原理是：客户端以中间件的形式，根据路由规则将请求发送到正确的实例，最后将结果返回给客户端。

通过引入代理层，统一管理多个实例，客户端只需要对其进行操作，无需关心后面有多少实例，从而实现集群。

优点：缺点：

作为使用最广泛、试用最稳定的代理，在业界被广泛使用。

(3)

实例无法平滑添加的问题带来了极大的不便，于是玩豆家自主研发了支持实例平滑添加的代理软件。它基于 Go 和 C 语言开发，于 2014 年 11 月开源。

在架构图中，介绍了，通过指定一个和一个或多个来实现集群的高可用。当一个挂掉时，不会自动将一个提升为，这涉及到数据一致性（数据同步本身采用主从异步复制，当数据成功写入时一致性hash算法php开源，是否已经读入此数据不保证），管理员需要在管理界面手动将提升为。

如果你觉得手动处理比较麻烦，玩豆家还提供了一个工具-ha，这个工具会在检测到宕机时将它下线并提升一个 。

是预分片的形式。启动时，会创建 1024 个插槽。一个插槽相当于一个盒子。每个盒子都有一个固定的编号，范围从 1 到 1024。插槽盒子用于存储密钥。至于密钥存放在哪个盒子里，可以通过算法“(key)24”得到一个数字。这个数字的范围必须在1到1024之间，钥匙放在这个数字对应的槽中。

例如，如果一个key通过算法“(key)24”得到数字5，则将其放入代码为5的槽（box）中。一个槽只能放在一个，一个槽不能放放置在多个s中。 1 最少可以存储1个slot，最多可以存储1024个slot。因此，最多可以指定 1024 个。

最大的优点是支持平滑增（减）（实例），可以安全透明地迁移数据，这也是不同于其他静态分布式方案的。添加后，涉及到的迁移。

比如系统有两个，slot对应关系如下。

添加一个后，将重新分配插槽。有两种分配槽的方法：

第一种：通过管理工具手动重新分配，为每一个指定对应的slot的范围。例如，您可以指定新的与slot之间的对应关系，如下所示。

第二：通过管理工具的功能，slot会根据各自的内存自动迁移，实现数据均衡。

4.

哨兵模式虽然可以实现高可用和读写分离，但有几个缺点：

3.0增加了集群模式，实现了分布式存储，即每个节点存储不同的数据。为了解决单台机器容量有限的问题小程序开发，该模式按照一定的规则将数据分配给多台机器。内存/QPS不限于单机，可以受益于分布式集群的高扩展性。

是一种服务器技术（分片和路由都是在服务器端实现的），采用多主多从，每个分区由一个主多从组成，区域相互平行。的。集群采用P2P模式，完全去中心化。

如上图，官方建议集群部署至少需要3个节点，最好使用6个节点的3主3从模式。该集群具有以下特点：

主要针对海量数据++高可用场景，海量数据，如果你的数据量很大，建议使用，当数据量不是很大的时候，就足够了。性能和高可用性优于哨兵模式。

采用虚拟哈希槽分区代替一致性哈希算法，预先分配一些卡槽，所有的key根据哈希函数映射到这些槽中，每个分区中的节点负责维护一部分槽和映射槽键值数据。

版权声明：本文为CSDN博主“有言先生”原创文章，遵循CC4.0 BY-SA版权协议。转载请附上原文出处链接和本声明。

公众号“Java ”发布的内容如注明出处，版权归原作者所有（无法核实或未注明出处的版权均来自互联网，转载为传达更多信息的目的，版权归原作者所有，如有侵权请联系本人，作者会第一时间删除！

最近很多人问有没有读者交流群！加入方式很简单，公众号Java选择，回复“加群”，即可入群！

（微信小程序）：3000+面试题，包括Java基础、并发、JVM、线程、MQ系列、、系列、、、K8s、、、架构设计等，随时在线！

------特别推荐-----