後端好書閱讀與推薦（續六）

MageekChiu發表於2019-01-19
後端

後端好書閱讀與推薦系列文章：
後端好書閱讀與推薦
後端好書閱讀與推薦（續）
後端好書閱讀與推薦（續二）
後端好書閱讀與推薦（續三）
後端好書閱讀與推薦（續四）
後端好書閱讀與推薦（續五）
後端好書閱讀與推薦（續六）

Elasticsearch權威指南

Elasticsearch: The Definitive Guide (豆瓣): https://book.douban.com/subje…

Elasticsearch是一個強大的開源搜尋引擎（不僅如此，還是一個分散式儲存、實時分析系統），作為後端開發者，我們常常需要用到它，甚至是借鑑其原理來實現自己特定的功能，因為了解一下是很有必要的。這本書不僅講了使用方法，還講了原理，很適合我們學習與查閱。

亮點：

  • Elasticsearch使用Java開發並使用 Lucene 作為其核心來實現所有索引和搜尋的功能，它的目的是通過簡單的 RESTful API 來隱藏 Lucene 的複雜性。也對使用者隱藏了分散式系統的複雜性，而且提供了一系列執行良好的預設值，從而讓全文搜尋變得簡單，達到開箱即用的效果

  • ES與傳統RDB的對比：

    • Relational DB -> Databases -> Tables -> Rows -> Columns
    • Elasticsearch -> Indices -> Types -> Documents -> Fields
  • ES的自動實現了分片、負載均衡、發現、冗餘、選主、同步、擴充套件遷移、容錯等功能。一個節點(node)就是一個Elasticsearch例項，而一個叢集(cluster)由一個或多個節點組成，它們具有相同的cluster.name，叢集中一個節點會被選舉為主節點(master)，它將臨時管理叢集級別的一些變更，例如新建或刪除索引、增加或移除節點等。索引只是一個用來指向一個或多個分片(shards，是一個 Lucene 例項)的邏輯名稱空間(logical namespace)，分片可以是主分片(primary shard)或者是複製分片(replica shard)。索引中的每個文件屬於一個單獨的主分片，所以主分片的數量決定了索引最多能儲存多少資料，複製分片只是主分片的一個副本，它可以防止硬體故障導致的資料丟失，同時可以提供讀請求，啟動新節點時叢集會重新組織並均勻分配各個分片
  • ES提供了豐富的資料操縱功能，不僅有簡單的查詢字串搜尋（含萬用字元），還有DSL，可以構建更復雜、強大的查詢
  • 批量請求可以減少網路往返次數開銷，以及日誌數量，可以提升效能（mysql也有這種做法），這個批量的大小要根據你的硬體來定製
  • 倒排索引是全文搜尋的核心技術，也就是按照每個單詞（經過分詞後）劃分歸屬集，儲存包含這個單詞的文件，檢索是按照單詞的，所以可以很快返回相關文件
  • ……

此外需要注意的是Elasticsearch發展太快，書籍只是用來系統性的學習的，如果真的要使用起來，還是要去官網看最新的用法，但是基本原理和思想變化是不多的。

大資料日知錄

大資料日知錄 (豆瓣): https://book.douban.com/subje…

這本書可以當做大資料領域的字典，包含很多方面，雖然有些地方有一點划水嫌疑（比如一大串單位換算，歌詞），但是畢竟瑕不掩瑜，亮點頗多，看完這本書後基本上對大資料就能有一個整體的認識了。

