摘要：可以通過大數據生態的一系列工具生態來解決大數據問題數據分片主要有兩種方式哈希和范圍。哈希的問題是范圍查詢支持不佳，范圍的問題是可能冷熱數據不均。

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

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——容器與容器云（第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：協議 (豆瓣) 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