系統內部矛盾的解決思路

最近在項目裏面遇到一個比較難以解決的問題,簡單的說就是查詢問題。web

某一張表的數據量比較大,不少業務都會根據條件來查詢相關的數據,查詢主要分爲兩類,一類是業務查詢,可以根據指定的條件查詢出相關的數據,數據量比較小,查詢速度快,一類是後臺查詢,偏向數據分析,特色是查詢耗時長,查詢數據量比較大。
因爲大量系統訪問這個數據庫,那麼對數據源鏈接的實時性要求就比較高,若是後臺查詢大量佔用數據源的鏈接,會影響到外部業務,從而影響業務功能的穩定性。
 
如何解決這個問題,在通常的狀況下,咱們首先會考慮設置一個合理的超時時間,因爲業務查詢都是大可能是根據關鍵字查詢,耗費時間都會在幾十毫秒之下,不多會有大量長耗時的sql,後臺的查詢耗時比較長,若是設置較小的查詢超時時間,會致使沒法查詢出來結果。那麼就根據後臺的查詢耗時的平均時間,設置一個合理值。這種作法相對來講比較簡單,可是會有潛在的風險。可能在默寫特殊狀況下,業務的查詢也會存在熱點數據,就是根據這些業務關鍵字的查詢廣泛耗時比較長,若是業務系統短期內大量的熱點數據查詢,則會佔用大量的數據源鏈接,從而影響正常的業務。尤爲是在查詢系統沒法評估有那些潛在的長耗時查詢的時候,系統就處於這種不可預測的有風險的階段。
 
第二種方案,就是簡單的區分這兩種查詢。咱們先解決的問題是後臺查詢超時的問題,若是採用上面的方案,則會影響其餘的業務系統。那麼能夠考慮把影響面侷限於後臺查詢。把問題所涉及到的關注點進行分離。就是長耗時和短耗時的問題,那麼就配置兩個數據源,一個負責提供給業務系統,超時時間設置短一點,鏈接數設置大一點,一個負責提供給後臺查詢系統,鏈接數設置小一點,超時時間設置長一點。經過這種方式,可以把縮小影響面,也可以解決目前的問題。
 
從上面的一個簡單的案例分析,在任何一個系統裏面,都存在矛盾的兩個方面(也可能存在多個方面)。解決這個矛盾有兩個思路,第一個思路是經過兩方對話和博弈使其達到一個均衡的過程。在不一樣的維度進行平衡,好比穩定性和複雜性,安全性和簡單性,從不一樣的角度去考慮,經過加權和降權的方式使其達成一個平衡。還有一個考慮的思路就是對矛盾進行分離,單獨進行處理,就是所謂的關注點分離。
 
相似上面的案例還有不少,咱們所說的分層模式,也是把一個大系統中不一樣層面的所具有的特性不一致,而且有不少矛盾。拿咱們最常用三層模式:web層,biz層,dal層舉例,web層變化很是頻繁,同時要快速的知足需求,biz層變化相對來講比web層少,而dal層則不容易變化。分層模式主要是利用系統中不一樣關注點所面對的問題,每一個層次的特性明顯不一樣,這些都是能夠才喲過度層的思路來設計。從系統分層到架構分層,均可以看到其背後隱藏着系統內部的矛盾。
 
 
不止在IT領域的系統設計存在這個問題,在組織架構上也面臨着一樣的問題。大公司都會存在一套特定的業務流程知足公司內全部的部門。但有一些部門涉及到的業務要求快,有一些業務要求穩,這兩個就是矛盾。這也是金融互聯網公司內部面臨的主要問題,互聯網要求簡單,快速,創新,金融則是複雜,穩定,保守。若是解決這些矛盾,也是這類公司面臨的問題。 
相關文章
相關標籤/搜索