前言
ZooKeeper 是一個分散式的，開放原始碼的分散式應用程式協調服務。它是一個為分散式應用提供一致性服務的軟體，提供的功能包括：配置維護、域名服務、分散式同步、組服務等。
ZooKeeper 的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的介面和效能高效、功能穩定的系統提供給使用者。
ZooKeeper 面試題
1. ZooKeeper 面試題？
2. ZooKeeper 提供了什麼？
3. Zookeeper 檔案系統
4. ZAB 協議？
5. 四種型別的資料節點 Znode
6. Zookeeper Watcher 機制 -- 資料變更通知
7. 客戶端註冊 Watcher 實現
8. 服務端處理 Watcher 實現
9. 客戶端回撥 Watcher
10. ACL 許可權控制機制
11. Chroot 特性
12. 會話管理
13. 伺服器角色
14. Zookeeper 下 Server 工作狀態
15. 資料同步
16. zookeeper 是如何保證事務的順序一致性的？
17. 分散式叢集中為什麼會有 Master？
18. zk 節點當機如何處理？
19. zookeeper 負載均衡和 nginx 負載均衡區別
20. Zookeeper 有哪幾種幾種部署模式？
21. 叢集最少要幾臺機器，叢集規則是怎樣的?
22. 叢集支援動態新增機器嗎？
23. Zookeeper 對節點的 watch 監聽通知是永久的嗎？為什麼不是永久的?
24. Zookeeper 的 java 客戶端都有哪些？
25. chubby 是什麼，和 zookeeper 比你怎麼看？
26. 說幾個 zookeeper 常用的命令。
27. ZAB 和 Paxos 演算法的聯絡與區別？
28. Zookeeper 的典型應用場景
ZooKeeper面試題答案解析
1. ZooKeeper 是什麼？
ZooKeeper 是一個開放原始碼的分散式協調服務，它是叢集的管理者，監視著叢集中各個節點的狀態根據節點提交的反饋進行下一步合理操作。最終，將簡單易用的介面和效能高效、功能穩定的系統提供給使用者。
分散式應用程式可以基於 Zookeeper 實現諸如資料釋出/訂閱、負載均衡、命名服務、分散式協調/通知、叢集管理、Master 選舉、分散式鎖和分散式佇列等功能。
Zookeeper 保證瞭如下分散式一致性特性：
（1）順序一致性
（2）原子性
（3）單一檢視
（4）可靠性
（5）實時性（最終一致性）
客戶端的讀請求可以被叢集中的任意一臺機器處理，如果讀請求在節點上註冊了監聽器，這個監聽器也是由所連線的 zookeeper 機器來處理。對於寫請求，這些請求會同時發給其他 zookeeper 機器並且達成一致後，請求才會返回成功。因此，隨著 zookeeper 的叢集機器增多，讀請求的吞吐會提高但是寫請求的吞吐會下降。
有序性是 zookeeper 中非常重要的一個特性，所有的更新都是全域性有序的，每個更新都有一個唯一的時間戳，這個時間戳稱為 zxid（Zookeeper Transaction Id）。而讀請求只會相對於更新有序，也就是讀請求的返回結果中會帶有這個zookeeper 最新的 zxid。
2. ZooKeeper 提供了什麼？
（1）檔案系統
（2）通知機制
3.Zookeeper 檔案系統
Zookeeper 提供一個多層級的節點名稱空間（節點稱為 znode）。與檔案系統不同的是，這些節點都可以設定關聯的資料，而檔案系統中只有檔案節點可以存放資料而目錄節點不行。
Zookeeper 為了保證高吞吐和低延遲，在記憶體中維護了這個樹狀的目錄結構，這種特性使得 Zookeeper 不能用於存放大量的資料，每個節點的存放資料上限為1M。
4. ZAB 協議？
ZAB 協議是為分散式協調服務 Zookeeper 專門設計的一種支援崩潰恢復的原子廣播協議。
ZAB 協議包括兩種基本的模式：崩潰恢復和訊息廣播。
當整個 zookeeper 叢集剛剛啟動或者 Leader 伺服器當機、重啟或者網路故障導致不存在過半的伺服器與 Leader 伺服器保持正常通訊時，所有程式（伺服器）進入崩潰恢復模式，首先選舉產生新的 Leader 伺服器，然後叢集中 Follower 伺服器開始與新的 Leader 伺服器進行資料同步，當叢集中超過半數機器與該 Leader伺服器完成資料同步之後，退出恢復模式進入訊息廣播模式，Leader 伺服器開始接收客戶端的事務請求生成事物提案來進行事務請求處理。
5. 四種型別的資料節點 Znode
（1）PERSISTENT-持久節點
除非手動刪除，否則節點一直存在於 Zookeeper 上
（2）EPHEMERAL-臨時節點
臨時節點的生命週期與客戶端會話繫結，一旦客戶端會話失效（客戶端與zookeeper 連線斷開不一定會話失效），那麼這個客戶端建立的所有臨時節點都會被移除。
（3）PERSISTENT_SEQUENTIAL-持久順序節點
基本特性同持久節點，只是增加了順序屬性，節點名後邊會追加一個由父節點維護的自增整型數字。
（4）EPHEMERAL_SEQUENTIAL-臨時順序節點
基本特性同臨時節點，增加了順序屬性，節點名後邊會追加一個由父節點維護的自增整型數字。
6. Zookeeper Watcher 機制 -- 資料變更通知
Zookeeper 允許客戶端向服務端的某個 Znode 註冊一個 Watcher 監聽，當服務端的一些指定事件觸發了這個 Watcher，服務端會向指定客戶端傳送一個事件通知來實現分散式的通知功能，然後客戶端根據 Watcher 通知狀態和事件型別做出業務上的改變。
工作機制：
（1）客戶端註冊 watcher
（2）服務端處理 watcher
（3）客戶端回撥 watcher
Watcher 特性總結：
（1）一次性
無論是服務端還是客戶端，一旦一個 Watcher 被 觸 發 ，Zookeeper 都會將其從相應的儲存中移除。這樣的設計有效的減輕了服務端的壓力，不然對於更新非常頻繁的節點，服務端會不斷的向客戶端傳送事件通知，無論對於網路還是服務端的壓力都非常大。
（2）客戶端序列執行
客戶端 Watcher 回撥的過程是一個序列同步的過程。
（3）輕量
3.1、Watcher 通知非常簡單，只會告訴客戶端發生了事件，而不會說明事件的具體內容。
3.2、客戶端向服務端註冊 Watcher 的時候，並不會把客戶端真實的 Watcher 物件實體傳遞到服務端，僅僅是在客戶端請求中使用 boolean 型別屬性進行了標記。
（4）watcher event 非同步傳送 watcher 的通知事件從 server 傳送到 client 是非同步的，這就存在一個問題，不同的客戶端和伺服器之間通過 socket 進行通訊，由於網路延遲或其他因素導致客戶端在不通的時刻監聽到事件，由於 Zookeeper 本身提供了 ordering guarantee，即客戶端監聽事件後，才會感知它所監視 znode發生了變化。所以我們使用 Zookeeper 不能期望能夠監控到節點每次的變化。Zookeeper 只能保證最終的一致性，而無法保證強一致性。
（5）註冊 watcher getData、exists、getChildren
（6）觸發 watcher create、delete、setData
（7）當一個客戶端連線到一個新的伺服器上時，watch 將會被以任意會話事件觸發。當與一個伺服器失去連線的時候，是無法接收到 watch 的。而當 client 重新連線時，如果需要的話，所有先前註冊過的 watch，都會被重新註冊。通常這是完全透明的。只有在一個特殊情況下，watch 可能會丟失：對於一個未建立的 znode的 exist watch，如果在客戶端斷開連線期間被建立了，並且隨後在客戶端連線上之前又刪除了，這種情況下，這個 watch 事件可能會被丟失。
7. 客戶端註冊 Watcher 實現
（1）呼叫 getData()/getChildren()/exist()三個 API，傳入 Watcher 物件
（2）標記請求 request，封裝 Watcher 到 WatchRegistration
（3）封裝成 Packet 物件，發服務端傳送 request
（4）收到服務端響應後，將 Watcher 註冊到 ZKWatcherManager 中進行管理
（5）請求返回，完成註冊。
8. 服務端處理 Watcher 實現
（1）服務端接收 Watcher 並儲存
接收到客戶端請求，處理請求判斷是否需要註冊 Watcher，需要的話將資料節點的節點路徑和 ServerCnxn（ServerCnxn 代表一個客戶端和服務端的連線，實現了 Watcher 的 process 介面，此時可以看成一個 Watcher 物件）儲存在WatcherManager 的 WatchTable 和 watch2Paths 中去。
（2）Watcher 觸發
以服務端接收到 setData() 事務請求觸發 NodeDataChanged 事件為例：
2.1 封裝 WatchedEvent
將通知狀態（SyncConnected）、事件型別（NodeDataChanged）以及節點路徑封裝成一個 WatchedEvent 物件
2.2 查詢 Watcher
從 WatchTable 中根據節點路徑查詢 Watcher
2.3 沒找到；說明沒有客戶端在該資料節點上註冊過 Watcher
2.4 找到；提取並從 WatchTable 和 Watch2Paths 中刪除對應 Watcher（從這裡可以看出 Watcher 在服務端是一次性的，觸發一次就失效了）
（3）呼叫 process 方法來觸發 Watcher
這裡 process 主要就是通過 ServerCnxn 對應的 TCP 連線傳送 Watcher 事件通知。
9. 客戶端回撥 Watcher
客戶端 SendThread 執行緒接收事件通知，交由 EventThread 執行緒回撥 Watcher。
客戶端的 Watcher 機制同樣是一次性的，一旦被觸發後，該 Watcher 就失效了。
10. ACL 許可權控制機制
UGO（User/Group/Others）
目前在 Linux/Unix 檔案系統中使用，也是使用最廣泛的許可權控制方式。是一種粗粒度的檔案系統許可權控制模式。
ACL（Access Control List）訪問控制列表
包括三個方面：
許可權模式（Scheme）
（1）IP：從 IP 地址粒度進行許可權控制
（2）Digest：最常用，用類似於 username:password 的許可權標識來進行許可權配置，便於區分不同應用來進行許可權控制
（3）World：最開放的許可權控制方式，是一種特殊的 digest 模式，只有一個許可權標識“world:anyone”
（4）Super：超級使用者
授權物件
授權物件指的是許可權賦予的使用者或一個指定實體，例如 IP 地址或是機器燈。
許可權 Permission
（1）CREATE：資料節點建立許可權，允許授權物件在該 Znode 下建立子節點
（2）DELETE：子節點刪除許可權，允許授權物件刪除該資料節點的子節點
（3）READ：資料節點的讀取許可權，允許授權物件訪問該資料節點並讀取其資料內容或子節點列表等
（4）WRITE：資料節點更新許可權，允許授權物件對該資料節點進行更新操作
（5）ADMIN：資料節點管理許可權，允許授權物件對該資料節點進行 ACL 相關設定操作
11. Chroot 特性
3.2.0 版本後，新增了 Chroot 特性，該特性允許每個客戶端為自己設定一個名稱空間。如果一個客戶端設定了 Chroot，那麼該客戶端對伺服器的任何操作，都將會被限制在其自己的名稱空間下。
通過設定 Chroot，能夠將一個客戶端應用於 Zookeeper 服務端的一顆子樹相對應，在那些多個應用公用一個 Zookeeper 進群的場景下，對實現不同應用間的相互隔離非常有幫助。
12. 會話管理
分桶策略：將類似的會話放在同一區塊中進行管理，以便於 Zookeeper 對會話進行不同區塊的隔離處理以及同一區塊的統一處理。
分配原則：每個會話的“下次超時時間點”（ExpirationTime）
計算公式：
ExpirationTime_ = currentTime + sessionTimeout
ExpirationTime = (ExpirationTime_ / ExpirationInrerval + 1) *
ExpirationInterval , ExpirationInterval 是指 Zookeeper 會話超時檢查時間間隔，預設 tickTime
13. 伺服器角色
Leader
（1）事務請求的唯一排程和處理者，保證叢集事務處理的順序性
（2）叢集內部各服務的排程者
Follower
（1）處理客戶端的非事務請求，轉發事務請求給 Leader 伺服器
（2）參與事務請求 Proposal 的投票
（3）參與 Leader 選舉投票
Observer
（1）3.0 版本以後引入的一個伺服器角色，在不影響叢集事務處理能力的基礎上提升叢集的非事務處理能力
（2）處理客戶端的非事務請求，轉發事務請求給 Leader 伺服器
（3）不參與任何形式的投票
14. Zookeeper 下 Server 工作狀態
伺服器具有四種狀態，分別是 LOOKING、FOLLOWING、LEADING、OBSERVING。
（1）LOOKING：尋 找 Leader 狀態。當伺服器處於該狀態時，它會認為當前叢集中沒有 Leader，因此需要進入 Leader 選舉狀態。
（2）FOLLOWING：跟隨者狀態。表明當前伺服器角色是 Follower。
（3）LEADING：領導者狀態。表明當前伺服器角色是 Leader。
（4）OBSERVING：觀察者狀態。表明當前伺服器角色是 Observer。
15. 資料同步
整個叢集完成 Leader 選舉之後，Learner（Follower 和 Observer 的統稱）迴向Leader 伺服器進行註冊。當 Learner 伺服器想 Leader 伺服器完成註冊後，進入資料同步環節。
資料同步流程：（均以訊息傳遞的方式進行）
Learner 向 Learder 註冊
資料同步
同步確認
Zookeeper 的資料同步通常分為四類：
（1）直接差異化同步（DIFF 同步）
（2）先回滾再差異化同步（TRUNC+DIFF 同步）
（3）僅回滾同步（TRUNC 同步）
（4）全量同步（SNAP 同步）
在進行資料同步前，Leader 伺服器會完成資料同步初始化：
peerLastZxid：
· 從 learner 伺服器註冊時傳送的 ACKEPOCH 訊息中提取 lastZxid（該Learner 伺服器最後處理的 ZXID）
minCommittedLog：
· Leader 伺服器 Proposal 快取佇列 committedLog 中最小 ZXIDmaxCommittedLog：
· Leader 伺服器 Proposal 快取佇列 committedLog 中最大 ZXID直接差異化同步（DIFF 同步）
· 場景：peerLastZxid 介於 minCommittedLog 和 maxCommittedLog之間先回滾再差異化同步（TRUNC+DIFF 同步）
· 場景：當新的 Leader 伺服器發現某個 Learner 伺服器包含了一條自己沒有的事務記錄，那麼就需要讓該 Learner 伺服器進行事務回滾--回滾到 Leader伺服器上存在的，同時也是最接近於 peerLastZxid 的 ZXID僅回滾同步（TRUNC 同步）
· 場景：peerLastZxid 大於 maxCommittedLog
全量同步（SNAP 同步）
· 場景一：peerLastZxid 小於 minCommittedLog
· 場景二：Leader 伺服器上沒有 Proposal 快取佇列且 peerLastZxid 不等於 lastProcessZxid
16. zookeeper 是如何保證事務的順序一致性的？
zookeeper 採用了全域性遞增的事務 Id 來標識，所有的 proposal（提議）都在被提出的時候加上了 zxid，zxid 實際上是一個 64 位的數字，高 32 位是 epoch（ 時期; 紀元; 世; 新時代）用來標識 leader 週期，如果有新的 leader 產生出來，epoch會自增，低 32 位用來遞增計數。當新產生 proposal 的時候，會依據資料庫的兩階段過程，首先會向其他的 server 發出事務執行請求，如果超過半數的機器都能執行並且能夠成功，那麼就會開始執行。
17. 分散式叢集中為什麼會有 Master？
在分散式環境中，有些業務邏輯只需要叢集中的某一臺機器進行執行，其他的機器可以共享這個結果，這樣可以大大減少重複計算，提高效能，於是就需要進行leader 選舉。
18. zk 節點當機如何處理？
Zookeeper 本身也是叢集，推薦配置不少於 3 個伺服器。Zookeeper 自身也要保證當一個節點當機時，其他節點會繼續提供服務。
如果是一個 Follower 當機，還有 2 臺伺服器提供訪問，因為 Zookeeper 上的資料是有多個副本的，資料並不會丟失；
如果是一個 Leader 當機，Zookeeper 會選舉出新的 Leader。
ZK 叢集的機制是隻要超過半數的節點正常，叢集就能正常提供服務。只有在 ZK節點掛得太多，只剩一半或不到一半節點能工作，叢集才失效。
所以
3 個節點的 cluster 可以掛掉 1 個節點(leader 可以得到 2 票>1.5)
2 個節點的 cluster 就不能掛掉任何 1 個節點了(leader 可以得到 1 票<=1)
19. zookeeper 負載均衡和 nginx 負載均衡區別
zk 的負載均衡是可以調控，nginx 只是能調權重，其他需要可控的都需要自己寫外掛；但是 nginx 的吞吐量比 zk 大很多，應該說按業務選擇用哪種方式。
20. Zookeeper 有哪幾種幾種部署模式？
部署模式：單機模式、偽叢集模式、叢集模式。
21. 叢集最少要幾臺機器，叢集規則是怎樣的?
叢集規則為 2N+1 臺，N>0，即 3 臺。
22. 叢集支援動態新增機器嗎？
其實就是水平擴容了，Zookeeper 在這方面不太好。兩種方式：
全部重啟：關閉所有 Zookeeper 服務，修改配置之後啟動。不影響之前客戶端的會話。
逐個重啟：在過半存活即可用的原則下，一臺機器重啟不影響整個叢集對外提供服務。這是比較常用的方式。
3.5 版本開始支援動態擴容。
23. Zookeeper 對節點的 watch 監聽通知是永久的嗎？為什麼不是永久的?
不是。官方宣告：一個 Watch 事件是一個一次性的觸發器，當被設定了 Watch的資料發生了改變的時候，則伺服器將這個改變傳送給設定了 Watch 的客戶端，以便通知它們。
為什麼不是永久的，舉個例子，如果服務端變動頻繁，而監聽的客戶端很多情況下，每次變動都要通知到所有的客戶端，給網路和伺服器造成很大壓力。
一般是客戶端執行 getData(“/節點 A”,true)，如果節點 A 發生了變更或刪除，客戶端會得到它的 watch 事件，但是在之後節點 A 又發生了變更，而客戶端又沒有設定 watch 事件，就不再給客戶端傳送。
在實際應用中，很多情況下，我們的客戶端不需要知道服務端的每一次變動，我只要最新的資料即可。
24. Zookeeper 的 java 客戶端都有哪些？
java 客戶端：zk 自帶的 zkclient 及 Apache 開源的 Curator。
25. chubby 是什麼，和 zookeeper 比你怎麼看？
chubby 是 google 的，完全實現 paxos 演算法，不開源。zookeeper 是 chubby的開源實現，使用 zab 協議，paxos 演算法的變種。
26. 說幾個 zookeeper 常用的命令。
常用命令：ls get set create delete 等。
27. ZAB 和 Paxos 演算法的聯絡與區別？
相同點：
（1）兩者都存在一個類似於 Leader 程式的角色，由其負責協調多個 Follower 程式的執行
（2）Leader 程式都會等待超過半數的 Follower 做出正確的反饋後，才會將一個提案進行提交
（3）ZAB 協議中，每個 Proposal 中都包含一個 epoch 值來代表當前的 Leader週期，Paxos 中名字為 Ballot
不同點：
ZAB 用來構建高可用的分散式資料主備系統（Zookeeper），Paxos 是用來構建分散式一致性狀態機系統。
28. Zookeeper 的典型應用場景
Zookeeper 是一個典型的釋出/訂閱模式的分散式資料管理與協調框架，開發人員可以使用它來進行分散式資料的釋出和訂閱。
通過對 Zookeeper 中豐富的資料節點進行交叉使用，配合 Watcher 事件通知機制，可以非常方便的構建一系列分散式應用中年都會涉及的核心功能，如：
（1）資料釋出/訂閱
（2）負載均衡
（3）命名服務
（4）分散式協調/通知
（5）叢集管理
（6）Master 選舉
（7）分散式鎖
（8）分散式佇列
資料釋出/訂閱
介紹
資料釋出/訂閱系統，即所謂的配置中心，顧名思義就是釋出者釋出資料供訂閱者進行資料訂閱。
目的
動態獲取資料（配置資訊）
實現資料（配置資訊）的集中式管理和資料的動態更新
設計模式
Push 模式
Pull 模式
資料（配置資訊）特性
（1）資料量通常比較小
（2）資料內容在執行時會發生動態更新
（3）叢集中各機器共享，配置一致
如：機器列表資訊、執行時開關配置、資料庫配置資訊等
基於 Zookeeper 的實現方式
· 資料儲存：將資料（配置資訊）儲存到 Zookeeper 上的一個資料節點
· 資料獲取：應用在啟動初始化節點從 Zookeeper 資料節點讀取資料，並在該節點上註冊一個資料變更 Watcher
· 資料變更：當變更資料時，更新 Zookeeper 對應節點資料，Zookeeper會將資料變更通知發到各客戶端，客戶端接到通知後重新讀取變更後的資料即可。
負載均衡
zk 的命名服務
命名服務是指通過指定的名字來獲取資源或者服務的地址，利用 zk 建立一個全域性的路徑，這個路徑就可以作為一個名字，指向叢集中的叢集，提供的服務的地址，或者一個遠端的物件等等。
分散式通知和協調
對於系統排程來說：操作人員傳送通知實際是通過控制檯改變某個節點的狀態，然後 zk 將這些變化傳送給註冊了這個節點的 watcher 的所有客戶端。
對於執行情況彙報：每個工作程式都在某個目錄下建立一個臨時節點。並攜帶工作的進度資料，這樣彙總的程式可以監控目錄子節點的變化獲得工作進度的實時的全域性情況。
zk 的命名服務（檔案系統）
命名服務是指通過指定的名字來獲取資源或者服務的地址，利用 zk 建立一個全域性的路徑，即是唯一的路徑，這個路徑就可以作為一個名字，指向叢集中的叢集，提供的服務的地址，或者一個遠端的物件等等。
zk 的配置管理（檔案系統、通知機制）
程式分散式的部署在不同的機器上，將程式的配置資訊放在 zk 的 znode 下，當有配置發生改變時，也就是 znode 發生變化時，可以通過改變 zk 中某個目錄節點的內容，利用 watcher 通知給各個客戶端，從而更改配置。
Zookeeper 叢集管理（檔案系統、通知機制）
所謂叢集管理無在乎兩點：是否有機器退出和加入、選舉 master。
對於第一點，所有機器約定在父目錄下建立臨時目錄節點，然後監聽父目錄節點
的子節點變化訊息。一旦有機器掛掉，該機器與 zookeeper 的連線斷開，其所建立的臨時目錄節點被刪除，所有其他機器都收到通知：某個兄弟目錄被刪除，於是，所有人都知道：它上船了。
新機器加入也是類似，所有機器收到通知：新兄弟目錄加入，highcount 又有了，對於第二點，我們稍微改變一下，所有機器建立臨時順序編號目錄節點，每次選取編號最小的機器作為 master 就好。
Zookeeper 分散式鎖（檔案系統、通知機制）
有了 zookeeper 的一致性檔案系統，鎖的問題變得容易。鎖服務可以分為兩類，一個是保持獨佔，另一個是控制時序。
對於第一類，我們將 zookeeper 上的一個 znode 看作是一把鎖，通過 createznode的方式來實現。所有客戶端都去建立 /distribute_lock 節點，最終成功建立的那個客戶端也即擁有了這把鎖。用完刪除掉自己建立的 distribute_lock 節點就釋放出鎖。
對於第二類， /distribute_lock 已經預先存在，所有客戶端在它下面建立臨時順序編號目錄節點，和選 master 一樣，編號最小的獲得鎖，用完刪除，依次方便。
Zookeeper 佇列管理（檔案系統、通知機制）
兩種型別的佇列：
（1）同步佇列，當一個佇列的成員都聚齊時，這個佇列才可用，否則一直等待所有成員到達。
（2）佇列按照 FIFO 方式進行入隊和出隊操作。
第一類，在約定目錄下建立臨時目錄節點，監聽節點數目是否是我們要求的數目。
第二類，和分散式鎖服務中的控制時序場景基本原理一致，入列有編號，出列按編號。在特定的目錄下建立 PERSISTENT_SEQUENTIAL 節點，建立成功時Watcher 通知等待的佇列，佇列刪除序列號最小的節點用以消費。此場景下Zookeeper 的 znode 用於訊息儲存，znode 儲存的資料就是訊息佇列中的訊息內容，SEQUENTIAL 序列號就是訊息的編號，按序取出即可。由於建立的節點是持久化的，所以不必擔心佇列訊息的丟失問題。
歡迎大家關注我的公眾號【程式設計師追風】，2019年多家公司java面試題整理了1000多道400多頁pdf文件，文章都會在裡面更新，整理的資料也會放在裡面。
最後
歡迎大家一起交流，喜歡文章記得關注我點個贊喲，感謝支援！