分布式數據庫管理系統的發展

單個數據庫分割成多個，然后把這些分割存放到同一網絡中的不同計算機中。多點數據庫是分布式數據庫系統的核心。業務分布在不同的國家和地區需要分布式數據庫管理系統。分布式數據庫系統的復雜性對于終端用戶來說是透明的。分布式數據庫管理系統把分布式數據庫看成單個邏輯的數據庫。分布式數據庫管理系統（distributed database management system, DDBMS）管理在相關計算機系統中邏輯相關的數據存儲和處理，在這個系統中，數據存儲和處理都是分布在不同的地方。集中式數據庫的使用需要公司把數據庫存儲到一個地方，通常這個地方是主機。復雜的分布式數據環境將增加標準協議的緊迫性，需要用這些協議來管理事物處理、并發控制、安全性、備份、恢復、查詢優化、訪問路徑的選擇等。

?

?

?

?

分布式處理（distributed processing）過程中，數據庫處理過程在邏輯上分布到兩個或者兩個以上的物理獨立位置上，而且這些位置可以通過網絡連接。分布式數據庫（distributed database）可以把邏輯相關的數據庫存儲兩個或者兩個以上的物理位置上。在一個分布式數據庫系統中，數據庫由許多部分組成，稱之為數據庫分割（database fragments）。

注意：

分布式處理不是需要一個分布式數據庫，而分布式數據庫需要分布式處理（其局域的數據庫處理負責管理每個數據庫分割）。

分布式處理可能基于單個數據庫，并且該數據庫也是存放在一臺計算機上。由于分布式數據的產生，數據處理功能的副本必須分布到所有的數據存儲位置上。

分布式處理和分布式數據庫都需要通過一個網絡來連接所有的計算機。

?

分布式處理

分布式數據庫管理系統的特征

DBMS至少有以下功能才算得上是分布式的：

在分布式數據庫中，應用層的接口必須連接終端用戶、應用程序和其他DBMS。

對數據進行分析、驗證語法的正確性。

把復雜的請求轉化成簡單的數據請求。

為了找到最好的訪問路徑，需要進行查詢優化（如果操作同步，那么必須知道查詢訪問哪個數據庫部件，怎么更新數據？）。

映射本地和遠程分割的數據位置圖。

I/O接口可以從永久的本地存儲中讀或者寫數據。

調整數據的格式后提交給終端用戶或應用程序。

確保本地和遠程數據庫的數據安全。

發生故障時，為了確保數據庫的有效性和可恢復性，必須進行備份和恢復。

DBA具有數據庫管理的功能。

在DDBMS中，為了管理同時訪問的數據，并且確保在數據庫部件中數據的一致性，必須進行進行并發控制。

為了確保數據從一個一致性狀態中轉換到另一個一致性狀態，必須進行相應的事務管理，包括本地和遠程事務的同步。

分布式數據庫管理系統必須執行集中式DBMS的所有功能：

接受應用層（終端用戶）的請求。

驗證、分析、分解請求。這些請求可能包含數學的或者邏輯的操作，例如，選擇所有余額超過1000的客戶。它可能從一個表中得到數據，也可能需要訪問多個表。

把請求的邏輯數據映射到物理數據。

把請求分解到磁盤I/O操作中。

查找、定位、讀取、驗證數據。

確保數據庫的一致性、安全性和完整性。

根據條件驗證數據。

根據要求保留已有的數據。

另外，DDBMS必須完成所有分布式數據的處理，并且對于終端用戶來說，執行這些功能是透明的。

數據層和分布式處理

單點處理與單點數據

在單點處理與單點數據（single-site processing, single-site data, SPSD）情況下，所有的處理都在一臺主機中進行（單處理服務器、多處理服務器、主機系統），并且所有數據都存儲在主機的本地磁盤系統中。處理不能在終端用戶的系統中執行。

多點處理與單點數據

在多點處理與單點數據（multiple-site processing, multiple-site data, MPSD）情況下，在共享單個數據倉庫的情況下，由不同的計算機來處理數據。通常MPSD需要一個網絡文件服務器，這個服務器可以通過網絡來訪問傳統的應用程序。

多點處理與多點數據

