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

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

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

Elasticsearch是一個強(qiáng)大的開源搜索引擎（不僅如此，還是一個分布式存儲、實時分析系統(tǒng)），作為后端開發(fā)者，我們常常需要用到它，甚至是借鑒其原理來實現(xiàn)自己特定的功能，因為了解一下是很有必要的。這本書不僅講了使用方法，還講了原理，很適合我們學(xué)習(xí)與查閱。

亮點(diǎn)：

Elasticsearch使用Java開發(fā)并使用 Lucene 作為其核心來實現(xiàn)所有索引和搜索的功能，它的目的是通過簡單的 RESTful API 來隱藏 Lucene 的復(fù)雜性。也對用戶隱藏了分布式系統(tǒng)的復(fù)雜性，而且提供了一系列運(yùn)行良好的默認(rèn)值，從而讓全文搜索變得簡單，達(dá)到開箱即用的效果

ES與傳統(tǒng)RDB的對比：

Relational DB -> Databases -> Tables -> Rows -> Columns

Elasticsearch -> Indices -> Types -> Documents -> Fields

ES的自動實現(xiàn)了分片、負(fù)載均衡、發(fā)現(xiàn)、冗余、選主、同步、擴(kuò)展遷移、容錯等功能。一個節(jié)點(diǎn)(node)就是一個Elasticsearch實例，而一個集群(cluster)由一個或多個節(jié)點(diǎn)組成，它們具有相同的cluster.name，集群中一個節(jié)點(diǎn)會被選舉為主節(jié)點(diǎn)(master)，它將臨時管理集群級別的一些變更，例如新建或刪除索引、增加或移除節(jié)點(diǎn)等。索引只是一個用來指向一個或多個分片(shards，是一個 Lucene 實例)的邏輯命名空間(logical namespace)，分片可以是主分片(primary shard)或者是復(fù)制分片(replica shard)。索引中的每個文檔屬于一個多帶帶的主分片，所以主分片的數(shù)量決定了索引最多能存儲多少數(shù)據(jù)，復(fù)制分片只是主分片的一個副本，它可以防止硬件故障導(dǎo)致的數(shù)據(jù)丟失，同時可以提供讀請求，啟動新節(jié)點(diǎn)時集群會重新組織并均勻分配各個分片

ES提供了豐富的數(shù)據(jù)操縱功能，不僅有簡單的查詢字符串搜索（含通配符），還有DSL，可以構(gòu)建更復(fù)雜、強(qiáng)大的查詢

批量請求可以減少網(wǎng)絡(luò)往返次數(shù)開銷，以及日志數(shù)量，可以提升性能（mysql也有這種做法），這個批量的大小要根據(jù)你的硬件來定制

倒排索引是全文搜索的核心技術(shù)，也就是按照每個單詞（經(jīng)過分詞后）劃分歸屬集，存儲包含這個單詞的文檔，檢索是按照單詞的，所以可以很快返回相關(guān)文檔

......

此外需要注意的是Elasticsearch發(fā)展太快，書籍只是用來系統(tǒng)性的學(xué)習(xí)的，如果真的要使用起來，還是要去官網(wǎng)看最新的用法，但是基本原理和思想變化是不多的。

大數(shù)據(jù)日知錄 (豆瓣): https://book.douban.com/subje...

這本書可以當(dāng)做大數(shù)據(jù)領(lǐng)域的字典，包含很多方面，雖然有些地方有一點(diǎn)劃水嫌疑（比如一大串單位換算，歌詞），但是畢竟瑕不掩瑜，亮點(diǎn)頗多，看完這本書后基本上對大數(shù)據(jù)就能有一個整體的認(rèn)識了。

亮點(diǎn)：

大數(shù)據(jù)沒有標(biāo)準(zhǔn)定義，可以用 4V 來表述：Volume（體量巨大）、Velocity（產(chǎn)生速率高）、Variety（類型多樣）、Value（需要從海量數(shù)據(jù)中發(fā)現(xiàn)價值）?？梢酝ㄟ^大數(shù)據(jù)生態(tài)的一系列工具（hadoop生態(tài)）來解決大數(shù)據(jù)問題

