1. 阿里sentinel源碼研究深入

1.1. 前言

之前使用了一次sentinel，已經可以初步使用它的限流和降級功能，對於其中的原理比較好奇，因此想花時間研究並記錄下來，備忘

1.2. 源碼

1.2.1. 流控降級監控等的構建

首先客戶端而言，我關注的是我寫的代碼SphU.entry，這明顯是很關鍵的方法，下圖的內容就是這裏構建的
-Sentinel工作主流程就包含在上面一個方法裏，通過鏈式調用的方式，經過了建立樹狀結構，保存統計簇點，異常日誌記錄，實時數據統計，負載保護，權限認證，流量控制，熔斷降級等Slot

進入鏈式方法的入口爲CtSph類，try方法大括號內

Entry e = new CtEntry(resourceWrapper, chain, context);
        try {
            chain.entry(context, resourceWrapper, null, count, prioritized, args);
        } catch (BlockException e1) {
            e.exit(count, args);
            throw e1;
        } catch (Throwable e1) {
            // This should not happen, unless there are errors existing in Sentinel internal.
            RecordLog.info("Sentinel unexpected exception", e1);
        }

1.2.2. 修改控制檯規則是如何通知客戶端的？

看sentinel-transport-simple-http包中的HttpEventTask類，它開啓了一個線程，轉麼用來做爲socket連接，控制檯通過socket請求通知客戶端，從而更新客戶端規則，更改規則核心代碼如下

// Find the matching command handler.
            CommandHandler<?> commandHandler = SimpleHttpCommandCenter.getHandler(commandName);
            if (commandHandler != null) {
                CommandResponse<?> response = commandHandler.handle(request);
                handleResponse(response, printWriter, outputStream);
            } else {
                // No matching command handler.
                badRequest(printWriter, "Unknown command `" + commandName + '`');
            }

通過命令模式，commandName爲setRules時，更新規則

1.2.3. 既然它建立連接用的socket，爲什麼不用netty呢？

帶着這個疑問，我本想在issues裏找下，突然發現它的源碼中有個sentinel-transport-netty-http這個包和sentinel-transport-simple-http處於同級，官方的例子用的simple-http，但明顯它也準備了netty-http，於是我替換成了netty-http，運行後效果和原先一樣，至於效率上有沒有提升，我就不清楚了^_^

1.2.4. 流量規則如何檢查？

該規則檢查類爲FlowRuleChecker，在core核心包中，核心檢查方法如下

    private static boolean passLocalCheck(FlowRule rule, Context context, DefaultNode node, int acquireCount,
                                          boolean prioritized) {
        Node selectedNode = selectNodeByRequesterAndStrategy(rule, context, node);
        if (selectedNode == null) {
            return true;
        }
        return rule.getRater().canPass(selectedNode, acquireCount, prioritized);
    }
1.2.5. 熔斷降級如何判斷？

判斷類爲DegradeRuleManager，在core核心包，核心內容如下，再深入就是它判斷的算法了，感興趣的自己去看如下的passCheck

public static void checkDegrade(ResourceWrapper resource, Context context, DefaultNode node, int count)
        throws BlockException {

        Set<DegradeRule> rules = degradeRules.get(resource.getName());
        if (rules == null) {
            return;
        }

        for (DegradeRule rule : rules) {
            if (!rule.passCheck(context, node, count)) {
                throw new DegradeException(rule.getLimitApp(), rule);
            }
        }
    }

1.2.6. 默認的鏈條構建在哪？

核心類爲DefaultSlotChainBuilder，構建瞭如下的slot

public class DefaultSlotChainBuilder implements SlotChainBuilder {

    @Override
    public ProcessorSlotChain build() {
        ProcessorSlotChain chain = new DefaultProcessorSlotChain();
        chain.addLast(new NodeSelectorSlot());
        chain.addLast(new ClusterBuilderSlot());
        chain.addLast(new LogSlot());
        chain.addLast(new StatisticSlot());
        chain.addLast(new SystemSlot());
        chain.addLast(new AuthoritySlot());
        chain.addLast(new FlowSlot());
        chain.addLast(new DegradeSlot());
        return chain;
    }
}

1.2.7. 既然已經知道了它是如何構建鏈式的處理節點的，我們是否何可自己重新構建？

