5.總結以及自己的一點心得
針對暑期高峰時段的防範，保護暑期直播的穩定性。於暑期前和團隊一起進行防火演練以及壓測，一直缺乏整理，此次記錄並分享。
服務效能瓶頸點究竟由什麼決定？
機器？db？架構？**？
木桶理論：
木桶理論又稱短板理論，其核心思想是乙隻木桶盛水多少，並不取決於最高的木板，而取決於最短的那塊木板。
木桶原理應用在系統分析中，即系統的最終效能取決於系統中效能表現最差的元件，為了提公升系統整體效能，對系統中表現最差的元件進行優化可以得到最好的效果。
找尋當前系統最差的點至關重要。而上述的每一點都可能成為系統的短板1.第一輪壓測評估當前哪些介面效能低下，從這些介面入手。
2.開啟效能監控的工具。監控壓測過程中機器，db等情況。
機器監控：
db監控：用的公司運維老師搭建的監控平台，主要監控的點cpu，used_memory，ops，traffic_in，traffic_out。
可參考此部落格：
壓測某一介面導致redis主從切換，從庫只允許讀不允許寫，導致大量報錯。
監控顯示rediscpu一下乾到100。
記憶體毛刺狀。
1.為什麼會壓切？
**層面的問題。進行review**。
壓測有四個場次，乙個場次4w人，是用redis的set，乙個zset 4w條資料，介面頻繁zrange，導致redis嚴重阻塞。
解決方案後面詳說。
監控：指標
狀況壓力機
未打滿db瓶頸
未滿介面耗時排查
心跳初始化介面耗時過長，大量1s-120s
機器指標
部分機器效能idle，cpu不正常
去kibana上繪製機器流量圖以及慢響應機器分布圖
發現某一台機器出問題。繼續跟進。因為無線上機子root許可權，聯絡運維老師一起查，運維老師沒有發現原因，選擇暫時下掉此機器[記得當時的方案是這樣子的]。
並且這一次有了重大的突破，發現不僅僅這一台有問題。
這一批機子是新產的機子，發現運維配置新機器的時候，某監控服務配置有誤，導致效能普遍偏低。
解決完如上問題之後，再壓測。
效能提高40%左右。
之前qps
現在qps
16000
28000
來當下的公司經歷了2次壓測了，每一次都有不同的問題出現。這次總結一下自己兩年來所碰到的問題。
1.**層面的問題
無論什麼時候，都應該先從自身找原因。看看是不是**層面的問題，**層面的瓶頸是最容易解決，成本最低的。問題詳細描述
1**質量問題
1.迴圈呼叫第三方。
2. 資料結構設計不合理。大key，熱key情況常常出現。
3.二級快取的必要性。對於經常呼叫，但是一定時間內固定的資料，應設定合理的二級快取，不必要每次都去呼叫第三方。
2第三方介面
第三方介面拖累。
第三方響應時間過慢，若設定超時時間會導致資料有誤，若不設定會導致介面響應過慢。
3對應的儲存架構
1.長連線與連線數的控制。我們用的twemproxy與redis建立長連線，發現並不是server_connections連線數越多就越好。文件：
2.根據業務形態考慮相應的讀寫分離機制。mysql的binlog。
3.pipeline和非同步重要性。最好使用pipeline去批量寫入redis。不需要實時的資料可以考慮非同步。
2.外部問題
網絡卡，機器cpu，db問題等等
此問題比較難解決，需要根據具體情況具體分析。
3.必要時設計優雅降級方案
保護核心業務。通過配置後台實現優雅降級。
4.針對業務合理拆分
如提交介面單獨集群。耗費效能的統計介面單獨集群。
不讓統計影響主流程提交。
對android的一些感想 2014 03 26
今天看了網上一些大神的部落格，意識到了一些自身存在的問題。1 規範的編碼是很重要的，方便其他同事的理解和閱讀，有助於team work 2 很重要的一點，建立自己的庫，將一些常用的基類 擴充套件類 動畫效果 儲存起來，當再次開始乙個專案的時候，架構起來就會很方便，使用到一些資源的時候也會很快能找到 ...
高併發的一些處理方法
最近一段時間一直在看一些高併發處理策略的文章，在此也稍微總結一下自己的心得 一.高併發 可以這麼理解高併發，在同一時間，有大量使用者同時訪問同乙個url，容易導致伺服器和資料庫資源被佔滿崩潰，資料庫的儲存和更新結果跟理想不一致，例如出現重複的資料記錄，多次新增記錄等資料錯亂問題。二.高併發的處理策略...
關於高併發的一些思考
1.什麼是高併發？高併發是解決大資料量業務的一種思路，源於現實的生產生活中的問題。舉乙個現實生活中的例子 去銀行辦業務，銀行裡段時間來了100個人辦理業務，但是只有乙個視窗來辦理，平均乙個人辦完業務需要5分鐘，100個人需要500分鐘。當出現類似問題的時候，我們應該怎樣去解決呢？1 提高單個視窗辦理...