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