摘要：續(xù)前文后端好書閱讀與推薦，幾十天過去了，又看了兩本好書還有以前看過的書，這里依然把它們總結(jié)歸納一下，加入一些自己的看法有用的鏈接和可能的延伸閱讀，并推薦給需要的同學(xué)。

續(xù)前文 后端好書閱讀與推薦 - Mageek`s Wonderland ，幾十天過去了，又看了兩本好書（還有以前看過的書），這里依然把它們總結(jié)歸納一下，加入一些自己的看法、有用的鏈接和可能的延伸閱讀，并推薦給需要的同學(xué)。

深入理解Java虛擬機(jī) (豆瓣) https://book.douban.com/subje...

Java怎么用，是一個問題；怎么用好是一個大問題；這么用是為什么，是一個更大的問題。搞懂這三個問題應(yīng)該是每一個搞Java的人都要追求的目標(biāo)，讀完本書，就能把這個更大的問題搞懂了。

本書亮點：

模塊化是解決應(yīng)用系統(tǒng)與技術(shù)平臺越來越復(fù)雜，越來越龐大的問題的一個重要途徑，也是建立各種功能的標(biāo)準(zhǔn)件的前提。

Java運行時數(shù)據(jù)區(qū)幾個主要部分：程序計數(shù)器（可看作當(dāng)前線程所執(zhí)行的字節(jié)碼的行號指示器）、虛擬機(jī)棧（每一個方法從調(diào)用直至執(zhí)行完成的過程，就對應(yīng)著一個棧幀在虛擬機(jī)棧中入棧到出棧的過程，而棧幀存儲局部變量表、 操作數(shù)棧、 動態(tài)鏈接、 方法出口等信息）、本地方法棧（Native方法對應(yīng)的棧）、堆（所有線程共享的一塊內(nèi)存區(qū)域，存放對象實例）、方法區(qū)（各個線程共享的內(nèi)存區(qū)域，存儲已被虛擬機(jī)加載的類信息、常量、靜態(tài)變量、即時編譯器編譯后的代碼等數(shù)據(jù)）、常量池（方法區(qū)的一部分，存放編譯期生成的各種字面量和符號引用）。

對象訪問方式取決于虛擬機(jī)實現(xiàn)而定的，目前主流的訪問方式有使用句柄和直接指針兩種：如果使用句柄訪問的話，那么Java堆中將會劃分出一塊內(nèi)存來作為句柄池，reference中存儲的就是對象的句柄地址，而句柄中包含了對象實例數(shù)據(jù)與類型數(shù)據(jù)各自的具體地址信息；如果使用直接指針訪問，reference中存儲的直接就是對象地址。

Java垃圾回收采用分代回收機(jī)制，新生代和老生代采用不同的算法（node.js也是），而不管什么機(jī)制，判斷一個對象是否存活都是基本的步驟，方法有：引用計數(shù)法，給對象添加一個引用計數(shù)器，每當(dāng)一個地方引用它時，計數(shù)器就加1，引用失效時，計數(shù)器就減1，任何時刻計數(shù)器為0的對象就是不可能再被使用的，這個方法實現(xiàn)簡單，但是不能解決循環(huán)引用問題，所以主流JVM不使用，但是這個算法也適用于許多地方如Python，微軟的COM；可達(dá)性分析，按照對象之間的引用關(guān)系維護(hù)一個引用鏈，如果一個對象不可達(dá)GC Roots，那么就是可回收的，應(yīng)用于主流JVM中。

finalize是一種迎合C++程序員的妥協(xié)，運行代價高昂，不確定性大，無法保證各個對象的調(diào)用順序。有些教材中描述它適合做“關(guān)閉外部資源”之類的工作，這完全是對這個方法用途的一種自我安慰。finalize能做的所有工作，使用try-finally或者其他方式都可以做得更好、更及時，所以建議大家完全可以忘掉Java語言中有這個方法的存在。

幾乎各種語言或多或少都提供過一些語法糖來方便程序員的代碼開發(fā)，這些語法糖雖然不會提供實質(zhì)性的功能改進(jìn)，但是它們或能提高效率，或能提升語法的嚴(yán)謹(jǐn)性，或能減少編碼出錯的機(jī)會。不過也有一種觀點認(rèn)為語法糖并不一定都是有益的，大量添加和使用“含糖”的語法，容易讓程序員產(chǎn)生依賴，無法看清語法糖的糖衣背后代碼的真實面目。所以我們既要會使用語法糖，同時也要搞懂背后的原理，這樣才能進(jìn)階呀。比如泛型技術(shù)：泛型只在程序源碼中存在，在編譯后的字節(jié)碼文件中，就已經(jīng)替換為原來的原生類型。

Java程序最初是通過解釋器（Interpreter）進(jìn)行解釋執(zhí)行的，當(dāng)虛擬機(jī)發(fā)現(xiàn)某個方法或代碼塊的運行特別頻繁時，就會把這些代碼認(rèn)定“熱點代碼”（Hot Spot Code）。 為了提高熱點代碼的執(zhí)行效率，在運行時，虛擬機(jī)將會把這些代碼編譯成與本地平臺相關(guān)的機(jī)器碼，并進(jìn)行各種層次的優(yōu)化，完成這個任務(wù)的編譯器稱為即時編譯器（Just In Time Compiler，簡稱JIT編譯器）

基于高速緩存(Cache)的存儲交互很好地解決了處理器與內(nèi)存的速度矛盾，但是也為計算機(jī)系統(tǒng)帶來更高的復(fù)雜度，因為它引入了一個新的問題：緩存一致性；除了增加高速緩存之外，為了使得處理器內(nèi)部的運算單元能盡量被充分利用，處理器可能會對輸入代碼進(jìn)行亂序執(zhí)行(Out-Of-Order Execution)優(yōu)化，類似的JVM也有指令重排(Instruction Reorder)。這兩點是提高程序運行的主要方法，然而也是多線程程序難以正確編寫的主要原因。

先行發(fā)生（happens-before）是Java內(nèi)存模型中定義的兩項操作之間的偏序關(guān)系，如果說操作A先行發(fā)生于操作B，其實就是說在發(fā)生操作B之前，操作A產(chǎn)生的影響能被操作B觀察到，“影響”包括修改了內(nèi)存中共享變量的值、發(fā)送了消息、調(diào)用了方法等。時間先后順序與先行發(fā)生原則之間基本沒有太大的關(guān)系，所以我們衡量并發(fā)安全問題的時候不要受到時間順序的干擾，一切必須以先行發(fā)生原則為準(zhǔn)。

這本書是基于jdk1.7的，如果要追蹤最新的Java和JVM規(guī)范，可以看這里。
另外，上面提到的第一個問題可以參閱Java核心技術(shù)，第二個問題可以參閱Java編程思想、Effective Java，第三個問題還可以參閱HotSpot實戰(zhàn)。這幾本書我都瀏覽過，部分有細(xì)讀，都是相當(dāng)經(jīng)典的。

高性能MySQL (豆瓣) https://book.douban.com/subje...

這本書可謂是MySQL領(lǐng)域的權(quán)威之作，從架構(gòu)到測試，從性能分析到查詢優(yōu)化，從軟件配置優(yōu)化到服務(wù)器硬件優(yōu)化，從單實例到主從復(fù)制、負(fù)載均衡，從底層數(shù)據(jù)庫優(yōu)化到應(yīng)用層優(yōu)化......本書真可謂是面面俱到，同時又很有深度，絕非淺嘗輒止。

本書亮點：

所謂的鎖策略，就是在鎖的開銷和數(shù)據(jù)的安全性之間尋求平衡，這種平衡自然也影響到性能。這句話適用于世間的一切工具，安全性和可用性總是矛盾的，我們在使用工具或者開發(fā)工具的時候，都要尋求一個最佳平衡點。

除非需要使用InnoDB不具備的的特性，并且沒有其他辦法可以替代，則都應(yīng)該優(yōu)先使用InnoDB引擎，也不要多引擎混用，例如全文索引可以使用InnoDB+Sphinx，而不要使用MyISAM引擎，因為InnoDB其他方面的優(yōu)點可以完全碾壓MyISAM，比如崩潰恢復(fù)快，支持事務(wù)，支持行級鎖，支持真正的熱備份等等。

基準(zhǔn)測試可以驗證對于系統(tǒng)的假設(shè)，檢查異常行為，找出擴(kuò)展性瓶頸等等。需要注意的是不要使用真實數(shù)據(jù)的子集，作物的數(shù)據(jù)分布，忽略預(yù)熱等等，這些錯誤的操作會使得測試結(jié)果無用或者不精確。而且要建立參數(shù)與結(jié)果文檔化的規(guī)范，這樣才利于結(jié)果分析與優(yōu)化。

很多人在優(yōu)化時都將精力放在修改某些東西上，卻很少去測量；正確的做法是要盡量測量響應(yīng)花的時間在哪，正確的測量一般都能將性能問題的點暴露出來，我們就能更好的對癥下藥，而不是盲目優(yōu)化（花1000塊優(yōu)化一個只值500塊的業(yè)務(wù)，或者已經(jīng)處于頂點的業(yè)務(wù)不就是虧了嗎）。所以說，決策要基于數(shù)據(jù)而不是感覺。

良好的邏輯設(shè)計和物理設(shè)計是高性能的基石，某些反范式的設(shè)計可能加快某些查詢，比如計數(shù)表和匯總表是一種很好的查詢優(yōu)化方式，能提高統(tǒng)計類的查詢速度，但是維護(hù)起來就比較麻煩，可能降低數(shù)據(jù)插入速度。這些都需要自己根據(jù)業(yè)務(wù)來進(jìn)行權(quán)衡（比如讀寫比），有陰就有陽嘛。

選擇能正確存儲數(shù)據(jù)的最小類型：既省空間又省計算時間，簡單就好：比如使用MySQL內(nèi)建時間戳而不是自己使用字符串，盡量避免null：因為null使得索引、統(tǒng)計、值比較都更加復(fù)雜還可能會占用更多空間。

InnoDB有一個“自適應(yīng)哈希索引”的功能，當(dāng)引擎注意到某些索引值被頻繁使用時就會在內(nèi)存中基于B+Tree索引之上再創(chuàng)建一個hash索引，這樣就讓B+Tree也具有hash索引的優(yōu)點比如快速查找。

小表通常全表掃描更高效，中大型表才適合用索引，使用索引過程中要注意，索引列必須多帶帶的出現(xiàn)在比較符號的右側(cè)而不是表達(dá)式的一部分（這會使索引失效），使用前綴索引來節(jié)省空間提高檢索效率，多列索引要注意順序不然容易失效，聚簇索引可以提高訪問速度。

慢查詢優(yōu)化：只向數(shù)據(jù)庫請求需要的列（比如不要隨意select * ）、避免不必要的行掃描、必要的時候分解查詢（拆分大的查詢，分解關(guān)聯(lián)查詢）。

默認(rèn)配置文件是經(jīng)過大量測試，所以屬于較優(yōu)解，一般符合普通用戶，要修改也主要是根據(jù)業(yè)務(wù)而不是服務(wù)器配置；任何打算長期使用的配置都應(yīng)該寫到全局配置文件而不是在命令行指定，因為如果偶然啟動忘了（事實是經(jīng)常會忘，好記性不如爛筆頭是個真理）設(shè)置就會有風(fēng)險。

MySQL復(fù)制功能不僅有利于構(gòu)建高性能應(yīng)用，同時也是高可用性（負(fù)載均衡、故障切換）、可擴(kuò)展性（升級）、災(zāi)難恢復(fù)、備份以及數(shù)據(jù)倉庫等工作的基礎(chǔ)。

數(shù)據(jù)如果非常龐大，比如幾億行了，單臺機(jī)器已經(jīng)撐不住了，通常要采取分片技術(shù)，分片最大的問題就是查詢與獲取數(shù)據(jù)，我們的目標(biāo)是對最重要且頻繁查詢的數(shù)據(jù)減少分片（熱點數(shù)據(jù)通常就那么多）。所以分片關(guān)鍵問題就在于選擇一個好的分區(qū)鍵，通常是一個數(shù)據(jù)庫中非常重要的實體的主鍵。

不僅要關(guān)注MySQL，還要關(guān)注應(yīng)用層優(yōu)化：Apache服務(wù)器處理靜態(tài)文件都可能使用一個占用內(nèi)存很大的進(jìn)程（上一個請求處理完后，該進(jìn)程仍然保持著），所以最好使用Nginx或者Lighttpd來處理靜態(tài)內(nèi)容服務(wù)，而且靜態(tài)文件名不要重用，要加上版本號，這樣就能避免瀏覽器緩存問題；主動緩存如Squid，被動緩存如Memcached，都可以對性能獲得數(shù)量級的提升，關(guān)鍵就在于找到正確的粒度和緩存過期策略組合，通常主動緩存更好，因為對應(yīng)用層隱藏了檢查-生成-存儲這個過程；

......

亮點太多，列不完了，需要大家自己去尋找。另外，這本書不適宜一次性的精讀完畢（太厚，內(nèi)容太多），可以快速瀏覽一遍，大概了解，以后遇上問題就可以把這本書當(dāng)作一本問題解答手冊來查詢解決方案，或者找找靈感。

Redis實戰(zhàn) (豆瓣) https://book.douban.com/subje...

本書對redis的介紹是相當(dāng)全面了，從基本用法講起，然后講了許多應(yīng)用場景，包括購物車、數(shù)據(jù)庫緩存等，然后講了一些常見問題的解決辦法，比如內(nèi)存占用過高，自定義擴(kuò)展來豐富redis的用法等等，看完一本書過后就能很好的使用redis了（還有本好書：redis設(shè)計與實現(xiàn)，我大致瀏覽了一下，這本書主要講了redis的實現(xiàn)原理，這兩本書加起來就能既懂原理又會使用，把redis搞個透徹）。

本書亮點：

使用冒號 : 或者管道號 | 等來實現(xiàn)命名空間的作用，比如一個名為 article:12222 的hash存了這篇article的title，link，time等屬性，article:12223又是另一篇文章，這個可以部分實現(xiàn)數(shù)據(jù)庫檢索的功能。

為了減少redis與客戶端之間的通信次數(shù)，可以用multi和exec來做事務(wù)處理，事務(wù)會一次性的把一批命令一次發(fā)給redis，提高吞吐率；另外事務(wù)還能保證一批操作的原子性。在node-redis實現(xiàn)中，如果只是想提高吞吐率則可以用batch替代multi。

通過復(fù)制（主從）和AOF能夠增強(qiáng)redis抵抗系統(tǒng)崩潰損失數(shù)據(jù)的能力，AOF如果用得不好的話，要么損失很多數(shù)據(jù)，要么嚴(yán)重降低吞吐量，比較合適的做法是appendfsync everysec 亦即把每一秒的命令一次同步進(jìn)文件。

使用 redis 的 setnx 來實現(xiàn)基本上正確的的分布式鎖，再加上expire可以實現(xiàn)具有超時功能的鎖，保證即使獲得鎖的客戶端崩潰沒有主動釋放鎖時，其他進(jìn)程也有機(jī)會獲得鎖。

用 list 來替代 subscribe、publish 實現(xiàn)更可靠的發(fā)布訂閱系統(tǒng)；另外，利用subscribe、publish加list來實現(xiàn)具有離線緩存的消息隊列系統(tǒng)，保證即使發(fā)生連接故障也能把消息送達(dá)。

利用反向索引以及 redis 集合的并、交、差功能可以實現(xiàn)簡易的搜索引擎，利用 hash 結(jié)構(gòu)的 sort 功能還能對搜索結(jié)果進(jìn)行簡易的排序功能，利用有序集合 zset 能實現(xiàn)更高級的排序功能。

社交網(wǎng)站通常是用時間線這一數(shù)據(jù)結(jié)構(gòu)來實現(xiàn)新鮮事瀏覽這一功能，雖然導(dǎo)致了大量的冗余信息，但是能夠節(jié)省查詢時間，這是典型的以空間換時間的操作，我以前做社交APP后臺的時候直接把所有新鮮事直接放在一張表中，然后按用戶id查詢，這樣雖然省了空間，但是如果用戶劇增（(⊙﹏⊙)b，我們的APP并沒有用戶劇增）就不行了，一張表幾億行還怎么查。

使用短結(jié)構(gòu)來節(jié)約內(nèi)存，使用較短的鍵名節(jié)約內(nèi)存，分片降低單實例的內(nèi)存占用。

使用lua腳本，在不編寫C代碼的情況下，為redis添加新的功能。

時效性問題，本書沒有一些最新特性 比如 geohash 解決了地理坐標(biāo)問題，鍵的異步釋放使得我們可以放心刪除而不必?fù)?dān)心大量數(shù)據(jù)的刪除使得redis短暫不可用?？傊玫睦胷edis還是要追蹤redis的最新變化，以便更簡潔、更靠譜的解決問題。

深入剖析Nginx (豆瓣) https://book.douban.com/subje...

本書從源碼入手，依次講解了進(jìn)程模型、模塊、響應(yīng)處理機(jī)制、過濾、負(fù)載均衡等相關(guān)原理，極大的滿足了我的好奇心，因為之前一直就對nginx高并發(fā)處理能力有一丟丟了解（比如nginx采用事件驅(qū)動機(jī)制而非apache的進(jìn)程、線程每請求方式），自己也用過nginx，但是對他的原理還不是特別的明白，本書算是填補(bǔ)了我的這個空白。

本書亮點：

Nginx 將職責(zé)分為監(jiān)控進(jìn)程（主進(jìn)程）和工作進(jìn)程（主進(jìn)程fork的子進(jìn)程），監(jiān)控進(jìn)程與用戶交互并對工作進(jìn)程進(jìn)行監(jiān)控管理，工作進(jìn)程完成具體業(yè)務(wù)邏輯，兩者都有一個無限的for循環(huán)，這是服務(wù)進(jìn)程的基本寫法。

Nginx僅提供針對大塊內(nèi)存的回收不提供小塊內(nèi)存的回收，這是因為web server的特殊性亦即階段和時效，請求就申請內(nèi)存，處理完畢就釋放內(nèi)存，所以不會存在nginx長時間占據(jù)大量無用內(nèi)存的情況，那么小內(nèi)存也自然不必急于回收，而是成為大內(nèi)存后在回收。

對于客戶端的請求，nginx將整個過程分為11個階段，每個階段有數(shù)個回調(diào)函數(shù)進(jìn)行專門的處理，每個階段的處理功能都比較單一，達(dá)到高內(nèi)聚低耦合的目的。

Nginx是以事件為驅(qū)動的，也就是說Nginx內(nèi)部流程的向前推進(jìn)基本都是靠各種事件的觸發(fā)來驅(qū)動，內(nèi)部事件主要有兩類：IO事件與定時器事件。其中IO事件主要靠epoll,epoll主要優(yōu)點是監(jiān)控數(shù)目不受文件描述符限制、事件響應(yīng)是觸發(fā)式的，不需要遍歷描述符（select需要）。

Nginx要處理動態(tài)的內(nèi)容一般需要轉(zhuǎn)發(fā)給后端服務(wù)器，常見的搭配是nginx+fastcgi+php，nginx把http請求轉(zhuǎn)化為fastcgi協(xié)議的數(shù)據(jù)后轉(zhuǎn)發(fā)給PHP引擎，PHP引擎處理結(jié)果后把數(shù)據(jù)返回給nginx，nginx把數(shù)據(jù)轉(zhuǎn)化為http格式返回給客戶端。

負(fù)載均衡有多重含義（或者說多重級別），可以是進(jìn)程上的（根據(jù)master進(jìn)程根據(jù)子進(jìn)程壓力調(diào)整其獲取監(jiān)聽套接口的幾率），更廣的意義上是指反向代理上，亦即nginx把請求均衡的轉(zhuǎn)發(fā)給后端服務(wù)器如PHP引擎，發(fā)揮多個單元的整體效能。一般采取加權(quán)輪詢、IP hash等策略，但是只靠nginx是不能實現(xiàn)完整的負(fù)載均衡的，詳見我以前寫的一篇文章。

這本書主要從應(yīng)用及其原理方面來介紹nginx，對于后端程序員應(yīng)該是夠用了（我也忽略了許多源碼，因為只是想了解一下原理）。但是對于要想自己深入、進(jìn)行模塊編寫的讀者應(yīng)該還不夠用，可以再參考一下這本書 深入理解Nginx（第2版）（我大概瀏覽了一下，本書會指導(dǎo)讀者編寫具體的模塊及其底層原理，比我們今天介紹的書更深入一些）。

第一本Docker書 修訂版 (豆瓣) https://book.douban.com/subje...

書如其名，這就是真正的第一本docker書。docker是什么、怎么安裝、如何使用、測試集成、構(gòu)建服務(wù)等都有介紹。之前就久仰docker大名，也試著試用了一下，但是直到這本書讀完我才對docker有了一個完整的認(rèn)知。另外，不出意料，本書的推薦序也很精彩。

本書亮點：

docker的核心價值在于可能改變軟件的交付方式和運行方式。傳統(tǒng)的交付方式下，軟件運行期依賴的環(huán)境是無法控制，不能標(biāo)準(zhǔn)化的，開發(fā)人員常常需要解決開發(fā)環(huán)境和生產(chǎn)環(huán)境的差別帶來的問題，而docker則把軟件及其依賴環(huán)境打包在一起，以鏡像形式交付，讓軟件運行在標(biāo)準(zhǔn)環(huán)境中，非常符合云計算的需求，同時docker的輕量虛擬化技術(shù)也符合實例水平擴(kuò)展，資源動態(tài)調(diào)整的要求。

docker提供以下幾個好處：簡單輕量的建模方式，工程容易docker化，隨時修改代碼，運行快速；職責(zé)分離，開發(fā)人員只管開發(fā)，運維人員只管容器管理，減少環(huán)境不同帶來的問題；快速高效的開發(fā)生命周期，程序容易部署、移植和協(xié)作；容易實現(xiàn)面向服務(wù)的架構(gòu)和微服務(wù)架構(gòu)。

docker只支持64位架構(gòu)，原生的Linux容器格式：libcontainer，使用命名空間來隔離文件系統(tǒng)（每個容器都有自己的root系統(tǒng)）、進(jìn)程（每個容器都運行在自己的進(jìn)程環(huán)境中）和網(wǎng)絡(luò)（容器間虛擬網(wǎng)絡(luò)地址和IP地址都是分開的），使用cgroups將CPU內(nèi)存之類的資源獨立分配給容器，寫時復(fù)制使得文件系統(tǒng)分層隔離、速度更快、占用空間更小，還提供日志和交互式shell。

鏡像分層：新鏡像是從 base 鏡像一層一層疊加生成的，文件系統(tǒng)發(fā)生變化時，就在現(xiàn)有鏡像的基礎(chǔ)上增加一層，這一層叫做“容器層”（讀寫層），“容器層”之下的都叫“鏡像層”（只讀層），只有當(dāng)需要修改時才從鏡像層復(fù)制一份數(shù)據(jù)到容器層，這種特性被稱作寫時復(fù)制（Copy-on-Write），達(dá)到了鏡像共享，快速構(gòu)建的目的。

可以使用docker commit來構(gòu)建鏡像，也可以基于dockerfile和docker build命令構(gòu)建，通常建議使用后者，因為dockerfile更具備透明性（可以清晰地看出安裝了什么軟件，修改了什么配置）、可重復(fù)性（一次編寫，多次使用。此外構(gòu)建緩存還可以制作構(gòu)建模板）、冪等性（同一個dockerfile不論執(zhí)行多少次，結(jié)果都是相同的）。

docker容器之間通訊有3種方式，1.9之前推薦用Docker Link（安全：只有l(wèi)ink之前的容器可以通信，不必硬編碼，不支持多主機(jī)），1.9之后推薦Docker Networking（支持多主機(jī)容器連接，可以熱更新容器，Networking網(wǎng)絡(luò)內(nèi)部容器可以自主發(fā)現(xiàn)），不太推薦docker內(nèi)部網(wǎng)絡(luò)（IP硬編碼等導(dǎo)致該方法不夠靈活）。

volume（卷）具有一些有用的特性：容器之間共享數(shù)據(jù)，對卷的修改會直接反映在包含改卷的容器里所以可以在不修改容器的情況下向容器里加入、更新、刪除數(shù)據(jù)，更新鏡像時不會影響卷。利用這些特性可以更好的進(jìn)行數(shù)據(jù)共享與持久化。

docker編排與集群化之路：Docker Compose 是用來做 docker 的多容器控制，使用Compose ，你可以在一個文件中定義多個容器應(yīng)用，然后使用一條命令來啟動你的所有應(yīng)用，避免繁復(fù)操作，docker 自動化構(gòu)建容器棧；Consul提供了一個易于使用，基于開放標(biāo)準(zhǔn)的服務(wù)發(fā)現(xiàn)解決方案，服務(wù)發(fā)現(xiàn)允許某個組件在想與其他組件通訊時自動找到對方；Docker Swarm是一個用于創(chuàng)建Docker主機(jī)（運行Docker守護(hù)進(jìn)程的服務(wù)器）集群的工具，使用Swarm操作集群，會使用戶感覺就像是在一臺主機(jī)上進(jìn)行操作亦即將容器抽象到集群級別。還有其他很多工具如：fleet、etcd、Kubernetes、Apache Mesos、Helios、Centurion。

時效性原因，書中一些例子已經(jīng)過時（如Docker1.12開始內(nèi)置編排機(jī)制，Docker1.13正式支持docker stack），需要結(jié)合最新版本來使用。
另外，想要深入理解docker可以閱讀這本書 Docker——容器與容器云。我大致瀏覽了下，這本書不僅講了docker如何使用，還深入講解了docker的核心原理如namespace資源隔離、cgroups資源限制、libcontainer原理和一些高級實踐技巧。此外，還講了對容器、容器云的思考，包括如何構(gòu)建自己的容器云，以及Kubernetes實現(xiàn)一切皆容器的“大同理想”。

UNIX/Linux 系統(tǒng)管理技術(shù)手冊 (豆瓣) https://book.douban.com/subje...

又是一本進(jìn)千頁的大部頭，但是不怕，這本書如其名，是一本手冊性質(zhì)的書，非常大而全，包括基本管理技術(shù)、網(wǎng)絡(luò)管理技術(shù)和其他補(bǔ)充管理技術(shù)，幾乎包攬了所有我們可能用到的功能（小到一行代碼整么寫，大到數(shù)據(jù)中心怎么建），對于宏觀把握整個Linux生態(tài)系統(tǒng)有很大作用。我的應(yīng)對策略是跳躍式閱讀（不錯，就像上面那本MySQL），留下整體映像，等遇上問題時再來具體的查詢相關(guān)部分的內(nèi)容。也就是說，大腦相當(dāng)于內(nèi)存，書本相當(dāng)于硬盤數(shù)據(jù)庫，我們首次閱讀就是在內(nèi)存中建立索引，便于提升以后的查找速度:-D。

本書亮點：

Linux各個發(fā)行版其實并沒有那么巨大的差別，我們選擇一個發(fā)行版時主要考慮幾點：是否能長期存在，是否會有持續(xù)的安全補(bǔ)丁，是否會持續(xù)更新軟件，發(fā)行商是否會在出了問題時幫我們解決，不同發(fā)行版?zhèn)戎攸c會有所不同我們要根據(jù)自己的業(yè)務(wù)來進(jìn)行選擇。

編寫腳本時注意形成一種指導(dǎo)風(fēng)格，這樣你和你的團(tuán)隊成員可以按照相同的規(guī)范來書寫代碼，有了這種指導(dǎo)在閱讀別人寫的代碼或者別人閱讀你的代碼時都會更容易；注釋不要多也不要少，最好的效果是一兩個月后再來讀代碼發(fā)現(xiàn)注釋和有用。

一個進(jìn)程由一個地址空間（一組內(nèi)存頁面）和內(nèi)核一部分?jǐn)?shù)據(jù)（有關(guān)進(jìn)程的信息如地址空間映射、狀態(tài)、優(yōu)先級、資源）組成；一個線程是在進(jìn)程內(nèi)執(zhí)行fork的結(jié)果，繼承了包含它的進(jìn)程的許多屬性，多個線程可以共享該進(jìn)程內(nèi)數(shù)據(jù)，并行（多核）或并發(fā)（單核，模擬并行）執(zhí)行

Unix家族的文件系統(tǒng)目前沒有一個標(biāo)準(zhǔn)，我們盡量按照如下標(biāo)準(zhǔn)來組織。bin：核心操作系統(tǒng)命令；sbin：系統(tǒng)最小規(guī)模運行所需命令；boot：內(nèi)核及加載內(nèi)核所需軟件；etc：關(guān)鍵啟動文件及配置文件；usr：次要的命令文件；var:隨主機(jī)變化的文件如日志，數(shù)據(jù)文件；mnt：可移動介質(zhì)臨時掛載點；opt：可選的應(yīng)用軟件包；proc：正在運行的進(jìn)程信息；tmp：臨時文件；

合適的備份計劃取決于：文件系統(tǒng)的活躍性，轉(zhuǎn)儲設(shè)備的容量，用戶期望的冗余度，想要購買的備份介質(zhì)數(shù)量。

版本控制與多人合作：svn是集中式的，一臺中央服務(wù)器充當(dāng)了一個項目的權(quán)威庫；git是分布式的，沒有中央庫，每個用戶都含有一個完整的項目，采用的是拷貝-分支策略。

信息安全領(lǐng)域的基本思想——CIA原則：Confidentiality（機(jī)密性），Integrity（完整性），Availability（可用性）。在設(shè)計、實現(xiàn)或者維護(hù)系統(tǒng)的時候，需要考慮CIA安全三原則，正如老話所說“安全性是一個過程”。

負(fù)載均衡既提高了性能又增加了冗余性，包括幾種方式：循環(huán)域名服務(wù)（也就是DNS輪詢）、負(fù)載均衡硬件（比如Big-IP Controller、Content Services Switches等）、軟件負(fù)載均衡（比如Nginx）。

Squid既是一個高速緩存軟件也是一個代理服務(wù)程序，代理服務(wù)很有用，但是Squid真正厲害之處是其高速緩存，它甚至能夠形成一個緩存層次結(jié)構(gòu)，以最大化提高緩存命中率。Squid是有意義的，因為用戶對web的探索具有趨同性，所以在適度的規(guī)模上會出現(xiàn)相當(dāng)多重復(fù)請求，運行高速緩存可以節(jié)省帶寬和計算資源。

虛擬化技術(shù)讓多個彼此獨立的操作系統(tǒng)同時運行在相同的物理硬件上，系統(tǒng)管理員把每個虛擬機(jī)當(dāng)做一臺獨立的服務(wù)器，既滿足了軟件廠商的要求，又降低了單一服務(wù)的成本。包括全虛擬化（如VMwareESX）、半虛擬化（Xen）、操作系統(tǒng)級別虛擬化（如workload partition）。除了傳統(tǒng)的虛擬化技術(shù)，近年來的云計算也是一種（或者說類）虛擬化技術(shù)，它把計算能力作為對外提供的服務(wù)類似于水電等基礎(chǔ)設(shè)施，直接使得硬件層對開發(fā)人員和系統(tǒng)管理員透明，提高了效率。

分析性能問題步驟：明確表述問題、收集證據(jù)并分類、批判性的評價數(shù)據(jù)、用語言和圖示總結(jié)證據(jù)、形成一份總結(jié)說明。這一套其實不止適用于性能分析問題，也適用于大多數(shù)其他問題，比如架構(gòu)、重構(gòu)、debug等等。

系統(tǒng)管理不是一種行為藝術(shù)。無論做的什么，都應(yīng)該能重復(fù)完成，切前后一致。通常意味著最底層的變化應(yīng)該有腳本或者配置程序來做，而不是管理員來做。配置上的變化應(yīng)該體現(xiàn)在系統(tǒng)管理軟件的配置文件里。說白了，就是文檔的重要性，在我看來：首先文檔就是一家公司的財富，沒有文檔，人走了，那么之前公司的積累也就沒了，又得重頭來，損失很大；其次，文檔是一種保證，大家都按約定辦事，保證操作可重復(fù)，避免歧義與甩鍋；再其次，文檔能節(jié)約時間，雖然寫的時候可能費點事，但是能節(jié)省后面大量的人員溝通的時間；最后，文檔保證了系統(tǒng)的完整性，亦即文檔保證了系統(tǒng)的后續(xù)修改遵循一致的思路和風(fēng)格，才不至于系統(tǒng)隨著時間流逝而越來越亂，難以維護(hù)與使用。

本書教會了我們怎么使用Linux，這對于我們后端開發(fā)人員是足夠受用了。而這本書Linux內(nèi)核設(shè)計與實現(xiàn)(原書第3版)就會告訴我們Linux是如何實現(xiàn)它這么多這么強(qiáng)大的功能的內(nèi)在原理，精力有限，我只是瀏覽了一下沒有細(xì)讀，等以后真的用得上Linux的深入知識時，或者遇上了什么解決不了的問題，我會再來求助于這本書的。

代碼整潔之道 (豆瓣) https://book.douban.com/subje...

本書提出一個觀點就是：代碼質(zhì)量與整潔度成正比，圍繞提高整潔度，作者展開了方方面面的闡述，從命名的方法到函數(shù)的定義，從注釋的使用到格式的目的，還介紹了對象，錯誤處理等等等等?？赐旰蟮母杏X就是：寫好代碼，從本書開始。雖然我現(xiàn)在寫的代碼還比較“亂”，但是今后的代碼中會努力踐行書中的原則，爭取寫出整潔的代碼。

本書亮點：

軟件質(zhì)量既依賴于架構(gòu)和項目管理，又與代碼質(zhì)量緊密相關(guān)，而代碼質(zhì)量與整潔度成正比，所以我們要致力于寫出干凈整潔的代碼。并且不僅要知道書寫整潔代碼的原則，還有查看大量代碼實例，進(jìn)行案例研究，在實踐中貫徹這些原則，才能真正做到知行合一。

不同的人對整潔代碼有不同的理解，總歸起來，有如下一些特點：代碼邏輯直截了當(dāng)，依賴關(guān)系很少，性能最優(yōu)，每個函數(shù)模塊類專注于一件事，可以輕易的被其他人閱讀，具有完整的測試，作者自己要在乎自己的代碼悉心維護(hù)，沒有重復(fù)代碼提前構(gòu)建重復(fù)代碼應(yīng)有的抽象，體現(xiàn)系統(tǒng)的所有設(shè)計理念，包含盡量少的實體。

命名看似簡單卻無處不在，所以我們不妨命好名，幾個原則：名副其實，不用注釋也能明白這個變量代表什么；避免誤導(dǎo)，不要用保留詞或太相同的詞引起歧義；做有意義的區(qū)分，不要添加在名字后數(shù)字或者廢話而是以讀者能鑒別不同之處的方式來區(qū)分；名字要讀的出來，便于交流；名稱要便于搜索；一個概念統(tǒng)一用一個詞，比如不要混用manager和Controller；避免雙關(guān)詞；給名詞添加語境，但是避免冗余的語境，含義明確的情況下，短名字總是比長名字好呀......

函數(shù)構(gòu)成了當(dāng)今程序的基石，函數(shù)要寫的明白要遵循如下原則：短小；只做一件事，也就是函數(shù)中的語句要在同一個抽象層級上，不在同一個抽象層級就得拆出來形成一個新的函數(shù)；把switch埋藏在較低的抽象層級，比如抽象工廠中，雖然依然免不了判斷或者條件增多時要增添代碼，但是能夠把變化截留在工廠內(nèi)，減少影響范圍；不要向函數(shù)傳入標(biāo)志參數(shù)，比如TRUE/FALSE，而是應(yīng)該直接把這個函數(shù)重構(gòu)成兩個函數(shù)；一個函數(shù)要么下達(dá)什么指令（set）要么回答什么問題（get），不要添加副作用；DRY（別重復(fù)自己）。

注釋是一種必須的惡，如果代碼寫的好根本不需要注釋（感覺有點過了，至少一個大的模塊用來干啥還是因該用注釋或者說文檔直接來說明），而且代碼才是真實的地方，注釋很可能沒有被維護(hù)而導(dǎo)致失效；別給糟糕的代碼加注釋，重寫吧；版本控制系統(tǒng)可以幫我們省掉許多注釋如作者署名，注釋掉的代碼。

或許你認(rèn)為“讓代碼工作”是開發(fā)者的頭等大事，但是其實并不是這樣的，代碼風(fēng)格關(guān)系著溝通，而溝通才是頭等大事。代碼風(fēng)格影響著可維護(hù)性和擴(kuò)展性，即使代碼已不復(fù)存在，其風(fēng)格和律條依然存在,因而一個團(tuán)隊?wèi)?yīng)該形成一個統(tǒng)一的風(fēng)格，便于溝通與維護(hù)。

隱藏實現(xiàn)并非就是簡單的在變量之間放一個函數(shù)層。隱藏關(guān)乎抽象，類并不是簡單的用取值器和賦值器將變量向外推，而是暴露抽象接口，以便用戶無需了解數(shù)據(jù)的具體實現(xiàn)就能操作數(shù)據(jù)本身。對象暴露行為，隱藏數(shù)據(jù)；數(shù)據(jù)結(jié)構(gòu)暴露數(shù)據(jù)，沒有明顯的行為。要合理的利用二者。

錯誤處理一旦處理不好就容易污染整潔的代碼：使用異常來保證錯誤處理不會打亂正常的程序邏輯；可檢異?？赡軙茐拈_閉原則，要謹(jǐn)慎使用；打包第三方API就降低了對它的依賴；不要返回null值，只是突然增加了工作量，可以用異常或者特例對象來代替。

測試非常重要：測試代碼和生產(chǎn)代碼一樣重要，臟測試就等于沒測試；有了測試就可以毫無顧慮的進(jìn)行重構(gòu)和改善，因為有保證，消除了清理代碼就會破壞代碼的恐懼（這句話可謂是戳中了我，我之前的項目也有過一些重構(gòu)的努力，但是就是怕重構(gòu)過后不能正常運行，導(dǎo)致重構(gòu)舉步維艱）；測試代碼要清晰，符合構(gòu)造-操作-檢驗三個環(huán)節(jié)；單個測試中的斷言應(yīng)該最小化，保證一個測試對應(yīng)一個概念；整潔的測試遵循 ＦＩＲＳＴ 原則（fast，independent，repeatable，self-validing，timely）。

系統(tǒng)層級的整潔：城市能有效運轉(zhuǎn)是因為演化出了恰當(dāng)?shù)某橄髮蛹壓湍K，有人負(fù)責(zé)全局有人負(fù)責(zé)細(xì)節(jié)，所以軟件系統(tǒng)也有架構(gòu)師和項目經(jīng)理等；將構(gòu)造和使用分開（依賴注入，控制反轉(zhuǎn)）；擴(kuò)容（要考慮可擴(kuò)展性，但是注重現(xiàn)有的系統(tǒng)的構(gòu)造，將來再重構(gòu)和添加，沒必要Big Design Up Front，考慮好模塊化和關(guān)注切面劃分就好）。

KISS（Keep It Simple, Stupid），簡單設(shè)計原則：運行所有測試（測試是對一個系統(tǒng)的保證）；不要重復(fù)（重復(fù)意味著額外的工作、風(fēng)險、復(fù)雜度）；表達(dá)了程序員的意圖（清晰可讀）；盡可能少的類和方法數(shù)量（避免教條如：每個類都要有接口）。

編程是一種技藝甚于科學(xué)的東西，不要指望一開始就寫出優(yōu)雅整潔的代碼，一般是先寫出骯臟的代碼，然后進(jìn)行重構(gòu)，清理。所以代碼僅僅能工作還不夠，滿足于代碼能工作的程序員不夠?qū)I(yè)，他們害怕沒時間進(jìn)行代碼結(jié)構(gòu)的重新設(shè)計，其實沒有什么比糟糕的代碼給項目帶來更長遠(yuǎn)的損害了，糟糕的代碼會一直腐敗發(fā)酵，影響各個模塊（找出這些依賴和影響相當(dāng)不容易）無情的腐蝕整個項目和團(tuán)隊。

......

這本書里面的良心建議實在是太多了，無法一一列舉，真的得自己看一遍才能有收獲。

重構(gòu) (豆瓣) https://book.douban.com/subje...

上一本書教會我們怎樣書寫整潔的代碼，那么面對不整潔的代碼，我們怎么辦呢？這本書就手把手教我們怎么重構(gòu)，改善現(xiàn)有的代碼。從一個實例入手，講了重構(gòu)的理由、原則、技巧、步驟與時機(jī)。我讀完過后感覺心里就有了些烙印，無論是寫代碼還是改代碼，基本都會不自主的向這本書靠攏，很有收獲。

本書亮點：

重構(gòu)是在不改變代碼外在行為的前提下對代碼作出修改，以改進(jìn)程序的內(nèi)部結(jié)構(gòu)，本質(zhì)上說重構(gòu)就是在代碼寫好后改進(jìn)其設(shè)計，提高其可理解性，降低修改成本；記住所有代碼的“壞味道”及其對應(yīng)的重構(gòu)手法，才能有信心面對各種情況——學(xué)會所有招式才可能“無招勝有招”；為了避免自掘墳?zāi)?，重?gòu)必須系統(tǒng)化進(jìn)行，用一些經(jīng)過檢驗的重構(gòu)手法，就可以一次一小步的修改代碼，所以任何錯誤都可以比較容易的發(fā)現(xiàn)，降低了重構(gòu)過程中的風(fēng)險。

如果你發(fā)現(xiàn)自己需要為程序添加一個特性，而現(xiàn)有的代碼結(jié)構(gòu)使你無法方便的添加，那就先重構(gòu)程序，使得特性添加變得容易，然后再添加這個特性。而重構(gòu)的第一步就是建立一組可靠的測試，來盡量避免bug，保證重構(gòu)的正確性。

對象A最好不要在另外一個對象B的屬性基礎(chǔ)上使用switch語句，因為將來B變了A也必須變，如果不得不使用switch也要在自己的屬性上使用，也就是把switch移動至B里面去；最好是用多態(tài)替換switch語句（其實也不是替換，而是把switch放在了較低的抽象層級，使得可能變化的部分就在一個對象里面，將其與不變的部分隔離開）。

添加新功能和重構(gòu)是兩種行為，一定要加以區(qū)分，并且同一時刻只做好一件事就行。

任何能夠查詢的東西，我都不太愿意去記，因為怕把大腦擠爆了。所以說大腦這個珍貴而有限的內(nèi)存主要做的事一定是建好索引，而非存儲數(shù)據(jù)；另一方面，常用的數(shù)據(jù)也應(yīng)該存進(jìn)大腦，以提高效率，這和內(nèi)存中的緩存是一個道理。

不要為了重構(gòu)而重構(gòu)，一定是因為你想做某件事時重構(gòu)恰好可以幫你做好，重構(gòu)的幾個時機(jī)：添加新特性時，修補(bǔ)錯誤時，復(fù)審代碼時。

程序有兩面價值“今天可以為你做什么”和“明天可以為你做什么”，如果只關(guān)注今天的工作，那么明天我們將無法工作，所以需要重構(gòu)，來避免代碼出現(xiàn)以下四個情況：難以閱讀，重復(fù)太多，新行為無法簡單添加，邏輯復(fù)雜。這四個情況導(dǎo)致的結(jié)果都是程序難以改變（修改），而唯一不變的就是改變:-D

代碼的壞味道——重構(gòu)的時機(jī)：重復(fù)代碼、過長函數(shù)、過大的類、過長的參數(shù)列、發(fā)散式變化、霰彈式修改、依戀情結(jié)、數(shù)據(jù)泥團(tuán)、基本類型偏執(zhí)、switch語句、平行繼承體系、冗贅類、夸夸其談未來性、臨時字段、過渡耦合的消息鏈、中間人、不適合的親昵關(guān)系、異曲同工的類......

本書給出了一份重構(gòu)列表，包含了很多很多的重構(gòu)類型的名稱、動機(jī)、方法、范例，涵蓋了函數(shù)、對象、數(shù)據(jù)、表達(dá)式、調(diào)用、概括關(guān)系、大型項目等方方面面，值得我們借鑒，下面摘抄幾條作為示例。

當(dāng)我看見一個過長的函數(shù)或者一段需要注釋才能讓人理解用途的代碼就會把這段代碼放進(jìn)一個獨立的函數(shù)中。短函數(shù)的好處：更可能被復(fù)用，讓高層函數(shù)看起來更清晰易懂，復(fù)寫更容易?！岸獭钡暮x不在代碼行數(shù)，而在于函數(shù)名稱和函數(shù)本體之間的語義距離。

如果一個類的某個方法、字段被另一個類頻繁使用，就應(yīng)該搬移該方法、字段。

混亂的繼承體系是一個嚴(yán)重的問題，因為它會導(dǎo)致重復(fù)的代碼，這正是程序員職業(yè)生涯的致命毒藥。它還會使修改變得困難，因為特定問題的解決策略被分散到了整個繼承體系，最終你的代碼難以理解。所以可以通過建立多個繼承體系，并利用委托來互相調(diào)用，使得原來負(fù)責(zé)多個任務(wù)的繼承體系變成多個負(fù)責(zé)單個任務(wù)的繼承體系。

......

感覺本書最大的問題就是太老了（1999年），有些工具或者方法在如今技術(shù)進(jìn)步的情況下顯得有些多余，比如現(xiàn)在的IDE如Eclipse或者IDEA都有很強(qiáng)大的功能，書里提到的一些技巧完全用不著。不過經(jīng)典終究是經(jīng)典，里面的絕大部分思想我們?nèi)缃穸歼€是可以借鑒的，尤其是對于重復(fù)代碼的觀點——應(yīng)該堅決消滅重復(fù)。

花費了幾個月來看書，又花了幾天來整理，希望對我們都有所幫助:-D。歡迎拍磚，我的主頁Mageek`s Wonderland。
查看原文