多點處理與多點數據（multiple-site processing, multiple-site data, MPMD）是一個完整的分布式DBMS，它支持多點的數據處理和事務處理。根據集中式DBMS的不同類型，可以把DBMS分為同構和異構的。

同構DDBMS（homogeneous DDBMS）在網絡上僅集成一種集中式DBMS。相比之下，異構DDBMS（heterogeneous DDBMS）在網絡上集成多種集中式DBMS。全異構DDBMS（fully heterogeneous DDBMS）支持不同的DMBS，而這些DBMS可能支持不同的數據模型（關系、層次或者網絡）。這些模型都在不同的計算機系統中運行，如主機和PC。

分布式數據庫的透明性

分布透明性（distribution transparency），把分布式數據庫看成單一的邏輯數據庫。

如果一個DDBMS呈現出分布透明性，那么用戶不需要知道：

數據的分割，即縱向和橫向地把表的行和列分割開并且存儲在多個地方。

數據可以被復制到多個地方。

數據的位置。

事務處理透明性（transaction transparency），運行一個事務在多個地方更新數據。

故障透明性（failure transparency），它保證了系統在一個節點上發生故障時，也能繼續運行。由于故障，丟失的功能將可以從其他網絡節點中找到。

性能透明性（performance transparency），是指系統的運行就像是一個集中式DBMS一樣。

異構透明性（heterogeneity transparency），在通用或全局模型下，異構透明性允許集成多個不同的本地DBMS（關系、網絡和層次）。

事務處理透明性

事務透明性是DDBMS的一個特征，它使數據庫事務保持分布式數據庫的完整性和一致性。請記住，一個DDBMS數據庫事務更新存儲在網絡中相連的不同計算機的數據。事務處理透明性確保在所有數據庫站點的事務處理都完成時，整個事務的處理才算完成。

為了管理事務并且確保數據庫的一致性和完整性，分布式數據庫系統需要復雜的機制。為了理解如何管理事務，應當知道管理遠程請求、遠程事務、分布式事務和分布式請求等基本概念。

分布式請求和分布式事務

一個事務是否時分布式的，主要看它是一個還是多個數據庫請求。非分布式事務與分布式事務之間最基本的區別是，后者可以更新或者請求網上許多不同的遠程數據。

分布式請求

分布式事務

分布式事務

遠程事務的特征：

• 事務會更新站點上的表
• 遠程事務會發送到站點上，并在站點上運行
• 每個事務之可以引用一個遠程DP
• 每個SQL語句在一個時間內只可以引用一個遠程DP，并且整個事務只能有一個遠程DP引用和運行

分布式事務的特征：

• 事務引用了兩個遠程站點
• 在不同的站點上處理不同的請求
• 在同一時候，每個請求只能訪問一個遠程站點

不能從一個遠程站點訪問數據，因此DBMS必須支持分布式請求。

分布式請求允許一個SQL語句可以在多個不同本地或者遠程DP站點引用數據。因為每個請求（SQL語句）都可以從一個本地或者遠程DP站點中訪問數據，一個事務可以訪問多個站點。

事務透明性把分布式事務處理看成是集中式事務，這樣可以確保事務的可串行化。也就是說不論并發事務的執行是否是分布式的，都是將數據庫從一個一致性狀態帶到另一個一致性的狀態。

分布式并發控制

并發控制在分布式數據庫環境中至關重要，因為多站點，多處理器操作比單點系統更可能產生數據的不一致和事務死鎖。例如，在最后的COMMIT執行完并且記錄事務之前，一個DDBMS的TP組件必須確保事務的所有分割都必須在所有站點上執行完。

假設每個本地DP都提交每個事務操作，但是其中有一個DP未提交事務的結果：事務將產生不一致數據庫，不可避免出現完整性問題，因為該提交的數據未能提交。為了解決這個方法，會學習下面的兩階段提交協議。

兩階段提交協議

集中式數據庫僅需要一個DP。所有的數據庫操作僅發生在一個站點上，并且DBMS可以很快地知道數據庫操作的結果。而分布式數據庫使得事務能夠訪問在多個站點的數據。所有的站點都已經執行完它們的事務后才可以提交最后的COMMIT。兩階段的提交協議（two-phase commit protocol）可以保證數據庫狀態的一致性：如果一個事務的一部分操作未能提交，那么對參與事務的其他站點的修改都取消。

