linux虛擬網絡基礎

1 Device

在linux裏面devic(設備)與傳統網絡概念里的物理設備(如交換機、路由器)不同，Linux所說的設備，其背後指的是一個類似於數據結構、內核模塊或設備驅動這樣的含義。就是說device可能只是軟件系統里的一個驅動，一個函數接口。

2 Tap

Tap位於二層數據鏈路層，tun位於三層網絡層，兩者在linux里的函數結構幾乎一致，除了一個flag值區分tap/tun。在linux中二層特指以太網（Ethernet）(傳統網絡里二層分Ethernet,P2P,HDLC,FR,ATM)，因此有時tap也叫“虛擬以太設備”。有意思的是linux創建tap需要用到tun模塊。Linux創建tap/tun都使用tun模塊。

 

3 Namespace

Namespace類似傳統網絡里的VRF，與VRF不同的是：VRF做的是網絡層三層隔離。而namespace隔離的更徹底，它做的是整個協議棧的隔離，隔離的資源包括：UTS(UnixTimesharing  System的簡稱，包含內存名稱、版本、 底層體繫結構等信息)、IPS(所有與進程間通信（IPC）有關的信息)、mnt(當前裝載的文件系統)、PID(有關進程ID的信息)、user(資源配額的信息)、net(網絡信息)。

從網絡角度看一個namespace提供了一份獨立的網絡協議棧（網絡設備接口、IPv4/v6、IP路由、防火牆規則、sockets等），而一個設備（Linux Device）只能位於一個namespace中，不同namespace中的設備可以利用vethpair進行橋接。

 

4 veth pair

veth pair不是一個設備，而是一對設備，以連接兩個虛擬以太端口。操作vethpair，需要跟namespace一起配合，不然就沒有意義。如圖

 

5 Bridge

在Linux的語境里，Bridge（網橋）與Switch（交換機）是一個概念。因為一對veth pair只能連接兩台device，因此如果需要多台設備互聯則需要bridge。

如圖：4個namespace，每個namespace都有一個tap，每個tap與網橋vb1的tap組成一對veth pair，這樣，這4個namespace就可以二層互通了。

 

6 Router

Linux創建Router並沒有像創建虛擬Bridge那樣，有一個直接的命令brctl，而且它間接的命令也沒有，不能創建虛擬路由器……因為它就是路由器（Router) !

如圖：我們需要在router(也就是我們的操作系統linux上增加去往各NS的路由)。

 

7 tun

tun是一個網絡層(IP)的點對點設備，它啟用了IP層隧道功能。Linux原生支持的三層隧道。支持隧道情況：ipip(ipv4 in ipv4)、gre(ipv4/ipv6 over ipv4)、sit(ipv6 over ipv4)、isatap(ipv6/ipv4隧道)、vti(ipsec接口)。

學過傳統網絡GRE隧道的人更容易理解，如圖：

NS1的tun1的ip 10.10.10.1與NS2的tun2的ip 10.10.20.2建立tun

NS1的tun的ip是10.10.10.1，隧道的外層源ip是192.168.1.1，目的ip是192.168.2.1，是不是跟GRE很像。

 

8 iptable

我們通常把iptable說成是linux的防火牆，實際上這種說法並不準確。實際上iptable只是一個運行在用戶空間的命令行工具，真正實現防火牆功能的是內核空間的netfilter模塊。

這裏我們先知道防火牆執行模塊netfilter位於內核空間，命令行iptable位於用戶空間。我們在通過iptable配置的防火牆策略(包括NAT)會在netfilter執行。

iptables有5個鏈：PREROUTING,INPUT,FORWARD,OUTPUT,POSTROUTING

l  PREROUTING：報文進入網絡接口尚未進入路由之前的時刻；

l  INPUT：路由判斷是本機接收的報文，準備從內核空間進入到用戶空間的時刻；

l  FORWARD：路由判斷不是本機接收的報文，需要路由轉發，路由轉發的那個時刻；

l  OUTPUT：本機報文需要發出去 經過路由判斷選擇好端口以後，準備發送的那一刻；

l  POSTROUTING：FORWARD/OUTPUT已經完成，報文即將出網絡接口的那一刻。

 DNAT用的是PREROUTING，修改的是目的地址，SNAT用的是POSTROUTING,修改的是源地址。

Iptable有5個表:filter,nat,mangle,raw, security，raw表和security表不常用。主流文檔都是說5鏈4表，沒有包括security表。

l  Raw表——決定數據包是否被狀態跟蹤機制處理

l  Mangle表——修改數據包的服務類型、TTL、並且可以配置路由實現QOS

l  Nat表——用於網絡地址轉換（IP、端口）

l  filter表——過濾數據包

l  security 表（用於強制訪問控制網絡規則，例如：SELinux）

4個表的優先級由高到低的順序為:raw–>mangle–>nat–>filter。RAW表,在某個鏈上,RAW表處理完后,將跳過NAT表和 ip_conntrack處理,即不再做地址轉換和數據包的鏈接跟蹤處理了。RAW表可以應用在那些不需要做nat的情況下，以提高性能。如大量訪問的web服務器，可以讓80端口不再讓iptables做數據包的鏈接跟蹤處理，以提高用戶的訪問速度。

下面講下數據包流向與處理：

1. 如果是外部訪問的目的是本機，比如用戶空間部署了WEB服務，外部來訪問。數據包從外部進入網卡—–>PREROUTING處理—–>INPUT處理—–>到達用戶空間程序接口，程序處理完成后發出—–>OUTPUT處理—–>POSTROUTING處理。每個處理點都有對應的表，表的處理順序按照raw–>mangle–>nat–>filter處理。
2. 如果用戶訪問的目的不是本機，linux只是一个中轉(轉發)設備，此時需要開啟ip forward功能，數據流就是進入網卡—–> PREROUTING處理—–> FORWARD處理—–> POSTROUTING處理。

 

8.2 NAT

Netfilter中的NAT有三個點做處理，

(1)   NAT-PREROUTING (DNAT)

數據報文進入PREROUTING，NAT模塊就會處理，比如用戶空間的WEB服務私網地址192.168.0.1，對外提供公網ip是220.1.1.1。

當外部ip訪問220.1.1.1時，PREROUTING接受數據包，NAT模塊處理將目的ip 220.1.1.1轉換為私網ip192.168.0.1，這就是DNAT。

(2)   NAT-POSTROUTING (SNAT)

用戶空間應用程序訪問外部網絡，比如用戶空間應用程序訪問114.114.114.144，私網ip 192.168.0.1，此時數據包流經POSTROUTING，NAT模塊會處理，將192.168.0.1轉換為220.2.2.2，對於目的ip114.114.114.114來說，就是220.2.2.2訪問它，這就是SNAT。

(3)   NAT-OUTPUT (DNAT)

我們把內核空間想象成一台防火牆，防火牆自身對外發送報文訪問外部時，就在OUTPUT做DNAT，此時不需要再POSTROUTING點再做NAT。因為此時從OUTPUT出來的源IP已經是公網地址了

8.3  Firewall

防火牆根據規則執行accept/reject動作，防火牆規則的元素如下：

入接口、出接口、協議、源地址/子網、目的地址/子網、源端口、目的端口。

Netfilter中的Firewall會在這三個點進行處理：INPUT/FORWARD/OUTPUT

8.4 Mangle

