之乎者也·的博客

高并发的定义高并发是指系统或应用程序在同一时间段内接收到大量并发请求的能力。具体来说，高并发环境下系统需要能够同时处理大量的请求，而不会出现性能问题或响应延迟高并发的特点1.大量请求：高并发场景下，系统需要同时处理大量的请求，这些请求可能来自于不同的用户或客户端。2.同时访问：这些请求几乎同时到达系统，需要在短时间内进行处理和响应。3.资源竞争：由于大量请求同时到达，系统的资源（如CPU、内存、网络带宽等）可能会面临竞争和争夺。

Sentinel 使用 MetricBucket 统计一个窗口时间内的各项指标数据，这些指标数据包括请求总数、成功总数、异常总数、总耗时、最小耗时、最大耗时等，而一个 Bucket 可以是记录一秒内的数据，也可以是 10 毫秒内的数据，这个时间长度称为窗口时间。如果想要获取连续的一分钟的 Bucket 数据，就不能简单的从头开始遍历数组，而是指定一个开始时间和结束时间，从开始时间戳开始计算 Bucket 存放在数组中的下标，然后循环每次将开始时间戳加上 1 秒，直到开始时间等于结束时间。

所谓失败重试，就是 consumer 调用 provider 要是失败了，比如抛异常了，此时应该是可以重试的，或者调用超时了也可以重试。比如说服务 A 调用服务 B，结果服务 B 挂掉了，服务 A 重试几次调用服务 B，还是不行，那么直接降级，走一个备用的逻辑，给用户返回响应。某个服务的接口，要耗费 5s，你这边不能干等着，你这边配置了 timeout 之后，我等待 2s，还没返回，我直接就撤了，不能干等你。说实话，几乎到后面没人搞的清楚了，因为服务实在太多了，可能几百个甚至几千个服务。

服务降级是指在面对系统故障、资源限制或高并发等情况下，通过减少或关闭某些功能或服务的使用，以保证核心功能的可用性和稳定性。通过服务降级，可以避免整个系统的崩溃或性能下降，保证核心业务正常运作，提高用户体验。举个大家都知道的例子，天猫双11活动时，为了保证平台与商家的交易稳定，关闭了很多数据的导出功能，关闭了区域预售功能，关闭了客服留言功能，查询历史订单搜不到对应订单等等，这都是服务降级。服务等级定义 SLA（Service Level Agreement）是判定压测是否异常的重要依据。

在微服务架构中，Sentinel 作为一种流量控制、熔断降级和服务降级的解决方案，得到了广泛的应用。Sentinel是一个开源的流量控制和熔断降级库，用于保护分布式系统免受大量请求的影响。

上面何小锋的讲解，我理解是整合在动态代理上，如果真熔断了至少省去序列化到编码的那部分时间，但是按照大部分人的理解惯性以及一些框架的设计（我至少翻了两个），是在网络准备传输之前处加上的。熔断器不在静默期，并且慢调用的比例大于设置的阈值，则接下来的熔断周期内对资源的访问会自动地被熔断。熔断说的是服务之间的调用能实现自我恢复的状态，终有停止熔断的时刻，是非持续的；服务治理中的熔断机制，指的是在发起服务调用的时候，如果被调用方返回的错误率超过一定的闻值，那么后续的请求将不会真正发起请求，而是在调用方直接返回错误。

想要让系统长期“三高”，流量治理只是众多策略的其中一个，其他还有像存储高可用、缓存、负载均衡、故障转移、冗余设计、可回滚设计等等均是确保系统长期稳定运行的关键因素，笔者也期待在后续就这些策略再和大家进行分享。熔断机制，包括传统熔断器和 Google SRE 模型，作为防止系统过载的重要工具隔离策略，如动静隔离、读写隔离和机房隔离，通过物理或逻辑上分离资源和请求，减少单点故障的影响重试策略，包括同步和异步重试，以及各种退避机制，帮助在失败时优雅地恢复服务。降级。

随着互联网的普及，内容信息越来越复杂，用户数和访问量越来越大，我们的应用需要支撑更多的并发量，同时我们的应用服务器和数据库服务器所做的计算也越来越多。但是往往我们的应用服务器资源是有限的，且技术变革是缓慢的，数据库每秒能接受的请求次数也是有限的（或者文件的读写也是有限的），如何能够有效利用有限的资源来提供尽可能大的吞吐量?一个有效的办法就是引入缓存，打破标准流程，每个环节中请求可以从缓存中直接获取目标数据并返回，从而减少计算量，有效提升响应速度，让有限的资源服务更多的用户。

