web架構延變

2021-07-31 03:57:33 字數 3450 閱讀 4648

在現代的軟體系統中,幾乎所有的系統都使用到了資料庫,不論是關係型資料,例如mysql、sqlite、oracle、sqlserver等,還是非關係性資料,例如mongodb、redis等。本文已web系統為例來闡述為什麼要降低資料庫的壓力,在提出具體方案之前先大致講解一下現在web系統的架構,要了解web系統的架構和演變過程具體可以參考大型**架構演變和知識體系這片文章。

現在的大型web系統多採用分布式的架構,分布式系統面臨的最大挑戰就是如何在複雜的、併發的情況下保證資料的一致性問題。通常為了避免由於保證資料一致性問題而帶來的困難,通常情況下都是採用多個例項,單個資料來源的架構模式,簡化模式如圖。 

在這個架構中,通過不斷的增加例項(webserver)可以降低應用伺服器的壓力,所以只要保證應用**的質量、應用之間的低耦合性、可擴充套件性和可維護性等,應用伺服器的壓力就不再會成為整體架構中效能瓶頸,但是隨著業務量的不斷增加增長,或者時間的積累,沉澱下來的資料變得越來越來多,隨著而來的資料庫的壓力變得越來越大,慢慢的效能的瓶頸主要集中在資料庫上。

表索引可以加快對錶中資料的檢索速度,但是會降低表中資料的更新速度,所以增加表的索引一定控制在合理範圍內,過多的索引不但不會降低資料庫的壓力,反而可能增大資料庫的壓力,表索引的建立一般要從具體業務場景出發,對於讀多寫少的場景,可以通過適當的增加索引來提高效率,對錶的那些列建立索引?建立單獨索引還是建立復合索引?要根據具體的業務場景來決定,建立索引之後可以針對索引對業務邏輯中使用的sql進行優化,建立索引是最基礎的手段,這裡不錯過多的介紹。

一般情況下,業務中所處理的資料的都具有一定的時間間隔,所以可以通過對業務進行梳理,將當前時間間隔之外的資料進行截轉,截轉到歷史資料庫中,通過對業務進行拆分,當需要歷史資料時,可以轉到歷史資料庫中進行查詢,或者修改,通過減少當前資料庫的資料量,來減輕當前業務資料的壓力。資料截轉一般情況下是按照時間來進行,所以在業務員資料庫設計的時候就要考慮到時間這個因素。 

資料截轉可以進行間隔一段時間做一次手工的資料截轉,也可以啟動乙個定時器,每個一段時間進行一次資料截轉,推薦的方式是準實時截轉,及每天在業務量較小的時間,啟動任務實時截轉。 

資料截轉需要注意的幾個問題:(1)外來鍵關聯關係(特別是有主鍵id的關聯的)注意在截轉的歷史資料庫中的關聯關係是否正確。(2)保證生產庫和歷史庫的業務關聯關係,從而避免歷史庫的資料需要關聯生產庫中的資料。

快取是降低資料壓力乙個強有力的手段,基本是所有系統大型web系統中都會使用到,所以現代的大型web系統的架構一般如圖。 

請求1到達webserver之後,首先執行2訪問快取,如果hit則返回,miss則執行3訪問資料庫,在執行4同步到快取中,再返回。但是不是快取並不是萬能的,快取也有其使用的業務場景,一般在讀多寫少,資料重複查詢比較集中的場景下,快取可以大大提高效能,快取操作順序非常重要,不合理的操作順序,在併發場景下常常會導致資料的不一致,快取的具體操作可以參考快取架構設計細節二三事這邊文章。

有些業務例如報表、資料彙總等需要資料量較多,此時可能需要進行多表聯合查詢,聯合查詢操作非常消耗資料庫的效能,所以在這種業務場景下為了避免過大的效能消耗,往往需要將查詢時的多個表按照關聯條件進行關聯,生成一張含有冗餘資訊的包含所有表的多個欄位的大寬表,這樣在進行查詢時,只在一張表中進行查詢,效能明顯得到提公升。大寬表的生成是在業務流程中生成還是通過非同步化任務來生成,根據具體的業務邏輯來定。

非關係型資料庫,也就是我們通常說的nosql資料,最常見就是key/value型別的資料庫,這類資料庫不強調表的關係,但是查詢速度非常快,所在某些具體場景下,我們應該優先選擇nosql資料庫,例如字典資訊表的查詢。

