細數，踏入it職場，已有2載，一直從事某網際網路公司非使用者端後台系統業務的開發。雖然面對的業務範疇，沒有超強的併發流量衝擊，也沒有較高的系統效能要求。但是其所面臨的業務邏輯之複雜性，讓我有了寫這篇文章的底氣。
說到這裡，也不得不說扯起乙個話題，系統的高效能與業務的複雜性往往是乙個對立。乙個系統，如果想要面對超高的流量衝擊，超強的系統響應，那麼它所承載的業務邏輯的複雜性也必然要降低。我們在優化乙個系統的效能，其本質也就是在不斷的拆分、裁剪乙個複雜的業務邏輯線。乙個業務邏輯，決定了幾次db的訪問，幾次rpc的呼叫，最終也就直接決定了系統的rtt。對乙個富有經驗的開發來說，總會在業務邏輯的制約下，通過各種技術手段，用跟更高效的cache冗餘儲存，用更多的計算資源併發壓榨，等等通過各類空間資源的消耗來換取時間，以其達到系統效能優化之目的。這也是我們優化系統的乙個基本思路。誠然，在90%的情況下，我們這麼去做，都會有乙個很好的效果。但是，我們往往忽略另外乙個問題，就是這麼做的前期是我們受業務邏輯的制約。換句話說，我們的系統的業務邏輯，已經到了沒有辦法優化的地步，我們對其每一步的妄加修改，都將導致這個流程土崩瓦解，發生crash。往往，由於我們面對的是一群頭腦發熱天馬行空的產品，他們交付給我們的流程設計，往往很難碰觸到這樣的場景。或者剛開始是這樣的場景，可是隨著業務的發展，樹木的成長，邊邊角角的枝幹成長，逐漸淹沒了主幹，讓我們看不到我們曾經的核心邏輯。最終，迫使我們不斷的通過各類技術手段去優化，有一定的事半功倍。
因此，本文想不以一行**，來**乙個系統之設計。使用的方法就是縱橫之術。
縱橫，乃鬼谷立派之本。作為秦迷，看到縱橫，無不肅然起義。言歸正傳，這裡縱橫之術，縱，即乃乙個業務邏輯的核心邏輯；橫，即乃乙個每乙個步驟中的各類充要條件。舉例來說，乙個系統，更細一點，乙個電商系統。其簡單概括由基礎資料和各種各樣的事情組成，放到大千世界，則上公升為萬物是由萬物自身和萬物與萬物之間的關係組成。這裡，我們**電商系統中的各個各樣的事情；基礎資料，準確的說，對基礎資料的管理，這裡不予展開。電商系統中的各類事情，比如使用者的下單流程、商品的入庫流程、商品的發貨流程。每乙個流程，我們可以分為好幾步，比如幾個點，少了其中的某一步，那麼這個流程就會產生crash。這樣的一條線下來，就是所謂的縱。比如，下單流程中的幾步： 當事人提交訂單、鎖庫存、去支付、成功o***il；商品入庫流程，提交入庫單據、推送到倉庫、倉庫理貨、倉庫回傳理貨單據、審核單據、入庫上架；等等，這樣的一條線。而在這條線中的每一步，每乙個點，我們可以逐漸的去展開，去進行我們的橫向拓展，業務上玩各種各樣的花樣，技術上玩各種各樣的實現方式。
這樣，一但我們的縱定下來，我們系統的rtt基本定下來。一方面我們在我們定下來的縱上，通過技術手段不斷的進行優化改造，使其rtt更高。另一方便，無論產品怎麼在橫上做文章，只要不要動縱上的某乙個牟釘，那麼我們的rtt就會保持。另外一定要注意的時，在我們的橫向邏輯實現時，一定要始終牢記盡可能的減少和避免對我們的縱向邏輯產生影響。這樣，我們設計的系統，不論何時何地，都會牢牢的掌握在我們的心中，哪怕橫的錯綜複雜，只要我們的縱不丟，我們系統就穩定可靠高效能。
這就是本文想表達的，慚愧，好久不動筆。邏輯有點亂，此文僅記錄點滴思考。
聊聊高併發系統之佇列術
佇列在資料結構中是一種線性表，從一端插入資料，然後從另一端刪除資料。本文目的不是講解各種佇列演算法，而是在應用層面講述使用佇列能解決哪些場景問題。在我開發過的系統中，不是所有的業務都必須實時處理 不是所有的請求都必須實時反饋結果給使用者 不是所有的請求 處理都必須100 處理成功 不知道誰依賴 我 ...
聊聊高併發系統之佇列術
佇列在資料結構中是一種線性表，從一端插入資料，然後從另一端刪除資料。本文目的不是講解各種佇列演算法，而是在應用層面講述使用佇列能解決哪些場景問題。在我開發過的系統中，不是所有的業務都必須實時處理 不是所有的請求都必須實時反饋結果給使用者 不是所有的請求 處理都必須100 處理成功 不知道誰依賴 我 ...
聊聊高併發系統之佇列術
佇列在資料結構中是一種線性表，從一端插入資料，然後從另一端刪除資料。本文目的不是講解各種佇列演算法，而是在應用層面講述使用佇列能解決哪些場景問題。應用場景 非同步處理 使用佇列的乙個主要原因是進行非同步處理，比如使用者註冊成功後需要傳送註冊成功郵件 新使用者積分 優惠券等等 快取過期時先返回老的資料...