大眾點評可用性理解
頻率要低
時間要快
幾點經驗
基本是演進過程
思考筆記
高可用是個結果。。
時間要快mttr：
5分鐘把問題解決
業務場景+流量規模=方案演進節奏
化簡為繁，化繁為簡
乙個系統，模組化，垂直服務化，平台服務化，化整為零。
一坨提公升研發效率&故障隔離
問題在於，分離之間會互相影響。
資料掛了，使用快取，怎麼辦？還有資料一致性問題。
資料跟服務走，不共享資料
訂單領域的服務化。拆成幾百個服務。瓶頸單點還是在資料庫
mysql，頻率是1-2w的速度。
水平拆分
拆庫拆表，拆成1000多個表，需要基礎元件基礎，否則運維成本很高。
常碰見幾個例子，伺服器網絡卡壞掉……；cache和cat伺服器，容易壞，它們都在乙個機櫃裡面。。。。；mq等中介軟體也會引起問題
系統繼續拆分
基礎通道做大
流量分塊
cdn/dns，
聯通，電信不穩
系統可限制流量，很容易解決問題，1s的任務分給3s做
無狀態，才容易擴容
降級能力，柔性可用
跟運營一起評估，評估流量，評估效能
如果不能回滾，否則就不要發布
灰度發布、灰度運營
跟監控速度有關，要熟悉系統以及下游的容量，影響時間、qps不同時間流量變化
機器所在的網路，資料庫結構
監控系統需要達到秒的級別
上策：系統，容錯、自動恢復；中策：運維，回滾、重啟、擴容、下伺服器、切災備；下冊：研發。
希望系統能夠自己解決問題
珍惜每次真實的高峰流量，建立高峰流量模型（為下次準備）；壓測也沒有這個準；普通流量跟高峰流量模型往往不一樣
可用性不只是技術問題（考慮每個場景，從產品角度、業務角度思考）
可用性最大的敵人，單點、發布，發布如何控制？架構變化基本是去掉效能單點
一切現有架構都是錯的（有序組織是錯誤的）
保證系統的高可用
1 客戶端層 到 反向 層 的高可用，是通過反向 層的冗餘實現的，常見實踐是keepalived virtual ip自動故障轉移 2 反向 層 到 站點層 的高可用，是通過站點層的冗餘實現的，常見實踐是nginx與web server之間的存活性探測與自動故障轉移 3 站點層 到 服務層 的高可用...
高併發高可用的架構實踐 設計理念（一）
客戶端頁面快取 http header中包含expires cache of control，last modified 304，server不返回body，客戶端可以繼續用cache，減少流量 etag 反向 快取 應用端的快取 memcache 記憶體資料庫 buffer cache機制 資料庫...
有關系統架構的高可用原則
對於乙個高可用服務，很重要的乙個設計就是降級開關。在設計降級開關時，主要有以下思路 1.開關集中化管理 通過推送機制把開關推送到各個應用。2.可降級的多級服務 比如服務呼叫降級為唯讀本地快取，唯讀分布式快取，唯讀預設降級資料 如庫存狀態預設有貨 3.開關前置化 如架構是nginx tomcat，可以...