系統內部矛盾的解決思路

某一張表的數據量比較大，很多業務都會根據條件來查詢相關的數據，查詢主要分為兩類，一類是業務查詢，能夠根據指定的條件查詢出相關的數據，數據量比較小，查詢速度快，一類是后臺查詢，偏向數據分析，特點是查詢耗時長，查詢數據量比較大。

由于大量系統訪問這個數據庫，那么對數據源連接的實時性要求就比較高，如果后臺查詢大量占用數據源的連接，會影響到外部業務，從而影響業務功能的穩定性。

 

如何解決這個問題，在一般的情況下，我們首先會考慮設置一個合理的超時時間，由于業務查詢都是大多是根據關鍵字查詢，耗費時間都會在幾十毫秒之下，很少會有大量長耗時的sql，后臺的查詢耗時比較長，如果設置較小的查詢超時時間，會導致無法查詢出來結果。那么就根據后臺的查詢耗時的平均時間，設置一個合理值。這種做法相對來說比較簡單，但是會有潛在的風險。可能在默寫特殊情況下，業務的查詢也會存在熱點數據，就是根據這些業務關鍵字的查詢普遍耗時比較長，如果業務系統短時間內大量的熱點數據查詢，則會占用大量的數據源連接，從而影響正常的業務。尤其是在查詢系統無法評估有那些潛在的長耗時查詢的時候，系統就處于這種不可預測的有風險的階段。

 

第二種方案，就是簡單的區分這兩種查詢。我們先解決的問題是后臺查詢超時的問題，如果采用上面的方案，則會影響其他的業務系統。那么可以考慮把影響面局限于后臺查詢。把問題所涉及到的關注點進行分離。就是長耗時和短耗時的問題，那么就配置兩個數據源，一個負責提供給業務系統，超時時間設置短一點，連接數設置大一點，一個負責提供給后臺查詢系統，連接數設置小一點，超時時間設置長一點。通過這種方式，能夠把縮小影響面，也能夠解決目前的問題。

 

從上面的一個簡單的案例分析，在任何一個系統里面，都存在矛盾的兩個方面（也可能存在多個方面）。解決這個矛盾有兩個思路，第一個思路是通過兩方對話和博弈使其達到一個均衡的過程。在不同的維度進行平衡，比如穩定性和復雜性，安全性和簡單性，從不同的角度去考慮，通過加權和降權的方式使其達成一個平衡。還有一個考慮的思路就是對矛盾進行分離，單獨進行處理，就是所謂的關注點分離。

 

類似上面的案例還有很多，我們所說的分層模式，也是把一個大系統中不同層面的所具備的特性不一致，并且有很多矛盾。拿我們最經常使用三層模式：web層，biz層，dal層舉例，web層變化非常頻繁，同時要快速的滿足需求，biz層變化相對來說比web層少，而dal層則不容易變化。分層模式主要是利用系統中不同關注點所面對的問題，每個層次的特性明顯不同，這些都是可以才喲過分層的思路來設計。從系統分層到架構分層，都可以看到其背后隱藏著系統內部的矛盾。

 

 

不止在IT領域的系統設計存在這個問題，在組織架構上也面臨著同樣的問題。大公司都會存在一套特定的業務流程滿足公司內所有的部門。但有一些部門涉及到的業務要求快，有一些業務要求穩，這兩個就是矛盾。這也是金融互聯網公司內部面臨的主要問題，互聯網要求簡單，快速，創新，金融則是復雜，穩定，保守。如果解決這些矛盾，也是這類公司面臨的問題。