數(shù)據(jù)分片主要有兩種方式：哈希和范圍。哈希有：round-robin（亦即哈希值取余，簡單但擴(kuò)展性不佳）；虛擬槽（key映射到槽，槽映射到機(jī)器，解耦key與機(jī)器）；一致性哈希（哈希值范圍歸屬，引入虛擬節(jié)點(diǎn)后擴(kuò)展性與平衡性俱佳）。范圍有：按不同的主鍵劃分順序。哈希的問題是范圍查詢支持不佳，范圍的問題是可能冷熱數(shù)據(jù)不均。除了分片問題，為了實現(xiàn)高可用還要解決復(fù)制問題，這就會引入各種級別的一致性（強(qiáng)弱）問題和復(fù)制策略（全、增量，同、異步）問題

采用獨(dú)立的資源管理與調(diào)度系統(tǒng)與靜態(tài)資源劃分相比有3大好處：減少閑置，提高利用率；增加數(shù)據(jù)共享能力；支持多類型/版本計算框架。通常具有三種范型：集中式調(diào)度、兩級調(diào)度、狀態(tài)共享調(diào)度，三者逐步弱化中央調(diào)度功能、強(qiáng)化框架自由度，適用于不同的應(yīng)用場景

數(shù)據(jù)總線的作用是形成數(shù)據(jù)變化通知通道，當(dāng)集中存儲的數(shù)據(jù)源（一般是RDB）數(shù)據(jù)發(fā)生變化時，能夠盡快通知相關(guān)組件。實現(xiàn)有2種思路，雙寫（需要引入兩階段提交來保證原子性）或者數(shù)據(jù)庫日志挖掘（如 binlog解析）

HayStack作為對象存儲，其設(shè)計有一次寫入、多次讀取、從不更改、很少刪除的特性，由于圖片數(shù)量很大，所以把多個圖片拼在一起減少元數(shù)據(jù)數(shù)量，同時減少元數(shù)據(jù)屬性，這樣就可以把元數(shù)據(jù)放入內(nèi)存，讀取對象時只需要一次內(nèi)存與一次磁盤訪問即可

一般數(shù)據(jù)多副本用來提高可用性與讀取性能，對熱數(shù)據(jù)來說還比較劃算，但是冷數(shù)據(jù)這樣就有點(diǎn)浪費(fèi)，可以用糾刪碼：數(shù)據(jù)分成n分，形成m分冗余的校驗信息，這m+n分?jǐn)?shù)據(jù)最多丟失m份數(shù)據(jù)依然可以恢復(fù)原數(shù)據(jù)，節(jié)約了存儲空間，常見編碼有Reed-Solomon、LRC等

批處理系統(tǒng)主要有兩種范型：MapReduce（兩階段批處理任務(wù)，簡潔但是表達(dá)能力不夠豐富）和DAG（圖計算，可以表述復(fù)雜并發(fā)任務(wù)之間的依賴關(guān)系，所以也比較復(fù)雜）。Spark本質(zhì)也是DAG批處理系統(tǒng)，描述能力更強(qiáng)，而且基于內(nèi)存速度快，對于同一個任務(wù)可以反復(fù)多次進(jìn)行，最適用于迭代式機(jī)器學(xué)習(xí)。Storm是流式計算，講究即時處理

常見的流式計算（甚至所有分布式架構(gòu)）主要分為主從、P2P模式兩種，主節(jié)點(diǎn)做管理比較方便簡潔，而P2P由于去中心化，所以系統(tǒng)管理復(fù)雜，該類架構(gòu)實例較少

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

通過這本書我們來深入了解一下Docker的用法與原理，更主要的是的Kubernates這個編排容器的強(qiáng)大工具的最佳實踐與運(yùn)行原理。最后可以了解下整個容器技術(shù)的生態(tài)。