亮點：

  • 大資料沒有標準定義，可以用 4V 來表述：Volume（體量巨大）、Velocity（產生速率高）、Variety（型別多樣）、Value（需要從海量資料中發現價值）。可以通過大資料生態的一系列工具（hadoop生態）來解決大資料問題
  • 資料分片主要有兩種方式：雜湊和範圍。雜湊有：round-robin（亦即雜湊值取餘，簡單但擴充套件性不佳）；虛擬槽（key對映到槽，槽對映到機器，解耦key與機器）；一致性雜湊（雜湊值範圍歸屬，引入虛擬節點後擴充套件性與平衡性俱佳）。範圍有：按不同的主鍵劃分順序。雜湊的問題是範圍查詢支援不佳，範圍的問題是可能冷熱資料不均。除了分片問題，為了實現高可用還要解決複製問題，這就會引入各種級別的一致性（強弱）問題和複製策略（全、增量，同、非同步）問題
  • 採用獨立的資源管理與排程系統與靜態資源劃分相比有3大好處：減少閒置，提高利用率；增加資料共享能力；支援多型別/版本計算框架。通常具有三種範型：集中式排程、兩級排程、狀態共享排程，三者逐步弱化中央排程功能、強化框架自由度，適用於不同的應用場景
  • 資料匯流排的作用是形成資料變化通知通道，當集中儲存的資料來源（一般是RDB）資料發生變化時，能夠儘快通知相關元件。實現有2種思路，雙寫（需要引入兩階段提交來保證原子性）或者資料庫日誌挖掘（如 binlog解析）
  • HayStack作為物件儲存，其設計有一次寫入、多次讀取、從不更改、很少刪除的特性，由於圖片數量很大，所以把多個圖片拼在一起減少後設資料數量，同時減少後設資料屬性，這樣就可以把後設資料放入記憶體，讀取物件時只需要一次記憶體與一次磁碟訪問即可
  • 一般資料多副本用來提高可用性與讀取效能，對熱資料來說還比較划算，但是冷資料這樣就有點浪費，可以用糾刪碼：資料分成n分，形成m分冗餘的校驗資訊，這m+n分資料最多丟失m份資料依然可以恢復原資料，節約了儲存空間，常見編碼有Reed-Solomon、LRC等
  • 批處理系統主要有兩種範型：MapReduce（兩階段批處理任務，簡潔但是表達能力不夠豐富）和DAG（圖計算，可以表述複雜併發任務之間的依賴關係，所以也比較複雜）。Spark本質也是DAG批處理系統，描述能力更強，而且基於記憶體速度快，對於同一個任務可以反覆多次進行，最適用於迭代式機器學習。Storm是流式計算，講究即時處理
  • 常見的流式計算（甚至所有分散式架構）主要分為主從、P2P模式兩種，主節點做管理比較方便簡潔，而P2P由於去中心化，所以系統管理複雜，該類架構例項較少

Docker—容器與容器雲

Docker——容器與容器雲（第2版） (豆瓣): https://book.douban.com/subje…

通過這本書我們來深入瞭解一下Docker的用法與原理，更主要的是的Kubernates這個編排容器的強大工具的最佳實踐與執行原理。最後可以瞭解下整個容器技術的生態。

亮點：

  • 雲端計算是一種資源的服務模式，支援隨時隨地按需從共享資源池中獲得所需資源（網路、伺服器、儲存、應用與服務）且資源可以快速供應並釋放，減少了資源管理工作開銷。包括IaaS（基礎設施如計算、儲存、網路）、PaaS（執行時環境設施如資料庫、日誌服務等）、SaaS（可直接使用的應用服務）
  • 一個軟體專案的成功與否與其能否帶動一個生態系統的發展相關，docker顯然做到了，帶動了整個容器技術的發展，而容器技術直接改善了:持續部署與測試、映象和容器的跨平臺支援、環境標準化與版本控制、資源利用率、眾多映象且易於理解和使用
  • 容器雲是以容器為資源分割和排程的基本單位，封裝整個軟體執行時環境，為開發者提供構建、釋出和執行分散式應用的平臺。容器雲專注資源共享、隔離和編排部署時更接近IaaS，容器雲滲透到應用支援與執行時環境時更接近於PaaS
  • namespace是linux中實現程式隔離（資源隔離）的主要技術，具體的隔離由幾個系統呼叫clone、setns、unshare和引數完成：CLONE_NEWUTS(主機與域名)、CLONE_NEWIPC(程式間通訊常見的包括訊號量、訊息佇列、共享記憶體)、%%_NEWPID(pid)、%%_NEWNET(網路裝置、棧、埠)、%%_NEWNS(掛載點檔案系統)、%%_NEWUSER(使用者與組)……常見做法是通過clone函式實現，而setns能直接進入一個已有的名稱空間
  • cgroups是linux實現資源限制的主要技術（顧名思義就是把一組任務統一加以控制），實現資源（CPU、Memory、IO等）限制和優先順序分配及其使用量統計、任務啟停等功能，其本質是核心附加在程式上的一些列鉤子，通過程式執行時對資源排程觸發相應的鉤子達到資源追蹤和限制的目的
  • etcd受ZooKeeper和doozer啟發，具有類似特點，但也有自己的特色：基於http，用curl就可以使用；可選ssl認證；單例項每秒千次寫；使用raft保證一致性。是一個 k v stroe，廣泛用於服務發現、釋出訂閱、負載均衡、分散式通知與協調、分散式鎖與競選、分散式佇列、叢集監控等
  • 容器雲就是以容器為資源分割和排程的基本單位，封裝整個軟體執行環境，為開發者和管理員提供用於構建、釋出和執行分散式應用的平臺。直觀的雲就是一群容器被分組，組間隔離、組內共享，藉助全域性元件進行管理。有許多工具如“小神器”Compose（dockerfile定義容器，compose定義配置和叢集）、跨平臺宿主環境管理工具Machine（跨雲平臺的容器建立與管理）、叢集抽象工具Swarm（在多臺宿主機上抽象，使得多容器管理介面統一）等
  • Kubernetes是一個（目前最流行的）管理跨主機容器化應用的系統，實現了包含應用部署、高可用管理、彈性伸縮在內的一系列基礎功能並封裝為簡單的Rest API 對外使用。其關鍵設計就是pod：一組可以互相互動、位於多個宿主的容器組，每個pod都可以有replica來保證高可用和伸縮性

