2. 程式人生 > >kafka--Kafka設計解析（二）：Kafka High Availability （上）

kafka--Kafka設計解析（二）：Kafka High Availability （上）

阿新 • • 發佈：2019-02-08

Kafka在0.8以前的版本中，並不提供High Availablity機制，一旦一個或多個Broker宕機，則宕機期間其上所有Partition都無法繼續提供服務。若該Broker永遠不能再恢復，亦或磁碟故障，則其上資料將丟失。而Kafka的設計目標之一即是提供資料持久化，同時對於分散式系統來說，尤其當叢集規模上升到一定程度後，一臺或者多臺機器宕機的可能性大大提高，對Failover要求非常高。因此，Kafka從0.8開始提供High Availability機制。本文從Data Replication和Leader Election兩方面介紹了Kafka的HA機制。

Kafka為何需要High Available

為何需要Replication

在Kafka在0.8以前的版本中，是沒有Replication的，一旦某一個Broker宕機，則其上所有的Partition資料都不可被消費，這與Kafka資料永續性及Delivery Guarantee的設計目標相悖。同時Producer都不能再將資料存於這些Partition中。

  • 如果Producer使用同步模式則Producer會在嘗試重新發送message.send.max.retries（預設值為3）次後丟擲Exception，使用者可以選擇停止傳送後續資料也可選擇繼續選擇傳送。而前者會造成資料的阻塞，後者會造成本應發往該Broker的資料的丟失。
  • 如果Producer使用非同步模式，則Producer會嘗試重新發送message.send.max.retries（預設值為3）次後記錄該異常並繼續傳送後續資料，這會造成資料丟失並且使用者只能通過日誌發現該問題。同時，Kafka的Producer並未對非同步模式提供callback介面。

由此可見，在沒有Replication的情況下，一旦某機器宕機或者某個Broker停止工作則會造成整個系統的可用性降低。隨著叢集規模的增加，整個叢集中出現該類異常的機率大大增加，因此對於生產系統而言Replication機制的引入非常重要。

為何需要Leader Election


引入Replication之後，同一個Partition可能會有多個Replica，而這時需要在這些Replication之間選出一個Leader，Producer和Consumer只與這個Leader互動，其它Replica作為Follower從Leader中複製資料。注意：本文所述Leader Election主要指Replica之間的Leader Election。

因為需要保證同一個Partition的多個Replica之間的資料一致性（其中一個宕機後其它Replica必須要能繼續服務並且即不能造成資料重複也不能造成資料丟失）。如果沒有一個Leader，所有Replica都可同時讀/寫資料，那就需要保證多個Replica之間互相（N×N條通路）同步資料，資料的一致性和有序性非常難保證，大大增加了Replication實現的複雜性，同時也增加了出現異常的機率。而引入Leader後，只有Leader負責資料讀寫，Follower只向Leader順序Fetch資料（N條通路），系統更加簡單且高效。

Kafka HA設計解析

如何將所有Replica均勻分佈到整個叢集

為了更好的做負載均衡，Kafka儘量將所有的Partition均勻分配到整個叢集上。一個典型的部署方式是一個Topic的Partition數量大於Broker的數量。同時為了提高Kafka的容錯能力，也需要將同一個Partition的Replica儘量分散到不同的機器。實際上，如果所有的Replica都在同一個Broker上，那一旦該Broker宕機，該Partition的所有Replica都無法工作，也就達不到HA的效果。同時，如果某個Broker宕機了，需要保證它上面的負載可以被均勻的分配到其它倖存的所有Broker上。

Kafka分配Replica的演算法如下：

  1. 將所有Broker（假設共n個Broker）和待分配的Partition排序
  2. 將第i個Partition分配到第（i mod n）個Broker上
  3. 將第i個Partition的第j個Replica分配到第（(i + j) mode n）個Broker上

Data Replication

Kafka的Data Replication需要解決如下問題：

  • 怎樣Propagate訊息
  • 在向Producer傳送ACK前需要保證有多少個Replica已經收到該訊息
  • 怎樣處理某個Replica不工作的情況
  • 怎樣處理Failed Replica恢復回來的情況

Propagate訊息

Producer在釋出訊息到某個Partition時，先通過ZooKeeper找到該Partition的Leader，然後無論該Topic的Replication Factor為多少（也即該Partition有多少個Replica），Producer只將該訊息傳送到該Partition的Leader。Leader會將該訊息寫入其本地Log。每個Follower都從Leader pull資料。這種方式上，Follower儲存的資料順序與Leader保持一致。Follower在收到該訊息並寫入其Log後，向Leader傳送ACK。一旦Leader收到了ISR中的所有Replica的ACK，該訊息就被認為已經commit了，Leader將增加HW並且向Producer傳送ACK。

