面向進程模型是一種數(shù)據(jù)庫系統(tǒng)的架構模型，核心思想是將不同的數(shù)據(jù)庫服務分配給不同的進程，每個進程獨立運行，相互之間通過進程間通信（IPC）進行協(xié)作。這種模型被廣泛應用于數(shù)據(jù)庫系統(tǒng)中，例如 PostgreSQL 數(shù)據(jù)庫系統(tǒng)。 正如上文所說，進程模型使得 PostgreSQL 可以將不同的服務分配給多個進程獨立運行，每個進程負責不同的任務，例如查詢處理、并發(fā)控制、鎖管理等。進程模型還可以可以保證系統(tǒng)的穩(wěn)定性和可靠性。當一個進程出現(xiàn)問題時，不會影響到其他進程的正常運行，從而提高了系統(tǒng)的可用性。 這樣的特點使得 PostgreSQL 可以同時處理大量的并發(fā)請求，提高了系統(tǒng)的性能和響應速度；除此之外，PostgreSQL 還可以很容易地進行水平擴展，增加更多的節(jié)點以應對更高的負載。不過與此同時，也讓 PostgreSQL 面對著管理和維護成本相對較高、需要較為復雜的進程間通信和協(xié)調(diào)機制、需要消耗更多的系統(tǒng)資源等缺點。 6 月初，Heikki Linnakangas 發(fā)布了將 PostgreSQL 轉為線程模型的提案。 線程模型是一種數(shù)據(jù)庫系統(tǒng)的架構模型，與面向進程模型類似，它是將不同的數(shù)據(jù)庫服務分配給不同的線程，每個線程獨立運行，相互之間通過線程間通信進行協(xié)作。線程模型在一些輕量級的數(shù)據(jù)庫系統(tǒng)中得到廣泛應用，例如 SQLite。 線程模型與進程模型的最大區(qū)別在于，線程模型中所有的線程共享同一個進程的地址空間，每個線程有自己的堆棧，共享代碼段和數(shù)據(jù)段。這意味著線程之間可以直接訪問同一份內(nèi)存，因此線程間通信的成本相對較低，不過這也意味著線程間的數(shù)據(jù)共享可能會帶來安全性問題。 從進程模型轉換成線程模型的優(yōu)缺點： 優(yōu)點

更輕量級：線程模型相對于進程模型更加輕量級，可以更加高效地使用系統(tǒng)資源，尤其是在單機上運行多個實例時，線程模型可以將多個實例運行在同一個進程中，減少了系統(tǒng)調(diào)用和進程間通信帶來的開銷。

更高的響應速度：線程模型中線程之間的通信成本相對較低，因此在高并發(fā)場景下具有更高的響應速度。

更少的內(nèi)存占用：線程模型中線程共享同一份地址空間，因此可以避免進程模型中同一份代碼和數(shù)據(jù)被多個進程重復加載到內(nèi)存的問題，節(jié)省了系統(tǒng)內(nèi)存占用。

缺點

安全性問題：線程之間共享同一份內(nèi)存，可能會帶來安全性問題，例如數(shù)據(jù)競爭和鎖競爭等。

可靠性問題：線程模型中一個線程崩潰可能會影響到整個進程的穩(wěn)定性和可靠性。

多線程編程難度較大：線程之間的通信需要進行同步和互斥，編寫多線程程序的難度相對較大。

PostgreSQL 開發(fā)者、EnterpriseDB 高級數(shù)據(jù)庫架構師 Andres Freund 指出：

我認為原有流程模型開始產(chǎn)生諸多限制，這個問題在大型設備上體現(xiàn)得尤其明顯。跨進程上下文切換所帶來的開銷，原本就比在同一進程內(nèi)的不同線程間切換要更高 —— 我估計這種開銷還將持續(xù)提升。面對大量連接，整個體系最終一定會因 TLB 未命中而浪費大量時間。這是進程模型無法跨進程共享 TLB 的天然屬性造成的必然結果。

目前這還僅僅只是一項提議，并且由于 PostgreSQL 被廣泛用于生產(chǎn)環(huán)境，轉換到線程模型的過程需要非常謹慎。開發(fā)團隊需要在不影響現(xiàn)有生產(chǎn)環(huán)境的情況下測試新的線程模型，以確保其穩(wěn)定性和可靠性。即便這個提議通過，這個轉化過程肯定也是無法通過單一版本徹底完成，從網(wǎng)上的各方評價來看，目前大多數(shù)人都支持這項提議。