1.Redis 源码哨兵模式 - 源码梳理
2.Sentinel 是如何做限流的
3.如何评价阿里巴巴sentinel开源?
4.sentinel持久化到nacos详细配置
5.[redis 源码走读] sentinel 哨兵 - 脑裂处理方案

Redis 哨兵模式 - 源码梳理

       本文以Redis 7.0.版本为基准，如有不妥之处，解析敬请指正。源码

       哨兵模式的解析代码流程逻辑如下：哨兵节点每秒（主从切换时为1秒）向已知的主节点和从节点发送info命令。接收到主节点的源码info回复后，解析其中的解析tc传奇源码slave字段信息，进而创建相应的源码从节点instance。收到从节点的解析info回复后，解析其中的源码slave_master_host、slave_master_port、解析slave_master_link_status、源码slave_priority、解析slave_repl_offset、源码replica_announced等信息（步骤2和sentinelInfoReplyCallback）。解析

       在sentinel.masters的源码初始数据中，来自于sentinel.conf中的monitor，利用info命令探测主节点及其所属的从节点。通过订阅__sentinel__:hello频道，获取其他哨兵节点的信息。其中，link->act_ping_time表示最早一次未收到回复的ping请求发送时间，收到回复后其会被重置为0。因此，多空盘指标源码其不为0时，表示有未收到回复的ping请求。link->last_avail_time表示最近一次收到对ping有效回复的时间，link->last_pong_time表示最近一次收到对ping回复（有效和无效）的时间，link->pc_last_activity表示最近一次收到publish的消息，ri->role_reported_time表示最近一次收到info且回复中role相比于上次发生改变的时间。

       Raft一致性算法

       thesecretlivesofdata.com...

Sentinel 是如何做限流的

       限流作为保障服务高可用的重要手段，在微服务架构中尤为重要，通过限制接口或资源访问，有效提升服务可用性和稳定性。对比传统的限流工具如Guava的RateLimiter，阿里提供的Sentinel在功能上更为丰富、强大。

       Guava的RateLimiter基于令牌桶算法，操作简单，但功能相对单一。相比之下，Sentinel作为阿里巴巴推出的一种限流、熔断中间件，不仅支持复杂规则的配置，还能提供集群范围内的限流功能，并将服务调用情况可视化，论道趋势指标源码满足更广泛的使用场景。

       目前，Sentinel已在多个项目中得到应用，本文将深入剖析其限流机制，主要围绕限流的总体流程、源码解析、Context、Node、Entry等核心概念，以及责任链机制的实现过程，详细介绍Sentinel是如何通过责任链模式，结合滑动窗口算法，实现高效、灵活的限流功能。

       在Sentinel中，限流、熔断逻辑主要在SphU.entry方法中实现。该方法会在请求进入Sentinel时，对资源进行限流和熔断的逻辑处理。如果触发熔断或限流，会抛出BlockException，开发者可以自定义处理逻辑。溯源码燕窝系列对于业务异常，也有相应的fallback方法处理。

       限流流程如下：首先获取资源的Context，构建Node调用树，聚合相同资源不同Context的Node，然后进行资源调用统计和限流判断。限流机制基于滑动窗口算法，动态调整QPS限制，确保服务在高负载下依然稳定运行。

       在阅读源码过程中，我们首先关注了Context、Node、Entry等关键概念，理解它们在Sentinel中的角色和作用。Context封装了当前线程的调用链上下文信息，Node作为资源调用的统计包装，Entry则作为限流凭证，记录了资源的责任链和当前Context，实现资源调用链的构建和管理。

       责任链中的每个节点（如NodeSelectorSlot、ClusterBuilderSlot、StatisticSlot、黑客源码书FlowSlot等）都有特定的功能，如获取资源对应的Node、聚合相同资源不同Context的Node、资源调用统计、限流判断等。这些节点通过责任链模式紧密协作，共同完成限流逻辑的执行。

       在责任链的执行过程中，NodeSelectorSlot负责获取资源对应的Node，ClusterBuilderSlot聚合相同资源不同Context的Node，StatisticSlot负责资源调用的统计信息更新，而FlowSlot则根据Node的统计信息进行限流判断。这个过程不仅高效地实现了限流功能，还保证了系统的稳定性和性能。

       在责任链执行完毕后，无论请求是否成功或被限流，都会执行Entry.exit()方法，进行最终的收尾工作。至此，Sentinel的限流机制实现了从请求处理到资源调用统计，再到限流判断和执行，最后的收尾操作的完整流程。

       总体来看，Sentinel通过其丰富的功能、灵活的配置和高效的实现机制，在微服务架构中为限流提供了强有力的支持，不仅保障了服务的高可用性，还提升了系统的整体性能和稳定性。