為了提高效能，每個Follower在接收到資料後就立馬向Leader傳送ACK，而非等到資料寫入Log中。因此，對於已經commit的訊息，Kafka只能保證它被存於多個Replica的記憶體中，而不能保證它們被持久化到磁碟中，也就不能完全保證異常發生後該條訊息一定能被Consumer消費。但考慮到這種場景非常少見，可以認為這種方式在效能和資料持久化上做了一個比較好的平衡。在將來的版本中，Kafka會考慮提供更高的永續性。

Consumer讀訊息也是從Leader讀取，只有被commit過的訊息（offset低於HW的訊息）才會暴露給Consumer。

Kafka Replication的資料流如下圖所示：

ACK前需要保證有多少個備份

和大部分分散式系統一樣，Kafka處理失敗需要明確定義一個Broker是否“活著”。對於Kafka而言，Kafka存活包含兩個條件，一是它必須維護與ZooKeeper的session（這個通過ZooKeeper的Heartbeat機制來實現）。二是Follower必須能夠及時將Leader的訊息複製過來，不能“落後太多”。

Leader會跟蹤與其保持同步的Replica列表，該列表稱為ISR（即in-sync Replica）。如果一個Follower宕機，或者落後太多，Leader將把它從ISR中移除。這裡所描述的“落後太多”指Follower複製的訊息落後於Leader後的條數超過預定值（該值可在$KAFKA_HOME/config/server.properties中通過replica.lag.max.messages配置，其預設值是4000）或者Follower超過一定時間（該值可在$KAFKA_HOME/config/server.properties中通過replica.lag.time.max.ms來配置，其預設值是10000）未向Leader傳送fetch請求。

Kafka的複製機制既不是完全的同步複製，也不是單純的非同步複製。事實上，完全同步複製要求所有能工作的Follower都複製完，這條訊息才會被認為commit，這種複製方式極大的影響了吞吐率（高吞吐率是Kafka非常重要的一個特性）。而非同步複製方式下，Follower非同步的從Leader複製資料，資料只要被Leader寫入log就被認為已經commit，這種情況下如果Follower都複製完都落後於Leader，而如果Leader突然宕機，則會丟失資料。而Kafka的這種使用ISR的方式則很好的均衡了確保資料不丟失以及吞吐率。Follower可以批量的從Leader複製資料，這樣極大的提高複製效能（批量寫磁碟），極大減少了Follower與Leader的差距。

需要說明的是，Kafka只解決fail/recover，不處理“Byzantine”（“拜占庭”）問題。一條訊息只有被ISR裡的所有Follower都從Leader複製過去才會被認為已提交。這樣就避免了部分資料被寫進了Leader，還沒來得及被任何Follower複製就宕機了，而造成資料丟失（Consumer無法消費這些資料）。而對於Producer而言，它可以選擇是否等待訊息commit，這可以通過request.required.acks來設定。這種機制確保了只要ISR有一個或以上的Follower，一條被commit的訊息就不會丟失。

Leader Election演算法

上文說明了Kafka是如何做Replication的，另外一個很重要的問題是當Leader宕機了，怎樣在Follower中選舉出新的Leader。因為Follower可能落後許多或者crash了，所以必須確保選擇“最新”的Follower作為新的Leader。一個基本的原則就是，如果Leader不在了，新的Leader必須擁有原來的Leader commit過的所有訊息。這就需要作一個折衷，如果Leader在標明一條訊息被commit前等待更多的Follower確認，那在它宕機之後就有更多的Follower可以作為新的Leader，但這也會造成吞吐率的下降。

一種非常常用的選舉leader的方式是“Majority Vote”（“少數服從多數”），但Kafka並未採用這種方式。這種模式下，如果我們有2f+1個Replica（包含Leader和Follower），那在commit之前必須保證有f+1個Replica複製完訊息，為了保證正確選出新的Leader，fail的Replica不能超過f個。因為在剩下的任意f+1個Replica裡，至少有一個Replica包含有最新的所有訊息。這種方式有個很大的優勢，系統的latency只取決於最快的幾個Broker，而非最慢那個。Majority Vote也有一些劣勢，為了保證Leader Election的正常進行，它所能容忍的fail的follower個數比較少。如果要容忍1個follower掛掉，必須要有3個以上的Replica，如果要容忍2個Follower掛掉，必須要有5個以上的Replica。也就是說，在生產環境下為了保證較高的容錯程度，必須要有大量的Replica，而大量的Replica又會在大資料量下導致效能的急劇下降。這就是這種演算法更多用在ZooKeeper這種共享叢集配置的系統中而很少在需要儲存大量資料的系統中使用的原因。例如HDFS的HA Feature是基於majority-vote-based journal，但是它的資料儲存並沒有使用這種方式。