亮點(diǎn)：

云計算是一種資源的服務(wù)模式，支持隨時隨地按需從共享資源池中獲得所需資源（網(wǎng)絡(luò)、服務(wù)器、存儲、應(yīng)用與服務(wù)）且資源可以快速供應(yīng)并釋放，減少了資源管理工作開銷。包括IaaS（基礎(chǔ)設(shè)施如計算、存儲、網(wǎng)絡(luò)）、PaaS（運(yùn)行時環(huán)境設(shè)施如數(shù)據(jù)庫、日志服務(wù)等）、SaaS（可直接使用的應(yīng)用服務(wù)）

一個軟件項目的成功與否與其能否帶動一個生態(tài)系統(tǒng)的發(fā)展相關(guān)，docker顯然做到了，帶動了整個容器技術(shù)的發(fā)展，而容器技術(shù)直接改善了:持續(xù)部署與測試、鏡像和容器的跨平臺支持、環(huán)境標(biāo)準(zhǔn)化與版本控制、資源利用率、眾多鏡像且易于理解和使用

容器云是以容器為資源分割和調(diào)度的基本單位，封裝整個軟件運(yùn)行時環(huán)境，為開發(fā)者提供構(gòu)建、發(fā)布和運(yùn)行分布式應(yīng)用的平臺。容器云專注資源共享、隔離和編排部署時更接近IaaS，容器云滲透到應(yīng)用支持與運(yùn)行時環(huán)境時更接近于PaaS

namespace是linux中實現(xiàn)進(jìn)程隔離（資源隔離）的主要技術(shù)，具體的隔離由幾個系統(tǒng)調(diào)用clone、setns、unshare和參數(shù)完成：CLONE_NEWUTS(主機(jī)與域名)、CLONE_NEWIPC(進(jìn)程間通信常見的包括信號量、消息隊列、共享內(nèi)存)、%%_NEWPID(pid)、%%_NEWNET(網(wǎng)絡(luò)設(shè)備、棧、端口)、%%_NEWNS(掛載點(diǎn)文件系統(tǒng))、%%_NEWUSER(用戶與組)......常見做法是通過clone函數(shù)實現(xiàn)，而setns能直接進(jìn)入一個已有的命名空間

cgroups是linux實現(xiàn)資源限制的主要技術(shù)（顧名思義就是把一組任務(wù)統(tǒng)一加以控制），實現(xiàn)資源（CPU、Memory、IO等）限制和優(yōu)先級分配及其使用量統(tǒng)計、任務(wù)啟停等功能，其本質(zhì)是內(nèi)核附加在程序上的一些列鉤子，通過程序運(yùn)行時對資源調(diào)度觸發(fā)相應(yīng)的鉤子達(dá)到資源追蹤和限制的目的

etcd受ZooKeeper和doozer啟發(fā)，具有類似特點(diǎn)，但也有自己的特色：基于http，用curl就可以使用；可選ssl認(rèn)證；單實例每秒千次寫；使用raft保證一致性。是一個 k v stroe，廣泛用于服務(wù)發(fā)現(xiàn)、發(fā)布訂閱、負(fù)載均衡、分布式通知與協(xié)調(diào)、分布式鎖與競選、分布式隊列、集群監(jiān)控等

容器云就是以容器為資源分割和調(diào)度的基本單位，封裝整個軟件運(yùn)行環(huán)境，為開發(fā)者和管理員提供用于構(gòu)建、發(fā)布和運(yùn)行分布式應(yīng)用的平臺。直觀的云就是一群容器被分組，組間隔離、組內(nèi)共享，借助全局組件進(jìn)行管理。有許多工具如“小神器”Compose（dockerfile定義容器，compose定義配置和集群）、跨平臺宿主環(huán)境管理工具Machine（跨云平臺的容器創(chuàng)建與管理）、集群抽象工具Swarm（在多臺宿主機(jī)上抽象，使得多容器管理接口統(tǒng)一）等

