新書預告：《Linux 多線程服務端程式設計——使用 muduo C++ 網絡庫》

看完了 W. Richard Stevens 的傳世經典《UNIX 網絡程式設計》， 能照着例子用 Sockets API 編寫 echo 服務， 卻仍然對稍微複雜一點的網絡程式設計任務感到無從下手？ 書中示例代碼把業務邏輯和 Sockets 調用混在一起，似乎不利于将來擴充？

程式在本機測試正常，放到網絡運作上就經常出現資料收不全的情況？

TCP 協定真的有所謂的“粘包問題”嗎？該如何設計打包拆包的協定？又該如何編碼實作才不會掉到陷阱裡？

帶外資料（OOB）、信号驅動IO這些進階特性到底有沒有用？

網絡協定格式該怎麼設計？發送 C struct 會有對齊方面的問題嗎？對方不用 C/C++ 怎麼通信？ 将來服務端軟體更新，需要在協定中增加一個字段，現有的用戶端就必須強制更新？

要處理幾千上萬的并發連接配接，似乎書上講的傳統 fork() 模型應付不過來，該用哪種并發模型呢？ 試試 select、poll、epoll 這種 IO 複用模型吧，又感覺非阻塞IO陷阱重重，怎麼程式的 CPU 使用率一直是100%？

要不改用現成的 libevent 網絡庫吧，怎麼查詢一下資料庫就把其他連接配接上的請求給耽誤了？ 再用個線程池吧。萬一發回響應的時候對方已經斷開連接配接了怎麼辦？會不會串話？

讀過《UNIX 環境進階程式設計》，想用多線程來發揮多核 CPU 的效率， 但對程式該用哪種多線程模型感到一頭霧水？ 有沒有值得推薦的适用面廣的多線程 IO 模型？ 互斥器、條件變量、讀寫鎖、信号量這些底層同步原語哪些該用哪些不該用？ 有沒有更進階的同步設施能簡化開發？ 《UNIX 網絡程式設計（第二卷）》介紹的那些琳琅滿目的IPC機制到底用哪個才能兼顧開發效率與可伸縮性？

網絡程式設計和多線程程式設計的基礎打得差不多，開始實際做項目了，更多問題撲面而來：

網上聽人說服務端開發要做到 7x24 運作，為了防止記憶體碎片連動态記憶體配置設定都不能用， 那豈不是連 C++ STL 也一并禁用了？硬體的可靠性高到值得去這麼做嗎？

傳聞服務端開發主要通過日志來查錯，那麼日志裡該寫些什麼？日志是寫給誰看的？怎樣寫日志才不會影響性能？

分布式系統跟單機多程序到底有什麼本質差別？心跳協定為什麼是必須的，該如何實作？

C++ 的大型工程該如何管理？庫的接口如何設計才能保證更新的時候不破壞二進制相容性？

這本《Linux 多線程服務端程式設計》中，作者憑借多年的工程實踐經驗試圖解答以上疑問。當然，内容還遠不止這些……

    本文轉自 陳碩  部落格園部落格，原文連結：http://www.cnblogs.com/Solstice/archive/2012/09/21/2696275.html，如需轉載請自行聯系原作者