Find N3入網：最高支持16+1TB
OPPO將于近期登場的Find N3折疊屏目前已經正式入網，型號為PHN110。本次Find N3在外觀方面相比前兩代有很大的變化，不再是小號的橫向折疊屏，而是跟別的廠商一樣采用了較為常見的
相信每一位開發同學多多少少都想參與或負責一個高用戶、高訪問、高并發的系統吧。一來可以增加自己實際的項目經驗，有應對高并發場景的解決方案，二來是有個高并發的項目經驗無疑是自己簡歷的一個大大的加分項。
但是奈何很多人都沒有機會可以參與這樣的項目，本文從以下幾點介紹一下設計一個高流量高并發的系統需要經歷哪些步驟以及考慮哪些因素(文章中的不足之處還請大佬們多多指點)。
在設計一個系統之前，我們先要有一個統一且清晰的認知：不要想著一下就能設計出完美的系統，好的系統是迭代出來的。不要復雜化，要先解決核心問題。但是要有先行的規劃，對現有的問題有方案，對未來系統有預案。
在設計高并發的系統時要遵循以下幾個原則：
什么是無狀態?服務器不保存狀態，對單次請求的處理不依賴別的請求就是無狀態，主要是為了在應對高并發時方便水平擴展。
在我們的系統體積過于龐大或者承載不了大量的請求時，就要考慮拆分系統，將復雜問題簡單化或將流量分散不同子系統分擔壓力。可以按照以下幾個維度進行拆分：
當我們的系統被拆分的足夠大時，一旦發生故障靠人工來處理是非常耗時耗力。這個時候就可以通過注冊發現、限流、熔斷、降級等方案讓每個服務可以自己處理問題來幫助我們減少排障成本。
在進行業務設計時要遵循一些最基本的原則比如：
在某些場景下要防止用戶重復操作，例如：用戶注冊、用戶下單、用戶支付等。我們需要在客戶端和服務端有一些方案避免這種問題。
在業務中每個功能多多少少是有聯系的，在設計的時候模塊盡量要獨立，其他模塊直接調用即可，調用減少代碼的冗余。
在程序的運行中避免不了業務問題以及故障的發生，但是我們可以通過日志的方式快速定位問題，做到有據可查。
系統對用戶的響應應該是具體、詳細的，舉一個很簡單的例子，用戶登錄失敗后應該反饋給用戶的是“用戶名錯誤”或者“密碼錯誤”，而不是“登錄失敗”。
做好代碼備份、數據備份以及人員備份。
在高并發高流量的系統客戶端的優化是必不可少的，如果沒有做好客戶端的優化影響用戶體驗是一方面，有時候甚至是致命的。
這里分享下我之前慘痛的教訓：之前參與過一個秒殺的業務，就是因為前端的沒有做優化，大量用戶在刷新頁面時服務器的帶寬被打爆，頁面加載不出來，影響了系統的發展，這是非常致命的。主要原因還是沒有經驗，以為后端做好高并發抵抗就可以。
客戶端優化主要集中以下幾點：
常見的資源緩存就是圖片、樣式和腳本。有些場景可以利用客戶端的緩存幫助服務端分擔壓力，比如網約車中的預估價格，客戶端可以緩存計算規則并緩存，減少向服務端的請求。
我們知道頁面中資源解析的順序是從上到下，如果上面有改變下面也需要變動，所以我們要縮小回流、重繪的范圍，比如虛擬dom。除此之外我們還可以利用懶加載和預加載進行優化：
<meta http-equiv="x-dns-prefetch-control" content="on"><link rel='dns-prefetch" href="www.baidu.com" ><link rel='preload" href="..js" ><link rel='prefetch" href="..js" >CDN應用在客戶端——>服務端之前，能夠實時的根據網絡流量和各節點的連接、負載情況以及到用戶的距離和響應時間等綜合信息將用戶的請求導向離用戶最近的服務節點上，使用戶可以就近取得所需內容，解決網絡擁擠的狀況，提高用戶訪問網站的響應速度和成功率。我們可以通過CDN服務商購買CDN服務，綁定我們的域名，其他的事就不用我們管了。
借用一張網絡上的圖片幫助理解下
通常高并發系統都存在集群節點，為了抵抗大量的請求，也為了系統的高可用。根據業務場景利用負載策略將一個請求分發到集群中的某個計算節點。通過Nginx、LVS、Keepalived等集群組件可以輕松的實現這一功能。
依然是借用一張網絡上的圖片
緩存的介入其實就是空間換時間，常見的緩存組件redis、memcache、guava都可以起到減少響應時間的作用，在高并發的項目中經常被使用到，適合讀多寫少、耗時長的查詢場景。但是會帶來開發人員學習、寫代碼、部署機器、維護的成本。在設計key時要有以下幾點認知：
否則使用緩存的收益是非常低甚至沒有必要的。
當然，緩存技術的引入也是可能會帶來一些列緩存問題，比如緩存擊穿、緩存穿透、緩存雪崩等，依然需要代碼層面去解決，在使用時需要注意這些問題。
我們知道所有的業務數據最終都會落到數據庫，隨著數據量的增加會帶來響應時間的增加，以及系統的負載不斷上升，數據庫單點壓力會越來越大，這個時候對數據庫的優化就不單僅是冗余、反范式、索引，可以根據業務場景參考以下方案：
在mysql中一張表的數據對應一個ibd文件，當文件過大時查找數據就會變的很慢。表分區是將一張表按照hash、list、key等規則進行分流，在物理上將這一張表ibd文件分成多個文件，但是邏輯上還是一張表。訪問量不大，但是表數據很多的表，可以采用這種方式，這樣的好處就是查詢的數據在一個分區時會很快的查到。
分庫分表是真正的把一張表分布在不同的庫或多張表，在訪問量大的時候可以把一張表分多張表并且分布在不同的庫減少單個數據庫的壓力，提高并發。或者按照業務劃分進行分庫分表達到數據隔離的作用。但是這種方式往往會帶來分布式id、事務、join查詢等一系列問題，我們只能通過代碼層面來解決，無疑增加了復雜度。
在讀多寫少的場景下我們可以利用shardingjdbc、mycat等開源框架或組件路由到寫庫或者讀庫實現讀寫分離。同樣讀寫分離也存在一定的問題，比如主從復制問題、時間差問題等，可以結合業務場景規避。
在高并發的項目中，往往我們的后端服務是很龐大的，因為服務拆分所引發的如：服務調用、服務雪崩、節點故障問題，以及處理高并發請求的問題。如何解決這些問題，讓服務更穩定地運行，我們管它叫作服務治理。通常有以下幾種方案：
做好一個高流量高并發的系統，不論前端還是后端，過程中每一個步驟都是至關重要的。設計一個系統除了滿足功能性，還要考慮兼容性、易用性、可靠性、安全性、可維護性、可移植性等軟件質量。同時要對系統的吞吐量、并發數、平均響應時間等指標要完全掌握，在指標異常時可以快速做出決策避免一系列問題發生。
本文鏈接：http://www.www897cc.com/showinfo-26-19929-0.html一個高流量高并發系統，設計關注點有哪些
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： ?Gorm 中的鉤子和回調
下一篇： 系統架構七個非功能性需求
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號