深入淺出雲計算 （簡體書）

《深入淺出云計算》理論聯系實踐，既有理論深度又有實用價值，可作為高校教材使用，也可作為云計算研發人員以及愛好者的學習和參考手冊。

第1篇初始云計算
第1章云計算介紹
1.1 云計算相關概念
1.1.1云計算的定義
1.1.2云計算的服務方式
1.1.3云計算的部署模式
1.2云計算的歷史
1.2.1虛擬化技術的發展
1.2.2分布式計算技術的發展
1.2.3軟件應用模式的發展
1.3云計算的現狀
1.3.1產業界現狀
1.3.2學術界現狀
1.3.3政府機構現狀
1.4本章小結
第2章 云計算技術基礎
2.1 HDFS相關技術
2.1.1 RPC
2.1.2基于Socket的Java網絡編程
2.2 MapReduce相關技術
2.2.1 Java反射機制
2.2.2序列化和反序列化
2.3 HBase相關技術
2.3.1 NoSQL
2.3.2 ACID
2.3.3 CAP理論
2.3.4一致性模型
2.4 ZooKeeper相關技術
2.4.1 Paxos算法介紹
2.4.2 Java NIO庫
2.5本章小結
第3章 云計算開發環境搭建
3.1集群環境介紹
3.2 Hadoop環境搭建
3.2.1 Hadoop簡介
3.2.2安裝前準備
3.2.3安裝環境搭建
3.2.4詳細安裝步驟
3.3 Hadoop集群配置
3.3.1 配置Hadoop守護進程的運行環境
3.3.2配置Hadoop守護進程的運行參數
3.4 HBase環境搭建
3.4.1 HBase簡介
3.4.2 HBase的數據模型
3.4.3 HBase安裝前的準備
3.4.4 HBase的安裝配置
3.4.5 HBase的運行
3.5 ZooKeeper環境搭建
3.5.1 ZooKeeper簡介
3.5.2安裝前的準備
3.5.3獨立服務器的安裝與配置
3.5.4集群服務器的安裝與配置
3.6本章小結
第2篇淺出云計算
第4章 應用實例：圖像百科系統
4.1 應用背景
4.2需求分析
4.2.1功能需求
4.2.2非功能需求
4.3核心業務處理流程
4.3.1查詢百科條目處理流程
4.3.2編輯百科條目處理流程
4.3.3更新百科條目處理流程
4.4總體設計
4.5 本章小結
第5章 使用HDFS存儲海量圖像數據
5.1 HDFS介紹
5.1.1 HDFS架構
5.1.2 HDFS的特點
5.1.3 HDFS存取機制簡介
5.2 HDFS接口介紹
5.3 圖像百科系統中的圖像存儲
5.3.1 圖像存儲基本思想
5.3.2圖像存儲設計目標
5.3.3圖像存儲體系結構
5.3.4圖像百科系統的功能結構
5.4系統實現
5.4.1存儲模塊類交互圖
5.4.2核心類詳細介紹
5.4.3 HDFS存儲小文件
5.5 本章小結
第6章 使用MapReduce處理圖像
6.1分布式數據處理MapReduce
6.1.1 MapReduce簡介
6.1.2編程模型
6.1.3執行概括
6.2使用MapReduce編程模型
6.2.1 MapReduce程序模板
6.2.2 MapReduce編程思想
6.3 更新圖像百科條目的MapReduce設計
6.3.1 設計目標
6.3.2更新條目的體系結構
6.3.3更新條目的邏輯流程
6.4 MapReduce對更新條目的實現
6.4.1更新條目的核心類
6.4.2 MapReduce核心類實現
6.4.3編譯運行
6.5本章小結
……
第7章使用HBase存儲百科數據
第8章使用ZooKeeper管理集群
第3篇深入云計算
第10章深入分析MapReduce
第11章深入分析HBase
第12章深入分析ZooKeeper
第4篇應用云計算
第13章應用Pig實現并行數據處理
第14章應用Hive構建數據處理平臺
第15章應用Mahout實現機器學習算法
第16章應用HAMA實現分布式計算
附錄

原子性：整個事務中的所有操作，要么全部完成，要么全部不完成，不可能停滯在中間某個環節。事務在執行過程中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務從來沒有執行過一樣。
一致性：在事務開始之前和事務結束以后，數據庫的完整性約束沒有被破壞。隔離性：兩個事務的執行是互不干擾的，一個事務不可能看到其他事務運行時中間某一時刻的數據。兩個事務不會發生交互。
持久性：在事務完成以后，該事務對數據庫所做的更改被持久地保存在數據庫之中，并不會被回滾。
某一數據在集群中不同節點中的內容一致。
可用性（Availability）：每一個操作無論是請求失敗或成功，總是能夠在確定的時間內得到響應。
分區容忍性（Partition Tolerance）：在出現網絡分區（如斷網）等情況時，系統中任意信息的丟失不會影響系統的繼續運行（除非整個網絡都故障）。
這個定理使得數據庫架構師在設計數據庫系統時，無須再去費盡心機地嘗試使系統同時滿足一致性、可用性和分區容忍性這三種需求，而可以集中精力按照系統的需求，設計合適的系統架構來滿足這三者中的兩個。
一般而言，傳統的關系數據庫大都是滿足CA的，放棄了分區容忍性來滿足強一致性和高可用性的需求。而對于分布式系統而言，系統數據分布在不同的網絡節點中，因此大多數情況下需要滿足分區容忍性來降低單點失效等問題的風險，因此一般只有CP和AP兩種選擇。
AP模式：確保系統可用性和分區容忍性，弱化了數據一致性要求，一般以“最終一致性（Eventual Consistency）”來實現一致性需求。典型的系統如Dynamo、Tokyo Cabinet、Cassandra、CouchDB、SimpleDB等。
CP模式：確保分布在網絡不同節點上數據的一致性，因此降低了對可用性的要求。
這種系統如BigTable、HBase、MongoDB、Redis、MemcacheDB、BerkeleyDB等。
2.3.4一致性模型
在CAP理論中，提出了分布式系統設計中對一致性的取舍。事實上，設計分布式系統時降低一致性要求，并不是說完全不考慮…致性，而是相對于強一致性而言，采取一定的折中方式，系統一般還是需要滿足最終一致性的。常用的一致性模型如下。
（1）強一致性（Strict Consistency）：系統中某個數據被成功更新（事務成功返回）后，后續任何對該數據的讀取操作得到的都是更新后的值。
（2）弱一致性（Weak Consistency）：系統中的某個數據被更新后，后續對該數據的讀取操作得到的不一定是更新后的值，這種情況下通常有個“不一致性時間窗口（InconsistencyWindow）”存在，當更新操作完成并經過這個不一致性時間窗口后，后續讀取操作得到的就是更新后的值。