TCP/IP詳解 卷1：協議

TCP/IP詳解 卷1：協議 (豆瓣) https://book.douban.com/subje…

TCP/IP是我們日常接觸最多的協議，搞後端的總會遇上粘包分包、reset、too many files等等問題，搞懂了TCP/IP才能解決這些問題，這本書對於我們全面深入的瞭解這個協議棧有很大的幫助。

亮點：

  • 網橋是在鏈路層上對網路進行互連，而路由器則是在網路層上對網路進行互連。網橋使得多個LAN組合在一起，這樣對上層來說就好像是一個區域網，TCP/IP傾向於使用路由器而不是網橋來連線網路，
  • 環回介面（127.0.0.1或者說localhost）允許在同一臺主機上的程式和伺服器程式通過 TCP/IP進行通訊，我們想象一旦傳輸層檢測到目的端地址是環回地址時，應該可以省略部分傳輸層和所有網路層的邏輯操作。但是大多數的產品還是照樣完成傳輸層和網路層的所有過程，只是當IP資料包離開網路層時把它返回給自己，看上去用傳輸層和 IP層的方法來處理環回資料似乎效率不高，但它簡化了設計，因為環回介面可以被看作是網路層下面的另一個鏈路層。但是Unix Domain Socket 則省略了一些協議封裝的過程，提高了效能
  • ICMP雖然基於IP，但是能反映和控制IP的狀況，所以通常就歸於IP層。我們常使用的Ping就是利用 ICMP echo實現的，不需要經過傳輸層；Tranceroute是不停的傳送ICMP echo 或者UDP包，逐次增大TTL，直到到達目的主機（亦即不報ICMP超時而是ICMP echo 回覆或者ICMP埠不可達），從而獲得路徑
  • TCP傳小報文在公網上容易引起擁塞，所以有Nagle（小於mss的包必須等到前面包收到ack再發，或者多個小分組湊成大分組）和Delayed Ack（ack在一定時間內等順風車如資料包或者其它ack一起傳送，累計Ack）分別在傳送端和接收端避免，這也是解決糊塗視窗綜合徵的辦法，但是對於實時性要求較高的應用也需要關閉這些演算法
  • TCP在區域網傳送可以一開始便傳送多個報文段，而在公網上（中間可能有多個較慢的路由器或者鏈路）一般採用慢啟動演算法慢慢探測鏈路的極限，這也是用“樂觀”和“悲觀”兩種策略來應對不同的場景，就像悲觀鎖與樂觀鎖在不同的多執行緒競爭程度下的使用效能會有不同體現一樣

效能之巔

效能之巔 (豆瓣): https://book.douban.com/subje…

效能問題橫跨諸多領域：CPU、記憶體、磁碟、網路、程式碼質量等等，從裸機到虛擬機器，本書幾乎做到了面面俱到。本書建立在對作業系統的深刻理解之上，甚至於統計學和實驗之上，從概念、模型、觀測到實驗手段，從原理上和方法上來回答了一系列問題如：“如何度量網路繁忙程度”、“服務中斷是程式問題還是機器問題”、“SSD與機械硬碟的使用比例是多少”等，讓我們在面對效能問題時心中有數，有典可查。同時，也對我們日常的研發起到一個監督作用。