實際上，Leader Election演算法非常多，比如ZooKeeper的Zab, Raft和Viewstamped Replication。而Kafka所使用的Leader Election演算法更像微軟的PacificA演算法。

Kafka在ZooKeeper中動態維護了一個ISR（in-sync replicas），這個ISR裡的所有Replica都跟上了leader，只有ISR裡的成員才有被選為Leader的可能。在這種模式下，對於f+1個Replica，一個Partition能在保證不丟失已經commit的訊息的前提下容忍f個Replica的失敗。在大多數使用場景中，這種模式是非常有利的。事實上，為了容忍f個Replica的失敗，Majority Vote和ISR在commit前需要等待的Replica數量是一樣的，但是ISR需要的總的Replica的個數幾乎是Majority Vote的一半。

雖然Majority Vote與ISR相比有不需等待最慢的Broker這一優勢，但是Kafka作者認為Kafka可以通過Producer選擇是否被commit阻塞來改善這一問題，並且節省下來的Replica和磁碟使得ISR模式仍然值得。

如何處理所有Replica都不工作

上文提到，在ISR中至少有一個follower時，Kafka可以確保已經commit的資料不丟失，但如果某個Partition的所有Replica都宕機了，就無法保證資料不丟失了。這種情況下有兩種可行的方案：

  • 等待ISR中的任一個Replica“活”過來，並且選它作為Leader
  • 選擇第一個“活”過來的Replica（不一定是ISR中的）作為Leader

這就需要在可用性和一致性當中作出一個簡單的折衷。如果一定要等待ISR中的Replica“活”過來，那不可用的時間就可能會相對較長。而且如果ISR中的所有Replica都無法“活”過來了，或者資料都丟失了，這個Partition將永遠不可用。選擇第一個“活”過來的Replica作為Leader，而這個Replica不是ISR中的Replica，那即使它並不保證已經包含了所有已commit的訊息，它也會成為Leader而作為consumer的資料來源（前文有說明，所有讀寫都由Leader完成）。Kafka0.8.*使用了第二種方式。根據Kafka的文件，在以後的版本中，Kafka支援使用者通過配置選擇這兩種方式中的一種，從而根據不同的使用場景選擇高可用性還是強一致性。

如何選舉Leader

最簡單最直觀的方案是，所有Follower都在ZooKeeper上設定一個Watch，一旦Leader宕機，其對應的ephemeral znode會自動刪除，此時所有Follower都嘗試建立該節點，而建立成功者（ZooKeeper保證只有一個能建立成功）即是新的Leader，其它Replica即為Follower。

但是該方法會有3個問題：

  • split-brain 這是由ZooKeeper的特性引起的，雖然ZooKeeper能保證所有Watch按順序觸發，但並不能保證同一時刻所有Replica“看”到的狀態是一樣的，這就可能造成不同Replica的響應不一致
  • herd effect 如果宕機的那個Broker上的Partition比較多，會造成多個Watch被觸發，造成叢集內大量的調整
  • ZooKeeper負載過重 每個Replica都要為此在ZooKeeper上註冊一個Watch，當叢集規模增加到幾千個Partition時ZooKeeper負載會過重。

Kafka 0.8.*的Leader Election方案解決了上述問題，它在所有broker中選出一個controller，所有Partition的Leader選舉都由controller決定。controller會將Leader的改變直接通過RPC的方式（比ZooKeeper Queue的方式更高效）通知需為為此作為響應的Broker。同時controller也負責增刪Topic以及Replica的重新分配。

HA相關ZooKeeper結構

首先宣告本節所示ZooKeeper結構中，實線框代表路徑名是固定的，而虛線框代表路徑名與業務相關

admin （該目錄下znode只有在有相關操作時才會存在，操作結束時會將其刪除）

/admin/preferred_replica_election資料結構