Kubernetes是一個（目前最流行的）管理跨主機(jī)容器化應(yīng)用的系統(tǒng)，實現(xiàn)了包含應(yīng)用部署、高可用管理、彈性伸縮在內(nèi)的一系列基礎(chǔ)功能并封裝為簡單的Rest API 對外使用。其關(guān)鍵設(shè)計就是pod：一組可以互相交互、位于多個宿主的容器組，每個pod都可以有replica來保證高可用和伸縮性

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

TCP/IP是我們?nèi)粘＝佑|最多的協(xié)議，搞后端的總會遇上粘包分包、reset、too many files等等問題，搞懂了TCP/IP才能解決這些問題，這本書對于我們?nèi)嫔钊氲牧私膺@個協(xié)議棧有很大的幫助。

亮點(diǎn)：

網(wǎng)橋是在鏈路層上對網(wǎng)絡(luò)進(jìn)行互連，而路由器則是在網(wǎng)絡(luò)層上對網(wǎng)絡(luò)進(jìn)行互連。網(wǎng)橋使得多個LAN組合在一起，這樣對上層來說就好像是一個局域網(wǎng)，TCP/IP傾向于使用路由器而不是網(wǎng)橋來連接網(wǎng)絡(luò)，

環(huán)回接口（127.0.0.1或者說localhost）允許在同一臺主機(jī)上的程序和服務(wù)器程序通過 TCP/IP進(jìn)行通信，我們想象一旦傳輸層檢測到目的端地址是環(huán)回地址時，應(yīng)該可以省略部分傳輸層和所有網(wǎng)絡(luò)層的邏輯操作。但是大多數(shù)的產(chǎn)品還是照樣完成傳輸層和網(wǎng)絡(luò)層的所有過程，只是當(dāng)IP數(shù)據(jù)報離開網(wǎng)絡(luò)層時把它返回給自己，看上去用傳輸層和 IP層的方法來處理環(huán)回數(shù)據(jù)似乎效率不高，但它簡化了設(shè)計，因為環(huán)回接口可以被看作是網(wǎng)絡(luò)層下面的另一個鏈路層。但是Unix Domain Socket 則省略了一些協(xié)議封裝的過程，提高了性能

ICMP雖然基于IP，但是能反映和控制IP的狀況，所以通常就歸于IP層。我們常使用的Ping就是利用 ICMP echo實現(xiàn)的，不需要經(jīng)過傳輸層；Tranceroute是不停的發(fā)送ICMP echo 或者UDP包，逐次增大TTL，直到到達(dá)目的主機(jī)（亦即不報ICMP超時而是ICMP echo 回復(fù)或者ICMP端口不可達(dá)），從而獲得路徑

TCP傳小報文在公網(wǎng)上容易引起擁塞，所以有Nagle（小于mss的包必須等到前面包收到ack再發(fā)，或者多個小分組湊成大分組）和Delayed Ack（ack在一定時間內(nèi)等順風(fēng)車如數(shù)據(jù)包或者其它ack一起發(fā)送，累計Ack）分別在發(fā)送端和接收端避免，這也是解決糊涂窗口綜合征的辦法，但是對于實時性要求較高的應(yīng)用也需要關(guān)閉這些算法

TCP在局域網(wǎng)發(fā)送可以一開始便發(fā)送多個報文段，而在公網(wǎng)上（中間可能有多個較慢的路由器或者鏈路）一般采用慢啟動算法慢慢探測鏈路的極限，這也是用“樂觀”和“悲觀”兩種策略來應(yīng)對不同的場景，就像悲觀鎖與樂觀鎖在不同的多線程競爭程度下的使用性能會有不同體現(xiàn)一樣

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