每個DP都有自己的事務日志。兩階段提交協議需要在實際更新數據庫部分之前，對每個DP記錄事務日志。因此兩階段提交協議需要一個DO-UNDO-REDO協議和先寫協議。

?

?

根據系統事務的日志，DP用DO-UNDO-REDO協議去會滾或前滾事務。DO-UNDO-REDO協議定義了3中類型的操作：

• DO執行操作并且在事務日志中記錄"之前"和"之后"的值。
• 根據DO的日志記錄，UNDO取消操作。
• 根據DO的日志記錄，REDO重做操作。

為了保證DO、UNDO和REDO在系統崩潰中也能發揮作用，當在執行DO、UNDO、REDO操作時，就必須使用先寫協議（write-ahead protocol）。在實際的操作發生時，先寫協議就把日志寫入永久存儲器中。

兩階段提交協議定義了兩種類型的節點之間的操作：協調器（coordinator）和一個或多個從屬者（subordinate）。參與節點使用的是同一個協調器。通常，協調器的作用是指定開始事務的節點。但是，不同系統實現了不同而且復雜的選舉方法。協議是分兩階段來實現。

第一階段：準備

協調器發送一個PREPARE TO COMMIT信息給所有的從屬者。

從屬者接到這個信息，使用先寫協議，寫入事務日志并發送一個確認信息（YES/PREPARED TO COMMIT或NO/NO PREPARED）給協調器。

協調器確保所有節點要么提交，要么取消。

如果所有節點為PREPARED TO COMMIT，事務調轉到第二階段。如果有一個或多個節點為NO或NO PREPARED協調器就給所有從屬者發送一個ABORT。

第二階段：最后的提交

協調器廣播一個COMMIT信息給所有從屬者并等待回復。

每個從屬者接收到COMMIT信息并且使用DO協議更性數據庫。

從屬者回復一個 COMMITTED或者NOT COMMITTED信息給協調器。

如果一個或者多個從屬者沒有提交，協調器就發送一個ABORT消息，這樣就使它們都取消所有的操作。

兩階段提交的目的是為了確保每個節點都提交事務自己所操作的部分；否則，事務就取消。如果其中一個節點提交失敗，就用事務日志來恢復數據庫的信息，而且使用的是DO-UNDO-REDO協議來恢復（記住使用先寫協議更新日志信息）。

分布式數據庫的設計

數據分割

水平分割

垂直分割

混合分割

數據復制

數據復制（data replication）是指通過計算機網絡把數據存儲復制到多個站點上。為了滿足特殊的信息需求，分割副本可以存儲到多個站點上。因為分割副本的存在能夠增強數據的可用性和響應時間，數據復制還可以減少通信和查詢時間。

數據放置

關于分布式事務、兩階段提交協議、三階提交協議

隨著大型網站的各種高并發訪問、海量數據處理等場景越來越多，如何實現網站的高可用、易伸縮、可擴展、安全等目標就顯得越來越重要。

為了解決這樣一系列問題，大型網站的架構也在不斷發展。提高大型網站的高可用架構，不得不提的就是分布式。在《分布式系統的一致性探討》一文中主要介紹了分布式系統中存在的一致性問題。本文將簡單介紹如何有效的解決分布式的一致性問題，其中包括什么是分布式事務，二階段提交和三階段提交。

分布式一致性回顧

在分布式系統中，為了保證數據的高可用，通常我們會將數據保留多個副本（replica），這些副本會放置在不同的物理的機器上。為了對用戶提供正確的增、刪、改、查等語義，我們需要保證這些放置在不同物理機器上的副本是一致的。

為了解決這種分布式一致性問題，前人在性能和數據一致性的反反復復權衡過程中總結了許多典型的協議和算法。其中比較著名的有二階提交協議（Two Phase Commitment Protocol）、三階提交協議（Two Phase Commitment Protocol）和Paxos算法。

分布式事務

分布式事務是指會涉及到操作多個數據庫的事務。其實就是將對同一庫事務的概念擴大到了對多個庫的事務。目的是為了保證分布式系統中的數據一致性。分布式事務處理的關鍵是必須有一種方法可以知道事務在任何地方所做的所有動作，提交或回滾事務的決定必須產生一致的結果（全部提交或全部回滾）