發現類SlotChainProvider中的構建方法如下

private static void resolveSlotChainBuilder() {
        List<SlotChainBuilder> list = new ArrayList<SlotChainBuilder>();
        boolean hasOther = false;
        for (SlotChainBuilder builder : LOADER) {
            if (builder.getClass() != DefaultSlotChainBuilder.class) {
                hasOther = true;
                list.add(builder);
            }
        }
        if (hasOther) {
            builder = list.get(0);
        } else {
            // No custom builder, using default.
            builder = new DefaultSlotChainBuilder();
        }

        RecordLog.info("[SlotChainProvider] Global slot chain builder resolved: "
            + builder.getClass().getCanonicalName());
    }

也就是說，我們如果在LOADER中加入了其他的非默認實現就可以替代原來的DefaultSlotChainBuilder，那LOADER怎麼來的？看代碼，如下的全局變量，也就是需要自定義實現SlotChainBuilder接口的實現類

private static final ServiceLoader<SlotChainBuilder> LOADER = ServiceLoader.load(SlotChainBuilder.class);

1.2.8. 如何實現SlotChainBuilder接口呢？

這裏要注意的是它使用了ServiceLoader，也就是SPI，全稱Service Provider Interface，加載它需要特定的配合，比如我自定義實現一個Slot


public class MySlotChainBuilder implements SlotChainBuilder {
    @Override
    public ProcessorSlotChain build() {
        ProcessorSlotChain chain = new DefaultProcessorSlotChain();
        chain.addLast(new NodeSelectorSlot());
        chain.addLast(new ClusterBuilderSlot());
        chain.addLast(new LogSlot());
        chain.addLast(new StatisticSlot());
        chain.addLast(new SystemSlot());
        chain.addLast(new AuthoritySlot());
        chain.addLast(new FlowSlot());
        chain.addLast(new DegradeSlot());
        //自定義的
        chain.addLast(new CarerSlot());
        chain;
    }
}

@Slf4j
public class CarerSlot extends AbstractLinkedProcessorSlot<DefaultNode> {
    @Override
    public void entry(Context context, ResourceWrapper resourceWrapper, DefaultNode node, int count,
                      boolean prioritized, Object... args) throws Throwable {
        log.info(JSON.toJSONString(resourceWrapper));
        fireEntry(context, resourceWrapper, node, count, prioritized, args);
    }

    @Override
    public void exit(Context context, ResourceWrapper resourceWrapper, int count, Object... args) {
        fireExit(context, resourceWrapper, count, args);
    }
}

這裏我自定義了CarerSlot，那是否能被加載到呢？事實上還不夠，需要在META-INF/services/com.alibaba.csp.sentinel.slotchain.SlotChainBuilder建這樣一個文件，內容如下

好了，這樣配置過後，它就能讀到我們自定義的實現類代替它原先的類了

1.2.9. 該命令模式最初的初始化階段在哪？

用過sentinel的都會感受到，只有當有第一個sentinel監控的請求過來時，sentinel客戶端纔會正式初始化，這樣看來，這個初始化步驟應該在哪呢？
我通過不斷反向跟蹤上述的命令模式最初的初始化，找到了最初初始化的地方如下

@Bean
    public SentinelResourceAspect sentinelResourceAspect() {
        pushlish();
        return new SentinelResourceAspect();
    }

有沒有覺得很熟悉？doInit就是很多初始化的起點，當Env被調用時會運行static代碼塊，那麼只有可能是sph被調用時

只要你debug過我上述第一條SphU.entry的源碼，就會發現，如下，該方法一進入不就是先獲取Env的sph，再調用的entry嗎，所以初始化的地方也就找到了，第一次調用SphU.entry的地方，或者你不用這個，使用的註解，裏面同樣有這個方法

public static Entry entry(String name) throws BlockException {
        return Env.sph.entry(name, EntryType.OUT, 1, OBJECTS0);
    }

1.2.10. 註解是如何實現熔斷降級的？

這個其實是比較容易理解的，既然通過SphU.entry包裹可以實現熔斷降級，通過註解的形式包裹代碼方法應該是比較容易的，那麼在哪裏實現和配置的呢
看過我前一篇文章的應該看到了，有存在如下配置

    @Bean
    public SentinelResourceAspect sentinelResourceAspect() {
        pushlish();
        return new SentinelResourceAspect();
    }