亮點：

  • 本書的序也很棒，都有自己的觀點：單程式的瓶頸很好定位與分析，但整個業務的瓶頸有可能不在單元內部，而是單元之間的網路服務，所以要動態分析；無論是除錯（debug是靜態的）還是調優（tune是動態的）都需要我們既有全域性觀也要能探微索隱，技術成長的路徑是，編碼->除錯->調優；很多問題解決不了是因為我們不知道我們不知道（效能問題太多太雜），比如不知道裝置中斷很耗CPU、Oracle session很耗記憶體（即使不活躍）等，所以說知識的廣度和深度都要有才能融會貫通；街燈法（哪裡出了問題就找哪裡，但實際上問題不一定出在這裡）這個觀點很新穎，我們要盡力避免，採用科學法：描述問題-假設-預測-實驗-分析；效能問題很主觀和微妙，本書卻提供了一個系統性的方法論
  • 效能是一個全棧的問題（不僅是一般概念上的應用與資料庫，還包括os與硬體），所以我們必須要清楚資料的整個流向，通過不同的人員、團隊合作（java開發、DBA、網路工程師等），在整個流程中尋找瓶頸，怎麼下手需要經驗，但是我們可以通過動態追蹤（基於CPU指令並在之上動態構建監控資料）收集資料來更好地分析和定位
  • 有已知的已知、已知的未知、未知的未知，效能問題和學習系統是一樣的，你知道得越多，你不知道的就越多。但是你瞭解的越多，那些未知的未知就可能變成已知的未知，最終可以變成已知的已知，所以見識一定要廣闊，鑽研一定要深入，做個T字形人才。
  • 本文提出了很多效能問題定位方法：街燈法（選熟悉的工具進行分體，比如top命令，這種方法與運氣有關）；隨機變動法（隨機找引數修改並觀察效果）；責怪他人法（可能是其他團隊的問題）；Ad Hoc 清單核對法（對常見問題列出檢查清單，一一嘗試）；科學法（問題，假設，預測，實驗，分析）；工具導向法（把手裡的工具都用用）；R方法（Oracle的效能分析方法，意在找到延時根源）；USE法（圍繞 使用率，飽和度，錯誤 三個指標進行分析）…… 這些方法平日我們可能都用過，這裡作者卻總結出來形成了系統方法論
  • 效能觀測工具要麼基於計數器（由核心維護的統計資料，預設啟用可以視作零開銷,一般可以從/proc檔案系統中讀取，如vmstat,mpstat,iostat,netstat,sar,ps,top）要麼基於跟蹤（跟蹤事件來分析，預設不啟用所以有開銷，如tcpdump,blktrace,Dtrace,strace,gdb）還有些基於剖析（profiling，對目標進行取樣或快照來歸納特徵比如CPU使用率、快取命中率，有oprofile,perf,Dtrace），有程式級別的也有系統級別的。
  • 應用程式效能分析之前首先要定好目標比如延時、吞吐量、資源利用率等，一旦選中目標就可以處理限制該目標的主要因素了，如延時可能是磁碟、網路，吞吐量可能是CPU等。提高應用效能常用技術有：合適的IO大小，IO開銷包括初始化緩衝區、系統呼叫、上下文切換、許可權檢查、地址對映、驅動程式碼執行等等，一次IO大小合適既能避免太小導致太多尋道也能避免太大浪費傳輸能力；快取，cache提升讀能力；緩衝區，buffer提升寫能力；輪詢，比如poll與epoll，基於事件，避免普通輪詢的CPU空轉消耗與延時；併發與並行，利用多處理器優勢；非阻塞IO，避免較慢的IO成為較快的CPU的“拖油瓶”；處理器繫結，提高記憶體本地性，減少IO
  • CPU使用率是指一段時間內忙於執行工作的比例，高使用率不一定是問題，可能意味著正在繁忙的工作，但是工作不一定是真正在執行指令，也可能是等待IO導致的停滯週期或者等待鎖的SpinLock，所以高使用率（每指令週期數CPI也高）不一定是效率高，還要看指令本身的特點，比如CPU親和性、記憶體本地性等。
  • 檔案系統通過快取、緩衝、非同步等手段可以減輕磁碟或遠端系統對應用的影響，所以其效能研究很重要。

本書雖然分為cpu、記憶體、檔案、磁碟等不同領域來說效能，但是有好多命令比如top、vmstat是跨領域的，就重複了很多次，把本來就很厚的書搞得更厚了，所以我們看書過程可以一次性把一個命令搞熟悉，就可以跳過很多重複了。

重新定義團隊：谷歌如何工作

谷歌可以說是IT業界標杆，引領了許多潮流：大資料生態、分散式系統、人工智慧等等，那麼我們就來看看這麼優秀的谷歌是如何工作的。

