協議設計原則：第一條 使用文字協議， 盡量使用http協議；（文字協議利於除錯和測試，也利於指令碼使用, http協議成熟，比較多工具支援）
第二條 如果效率成為問題，可以在實現了文字協議之後，支援二進位制協議；（這樣程式的bug可以用文字協議及早發現，後來除錯也更方便）；
第三條 選擇二進位制協議時（protocal_buffer, memcache協議, messagepack)，考慮指令碼語言的相容性（ruby, python可否使用），如果自己定義二進位制協議，必須實現 ruby, python 的介面，這樣方便以後除錯和測試。
非 阻塞io和多路分發（epoll），一開始可以使用lt模式，這樣程式更容易實現些，後期可以改成et模式。
et模式要求一定要讀完資料，所以快取要考慮清楚，例如最大長度，超過就要丟棄請求（reset或返回錯誤）.
如果有的操作會阻塞，比如資料庫操作，檔案操 作，mmap， 那就用多執行緒。這樣前端就是非同步，後端就是同步的，簡稱半同步半非同步。
用mutrace, 或valgrind 檢測程式的mutex和rw_lock 會不會有大量 contention, 如果有的話，減小鎖粒度或使用無鎖演算法（比如circle buffer, rcu, ms-queue).
多執行緒需要佇列配合，如果執行緒是不會長時間休眠的，可以 每個執行緒都有乙個佇列，
但如果執行緒會長時間休眠，就需要使用乙個執行緒組乙個佇列，執行緒每次從執行緒組的佇列中取消，
這樣可以避免因為執行緒休眠導致的任務阻塞（就是乙個執行緒持有多個任務，但它休眠了，其它執行緒沒有任務，有cpu也沒辦法搶到任務).
整數操作，盡量用atomic_interger operator, 不要去加鎖。
大 量false的成員查詢，可以使用 bloomfilter把 false成員擋掉，從而免去查詢cache和資料的開銷。
（例如 有3億使用者，但只有1千萬有頭像，那麼用bloomfilter過濾掉 99%的使用者訪問，cache只要承受1%的壓力，
這時只 要兩個hash就可以了，我使用的是bobhash和 time33）
適當使用無鎖演算法（失敗-重做原則）
一 個請求，不要跨越太多的執行緒處理，因為執行緒排程和同步需要比較多的時間，這會帶來比較大的時延。減少記憶體拷貝，可以參考linux的 sk_buffer實現
減小鎖粒度，例如容器操作，可以先swap後操作，這樣只要在swap操作的時候加鎖，後續操作可以不用加鎖。critical_section 和 spin_lock 可以省去陷入核心的時間，但是如果執行緒在 獲得鎖的時候被休眠了，那麼其它執行緒就會白白浪費cpu.
服 務器最好主動關閉連線，如果客戶端能確保主動關閉，那麼可以考慮被動關閉來節省資源。 不然被動關閉需要超時機制來保證socket會被關閉掉。
主 動關閉會導致大量的 timewait，如果是socket異常，會客戶端不合要求的請求，可以考慮用linger選項來 reset連線，從而節約伺服器資源。
linger（onoff=1, linger = 0)會導致reset包，無論是主動關閉還是被動關閉，也不管資料報有沒有傳送完.(shutdown函式不受影響）
http 的 header 可以用vector或固定幾個變數來儲存，不要使用 map， 因為map的insert和find效率都比較低。
編譯時使用 -o2選項，這樣可以提高 10-20%的效率。
用 g++ -pg 和 gprof 來剖析cpu效能問題， oprofile 來進行更深入的剖析（l1 l2 cache）。
記憶體洩露問題用 valgrind加上 ab 壓力測試一段時間，就可以看出洩露部分。
cpu 100% 問題 gdb 隨機斷點幾次，用 bt看堆疊基本可以看出，還可以使用 gprof 來看哪個函式佔了最多的cpu。
strace 可以跟蹤系統呼叫，和呼叫占用的時間，這個可以用來查程序休眠時間問題（cpu占用低，程序經常休眠）。
壓力測試可以使用 ab, httperf, autobench。
功能測試：selenium
測試出系統效能曲線後，就要限 制前端的接入數量，保證系統高效。（接入過多，反而拖累系統，但也要考慮併發數的問題，所以要在吞吐和併發數之間折中）。
多路分 發的方式：
1. libevent， 使用c介面，這樣可以分發到任意函式。（效率最高，靈活性大）
2. 通過虛函式分發。這個的缺點是，不能分發到不同函式。（最多人這麼實現）
3. boost的 asio方式分發，使用function和bind物件來定製分發函式。（靈活性最大)
工作經驗總結
場景描述 當前的智慧型音箱專案組由 音箱裝置端 proxy 語音語義及技能 三大系統組成。裝置端負責使用者語音資料的採集 上傳至proxy端，proxy負責資料透傳，語音語義團隊將接收到的音訊資料進行解析並實現相應技能。技能按照相反的順序返回至音箱裝置端。目前的現狀是整個工作流程不可靠，究竟是哪個環...
近期工作經驗總結
最近在android下層做rtp傳送的模組，算是工作以來，最正規的coding mission吧 雖然 不多,但是讓我對於專案的開發略有一些心得.從我的感覺來看,最重要的就是乙個整體的規劃,首先定義與android層的介面,介面呼叫一旦定義下來,那麼後期的coding工作,都將以此為中心,所有功能模...
軟體測試工作經驗總結
公司自有專案採用迭代式開發，年度大版本，季度小版本，每個版本都要進行多次回歸測試，首次進行功能測試，目的測試當前版本功能沒有問題，第二次進行公升級測試，目的確認從舊版本公升級到新版本資料相容，功能正常，第三次進行功能測試，目的公升級之後功能正常。每個版本都應該有專項測試階段，比如介面測試 效能測試 ...