在【 程式設計師必須掌握的效能調優 xyz 】這篇文章中，老兵哥結合個人經歷解釋了程式設計師往架構師方向發展時為什麼要跨越效能調優這一關，這是我們建立流程化、結構化、系統化的思維的契機。另外，老兵哥還介紹了從 x、y、z 三個維度優化效能的思路。接下來，我們將從 x 維度來談談優化業務互動設計的思路。
讓客戶端分擔部分計算儲存任務。面向公網的網際網路應用最顯著的特點就是使用者基數非常大，每項業務操作本身的計算量可能不大，但是乘上使用者量之後情況就完全不一樣了，為了保障業務正常高效運轉，我們就要投入更多伺服器和頻寬資源。如果資源投入跟不上業務量的增長，那麼系統效能就會變差，使用者操作就會超時或失敗，使用者體驗就會變差，最終導致業務受損。有沒有辦法在不增加資源投入的情況下來改善系統效能呢？如果把使用者的終端（手機或電腦等）也納入到系統範疇，那麼把某些任務放到客戶端計算是緩解服務端資源的有效辦法。
具體有哪些任務適合交給客戶端處理呢？資料合法性的初步驗證、資料的加工轉換、資料呈現形式變換等等，例如在註冊登入過程中，客戶端可以對使用者填寫的資訊做格式層面的校驗，如果不符合要求可以直接給出提示資訊讓使用者重新填寫，這樣就免去了將資訊傳送至伺服器的資源消耗。在現在流行的人臉或聲紋驗證身份的場景下，客戶端可以直接提取**或聲音的特徵碼發往伺服器端做校驗，而不是把**或聲音檔案直接傳送過去。還有就是對已呈現資料的排序或展示轉換上，客戶端也完全可以勝任。現在的客戶端計算儲存能力都很強大，關鍵是我們要識別出哪些任務適合在客戶端執行，這是提公升效能乙個思路方向。
除此之外，優化互動設計是提公升效能非常有效的途徑。如果互動設計不合理，那就容易產生許多無效的操作，這就是對資源最大的浪費。舉乙個非常普遍的場景為例，不管何種型別的業務，都會存在耗時較長的操作，比如將某批任務分派給許多人，分配時要綜合考慮任務和執行者的匹配度，這個匹配過程的耗時跟任務和執行者的數量成正比，我們習慣性做法就是提交操作指令後阻塞輪詢進度直至完成，而輪詢會導致大量無效的查詢請求，尤其在海量使用者的情況下，這就是一場 ddos 攻擊，很容易自己就把自己給搞死了。
關注「it老兵哥
近期熱評系列《程式設計師必須懂的架構師入門課
》：
C 程式常見的效能調優方式
冗餘的變數拷貝 相對c而言，寫c 經常一不小心就會引入一些臨時變數，比如函式實參 函式返回值。在臨時變數之外，也會有其他一些情況會帶來一些冗餘的變數拷貝。之前針對冗餘的變數拷貝問題寫過一些帖子，詳情這裡。多重過濾 很多服務都會過濾的部分結果的需求，比如遊戲交談中過濾需要過濾掉敏感詞。假設現在有兩個過...
程式設計師必須開始的道路
說起軟體工程不得不提軟體，那軟體又是什麼呢？軟體呀，它生存於硬體的家庭，由於硬體的各種限制，軟體就是乙個程式，主要由個人來編制。隨著硬體的發展，軟體的規模也相繼變大，個人不能夠完成這麼大的規模，就必須有好多人來完成。這時人們之間就有矛盾了，互相之間交流出現障礙，所以這些開發者就每寫個程式，就寫段說明...
程式設計師必須了解的記憶體知識
c和c 語言開發中，指標 記憶體一直是學習的重點。因為c語言作為一種偏底層的中低階語言，提供了大量的記憶體直接操作的方法，這一方面使程式的靈活度最大化，同時也為bug埋下很多隱患。因此，無論如何，我們都要對記憶體有乙個清晰的理解。1.對記憶體的分配 32位作業系統支援4gb記憶體的連續訪問，但通常把...