要點如下：
目前23台pc server
每天pv數2k萬左右。注冊用戶數300萬。
表的數據，大部分是行數量是千萬的。
5個人算法團隊。另外開發人員總共11個,包括全職和兼職(以前看百姓網分享其技術也只有10名)
06年的時候每天120萬左右動態請求。這個時候主要瓶頸在磁盤i/0上面，拿到風投，有錢購買硬件設備。購買兩台iu服務器(雙核,4g內存)
一台作為應用服務器，一台作為數據庫服務器，遷移到雙線ip機房，使用dns解析不同網段ip(自己去找哪些網段是電信的哪些網段是網通，然後自己進行解析)。看演講後面提到的機房調整感覺到，其實這是走了彎路，可以選擇一個好的機房來解決dns解析方面(後來總結是靠ip段來分布數據不靠譜)
具體怎麼做，就是放到一個支持多線的(教育網鐵通等)機房,現在我們公司用的阿裡雲就是多線）
那麼這樣子就不需要自己多ip段分配了(就是判斷訪問用戶是電信還是網通等)。
使用內存緩存(豆瓣使用的是memcached)的兩點原則：
1、對於需要比較消耗資源的數據
2、需要重復使用的數據。如果只需要使用一次，那麼即便是比較消耗資源，丟入緩存也沒多少意義
理解：內存緩存也需要內存，沒必要浪費。如果不需要重復使用，丟入內存中也比較浪費(畢竟內存不便宜,也占用服務器資源)
豆瓣的memached命中率挺高的。靠這個也緩解了很多壓力。
innodb並發訪問支持好，因為支持行級存儲。使用myisam還是innodb他們的的業務特點是：讀多寫少使用myisam，寫多讀少使用innodb
數據庫切分方面：目前是按照功能進行分區(作者沒有詳細解釋，應該是按照功能模塊劃分表。一個功能模塊相關的表放到一個庫中去)，提到，采用了經典的mysql主從架構。所以每個庫其實是重復三份的(他說的主輔庫)。應該是三個mysql從服務器
分庫之後，操作多個庫，使用游標的方式獲取具體的庫和具體的表。傳入參數進去(具體沒看懂)
數據庫主從復制延遲問題一直是一個常見問題。
購買硬盤是一個教訓：剛開始還是寧願投資多點錢購買好的點的磁盤，因為磁盤這東西升級不太可能。到時候網站扛不住了。仍然得換。那麼，剛開始寧願多花點錢，購買高速磁盤，因為業務如果發展快了的話，就得換。即便貴點，磁盤仍然沒有浪費的。
200萬每天的動態請求的時候，豆瓣提到，靜態的小文件服務(用戶頭像、封面圖片)使得磁盤i/0成為瓶頸，以前愚蠢得把圖片都放到一個目錄下面,這個目錄下面有幾十萬個小文件(直接導致不能使用ls命令,一使用服務器就死掉了)，這個時候把文件分目 錄。分成每個目錄存儲10000個文件。
有專門的數據挖掘團隊。算法團隊進行矩陣計算，把結果放入mysql，供前端查詢顯示出來。
豆瓣的fs是專門針對圖片存儲，自己開發的。其實機制是參考了amazon的，寫的時候寫三份數據。
磁盤隨機尋道比吞吐量更加重要,當時的性能瓶頸在磁盤尋道速度上(這點跟之前看淘寶的圖片文件系統分析的大量的圖片訪問帶來的磁盤磁頭頻繁定位造成的延時類似)
後來把所有myisam表改為innodb表。
innodb的緩存：是在進程中自我管理(也就是內存中)，而myisam的緩存是基於文件中(受操作系統控制)。以前既用myisam表也用innodb表，導致兩種類型的表相互競爭內存，效率不高。索引全部換成innodb存儲引擎(這點我不是很理解，只明白其考慮點是為了更好利用內存)
應用服務器故障：nginx自帶功能。
圖片的流量成為很大成本：遷移到天津機房是因為更加便宜點。機櫃比較便宜，把數據挖掘方面的數據和圖片數據都搬過去。
北京與天津兩個機房。裡面各自搭建mysql的master-slave結構。
搜索方面：以前一直使用mysql的全文索引。後來遷移使用sphinx(這個結合mysql來使用,作為mysql的一個存儲引擎)，後來又變為xapain
為什麼沒使用sphinx了？沒有詳細解釋
使用MogileFS來存儲圖片，後來又自己開發了doubanfs存儲。遷移的原因：mogilefs出現性能瓶頸，由於mogilefs是把元數據(命名空間, 和文件在哪裡)存儲在mysql中,數據庫行數變多之後，就會變得越來越慢。而大量的小文件需要讀取數據庫，也影響了速度。當時的行數增長非常快，當時瓶頸在於mysql數據庫上。
大字段影響了數據庫的性能，實際上數據表行數並不多。就是大字段的影響。大文本字段移除出去，存儲到自己開發的doubanDB中(是一個key-value數據庫，參考了亞馬遜的dymamo，進行簡化)。底層存儲基於tokyocabinet。後來把doubanfs重寫，基於doubandb實現，把圖片存儲進去。
使用雙master方案。解決了復制延遲問題，因為寫和讀都是對同一個master，讀取到的數據是最新的。而以前：從master寫入，然後從slave讀，存在數據延遲
部署lvs。
之前使用spread作為消息隊列，後來使用rabbitMQ替代
=========================================================
總結：照搬其架構和技術方案是不可行的。借鑒他的錯誤經驗和背後的設計思想才能學到本質(主要了解為什麼那樣子做,出於什麼考慮)。
教訓：磁盤的選擇和機房的選擇。磁盤選擇轉數快的，開始成本貴點值得。
分庫，首先從功能角度劃分區。暫時還沒必要去做水平分區。功能相關表放到一個庫中或者單獨的服務器上這是必經的階段。
把錢花在內存上是值得的的，一台機器的內存永遠不嫌多，數據庫消耗的內存比較多，一般內存往往會成為瓶頸(大量連接，計算數據都能導致內存不夠用)。memcached並不廉價(網絡i/0,消耗cpu)。放入memcached的東西要慎重。
避免數據庫的join操作(這點與以前看的石展分享的觀點類似，減少join操作，寧願拆分成多次獲取數據，facebook的架構中也提到不做JOIN 操作)
總體感覺，從豆瓣中學到數據庫方面的經驗是分庫方面。他們的訪問量級別還不需要進行到水平切分，進行分庫即可了，按照業務功能分區。一個業務功能模塊相關的表都拆分到同一個庫中去。然後對數據庫服務器做主從同步保持數據熱備份。
Sharding 在業界的應用場景基本上也就是這種讀應用比較重的情況，而且對事務的安全性要求不高，這樣的場景會非常適合。
sata*3查了一下 450G 1000多塊錢一個。
sata硬盤故障率比較高，換了scsi硬盤。
針對圖片存儲或者小文件存儲方面，因為量大(流量成本，存儲成本)，開發了自己的文件系統
圖片存儲如果依賴於數據庫做存儲，數據量大之後，確實會成為瓶頸(難怪淘寶的圖片文件系統,將一部分元數據隱藏到圖片的保存文件名上)
疑問：北京和天津跨機房，兩邊的mysql之間進行同步數據，或者是天津那邊的數據挖掘程序往北京寫入數據，這個速度如何？
這個我查了一下資料，一般是需要使用專用光釬網絡通道。