很明顯的註解切面，通過spring註解的形式注入，我覺得這還是比較優雅的注入方式了，點進入就可以看到如下

    @Pointcut("@annotation(com.alibaba.csp.sentinel.annotation.SentinelResource)")
    public void sentinelResourceAnnotationPointcut() {
    }

對@SentinelResource註解進行了處理

1.2.11. 什麼是直接失敗？

這個很好理解，qps超過設置的值，直接失敗

1.2.12. 什麼是排隊等待？

這個似乎看字面意思很好理解，但是一旦你點了這個選項，下面還有個參數的
所以這個排隊等待是有超時時間的，達到峯值後勻速通過，採用的漏桶算法，流控圖

1.2.13. 什麼是慢啓動模式？

以下是核心算法，Warm Up模式不看算法細節，看它的中文說明應該就能理解是怎麼回事了吧；所謂慢啓動模式，要求系統的QPS請求增速不能超過一定的速率，否則會被壓制超過部分請求失敗，應該是爲了避免一啓動就有大流量的請求進入導致系統一下子就宕機卡主或直接進入了熔斷

@Override
    public boolean canPass(Node node, int acquireCount, boolean prioritized) {
        long passQps = (long) node.passQps();

        long previousQps = (long) node.previousPassQps();
        syncToken(previousQps);

        // 開始計算它的斜率
        // 如果進入了警戒線，開始調整他的qps
        long restToken = storedTokens.get();
        if (restToken >= warningToken) {
            long aboveToken = restToken - warningToken;
            // 消耗的速度要比warning快，但是要比慢
            // current interval = restToken*slope+1/count
            double warningQps = Math.nextUp(1.0 / (aboveToken * slope + 1.0 / count));
            if (passQps + acquireCount <= warningQps) {
                return true;
            }
        } else {
            if (passQps + acquireCount <= count) {
                return true;
            }
        }

        return false;
    }

配置如下時，測試流控
流控圖

1.2.14. 模式總結

你會發現直接失敗和排隊等待的區別在流控圖上並不明顯，那差別在哪呢？我重慶給個請求參數，5秒內模擬100個人輪流請求10次
sentinel控制檯設置
流控圖

總結：我設置了超時時間是5秒，而100個線程10次輪詢也就是1000個請求，可以看出，它並不是一定要在5秒內解決這些請求，有了延時後，代表只要響應時間在5秒以內，不管多少請求都不會拒絕;
幾個模式有利有弊，默認的快速失敗使我們可以最大程度的控制系統的QPS，避免造成系統壓力過大，但同時可能造成用於的體驗效果變差
慢啓動上面說過了
排隊等待在設置合理的超時時間後可以最大程度的避免求情的失敗，但同時可能造成線程壓力過大
綜上，在我看來排隊等待模式是比較適合線上運行的，只是需要設置合理的超時時間，大公司機器不愁那就設小點，業界一般標準是200ms用戶無感知，中小型可以設500ms甚至更大，看機器情況動態調整了

sentinel初次剖析

1. 阿里sentinel源碼研究深入

1.1. 前言

1.2. 源碼

1.2.1. 流控降級監控等的構建

1.2.2. 修改控制檯規則是如何通知客戶端的？

1.2.3. 既然它建立連接用的socket，爲什麼不用netty呢？

1.2.4. 流量規則如何檢查？

1.2.5. 熔斷降級如何判斷？

1.2.6. 默認的鏈條構建在哪？

1.2.7. 既然已經知道了它是如何構建鏈式的處理節點的，我們是否何可自己重新構建？

1.2.8. 如何實現SlotChainBuilder接口呢？

1.2.9. 該命令模式最初的初始化階段在哪？

1.2.10. 註解是如何實現熔斷降級的？

1.2.11. 什麼是直接失敗？

1.2.12. 什麼是排隊等待？

1.2.13. 什麼是慢啓動模式？

1.2.14. 模式總結

redis分佈式鎖實現秒殺活動

sentinel實現秒殺活動

數據庫鎖實現秒殺活動

Dubbo 服務暴露

sentinel初次剖析

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結