這次的 QCon 會議，《豆瓣網技術架構的發展歷程》這個議題差不多是最受關注的。洪強寧在演講開始告誡大家期望值不要太高，我還是相信不會有人覺得失望的。
先說幾句題外話，整個演講聽下來，我們會發現豆瓣在發展的過程中也是有點彎路，這些是一個網站發展過程中的寶貴財富，能把自己有周折的地方大大方方的拿出來，是難能可貴的事情。儘管豆瓣批露了很多架構細節出來，也不會(也不可能)有哪個公司一拿到這些東西，就能照貓畫虎再做一個豆瓣並且超過豆瓣。從某種程度上來說這體現了豆瓣同學們的氣度，這是令國內大多數公司汗顏的。很多公司只願索取，而不願奉獻哪怕一點點出來，用這樣封閉的心態對待技術其實是小家子氣，守財奴的思維。技術只有爲更多人所用纔是大道。
議論說完，再來敘述。寫點對豆瓣架構的體會。戲法人人會變，各有巧妙不同。有些東西大家都在用(Nginx)，但是有人的用得好，有人用了比不用還差。所以，需要逐漸總結，改進。學習別人的架構設計，不是要照搬，而是借鑑其思想。
技術的選擇
一直以來，豆瓣在技術上都給人很前衛的感覺，看起來好像什麼新用什麼，其實是不是的，他們一直是"用已掌握的技術解決問題"，現有的東西如果夠用，那麼就沒必要一定遷移到新的上面去，而轉換往往是爲了解決當前問題。另外，換用新的東西，要有足夠的駕馭能力，從演講中得知，豆瓣曾有幾次在臨上線前發現基礎庫的Bug(比如 Libmemcached 的一致性哈希相關的Bug)，技術團隊能在第一時間有進行修復並且提交給開源社區。否則的話，就變成了一種錯誤決策了。
磁盤轉速
小話題。如果可能，直接買 15000 轉的磁盤好了。10000 轉的磁盤可能省錢，但這東西部署了之後幾乎就不太可能升級。所以，如果是初創公司，我的建議就是買高速磁盤，因爲業務如果發展快了的話，先前對機器的定位也可能發生變化。
杜絕遠程 I/O
在普通的 TCP/IP 網絡的環境下，不要進行遠程數據寫入操作。跨網絡操作的延時看似沒什麼大不了的，但一旦達到臨界點就回天乏術。這個事情基本是不撞南牆不回頭，有的技術人員總要親身體驗一把才肯罷休。
持續保持 URL 友好風格
演講中有多次提到一致性 URL ，其實體現了豆瓣對 URL Rewrite 的重視，結構調整，或者應用程序變化的時候，URL 最好做到"用戶友好"的。這算是"軟技術"，但是應該加以最大的重視。
數據庫複製延遲問題
對於 MySQL 複製的環境，如果Slave 上有讀取操作，那麼有些情況下可能因爲 Master 和 Slave 節點數據不一致對用戶造成困惑。如果從一致性的角度上考慮，其實也不復雜:，只需要對"知道數據發生了變化的用戶"提供一致性就行了(基本上就是發起變更的用戶)，不知道數據發生變化的用戶對數據的不一致有一定的"容忍程度"，當然說着簡單，實現起來還是需要技巧和精巧的。
大量小文件同步問題：Merkle tree
關於大量小文件的同步問題，很多上了規模的網站都會遇到，如果設計得不好或者是比較偷懶，用傳統的辦法(比如 rsync 之類的老模式)很容易觸發問題，也浪費資源。DoubanFS 是用 Merkle tree(Hash Tree)的方式進行數據同步的。對這個問題的具體描述可以參見《大量小文件的實時同步方案》。Merkle Tree 是個很精巧的思路，ZFS 在用(refer)，Amazon Dynamo 系統也在用。
不會一會兒又有人留言說：我們早就採用這個思路了...... 我這裏預先來句回答：拜託，你早點共享啊?