所谓降级，一般指整体的资源即将耗尽，为了保留关键的服务，舍弃非核心的服务。核心链路又称黄金链路。黄金链路是团队的生命线链路，由最核心的应用，最关键的DB，最需要死保的接口，支撑的最核心业务。不要让非核心的东西影响了核心的。这里的“东西”包括业务、系统、DB 等等。

一般的配置管理系统都是代码侵入性的，应用接入配置管理系统都需要使用对应的SDK来查询和监听数据的变更。对于一些已经成熟的系统来说，接入SDK来实现动态配置管理是很难实现的，Nacos通过引入配置管理工具confd可以实现系统的配置变更做到无代码侵入性。为什么要支持confd，老的应用配置管理模式是启动时读取配置文件，然后重新读取配置文件需要应用重启。

Eureka 使用 Peer to Peer 模式进行数据复制。Eureka 通过 http header就是 HEADER_REPLICATION 解决循环复制问题。Eureka 通过 lastDirtyTimestamp 解决复制冲突。Eureka 通过心跳机制实现数据修复。Distro 协议是 Nacos 针对临时实例数据开发的⼀致性协议。数据存储在缓存中，并在启动时进行全量数据同步，定期执行数据校验。遵循 Distro 协议的设计理念，每个 Distro 节点均能接收读写请求。

Sentinel是阿里开源的项目，提供了流量控制、熔断降级、系统负载保护等多个维度来保障服务之间的稳定性。官网：https://github.com/alibaba/Sentinel/wiki2012年，Sentinel诞生于阿里巴巴，其主要目标是流量控制。2013-2017年，Sentinel迅速发展，并成为阿里巴巴所有微服务的基本组成部分。它已在6000多个应用程序中使用，涵盖了几乎所有核心电子商务场景。2018年，Sentinel演变为一个开源项目。2020年，Sentinel Golang发布。

再讲Nacos之前，先来讲一下服务注册和发现。我们知道，现在微服务架构是目前开发的一个趋势。服务消费者要去调用多个服务提供者组成的集群。服务消费者需要在本地配置文件中维护服务提供者集群的每个节点的请求地址。服务提供者集群中如果某个节点宕机，服务消费者的本地配置中需要同步删除这个节点的请求地址，防止请求发送到已经宕机的节点上造成请求失败。服务地址的管理。服务注册。服务动态感知。而Nacos致力于解决微服务中的统一配置，服务注册和发现等问题。Nacos集成了注册中心和配置中心。

Nacos是一个开源的分布式系统配置和服务管理平台，具备服务发现、配置管理、动态更新配置的能力。其中，动态配置是Nacos的一个比较重要的特性，在实际应用中可以大大提高应用的配置管理效率和可变性。下面我们将深入探讨Nacos动态配置的具体实现。Nacos动态配置作为Nacos的重要特性之一，具有丰富的功能和优势。通过多种方式实现动态配置，可以大大提高应用的配置管理效率和可变性，是一个不可忽视的工具。

Nacos集群扩容缩容步骤由于业务量的增长或者系统性能的变化，Nacos集群的扩容和缩容是非常常见的操作。本文将详细介绍Nacos集群的扩容和缩容步骤，帮助读者在实际应用中进行操作。

将我们的服务告诉注册中心，注册中心登记每一个服务的详情信息，并在注册中心形成一张服务清单，服务中心会已心跳的方式去监测清单中的服务是否可用，如果不可用，会自动在服务清单中剔除不可用的服务，服务调用方（消费者）向服务中心咨询服务，并获取所有的实例清单，实现对具体服务实例的调用访问，不需要我们手动管理，实现各个微服务的。Nacos能让用户从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略。客户端通过请求方式向。

当我们在聊高可用时，我们在聊什么？系统可用性达到 99.99%在分布式系统中，部分节点宕机，依旧不影响系统整体运行服务端集群化部署多个节点Nacos 高可用，则是 Nacos 为了提升系统稳定性而采取的一系列手段。Nacos 的高可用不仅仅存在于服务端，同时也存在于客户端，以及一些与可用性相关的功能特性中，这些点组装起来，共同构成了 Nacos 的高可用。本文从多个角度出发，总结了一下 Nacos 是如何保障高可用的。