重新定義團隊：谷歌如何工作 (豆瓣): https://book.douban.com/subje…

亮點：

  • 人的主觀能動性是有很大力量的，所以企業需要堅信員工都是好的，再就是要有足夠的勇氣，把員工看成是企業的主人翁， 而不是把他們當成機器。機器會完成工作；主人翁會竭盡所能幫助企業和團隊獲得成功。你給員工以自由，員工將還你以驚喜
  • 書中反覆強調，無法從每日工作中得到一定滿足感的人，就是去了薪酬中最好的一部分。你或許不是一家公司的創始人，但是也可以成為一個團隊、一個家庭或一種文化的創始人，盡力創造出空間使得其他創始人與自己攜手同行。
  • 公司文化要快樂，快樂使我們不必謹小慎微，可以發揮開發和探索的能力，但這只是表面，文化的三個根本元素是使命（讓工作有意義）、透明（相信員工，分享資料）和權利（給員工話語權，便於做出高水平決策）。文化塑造戰略，而非相反。
  • 聘用水平超過90%應聘者的員工，最糟的情況他們也能有平均水平的表現。這些員工幾乎不可能成為公司裡表現最差的。但是如果招聘平均水平的員工，不僅會耗費大量的培訓資源，而且很可能他們的表現會低於平均水平而不是高於平均水平
  • 我們發現在個人競爭中表現好的人並不總能成為優秀的團隊夥伴。贏得這些比賽的人或許很聰明，但通常只是在某一領域有所專長。或者是因為他們習慣於解決有明確終點和確定答案的問題， 而不是掌控現實世界中的複雜狀況。 我們在谷歌就有這樣的要求， 我們尋找的人不僅能夠解決今天的問題， 而且能夠解決未來可能出現的各種未知問題

逆流而上

逆流而上 阿里巴巴技術成長之路(豆瓣): https://book.douban.com/subje…

這本書包含了阿里的許多經驗，每一篇都會解決一個特定的問題，當成有體系梳理的博文來看還是很不錯的。

亮點：

  • 穩定性要做好幾點：研發與運維要靠近、故障標準要統一併強化處理流程、建設統一的基礎設施並完善團隊融合做到“書同文車同軌行同倫”；堅持技術創新比如新技術、全鏈路壓測與異地多活等；設定專門的崗位與部門來保障穩定
  • 使用者使用pwrite寫資料，加上O_DIRECT標識，只能保證資料直接落盤（忽略Buffer cache），而檔案系統後設資料仍然儲存在inode cache（記憶體）中，當加上O_SYNC標識，寫操作變為同步寫（synchronous I/O），此時可以保證後設資料同步落盤。所以我們對整個IO鏈路理解的越清楚，就越容易看到問題背後的真相
  • 防止快取被擊穿不能簡單用預估流量除以單臺快取機器，因為很有可能是按key的hash分佈的，有些高頻key或者大value的key若處在同一機器則會輕易使此機器超過閾值（併發量與流量）。所以要監控所有key，一旦發現QPS限流或流量限流就要快速定位問題key，再結合使用的雜湊演算法將可疑key分散到各個機器上去，分散壓力
  • 去閘道器化的軟負載形式，會將負載均衡策略下沉到客戶端，避免閘道器的單點故障。當然避免不了需要統一的閘道器作為接入層時，就要考慮同城多機房甚至異地這樣的高可用策略。必要的時候要採取自我保護的限流機制，避免雪球效應，一臺一臺機器接連爆表
  • select * 的弊端一般我們認為是若欄位較多或較大對效能有影響，其實不止這樣，在分庫分表的過程中，這個語句會導致相容問題，還有其他問題如增加解析成本，不能使用覆蓋索引等
  • 冪等控制是資金安全中的重中之重，對於事務、分散式鎖、重試等要好好運用，建議在系統設計時，將第三方唯一性的冪等控制作為冪等控制的兜底方案。我最近在玩支付寶的積分換天貓券，因為券很少，需要積分兌換並且搶，這是一個明顯的事務：扣積分、得到券。為了安全起見，支付寶提示了可能先扣分但是沒有搶到券，事後再把積分還給你，這就是一個典型的補償機制。本來可以使用兩階段提交的，但是這種做法允許短暫的不一致狀態，達到最終一致較兩階段提交更易於編碼與理解且資料庫消耗增加少

訪問原文，來自MageekChiu

相關文章