標籤: 台北網頁設計公司

  • dubbo源碼解析之負載均衡

    dubbo源碼解析之負載均衡

    在分佈式系統中,負載均衡是必不可少的一個模塊,dubbo 中提供了五種負載均衡的實現,在閱讀這塊源碼之前,建議先學習負載均衡的基礎知識。把看源碼當做一個印證自己心中所想的過程,這樣會得到事半功倍的效果

    以下源碼分析基於 dubbo 2.77 版本

    類結構

    先來看一下這一塊的類結構圖

    大部分算法都是在權重比的基礎上進行負載均衡,RandomLoadBalance 是默認的算法

    類型 描述 是否默認 是否加權
    RandomLoadBalance 隨機 是 是,默認權重相同
    RoundRobinLoadBalance 輪訓 否 是,默認權重相同
    LeastActiveLoadBalance 最少活躍數調用 否 不完全是,默認權重相同,僅在活躍數相同時按照權重比隨機
    ConsistentHashLoadBalance 一致性hash 否 否
    ShortestResponseLoadBalance 最短時間調用 否 不完全是,默認權重相同,僅在預估調用相同時按照權重比隨機

    AbstractLoadBalance

    AbstractLoadBalance 對一些通用的操作做了處理,是一個典型的模板方法模式的實現

    select 方法只做一些簡單的範圍校驗,具體的實現有子類通過 doSelect 方法去實現

        @Override
        public <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) {
            if (CollectionUtils.isEmpty(invokers)) {
                return null;
            }
            if (invokers.size() == 1) {
                return invokers.get(0);
            }
            return doSelect(invokers, url, invocation);
        }
    

    getWeight方法封裝了獲取一個調用者的權重值的方法,並加入了預熱處理

        int getWeight(Invoker<?> invoker, Invocation invocation) {
            int weight;
            URL url = invoker.getUrl();
            // Multiple registry scenario, load balance among multiple registries.
            // 註冊中心不需要預熱
            if (REGISTRY_SERVICE_REFERENCE_PATH.equals(url.getServiceInterface())) {
                weight = url.getParameter(REGISTRY_KEY + "." + WEIGHT_KEY, DEFAULT_WEIGHT);
            } else {
                // 獲取配置的權重值
                weight = url.getMethodParameter(invocation.getMethodName(), WEIGHT_KEY, DEFAULT_WEIGHT);
                if (weight > 0) {
                    // 獲取服務提供者啟動時的時間戳
                    long timestamp = invoker.getUrl().getParameter(TIMESTAMP_KEY, 0L);
                    if (timestamp > 0L) {
                        //  獲取啟動時長
                        long uptime = System.currentTimeMillis() - timestamp;
                        // 當前時間小於服務提供者啟動時間,直接給一個最小權重1
                        if (uptime < 0) {
                            return 1;
                        }
                        // 獲取預熱時間
                        int warmup = invoker.getUrl().getParameter(WARMUP_KEY, DEFAULT_WARMUP);
                        // 如果小於預熱時間,計算權重
                        if (uptime > 0 && uptime < warmup) {
                            weight = calculateWarmupWeight((int)uptime, warmup, weight);
                        }
                    }
                }
            }
            // 取與零比較的最大值,保證不會出現負值權重
            return Math.max(weight, 0);
        }
    

    calculateWarmupWeight 方法用來計算權重,保證隨着預熱時間的增加,權重逐漸達到設置的權重

        static int calculateWarmupWeight(int uptime, int warmup, int weight) {
            // 運行時間/(預熱時間/權重)
            int ww = (int) ( uptime / ((float) warmup / weight));
            // 保證計算的權重最小值是1,並且不能超過設置的權重
            return ww < 1 ? 1 : (Math.min(ww, weight));
        }
    

    RandomLoadBalance

    隨機調用是負載均衡算法中最常用的算法之一,也是 dubbo 的默認負載均衡算法,實現起來也較為簡單
    隨機調用的缺點是在調用量比較少的情況下,有可能出現不均勻的情況

    	@Override
        protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
            // Number of invokers
            int length = invokers.size();
            // Every invoker has the same weight?
            boolean sameWeight = true;
            // the weight of every invokers
            int[] weights = new int[length];
            // the first invoker's weight
            int firstWeight = getWeight(invokers.get(0), invocation);
            weights[0] = firstWeight;
            // The sum of weights
            int totalWeight = firstWeight;
            for (int i = 1; i < length; i++) {
                int weight = getWeight(invokers.get(i), invocation);
                // save for later use
                // 依次把權重放到數組對應的位置
                weights[i] = weight;
                // Sum
                // 累加權重
                totalWeight += weight;
                // 如果出現權重不一樣的,sameWeight 設為false
                if (sameWeight && weight != firstWeight) {
                    sameWeight = false;
                }
            }
            if (totalWeight > 0 && !sameWeight) {
                // If (not every invoker has the same weight & at least one invoker's weight>0), select randomly based on totalWeight.
                // 在總權重裏面隨機選擇一個偏移量
                int offset = ThreadLocalRandom.current().nextInt(totalWeight);
                // Return a invoker based on the random value.
                for (int i = 0; i < length; i++) {
                    offset -= weights[i];
                    // 依次用偏移量減去當前權重,小於0說明選中
                    if (offset < 0) {
                        return invokers.get(i);
                    }
                }
            }
            // If all invokers have the same weight value or totalWeight=0, return evenly.
            // 如果所有的調用者有同樣的權重或者總權重為0,則隨機選擇一個
            return invokers.get(ThreadLocalRandom.current().nextInt(length));
        }
    

    RoundRobinLoadBalance

    輪訓算法避免了隨機算法在小數據量產生的不均勻問題,我個人認為,輪訓算法可以理解為隨機算法的一種特例,在大量請求的情況下,從調用次數看,和隨機並無區別,主要區別在於短時間內的調用分配上

    加權輪訓算法給人的直觀感受,實現起來並不複雜,算出一權重總量,依次調用即可
    例如A,B,C 三個節點的權重比依次 1,200,1000,如果依次輪訓調用,就會出現先調用A 10 次,再調用B 200次,最後調用 C 1000次,不斷重複前面的過程
    但這樣有一個問題,我們可以發現C 被練習調用1000次,會對C瞬間造成很大的壓力

    dubbo的新版本採用的是平滑加權輪詢算法,輪訓的過程中節點之間穿插調用,可以避免了上面說的問題,因此這塊源碼看起來會稍有難度

    輪訓算法 在dubbo 在升級的過程中,做過多次優化,有興趣的可以去了解下該算法的優化過程,也是件很有意思的事情

    public class RoundRobinLoadBalance extends AbstractLoadBalance {
        public static final String NAME = "roundrobin";
    
        private static final int RECYCLE_PERIOD = 60000;
    
        protected static class WeightedRoundRobin {
            // 權重值
            private int weight;
            // 當前權重值
            private AtomicLong current = new AtomicLong(0);
            // 最後一次使用該對象時間
            private long lastUpdate;
    
            public int getWeight() {
                return weight;
            }
    
            public void setWeight(int weight) {
                this.weight = weight;
                current.set(0);
            }
    
            // 獲取自增權重基數的當前權重值
            public long increaseCurrent() {
                return current.addAndGet(weight);
            }
    
            public void sel(int total) {
                current.addAndGet(-1 * total);
            }
    
            public long getLastUpdate() {
                return lastUpdate;
            }
    
            // 設置最後一次更新時間戳
            public void setLastUpdate(long lastUpdate) {
                this.lastUpdate = lastUpdate;
            }
        }
    
        private ConcurrentMap<String, ConcurrentMap<String, WeightedRoundRobin>> methodWeightMap = new ConcurrentHashMap<String, ConcurrentMap<String, WeightedRoundRobin>>();
    
        /**
         * get invoker addr list cached for specified invocation
         * <p>
         * <b>for unit test only</b>
         *
         * @param invokers
         * @param invocation
         * @return
         */
        protected <T> Collection<String> getInvokerAddrList(List<Invoker<T>> invokers, Invocation invocation) {
            String key = invokers.get(0).getUrl().getServiceKey() + "." + invocation.getMethodName();
            Map<String, WeightedRoundRobin> map = methodWeightMap.get(key);
            if (map != null) {
                return map.keySet();
            }
            return null;
        }
    
        @Override
        protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
            // {group}/{interfaceName}:{version} + methoName 獲取當前消費者的唯一標示
            String key = invokers.get(0).getUrl().getServiceKey() + "." + invocation.getMethodName();
            // 獲取對應的 WeightedRoundRobin map,如果不存在,new 一個map放進去
            ConcurrentMap<String, WeightedRoundRobin> map = methodWeightMap.computeIfAbsent(key, k -> new ConcurrentHashMap<>());
            int totalWeight = 0;
            long maxCurrent = Long.MIN_VALUE;
            long now = System.currentTimeMillis();
            Invoker<T> selectedInvoker = null;
            WeightedRoundRobin selectedWRR = null;
            for (Invoker<T> invoker : invokers) {
                // 服務提供者在的唯一標識
                String identifyString = invoker.getUrl().toIdentityString();
                int weight = getWeight(invoker, invocation);
                WeightedRoundRobin weightedRoundRobin = map.computeIfAbsent(identifyString, k -> {
                    WeightedRoundRobin wrr = new WeightedRoundRobin();
                    wrr.setWeight(weight);
                    return wrr;
                });
                // 如果權重改變了,更新 weightedRoundRobin 裏面權重的值
                if (weight != weightedRoundRobin.getWeight()) {
                    //weight changed
                    weightedRoundRobin.setWeight(weight);
                }
                // 當前權重自增自身權重
                long cur = weightedRoundRobin.increaseCurrent();
                // 設置最後一次更新時間戳
                weightedRoundRobin.setLastUpdate(now);
                // 如果當前權重大於最大當前權重
                if (cur > maxCurrent) {
                    // 重置最大當前權重的值
                    maxCurrent = cur;
                    // 把當前提供者設為選中的提供者
                    selectedInvoker = invoker;
                    // 把當前輪訓權重實例設為選中
                    selectedWRR = weightedRoundRobin;
                }
                // 累計總權重
                totalWeight += weight;
            }
            // 提供者有變化
            if (invokers.size() != map.size()) {
                // 超過60s沒有使用,刪除掉
                map.entrySet().removeIf(item -> now - item.getValue().getLastUpdate() > RECYCLE_PERIOD);
            }
            if (selectedInvoker != null) {
                // 減去總權重
                // 關於這個地方為什麼要減去總權重,是一個很容易造成迷惑的地方
                // 我的理解:每一次調用循環 每個提供者的 當前權重 都會自增自己的權重
                // 因此在選中后(只有一個被選中),再減去總權重,正好保證了所有 WeightedRoundRobin 中當前權重之和永遠等於0
                selectedWRR.sel(totalWeight);
                return selectedInvoker;
            }
            // 理論上不會走到這個地方
            // should not happen here
            return invokers.get(0);
        }
    
    }
    

    LeastActiveLoadBalance

    最少活躍數調用算法是指在調用時判斷此時每個服務提供者此時正在處理的請求個數,選取最小的調用

    dubbo 在實現該算法時的具體邏輯如下

    1. 選取所有活躍數最少的提供者
    2. 如果只有一個,直接返回
    3. 如果權重不同,加權隨機選擇一個
    4. 如果權重相同,隨機選擇一個
        @Override
        protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
            // Number of invokers
            int length = invokers.size();
            // The least active value of all invokers
            // 最少活躍數量
            int leastActive = -1;
            // The number of invokers having the same least active value (leastActive)
            // 有同樣活躍值的提供者數量
            int leastCount = 0;
            // The index of invokers having the same least active value (leastActive)
            int[] leastIndexes = new int[length];
            // the weight of every invokers
            // 每一個提供者的權重
            int[] weights = new int[length];
            // The sum of the warmup weights of all the least active invokers
            // 最少活躍提供者的總權重
            int totalWeight = 0;
            // The weight of the first least active invoker
            int firstWeight = 0;
            // Every least active invoker has the same weight value?
            // 所有的最少活躍提供者是否擁有同樣的權重值
            boolean sameWeight = true;
    
    
            // Filter out all the least active invokers
            for (int i = 0; i < length; i++) {
                Invoker<T> invoker = invokers.get(i);
                // Get the active number of the invoker
                // 活躍數量
                int active = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName()).getActive();
                // Get the weight of the invoker's configuration. The default value is 100.
                // 獲取權重值
                int afterWarmup = getWeight(invoker, invocation);
                // save for later use
                // 保存權重留着後面用
                weights[i] = afterWarmup;
                // If it is the first invoker or the active number of the invoker is less than the current least active number
                // 如果是第一個提供者,或者當前活躍數量比最少的少
                if (leastActive == -1 || active < leastActive) {
                    // Reset the active number of the current invoker to the least active number
                    // 重置最少活躍數量
                    leastActive = active;
                    // Reset the number of least active invokers
                    // 重置最少活躍提供者的數量
                    leastCount = 1;
                    // Put the first least active invoker first in leastIndexes
                    // 把最少活躍提供者的索引保存起來
                    leastIndexes[0] = i;
                    // Reset totalWeight
                    // 重置總權重
                    totalWeight = afterWarmup;
                    // Record the weight the first least active invoker
                    // 記錄第一個最少活躍提供者的權重
                    firstWeight = afterWarmup;
                    // Each invoke has the same weight (only one invoker here)
                    // 每個最少活躍提供者是否有同樣的權重???
                    sameWeight = true;
                    // If current invoker's active value equals with leaseActive, then accumulating.
                    // 如果當前活躍數量等於最少活躍數量
                } else if (active == leastActive) {
                    // Record the index of the least active invoker in leastIndexes order
                    // 最少活躍提供者的索引依次放入 leastIndexes
                    leastIndexes[leastCount++] = i;
                    // Accumulate the total weight of the least active invoker
                    // 累計最少活躍提供者的總權重
                    totalWeight += afterWarmup;
                    // If every invoker has the same weight?
                    // 如果當前權重和第一個最少活躍的權重不同,sameWeight 設為false
                    if (sameWeight && afterWarmup != firstWeight) {
                        sameWeight = false;
                    }
                }
            }
            // Choose an invoker from all the least active invokers
            // 最少活躍提供者只有一個,直接返回
            if (leastCount == 1) {
                // If we got exactly one invoker having the least active value, return this invoker directly.
                return invokers.get(leastIndexes[0]);
            }
            // 如擁有不同的權重,在權重的基礎上隨機選取一個,可以參考 RandomLoadBalance,有同樣的寫法
            if (!sameWeight && totalWeight > 0) {
                // If (not every invoker has the same weight & at least one invoker's weight>0), select randomly based on 
                // totalWeight.
                int offsetWeight = ThreadLocalRandom.current().nextInt(totalWeight);
                // Return a invoker based on the random value.
                for (int i = 0; i < leastCount; i++) {
                    int leastIndex = leastIndexes[i];
                    offsetWeight -= weights[leastIndex];
                    if (offsetWeight < 0) {
                        return invokers.get(leastIndex);
                    }
                }
            }
            // 權重相同,隨機選取一個
            // If all invokers have the same weight value or totalWeight=0, return evenly.
            return invokers.get(leastIndexes[ThreadLocalRandom.current().nextInt(leastCount)]);
        }
    

    ShortestResponseLoadBalance

    最短時間調用調用算法是指預估出來每個處理完請求的提供者所需時間,然後又選擇最少最短時間的提供者進行調用,整體處理邏輯和最少活躍數算法基本相似

    dubbo 在實現該算法時的具體邏輯如下

    1. 選取所有預估處理時間最短的提供者
    2. 如果只有一個,直接返回
    3. 如果權重不同,加權隨機選擇一個
    4. 如果權重相同,隨機選擇一個
        @Override
        protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
            // Number of invokers
            int length = invokers.size();
            // Estimated shortest response time of all invokers
            // 最少響應時間
            long shortestResponse = Long.MAX_VALUE;
            // The number of invokers having the same estimated shortest response time
            // 最少響應時間的提供者數量
            int shortestCount = 0;
            // The index of invokers having the same estimated shortest response time
            int[] shortestIndexes = new int[length];
            // the weight of every invokers
            int[] weights = new int[length];
            // The sum of the warmup weights of all the shortest response  invokers
            // 最少響應時間的提供者的總權重
            int totalWeight = 0;
            // The weight of the first shortest response invokers
            // 第一個最少響應時間的權重
            int firstWeight = 0;
            // Every shortest response invoker has the same weight value?
            // 所有的最少響應時間提供者是否擁有同樣的權重值
            boolean sameWeight = true;
    
            // Filter out all the shortest response invokers
            for (int i = 0; i < length; i++) {
                Invoker<T> invoker = invokers.get(i);
                RpcStatus rpcStatus = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName());
                // Calculate the estimated response time from the product of active connections and succeeded average elapsed time.
                //  平均響應成功時間
                long succeededAverageElapsed = rpcStatus.getSucceededAverageElapsed();
                // 活躍的連接連接數量
                int active = rpcStatus.getActive();
                // 預估響應時間
                long estimateResponse = succeededAverageElapsed * active;
                // 獲取權重值
                int afterWarmup = getWeight(invoker, invocation);
                // 保存權重留着後面用
                weights[i] = afterWarmup;
                // Same as LeastActiveLoadBalance
                // 如果預估時間小於最少的響應時間
                if (estimateResponse < shortestResponse) {
                    // 重置最少響應時間
                    shortestResponse = estimateResponse;
                    // 最少響應時間的提供者數量設為1
                    shortestCount = 1;
                    // 保存提供者下標
                    shortestIndexes[0] = i;
                    // 重置最少響應時間的提供者的總權重
                    totalWeight = afterWarmup;
                    // 重置第一個最少響應時間的權重
                    firstWeight = afterWarmup;
                    sameWeight = true;
                    // 如果當前最少響應時間等於最少響應時間
                } else if (estimateResponse == shortestResponse) {
                    // 最少最少響應時間的下標依次放入 shortestIndexes
                    shortestIndexes[shortestCount++] = i;
                    // 累計最少響應時間的總權重
                    totalWeight += afterWarmup;
                    // 如果當前權重和第一個最少響應時間的權重不同,sameWeight 設為false
                    if (sameWeight && i > 0
                            && afterWarmup != firstWeight) {
                        sameWeight = false;
                    }
                }
            }
            // 最少最少響應時間只有一個,直接返回
            if (shortestCount == 1) {
                return invokers.get(shortestIndexes[0]);
            }
            // 如擁有不同的權重,在權重的基礎上隨機選取一個,可以參考 RandomLoadBalance,有同樣的寫法
            if (!sameWeight && totalWeight > 0) {
                int offsetWeight = ThreadLocalRandom.current().nextInt(totalWeight);
                for (int i = 0; i < shortestCount; i++) {
                    int shortestIndex = shortestIndexes[i];
                    offsetWeight -= weights[shortestIndex];
                    if (offsetWeight < 0) {
                        return invokers.get(shortestIndex);
                    }
                }
            }
            // 權重相同,隨機選取一個
            return invokers.get(shortestIndexes[ThreadLocalRandom.current().nextInt(shortestCount)]);
        }
    

    ConsistentHashLoadBalance

    一致性hash算法是一種廣泛應用與分佈式緩存中的算法,該算法的優勢在於新增和刪除節點后,只有少量請求發生變動,大部分請求仍舊映射到原來的節點
    為了防止節點過少,造成節點分佈不均勻,一般採用虛擬節點的方式,dubbo默認的是160個虛擬節點

    網上關於一致性hash算法的文章有很多,這裏就不再多贅述,以下是dubbo中的實現,需要說明的是, 一致性hash算法中權重配置不起作用

        @Override
        protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
            String methodName = RpcUtils.getMethodName(invocation);
            // {group}/{interfaceName}:{version} + methoName 獲取當前消費者的唯一標示
            String key = invokers.get(0).getUrl().getServiceKey() + "." + methodName;
            // using the hashcode of list to compute the hash only pay attention to the elements in the list
            int invokersHashCode = invokers.hashCode();
            // 獲取當前消費者的一致性hash選擇器
            ConsistentHashSelector<T> selector = (ConsistentHashSelector<T>) selectors.get(key);
            // 如果 selector 還沒初始化,或者 invokers 已經變化,重新初始化 selector
            if (selector == null || selector.identityHashCode != invokersHashCode) {
                selectors.put(key, new ConsistentHashSelector<T>(invokers, methodName, invokersHashCode));
                selector = (ConsistentHashSelector<T>) selectors.get(key);
            }
            return selector.select(invocation);
        }
        // 一致性hash選擇器
        private static final class ConsistentHashSelector<T> {
    
            // 存儲hash環的數據結構 節點 -> 提供者
            private final TreeMap<Long, Invoker<T>> virtualInvokers;
    
            // 虛擬節點數量
            private final int replicaNumber;
    
            // 用來標示所有提供者是唯一標示
            private final int identityHashCode;
            // 用來存儲計算hash值參數下標的數組,例如計算第一個和第三個參數 該數組為[0,2]
            private final int[] argumentIndex;
    
            ConsistentHashSelector(List<Invoker<T>> invokers, String methodName, int identityHashCode) {
                this.virtualInvokers = new TreeMap<Long, Invoker<T>>();
                this.identityHashCode = identityHashCode;
                URL url = invokers.get(0).getUrl();
                // 虛擬節點數量,默認 160
                this.replicaNumber = url.getMethodParameter(methodName, HASH_NODES, 160);
                // 默認只對第一個參數進行hash
                String[] index = COMMA_SPLIT_PATTERN.split(url.getMethodParameter(methodName, HASH_ARGUMENTS, "0"));
                argumentIndex = new int[index.length];
                for (int i = 0; i < index.length; i++) {
                    argumentIndex[i] = Integer.parseInt(index[i]);
                }
                for (Invoker<T> invoker : invokers) {
                    String address = invoker.getUrl().getAddress();
                    // 關於這個地方為什麼要除以4,我理解的是md5後為16字節的數組,計算hash值只需要用到四個字節,所以可以用四次
                    // 因此除以4,算是一個性能優化點
                    for (int i = 0; i < replicaNumber / 4; i++) {
                        // md5, 獲得一個長度為16的字節數組
                        byte[] digest = md5(address + i);
                        for (int h = 0; h < 4; h++) {
                            // 如果h=0,則用第0,1,2,3四個字節進行位運算,得出一個0-2^32-1的值
                            // 如果h=1,則用第4,5,6,7四個字節進行位運算,得出一個0-2^32-1的值
                            // 如果h=2,則用第8,9,10,11四個字節進行位運算,得出一個0-2^32-1的值
                            // 如果h=3,則用第12,13,14,15四個字節進行位運算,得出一個0-2^32-1的值
                            long m = hash(digest, h);
                            virtualInvokers.put(m, invoker);
                        }
                    }
                }
            }
    
            public Invoker<T> select(Invocation invocation) {
                String key = toKey(invocation.getArguments());
                byte[] digest = md5(key);
                return selectForKey(hash(digest, 0));
            }
            // 根據配置生成計算hash值的key
            private String toKey(Object[] args) {
                StringBuilder buf = new StringBuilder();
                for (int i : argumentIndex) {
                    if (i >= 0 && i < args.length) {
                        buf.append(args[i]);
                    }
                }
                return buf.toString();
            }
    
            private Invoker<T> selectForKey(long hash) {
                // 找到hash值在hash環上的位置
                // ceilingEntry 方法返回大於或者等於當前key的鍵值對
                Map.Entry<Long, Invoker<T>> entry = virtualInvokers.ceilingEntry(hash);
                // 如果返回為空,說明落在了hash環中2的32次方-1的最後,直接返回第一個
                if (entry == null) {
                    entry = virtualInvokers.firstEntry();
                }
                return entry.getValue();
            }
            // 得出一個0-2^32-1的值, 四個字節組成一個長度為32位的二進制数字並轉化為long值
            private long hash(byte[] digest, int number) {
                return (((long) (digest[3 + number * 4] & 0xFF) << 24)
                        | ((long) (digest[2 + number * 4] & 0xFF) << 16)
                        | ((long) (digest[1 + number * 4] & 0xFF) << 8)
                        | (digest[number * 4] & 0xFF))
                        & 0xFFFFFFFFL;
            }
    
            private byte[] md5(String value) {
                MessageDigest md5;
                try {
                    md5 = MessageDigest.getInstance("MD5");
                } catch (NoSuchAlgorithmException e) {
                    throw new IllegalStateException(e.getMessage(), e);
                }
                md5.reset();
                byte[] bytes = value.getBytes(StandardCharsets.UTF_8);
                md5.update(bytes);
                return md5.digest();
            }
    
        }
    

    總結

    以上就是dubbo負載均衡源碼的全部解析,如果還是不明白,可以看下官方文檔的解析  
    http://dubbo.apache.org/zh-cn/docs/source_code_guide/loadbalance.html

    dubbo的負載均衡算法總體來說並不複雜,代碼寫的也很優雅,簡潔,看起來很舒服,而且有很多細節的處理值得稱讚,例如預熱處理,輪訓算法的平滑處理等。

    我們平時使用時,可以根據自己的業務場景,選擇適合自己的算法,當然,一般情況下,默認的的隨機算法就能滿足我們的日常需求,而且隨機算法的性能足夠好。

    如果覺得dubbo提供的五種算法都不能滿足自己的需求,還可以通過dubbo的SPI機制很方便的擴展自己的負載均衡算法。

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※台北網頁設計公司這麼多,該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

    ※網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

    ※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

    ※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

    ※教你寫出一流的銷售文案?

  • 從0到1打造數據可信的數據產品:解析數據治理在過程可信變革中的運作流程

    從0到1打造數據可信的數據產品:解析數據治理在過程可信變革中的運作流程

    摘要:本文針對“數據牽引改進,工具固化規範”這一思路在業務團隊落地過程中的動作流程進行詳細闡述,並明確了支撐整個流程的關鍵角色定義和組織運作形式。

    目的

    為實現雲服務開發的過程可信,需要基於數據對各個服務產品部的可信變革動作進行數據採集、進展可視、目標牽引、能力評估,最終用數據反映目標達成。與傳統的“基於數據晾曬驅動業務團隊改進,6+1指標度量”的運作方式有本質的區別,我們是基於統一的作業工具上產生的客觀數據呈現,識別研發過程中基本的流程斷裂點和質量缺失動作,和業務團隊達成一致的目標后,把大部分改進動作固話到作業工具中自動化承載,我們稱這個思路為“數據牽引改進,工具固化規範”,也就是我們不僅告訴業務團隊哪裡有問題,同時也要基於我們的作業工具,輔助業務團隊一起改進完善。

    本文針對“數據牽引改進,工具固化規範”這一思路在業務團隊落地過程中的動作流程進行詳細闡述,並明確了支撐整個流程的關鍵角色定義和組織運作形式。

    數據牽引改進,是指關注軟件交付過程中各種度量數據的收集、統計、分析和反饋,通過可視化的數據客觀反映整個研發過程的狀態,以全局視角分析系統約束點,並和業務團隊達成共識,提煉出客觀有效的改進目標;工具固化規範,針對識別出來的Gap點和重點問題進行分析,制定出可以在作業工具承載的模板規範,以及需要工程師行為做出改變的能力要求,並在作業工具上對這些規範要求的落地效果進行檢查,用數據度量改進效果。最後,對改進項目進行總結分享,打造學習型組織,不斷驅動持續改進和價值交付,牽引研發團隊模式和文化的轉變。

    2020年的研發過程可信圍繞CleanCode、構建、開源、E2E追溯四個領域開展,這也是公司要求的可信變革中最基本、最重要、投入產出比最大的四個點。

    整體流程說明

    整個運作流程,圍繞數據,按照“定義軟件工程規範->定義數據分析模型->工具實現數據度量和分析->數據運營發現實際軟件工程活動和規範的偏差->工具輔助團隊改進->工具固化軟件工程規範”這個流程進行實施,並對最終效果進行階段性總結。隨着業務團隊能力的提升以及軟件工程規範性、開發模式的改變,對最初定義的軟件工程規範,會階段性的進行完善,循環往複、持續優化,最終讓業務團隊在遵守公司要求的研發過程可信規範的前提下,實現業務成功。

    1) 定義軟件工程規範:圍繞公司可信變革的目標,BU對各個服務產品部的研發模式規範和能力要求,COE制定適合BU現狀的軟件工程規範;

    2) 定義數據模型:COE針對制定的軟件工程規範,提煉出核心的、有針對性、可用工具度量的數據模型,並且和各個服務產品部達成一致;

    3) 工具實現數據度量和分析:根據這幾個數據模型,數據分析工具自動從數據源進行採集、匯總、計算,並把結果呈現在數據看板上;業務團隊可以打開匯總數據,根據明細數據進行動作規範自檢和改進;

    4) 數據運營發現實際軟件工程活動和規範的偏差:數據治理小組在實際運營過程中,分析度量指標的數據,識別業務團隊實際的軟件工程活動和要求規範不一致的Gap點和關鍵問題;

    5) 工具輔助業務團隊改進:COE針對分析出來的Gap點和關鍵問題,制定相應的改進措施,作業工具承載流程規範模板化整改,並針對業務團隊的不規範行為,制定適合各個服務產品部的公約要求,促使業務團隊人員能力提升;

    6) 工具固化軟件工程規範:針對業務團隊的公約要求,在作業工具上進行check,最終作業工具承載了整個軟件工程規範要求,以及融入到作業流程中的規範要求事前檢查。

    三層數據分析模型

    我們採用了三層數據分析模型,由作業工具自動採集用戶研發過程行為明細數據,數據分析工具進行准實時匯總計算呈現總體目標,三層數據系統性的輔助業務團隊系統性的識別研發過程中的不規範點和能力短板,讓業務團隊“知其然,知其所以然”。這三層數據模型是層層深入,迭代完善,下層支撐上層的關係。

    第一層:目標、進展、結果數據分析;和公司可信變革目標牽引對齊,結合BU實際情況,形成BU的整體可信要求,並在數據分析看板上呈現各個服務產品部要達成的過程可信目標、每日的改進進展和最終完成情況;例如,對各個服務產品部要求達成CleanCode的目標。

    第二層:詞法/語法分析數據;COE針對第一層的目標牽引,分解出來的具體實施環節的度量指標,只有這些分解的指標都完成,第一層的目標才達成。這一層數據的目的主要是圍繞幫助業務團隊分析自己的能力短板在哪裡,進行有針對性的改進指;通過打開匯總數據的層層下鑽,用明細數據來分析業務團隊在DevSecOps軟件工程規範流程中關鍵動作執行的缺失點,並針對性的制定改進規範要求,牽引作業工具或者業務團隊補齊該部分缺失動作;例如,CleanCode的過程可信目標達成,可以分解成:靜態檢查配置合規率、Committer合入保障率、代碼倉Clean三個目標,只有這三個目標達成,就可以認為CleanCode總體目標達成。

    第三層:語義分析數據:COE打開第二層數據,不僅要看這些關鍵動過做沒做,還要看做的效果怎麼樣,最終效果體現在業務團隊的DevSecOps軟件工程規範提升;這一層的數據分析聚焦在防止為了指標而做第二層的數據,而是看業務團隊是否在真正參考BU制定的規範牽引的目標,提升業務交付過程中的效能、可信、質量能力,以及最終產生實際的業務效果。通過打開各個團隊的明細數據分析審視業務團隊執行的關鍵動作是否符合規範,是否在合適的階段點執行,執行效果是否有效;並階段性的總結和提煉經驗,形成知識資產固化到作業工具。例如,針對第二層的靜態檢查配置合規率,可以分解為:靜態檢查配置有效性和靜態檢查執行有效性。靜態檢查配置有效性,包括:檢查靜態檢查工具配置的數量、是否符合BU的配置規範,以及是否在代碼合入主幹master時進行了配置;靜態檢查執行有效性,主要看是否每一次MR提交時都執行靜態檢查、是否發現問題在研發活動的最早階段,攔截的問題的效果怎麼樣。只有第三層的動作度量都達成后,才可以說第二層的目標是達成的。

    數據治理過程流程圖

    為了實現“數據牽引改進,工具固化規範”這個目標,準確、一致、准實時的數據是核心關鍵,但因為數據採集不完整、業務團隊不規範、數據呈現維度不一致等原因,數據的準確性有一個不斷提升的過程,因此需要對各個層級展示的數據進行治理。整個數據治理過程中,由“業務團隊/作業工具/治理小組/數據分析工具(阿基米德)/COE”五個角色緊密配合,而且以年/半年為目標,不斷總結經驗,循環往複、持續優化的過程。

    a) COE:和公司可信變革目標牽引對齊,結合BU能力現狀,形成BU的整體可信要求;

    b) COE:針對BU的業務現狀,定義出適合BU現狀的軟件工程規範要求;業務團隊:和BU發布的各個領域的軟件工程規範牽引目標達成一致;

    c) COE:針對規範分解出核心的度量指標,並制定度量數據模型;

    d) 研發用戶:在使用作業工具進行研發活動;作業工具:承載了BU各個服務產品部在使用過程中沉澱的行為數據;

    e) 數據分析(阿基米德):准實時接入作業工具的數據,展示各個服務產品部當前的研發能力現狀;

    f) COE:和各個服務產品部達成一致,制定各個服務產品部的年度牽引目標;

    g) 數據分析(阿基米德):用數據呈現各個服務產品部的牽引目標和能力現狀,統一數據口徑;呈現月/周/天的明細數據,以及支撐Gap分析和重點問題的數據視圖;

    h) COE:根據牽引目標和能力現狀,分析Gap原因和關鍵問題;治理小組:在數據運營過程中,根據數據分析團隊當前的能力現狀是否和數據呈現一致;

    i) 研發用戶:可以實時登錄數據工具(阿基米德)進行查看各個層級的明細數據;

    j) 治理小組:根據准實時進展數據,分析當前團隊研發過程中的實際問題,並匯總給COE;

    k) COE:結合細粒度的分析數據、以及治理小組匯總出來的各個服務產品部的實際問題,制定規範和改進措施,包括作業工具的規範和研發用戶的動作行為公約;

    l) 作業工具:承載作業工具上落地的規範要求;治理小組:作為接口人,承接研發工程師的行為規範公約,結合各個服務產品部實際情況來負責落地;

    m) 研發用戶:按照規範要求和針對數據的自檢進行研發過程行為規範化;

    n) 研發工具:對研發用戶的行為規範是否滿足要求進行自動化檢查;最終目標是讓整個軟件工程規範都固化在工具中進行承載;

    o) 數據分析(阿基米德):呈現按照規範改進后的明細數據和匯總目標;研發用戶:自助查看整改后的明細數據;

    p) COE:根據數據改進的效果,以及過程中暴露的問題進行總結后形成經驗資產,並持續改進;

    數據流圖

    過程可信的數據在各個工具系統中採集、流轉、匯聚、分析、呈現,整個數據流圖如下:

    其中,識別出6個重要的全量數據源:

    a) 代碼庫數據:該數據由伏羲的服務信息樹上配置的代碼庫數據,加上阿基米德上人工配置的代碼庫,構成各個雲服務發布到生產倉的代碼全集;

    b) Workitem信息流數據:當前識別vision上的需求、問題、task,加上Gitlab/Codeclub上的issue,構成可識別的Workitem數據全集;

    c) SRE現網包數據:包括普羅部署、CCE、CPS、CDK各種類型部署的包數據,構成全量現網包數據;

    d) 開源二進制包數據:開源中心倉數據(java、python、go、nodejs四種)語言,加上公司c/c++的數據構成全量開源二進制包數據;

    e) 研發過程配置數據:阿基米德上配置的committer數據是全量的committer數據;阿基米德上識別出來的主分支是全量的主分支(邏輯“master”)數據;

    f) 伏羲研發過程數據:伏羲三個庫,MongoDB的靜態檢查、門禁數據;MySQL中的測試、發布數據;MySQL中包和多個流水線的對應關係數據;一起構成了以“包”為維度的全量伏羲研發過程數據;

    運作組織

    數據治理運營團隊

    按照過程可信在BU的落地策略,在CleanCode、構建、開源、E2E追溯四個領域設置數據治理運營團隊,由 “數據分析工具(阿基米德)—COE—各個服務產品部接口人組成的治理小組”三個角色組成,以“指標度量為牽引,數據的客觀呈現為落地方式,業務的價值反饋為最終目的”的原則來落地數據治理工作。

    COE的職責:

    1) 和公司可信變革目標牽引對齊,結合BU能力現狀,形成BU的整體可信要求;定義出適合BU現狀的軟件工程規範要求;針對規範分解出核心的度量指標,並制定度量數據模型;

    2) 利用作業工具已經產生的數據,和治理小組一起分析識別數據質量的問題,按照三層數據分析模型,層層打開,識別業務團隊能力Gap點。

    3) 分析典型問題,識別作業流的斷裂點進行補齊,和業務團隊的不規範動作,制定規範和公約要求,逐步改善數據質量。

    4) 事後歸納總結,識別出流程缺失,組織缺失,責任缺失等機制行問題,並固化到作業工具中。

    治理小組:

    1) 結合各個服務產品部的實際情況,承接COE的數據治理規範在各個服務產品部的落地;

    2) 識別數據治理動作在各個服務產品部落地過程中的實際問題,和COE一起分析,提出系統性的解決思路,最終固化到作業工具中。

    3) 跟蹤過程可信在業務團隊落地的過程中的進展,為業務團隊最終達成可信變革目標負責,為改進過程產生實際的業務價值負責;

    數據分析工具(阿基米德):

    1) 確保接入的數據準確、實時、一致,用數據實時反映BU各個服務產品部的能力現狀,為COE和治理小組的數據運營提供數據支撐;

    2) 系統性的落地COE的方案設計,實現整個BU統一標準的數據看板,能夠清晰的通過數據識別出來業務團隊的能力Gap,牽引業務團隊達成整體改進目標;

    3) 按照三層數據模型進行數據展示,層層下鑽,讓業務團隊“知其然,知其所以然”,牽引業務團隊中的每一個人都能自己進行改進;

    4) 通過數據分析,識別DevSecOps軟件工程規範在BU的業務團隊落地過程中的重點問題,以及該問題背後的流程、制度缺失,促使最終規範固化在作業工具中。

    例會設置

    “數據驅動DevSecOps能力提升例會”為研發領域數據治理相關問題的求助和裁決例會。

    會議分為三個階段:

    1) 第一階段,例行議題,形式類似於“體檢報告”,用數據反映業務團隊的現狀和問題;

    2) 第二階段,申報議題,形式類似於“專家會診”,討論某一個具體數據治理過程中的問題和Top困難求助;

    3) 第三階段,靈活安排議題,形式類似於“問題總結”,針對某一類的具體問題,進行集中討論和歸納總結定義,形成BU的規範流程和章程總結。

    主數據承載系統

    主數據是指具有高業務價值的、可以在企業內跨越多個業務部門被重複使用的數據,是單一、準確、權威的數據來源。和業務型數據、分析型數據相比,主數據主要有以下幾個特徵:

    1) 特徵一致性:也就是能否保證主數據的關鍵特徵在不同應用、不同系統中的高度一致,直接關係了數據治理成敗;

    2) 識別唯一性:在一個系統、一個平台,甚至一個企業範圍內,同一主數據實體要求具有唯一的數據標識,即數據編碼;

    3) 長期有效性:貫穿該業務對象的整個生命周期甚至更長,當該主數據失去其效果時,系統採取的措施通常為軟刪除,而不是物理刪除;

    4) 業務穩定性:在業務過程中其識別信息和關鍵特徵會被業務過程中產生的數據繼承、引用和複製。除非該主數據本身的特徵發生變化,否則該主數據不會隨着業務的過程中被其他系統修改。

    主數據源識別原則:

    a) 如果有多個數據源構成同類型數據的主數據,兩種處理策略:

    1)選取一個源系統逐步收編其他源系統的數據,變成唯一主數據源

    2)如果1)不能實現,由阿基米德系統進行封裝后屏蔽多個數據源系統,該類型數據的唯一數據源變成阿基米德,待後續1)實現后,阿基米德該類型主數據源失效。

    3)當數據在多個作業系統中進行流轉時,判斷是否作為主數據源的標準是:數據在該系統有實際的業務動作產生,而不是只承載數據的流轉。

    b) 如果確定為唯一數據源,其他消費該類型數據的系統不能和數據源產生衝突。

    所有數據僅能在數據源產生,其它系統只能讀取不能修改。下游發現的數據源質量問題,應當在數據源頭進行修正。

    c) 主數據使用方不得改變原始數據,但可以進行擴展。

    數據消費方不得對獲取的數據進行增、刪、改,但可以在數據的基礎上進行屬性擴展。

    d) 在滿足信息安全的前提下充分共享,不得拒絕合理的數據共享需求。

    數據如果不流轉,不僅不會產生業務價值,還增加存儲成本;只有不斷流轉,對業務團隊產生實際價值時,還能得到使用效果的反饋,促進數據價值的進一步提升。

    原則為:核心資產安全優先,非關鍵資產效率優先。

    一類主數據源

    二類主數據源

     

    點擊關注,第一時間了解華為雲新鮮技術~

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

    ※不管是台北網頁設計公司、台中網頁設計公司,全省皆有專員為您服務

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

    ※帶您來看台北網站建置,台北網頁設計,各種案例分享

    ※別再煩惱如何寫文案,掌握八大原則!

  • 歐盟2020年環保目標難達陣 生物多樣性挑戰尤多

    摘錄自2019年12月4日中央社報導

    聯合國氣候變化綱要公約第25次締約方會議(COP25)2日在西班牙馬德里開議,將持續至13日。歐洲環保署在配合會議出版的報告中指出,儘管大部分原定2020年達成的環保目標勢必已無法達成,尤其是在生物多樣性領域,歐盟仍有機會實現為2030年和2050年設定的較長遠目標。

    報告強調,有鑑於生物多樣性降低的程度令人憂心、氣候變遷衍生的多方面衝擊日益嚴重,以及天然資源遭過度消耗,歐洲必須在未來10年儘速行動。

    報告指出,儘管1990至2017年期間,歐洲的溫室氣體排放量已減少22%,且再生能源的使用比例也提升,歐洲在環保領域仍有進步空間。

    根據歐洲環保署,在為2020年設定的13個生物多樣性政策目標中,只有兩個達標:劃設海洋保護區和陸地保護區。然而,物種、天然棲地、水生態系統、溼地和土壤狀況的保護,以及化學物排放與空氣和噪音的污染,仍令人擔憂。

    本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※台北網頁設計公司這麼多,該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

    ※網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

    ※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

    ※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

    ※教你寫出一流的銷售文案?

  • 陷垃圾危機 菲律賓計劃禁用一次性塑膠

    摘錄自2019年12月5日中央通訊社綜合報導

    菲律賓環境部長希瑪圖今天(5日)說,由於人們製造數量甚多的廢棄物,清理速度遠遠趕不及,菲律賓正處於垃圾危機中。環境部預計將在2週內規劃完成限用一次性塑膠的全國禁令。

    ABS-CBN新聞網和「菲律賓每日詢問報」(Philippine Daily Inquirer)報導,希瑪圖(Roy Cimatu)說,在馬尼拉都會區,今年第一季製造的廢棄物達3萬4574.77立方公尺,第二季則為3萬2221.17立方公尺,已超過全年基線預估值5萬8112.31立方公尺。

    他引述數據表示,菲律賓是全球第3大海洋塑膠污染來源國。為此,當局須加強固體廢棄物管理政策。菲律賓總統杜特蒂(Rodrigo Duterte)日前提出為因應氣候變遷問題,菲律賓應禁用塑膠。

    希瑪圖說,除了一次性塑膠禁令,環境暨天然資源部(DENR)正擬定的命令也將涵括塑膠回收問題。

    本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

    ※不管是台北網頁設計公司、台中網頁設計公司,全省皆有專員為您服務

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

    ※帶您來看台北網站建置,台北網頁設計,各種案例分享

    ※別再煩惱如何寫文案,掌握八大原則!

  • 德國總理許諾為汽車製造商掃除法律障礙 推動無人車、電動車研發

    德國總理安格拉•默克爾稱,自動駕駛汽車很快便能在德國進行上路測試,許諾為汽車製造商們掃除法律障礙。

    德國擁有全球最大的幾家汽車製造商。安格拉•默克爾表示,德國汽車行業應該起草一份請願書提交柏林,以加快無人駕駛汽車的研發與推出,請願書中最好附上時間規劃。

    目前,全球的汽車製造商都在致力於研發自動駕駛汽車,然而其原型至少將在2020年才能獲得推出。安格拉•默克爾12日在柏林的一次工業活動中透露,德國政府機關將於5月底舉行會議,討論下一步工作計畫,如若待辦事項均已完成,內閣便可開始推進車輛測試相關法律依據的制定工作。她告知戴姆勒集團CEO蔡澈(Dieter Zetsche)等稱,“這一話題在政府內部並不存在爭議。”

    德國政府還考慮支持電動車的研發工作,拉動消費者需求。然而德國內政部長朔伊布勒(Wolfgang Schaeuble)上月表示,政府機關會設法支援電動車研發,但可能無法滿足汽車製造商們的所有願望。

    德國工業領袖已經向政府施壓,要求推出激勵措施拉動電動車需求增長,並稱如果德國想要保持在汽車製造行業領先,那麼推出激勵措施是必需的。

    社會民主黨資深議員Hubertus Heil則對此表示,執政聯盟將在本週三的會議上就相關問題達成一致,“我相信我們能夠說服朔伊布勒。”

    本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※台北網頁設計公司這麼多,該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

    ※網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

    ※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

    ※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

    ※教你寫出一流的銷售文案?

  • 8 縣市 2020 年電動機車補助出爐,新購補助減少、汰舊換新成主力

    8 縣市 2020 年電動機車補助出爐,新購補助減少、汰舊換新成主力

    2020 年 1 月邁向尾聲,各縣市的電動機車補助也陸續出爐,至過年前已有 8 個縣市公布新購電動機車或汰舊換新補助的辦法。

    由於環保署補助在 2020 年退場,因此 2019 年底掀起一股電動機車的購車熱潮。2020 年後環保署政策改變,主力放在淘汰舊型機車減少空氣污染排放。因此雖然沒了新購電動機車補助,但汰舊換新的範圍擴大,2007 年 6 月 30 日前生產的一至四行程老舊燃油機車汰換成電動機車或 7 期燃油機車都能享有補助,重型機車每輛 5,000 元,輕型機車每輛 3,000 元。

    除了環保署政策改變,工業局購買電動機車的補助也下滑,從原先的每輛補助 1 萬元減少至 7,000 元,也是唯一全國適用的新購電動機車補助。因此 2020 年中央政府補助新購電動機車每輛 7,000 元,汰舊換新購買重型電動機車每輛共 12,000 元,汰舊換新購買輕型電動機車每輛共 1 萬元。

    截至 1 月 22 日有 8 個縣市公布電動機車補助額。

    地方政府部分,目前補助公布的縣市包括台北市、台中市、嘉義市、台南市、屏東縣、花蓮縣、台東縣和彰化縣。台北市和屏東縣等縣市跟隨環保署方向,停止補助新購電動機車,但繼續提供汰舊換新補助。彰化縣則是僅公佈汰舊換新補助辦法,尚未宣告新購電動機車補助措施。

    花蓮縣和台東縣補助金額最高但仰賴花東基金,有補助數量限制,每輛電動機車補助 1 萬元,花蓮縣政府僅於汰舊換新補助微幅加碼。花東以外,以嘉義市的補助金額最高,新購電動機車補助 8,000 元,汰舊換新補助更高達 1 萬元。

    有些人認為 2020 年補助減少,電動機車銷量將大幅衰退。電動機車大廠 Gogoro 指出,由於汰購換新補助帶動換車潮,1 月上半銷售量已達 2019 年同期近 80%。不過這樣的觀察僅為少量樣本,電動機車能否維持 2019 年的強勢表現,值得持續關注。

    (合作媒體:。首圖來源:Gogoro)

    本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

    ※不管是台北網頁設計公司、台中網頁設計公司,全省皆有專員為您服務

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

    ※帶您來看台北網站建置,台北網頁設計,各種案例分享

    ※別再煩惱如何寫文案,掌握八大原則!

  • PCA降維的原理、方法、以及python實現。

    PCA降維的原理、方法、以及python實現。

    參考:菜菜的sklearn教學之降維算法.pdf!!

    PCA(主成分分析法)

    1. PCA(最大化方差定義或者最小化投影誤差定義)是一種無監督算法,也就是我們不需要標籤也能對數據做降維,這就使得其應用範圍更加廣泛了。那麼PCA的核心思想是什麼呢?

    • 例如D維變量構成的數據集,PCA的目標是將數據投影到維度為K的子空間中,要求K<D且最大化投影數據的方差。這裏的K值既可以指定,也可以利用主成分的信息來確定。
    • PCA其實就是方差與協方差的運用。
    • 降維的優化目標:將一組 N 維向量降為 K 維,其目標是選擇 K 個單位正交基,使得原始數據變換到這組基上后,各變量兩兩間協方差為 0,而變量方差則盡可能大(在正交的約束下,取最大的 K 個方差)。

    2. PCA存在的問題:

    • 原來的數據中比如包括了年齡,性別,身高等指標降維后的數據既然維度變小了,那麼每一維都是什麼含義呢?這個就很難解釋了,所以PCA本質來說是無法解釋降維后的數據的物理含義,換句話說就是降維完啦計算機能更好的認識這些數據,但是咱們就很難理解了。
    • PCA對數據有兩個假設:數據必須是連續數值型;數據中沒有缺失值。
    • 過擬合:PCA 保留了主要信息,但這個主要信息只是針對訓練集的,而且這個主要信息未必是重要信息。有可能捨棄了一些看似無用的信息,但是這些看似無用的信息恰好是重要信息,只是在訓練集上沒有很大的表現,所以 PCA 也可能加劇了過擬合;

    3. PCA的作用:

    • 緩解維度災難:PCA 算法通過捨去一部分信息之後能使得樣本的採樣密度增大(因為維數降低了),這是緩解維度災難的重要手段;
    • 降噪:當數據受到噪聲影響時,最小特徵值對應的特徵向量往往與噪聲有關,將它們捨棄能在一定程度上起到降噪的效果;
    • 特徵獨立:PCA 不僅將數據壓縮到低維,它也使得降維之後的數據各特徵相互獨立;

    4. 方差的作用:咱們可以想象一下,如果一群人都堆疊在一起,我們想區分他們是不是比較困難,但是如果這群人站在馬路兩側,我們就可以很清晰的判斷出來應該這是兩伙人。所以基於方差我們可以做的就是讓方差來去判斷咱們數據的擁擠程度,在這裏我們認為方差大的應該辨識度更高一些,因為分的比較開(一條馬路給隔開啦)。方差可以度量數值型數據的,數據若是想要區分開來,他那他們的離散程度就需要比較大,也就是方差比較大。

    5. 協方差的作用:

    6. 計算過程:(下圖為採用特徵值分解的計算過程,若採用SVM算法,則無需計算協方差矩陣!)

    為什麼我們需要協方差矩陣?我們最主要的目的是希望能把方差和協方差統一到一個矩陣里,方便後面的計算。

      假設我們只有 a 和 b 兩個變量,那麼我們將它們按行組成矩陣 X:(與matlab不同的是,在numpy中每一列表示每個樣本的數據,每一行表示一個變量。比如矩陣X,該矩陣表示的意義為:有m個樣本點,每個樣本點由兩個變量組成!)

      然後:

              

      Cov(a,a) = E[(a-E(a))(a-E(a))], Cov(b,a) = E[(b-E(b))(a-E(a))],因為E(b)=E(a)=0,所以大大簡化了計算!!!(這就體現了去中心化的作用!)

      我們可以看到這個矩陣對角線上的分別是兩個變量的方差,而其它元素是 a 和 b 的協方差。兩者被統一到了一個矩陣里。

    7. 特徵值與特徵向量的計算方法—--特徵值分解與奇異值分解法(SVD)(有關特徵值與奇異值可見我的博文!)

    (1) 特徵值分解的求解過程較為簡單,以下圖為例子

    (2) 特徵值分解存在的缺點:

    • 特徵值分解中要求協方差矩陣A必須是方陣,即規模必須為n*n。
    • 後期計算最小投影維度K時,計算量過大。
    • 當樣本維度很高時,協方差矩陣計算太慢;

    (3) SVD算法(奇異值分解)的提出克服這些缺點,目前幾乎所有封裝好的PCA算法內部採用的都是SVD算法進行特徵值、特徵向量以及K值的求解。

    • 奇異值(每個矩陣都有):設A是一個mXn矩陣,稱正半定矩陣A‘A的特徵值的非負平方根為矩陣A的奇異值,其中A‘表示矩陣A的共扼轉置矩陣(實數矩陣的共軛就是轉置矩陣,複數矩陣的共軛轉置矩陣就是上面所說的行列互換后每個元素取共軛)
    • 只有方陣才有特徵值。

    (4) SVD算法的計算過程:(numpy中已經將SVD進行了封裝,所以只需要調用即可)

    可以發現,採用SVD算法無需計算協方差矩陣,這樣在數據量非常大的時候可以降低消耗。

    • A為數據矩陣,大小為M*N(2*5)
    • U是一個由與數據點之間具有最小投影誤差的方向向量所構成的矩陣,大小為M*M(2*2),假如想要將數據由M維降至K維,只需要從矩陣U中選擇前K個列向量,得到一個M*K的矩陣,記為Ureduce。按照下面的公式即可計算降維后的新數據:降維后的數據矩陣G = A.T * Ureduce. 
    • sigma為一個列向量,其包含的值為矩陣A的奇異值。
    • VT是一個大小為N*N的矩陣,具體意義我們無需了解。

    利用python實現PCA降維(採用SVD的方法):

     1 from numpy import linalg as la
     2 import numpy as np
     3 #1.矩陣A每個變量的均值都為0,所以不用進行“去平均值”處理。倘若矩陣A的每個變量的均值不為0,則首先需要對數據進行預處理
     4 #  才可以進行協方差矩陣的求解。
     5 #2.與matlab不同的是,在numpy中每一列表示每個樣本的數據,每一行表示一個變量。
     6 #  比如矩陣A,該矩陣表示的意義為:有5個樣本點,每個樣本點由兩個變量組成!
     7 #3.np.mat()函數中矩陣的乘積可以使用 * 或 .dot()函數
     8 #  array()函數中矩陣的乘積只能使用 .dot()函數。而星號乘(*)則表示矩陣對應位置元素相乘,與numpy.multiply()函數結果相同。
     9 A = np.mat([[-1, -1, 0, 2, 0], [-2, 0, 0, 1, 1]])
    10 # A = np.mat([[-1, -2], [-1, 0], [0, 0], [2, 1], [0, 1]]).T
    11 U, sigma, VT = la.svd(A)
    12 print("U:")
    13 print(U)
    14 print("sigma:")
    15 print(sigma)
    16 print("VT:")
    17 print(VT)
    18 print("-"*30)
    19 print("降維前的數據:")
    20 print(A.T)
    21 print("降維后的數據:")
    22 print(A.T * U[:,0])

    運行結果圖:與上文採用特徵值分解所得到的降維結果一致!

    8.PCA的重建

     眾所周知,PCA可以將高維數據壓縮為較少維度的數據,由於維度有所減少,所以PCA屬於有損壓縮,也就是,壓縮后的數據沒有保持原來數據的全部信息,根據壓縮數據無法重建原本的高維數據,但是可以看作原本高維數據的一種近似。

     還原的近似數據矩陣Q = 降維后的矩陣G * Ureduce.T

    9.採用sklearn封裝好的PCA實現數據降維(採用的是SVD算法):

     1 import numpy as np
     2 from sklearn.decomposition import PCA
     3 # 利用sklearn進行PCA降維處理的時候,數據矩陣A的行數表示數據的個數,數據矩陣A的列數表示每條數據的維度。這與numpy中是相反的!
     4 # A = np.mat([[-1, -1, 0, 2, 0], [-2, 0, 0, 1, 1]]).T
     5 A = np.mat([[-1, -2], [-1, 0], [0, 0], [2, 1], [0, 1]])
     6 pca = PCA(n_components = 1)
     7 pca.fit(A)
     8 # 投影后的特徵維度的方差比例
     9 print(pca.explained_variance_ratio_)
    10 # 投影后的特徵維度的方差
    11 print(pca.explained_variance_)
    12 print(pca.transform(A))

     可以發現,採用sklearn封裝的方法實現PCA與上文的方法達到的結果一致!

    10.如何確定主成分數量(針對於Sklearn封裝的PCA方法而言)

    PCA算法將D維數據降至K維,顯然K是需要選擇的參數,表示要保持信息的主成分數量。我們希望能夠找到一個K值,既能大幅降低維度,又能最大限度地保持原有數據內部的結構信息。實現的過程是通過SVD方法得到的S矩陣進行操作求解,

     

    11.sklearn中封裝的PCA方法的使用介紹。

    PCA的函數原型

     (1)主要參數介紹

    n_components

    • 這個參數類型有int型,float型,string型,默認為None。 它的作用是指定PCA降維后的特徵數(也就是降維后的維度)。 
    • 若取默認(None),則n_components==min(n_samples, n_features),即降維后特徵數取樣本數和原有特徵數之間較小的那個;
    • 若n_components}設置為‘mle’並且svd_solver設置為‘full’則使用MLE算法根據特徵的方差分佈自動去選擇一定數量的主成分特徵來降維; 
    • 若0<n_components<1,則n_components的值為主成分方差的閾值; 通過設置該變量,即可調整主成分數量K。
    • 若n_components≥1,則降維后的特徵數為n_components; 

    copy

    •  bool (default True) 
    • 在運行算法時,將原始訓練數據複製一份。參數為bool型,默認是True,傳給fit的原始訓練數據X不會被覆蓋;若為False,則傳給fit后,原始訓練數據X會被覆蓋。 

    whiten

    • bool, optional (default False)
    • 是否對降維后的數據的每個特徵進行歸一化。參數為bool型,默認是False。

    (2)主要方法介紹:

    fit(X,y=None) :用訓練數據X訓練模型,由於PCA是無監督降維,因此y=None。 

    transform(X,y=None) :對X進行降維。 

    fit_transform(X) :用訓練數據X訓練模型,並對X進行降維。相當於先用fit(X),再用transform(X)。 

    inverse_transform(X) :將降維后的數據轉換成原始數據。(PCA的重建)

     (3)主要屬性介紹:

    components:array, shape (n_components, n_features) ,降維后各主成分方向,並按照各主成分的方差值大小排序。 

    explained_variance:array, shape (n_components,) ,降維后各主成分的方差值,方差值越大,越主要。 

    explained_variance_ratio:array, shape (n_components,) ,降維后的各主成分的方差值佔總方差值的比例,比例越大,則越主要。 

    singular_values:array, shape (n_components,) ,奇異值分解得到的前n_components個最大的奇異值。

     

     二、LDA

    1. 類間距離最大,類內距離最小(核心思想)

    2. LDA的原理,公式推導見西瓜書,這裏主要講一下PCA與LDA的異同點!

    • PCA為非監督降維,LDA為有監督降維PCA希望投影后的數據方差盡可能的大(最大可分性),因為其假設方差越多,則所包含的信息越多;而LDA則希望投影后相同類別的組內方差小,而組間方差大。LDA能合理運用標籤信息,使得投影后的維度具有判別性,不同類別的數據盡可能的分開。舉個簡單的例子,在語音識別領域,如果單純用PCA降維,則可能功能僅僅是過濾掉了噪聲,還是無法很好的區別人聲,但如果有標籤識別,用LDA進行降維,則降維后的數據會使得每個人的聲音都具有可分性,同樣的原理也適用於臉部特徵識別。
    • 所以,可以歸納總結為有標籤就盡可能的利用標籤的數據(LDA),而對於純粹的非監督任務,則還是得用PCA進行數據降維。
    • LDA降維最低可以降維到(類別數-1),而PCA沒有限制

     

    參考資料:https://zhuanlan.zhihu.com/p/77151308?utm_source=qq&utm_medium=social&utm_oi=1095998405318430720

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※台北網頁設計公司這麼多,該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

    ※網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

    ※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

    ※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

    ※教你寫出一流的銷售文案?

  • 用python實現對元素的長截圖

    用python實現對元素的長截圖

    一.目標

    瀏覽網頁的時候,看見哪個元素,就能截取哪個元素當圖片,不管那個元素有多長

     

    二.所用工具和第三方庫

    python ,PIL,selenium

    pycharm

    三.代碼部分

    長截圖整體思路:

    1.獲取元素

    2.移動,截圖,移動,截圖,直到抵達元素的底部

    3.把截圖按照元素所在位置切割,在所有圖片中只保留該元素

    4.拼接

     

    如果driver在環境變量中,那麼不用指定路徑

    b=webdriver.Chrome(executable_path=r"C:\Users\Desktop\chromedriver.exe")#指定一下driver
    b.get("")
    b.maximize_window()#最大化窗口

    打開網站

     

     

     我們可以看見一個ID為maincontent的元素,寬度為850PX,長度為3828PX,這個長度必須使用才能長截圖才能完整截下來

     

    el=b.find_element_by_id("maincontent")#找到元素

    我們還需要一個重要的參數,就是你電腦一次能截取多高的像素

    先用下圖代碼獲取一個圖片

    #fp為存放圖片的地址
    b.get_screenshot_as_file(fp)

     

    也就是說用我電腦上截圖的默認高度為614像素

     

     所以我設置一個變量:

    sc_hight=614

    然後設置一下其他變量

        count = int(el.size["height"] / sc_hight)  # 元素的高度除以你每次截多少就是次數
        start_higth = el.location["y"]  # 元素的初始高度
        max_px = start_higth + (count - 1) * sc_hight  # for循環中最大的px
        last_px = el.size["height"] + start_higth - sc_hight  # 元素最底部的位置
        surplus_px = last_px - max_px  # 剩餘的邊的高度
        img_path = []  # 用來存放圖片地址

    註釋:

    1.count為元素的高度/每次截取的高度,比如這次實例中元素高度為3828PX,我每次截614px,需要6.2次,int之後變成6,也就是截6次,還剩一點,那一點後面再說

    2.start_higth為初始高度,這個沒有什麼可說的

    3.max_px為循環結束后,到達的高度

    4.last_px為元素最底部的高度

    5.surplus_px就是移動6次后,還沒有截取的高度

    屏幕每次移動,移動sc_hight個像素,初始位置為(0,元素的Y值)

        for i in range(0, count):
            js = "scrollTo(0,%s)" % (start_higth + i * sc_hight)  # 用於移動滑輪,每次移動614px,初始值是元素的初始高度
            b.execute_script(js)  # 執行js
            time.sleep(0.5)
            fp = r"C:\Users\wdj\Desktop\%s.png" % i  # 圖片地址,運行的話,改一下
            b.get_screenshot_as_file(fp)  # 屏幕截圖,這裡是截取是完整的網頁圖片,你可以打斷點看一下圖片
            img = Image.open(fp=fp)
            img2 = img.crop((el.location["x"], 0, el.size["width"] + el.location["x"], sc_hight))  # 剪切圖片
            img2.save(fp)  # 保存圖片,覆蓋完整的網頁圖片
            img_path.append(fp)  # 添加圖片路徑
            time.sleep(0.5)
            print(js)
        else:
            js = "scrollTo(0,%s)" % last_px  # 滾動到最後一個位置
            b.execute_script(js)
            fp = r"C:\Users\wdj\Desktop\last.png"
            b.get_screenshot_as_file(fp)
            img = Image.open(fp=fp)
            print((el.location["x"], sc_hight - surplus_px, el.size["width"] + el.location["x"], sc_hight))
            img2 = img.crop((el.location["x"], sc_hight - surplus_px, el.size["width"] + el.location["x"], sc_hight))
            img2.save(fp)
            img_path.append(fp)
            print(js)

    上面是把該元素的在頁面都截完,並且剪切,把圖片保存的路徑放入img_path

    最後一步:把所有截圖都貼到新創建的圖片中

        new_img = Image.new("RGB", (el.size["width"], el.size["height"]))  # 創建一個新圖片,大小為元素的大小
        k = 0
        for i in img_path:
            tem_img = Image.open(i)
            new_img.paste(tem_img, (0, sc_hight * k))  # 把圖片貼上去,間隔一個截圖的距離
            k += 1
        else:
            new_img.save(r"C:\Users\wdj\Desktop\test.png")  # 保存

     

    運行效果圖:


    說明完整的截取下來了

     

     

     

    補充優化:

    如果是個小元素怎麼辦,不用長截圖就能截取的那種

    因為很簡單我就直接貼代碼了

        start_higth = el.location["y"]
        js = "scrollTo(0,%s)" % (start_higth)
        b.execute_script(js)  # 執行js
        time.sleep(0.5)
        fp = r"C:\Users\wdj\Desktop\test.png" # 圖片地址,運行的話,改一下
        b.get_screenshot_as_file(fp)
        img = Image.open(fp=fp)
        img2 = img.crop((el.location["x"], 0, el.size["width"] + el.location["x"], el.size["height"]))  # 剪切圖片
        img2.save(fp)

    效果如下:

     

     

    完整代碼:

    from selenium import webdriver
    from PIL import Image
    import time
    def short_sc(el,b):
        start_higth = el.location["y"]
        js = "scrollTo(0,%s)" % (start_higth)
        b.execute_script(js)  # 執行js
        time.sleep(0.5)
        fp = r"C:\Users\wdj\Desktop\test.png" # 圖片地址,運行的話,改一下
        b.get_screenshot_as_file(fp)
        img = Image.open(fp=fp)
        img2 = img.crop((el.location["x"], 0, el.size["width"] + el.location["x"], el.size["height"]))  # 剪切圖片
        img2.save(fp)
    
    def long_sc(el,b):
        count = int(el.size["height"] / sc_hight)  # 元素的高度除以你每次截多少就是次數
        start_higth = el.location["y"]  # 元素的初始高度
        max_px = start_higth + (count - 1) * sc_hight  # for循環中最大的px
        last_px = el.size["height"] + start_higth - sc_hight  # 元素最底部的位置
        surplus_px = last_px - max_px  # 剩餘的邊的高度
        img_path = []  # 用來存放圖片地址
        for i in range(0, count):
            js = "scrollTo(0,%s)" % (start_higth + i * sc_hight)  # 用於移動滑輪,每次移動614px,初始值是元素的初始高度
            b.execute_script(js)  # 執行js
            time.sleep(0.5)
            fp = r"C:\Users\wdj\Desktop\%s.png" % i  # 圖片地址,運行的話,改一下
            b.get_screenshot_as_file(fp)  # 屏幕截圖,這裡是截取是完整的網頁圖片,你可以打斷點看一下圖片
            img = Image.open(fp=fp)
            img2 = img.crop((el.location["x"], 0, el.size["width"] + el.location["x"], sc_hight))  # 剪切圖片
            img2.save(fp)  # 保存圖片,覆蓋完整的網頁圖片
            img_path.append(fp)  # 添加圖片路徑
            time.sleep(0.5)
            print(js)
        else:
            js = "scrollTo(0,%s)" % last_px  # 滾動到最後一個位置
            b.execute_script(js)
            fp = r"C:\Users\wdj\Desktop\last.png"
            b.get_screenshot_as_file(fp)
            img = Image.open(fp=fp)
            print((el.location["x"], sc_hight - surplus_px, el.size["width"] + el.location["x"], sc_hight))
            img2 = img.crop((el.location["x"], sc_hight - surplus_px, el.size["width"] + el.location["x"], sc_hight))
            img2.save(fp)
            img_path.append(fp)
            print(js)
    
        new_img = Image.new("RGB", (el.size["width"], el.size["height"]))  # 創建一個新圖片,大小為元素的大小
        k = 0
        for i in img_path:
            tem_img = Image.open(i)
            new_img.paste(tem_img, (0, sc_hight * k))  # 把圖片貼上去,間隔一個截圖的距離
            k += 1
        else:
            new_img.save(r"C:\Users\wdj\Desktop\test.png")  # 保存
    
    b=webdriver.Chrome(executable_path=r"C:\Users\wdj\Desktop\chromedriver.exe")#指定一下driver
    b.get("https://www.w3school.com.cn/html/html_links.asp")
    b.maximize_window()#最大化窗口
    # b.get_screenshot_as_file(fp)
    sc_hight=614#你屏幕截圖默認的大小,可以去截一張,去畫圖裡面看看是多少像素,我這裡是614像素
    
    # b.switch_to.frame(b.find_element_by_xpath('//*[@id="intro"]/iframe'))
    el=b.find_element_by_id("maincontent")#找到元素
    if el.size["height"]>sc_hight:
        long_sc(el,b)
    else:
        short_sc(el,b)

    完整代碼

     

    PS:

    有些特殊情況,比如截取的元素在iframe中,直接用driver.switch_to.frame(iframe元素)即可

    或者不是iframe,但是元素有overflow屬性,直接用JS把他的overflow去掉就行

     

     

     

     

     

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

    ※不管是台北網頁設計公司、台中網頁設計公司,全省皆有專員為您服務

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

    ※帶您來看台北網站建置,台北網頁設計,各種案例分享

    ※別再煩惱如何寫文案,掌握八大原則!

  • HtmlSpanner 使用小結 — 安卓解析html

    HtmlSpanner 使用小結 — 安卓解析html

    如何利用 HtmlSpanner解析 HTML格式 的字符串:

    1. GitHub 下載HtmlSpanner項目 https://github.com/NightWhistler/HtmlSpanner

    2. 最好是直接放在java目錄下在,這樣不需要改引用的包路徑

    3.  引入需要的依賴包

        implementation 'net.sourceforge.htmlcleaner:htmlcleaner:2.21'
        implementation 'com.osbcp:cssparser:1.7'
    

      4. 使用方法:

     // 頁面上用於展示 html格式的文本布局
     TextView textView = findViewById(R.id.htmlSpanner);
     // 直接 new一個 HtmlSpanner對象
     HtmlSpanner htmlSpanner = new HtmlSpanner(); // 格式化
     // 解析 html得到 spannable對象
     Spannable spannable1 = htmlSpanner.fromHtml("<span style='color:red'>html格式的文字1</span>");
     // 显示到 TextView上
     textView.setText(spannable1);
    

     5. 在使用中遇到的問題——當富文本中顏色格式是rgb格式,解析失敗

     

     

     

     

     解決思路:

      1. 首先我們解析的是style=’color:rgb(0,255,255)’ 這種格式,於是看源碼覺得 CSSCompiler 這個類很有問題

      2. 找與顏色相關的於是就找到了 parseCSSColor( String colorString ) 這個方法,看起來就是轉換顏色用的

      3. 源碼的寫法如下:(是沒有對於rgb格式的算法,所以不能解析就很合理啦)

      

     

       4. 想法修改:( 遇到 0rgb格式就先處理成我們的 hex格式,這樣不就完美了嘛 )

      5. 工具類代碼如下:

    package com.xxx.xxx.xxx;
    
    public class ColorUtil {
    
         /**
         * rgb 格式的顏色轉 hex格式顏色
         * @param rgb
         * @return
         */
        public static String rgb2hex(String rgb) {
            int r = 0;
            int g = 0;
            int b = 0;
            int left = rgb.indexOf("(");
            int right = rgb.indexOf(")");
            if (left > -1 && right > -1 && right > left) {
                String substring = rgb.substring(left + 1, right);
                String[] split = substring.split(",");
                if (split.length == 3){
                    r = Integer.valueOf(split[0].trim());
                    g = Integer.valueOf(split[1].trim());
                    b = Integer.valueOf(split[2].trim());
                }
            }
            String rFString, rSString, gFString, gSString,
                    bFString, bSString, result;
            int red, green, blue;
            int rred, rgreen, rblue;
            red = r / 16;
            rred = r % 16;
            if (red == 10) rFString = "A";
            else if (red == 11) rFString = "B";
            else if (red == 12) rFString = "C";
            else if (red == 13) rFString = "D";
            else if (red == 14) rFString = "E";
            else if (red == 15) rFString = "F";
            else rFString = String.valueOf(red);
    
            if (rred == 10) rSString = "A";
            else if (rred == 11) rSString = "B";
            else if (rred == 12) rSString = "C";
            else if (rred == 13) rSString = "D";
            else if (rred == 14) rSString = "E";
            else if (rred == 15) rSString = "F";
            else rSString = String.valueOf(rred);
    
            rFString = rFString + rSString;
    
            green = g / 16;
            rgreen = g % 16;
    
            if (green == 10) gFString = "A";
            else if (green == 11) gFString = "B";
            else if (green == 12) gFString = "C";
            else if (green == 13) gFString = "D";
            else if (green == 14) gFString = "E";
            else if (green == 15) gFString = "F";
            else gFString = String.valueOf(green);
    
            if (rgreen == 10) gSString = "A";
            else if (rgreen == 11) gSString = "B";
            else if (rgreen == 12) gSString = "C";
            else if (rgreen == 13) gSString = "D";
            else if (rgreen == 14) gSString = "E";
            else if (rgreen == 15) gSString = "F";
            else gSString = String.valueOf(rgreen);
    
            gFString = gFString + gSString;
    
            blue = b / 16;
            rblue = b % 16;
    
            if (blue == 10) bFString = "A";
            else if (blue == 11) bFString = "B";
            else if (blue == 12) bFString = "C";
            else if (blue == 13) bFString = "D";
            else if (blue == 14) bFString = "E";
            else if (blue == 15) bFString = "F";
            else bFString = String.valueOf(blue);
    
            if (rblue == 10) bSString = "A";
            else if (rblue == 11) bSString = "B";
            else if (rblue == 12) bSString = "C";
            else if (rblue == 13) bSString = "D";
            else if (rblue == 14) bSString = "E";
            else if (rblue == 15) bSString = "F";
            else bSString = String.valueOf(rblue);
            bFString = bFString + bSString;
            result = "#" + rFString + gFString + bFString;
            return result;
        }
    }
    

     

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※台北網頁設計公司這麼多,該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

    ※網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

    ※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

    ※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

    ※教你寫出一流的銷售文案?

  • Redis 的底層數據結構(壓縮列表)

    Redis 的底層數據結構(壓縮列表)

    上一篇我們介紹了 redis 中的整數集合這種數據結構的實現,也談到了,引入這種數據結構的一個很大的原因就是,在某些僅有少量整數元素的集合場景,通過整數集合既可以達到字典的效率,也能使用遠少於字典的內存達到同樣的效果。

    我們本篇介紹的壓縮列表,相信你從他的名字里應該也能看出來,又是一個為了節約內存而設計的數據結構,它的數據結構相對於整數集合來說會複雜了很多,但是整數集合只能允許存儲少量的整型數據,而我們的壓縮列表可以允許存儲少量的整型數據或字符串。

    這是他們之間的一個區別,下面我們來看看這種數據結構。

    一、基本的結構定義

    • ZIPLIST_BYTES:四個字節,記錄了整個壓縮列表總共佔用了多少字節數
    • ZIPLIST_TAIL_OFFSET:四個字節,記錄了整個壓縮列表第一個節點到最後一個節點跨越了多少個字節,通故這個字段可以迅速定位到列表最後一個節點位置
    • ZIPLIST_LENGTH:兩個字節,記錄了整個壓縮列表中總共包含幾個 zlentry 節點
    • zlentry:非固定字節,記錄的是單個節點,這是一個複合結構,我們等下再說
    • 0xFF:一個字節,十進制的值為 255,標誌壓縮列表的結尾

    其中,zlentry 在 redis 中確實有着這樣的結構體定義,但實際上這個結構定義了一堆類似於 length 這樣的字段,記錄前一個節點和自身節點佔用的字節數等等信息,用處不多,而我們更傾向於使用這樣的邏輯結構來描述 zlentry 節點。

    這種結構在 redis 中是沒有具體結構體定義的,請知悉,網上的很多博客文章都直接描述 zlentry 節點是這樣的一種結構,其實是不準確的。

    簡單解釋一下這三個字段的含義:

    • previous_entry_length:每個節點會使用一個或者五個字節來描述前一個節點佔用的總字節數,如果前一個節點佔用的總字節數小於 254,那麼就用一個字節存儲,反之如果前一個節點佔用的總字節數超過了 254,那麼一個字節就不夠存儲了,這裡會用五個字節存儲並將第一個字節的值存儲為固定值 254 用於區分。
    • encoding:壓縮列表可以存儲 16位、32位、64位的整數以及字符串,encoding 就是用來區分後面的 content 字段中存儲於的到底是哪種內容,分別佔多少字節,這個我們等下細說。
    • content:沒什麼特別的,存儲的就是具體的二進制內容,整數或者字符串。

    下面我們細說一個 encoding 具體是怎麼存儲的。

    主要分為兩種,一種是字符串的存儲格式:

    編碼 編碼長度 content類型
    00xxxxxx 一個字節 長度小於 63 的字符串
    01xxxxxx xxxxxxxx 兩個字節 長度小於 16383 的字符串
    10xxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx 五個字節 長度小於 4294967295 的字符串

    content 的具體長度,由編碼除去高兩位剩餘的二進制位表示。

    編碼 編碼長度 content類型
    11000000 一個字節 int16_t 類型的整數
    11010000 一個字節 int32_t 類型的整數
    11100000 一個字節 int64_t 類型的整數
    11110000 一個字節 24 位有符號整數
    11111110 一個字節 8 位有符號整數

    注意,整型數據的編碼是固定 11 開頭的八位二進制,而字符串類型的編碼都是非固定的,因為它還需要通過後面的二進制位得到字符串的長度,稍有區別。

    這就是壓縮列表的基本的結構定義情況,下面我們通過節點的增刪改查方法源碼實現來看看 redis 中具體的實現情況。

    二、redis 的具體源碼實現

    1、ziplistNew

    我們先來看看壓縮列表初始化的方法實現:

    unsigned char *ziplistNew(void) {
        //bytes=2*4+2
        //分配壓縮列表結構所需要的字節數
        //ZIPLIST_BYTES + ZIPLIST_TAIL_OFFSET + ZIPLIST_LENGTH
        unsigned int bytes = ZIPLIST_HEADER_SIZE+1;
        unsigned char *zl = zmalloc(bytes);
        //初始化 ZIPLIST_BYTES 字段
        ZIPLIST_BYTES(zl) = intrev32ifbe(bytes);
        //初始化 ZIPLIST_TAIL_OFFSET
        ZIPLIST_TAIL_OFFSET(zl) = intrev32ifbe(ZIPLIST_HEADER_SIZE);
        //初始化 ZIPLIST_LENGTH 字段
        ZIPLIST_LENGTH(zl) = 0;
        //為壓縮列表最後一個字節賦值 255
        zl[bytes-1] = ZIP_END;
        return zl;
    }

    2、ziplistPush

    接着我們看新增節點的源碼實現:

    unsigned char *ziplistPush(unsigned char *zl, unsigned char *s
            ,unsigned int slen, int where) {
        unsigned char *p;
        //找到待插入的位置,頭部或者尾部
        p = (where == ZIPLIST_HEAD) ? ZIPLIST_ENTRY_HEAD(zl) : ZIPLIST_ENTRY_END(zl);
        return __ziplistInsert(zl,p,s,slen);
    }

    解釋一下 ziplistPush 的幾個入參的含義。

    zl 指向一個壓縮列表的首地址,s 指向一個字符串首地址),slen 指向字符串的長度(如果節點存儲的值是整型,存儲的就是整型值),where 指明新節點的插入方式,頭插亦或尾插。

    ziplistPush 方法的核心是 __ziplistInsert:

    unsigned char *__ziplistInsert(unsigned char *zl, unsigned char *p, unsigned char *s, unsigned int slen) {
        size_t curlen = intrev32ifbe(ZIPLIST_BYTES(zl)), reqlen;
        unsigned int prevlensize, prevlen = 0;
        size_t offset;
        int nextdiff = 0;
        unsigned char encoding = 0;
        long long value = 123456789; 
        zlentry tail;
        //prevlensize 存儲前一個節點長度,本節點使用了幾個字節 1 or 5
        //prelen  存儲前一個節點實際佔用了幾個字節
        if (p[0] != ZIP_END) {
            ZIP_DECODE_PREVLEN(p, prevlensize, prevlen);
        } else {
            unsigned char *ptail = ZIPLIST_ENTRY_TAIL(zl);
            if (ptail[0] != ZIP_END) {
                prevlen = zipRawEntryLength(ptail);
            }
        }
        if (zipTryEncoding(s,slen,&value,&encoding)) {
            //s 指針指向一個整數,嘗試進行一個轉換並得到存儲這個整數佔用了幾個字節
            reqlen = zipIntSize(encoding);
        } else {
            //s 指針指向一個字符串(字符數組),slen 就是他佔用的字節數
            reqlen = slen;
        }
        //當前節點存儲數據佔用 reqlen 個字節,加上存儲前一個節點長度佔用的字節數
        reqlen += zipStorePrevEntryLength(NULL,prevlen);
        //encoding 字段存儲實際佔用字節數
        reqlen += zipStoreEntryEncoding(NULL,encoding,slen);
        //至此,reqlen 保存了存儲當前節點數據佔用字節數和 encoding 編碼佔用的字節數總和
        int forcelarge = 0;
        //當前節點佔用的總字節減去存儲前一個節點字段佔用的字節
        //記錄的是這一個節點的插入會引起下一個節點佔用字節的變化量
        nextdiff = (p[0] != ZIP_END) ? zipPrevLenByteDiff(p,reqlen) : 0;
        if (nextdiff == -4 && reqlen < 4) {
            nextdiff = 0;
            forcelarge = 1;
        }
        //擴容有可能導致 zl 的起始位置偏移,故記錄 p 與 zl 首地址的相對偏差數,事後還原 p 指針指向
        offset = p-zl;
        zl = ziplistResize(zl,curlen+reqlen+nextdiff);
        p = zl+offset;
        if (p[0] != ZIP_END) {
            memmove(p+reqlen,p-nextdiff,curlen-offset-1+nextdiff);
            //把當前節點佔用的字節數存儲到下一個節點的頭部字段
            if (forcelarge)
                zipStorePrevEntryLengthLarge(p+reqlen,reqlen);
            else
                zipStorePrevEntryLength(p+reqlen,reqlen);
    
            //更新 tail_offset 字段,讓他保存從頭節點到尾節點之間的距離
            ZIPLIST_TAIL_OFFSET(zl) =
                intrev32ifbe(intrev32ifbe(ZIPLIST_TAIL_OFFSET(zl))+reqlen);
            zipEntry(p+reqlen, &tail);
            if (p[reqlen+tail.headersize+tail.len] != ZIP_END) {
                ZIPLIST_TAIL_OFFSET(zl) =
                    intrev32ifbe(intrev32ifbe(ZIPLIST_TAIL_OFFSET(zl))+nextdiff);
            }
        } else {
            ZIPLIST_TAIL_OFFSET(zl) = intrev32ifbe(p-zl);
        }
        //是否觸發連鎖更新
        if (nextdiff != 0) {
            offset = p-zl;
            zl = __ziplistCascadeUpdate(zl,p+reqlen);
            p = zl+offset;
        }
        //將節點寫入指定位置
        p += zipStorePrevEntryLength(p,prevlen);
        p += zipStoreEntryEncoding(p,encoding,slen);
        if (ZIP_IS_STR(encoding)) {
            memcpy(p,s,slen);
        } else {
            zipSaveInteger(p,value,encoding);
        }
        ZIPLIST_INCR_LENGTH(zl,1);
        return zl;
    }

    具體細節我不再贅述,總結一下整個插入節點的步驟。

    1. 計算並得到前一個節點的總長度,並判斷得到當前待插入節點保存前一個節點長度的 previous_entry_length 佔用字節數
    2. 根據傳入的 s 和 slen,計算並保存 encoding 字段內容
    3. 構建節點並將數據寫入節點添加到壓縮列表中

    ps:重點要去理解壓縮列表節點的數據結構定義,previous_entry_length、encoding、content 字段,這樣才能比較容易理解節點新增操作的實現。

    三、連鎖更新

    談到 redis 的壓縮列表,就必然會談到他的連鎖更新,我們先引一張圖:

    假設原本 entry1 節點佔用字節數為 211(小於 254),那麼 entry2 的 previous_entry_length 會使用一個字節存儲 211,現在我們新插入一個節點 NEWEntry,這個節點比較大,佔用了 512 個字節。

    那麼,我們知道,NEWEntry 節點插入后,entry2 的 previous_entry_length 存儲不了 512,那麼 redis 就會重分配內存,增加 entry2 的內存分配,並分配給 previous_entry_length 五個字節存儲 NEWEntry 節點長度。

    看似沒什麼問題,但是如果極端情況下,entry2 擴容四個字節后,導致自身佔用字節數超過 254,就會又觸發后一個節點的內存佔用空間擴大,非常極端情況下,會導致所有的節點都擴容,這就是連鎖更新,一次更新導致大量甚至全部節點都更新內存的分配。

    如果連鎖更新發生的概率很高的話,壓縮列表無疑就會是一個低效的數據結構,但實際上連鎖更新發生的條件是非常苛刻的,其一是需要大量節點長度小於 254 連續串聯連接,其二是我們更新的節點位置恰好也導致后一個節點內存擴充更新。

    基於這兩點,且少量的連鎖更新對性能是影響不大的,所以這裏的連鎖更新對壓縮列表的性能是沒有多大的影響的,可以忽略,但需要知曉。

    同樣的,如果覺得我寫的對你有點幫助的話,順手點一波關注吧,也歡迎加作者微信深入探討,我們逐漸開始走近 redis 比較實用性的相關內容了,盡請關注。

    關注公眾不迷路,一個愛分享的程序員。


    公眾號回復「1024」加作者微信一起探討學習!


    每篇文章用到的所有案例代碼素材都會上傳我個人 github





    歡迎來踩!

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※台北網頁設計公司這麼多,該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

    ※網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

    ※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

    ※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

    ※教你寫出一流的銷售文案?