即标记为健康实例，最后会调用`PushService#serviceChanged()方法推送服务实例最新信息到客户端以便客户端能够及时感知服务实例发生的变化，并做出相应的调整，从而保证服务的高可用性和稳定性。属性，它用于判断是否启用轻量级心跳，轻量级心跳不会把客户端心跳信息发送给服务端，可以更快地检测到实例故障并进行处理，客户端第一次传false，之后从服务端返回true。心跳机制是一种用于监测和管理微服务可用性的机制，它用来维护注册中心和服务提供者之间的连接状态，并及时更新服务实例的状态信息。

服务优雅上下线：Ncos还提供服务实例的上下线操作，在服务详细页面，可以点击实例的“上线"或者“下线"按钮，被下线的实例，将不会包含在健。服务流量权重支持及流量保护：Ncos为用户提供了流量权重控制的能力，同时开发了服务流量的阈值保护，以帮助用户更好的保护服务不被意外打。集群：服务实例的集合，服务实例组成一个默认集群，集群可以被进一步按需求划分，划分的单位可以是虚拟集群，相同集群。实例：提供一个或多个服务的具有可访问网络地址(IP:pot)的进程，启动一个服务，就产生一个服务实例；k=V1这样的格式展示。

网关中有两个重要的概念，那就是路由配置和路由规则，路由配置是指配置某请求路径路由到指定的目的地址。而路由规则是指匹配到路由配置之后，再根据路由规则进行转发处理。Spring Cloud Gateway作为所有请求流量的入口，在实际生产环境中为了保证高可靠和高可用，尽量避免重启,需要实现Spring Cloud Gateway动态路由配置。

总结来说，Spring Cloud Nacos 通过与 Ribbon 的集成，利用 Nacos 注册中心的服务列表自动刷新特性，实现了动态的负载均衡。通过以上方式，Nacos实现了服务的负载均衡，提高了服务的可用性和性能。当一个服务需要调用其他服务时，它首先会通过 Nacos 服务器获取到注册的服务列表，然后 Ribbon 负载均衡器根据配置的负载均衡策略，选择一个可用实例进行调用。同样的使用的是Ribbon的规则，不过Nacos实现了自己的类。继承自AbstractLoadBalancerRule。

Nacos支持服务的故障检测和降级

Nacos的配置中心和注册中心的数据存储方式如下：配置中心的数据存储在外置数据源（关系型数据库）和内嵌存储数据源（Apache Derby）中。当配置文件数量较少时，可以使用内嵌的轻量级基于Derby的分布式关系型存储来解决。在集群模式下，如果需要高可用数据库集群作为支撑，成本会比较大。设计目标是期望Nacos存在两种数据存储模式，一种是现在的方式，数据存储在外置数据源（关系型数据库）；第二种方式是内嵌存储数据源（Apache Derby）。

Nacos保证数据的高可用性和一致性主要是通过以下方式：Nacos采用了基于Raft协议的一致性算法，保证了数据在集群中的高可用性。Raft协议通过选举Leader节点，并将数据复制到其他节点，确保在Leader节点故障时，其他节点可以继续提供服务。Nacos还支持多副本数据同步，将数据复制到多个节点上，以防止单点故障导致的数据丢失。Nacos通过分布式一致性协议（如Raft）保证了数据在集群中的强一致性。这意味着无论客户端访问集群中的哪个节点，都能够获取到最新的、一致的数据。

总之，Nacos通过访问控制和认证、加密通信、数据备份和恢复、安全审计和日志记录、漏洞管理和修复、网络隔离和安全组以及容器化和虚拟化安全等方法来保证服务的安全性。在实际应用中，用户应根据具体需求和安全策略选择适当的安全措施来增强系统的安全性。

总结来说，Nacos通过配置降级规则和集成熔断器组件来实现服务降级和熔断机制。这些机制可以在服务出现故障或性能问题时，自动调整请求路由和中断调用链路，以保证整体系统的可用性和稳定性。在实际应用中，用户应根据具体需求和服务特点来配置和管理降级规则和熔断器参数，以达到最佳的效果。

Nacos注册中心会维护一个与服务提供者之间的心跳连接，并根据心跳的接收情况来判断服务提供者的存活状态。如果注册中心在一段时间内没有收到来自服务提供者的心跳消息，它会认为该服务提供者已经不可达或出现故障，从而将其标记为不健康的实例或将其从服务列表中移除。总结来说，在Nacos中，服务提供者通过定期发送心跳消息来向Nacos注册中心续约，以保持其存活状态并被其他服务消费者发现和调用。当服务提供者启动时，它会向Nacos注册中心进行注册，将自己的服务信息（如服务名、IP地址、端口号等）上报给注册中心。

Nacos 这款开源产品很好地支持了地址服务器这种模式，所以无论是大、中、小型公司在自建 Nacos 时，都可以选择地址服务器模式去构建生产高可用的 Nacos 集群，地址服务器组件相对而言维护简单，Nginx，Java 构建的 Web 服务器均可以轻松实现一个地址服务器。本文介绍了 Nacos 的三种部署模式，并就高可用、可伸缩、易用性等方面对各个模式进行了介绍，并对自建 Nacos 场景的部署选型进行了分析，同时介绍了 MSE Nacos 企业版的部署架构，对云环境部署 Nacos 进行了补充。

不同于Paxos算法直接从分布式一致性问题出发推导出来，Raft算法则是从多副本状态机的角度提出，用于管理多副本状态机的日志复制。Raft实现了和Paxos相同的功能，它将一致性分解为多个子问题：Leader选举（Leader election）、日志同步（Log replication）、安全性（Safety）、日志压缩（Log compaction）、成员变更（Membership change）等。同时，Raft算法使用了更强的假设来减少了需要考虑的状态，使之变的易于理解和实现。Leader。

当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的 Server都恢复到一个正确的状态。3 .Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。2 .接收Leader消息并进行处理；

首先我们开门见山，什么是 Sentinel 流控？Sentinel 是面向分布式服务框架的轻量级流量控制框架，主要以流量为切入点，从流量控制，熔断降级，系统负载保护等多个维度来维护系统的稳定性。Sentinel 不仅仅可以做到流控，还可以做到其他熔断降级等方面。那什么叫滑动窗口呢？滑动窗口（Sliding window）是一种流量控制技术。早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。

服务熔断与服务降级比较熔断和降级都是系统自我保护的一种机制，但二者又有所不同，它们的区别主要体现在以下几点：概念不同触发条件不同归属关系不同

Zookeeper、Eureka、Nacos、Consul和ETCD有什么区别？

hystrix 就是一种高可用保障的一个框架，类似于 spring（ioc、mvc）、mybatis、activiti、lucene 框架， 预先封装好的为了解决某个特定领域的特定问题的一套代码库，用了框架来解决这个领域的特定的问题， 就可以大大减少我们的工作量，提升我们的工作质量和工作效率Netflix（网飞公司，美国流媒体巨头、世界最大的收费视频网站网飞），API 团队从 2011 年开始做一些提升系统可用性和稳定性的工作， Hystrix 就是从那时候开始发展出来的。

Sentinel是阿里开源的一款面向分布式、多语言异构化服务架构的流量治理组件。主要以流量为切入点，从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。上面两句话来自Sentinel官网的自我介绍，从这短短的两句话就可以看出Sentinel的定位和强大的功能。

Sentinel是阿里中间件团队开源的，面向分布式服务架构的轻量级高可用流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助用户保护服务的稳定性。大家可能会问：Sentinel 和之前常用的熔断降级库 Netflix Hystrix 有什么异同呢？本文将从多个角度对 Sentinel 和 Hystrix 进行对比，帮助大家进行技术选型。SentinelHystrix隔离策略信号量隔离线程池隔离/信号量隔离熔断降级策略基于慢调用比例或异常比例基于失败比率。

由于ZK只有Leader节点可以写入数据，如果是其他节点收到写入数据的请求，则会将之转发给Leader节点。A要进行事务回滚，相当于抛弃这条数据，并且回滚到最接近于PeerLastZxid的事务，对于A来说，也就是PeerLastZxid=3。ZooKeeper的数据结构，跟Unix文件系统非常类似，可以看做是一颗树，每个节点叫做Znode。leader刚生成一个proposal，还没有来得及发送出去，此时leader宕机，重新选举之后作为follower，但是新的leader没有这个proposal。

​​ 参考 ​​Paxos​​算法，专门设计了一种支持崩溃恢复的原子广播协议 ​​Zab​​（​​），​​Leader​​选举是其核心思想，也是保证​​数据一致性的关键所在。熟悉 ​​Leader​​​ 选举的底层理论，可以很好的应对集群的迁移和扩缩容。​​​ 在Leader选举期间和正常服务个数不过半数都无法对外提供服务，并且会丢弃一些未完成的事务，以保证数据一致，所以它是​​CP​​​，即保证数据一致性（​​​）和分区容错性（​​​），但不保证可用性（​​）。​​Leader​​​选举，先比较​。

序列号对于此节点的父节点来说是唯一的，这样便会记录每个子节点创建的先后顺序。可以创建子节点，子节点可以临时也可以持久；临时节点的生命周期与客户端会话绑定，一旦客户端会话失效（客户端与zookeeper 连接断开不一定会话失效），那么这个客户端创建的所有临时节点都会被移除。可以创建子节点，子节点可以临时也可以持久；基本特性同持久节点，只是增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。基本特性同临时节点，增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。