在分布式系統中，各個節點之間在物理上相互獨立，通過網絡進行溝通和協調。由于存在事務機制，可以保證每個獨立節點上的數據操作可以滿足ACID。但是，相互獨立的節點之間無法準確的知道其他節點中的事務執行情況。所以從理論上講，兩臺機器理論上無法達到一致的狀態。如果想讓分布式部署的多臺機器中的數據保持一致性，那么就要保證在所有節點的數據寫操作，要不全部都執行，要么全部的都不執行。但是，一臺機器在執行本地事務的時候無法知道其他機器中的本地事務的執行結果。所以它也就不知道本次事務到底應該commit還是 rollback。所以，常規的解決辦法就是引入一個"協調者"的組件來統一調度所有分布式節點的執行。

XA規范

X/Open 組織（即現在的 Open Group）定義了分布式事務處理模型。 X/Open DTP 模型（ 1994）包括應用程序（AP）、事務管理器（TM）、資源管理器（RM）、通信資源管理器（CRM）四部分。一般，常見的事務管理器（TM）是交易中間件，常見的資源管理器（RM）是數據庫，常見的通信資源管理器（CRM）是消息中間件。 通常把一個數據庫內部的事務處理，如對多個表的操作，作為本地事務看待。數據庫的事務處理對象是本地事務，而分布式事務處理的對象是全局事務。所謂全局事務，是指分布式事務處理環境中，多個數據庫可能需要共同完成一個工作，這個工作即是一個全局事務，例如，一個事務中可能更新幾個不同的數據庫。對數據庫的操作發生在系統的各處但必須全部被提交或回滾。此時一個數據庫對自己內部所做操作的提交不僅依賴本身操作是否成功，還要依賴與全局事務相關的其它數據庫的操作是否成功，如果任一數據庫的任一操作失敗，則參與此事務的所有數據庫所做的所有操作都必須回滾。一般情況下，某一數據庫無法知道其它數據庫在做什么，因此，在一個 DTP 環境中，交易中間件是必需的，由它通知和協調相關數據庫的提交或回滾。而一個數據庫只將其自己所做的操作（可恢復）影射到全局事務中。

XA 就是 X/Open DTP 定義的交易中間件與數據庫之間的接口規范（即接口函數），交易中間件用它來通知數據庫事務的開始、結束以及提交、回滾等。 XA 接口函數由數據庫廠商提供。

二階提交協議和三階提交協議就是根據這一思想衍生出來的。可以說二階段提交其實就是實現XA分布式事務的關鍵（確切地說：兩階段提交主要保證了分布式事務的原子性：即所有結點要么全做要么全不做）

2PC

二階段提交（Two Phase Commit）是指，在計算機網絡以及數據庫領域內，為了使基于分布式系統架構下的所有節點在進行事務提交時保持一致性而設計的一種算法。通常，二階段提交也被稱為是一種協議（Protocol）。在分布式系統中，每個節點雖然可以知曉自己的操作時成功或者失敗，卻無法知道其他節點的操作的成功或失敗。當一個事務跨越多個節點時，為了保持事務的ACID特性，需要引入一個作為協調者的組件來統一掌控所有節點（稱作參與者）的操作結果并最終指示這些節點是否要把操作結果進行真正的提交（比如將更新后的數據寫入磁盤等等）。因此，二階段提交的算法思路可以概括為：參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋情報決定各參與者是否要提交操作還是中止操作。

所謂的兩個階段是指：第一階段：準備階段（投票階段）和第二階段：提交階段（執行階段）。

準備階段

事務協調者（事務管理器）給每個參與者（資源管理器）發送Prepare消息，每個參與者要么直接返回失敗（如權限驗證失敗），要么在本地執行事務，寫本地的redo和undo日志，但不提交，到達一種"萬事俱備，只欠東風"的狀態。

可以進一步將準備階段分為以下三個步驟：

協調者節點向所有參與者節點詢問是否可以執行提交操作（vote），并開始等待各參與者節點的響應。

參與者節點執行詢問發起為止的所有事務操作，并將undo信息和redo信息寫入日志。（注意：若成功這里其實每個參與者已經執行了事務操作）

