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

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

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