###################################################

當我們系統架構出現瓶頸的時候一般擴展方法分為：

縱向擴展也可以叫垂直擴展，比如擴充服務器的cpu 1顆到2顆 內存8G到16G 磁盤容量擴容...

橫向擴展也可以叫水平擴展，比如web服務器從1臺，增加到2臺...

###################################################負載均衡實現方法 ?之 http的header頭 ? ?DNS輪詢

http header頭里面有location域 可以重定向http請求，可以在程序端操作 比如用php來實現，具體方法網上查查。場景 為下載業務提供http代理 下載的時候判斷客戶端ip然后再重定向到后端下載web服務器，#還有就是CDN的邊緣節點，有時候獲取的可能locadns的ip？

騰訊cdn白皮書： https://mccdn.qcloud.com/static/pdf/5eef0923c4330481a24245b6542563d8/docfile.pdf

作為一名技術人員一定要用合適的技術解決問題

趙班長提供的案例：cdn數據用rsync同步過去，可以認為是一個偽源站，這樣就避免了cdn出問題的是，全部回源帶寬堵死或服務器壓力太大等問題

用dns輪詢做負載的場景還是有的 1.DNS輪詢ip本身就是高可用 2.某些時候dns輪詢可以解決多機房問題

我們再做負載均衡-健康檢查 重試次數和頻率 一般都是根據實際情況配置 有時候是經驗值

在nginx用負載均衡器的時候 當一臺web服務器被踢出集群---如果恢復還會自動加入 nginx上面有個等待時間繼續檢查

負載均衡算法：輪詢 加權輪詢 ，最小連接數，url（hash）每次請求可能不一樣 如果后端服務器是緩存服務器， url（hash）在內存有url-hash表 -馬蓉出軌了 被命中的緩存可能會蹦掉，開源的沒有解決方案（nginx和haproxy），如果想自動解決的只能二次開發，正常情況用uslhash，負載高的時候用輪詢。 網關負載均衡，鏈接負載均衡 一般都是用硬件去解決實現 #################################################負載均衡實現方法之 nginx ?haproxy lvs lvs nat模式 lb負載均衡器要設置為后端服務器的網關 進行了雙向的數據包的改寫，都是內核基本的改寫 可以忽略，實際是和dr模式效率差不多，但是瓶頸主要在帶寬，一般內網千兆的

DR模式

下載站 肯定用dr模式，LB和rserver必須在同一網段，交換機解決沖突域，泛洪，dr 也可以說是二層負載

四層負載均衡和七層負載均衡，七層是2個獨立的tcp連接，只是一個代理，后端服務器返回給代理，代理返回給用戶

?

haproxy支持4層和7層 雙臂路由，單臂路由 服務器直接插在負載均衡端口上 dr模式出現的瓶頸一般是前面的防火墻，因為防火墻有最大連接數限制，可以把防火墻撤銷了，可以直接nginx對外，只開80端口。 單一技術棧：反向代理nginx 緩存也是nginx web服務器還是nginx 好處：架構的單一 ? ?1.降到成本 2.減少運維對象 3.管理方便 4.減少故障點 架構需要考慮到很多東西： 業務模型 網絡環境等等 架構沒有固定好了，只有合適的 ################web集群中Session處理方案

Session id 一般會存在用戶的cookie中

大公司可能會有自己的session框架，tomcat在session存儲很大的時候會有問題？