mangle表主要用於修改數據包的ToS(  Type of Service，服務類型）、 TTL(Time to Live，生存周期）以及為數據包設置Mark標記，以實現QoS(Qualityof Service，服務質量）調整以及策略路由等應用。Netfilter每個點都可以做mangle。

9 總結

tap、tun、vethpair在Linux中都被稱為設備，但是在與日常概念的類比中，常常被稱作接口。而bridge和router這些日常稱為設備的再linux中反而不稱為設備。linux利用namespace做隔離，Bridge提供二層轉發功能，Router提供三層轉發功能。Router還常常藉助iptable提供SNAT/DNAT功能。Bridge也常常藉助iptable提供Firewall功能。

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

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

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

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

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

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

※超省錢租車方案

前言

對於單線程來說，事件循環可以說是重中之重了，它為任務分配不同的優先級，井然有序的調度。讓js解析，用戶交互，頁面渲染等互不衝突，各司其職。

我們書寫的代碼無時無刻都在和事件循環打交道，要想寫出更流暢，我們就必須深入了解事件循環，下面我們將從規範中翻譯和解讀整個流程。

以下內容來自whatwg文檔，均為個人理解，若有不對，煩請指出，我會第一時間修改，避免誤導他人！

正文

為了協調用戶操作，js執行，頁面渲染，網絡請求等事件，每個宿主中，存在事件循環這樣的角色，並且該角色在當前宿主中是唯一的。

簡單解釋一下宿主：宿主是一個ECMAScript執行上下文，一般包含執行上下文棧，運行時執行環境，宿主記錄和一個執行線程，除了這個執行線程外，其他的專屬於當前宿主。例如，某些瀏覽器在不同的tabs使用同一個執行線程。

不僅如此，事件循環又存於在各個不同場景，有瀏覽器環境下的，worker環境下的和Worklet環境下的。

Worklet是一個輕量級的web worker，可以讓開發者訪問更底層的渲染工作線，也就是說你可以通過Worklet去干預瀏覽器的渲染環境。

提到了worklet，那就順便看一個例子(需開啟服務，不要以file協議運行)，通過這個例子，可以看到事件循環不同階段觸發了什麼鈎子函數：

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Document</title>
        <style>
            .fancy {
                background-image: paint(headerHighlight);
                display: layout(sample-layout);
                background-color: green;
            }
        </style>
    </head>
    <body>
        <h1 class="fancy">My Cool Header</h1>
        <script>
            console.log('開始');
            CSS.paintWorklet.addModule('./paint.js');
            CSS.layoutWorklet.addModule('./layout.js');

            requestAnimationFrame(() => {
                console.log('requestAnimationFrame');
            });
            Promise.resolve().then(() => {
                console.log('微任務');
            });
            setTimeout(function () {
                document.querySelector('.fancy').style.height = '150px';
                ('translateZ(0)');

                Promise.resolve().then(() => {
                    console.log('新一輪的微任務');
                });
                requestAnimationFrame(() => {
                    console.log('新一輪的requestAnimationFrame');
                });
            }, 2000);
            console.log(2);
        </script>
    </body>
</html>

// paint.js
registerPaint(
    'headerHighlight',
    class {
        static get contextOptions() {
            console.log('contextOptions');
            return {alpha: true};
        }

        paint(ctx) {
            console.log('paint函數');
        }
    }
);

// ==========================分割線

// layout.js
registerLayout(
    'sample-layout',
    class {
        async intrinsicSizes(children, edges, styleMap) {}

        async layout(children, edges, constraints, styleMap, breakToken) {
            console.log('layout階段');
        }
    }
);

事件循環有一個或多個Task隊列，每個Task隊列都是Task的一個集合。其中Task不是指我們的某個函數，而是一個上下文環境，結構如下:

• step：一系列任務將要執行的步驟
• source：任務來源，常用來對相關任務進行分組和系列化
• document：與當前任務相關的document對象，如果是非window環境則為null
• 環境配置對象：在任務期間追蹤記錄任務狀態

這裏的Task隊列不是Task，是一個集合，因為取出一個Task隊列中的Task是選擇一個可執行的Task，而不是出隊操作。

微任務隊列是一個入對出對的隊列。

這裏說明一下，Task隊列為什麼有多個，因為不同的Task隊列有不同的優先級，進而進行次序排列和調用，有沒有感覺react的fiber和這個有點類似？

舉個例子，Task隊列可以是專門負責鼠標和鍵盤事件的，並且賦予鼠標鍵盤隊列較高的優先級，以便及時響應用戶操作。另一個Task隊列負責其他任務源。不過也不要餓死任何一個task，這個後續處理模型中會介紹。

Task封裝了負責以下任務的算法:

• Events: 由專門的Task在特定的EventTarget(一個具有監聽訂閱模式列表的對象)上分發事件對象
• Parsing: html解析器標記一個或多個字節，並處理所有生成的結果token
• Callbacks: 由專門的Task觸發回調函數
• Using a resource: 當該算法獲取資源的時候，如果該階段是以非阻塞方式發生，那麼一旦部分或者全部資源可用，則由Task進行後續處理
• Reacting to DOM manipulation: 通過dom操作觸發的任務，例如插入一個節點到document

事件循環有一個當前運行中的Task，可以為null，如果是null的話，代表着可以接受一個新的Task(新一輪的步驟)。

事件循環有微任務隊列，默認為空，其中的任務由微任務排隊算法創建。

事件循環有一個執行微任務檢查點，默認為false，用來防止微任務死循環。

微任務排隊算法:

1. 如果未提供event loop，設置一個隱式event loop。
2. 如果未提供document，設置一個隱式document.
3. 創建一個Task作為新的微任務
4. 設置setp、source、document到新的Task上
5. 設置Task的環境配置對象為空集
6. 添加到event loop的微任務隊列中

微任務檢查算法：

1. 如果微任務檢查標誌為true，直接return
2. 設置微任務檢查標誌為true
3. 如果微任務隊里不為空(也就是說微任務添加的微任務也會在這個循環中出現，直到微任務隊列為空)：
   1. 從微任務隊列中找出最老的任務(防餓死)
   2. 設置當前執行任務為這個最老的任務
   3. 執行
   4. 重置當前執行任務為null
4. 通知環境配置對象的promise進行reject操作
5. 清理indexdb事務(不太明白這一步，如果有讀者了解，煩請點撥一下)
6. 設置微任務檢查標誌為false

處理模型

event loop會按照下面這些步驟進行調度：

1. 找到一個可執行的Task隊列，如果沒有則跳轉到下面的微任務步驟
2. 讓最老的Task作為Task隊列中第一個可執行的Task，並將其移除
3. 將最老的Task作為event loop的可執行Task
4. 記錄任務開始時間點
5. 執行Task中的setp對應的步驟(上文中Task結構中的step)
6. 設置event loop的可執行任務為null
7. 執行微任務檢查算法
8. 設置hasARenderingOpportunity(是否可以渲染的flag)為false
9. 記住當前時間點
10. 通過下面步驟記錄任務持續時間
    1. 設置頂層瀏覽器環境為空
    2. 對於每個最老Task的腳本執行環境配置對象，設置當前的頂級瀏覽器上下文到其上
    3. 報告消耗過長的任務，並附帶開始時間，結束時間，頂級瀏覽器上下文和當前Task
11. 如果在window環境下，會根據硬件條件決定是否渲染，比如刷新率，頁面性能，頁面是否在後台，不過渲染會定期出現，避免頁面卡頓。值得注意的是，正常的刷新率為60hz，大概是每秒60幀，大約16.7ms每幀，如果當前瀏覽器環境不支持這個刷新率的話，會自動降為30hz，而不是丟幀。而李蘭其在後台的時候，聰明的瀏覽器會將這個渲染時機降為每秒4幀甚至更低，事件循環也會減少(這就是為什麼我們可以用setInterval來判斷時候能打開其他app的判斷依據的原因)。如果能渲染的話會設置hasARenderingOpportunity為true。

除此之外，還會在觸發resize、scroll、建立媒體查詢、運行css動畫等，也就是說瀏覽器幾乎大部分用戶操作都發生在事件循環中，更具體點是事件循環中的ui render部分。之後會進行requestAnimationFrame和IntersectionObserver的觸發，再之後是ui渲染

1. 如果下麵條件都成立，那麼執行空閑階段算法，對於開發者來說就是調用window.requestIdleCallback方法
   1. 在window環境下
   2. event loop中沒有活躍的Task
   3. 微任務隊列為空
   4. hasARenderingOpportunity為false

借鑒網上的一張圖來粗略表示下整個流程

小結

上面就是整個事件循環的流程，瀏覽器就是按照這個規則一遍遍的執行，而我們要做的就是了解並適應這個規則，讓瀏覽器渲染出性能更高的頁面。

比如:

1. 非首屏相關性能打點可以放到idle callback中執行，減少對頁面性能的損耗
2. 微任務中遞歸添加微任務會導致頁面卡死，而不是隨着事件循環一輪輪的執行
3. 更新元素布局的最好時機是在requestAnimateFrame中
4. 盡量避免頻繁獲取元素布局信息，因為這會觸發強制layout(哪些屬性會導致強制layout？)，影響頁面性能
5. 事件循環有多個任務隊列，他們互不衝突，但是用戶交互相關的優先級更高
6. resize、scroll等會伴隨事件循環中ui渲染觸發，而不是根據我們的滾動觸發，換句話說，這些操作自帶節流
7. 等等，歡迎補充

最後感謝大家閱讀，歡迎一起探討！

提前祝大家端午節nb

參考

composite

深入探究 eventloop 與瀏覽器渲染的時序問題

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

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

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

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

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

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

Spark Streaming支持實時數據流的可擴展（scalable）、高吞吐（high-throughput）、容錯（fault-tolerant）的流處理（stream processing）。

 

                                                    架構圖

 

特性如下：

 

• 可線性伸縮至超過數百個節點；

• 實現亞秒級延遲處理；

• 可與Spark批處理和交互式處理無縫集成；

• 提供簡單的API實現複雜算法；

• 更多的流方式支持，包括Kafka、Flume、Kinesis、Twitter、ZeroMQ等。

 

原理

 

Spark在接收到實時輸入數據流后，將數據劃分成批次（divides the data into batches），然後轉給Spark Engine處理，按批次生成最後的結果流（generate the final stream of results in batches）。 

 

 

API

 

DStream

 

DStream（Discretized Stream，離散流）是Spark Stream提供的高級抽象連續數據流。

 

• 組成：一個DStream可看作一個RDDs序列。

• 核心思想：將計算作為一系列較小時間間隔的、狀態無關的、確定批次的任務，每個時間間隔內接收的輸入數據被可靠存儲在集群中，作為一個輸入數據集。

 

 

• 特性：一個高層次的函數式編程API、強一致性以及高校的故障恢復。

• 應用程序模板：

• 模板1

• 模板2

 

WordCount示例

 

 

Input DStream

 

Input DStream是一種從流式數據源獲取原始數據流的DStream，分為基本輸入源（文件系統、Socket、Akka Actor、自定義數據源）和高級輸入源（Kafka、Flume等）。

 

• Receiver：

• 每個Input DStream（文件流除外）都會對應一個單一的Receiver對象，負責從數據源接收數據並存入Spark內存進行處理。應用程序中可創建多個Input DStream并行接收多個數據流。

• 每個Receiver是一個長期運行在Worker或者Executor上的Task，所以會佔用該應用程序的一個核（core）。如果分配給Spark Streaming應用程序的核數小於或等於Input DStream個數（即Receiver個數），則只能接收數據，卻沒有能力全部處理（文件流除外，因為無需Receiver）。

• Spark Streaming已封裝各種數據源，需要時參考官方文檔。

 

Transformation Operation

 

• 常用Transformation

 

* map(func) ：對源DStream的每個元素，採用func函數進行轉換，得到一個新的DStream；

* flatMap(func)：與map相似，但是每個輸入項可用被映射為0個或者多個輸出項；

* filter(func)：返回一個新的DStream，僅包含源DStream中滿足函數func的項；

* repartition(numPartitions)：通過創建更多或者更少的分區改變DStream的并行程度；

* union(otherStream)：返回一個新的DStream，包含源DStream和其他DStream的元素；

* count()：統計源DStream中每個RDD的元素數量；

* reduce(func)：利用函數func聚集源DStream中每個RDD的元素，返回一個包含單元素RDDs的新DStream；

* countByValue()：應用於元素類型為K的DStream上，返回一個（K，V）鍵值對類型的新DStream，每個鍵的值是在原DStream的每個RDD中的出現次數；

* reduceByKey(func, [numTasks])：當在一個由(K,V)鍵值對組成的DStream上執行該操作時，返回一個新的由(K,V)鍵值對組成的DStream，每一個key的值均由給定的recuce函數（func）聚集起來；

* join(otherStream, [numTasks])：當應用於兩個DStream（一個包含（K,V）鍵值對,一個包含(K,W)鍵值對），返回一個包含(K, (V, W))鍵值對的新DStream；

* cogroup(otherStream, [numTasks])：當應用於兩個DStream（一個包含（K,V）鍵值對,一個包含(K,W)鍵值對），返回一個包含(K, Seq[V], Seq[W])的元組；

* transform(func)：通過對源DStream的每個RDD應用RDD-to-RDD函數，創建一個新的DStream。支持在新的DStream中做任何RDD操作。

 

• updateStateByKey(func)

• updateStateByKey可對DStream中的數據按key做reduce，然後對各批次數據累加

• WordCount的updateStateByKey版本

 

• transform(func)

• 通過對原DStream的每個RDD應用轉換函數，創建一個新的DStream。

• 官方文檔代碼舉例

 

• Window operations

• 窗口操作：基於window對數據transformation（個人認為與Storm的tick相似，但功能更強大）。

• 參數：窗口長度（window length）和滑動時間間隔（slide interval）必須是源DStream批次間隔的倍數。

• 舉例說明：窗口長度為3，滑動時間間隔為2；上一行是原始DStream，下一行是窗口化的DStream。

• 常見window operation

有狀態轉換包括基於滑動窗口的轉換和追蹤狀態變化(updateStateByKey)的轉換。

基於滑動窗口的轉換

* window(windowLength, slideInterval) 基於源DStream產生的窗口化的批數據，計算得到一個新的DStream；

* countByWindow(windowLength, slideInterval) 返迴流中元素的一個滑動窗口數；

* reduceByWindow(func, windowLength, slideInterval) 返回一個單元素流。利用函數func聚集滑動時間間隔的流的元素創建這個單元素流。函數func必須滿足結合律，從而可以支持并行計算；

* reduceByKeyAndWindow(func, windowLength, slideInterval, [numTasks]) 應用到一個(K,V)鍵值對組成的DStream上時，會返回一個由(K,V)鍵值對組成的新的DStream。每一個key的值均由給定的reduce函數(func函數)進行聚合計算。注意：在默認情況下，這個算子利用了Spark默認的併發任務數去分組。可以通過numTasks參數的設置來指定不同的任務數；

* reduceByKeyAndWindow(func, invFunc, windowLength, slideInterval, [numTasks]) 更加高效的reduceByKeyAndWindow，每個窗口的reduce值，是基於先前窗口的reduce值進行增量計算得到的；它會對進入滑動窗口的新數據進行reduce操作，並對離開窗口的老數據進行“逆向reduce”操作。但是，只能用於“可逆reduce函數”，即那些reduce函數都有一個對應的“逆向reduce函數”（以InvFunc參數傳入）；

* countByValueAndWindow(windowLength, slideInterval, [numTasks]) 當應用到一個(K,V)鍵值對組成的DStream上，返回一個由(K,V)鍵值對組成的新的DStream。每個key的值都是它們在滑動窗口中出現的頻率。

• 官方文檔代碼舉例 

 

• join(otherStream, [numTasks])

• 連接數據流

• 官方文檔代碼舉例1

• 官方文檔代碼舉例2

 

Output Operation

 

 

緩存與持久化

 

• 通過persist()將DStream中每個RDD存儲在內存。

• Window operations會自動持久化在內存，無需显示調用persist()。

• 通過網絡接收的數據流（如Kafka、Flume、Socket、ZeroMQ、RocketMQ等）執行persist()時，默認在兩個節點上持久化序列化后的數據，實現容錯。

 

Checkpoint

 

• 用途：Spark基於容錯存儲系統（如HDFS、S3）進行故障恢復。

• 分類：

• 元數據檢查點：保存流式計算信息用於Driver運行節點的故障恢復，包括創建應用程序的配置、應用程序定義的DStream operations、已入隊但未完成的批次。

• 數據檢查點：保存生成的RDD。由於stateful transformation需要合併多個批次的數據，即生成的RDD依賴於前幾個批次RDD的數據（dependency chain），為縮短dependency chain從而減少故障恢復時間，需將中間RDD定期保存至可靠存儲（如HDFS）。

• 使用時機：

• Stateful transformation：updateStateByKey()以及window operations。

• 需要Driver故障恢復的應用程序。

• 使用方法

• Stateful transformation

streamingContext.checkpoint(checkpointDirectory)

 

• 需要Driver故障恢復的應用程序（以WordCount舉例）：如果checkpoint目錄存在，則根據checkpoint數據創建新StreamingContext；否則（如首次運行）新建StreamingContext。

 

• checkpoint時間間隔

• 方法：

dstream.checkpoint(checkpointInterval)

 

• 原則：一般設置為滑動時間間隔的5-10倍。

• 分析：checkpoint會增加存儲開銷、增加批次處理時間。當批次間隔較小（如1秒）時，checkpoint可能會減小operation吞吐量；反之，checkpoint時間間隔較大會導致lineage和task數量增長。

 

性能調優

 

降低批次處理時間

 

• 數據接收并行度

• 增加DStream：接收網絡數據（如Kafka、Flume、Socket等）時會對數據反序列化再存儲在Spark，由於一個DStream只有Receiver對象，如果成為瓶頸可考慮增加DStream。

• 設置“spark.streaming.blockInterval”參數：接收的數據被存儲在Spark內存前，會被合併成block，而block數量決定了Task數量；舉例，當批次時間間隔為2秒且block時間間隔為200毫秒時，Task數量約為10；如果Task數量過低，則浪費了CPU資源；推薦的最小block時間間隔為50毫秒。

• 顯式對Input DStream重新分區：在進行更深層次處理前，先對輸入數據重新分區。

inputStream.repartition(<number of partitions>)

 

• 數據處理并行度：reduceByKey、reduceByKeyAndWindow等operation可通過設置“spark.default.parallelism”參數或顯式設置并行度方法參數控制。

• 數據序列化：可配置更高效的Kryo序列化。

 

設置合理批次時間間隔

 

• 原則：處理數據的速度應大於或等於數據輸入的速度，即批次處理時間大於或等於批次時間間隔。

• 方法：

• 先設置批次時間間隔為5-10秒以降低數據輸入速度；

• 再通過查看log4j日誌中的“Total delay”，逐步調整批次時間間隔，保證“Total delay”小於批次時間間隔。

 

內存調優

 

• 持久化級別：開啟壓縮，設置參數“spark.rdd.compress”。

• GC策略：在Driver和Executor上開啟CMS。

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

【其他文章推薦】

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

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※南投搬家公司費用需注意的眉眉角角，別等搬了再說!

※新北清潔公司,居家、辦公、裝潢細清專業服務

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

前一陣字節跳動程序員，年僅 28 歲的郭宇財務自由，宣布退休的消息在網上火了一把，這個事情大家應該都知道了，細節就不多說了。

我剛看了這個新聞之後，起初內心出現的幾個關鍵詞是：卧槽、牛、羡慕……在意識到瞎感慨、羡慕沒啥用之後，我心裏不禁有個疑問：他的錢是怎麼來的？

我找在字節上班的朋友打聽了一下，據說郭同學近幾年投資賺了錢。當然還有網上大部分傳的，郭同學的發家致富是因為有字節跳動的期權，期權的價值隨着字節的估值翻上了天。

說到期權，估計很多人對期權不太清楚，除了關注熱點，我們還得學點知識對不對。今天我就和大家聊聊期權，省的將來大家遇到類似機會了，你一臉懵逼，甚至掉坑裡。

同時，因為我不是專業的，只是接觸過，所以講的不對、不嚴謹的，大家多擔待。

講期權之前，我們先接着上面說完郭同學的期權。

郭同學 2014 年加入字節，當時字節估值 5 億美元，現在字節估值 1000 億美元以上，估值妥妥的漲了 200 倍啊。如果當時有 10 萬期權，現在值 2000 萬；如果有 100 萬期權，現在值 2 億。就算考慮上後幾輪字節融資帶來的稀釋，打個折扣，那也是一筆不小的財富啊。

那麼郭同學有多少期權呢？說實話我也不知道，引用幾年前他和同學的對話，大家自己猜測吧。

郭同學的事說完了，我們繼續說期權。

1. 什麼是期權？

先舉個例子：

比如公司承諾你說，4 年之後，可以按每股 10 塊錢的價格，購買公司 1 萬份股票。期權的“期”就是指 4 年時間；期權的“權”就是 10 塊錢購買 1 萬份股票的權利。

等 4 年之後，如果公司的股票價格漲到了 100 塊，你依然可以用 10 塊錢的價格購買 1 萬份股票。花 10 萬買的股票就值 100 萬了，轉手賣出去之後，你能賺 90 萬。恭喜你！

另外一種可能是，如果 4 年後公司股票價格掉到 8 塊錢，這時候你肯定就不會按 10 塊錢價格購買股票了，不行使這個權利你也不會虧錢。

期權在國內互聯網公司不算少見，這當初是從硅谷那些互聯網公司學來的。

公司為了留住你，同時也為了長期激勵你，期權通常不會一下都給你，按上面的例子來說，4 年時間，可能每滿一年給你 1/4 數量的期權，或者是按月給。這也是為什麼有人把期權稱為“金手銬”。

2. 離職了期權怎麼辦？

上面的例子繼續展開說，如果乾滿了兩年，還沒幹滿四年，離職了期權怎麼辦？

這種情況，需要看之前你和公司怎麼約定的。通常有 3 種方式：

1. 干滿 2 年，給了 50%，那麼就可以對這 50% 的期權行權，然後帶走，等着公司上市后變成股票。
2. 公司回購你這 50% 的期權。
3. 被公司收回，什麼都沒有。

說一個我自己的例子，我在 2008 年打工的時候，公司給過我期權，數量不多，具體的價格、時間已經完全記不住了，後來離職的時候，期權都被公司收回了。當時對期權完全不懂，想着收回就收回唄。後來那家公司發展的不是很好，即使我堅守到現在，那些期權啥也兌現不了。否則，我現在腸子都要悔青了。

3. 有期權是不是肯定拿低工資？

這個不一定。比如小米早期，就有高工資低期權、低工資高期權兩種方案供員工選擇。

如果你覺得老闆靠譜、公司有希望，同時少拿點工資也不影響自己的生活，當然可以選擇低工資高期權。博一把，一旦成了，那麼期權帶來的財富肯定遠超過工資。

當然選擇高工資低期權，也能理解，畢竟生活不易，很多人都要養家糊口。而且創業公司的成功率非常低，期權最後能兌現都是小概率事件。萬一期權不能兌現，除了損失了工資，時間成本和機會成本也不小。

但是大家要小心，有的公司會用期權給你畫個大大的餅，刻意把你的工資壓到非常低。如果老闆真有誠意，起碼會給你開一個可接受的工資。

期權是為了留住和激勵優秀員工的，工資太低，優秀員工的忠誠度、穩定性怎麼保證？

4. 白紙黑字

如果你遇到的老闆是天天把分期權掛在嘴上，但是遲遲不和你簽協議，那你要小心了。無論怎樣，任何口頭承諾都沒有任何意義。

一定要白紙黑字落在協議上，特別是行權時間、價格、數量、期限、公司回購價格等等要寫到合同協議里，省的將來產生糾紛。

當然，最省心的還是找一個靠譜的公司，比如：

1. 公司的創始人信用好，如果他之前兌現過期權，那就更好了。
2. 是著名投資機構投資的公司。
3. 過往的融資都很順利，而且每一輪融資公司估值都漲的很快。
4. 能吸引很多優秀的人才加入，也能側面說明這家公司比較健康。大家都眼瞎的概率還是很小的。

寫完以上幾點，我不禁想到了曾經的樂視，好像能滿足以上好幾點……

5. 期權的其他知識

進入公司差一年，為什麼期權相差很多？
拿字節跳動來說，入職時間差一年，可能期權差一個數量級。發展越迅猛的公司，這個差距越大，早期公司估值低，越早加入越有優勢。

期權怎麼變現？
通常除了公司回購，只能等上市了。

員工是否可以賣掉期權？
一般來說，員工是不能出售期權的。如果員工可以出售期權，只能賣給你的公司。

6. 乾股

再說一下乾股。

有些技術大牛在加入創業公司的時候，創始人可能會對技術大牛說：你出技術，不用出錢了，我白給你 20% 的乾股（或叫技術股）。

乾股聽起來好像挺好，大家一起干，不用出錢，還可以分紅。

但是通常乾股是虛股，只有分紅的權利，沒有參与經營、決策的權利，往往也不能轉讓。

乾股是不規範的叫法，由於技術合伙人沒有實際出資，也沒經過工商登記，有可能忙活半天，最後你的名字都不會出現在股東名單里。如果之前也沒簽過協議，這麼不清不楚的，將來會不會被踢出局，都不好說。

最穩妥的辦法還是去工商局登記變更，把乾股變成法律上認可的股權。

最後

以上就是這篇文章的主要內容，估計很多讀者會覺得，期權、股票這些離自己太遠，和自己關係不大。

千萬別這麼想！

第一、現在互聯網行業給股票、期權的公司不算少見，提前儲備點知識，萬一以後談 offer 的時候出現這些字眼，你也不至於啥也不懂。

第二、覺得自己現在還很菜，公司的股票、期權都是給核心員工的，輪不到自己。現在菜又怎樣，誰不是由菜變強的，現在沒有股票、期權，不代表以後也拿不到。

第三、在工資不降低或者可接受的範圍內，我建議大家拿股票、期權，萬一哪天自己就莫名其妙的發財了呢。

第三點大家一定要謹慎，再次提醒一下你們，別為了股票、期權就接受一個特別低的工資，這塊我教訓深刻。

就寫這麼多吧，希望這篇掃盲文章能讓你們有收穫。起碼我旁邊的碼農二毛又有收穫了：

二毛說：四哥你這麼一說，我明白了，我現在就算能跳槽進字節，就算給我期權，現在太晚了，字節估值都這麼高了，別說暴富，估計連湯都喝不上了。我應該怎麼辦呢？

我說：打開你的炒股軟件……

二毛說：我明白了，四哥你是讓我買字節的股票，拿着股票也可以跟着字節市值上漲賺錢。

我說：呸，字節還沒上市，你買毛線。我的意思是，如果幾年前你能拿出來選股票的勁頭來分析、選擇出一家潛力公司，早跳槽過去堅持到現在，估計你也發財了。

感謝閱讀，如果覺得有用，希望你可以分享給你的朋友、同事，或者點個在看支持一下。

—END—

我準備了一些純手打的高質量PDF，有好友贊助的也有我自己的，大家可以免費領取：

深入淺出Java多線程、HTTP超全匯總、Java基礎核心總結、程序員必知的硬核知識大全、簡歷面試談薪的超全乾貨。

別看數量不多，但篇篇都是乾貨，看完的都說很肝。

領取方式：掃碼關注后，在公眾號後台回復：666

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

【其他文章推薦】

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※想知道最厲害的網頁設計公司"嚨底家"!

※幫你省時又省力,新北清潔一流服務好口碑

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

原文鏈接：https://fuckcloudnative.io/posts/lens/

Kubernetes 的桌面客戶端有那麼幾個，曾經 Kubernetic 應該是最好用的，但最近有個叫 Lens 的 APP 改變了這個格局，功能比 Kubernetic 多，使用體驗更好，適合廣大系統重啟工程師裝逼。它有以下幾個亮點：

① Lens 就是一個強大的 IDE，可以實時查看集群狀態，實時查看日誌流，方便排查故障。有了 Lens，你可以更方便快捷地使用你的集群，從根本上提高工作效率和業務迭代速度。

日誌流界面可以選擇显示或隱藏時間戳，也可以指定显示的行數：

② Lens 可以管理多集群，它使用內置的 kubectl 通過 kubeconfig 來訪問集群，支持本地集群和外部集群（如EKS、AKS、GKE、Pharos、UCP、Rancher 等），甚至連 Openshift 也支持：

只是與 Openshift 的監控還不太兼容。也可以很輕鬆地查看並編輯 CR：

有了 Lens，你就可以統一管理所有的集群。

③ Lens 內置了資源利用率的儀錶板，支持多種對接 Prometheus 的方式：

④ Lens 內置了 kubectl，它的內置終端會確保集群的 API Server 版本與 kubectl 版本兼容，所以你不需要在本地安裝 kubectl。可以驗證一下：

你會看到本地安裝的 kubectl 版本和 Lens 裏面打開的終端里的 kubectl 版本信息是不一樣的，Lens 確實內置了 kubectl。

⑤ Lens 內置了 helm 模板商店，可直接點擊安裝：

現在 Lens 迎來了最新版 3.5.0，換上了全新的 Logo：

穩定性也提升了很多，快去試試吧。

Kubernetes 1.18.2 1.17.5 1.16.9 1.15.12離線安裝包發布地址http://store.lameleg.com ，歡迎體驗。 使用了最新的sealos v3.3.6版本。 作了主機名解析配置優化，lvscare 掛載/lib/module解決開機啟動ipvs加載問題， 修復lvscare社區netlink與3.10內核不兼容問題,sealos生成百年證書等特性。更多特性 https://github.com/fanux/sealos 。歡迎掃描下方的二維碼加入釘釘群 ，釘釘群已經集成sealos的機器人實時可以看到sealos的動態。

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

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

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

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

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

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

※超省錢租車方案

用Map+函數式接口來實現策略模式

目前在魔都，貝殼找房是我的僱主，平時關注一些 java 領域相關的技術，希望你們能在這篇文章中找到些有用的東西。個人水平有限，如果文章有錯誤還請指出，在留言區一起交流。

本文已投稿至公眾號 Hollis 原文鏈接：https://mp.weixin.qq.com/s/hkypvNBkRjPM6HM51_jW9g

我想大家肯定都或多或少的看過各種“策略模式”的講解、佈道等等，這篇文章就是來好好“澄清”一下策略模式，並嘗試回答以下的問題：

1. 策略模式是如何優化業務邏輯代碼結構的？
2. 殺雞焉用宰牛刀？就是幾個if else場景我需要用到策略模式？！
3. 有沒有什麼更好的代碼結構來實現策略模式的嗎？

策略模式是如何優化業務邏輯代碼結構的？

要回答這個問題，我們還得先扒一扒策略模式的定義，從定義着手來理解它：

策略模式的教科書定義

它的定義很精簡：一個類的行為或其算法可以在運行時更改。我們把它降維到代碼層面，用人話翻譯一下就是，運行時我給你這個類的方法傳不同的“key”，你這個方法會執行不同的業務邏輯。細品一下，這不就是 if else 乾的事嗎？

策略模式優化了什麼？

其實策略模式的核心思想和 if else如出一轍，根據不同的key動態的找到不同的業務邏輯，那它就只是如此嗎？

實際上，我們口中的策略模式其實就是在代碼結構上調整，用接口+實現類+分派邏輯來使代碼結構可維護性好點。

一般教科書上講解到接口與實現類就結束了，其他博客上會帶上提及分派邏輯。這裏就不啰嗦了。

小結一下，即使用了策略模式，你該寫的業務邏輯照常寫，到邏輯分派的時候，還是變相的if else。而它的優化點是抽象了出了接口，將業務邏輯封裝成一個一個的實現類，任意地替換。在複雜場景（業務邏輯較多）時比直接 if else 來的好維護些。

殺雞焉用宰牛刀？就是幾個if else場景我需要用到策略模式？！

我想小夥伴們經常有這樣的不滿，我的業務邏輯就3 4 行，你給我整一大堆類定義？有必要這麼麻煩嗎？我看具體的業務邏輯還需要去不同的類中，簡單點行不行。

其實我們所不滿的就是策略模式帶來的缺點：1、策略類會增多 2、業務邏輯分散到各個實現類中，而且沒有一個地方可以俯視整個業務邏輯

針對傳統策略模式的缺點，在這分享一個實現思路，這個思路已經幫我們團隊解決了多個複雜if else的業務場景，理解上比較容易，代碼上需要用到Java8的特性——利用Map與函數式接口來實現。

直接show代碼結構：為了簡單演示一個思路，代碼用String 類型來模擬一個業務BO

其中：

1. getCheckResult() 為傳統的做法
2. getCheckResultSuper()則事先在Map中定義好了“判斷條件”與“業務邏輯”的映射關係,具體講解請看代碼註釋

/**
 * 某個業務服務類
 */
@Service
public class BizService {

    /**
     * 傳統的 if else 解決方法
     * 當每個業務邏輯有 3 4 行時，用傳統的策略模式不值得，直接的if else又顯得不易讀
     */
    public String getCheckResult(String order) {
        if ("校驗1".equals(order)) {
            return "執行業務邏輯1";
        } else if ("校驗2".equals(order)) {
            return "執行業務邏輯2";
        }else if ("校驗3".equals(order)) {
            return "執行業務邏輯3";
        }else if ("校驗4".equals(order)) {
            return "執行業務邏輯4";
        }else if ("校驗5".equals(order)) {
            return "執行業務邏輯5";
        }else if ("校驗6".equals(order)) {
            return "執行業務邏輯6";
        }else if ("校驗7".equals(order)) {
            return "執行業務邏輯7";
        }else if ("校驗8".equals(order)) {
            return "執行業務邏輯8";
        }else if ("校驗9".equals(order)) {
            return "執行業務邏輯9";
        }
        return "不在處理的邏輯中返回業務錯誤";
    }

    /**
     * 業務邏輯分派Map
     * Function為函數式接口，下面代碼中 Function<String, String> 的含義是接收一個Stirng類型的變量，返回一個String類型的結果
     */
    private Map<String, Function<String, String>> checkResultDispatcher = new HashMap<>();

    /**
     * 初始化 業務邏輯分派Map 其中value 存放的是 lambda表達式
     */
    @PostConstruct
    public void checkResultDispatcherInit() {
        checkResultDispatcher.put("校驗1", order -> String.format("對%s執行業務邏輯1", order));
        checkResultDispatcher.put("校驗2", order -> String.format("對%s執行業務邏輯2", order));
        checkResultDispatcher.put("校驗3", order -> String.format("對%s執行業務邏輯3", order));
        checkResultDispatcher.put("校驗4", order -> String.format("對%s執行業務邏輯4", order));
        checkResultDispatcher.put("校驗5", order -> String.format("對%s執行業務邏輯5", order));
        checkResultDispatcher.put("校驗6", order -> String.format("對%s執行業務邏輯6", order));
        checkResultDispatcher.put("校驗7", order -> String.format("對%s執行業務邏輯7", order));
        checkResultDispatcher.put("校驗8", order -> String.format("對%s執行業務邏輯8", order));
        checkResultDispatcher.put("校驗9", order -> String.format("對%s執行業務邏輯9", order));
    }

    public String getCheckResultSuper(String order) {
        //從邏輯分派Dispatcher中獲得業務邏輯代碼，result變量是一段lambda表達式
        Function<String, String> result = checkResultDispatcher.get(order);
        if (result != null) {
            //執行這段表達式獲得String類型的結果
            return result.apply(order);
        }
        return "不在處理的邏輯中返回業務錯誤";
    }
}

通過http調用一下看看效果：

/**
 * 模擬一次http調用
 */
@RestController
public class BizController {

    @Autowired
    private BizService bizService;

    @PostMapping("/v1/biz/testSuper")
    public String test2(String order) {
        return bizService.getCheckResultSuper(order);
    }
}

這是個簡單的demo演示，之後會舉一些複雜的場景案例。

魯迅曾說過，“每解決一個問題，就會引出更多的問題”。我們一起來看看這樣的實現有什麼好處，會帶來什麼問題。

好處很直觀：

1. 在一段代碼里直觀的看到”判斷條件”與業務邏輯的映射關係
2. 不需要單獨定義接口與實現類，直接使用現有的函數式接口（什麼？不知道函數式接口？快去了解），而實現類直接就是業務代碼本身。

不好的點：

1. 需要團隊成員對lambda表達式有所了解(什麼？Java14都出來了還有沒用上Java8新特性的小夥伴？)

接下來我舉幾個在業務中經常遇到的if else場景，並用Map+函數式接口的方式來解決它

在真實業務場景問題的解決思路

有的小夥伴會說，我的判斷條件有多個啊，而且很複雜，你之前舉個例子只有單個判斷邏輯，而我有多個判斷邏輯該怎麼辦呢？

很好解決：寫一個判斷邏輯的方法，Map的key由方法計算出

/**
 * 某個業務服務類
 */
@Service
public class BizService {

    private Map<String, Function<String, String>> checkResultDispatcherMuti = new HashMap<>();

    /**
     * 初始化 業務邏輯分派Map 其中value 存放的是 lambda表達式
     */
    @PostConstruct
    public void checkResultDispatcherMuitInit() {
        checkResultDispatcherMuti.put("key_訂單1", order -> String.format("對%s執行業務邏輯1", order));
        checkResultDispatcherMuti.put("key_訂單1_訂單2", order -> String.format("對%s執行業務邏輯2", order));
        checkResultDispatcherMuti.put("key_訂單1_訂單2_訂單3", order -> String.format("對%s執行業務邏輯3", order));
    }

    public String getCheckResultMuti(String order, int level) {
        //寫一段生成key的邏輯：
        String ley = getDispatcherKey(order, level);

        Function<String, String> result = checkResultDispatcherMuti.get(ley);
        if (result != null) {
            //執行這段表達式獲得String類型的結果
            return result.apply(order);
        }
        return "不在處理的邏輯中返回業務錯誤";
    }

    /**
     * 判斷條件方法
     */
    private String getDispatcherKey(String order, int level) {
        StringBuilder key = new StringBuilder("key");
        for (int i = 1; i <= level; i++) {
            key.append("_" + order + i);
        }
        return key.toString();
    }
}

用http模擬一下：

/**
 * 模擬一次http調用
 */
@RestController
public class BizController {

    @Autowired
    private BizService bizService;

    @PostMapping("/v1/biz/testMuti")
    public String test1(String order, Integer level) {
        return bizService.getCheckResultMuti(order, level);
    }
}

只要設計好你的key的生成規則就好。

還有小夥伴會問：我的業務邏輯有很多很多行，在checkResultDispatcherMuitInit()方法的Map中直接寫不會很長嗎？

直接寫當然長了，我們可以抽象出一個service服務專門放業務邏輯，然後在定義中調用它就好了：

提供一個業務邏輯單元：

/**
 * 提供業務邏輯單元
 */
@Service
public class BizUnitService {

    public String bizOne(String order) {
        return order + "各種花式操作1";
    }
    public String bizTwo(String order) {
        return order + "各種花式操作2";
    }
    public String bizThree(String order) {
        return order + "各種花式操作3";
    }
}

/**
 * 某個業務服務類
 */
@Service
public class BizService {
    @Autowired
    private BizUnitService bizUnitService;

    private Map<String, Function<String, String>> checkResultDispatcherComX = new HashMap<>();

    /**
     * 初始化 業務邏輯分派Map 其中value 存放的是 lambda表達式
     */
    @PostConstruct
    public void checkResultDispatcherComXInit() {
        checkResultDispatcherComX.put("key_訂單1", order -> bizUnitService.bizOne(order));
        checkResultDispatcherComX.put("key_訂單1_訂單2", order -> bizUnitService.bizTwo(order));
        checkResultDispatcherComX.put("key_訂單1_訂單2_訂單3", order -> bizUnitService.bizThree(order));
    }

    public String getCheckResultComX(String order, int level) {
        //寫一段生成key的邏輯：
        String ley = getDispatcherComXKey(order, level);

        Function<String, String> result = checkResultDispatcherComX.get(ley);
        if (result != null) {
            //執行這段表達式獲得String類型的結果
            return result.apply(order);
        }
        return "不在處理的邏輯中返回業務錯誤";
    }

    /**
     * 判斷條件方法
     */
    private String getDispatcherComXKey(String order, int level) {
        StringBuilder key = new StringBuilder("key");
        for (int i = 1; i <= level; i++) {
            key.append("_" + order + i);
        }
        return key.toString();
    }
}

調用結果：

總結

最後，我們一起嘗試回答以下幾個問題：

1. 策略模式是如何優化業務邏輯代碼結構的？
   —— 抽象了出了接口，將業務邏輯封裝成一個一個的實現類，任意地替換。在複雜場景（業務邏輯較多）時比直接 if else 來的好維護些。
2. 殺雞焉用宰牛刀？就是幾個if else場景我需要用到策略模式？！——我們所不滿的其實就是傳統接口實現的缺點：1、策略類會很多。 2、業務邏輯分散到各個實現類中，而且沒有一個地方可以俯覽整個業務邏輯
3. 有沒有什麼更好的代碼結構來實現策略模式的嗎？——針對傳統策略模式的缺點，分享了利用Map與函數式接口來實現的思路。

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

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

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

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

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

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

Python中的異常處理

異常分類

　　程序中難免出現錯誤，總共可分為兩種。

 

　　1.邏輯錯誤

　　2.語法錯誤

 

　　對於剛接觸編程的人來說，這兩個錯誤都會經常去犯，但是隨着經驗慢慢的積累，語法錯誤的情況會越來越少反而邏輯錯誤的情況會越來越多（因為工程量巨大）。不論多麼老道的程序員都不可避免出現這兩種錯誤。

 

異常的三大信息

　　異常其實就是程序運行時發生錯誤的信號，我們寫代碼的過程中不可避免也最害怕的就是出現異常，然而當程序拋出異常時實際上會分為三部分，即三大信息。

 

 

常用的異常類

　　在Python中一切皆對象，異常本身也是由一個類生成的，NameError其實本身就是一個異常類，其他諸如此類的異常類還有很多。

Python中常見的異常類
AttributeError	試圖訪問一個對象沒有的屬性，比如foo.x，但是foo並沒有屬性x
IOError	輸入/輸出異常；基本上是無法打開文件
ImportError	無法引入模塊或包；基本上是路徑問題或名稱錯誤
IndentationError	語法錯誤（的子類） ；代碼沒有正確對齊
IndexError	下標索引超出序列邊界，比如當x只有三個元素，卻試圖訪問x[5]
KeyError	試圖訪問字典里不存在的鍵
KeyboardInterrupt	Ctrl+C被按下
NameError	試圖使用一個還未被賦予對象的變量
SyntaxError	Python代碼非法，代碼不能編譯(其實就是語法錯誤，寫錯了）
TypeError	傳入對象類型與要求的不符合
UnboundLocalError	試圖訪問一個還未被設置的局部變量，基本上是由於另有一個同名的 全局變量，導致你以為正在訪問它
ValueError	傳入一個調用者不期望的值，即使值的類型是正確的

 

異常處理

　　我們可以來用某些方法進行異常捕捉，當出現異常時我們希望代碼以另一種邏輯運行，使得我們的程序更加健壯，這個就叫做異常處理。異常處理是非常重要的，本身也並不複雜，千萬不可馬虎大意。

　　但是切記不可濫用異常處理，這會使得你的代碼可讀性變差。

 

if else處理異常

　　if和else本身就具有處理異常的功能，他們更多的是在我們能預測到可能出現的範圍內進行規避異常，對於我們不能預測的異常來說就顯得不是那麼的好用。如下：

# ==== if else 處理異常 ====

while 1:
    select = input("請輸入数字0進行關機:").strip()
    if select.isdigit():  # 我們可以防止用戶輸入非数字的字符
        if select == "0":
            print("正在關機...")
            break
    print("輸入有誤，請重新輸入")

# ==== 執行結果 ====

"""
請輸入数字0進行關機:關機
輸入有誤，請重新輸入
請輸入数字0進行關機:關機啊
輸入有誤，請重新輸入
請輸入数字0進行關機:0
正在關機...
"""

　　這種異常處理機制雖然非常簡單，但是並不靈活，我們可以使用更加簡單的方式來處理他們。

 

try except處理異常

 

　　try:代表要檢測可能出現異常的代碼塊

　　except:當異常出現后的處理情況

 

　　執行流程:

　　　　try中檢測的代碼塊 —> 如果有異常 —> 執行except代碼塊 —> 執行正常邏輯代碼 —> 程序結束

　　　　try中檢測的代碼塊 —> 如果沒有異常 —> 執行完畢try中的代碼塊 —> 執行正常邏輯代碼 —> 程序結束

 

# ====  try except 執行流程 有異常的情況 ====

li = [1,2,3]

try:
    print("開始執行我try了...")
    print(li[10])  # 出錯點...
    print("繼續執行我try...")
except IndexError as e:
    print("有異常執行我except...")

print("正常邏輯代碼...")

# ==== 執行結果 ====

"""
開始執行我try了...
有異常執行我except...
正常邏輯代碼...
""" 

# ====  try except 執行流程 無異常的情況 ====

li = [1,2,3]

try:
    print("開始執行我try了...")
    print(li[2])
    print("繼續執行我try...")
except IndexError as e:
    print("有異常執行我except...")

print("正常邏輯代碼...")

# ==== 執行結果 ====

"""
開始執行我try了...
3
繼續執行我try...
正常邏輯代碼...
""" 

# ==== try except 處理異常 ====

while 1:
    try:  # try檢測可能出錯的語句，一旦出錯立馬跳轉到except語句塊執行代碼。
        select = int(input("請輸入数字0進行關機:").strip())
        if select == 0:
            print("正在關機...")
            break
        print("輸入有誤，請重新輸入...")
    except ValueError as e:  # 當執行完except的代碼塊后，程序運行結束，其中e代表的是異常信息。
        print("錯誤信息是:",e)
        print("輸入有誤，請重新輸入")

# ==== 執行結果 ====

"""
請輸入数字0進行關機:1
輸入有誤，請重新輸入...
請輸入数字0進行關機:tt
錯誤信息是: invalid literal for int() with base 10: 'tt'
輸入有誤，請重新輸入
請輸入数字0進行關機:0
正在關機...
"""

 

多段except捕捉多異常

　　我們可以使用try和多段except的語法來檢測某一代碼塊，可以更加方便的應對更多類型的錯誤，Ps不常用:

# ==== 多段 except 捕捉多異常 ====

while 1:

    li = [1,2,3,4]
    dic = {"name":"Yunya","age":18}

    li_index = input("請輸入索引:")
    dic_key = input("請輸入鍵的名稱:")

    if li_index.isdigit():
        li_index = int(li_index)

    try:
        print(li[li_index])
        print(dic[dic_key])
    except IndexError as e1:  # 注意，先拋出的錯誤會直接跳到其處理的except代碼塊，而try下面的語句將不會被執行。
        print("索引出錯啦！")
    except KeyError as e2:
        print("鍵出錯啦！")

# ==== 執行結果 ====

"""
請輸入索引:10
請輸入鍵的名稱:gender
索引出錯啦！
請輸入索引:2
請輸入鍵的名稱:gender
3
鍵出錯啦！
"""

 

元組捕捉多異常

　　使用多段except捕捉多異常會顯得特別麻煩，這個時候我們可以使用(異常類1,異常類2)來捕捉多異常，但是需要注意的是，對比多段except捕捉多異常來說，這種方式的處理邏輯會顯得較為複雜（因為只有一段處理邏輯），如下：

# ====  元組捕捉多異常 ====

while 1:

    li = [1,2,3,4]
    dic = {"name":"Yunya","age":18}

    li_index = input("請輸入索引:")
    dic_key = input("請輸入鍵的名稱:")

    if li_index.isdigit():
        li_index = int(li_index)

    try:
        print(li[li_index])
        print(dic[dic_key])
    except (IndexError,KeyError) as e:  # 使用()的方式可以同時捕捉很多異常。
        print("出錯啦！")

# ==== 執行結果 ====

"""
請輸入索引:10
請輸入鍵的名稱:gender
出錯啦！
請輸入索引:2
請輸入鍵的名稱:gender
3
出錯啦！
"""

　　可以看到，不管是那種錯誤都只有一種應對策略，如果我們想要多種應對策略就只能寫if判斷來判斷異常類型再做處理。所以就會顯得很麻煩，如下：

# ====  元組捕捉多異常 ====

while 1:

    li = [1,2,3,4]
    dic = {"name":"Yunya","age":18}

    li_index = input("請輸入索引:")
    dic_key = input("請輸入鍵的名稱:")

    if li_index.isdigit():
        li_index = int(li_index)

    try:
        print(li[li_index])
        print(dic[dic_key])
    except (IndexError,KeyError) as e:
        # 判斷異常類型再做出相應的對應策略
        if isinstance(e,IndexError):
            print("索引出錯啦！")
        elif isinstance(e,KeyError):
            print("鍵出錯啦！")

# ==== 執行結果 ====

"""
請輸入索引:10
請輸入鍵的名稱:gender
索引出錯啦！
請輸入索引:2
請輸入鍵的名稱:gender
3
鍵出錯啦！
"""

 

萬能異常Exception

　　我們可以捕捉Exception類引發的異常，它是所有異常類的基類。（Exception類的父類則是BaseException類，而BaseException的父類則是object類)

# ====  萬能異常Exception ====

while 1:

    li = [1,2,3,4]
    dic = {"name":"Yunya","age":18}

    li_index = input("請輸入索引:")
    dic_key = input("請輸入鍵的名稱:")

    if li_index.isdigit():
        li_index = int(li_index)

    try:
        print(li[li_index])
        print(dic[dic_key])
    except Exception as e:  #使用 Exception來捕捉所有異常。
        # 判斷異常類型再做出相應的對應策略
        if isinstance(e,IndexError):
            print("索引出錯啦！")
        elif isinstance(e,KeyError):
            print("鍵出錯啦！")

# ==== 執行結果 ====

"""
請輸入索引:10
請輸入鍵的名稱:gender
索引出錯啦！
請輸入索引:2
請輸入鍵的名稱:gender
3
鍵出錯啦！
"""

 

 

try except else聯用

　　這種玩法比較少，else代表沒有異常發生的情況下執行的代碼，執行順序如下：

 

　　try中檢測的代碼塊 —> 如果有異常 —> 終止try中的代碼塊繼續執行 —> 執行except代碼塊 —> 執行正常邏輯代碼 —> 程序結束

　　try中檢測的代碼塊 —> 如果沒有異常 —> 執行完畢try中的代碼塊 —> 執行else代碼塊 —> 執行正常邏輯代碼 —> 程序結束

 

# ====  try except else聯用 有異常的情況====

li = [1,2,3]

try:
    print("開始執行我try了...")
    print(li[10])  # 出錯點...
    print("繼續執行我try...")
except IndexError as e:
    print("有異常執行我except...")
else:
    print("沒有異常執行我else...")
print("正常邏輯代碼...")

# ==== 執行結果 ====

"""
開始執行我try了...
有異常執行我except...
正常邏輯代碼...
"""

# ====  try except else聯用 無異常的情況====

li = [1,2,3]

try:
    print("開始執行我try了...")
    print(li[2])
    print("繼續執行我try...")
except IndexError as e:
    print("有異常執行我except...")
else:
    print("沒有異常執行我else...")
print("正常邏輯代碼...")

# ==== 執行結果 ====

"""
開始執行我try了...
3
繼續執行我try...
沒有異常執行我else...
正常邏輯代碼...
"""

 

try except finally聯用

　　finally代表不論拋異常與否都會執行，因此常被用作關閉系統資源的操作，關於try,except,else,finally他們的優先級如下：

 

　　有異常的情況下:

　　　　try代碼塊

　　　　終止try代碼塊繼續執行

　　　　except代碼塊

　　　　finally代碼塊

　　　　正常邏輯代碼

 

　　無異常的情況下:

　　　　try代碼塊

　　　　else代碼塊

　　　　finally代碼塊

　　　　正常邏輯代碼

 

# ====  try except else finally 執行流程 有異常的情況 ====

li = [1,2,3]

try:
    print("開始執行我try了...")
    print(li[10])  # 出錯點...
    print("繼續執行我try...")
except IndexError as e:
    print("有異常執行我except...")
else:
    print("沒有異常執行我else...")
finally:
    print("不管有沒有異常都執行我finally...")

print("正常邏輯代碼...")

# ==== 執行結果 ====

"""
開始執行我try了...
有異常執行我except...
不管有沒有異常都執行我finally...
正常邏輯代碼...
"""

# ====  try except else finally 執行流程 無異常的情況 ====

li = [1,2,3]

try:
    print("開始執行我try了...")
    print(li[2])
    print("繼續執行我try...")
except IndexError as e:
    print("有異常執行我except...")
else:
    print("沒有異常執行我else...")
finally:
    print("不管有沒有異常都執行我finally...")

print("正常邏輯代碼...")

# ==== 執行結果 ====

"""
開始執行我try了...
3
繼續執行我try...
沒有異常執行我else...
不管有沒有異常都執行我finally...
正常邏輯代碼...
"""

 

自定義異常

raise主動拋出異常

　　在某些時候我們可能需要主動的去阻止程序的運行，主動的拋出一個異常。可以使用raise來進行操作。這個是一種非常常用的手段。

# ====  raise使用方法  ====

print("----1----")
print("----2----")
print("----3----")
raise Exception("我也不知道是什麼類型的異常...")
print("----4----")
print("----5----")
print("----6----")

# ==== 執行結果 ====

"""
----1----
----2----
----3----
Traceback (most recent call last):
  File "C:/Users/Administrator/PycharmProjects/learn/元類編程.py", line 6, in <module>
    raise Exception("我也不知道是什麼類型的異常...")
Exception: 我也不知道是什麼類型的異常...

Process finished with exit code 1
"""

 

自定義異常類

　　前面已經說過一切皆對象，異常也來自一個對象。因此我們也可以自己來定製一個對象。注意，自定義異常類必須繼承BaseException類。

# ====  自定義異常類  ====

class MyError(BaseException):
    pass

raise MyError("我的異常")



# ==== 執行結果 ====

"""
Traceback (most recent call last):
  File "C:/Users/Administrator/PycharmProjects/learn/元類編程.py", line 6, in <module>
    raise MyError("我的異常")
__main__.MyError: 我的異常
"""

 

擴展：斷言assert

　　斷言是一個十分裝逼的使用，假設多個函數進行計算，我們已經有了預期的結果只是在做一個算法的設計。如果函數的最後的結果不是我們本來預期的結果那麼寧願讓他停止運行也不要讓錯誤繼續擴大，在這種情況下就可以使用斷言操作，使用斷言會拋出一個AssertionError類的異常。

# ====  斷言assert  ====

def calculate():
    """假設在做非常複雜的運算"""
    return 3+2*5

res = calculate()

assert res == 25  # AssertionError

print("算法測試通過！你真的太厲害了")

# ==== 執行結果 ====

"""
Traceback (most recent call last):
  File "C:/Users/Administrator/PycharmProjects/learn/元類編程.py", line 8, in <module>
    assert res == 25
AssertionError
"""

 

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

【其他文章推薦】

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

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※南投搬家公司費用需注意的眉眉角角，別等搬了再說!

※新北清潔公司,居家、辦公、裝潢細清專業服務

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