性能問題橫跨諸多領(lǐng)域：CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)、代碼質(zhì)量等等，從裸機(jī)到虛擬機(jī)，本書幾乎做到了面面俱到。本書建立在對操作系統(tǒng)的深刻理解之上，甚至于統(tǒng)計學(xué)和實驗之上，從概念、模型、觀測到實驗手段，從原理上和方法上來回答了一系列問題如：“如何度量網(wǎng)絡(luò)繁忙程度”、“服務(wù)中斷是進(jìn)程問題還是機(jī)器問題”、“SSD與機(jī)械硬盤的使用比例是多少”等，讓我們在面對性能問題時心中有數(shù)，有典可查。同時，也對我們?nèi)粘５难邪l(fā)起到一個監(jiān)督作用。

亮點(diǎn)：

本書的序也很棒，都有自己的觀點(diǎn)：單進(jìn)程的瓶頸很好定位與分析，但整個業(yè)務(wù)的瓶頸有可能不在單元內(nèi)部，而是單元之間的網(wǎng)絡(luò)服務(wù)，所以要動態(tài)分析；無論是調(diào)試（debug是靜態(tài)的）還是調(diào)優(yōu)（tune是動態(tài)的）都需要我們既有全局觀也要能探微索隱，技術(shù)成長的路徑是，編碼->調(diào)試->調(diào)優(yōu)；很多問題解決不了是因為我們不知道我們不知道（性能問題太多太雜），比如不知道設(shè)備中斷很耗CPU、Oracle session很耗內(nèi)存（即使不活躍）等，所以說知識的廣度和深度都要有才能融會貫通；街燈法（哪里出了問題就找哪里，但實際上問題不一定出在這里）這個觀點(diǎn)很新穎，我們要盡力避免，采用科學(xué)法：描述問題-假設(shè)-預(yù)測-實驗-分析；性能問題很主觀和微妙，本書卻提供了一個系統(tǒng)性的方法論

性能是一個全棧的問題（不僅是一般概念上的應(yīng)用與數(shù)據(jù)庫，還包括os與硬件），所以我們必須要清楚數(shù)據(jù)的整個流向，通過不同的人員、團(tuán)隊合作（java開發(fā)、DBA、網(wǎng)絡(luò)工程師等），在整個流程中尋找瓶頸，怎么下手需要經(jīng)驗，但是我們可以通過動態(tài)追蹤（基于CPU指令并在之上動態(tài)構(gòu)建監(jiān)控數(shù)據(jù)）收集數(shù)據(jù)來更好地分析和定位

有已知的已知、已知的未知、未知的未知，性能問題和學(xué)習(xí)系統(tǒng)是一樣的，你知道得越多，你不知道的就越多。但是你了解的越多，那些未知的未知就可能變成已知的未知，最終可以變成已知的已知，所以見識一定要廣闊，鉆研一定要深入，做個T字形人才。

本文提出了很多性能問題定位方法：街燈法（選熟悉的工具進(jìn)行分體，比如top命令，這種方法與運(yùn)氣有關(guān)）；隨機(jī)變動法（隨機(jī)找參數(shù)修改并觀察效果）；責(zé)怪他人法（可能是其他團(tuán)隊的問題）；Ad Hoc 清單核對法（對常見問題列出檢查清單，一一嘗試）；科學(xué)法（問題，假設(shè)，預(yù)測，實驗，分析）；工具導(dǎo)向法（把手里的工具都用用）；R方法（Oracle的性能分析方法，意在找到延時根源）；USE法（圍繞 使用率，飽和度，錯誤 三個指標(biāo)進(jìn)行分析）...... 這些方法平日我們可能都用過，這里作者卻總結(jié)出來形成了系統(tǒng)方法論

性能觀測工具要么基于計數(shù)器（由內(nèi)核維護(hù)的統(tǒng)計數(shù)據(jù)，默認(rèn)啟用可以視作零開銷,一般可以從/proc文件系統(tǒng)中讀取，如vmstat,mpstat,iostat,netstat,sar,ps,top）要么基于跟蹤（跟蹤事件來分析，默認(rèn)不啟用所以有開銷，如tcpdump,blktrace,Dtrace,strace,gdb）還有些基于剖析（profiling，對目標(biāo)進(jìn)行采樣或快照來歸納特征比如CPU使用率、緩存命中率，有oprofile,perf,Dtrace），有進(jìn)程級別的也有系統(tǒng)級別的。