{
   "fields":[
      {
         "name":"version",
         "type":"int",
         "doc":"version id"
      },
      {
         "name":"partitions",
         "type":{
            "type":"array",
            "items":{
               "fields":[
                  {
                     "name":"topic",
                     "type":"string",
                     "doc":"topic of the partition for which preferred replica election should be triggered"
                  },
                  {
                     "name":"partition",
                     "type":"int",
                     "doc":"the partition for which preferred replica election should be triggered"
                  }
               ],
            }
            "doc":"an array of partitions for which preferred replica election should be triggered"
         }
      }
   ]
}

Example:

{
  "version": 1,
  "partitions":
     [
        {
            "topic": "topic1",
            "partition": 8         
        },
        {
            "topic": "topic2",
            "partition": 16        
        }
     ]            
}

/admin/reassign_partitions用於將一些Partition分配到不同的broker集合上。對於每個待重新分配的Partition，Kafka會在該znode上儲存其所有的Replica和相應的Broker id。該znode由管理程序建立並且一旦重新分配成功它將會被自動移除。其資料結構如下：

{ 
"fields":[ 
{ 
"name":"version", 
"type":"int", 
"doc":"version id" 
}, 
{ 
"name":"partitions", 
"type":{ 
"type":"array", 
"items":{ 
"fields":[ 
{ 
"name":"topic", 
"type":"string", 
"doc":"topic of the partition to be reassigned" 
}, 
{ 
"name":"partition", 
"type":"int", 
"doc":"the partition to be reassigned" 
}, 
{ 
"name":"replicas", 
"type":"array", 
"items":"int", 
"doc":"a list of replica ids" 
} 
], 
} 
"doc":"an array of partitions to be reassigned to new replicas" 
} 
} 
] 
}
Example:
{
  "version": 1,
  "partitions":
     [
        {
            "topic": "topic3",
            "partition": 1,
            "replicas": [1, 2, 3]
        }
     ]            
}

/admin/delete_topics資料結構：

Schema:
{ "fields":
    [ {"name": "version", "type": "int", "doc": "version id"},
      {"name": "topics",
       "type": { "type": "array", "items": "string", "doc": "an array of topics to be deleted"}
      } ]
}

Example:
{
  "version": 1,
  "topics": ["topic4", "topic5"]
}

brokers

broker（即/brokers/ids/[brokerId]）儲存“活著”的broker資訊。資料結構如下：

Schema:
{ "fields":
    [ {"name": "version", "type": "int", "doc": "version id"},
      {"name": "host", "type": "string", "doc": "ip address or host name of the broker"},
      {"name": "port", "type": "int", "doc": "port of the broker"},
      {"name": "jmx_port", "type": "int", "doc": "port for jmx"}
    ]
}

Example:
{
    "jmx_port":-1,
    "host":"node1",
    "version":1,
    "port":9092
}

topic註冊資訊（/brokers/topics/[topic]），儲存該topic的所有partition的所有replica所在的broker id，第一個replica即為preferred replica，對一個給定的partition，它在同一個broker上最多隻有一個replica,因此broker id可作為replica id。資料結構如下：

Schema:
{ "fields" :
    [ {"name": "version", "type": "int", "doc": "version id"},
      {"name": "partitions",
       "type": {"type": "map",
                "values": {"type": "array", "items": "int", "doc": "a list of replica ids"},
                "doc": "a map from partition id to replica list"},
      }
    ]
}
Example:
{
    "version":1,
    "partitions":
        {"12":[6],
        "8":[2],
        "4":[6],
        "11":[5],
        "9":[3],
        "5":[7],
        "10":[4],
        "6":[8],
        "1":[3],
        "0":[2],
        "2":[4],
        "7":[1],
        "3":[5]}
}

partition state（/brokers/topics/[topic]/partitions/[partitionId]/state） 結構如下：

Schema:
{ "fields":
    [ {"name": "version", "type": "int", "doc": "version id"},
      {"name": "isr",
       "type": {"type": "array",
                "items": "int",
                "doc": "an array of the id of replicas in isr"}
      },
      {"name": "leader", "type": "int", "doc": "id of the leader replica"},
      {"name": "controller_epoch", "type": "int", "doc": "epoch of the controller that last updated the leader and isr info"},
      {"name": "leader_epoch", "type": "int", "doc": "epoch of the leader"}
    ]
}

Example:
{
    "controller_epoch":29,
    "leader":2,
    "version":1,
    "leader_epoch":48,
    "isr":[2]
}

controller 
/controller -> int (broker id of the controller)儲存當前controller的資訊

