付費並發伺服器開發(vip.kankan.com)的心得體會

即將從迅雷離職了，雖然有點捨不得，但是既然做了決定，就會堅持。

一年多的時間，我很感謝迅雷給我的機會，讓我剛來就能負責迅雷看看付費頻道的後台開發，接著又把看看無線整個後台交給我維護，敢於用人，因人而異的思想讓我受益匪淺。

剛來的3個月其實是個挑戰，因為這段時間裡，付費頻道（vip.kankan.com)從無到有，從架構到上線。

為什麼選擇C++？

誠然一些指令碼如Python，寫CGI也是很方便的，維護和擴充也非常方便，但是如果並發量大（如使用者資訊擷取，幾乎在每個頁面都有），即時性安全性高（如支付邏輯，幾乎不能有錯），可跟蹤可調試的伺服器，似乎只能選擇C/C++了。

為什麼不用現成的伺服器？

在nginx上做開發，如taobao一直推崇的模組開發，對於熟悉nginx的人應該可以很快上手，但是我還是沒選擇它，因為nginx其實也有一些解決不了的難題，後期將有文章專門論述。

付費項目將會有哪些難題?

1.產品庫的更新（如新增的產品，修改的價格）必須即時在頁面上體現。

2.使用者購買的價格因人而異，因為可能有很多種身份，如會員，套餐，包月等，使用者的身份也會隨時變化，如套餐到期等。

3.跨伺服器的調用，如和使用者資訊服務器的互動，對並發性即時性要求很高。

4.並發性與即時性。

開發起來有哪些工作需要注意？

根據以往的經驗，資料庫的互動開發會佔用很多時間，而且sql語句也會千變萬化，為了節約開發時間，專門開發了一個工具，根據資料表產生好data object,並且互動層封裝成一個類，再把所有的請求資料放進data manager裡。

產品庫變化快，有可能會碰到一個connection 已經請求得到一個 produt info 指標，但是產品庫已經更新了，記憶體也釋放掉了。資訊緩衝這一塊的記憶體管理上其實很重要，我的做法是將產品庫根據更新時間分代，每一代有一個引用數ref，ref的增加與減少放在request 生命週期中。根據引用數來控制，就保證了記憶體即時更新與安全了。

記憶體管理，我們知道記憶體的分配和使用過程中會觸發很多缺頁中斷，對於交發量大的伺服器，記憶體管理其實很重要。

與nginx的做法相似，我將伺服器的記憶體分成connection,request,busi,三個等級記憶體池，由它們的生命週期來統一協調記憶體管理。

與前端的互動協議設計也是一塊重點，從早規劃，封裝成一個統一的json介面，會讓後面的工作輕車熟路。

 

總體來說，伺服器的開發其實很累人的，如果三個月的時間裡我沒有完成工作，估計我就只能打個醬油了，各種加班，現在回想起來，還是心有餘悸。不過當我看到產品上線，給公司賺線的時候，心裡還是很欣慰的，為它付出的努力也是值得的。

接下來的這段時間，我將會整理這些年對伺服器開發的一些心得。