應(yīng)用程序性能分析之前首先要定好目標(biāo)比如延時、吞吐量、資源利用率等，一旦選中目標(biāo)就可以處理限制該目標(biāo)的主要因素了，如延時可能是磁盤、網(wǎng)絡(luò)，吞吐量可能是CPU等。提高應(yīng)用性能常用技術(shù)有：合適的IO大小，IO開銷包括初始化緩沖區(qū)、系統(tǒng)調(diào)用、上下文切換、權(quán)限檢查、地址映射、驅(qū)動代碼執(zhí)行等等，一次IO大小合適既能避免太小導(dǎo)致太多尋道也能避免太大浪費(fèi)傳輸能力；緩存，cache提升讀能力；緩沖區(qū)，buffer提升寫能力；輪詢，比如poll與epoll，基于事件，避免普通輪詢的CPU空轉(zhuǎn)消耗與延時；并發(fā)與并行，利用多處理器優(yōu)勢；非阻塞IO，避免較慢的IO成為較快的CPU的“拖油瓶”；處理器綁定，提高內(nèi)存本地性，減少IO

CPU使用率是指一段時間內(nèi)忙于執(zhí)行工作的比例，高使用率不一定是問題，可能意味著正在繁忙的工作，但是工作不一定是真正在執(zhí)行指令，也可能是等待IO導(dǎo)致的停滯周期或者等待鎖的SpinLock，所以高使用率（每指令周期數(shù)CPI也高）不一定是效率高，還要看指令本身的特點(diǎn)，比如CPU親和性、內(nèi)存本地性等。

文件系統(tǒng)通過緩存、緩沖、異步等手段可以減輕磁盤或遠(yuǎn)程系統(tǒng)對應(yīng)用的影響，所以其性能研究很重要。

本書雖然分為cpu、內(nèi)存、文件、磁盤等不同領(lǐng)域來說性能，但是有好多命令比如top、vmstat是跨領(lǐng)域的，就重復(fù)了很多次，把本來就很厚的書搞得更厚了，所以我們看書過程可以一次性把一個命令搞熟悉，就可以跳過很多重復(fù)了。

谷歌可以說是IT業(yè)界標(biāo)桿，引領(lǐng)了許多潮流：大數(shù)據(jù)生態(tài)、分布式系統(tǒng)、人工智能等等，那么我們就來看看這么優(yōu)秀的谷歌是如何工作的。

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

亮點(diǎn)：

人的主觀能動性是有很大力量的，所以企業(yè)需要堅信員工都是好的，再就是要有足夠的勇氣，把員工看成是企業(yè)的主人翁， 而不是把他們當(dāng)成機(jī)器。機(jī)器會完成工作；主人翁會竭盡所能幫助企業(yè)和團(tuán)隊獲得成功。你給員工以自由，員工將還你以驚喜

書中反復(fù)強(qiáng)調(diào)，無法從每日工作中得到一定滿足感的人，就是去了薪酬中最好的一部分。你或許不是一家公司的創(chuàng)始人，但是也可以成為一個團(tuán)隊、一個家庭或一種文化的創(chuàng)始人，盡力創(chuàng)造出空間使得其他創(chuàng)始人與自己攜手同行。

公司文化要快樂，快樂使我們不必謹(jǐn)小慎微，可以發(fā)揮開發(fā)和探索的能力，但這只是表面，文化的三個根本元素是使命（讓工作有意義）、透明（相信員工，分享數(shù)據(jù)）和權(quán)利（給員工話語權(quán)，便于做出高水平?jīng)Q策）。文化塑造戰(zhàn)略，而非相反。