各參與者節點響應協調者節點發起的詢問。如果參與者節點的事務操作實際執行成功，則它返回一個"同意"消息；如果參與者節點的事務操作實際執行失敗，則它返回一個"中止"消息。

提交階段

如果協調者收到了參與者的失敗消息或者超時，直接給每個參與者發送回滾（rollback）消息；否則，發送提交（commit）消息；參與者根據協調者的指令執行提交或者回滾操作，釋放所有事務處理過程中使用的鎖資源。（注意：必須在最后階段釋放鎖資源）

接下來分兩種情況分別討論提交階段的過程。

當協調者節點從所有參與者節點獲得的相應消息都為"同意"時：

協調者節點向所有參與者節點發出"正式提交（commit）"的請求。

參與者節點正式完成操作，并釋放在整個事務期間內占用的資源。

參與者節點向協調者節點發送"完成"消息。

協調者節點受到所有參與者節點反饋的"完成"消息后，完成事務。

如果任一參與者節點在第一階段返回的響應消息為"中止"，或者協調者節點在第一階段的詢問超時之前無法獲取所有參與者節點的響應消息時：

協調者節點向所有參與者節點發出"回滾操作（rollback）"的請求。

參與者節點利用之前寫入的undo信息執行回滾，并釋放在整個事務期間內占用的資源。

參與者節點向協調者節點發送”回滾完成”消息。

協調者節點受到所有參與者節點反饋的"回滾完成"消息后，取消事務。

不管最后結果如何，第二階段都會結束當前事務。

二階段提交看起來確實能夠提供原子性的操作，但是不幸的事，二階段提交還是有幾個缺點的：

同步阻塞問題。執行過程中，所有參與節點都是事務阻塞型的。當參與者占有公共資源時，其他第三方節點訪問公共資源不得不處于阻塞狀態。

單點故障。由于協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去。尤其在第二階段，協調者發生故障，那么所有的參與者還都處于鎖定事務資源的狀態中，而無法繼續完成事務操作。（如果是協調者掛掉，可以重新選舉一個協調者，但是無法解決因為協調者宕機導致的參與者處于阻塞狀態的問題）

數據不一致。在二階段提交的階段二中，當協調者向參與者發送commit請求之后，發生了局部網絡異常或者在發送commit請求過程中協調者發生了故障，這回導致只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求之后就會執行commit操作。但是其他部分未接到commit請求的機器則無法執行事務提交。于是整個分布式系統便出現了數據不一致性的現象。

二階段無法解決的問題：協調者在發出commit消息之后宕機，而唯一接收到這條消息的參與者同時也宕機了。那么即使協調者通過選舉協議產生了新的協調者，這條事務的狀態也是不確定的，沒人知道事務是否被已經提交。

由于二階段提交存在著諸如同步阻塞、單點問題、腦裂等缺陷，所以，研究者們在二階段提交的基礎上做了改進，提出了三階段提交。

3PC

三階段提交（Three Phase Commit），也叫三階段提交協議（Three Phase Commit Protocol），是二階段提交（2PC）的改進版本。

與兩階段提交不同的是，三階段提交有兩個改動點。

引入超時機制。同時在協調者和參與者中都引入超時機制。

在第一階段和第二階段中插入一個準備階段。保證了在最后提交階段之前各參與節點的狀態是一致的。

（引入XA規范和2PC、3PC講的很好。但是上面這段話的第2條，在第一階段和第二階段中插入一個準備階段？這么說不容易讓人理解，本來2pc就是準備階段+提交階段。再插入一個準備階段成什么了，很容易讓人誤解。希望作者改正。建議：將準備階段拆分并在請求之前增加了一個狀態確認階段。

提問：3PC的canCommit，參與者進入預備狀態后這個預備狀態可以理解為事務已經開啟了么？）

也就是說，除了引入超時機制之外，3PC把2PC的準備階段再次一分為二，這樣三階段提交就有CanCommit、PreCommit、DoCommit三個階段。

CanCommit階段

3PC的CanCommit階段其實和2PC的準備階段很像。協調者向參與者發送commit請求，參與者如果可以提交就返回Yes響應，否則返回No響應。

1.事務詢問 協調者向參與者發送CanCommit請求。詢問是否可以執行事務提交操作。然后開始等待參與者的響應。