Schema:
{ "fields":
    [ {"name": "version", "type": "int", "doc": "version id"},
      {"name": "brokerid", "type": "int", "doc": "broker id of the controller"}
    ]
}
Example:
{
    "version":1,
　　"brokerid":8
}

/controller_epoch -> int (epoch)直接以整數形式儲存controller epoch，而非像其它znode一樣以JSON字串形式儲存。

broker failover過程簡介

  1. Controller在ZooKeeper註冊Watch，一旦有Broker宕機（這是用宕機代表任何讓系統認為其die的情景，包括但不限於機器斷電，網路不可用，GC導致的Stop The World，程序crash等），其在ZooKeeper對應的znode會自動被刪除，ZooKeeper會fire Controller註冊的watch，Controller讀取最新的倖存的Broker。
  2. Controller決定set_p，該集合包含了宕機的所有Broker上的所有Partition。
  3. 對set_p中的每一個Partition

    3.1 從/brokers/topics/[topic]/partitions/[partition]/state讀取該Partition當前的ISR

    3.2 決定該Partition的新Leader。如果當前ISR中有至少一個Replica還倖存，則選擇其中一個作為新Leader，新的ISR則包含當前ISR中所有幸存的Replica。否則選擇該Partition中任意一個倖存的Replica作為新的Leader以及ISR（該場景下可能會有潛在的資料丟失）。如果該Partition的所有Replica都宕機了，則將新的Leader設定為-1。

    3.3 將新的Leader，ISR和新的leader_epoch及controller_epoch寫入/brokers/topics/[topic]/partitions/[partition]/state。注意，該操作只有其version在3.1至3.3的過程中無變化時才會執行，否則跳轉到3.1

  4. 直接通過RPC向set_p相關的Broker傳送LeaderAndISRRequest命令。Controller可以在一個RPC操作中傳送多個命令從而提高效率。

    broker failover順序圖如下所示。

作者簡介

郭俊（Jason），碩士，從事大資料平臺研發工作，精通Kafka等分散式訊息系統及Storm等流式處理系統。

下篇預告

下篇文章將詳細介紹Kafka HA相關的異常情況處理，例如，怎樣處理Broker failover，Follower如何從Leader fetch訊息，如何重新分配Replica，如何處理Controller failure等。


相關推薦

kafka--Kafka設計解析（二）：Kafka High Availability （上）

Kafka在0.8以前的版本中，並不提供High Availablity機制，一旦一個或多個Broker宕機，則宕機期間其上所有Partition都無法繼續提供服務。若該Broker永遠不能再恢復，亦或磁碟故障，則其上資料將丟失。而Kafka的設計目標之一即是提供資

Kafka筆記整理（二）：Kafka Java API使用

大數據 Kafka Java [TOC] Kafka筆記整理（二）：Kafka Java API使用 下面的測試代碼使用的都是下面的topic： $ kafka-topics.sh --describe hadoop --zookeeper uplooking01:2181,uplooking0

Spark實戰（二）：Kafka-SparkStreaming-Elasticsearch

本文介紹saprk實時部分----spark-streaming。spark-streaming可以實現實時批處理功能，實際上還是相當於小的批處理，但是是7*24工作，可以近實時但需要維護成本。本文裡的用java寫的demo，實現功能是將kafka作為spar

Kafka（二）： Kafka 叢集部署與使用

一、Kafka 叢集部署                                                               Kafka是一種分散式的釋出（producer）/訂

大資料（三十二）：kafka消費過程

一、kafka在zookeeper中的儲存結構 producer不在zk中註冊，消費者在zk中註冊。 二、kafka消費過程分析 kafka提供了兩套consumer API：高階Consumer Api和低階Api 1.高階Api 優點： 編

大資料（二十九）：kafka簡介、架構、原理

一、kafka是什麼 在流式計算中，kafka一般用來快取資料，storm通過消費kafka的資料進行計算。 1.Apache kafka是一個開源的訊息系統，由scala寫成，是由Apache軟體基金會開發的一個開源訊息系統專案。 2.kafka最初始由Linkedi

kafka（八）：Kafka高可用性

  1. Kafka Partition Replication     功能：增加Topic分割槽的可用性     每個Partition分為leader和follower兩部分(前提是replication factor大於1的) &nb

kafka（九）：Kafka為什麼快

 1. 訊息集(message set)    生產者在將訊息傳送給Kafka的時候，可以將多條訊息以前傳送，減低IO的次數 2. 二進位制傳輸    Kafka的訊息傳遞過程中，會將資料轉換為位元組陣列來進行傳遞 3. 順序讀寫磁碟

