針對高併發 高可用的架構思考
前幾天在B站上面有幸逛到一期關於網站 高併發性 高可用性 伸縮性 的架構方案思路科普視訊,收益匪淺。
所以把心得理解記錄下來，以備日後使用..
恰好身邊有3臺洋垃圾 所以可以使用幾臺洋垃圾做測試
洋垃圾1:
超微C612伺服器 因為使用的是多核心 低頻率的ES亮機U 所以計算效能中等,記憶體最少
洋垃圾2:
Dell PowerEdge R820 計算效能最強 記憶體數量最大
洋垃圾3
Dell PowerEdge R720XD 使用兩顆2680 C1 計算效能介於超微與R820之間, 記憶體也是比較少
這邊使用的是核心數量最多, 頻率最低的超微來做閘道器伺服器 因為這臺伺服器不需要做大量計算,只需要對各個節點的情況進行監控 並且分配新客戶和癱瘓節點的客戶到最優節點即可
應用性伺服器負擔了最大量的計算任務 所以這版使用R820 並使用虛擬機器來虛擬多臺物理機來模擬高可用架構。在其中一臺節點伺服器(虛擬機器)當掉之後, 由客戶端在心跳包超時/斷線之後重新請求連線 由閘道器伺服器重新分配一臺最優節點繼續提供服務(這種方案在網頁服務比較適用,但是對於多人同屏的遊戲來說的話 可能就會存在一些問題 設計思路應該也需要做相應調整)
在多人同屏遊戲下 如果遇到一個節點癱瘓的情況,最理想的情況是記錄下當前Map的所有物件的狀態值 然後整個移植到另外一臺節點上面，這樣的話 客戶端感受的情況可能是“”卡“”了一段時間之後網路又OK了
但是這樣的情況下 負擔這部分客戶的節點在短時間內必然會有一個瘋狂的資料庫讀取操作(如果2秒時間為比較理想的時間的話) 在兩秒內 這臺客戶端就需要在資料庫內讀取另外一臺節點所有玩家的資料/狀態 這將必然造成伺服器的負載增高,有再次癱瘓的可能. 並且所有玩家必須以集合的方式同步移動到相同的節點， 這也加大了設計上的複雜程度 所以個人覺得並不可取
在這種情況下目前個人想法是製作一個“影”伺服器，這是之前研究Raid1磁碟陣列受到的啟發。我們這邊把每兩個節點組成的陣列成為A陣列,而在A陣列下有A1節點和A2節點。
假設A1節點目前是正在執行的遊戲節點，所有發往A1節點的資料包同時拷貝給A2節點(或者以其他方法使得兩個節點資料同步),這樣的話在A1節點癱瘓的時候 A2節點可以立即從影備份節點轉化為遊戲節點，同時把已經癱瘓的節點服務殺掉 重新啟動A1節點作為A2節點的影備份---當然 這也是一個很笨的方法= =....
待編輯
相關推薦
針對高併發 高可用的架構思考
前幾天在B站上面有幸逛到一期關於網站 高併發性 高可用性 伸縮性 的架構方案思路科普視訊,收益匪淺。 所以把心得理解記錄下來，以備日後使用.. 恰好身邊有3臺洋垃圾 所以可以使用幾臺洋垃圾做測試 洋垃圾1: 超微C612伺服器 因為使用的是多核心 低頻率的ES
構建高併發高可用的系統平臺架構實踐
15套java架構師、叢集、高可用、高可擴充套件、高效能、高併發、效能優化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分散式專案實戰 視訊課程內容包含： 高階Java架構師包含：spring boot、S
高併發高可用（一）概念和技術架構雜談
1.1 系統吞度量要素 一個系統的吞度量（承壓能力：系統在單位時間內處理請求的數量，體現系統整體處理能力）與request對CPU的消耗、外部介面、IO等等緊密關聯。單個request對CPU消耗越
構建高併發高可用的電商平臺架構實踐
從各個角度總結了電商平臺中的架構實踐，由於時間倉促，定了個初稿，待補充完善，歡迎大家一起交流。 作者：楊步濤 QQ:306591368 一、 設計理念 1. 空間換時間 1) 多級快取，靜態
【轉】構建高併發高可用的架構
從各個角度總結了電商平臺中的架構實踐，由於時間倉促，定了個初稿，待補充完善，歡迎大家一起交流。作者：楊步濤QQ:306591368一、 設計理念1. 空間換時間1) 多級快取，靜態化客戶端頁面快取（http header中包含Expires/Cache of Control，last mo
構建高併發高可用的架構
從各個角度總結了電商平臺中的架構實踐，由於時間倉促，定了個初稿，待補充完善，歡迎大家一起交流。 作者：楊步濤 QQ:306591368 一、 設計理念 1. 空間換時間 1) 多級快取，靜態化 客戶端頁面快取（http header中包含Ex
轉載-- 構建高併發高可用的電商平臺架構實踐
從各個角度總結了電商平臺中的架構實踐，由於時間倉促，定了個初稿，待補充完善，歡迎大家一起交流。 作者：楊步濤 QQ:306591368 一、 設計理念 1. 空間換時間 1) 多級快取，靜態化 客戶端頁面快取（http header中包含E
高併發訂單系統架構設計
高併發下單主要包括以下幾個方面： 分庫分表 多應用例項全域性唯一訂單號 資料庫連線 買家查詢訂單 賣家查詢訂單 擴容問題 業務拆分 一、分庫分表 隨著訂單量的增長，資料庫的發展主要經歷以下幾個步驟： - 1主-1從架構 - 雙主-多從架構，讀寫分離 - 表
大規模叢集下的Hadoop高併發以及高效能架構原理總結【石杉的架構筆記】
歡迎關注個人公眾號：石杉的架構筆記（ID:shishan100） 週一至週五早8點半！精品技術文章準時送上！ “ 又到週末，老規矩，週末不給大家送上“燒腦”的技術文章，我們稍微停一下腳步，總結一下之前的內容，溫故而知新。 前言 這次我們總結的，主要是之前大資料的內容。這裡筆者多說一句，筆者認為
企業高併發成熟解決方案思考
要想解決高併發的問題，先需要弄清楚企業整體架構 高併發發生在二處：1.負載均衡 2.資料庫處 分析完企業整體架構之後 1:開始搭建負載均衡伺服器 2:演示負載均衡伺服器的效果 第一種:解決方案 DNS 場景： 我說的大資料量處理是指同
千萬級規模【高效能、高併發】網際網路架構經驗分羹
架構以及我理解中架構的本質 在開始談我對架構本質的理解之前，先談談對今天技術沙龍主題的個人見解，千萬級規模的網站感覺數量級是非常大的，對這個數量級我們戰略上 要重 視 它 ， 戰術上又 要 藐 視 它。先舉個例子感受一下千萬級到底是什麼數量級？現在很流行的優步(Uber)，從媒體公佈的資訊看，它每天接單
千萬級規模【高效能、高併發】網際網路架構經驗分享~
作者：Java關博 連結：http://blog.51cto.com/14049376/2329037?utm_source=tuicool&utm_medium=referral 架構以及我理解中架構的本質 在開始談我對架構本質的理解之前，先談談對今天技術沙龍主題的個人見解，千萬級規模
說說大型高併發高負載網站的系統架構
15套java架構師、叢集、高可用、高可擴充套件、高效能、高併發、效能優化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分散式專案實戰 視訊課程內容包含： 高階Java架構師包含：spring boot、S
高併發訂單系統架構設計（二）
高併發下單主要包括以下幾個方面： 分庫分表 多應用例項全域性唯一訂單號 資料庫連線 買家查詢訂單 賣家查詢訂單 擴容問題 業務拆分 一、分庫分表 隨著訂單量的增長，資料庫的發展主要經歷以下幾個步驟： - 1主-1從架構 - 雙主-多從架構，讀寫
linux c++ 高併發tcp伺服器架構
本文轉載自部落格：http://blog.csdn.net/opencpu/article/details/47175813 epoll 接受資料到佇列，執行緒池處理佇列裡的資料 具體實現方式：（只使用使用std的的資料結構，未使用boost）
【火熱報名】1月19日阿里雲棲開發者沙龍合肥專場：高併發企業級應用架構實踐分享
活動介紹 阿里雲棲開發者沙龍是“雲棲社群”主辦的線下技術沙龍品牌，希望通過技術乾貨分享來打通線上線下專家和開發者的連線。沙龍每期將定位不同的技術方向，逐步覆蓋 雲端計算，大資料，前端，PHP，android，AI，運維，測試 等技術領域，並會穿插一些特別專場（開源專場，女性開發者專場，開發者成長專場等）。我
新浪微博千萬級規模高效能、高併發的網路架構經驗分享
架構以及我理解中架構的本質 在開始談我對架構本質的理解之前，先談談對今天技術沙龍主題的個人見解，千萬級規模的網站感覺數量級是非常大的，對這個數量級我們戰略上要重視它，戰術上又要藐視它。 先舉個例子感受一下千萬級到底是什麼數量級？現在很流行的優步(Uber)，從媒體
分散式高併發高可用FastDFS檔案伺服器叢集部署----
在搭建fastDFS檔案系統時遇到一些問題，總結下來與大家一起分享。也可以給大家作為參考。FastDFS叢集規劃（一個IP對應一個伺服器）VIP為對外訪問入口Proxy-1/Proxy-2組成高可用的代理伺服器，分搶佔模式和非搶佔模式。搶佔模式下:MASTER故障中恢復後會繼
大資料高併發網站基礎架構
大資料高併發網站一般使用的架構模式 1、負載均衡； 2、頁面靜態化； 3、動靜分離； 4、快取； 5、資料佇列； 6、資料庫叢集； 7、資料庫庫表水平垂直拆分； 在網上找了一張圖，如下所示： 當客戶端發起請求，nginx會判斷，請求的是否為
高併發系統資料庫架構設計
在WEB網站的規模從小到大不斷擴充套件的過程中，資料庫的訪問壓力也不斷的增加，資料庫的架構也需要動態擴充套件，在資料庫的擴充套件過程基本上包含如下幾步，每一個擴充套件都可以比上一步驟的部署方式的效能得到數量級的提升。 1、WEB應用和資料庫部署在同一臺伺服