如果採用單點資料資料庫,就算對資料進行上述的相關優化,但是由於其本身的單點性,所以隨著流量的激增,資料庫仍然會成為系統的瓶頸,如何對資料進行拆分來解決這個問題了,讀寫分離就是最常用的方法,讀寫分離的原理如下圖。 

讀寫分離技術現在已經應用的很成熟,通過將資料拆分為兩個例項,讀寫分離操作改善了資料單點的瓶頸,分攤了資料庫壓力,而且當主資料庫宕機之後可以迅速的切換到從庫,而不會導致業務不可用,同時也起到資料備份的作用,由於存在兩個資料例項,所以資料怎麼由主庫同步到從庫、主從之間延遲引發的資料不一致問題,以及怎麼來分離業務中讀和寫操作成為要解決的問題成為要解決的問題。主從同步可以參考mysql主從架構的複製原理及配置這篇文章,從主資料一致可以參考db主從一致性的幾種解決方法這篇文章。

採用讀寫分離之後,資料庫已經變為兩份例項,資料庫的壓力已經得到分攤,如果資料庫的壓力還是過大時,這是就要從業務方面著手,將具體業務細分,將業務對應的表分拆到不同的資料庫當中,如下圖。 

業務變動較大,同時要對系統內部之間的相互呼叫提供介面,呼叫方式可以選用rpc、restful、jmq訊息等方式。一般情況下,資料庫垂直拆分做的足夠細分的話,加上讀寫分離技術,加上適當的資料截轉就可以滿足一般的大型業務系統對效能的需求。

資料庫可以進行垂直拆分,當然也可以對資料庫中的表進行垂直拆分,對錶進行拆分就是對資料拆分的再拆分,如圖。種解決方法只適用於一些特定的場景,例如對錶進行垂直拆分,通過非同步化呼叫將所有任務非同步化,前提是總的任務可以進行分布的非同步化操作,在實際應用比較少,因為設計的表只要復合三正規化的要求,一般是很難在進行拆分的,應用較多是對錶進行水平拆分。 

如果已經做了資料庫拆分,並且進行了讀寫分離,資料壓力還是過大,主要原因就是資料庫表中的記錄太多,或者對資料進行了截轉,但是對歷史資料的操作還是比較頻繁的,且隨著截轉的歷史資料越來越多,歷史資料庫的壓力也邊的也變的越來越大,這時有兩種解決方案:第一種方案就是對資料庫中的表進行垂直拆分,從而不用在截轉資料,通過不斷對錶進行水平拆分,保證資料資料庫中單錶的記錄數保持在乙個高效能合理的範圍之類,通過擴容將不同分配到不同的資料中(分庫分表)來保證資料庫的壓力,應用在訪問時,通過分庫分表的條件進行路由,就可以取到資料。第二種就是仍舊對資料進行截轉,當歷史資料資訊過多從而導致資料庫壓力過大時,採用搜尋引擎的方式來解決。相比於第一種操作第二種方案適用於讀操作上,對與寫操作,具有一定的侷限性,第一種方案具有一定的通用性。對錶進行水平拆分的過程如圖所示。 

在進行進行具體水平拆分之前,我們需要考慮這樣幾個問題

制定什麼樣的路由規則

如何盡量避免跨庫或者跨表操作

如何盡可能的避免全庫全表掃瞄

如何保證每個庫的負載處於基本盡可能均衡的狀態

如何實時跨庫訪問事物

如何實時聚合操作

如何保證擴容的方便性

web系統架構

前端頁面快取技術,例如squid,如想用好的話還得深入掌握下squid的實現方式以及快取的失效演算法等。頁面片段快取技術,例如esi等,想用好的話同樣需要掌握esi的實現方式等 架構演變第五步 增加webserver 負載均衡技術 包括但不限於硬體負載均衡 軟體負載均衡 負載演算法 linux 協議...

web安全新架構

pki體制中,由第三方安全伺服器如hkp 負責分發通訊公鑰,或者由瀏覽器預裝 主動匯入證書的方式進行。在雲安全世界,mathematical mesh infrastracture更為合理,容易進行多使用者裝置之間configuration和 credential data的交換。mathemati...

web應用基礎架構

中介軟體是一類連線軟體元件和應用的計算機軟體,它包括一組服務。以便執行在一台或多台伺服器上的多個軟體通過網路進行互動。該技術所提供的互操作性,推動了一致分布式體系架構的演進,該架構通常用於支援並簡化那些複雜的分布式應用程式,它包括web伺服器 事務監控器和訊息佇列軟體。中介軟體 middleware...