園子裡面很多關於高效能，大併發，還有什麼日pv
百萬的架構搭建。其實真心真心很扯淡。
對於大部分應用來說，想要高效能，主要是要做到盡可能的減少網路請求(含db、
redis
、mongo、mq
等)。
幾乎所有的應用，效能瓶頸永遠是在頻寬那裡，硬體方面這裡就不提了，說說我們能做的事。
關於各個元件到cpu
的時間週期，我用文字描述一下：l1>l2>memory>disk>internet
有人說redis
效能高，做大併發，大資料訪問必須要用，有人說
mongo
效能高，什麼
zeromq
等等一系列的，其實都是渣。
先說網路請求，關於tcp/ip:
大家都知道ip
是逐跳協議，也就是說我只能從乙個路由器，到下乙個路由器，再到下乙個路由器，如果你的電腦到伺服器，中途要經過很多個路由器，那時間週期就會長很多很多恨多。為什麼要做
cdn、
p2p等也是這個考慮，縮短網路的路徑（降低頻寬承載也是一方面）。
再說redis
、mongo:
4000
，裡面是乙個狀態機在跑，需要不斷的去檢測各種狀態，經驗，星座，任務開放，技能開放等等。乙個玩家大約
10個狀態的判定，
4000
個玩家必須在
200ms
之內檢測完畢，不然延遲會很嚴重，那
1s就是大約執行
5次，如果每一次資料都去
redis
去取，大約是
5*10*4000 = 200k
次，別說
redis
，怎樣的牛
b的伺服器都頂不住，這還是只有
1個服。
那麼問題來了：怎麼解決呢？
把資料放在記憶體裡面，直接從記憶體取，然後foreach
。大部分的應用優化到這裡，基本上應付所謂的日
pv百萬，就不是什麼問題了。
到了這一步，那麼問題來了，對於內部應用，比如分布式檔案儲存，資料分析，任務排程。腫麼破？
對於大資料，其實一直是乙個偽命題，資料量太大屬於硬傷。
所有的做大資料處理的，都是把資料分成小資料，然後分塊來處理，最後再合併。其實從mysql,oracle,mssql
等一系列
rmdb
的分割槽，分庫上的處理就可以看出來。想要提高效能，必須要做到，每個模組處理的資料量，都是細分到了一定粒度的。這個時候
index, group, hash
等的重要性，在這裡就體現出來了。
舉個簡單的例子：我有乙個業務系統，每天的日誌大約是10個g
，乙個月就大約是
300g
，一季度大約
1t，我需要看每小時/每天
/每週/每月
/每季度的各種報表，每次都去數
t裡面去找，肯定是不可能的。
那麼問題來了：怎麼解決呢？
按業務分析每分鐘的資料，10g/24/60
大約7m
，然後生成乙個分析後的結果檔案，大約幾k，
1小時就是
60個檔案，需要檢視每小時的資料，則將
60個檔案的結果合併。具體粒度可按具體業務定製，這個是比較簡單的分組的例子。
那我需要檢視某乙個使用者，最近10
天來的所有操作
/訂單，那原分組方式，已經無法滿足，這個時候怎麼辦呢？
在插入使用者資料的時候，可以按照一定規則，比如使用者編號的後兩位取摸，去儲存在某乙個檔案裡面，10g
的資料，則可以相對平均的分配到
100個檔案裡面去，需要檢視某使用者時，則可以針對使用者編號取摸，直接定位到那個檔案，然後再去裡面查詢資料。這個是比較簡單的
gourp+index
。這一塊想明白以後，你就可以在這個基礎上面，寫個定製化的簡單的fs了
()。
經常聽到有人說，多執行緒的程式還不如單執行緒的程式效能高。那如何編寫乙個能合理利用cpu
資源的多執行緒程式？
大家都知道，執行緒切換是需要額外的開銷，所以在編寫多執行緒程式的時候，就需要盡可能的避免共享式資源，這樣就可以在保證資料一致性的同時，而又避開執行緒等待的時間。
舉個簡單的例子：
我有個大的字典(dictionary/map)
存放使用者的會話資料，每個執行緒，去這個字典裡面去讀
/寫資料的時候，都需要去上鎖，才能保證資料的一致性，如果兩個(更多
)執行緒同時去讀
/寫資料，其他的執行緒就需要去等待當前執行緒釋放資源，執行緒越多，則等待的機率越大，效能則越差，多執行緒處理變成了單執行緒處理，且等待完了以後，能否再切換回來這個執行緒繼續執行，又是另外乙個開銷，這一部分屬於系統拖託管，屬於不可控的。
那麼問題來了：怎麼解決呢？
根據硬體和實際測試資料，合理分配執行緒資源，比如，我初始化了8
個執行緒，每個使用者的請求，對於執行緒總數取摸，保證每個使用者的請求，入同乙個執行緒處理，則可以在每個執行緒內部，存放這些使用者資料，每個執行緒在自己內部進行訪問，避開了
lock
，也避開了執行緒等待
/切換帶來的資源開銷。不取模，隨機分配執行緒，然後用乙個
hash
表來存放，也可。讓每個執行緒，專注於做自己的事情，任務排程作業，也大是基於這個處理。把執行緒處理機制，放大到虛擬機器
/物理機之間的訊息分發，也大是如此。
還有很多很多，不一一枚舉，具體業務，視具體情況而定。
總體來說，避開網路開銷、避開海量資料、避開資源爭奪 是所有高效能的幾個基本要素。
本人對**不做任何智財權限制，也不保證所有的**皆為原創。
關於高效能的那點事
園子裡面很多關於高效能，大併發，還有什麼日pv百萬的架構搭建。其實真心真心很扯淡。對於大部分應用來說，想要高效能，主要是要做到盡可能的減少網路請求 含db redis mongo mq等 幾乎所有的應用，效能瓶頸永遠是在頻寬那裡，硬體方面這裡就不提了，說說我們能做的事。找了半天沒有找到那張圖，關於各...
關於高效能的那點事
園子裡面很多關於高效能，大併發，還有什麼日pv百萬的架構搭建。其實真心真心很扯淡。對於大部分應用來說，想要高效能，主要是要做到盡可能的減少網路請求 含db redis mongo mq等 幾乎所有的應用，效能瓶頸永遠是在頻寬那裡，硬體方面這裡就不提了，說說我們能做的事。找了半天沒有找到那張圖，關於各...
關於高效能的那點事
園子裡面很多關於高效能，大併發，還有什麼日pv百萬的架構搭建。其實真心真心很扯淡。對於大部分應用來說，想要高效能，主要是要做到盡可能的減少網路請求 含db redis mongo mq等 幾乎所有的應用，效能瓶頸永遠是在頻寬那裡，硬體方面這裡就不提了，說說我們能做的事。找了半天沒有找到那張圖，關於各...