2.響應反饋 參與者接到CanCommit請求之后，正常情況下，如果其自身認為可以順利執行事務，則返回Yes響應，并進入預備狀態。否則反饋No

PreCommit階段

協調者根據參與者的反應情況來決定是否可以進行事務的PreCommit操作。根據響應情況，有以下兩種可能。

假如協調者從所有的參與者獲得的反饋都是Yes響應，那么就會執行事務的預執行。

1. 發送預提交請求協調者向參與者發送PreCommit請求，并進入Prepared階段。

2. 事務預提交 參與者接收到PreCommit請求后，會執行事務操作，并將undo和redo信息記錄到事務日志中。

3. 響應反饋 如果參與者成功的執行了事務操作，則返回ACK響應，同時開始等待最終指令。

假如有任何一個參與者向協調者發送了No響應，或者等待超時之后，協調者都沒有接到參與者的響應，那么就執行事務的中斷。

1.發送中斷請求 協調者向所有參與者發送abort請求。

2.中斷事務 參與者收到來自協調者的abort請求之后（或超時之后，仍未收到協調者的請求），執行事務的中斷。

doCommit階段

該階段進行真正的事務提交，也可以分為以下兩種情況。

執行提交

1. 發送提交請求 協調接收到參與者發送的ACK響應，那么他將從預提交狀態進入到提交狀態。并向所有參與者發送doCommit請求。

2. 事務提交 參與者接收到doCommit請求之后，執行正式的事務提交。并在完成事務提交之后釋放所有事務資源。

3. 響應反饋 事務提交完之后，向協調者發送Ack響應。

4. 完成事務 協調者接收到所有參與者的ack響應之后，完成事務。

中斷事務 協調者沒有接收到參與者發送的ACK響應（可能是接受者發送的不是ACK響應，也可能響應超時），那么就會執行中斷事務。

1.發送中斷請求 協調者向所有參與者發送abort請求

2.事務回滾 參與者接收到abort請求之后，利用其在階段二記錄的undo信息來執行事務的回滾操作，并在完成回滾之后釋放所有的事務資源。

3.反饋結果 參與者完成事務回滾之后，向協調者發送ACK消息

4.中斷事務 協調者接收到參與者反饋的ACK消息之后，執行事務的中斷。

在doCommit階段，如果參與者無法及時接收到來自協調者的doCommit或者rebort請求時，會在等待超時之后，會繼續進行事務的提交。（其實這個應該是基于概率來決定的，當進入第三階段時，說明參與者在第二階段已經收到了PreCommit請求，那么協調者產生PreCommit請求的前提條件是他在第二階段開始之前，收到所有參與者的CanCommit響應都是Yes。（一旦參與者收到了PreCommit，意味他知道大家其實都同意修改了）所以，一句話概括就是，當進入第三階段時，由于網絡超時等原因，雖然參與者沒有收到commit或者abort響應，但是他有理由相信：成功提交的幾率很大。 ）

2PC與3PC的區別

相對于2PC，3PC主要解決的單點故障問題，并減少阻塞，因為一旦參與者無法及時收到來自協調者的信息之后，他會默認執行commit。而不會一直持有事務資源并處于阻塞狀態。但是這種機制也會導致數據一致性問題，因為，由于網絡原因，協調者發送的abort響應沒有及時被參與者接收到，那么參與者在等待超時之后執行了commit操作。這樣就和其他接到abort命令并執行回滾的參與者之間存在數據不一致的情況。

了解了2PC和3PC之后，我們可以發現，無論是二階段提交還是三階段提交都無法徹底解決分布式的一致性問題。Google Chubby的作者Mike Burrows說過，"there is only one consensus protocol, and that's Paxos – all other approaches are just broken versions of Paxos."。意即世上只有一種一致性算法，那就是Paxos，所有其他一致性算法都是Paxos算法的不完整版。后面的文章會介紹這個公認的難以理解但是行之有效的Paxos算法。

參考資料：

分布式協議之兩階段提交協議（2PC）和改進三階段提交協議（3PC）

關于分布式事務、兩階段提交、一階段提交、Best Efforts 1PC模式和事務補償機制的研究

兩階段提交協議與三階段提交協議

轉載于:https://www.cnblogs.com/tuhooo/p/9070222.html

總結

以上是生活随笔為你收集整理的分布式数据库管理系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。