面向物件設計的設計模式（二）：結構型模式（附 Demo & UML類圖）

本篇是面向物件設計系列文章的第三篇，講解的是設計模式中的結構型模式： 外觀模式 介面卡模式 橋接模式 代理模式 裝飾者模式 享元模式 該系列前面的兩篇文章： 面向物件設計的六大設計原則（附 Demo 及 UML 類圖） 面向物件設計的設計模式（一）：建

(轉) 面向物件設計原則（二）：開放-封閉原則（OCP）

原文：https://blog.csdn.net/tjiyu/article/details/57079927 面向物件設計原則（二）：開放-封閉原則（OCP）        開放-封閉原則（Open-closed principle，OCP）也

我對hyperledger fabric1.1.0的執著（六）：kafka叢集部署

1、用11臺伺服器，如下 名稱 ip Hostname 組織機構 Zk1 192.168.2.237 zookeeper1   Zk2 19

Ansible入門篇（六）：Kafka自動化安裝

Kafka是一種高吞吐量的分散式釋出訂閱訊息系統，可作為中介軟體進行資料隔離、傳輸作用。 Kafka安裝包下載 到 Kafka官網下載對應版本的安裝包，本文以kafka 1.0.2為例。 將下載好的kafka_2.11-1.0.2.tgz上傳到/opt/ans

Java併發程式設計：volatile關鍵字解析（二.併發程式設計中的三個概念）

在併發程式設計中，我們通常會遇到以下三個問題：原子性問題，可見性問題，有序性問題。我們先看具體看一下這三個概念： 1.原子性 　　原子性：即一個操作或者多個操作 要麼全部執行並且執行的過程不會被任何因素打斷，要麼就都不執行。 　　一個很經典的例子就是銀行賬戶轉賬問題

雲端計算設計模式翻譯（二）：Circuit Breaker Pattern（斷路器模式）

    當連線使用遠端服務或資源時，可能需要花不少精力來做好錯誤處理。這個模式可以有效提高程式的穩定性和彈性。 Context and Problem     在像雲這種分散式的環境中，應用程式的操作經常訪問遠端的資源和服務。然而這類操作有可能因為網路響應慢、超時、資源暫時

Kafka總結（一）：Kafka概述

Kafka是什麼？ KafKa是一個高吞吐量、分散式的釋出——訂閱訊息系統。據KafKa官網介紹，當前的KafKa已經定位為一個分散式流式處理平臺（a distributed streaming platform），它以可水平擴充套件和具

設計模式之十八：橋接模式（Bridge）

ora 它的 pla sin string src ams down ng- 橋接模式： 將抽象部分和它的實現部分相分離開來，以使它們能夠單獨地變化。 UML圖： 主要包含： Abstraction:定義了抽象部分的接口。操作一個實現部分對

MOOC清華《面向對象程序設計》第8章：棧的實現（采用模板實例化）

com mooc html 程序 ndt wot 面向 tar dmz 3lztmo1xf豪已4茲6http://www.zcool.com.cn/collection/ZMTkxNTY1OTI=.html 6桓50勞爻拍62誹喜0栽2http://www.zcool.c

Java設計模式簡介（四）：行為型模式（下）

其實每個設計模式都是很重要的一種思想，看上去很熟，其實是因為我們在學到的東西中都有涉及，儘管有時我們並不知道，其實在Java本身的設計之中處處都有體現，像AWT、JDBC、集合類、IO管道或者是Web框架，裡面設計模式無處不在。因為我們篇幅有限，很難講每一個設計模式都講的很詳細。 本章講講

Java設計模式簡介（三）：行為型模式（上）

本章講到第三種設計模式——行為型模式，共11種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、直譯器模式。 先來張圖，看看這11中模式的關係： 第一類：通過父類與子類的關係進行實現。第二類：兩個類之間。第三類：類的狀態。第

Spring Boot + Spring Cloud 實現許可權管理系統 後端篇（二十二）：鏈路追蹤（Sleuth、Zipkin）

線上演示 演示地址：http://139.196.87.48:9002/kitty 使用者名稱：admin 密碼：admin 技術背景 在微服務架構中，隨著業務發展，系統拆分導致系統呼叫鏈路愈發複雜，一個看似簡單的前端請求可能最終需要呼叫很多次後端服務才能完成，那麼當整個請求出現問題時，我們很難得知到