聘用水平超過90%應(yīng)聘者的員工，最糟的情況他們也能有平均水平的表現(xiàn)。這些員工幾乎不可能成為公司里表現(xiàn)最差的。但是如果招聘平均水平的員工，不僅會耗費(fèi)大量的培訓(xùn)資源，而且很可能他們的表現(xiàn)會低于平均水平而不是高于平均水平

我們發(fā)現(xiàn)在個人競爭中表現(xiàn)好的人并不總能成為優(yōu)秀的團(tuán)隊伙伴。贏得這些比賽的人或許很聰明，但通常只是在某一領(lǐng)域有所專長?；蛘呤且驗樗麄兞?xí)慣于解決有明確終點(diǎn)和確定答案的問題， 而不是掌控現(xiàn)實世界中的復(fù)雜狀況。 我們在谷歌就有這樣的要求， 我們尋找的人不僅能夠解決今天的問題， 而且能夠解決未來可能出現(xiàn)的各種未知問題

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

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

亮點(diǎn)：

穩(wěn)定性要做好幾點(diǎn)：研發(fā)與運(yùn)維要靠近、故障標(biāo)準(zhǔn)要統(tǒng)一并強(qiáng)化處理流程、建設(shè)統(tǒng)一的基礎(chǔ)設(shè)施并完善團(tuán)隊融合做到“書同文車同軌行同倫”；堅持技術(shù)創(chuàng)新比如新技術(shù)、全鏈路壓測與異地多活等；設(shè)置專門的崗位與部門來保障穩(wěn)定

用戶使用pwrite寫數(shù)據(jù)，加上O_DIRECT標(biāo)識，只能保證數(shù)據(jù)直接落盤（忽略Buffer cache），而文件系統(tǒng)元數(shù)據(jù)仍然存儲在inode cache（內(nèi)存）中，當(dāng)加上O_SYNC標(biāo)識，寫操作變?yōu)橥綄懀╯ynchronous I/O），此時可以保證元數(shù)據(jù)同步落盤。所以我們對整個IO鏈路理解的越清楚，就越容易看到問題背后的真相

防止緩存被擊穿不能簡單用預(yù)估流量除以單臺緩存機(jī)器，因為很有可能是按key的hash分布的，有些高頻key或者大value的key若處在同一機(jī)器則會輕易使此機(jī)器超過閾值（并發(fā)量與流量）。所以要監(jiān)控所有key，一旦發(fā)現(xiàn)QPS限流或流量限流就要快速定位問題key，再結(jié)合使用的散列算法將可疑key分散到各個機(jī)器上去，分散壓力

去網(wǎng)關(guān)化的軟負(fù)載形式，會將負(fù)載均衡策略下沉到客戶端，避免網(wǎng)關(guān)的單點(diǎn)故障。當(dāng)然避免不了需要統(tǒng)一的網(wǎng)關(guān)作為接入層時，就要考慮同城多機(jī)房甚至異地這樣的高可用策略。必要的時候要采取自我保護(hù)的限流機(jī)制，避免雪球效應(yīng)，一臺一臺機(jī)器接連爆表

select * 的弊端一般我們認(rèn)為是若字段較多或較大對性能有影響，其實不止這樣，在分庫分表的過程中，這個語句會導(dǎo)致兼容問題，還有其他問題如增加解析成本，不能使用覆蓋索引等

冪等控制是資金安全中的重中之重，對于事務(wù)、分布式鎖、重試等要好好運(yùn)用，建議在系統(tǒng)設(shè)計時，將第三方唯一性的冪等控制作為冪等控制的兜底方案。我最近在玩支付寶的積分換天貓券，因為券很少，需要積分兌換并且搶，這是一個明顯的事務(wù)：扣積分、得到券。為了安全起見，支付寶提示了可能先扣分但是沒有搶到券，事后再把積分還給你，這就是一個典型的補(bǔ)償機(jī)制。本來可以使用兩階段提交的，但是這種做法允許短暫的不一致狀態(tài)，達(dá)到最終一致較兩階段提交更易于編碼與理解且數(shù)據(jù)庫消耗增加少

訪問原文，來自MageekChiu