生產環境基本都用redis，memcache有單點故障 /解決問題不要增加架構的復雜度和故障點，技術不是唯一，趙班長在這里引申出了IT管理的ppt 有時候運維坐姿可能導致一個故障，比如沒有做好，不小心碰到了回車鍵，或椅子壞了等等導致意外的鍵盤錯誤輸入，引發的血案（哈 很有可能，我遇到過開發人員執行rm -rf 都時候手一抖敲到回車了 還好是測試機） ORM?英語：(Object Relational Mapping，簡稱ORM，或O/RM，或O/R mapping），是一種程序技術，用于實現面向對象編程語言里不同類型系統的數據之間的轉換 安全問題 性能攻擊 研究哪個請求訪問數據庫，而且可能時間長的 多并發請求 SOA dubbo 阿里有官方支持 熟悉框架，知道運維模式， 京東在去dubbo 常用的搜索可以靜態化 cookies記錄 在沒有登錄的時候，購物車放在一下臨時的地方，登錄的時候可能會在分布式緩存中或數據庫 電商網站 系統很復雜，服務架構設計，搜索服務：前端商品搜索 用戶搜索 秒殺：1.拉新 找新客戶 ?2.粉絲得到優惠 流量變現，增加用戶的粘性 打分平臺 進入 異常平臺 然后人工審核（比如購買幾萬的商品，需要客服確認） 推薦系統： 頁面前端 用js把用戶的行為記錄下來，然后放在hoodop里面，然后再推薦 1.讓客戶買更多的商品 2.推薦一下 存貨 是一個營銷的收到，技術實現有很多 視頻點播? 拆單系統，京東是自動拆單 人的資源是最貴的，能不用人就不用 如果官網出現400電話，說明這個網站流量說明不大，如果大400會被打爆的。 溝通的不對等，在工作中是最大的問題。很重要 有時候不漲工作和技術沒有關系，你可能覺得自己厲害，但是領導認為你不厲害 做架構盡量少的訪問數據庫， 數學家 哲學家 計算機專家 有的大公司 一個工作必須2個人，輪詢 +備份 哲學觀

倉儲是多級的 前店后倉，和緩存機制是相同的 #######共有云 運維產品化，內部服務 商品化 視頻直播很多 公有云都提供了 門檻很低了，沒有計算壁壘 學的所有的開源軟件，公有云上都有 如果一個新技術，不懂就去公有上看看有沒有相關的產品介紹 上云就很難下來了，消息隊列等可能不兼容 等等其它問題 阿里云只支持主mysql 不支持slave #################### 來自趙班長的總結 當用戶使用代理訪問web服務器時候，web服務器只能獲取到用戶的代理ip，而無法獲取的用戶的真實ip 公司可以建設一個 評分系統，嚴格的防止作弊，使用使用代理的都應該減分，進入異常隊列，繼續進行評分或者人工進行審核 ####################haproxy 生產環境除了代理其它后端web都不用80端口，因為80端口需要root啟動 運維就是有問題解決問題，需要有這個能力

hatop是一個haproxy的開源工具

haproxy 在線維護 socat 通過unix socket 上線下線等 后端服務器 ? ? ? ? ?（#詳細配置見群里提供的haproxy配置文檔） echo?"help"|?socat?stdio?/var/lib/haproxy.sock ?查看幫助 keepalive最早是給lvs做高可用的，所有給haproxy可以不加lvs支持功能 （#詳細知識點見群里的keepalive權威指南） postfix 是keepalive 郵件服務 echo?1?>?/proc/sys/net/ipv4/ip_nonlocal_bind?開啟允許綁定非本機的IP keepalive可以管理多個vip master可以設置恢復搶占或不搶占，默認是搶占的 ##########到一個新公司第一件是考慮數據容災方案，如果沒有相關方案，數據出問題那就是大事了 容災方案常規原則： 1.核心業務，非核心業務 2.從重要數據到非重要數據 3.從下往上（先數據庫） 4.災備演練 5.徘徊在冷備和雙活之間，在災備機房所有的服務都是正常的，可以先切1%的流量，數據回寫看是否正常 專線：內部專線（比如世紀互聯內部的已經實現好的。），vpn（基于互聯網不穩定），運營商專線（mstp按照公里數收費） 問題： 1.流量控制，比如master突然寫大量的sql很有可能把專線跑慢了 2.vpn網絡延遲大，redis復制永遠復制不過去，redis有個backxxx（1.加帶寬 2.把內存調小） 3.服務如果是用的ip，災備要更改ip比較復雜 可以備在云上，支持動態擴展 各大公有云一般都有拉專線服務，一般建議可以遠程寫 備份數據的刪除： 記錄在excel表里 找開發確認，然后再刪除 備份方案寫全了找各部門確認，然后還要定期巡檢 運維被黑鍋，就是自己做的不好，背鍋原因一般是找不到問題的原因 給領導一個可控的方案 單點故障：架構 數據備份 人 思考： haproxy 主down 所有的連接都沒有 有沒有有這個機制能保持不斷開這些連接 ######### 信息系統災難恢復規范GBT20988-2007 和 跟趙班長學高性能Web架構-集群篇.pdf?

轉載于:https://www.cnblogs.com/xiewenming/p/7471353.html

總結

以上是生活随笔為你收集整理的运维杂记-02的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。