1.垂直分層
dns層，跨機房部署，負載均衡，共享儲存實現動靜分離，nginx後掛載伺服器集群，伺服器集群後面掛載微服務化，微服務後掛載資料庫讀寫分離、分庫分表+訊息佇列+任務佇列+任務排程+資料庫同意歸檔+非同步批處理
2.水平分層
根據業務劃分業務線，每個業務設計區分鍵，根據userno實現使用者隔離，根據ip設計地區隔離，根據使用者級別設計級別隔離，根據關鍵key設計hash雜湊，考慮分割槽的擴容、縮容、備災、監控等
3.資料同步
彙總集群，建立乙個統一的資料彙總集群（hadoop、spark），將資料彙總到統一的大資料集群中，再進行統計，彙總，運算等。
處理高併發
這個我感覺都不是做開發來考慮的，但是估計面試需要。做查詢的時候會對查詢的表加上共享鎖。做更改的時候對錶加排它鎖。這個進行多個表更新查詢的時候x需要加鎖abc，y加鎖cba。現在x加了a需要c，y加了c需要a，就形成死鎖了。可以對錶建立乙個臨時表，臨時表不需要加鎖。還可以通過建立檔案組，來處理高併發，...
高併發處理
真實的支撐複雜業務場景的高併發系統架構其實是非常複雜的。比如說每秒百萬併發的中介軟體系統 每日百億請求的閘道器系統 瞬時每秒幾十萬請求的秒殺大促系統 支撐幾億使用者的大規模高並發電商平台架構，等等。為了支撐高併發請求，在系統架構的設計時，會結合具體的業務場景和特點，設計出各種複雜的架構，這需要大量底...
高併發處理方案
時常看到高併發的問題，但高併發其實是最不需要考慮的東西。為何，他虛無縹緲，很少有 真的需要這些東西，而且其中很多技術，其實你已經在用了。有這個意識就夠了，不需要時刻盯著這個問題。只有很少的 真的能達到高併發。簡單做乙個歸納，從低成本 高效能和高擴張性的角度來說有如下處理方案 1 html靜態化 2 ...