如何评价阿里巴巴sentinel开源?

       如何评价阿里巴巴sentinel开源？

       sentinel是一个针对微服务架构的流量控制和监控平台，它通过一系列的规则来实现流量的限流、降级、系统保护等功能。sentinel的核心在于其规则的执行机制和功能插槽的实现。

       规则执行机制基于责任链模式，当执行代码时，会根据资源调用ProcessorSlotChain中的规则，这个过程通过SphU.entry("HelloWorld")实现。ProcessorSlotChain包含多种功能插槽，如NodeSelectorSlot、ClusterBuilderSlot、StatisticSlot、FlowSlot、DegradeSlot和SystemSlot等。

       NodeSelectorSlot收集资源路径，ClusterBuilderSlot构建资源统计信息，StatisticSlot用于实时统计调用数据，FlowSlot根据规则进行限流，DegradeSlot根据响应时间和异常率决定熔断，而SystemSlot则动态调整入口流量与系统容量。这些功能插槽构成了sentinel的执行链条。

       在实现上，sentinel使用了高性能的滑动窗口数据结构LeapArray来统计指标数据，并通过SPI接口扩展Slot Chain，允许用户自定义功能。

       在配置方面，通过SentinelWebAutoConfiguration实现自动配置，生成SentinelWebInterceptor拦截器，对Web请求进行处理。@SentinelResource注解用于标记方法，生成代理类，从而开启sentinel的限流等功能。

       资源对应的ProcessorSlotChain通过CtSph中的参数初始化，这个参数在Env的静态代码块中获取dashboard规则。

       sentinel与服务端dashboard交互通过客户端与服务端的通信实现，源码阅读可以深入了解其内部实现。

       总之，sentinel以其灵活的规则系统、高性能的数据处理能力以及丰富的功能插槽，成为了一款强大的流量控制和监控工具。其自动配置和自定义扩展特性，使得它在微服务架构中具有广泛的应用前景。

sentinel持久化到nacos详细配置

       1. 首先，搭建Nacos环境，包括单例和集群模式，详细步骤参考先前文档。

       2. 从github.com/alibaba/Sentinel下载Sentinel源码。

       3. 使用编辑器打开sentinel-dashboard。

       4. 修改pom.xml文件，因为我们使用的是Nacos。

       5. 将项目test中的nacos文件复制到正式项目中。

       6. 在nacos文件中创建NacosConfigProperties.java文件，并输入相应代码。

       7. 将Nacos配置参数注入到容器中，并修改NacosConfig文件。

       8. 修改规则控制器类。

       9. 修改前端代码，具体为sidebar.html文件。

       . 修改js文件中的identity.js，将'FlowServiceV1'替换为'FlowServiceV2'。

       . 在代码中搜索'/dashboard/flow/'，定位到第行。

       将let url = '/dashboard/flow/' + $scope.app; 替换为：let url = '/dashboard/v2/flow/' + $scope.app;

       . 修改项目的配置文件application.properties。

       直接使用Maven打包项目，运行即可。

       . 进行熔断改造，包括以下步骤：

       在nacos文件中添加熔断改造类，用于获取规则和推送规则到Nacos。

       增加NacosConfigUtil的配置参数，该参数是Nacos配置文件名称的后缀。

       增加NacosConfig中degrade的转换，并注入到容器中（如果没有该配置，则之前的拉取和推送Nacos类会报错）。

       修改degrade的API调用类，具体代码如下。

       具体类代码内容。

[redis 源码走读] sentinel 哨兵 - 脑裂处理方案

       哨兵模式的 Redis 集群在部署时可能出现脑裂现象，即产生多个主服务导致数据不一致的情况。哨兵通过检查、发现故障并进行故障转移来维护集群的高可用性。合理部署配置哨兵和主服务可以有效降低脑裂现象。配置哨兵节点个数和选举法定人数，确保多个哨兵能进行相互选举，选出领导者哨兵进行故障转移，法定人数一般建议为哨兵总数的一半以上，以实现少数服从多数的决策。对于主服务，通过修改配置，当主服务与一定数量的副本失去联系时，禁止客户端向故障主服务进行写操作，从而避免数据不一致的情况。解决此问题时，需注意配置选项min-slaves-to-write，其依赖于副本的链接个数，合理设置以确保集群的故障转移能力。高版本的 Redis 已对相关选项进行了优化。总之，通过合理部署哨兵和主服务配置，可以有效管理 Redis 集群，减少脑裂现象带来的问题。