淘寶十年曆程隨筆

初創

1. 淘寶PV頁面訪問量在十幾億到二十幾億，因此即便訪問淘寶首頁頁面服務器也有成百上千臺，這過程用到的負載均衡技術LVS（Linux Virtual Server 由淘寶章文嵩博士開發）
2. 一個頁面加載網頁資源併發數有限，淘寶經過不一樣域名繞開這個限制，至關於訪問不一樣的網頁。不一樣地區之間訪問也會很是緩慢，這能夠經過CDN（Content Delivery Network即內容分發網絡的做用）。淘寶在全國各地創建數十個甚至上百個CDN節點，經過一些手段保證你訪問的資源站點離你最近的CDN節點。保證了大流量的分散以及各地訪問的加速
3. 這樣又會致使一個問題，當上傳一張圖片如何在各節點都上傳上相同的圖片，這涉及到內容分發與同步的相關技術。淘寶開發了分佈式文件系統TFS（TaoBao File System）
4. 通過上面三部終於加載完成淘寶首頁，首頁輸入關鍵字，好比「毛衣」，點擊搜索，進入分詞庫分詞，而後由一千多臺搜索服務器完成搜索。
5. 對於已買過的寶貝，能夠經過已買到查看當時的快照，這是爲了防止商家對商品作出承若的否定。這樣的快照確定很是多，對他的保存和快速調用不是簡單的事，其中淘寶用到了Tair（淘寶自行研發的分佈式KV存儲方案）
6. 訪問行爲數據的記錄，產生的日誌可能很是龐大，達到TB級也正常，這時要解決快速、及時、同步地傳輸這些日誌，淘寶開發了TimeTunnel，用於進行實時的數據傳輸，而後交由後端系統進行計算報表
7. mysql第四版，存儲引擎MyISAM，這種存儲引擎在寫數據的時候會把表鎖住
8. 行癲初期數據分庫分表作了個數據路由框架DBRoute，統一處理數據的合併、排序、分頁等操做。但對容災的需求沒有達到
9. 以後用spring替換了EJB
10. 對商品詳情這種大數據量字段，從商品表移出到單獨的表，後又放入緩存系統，直到如今放入文件系統TFS中
11. 淘寶網使用GraphicsMagick進行圖片處理，採用了面向小對象的緩存文件系統，前端有LVS+Haproxy將原圖和其全部的縮略圖請求都調度到同一臺Image Server（圖片服務器）
12. 淘寶緩存從ESI到基於Berkeley DB的TBstore，又專門爲用戶系統寫了個TDBM，拋棄了Berkeley DB的持久化功能，以後參考memcached改進推出TDBM2.0，再以後將TDBM、TBstore合併推出Tair（TaoBao Pair的意思，Pair即Key-Value數據對）。Tair做爲一個分佈式系統，由一箇中心控制節點和一系列的服務節點組成，咱們稱中心控制節點爲Config Server，服務節點是Data Server。

分佈式時代

1. 系統進行了服務化拆分，集羣和分佈式又帶來不少問題
2. 爲了解決服務間調用，寫了HSF同步調用框架和notify異步調用消息中間件
3. 有了HSF和Notify的支持，在應用級別中，整個淘寶網的系統能夠拆分了，還有一個制約系統規模的更重要的因素，就是數據庫，也必須拆分
4. TDDL就是爲了解決分庫分表分佈式狀況下致使的各類問題而生
5. 再要解決集羣session問題，考慮用cookie或tair解決
6. 以後開始作開放平臺，須要解決路由、數據規範和受權，當時尚未oauth2，直到2011年才支持
7. 以後逐漸嘗試新興技術Hadoop和Memcached
8. 後面主要是一些做者心路歷程和一些牛人列傳

總結

1. 看了這本pdf，你會了解淘寶架構的演變，瞭解系統演進的過程。
2. 它讓我理解了淘寶大多所用的技術爲何不是如今最流行的，在那個年代，他們是技術的先鋒，也只有在流量到達了那個級別，迫切須要解決這樣的需求，才演變出瞭如今阿里內部各類架構和中間件體系
3. 想看具體的pdf內存，下面我留了連接

連接：https://pan.baidu.com/s/1M57ptoxXGuGwiVrLCwhl4w
提取碼：m4k0