SaaS關鍵技術

----開源解決方案Copyright?2009NeusoftCorporation解決方案技術中心SaaS關鍵技術

----開源解Part1：IT部署視圖演化及挑戰Part2：動態基礎設施Part3：SaaS架構關注技術Part4：Q&APart1：IT部署視圖演化及挑戰IT系統部署視圖演化-1IT系統部署視圖演化-1N輪視圖演化后架構N輪視圖演化后架構開源的SaaS項目解決方案演化面對的挑戰基礎設施可擴展計算資源快速的供給應用快速部署資源按需分配自動化管理的能力應用架構可擴展應用服務器可水平擴展數據庫水平可擴展異步消息隊列緩存機制應用負載均衡流程可定制功能可配置演化面對的挑戰基礎設施可擴展計算資源快速的供給應用快速部署資Part1：IT部署視圖演化及挑戰Part2：動態基礎設施Part3：SaaS架構關注技術Part4：Q&APart1：IT部署視圖演化及挑戰云計算關鍵特性計算服務化資源虛擬化管理智能化自服務化云計算關鍵特性計算服務化資源虛擬化管理智能化自服務化基礎設施供應生命周期基礎設施供應生命周期資源池動態伸縮CloudCloudDDDDDDDDD資源池動態伸縮CloudCloudDDDDDDDDDPart1：IT部署視圖演化及挑戰Part2：動態基礎設施Part3：SaaS關注技術Part4：Q&APart1：IT部署視圖演化及挑戰SaaS關鍵特性高可用性高伸縮性高性能高伸縮：多租戶，功能可配置，流程可配置SaaS關鍵特性高可用性高伸縮性高性能高伸縮：多租戶，功能可SaaS架構關注內容1.數據存儲區域2.數據訪問區域3.緩存區域4.應用服務服務區域5.Web服務器區域6.分布式文件區域7.MQ消息隊列區域8.負載均衡區域9.

其它技術SaaS架構關注內容1.數據存儲區域2.數據訪問區域3.緩數據存儲的挑戰SaaS數據存儲模式完全獨立模式（獨立數據庫模式）部分獨立模式（共享數據庫、獨立數據結構模式）完全共享模式（共享數據庫、共享數據結構模式）成長的煩惱高并發的數據讀寫訪問海量數據的高效讀寫訪問及管理高擴展及高可用性數據存儲的挑戰SaaS數據存儲模式完全獨立模式（獨立數據庫模傳統解決方案VS新興解決方案SQL

采用集群方式分擔系統壓力Partition方式Sharding方式

（垂直，水平）讀寫分離預留字段值對/行專列Xml擴展不足：擴展性不好成本高NoSQL內置集群支持很容易水平擴展強大數據備份功能支持Mapreduce功能不足：不支持SQL目前都是開業的沒有商業產品不支持或是局部支持事務傳統解決方案VS新興解決方案SQL采用集群方式分擔系統SQL集群技術-MySQL集群方案有點缺點速度適用場合NDB可用于負載均衡場合；

可用于高可靠性場合；

高伸縮性；

真正的數據庫冗余；

容易維護。

隨著數據庫的變大，對RAM的需求變得更大，因此成本很高幾乎比典型的單獨服務器（無千兆以太網，無SCI卡，存儲引擎相關的限制少）慢10倍。冗余，高可靠性，負載均衡MySQL/GFS-GNBD/HA(Active/Passive)高可靠性

某種程度的冗余

按照高可靠性進行伸縮

沒有負載均衡

沒有保證的冗余

無法對寫操作進行伸縮

對讀操作支持得較好需要高可靠性的、讀操作密集型的應用MySQL/DRBD/HA(Active/Passive)高可靠性；

一定程度的冗余；

以高可靠性名義來看是可伸縮的

沒有負載均衡

沒有保證的冗余

在寫負載方面沒有伸縮性

在讀寫方面相當于單獨服務器需要高可靠性、讀操作密集型的應用MySQLWriteMaster/MultipleMySQLReadSlaves(Active/Active)讀操作的高可靠性；

讀操作的負載均衡；

在讀操作負載均衡方面是可伸縮的

無寫操作的高可靠性；

無寫操作的負載均衡；

在寫操作方面無伸縮性

同單獨服務器；在讀操作方面支持得較好讀操作密集型的、需要高可靠性和負載均衡的應用Google

MySQL

MMM技術SQL集群技術-MySQL集群方案有點缺點速度適用場合NDBShardingvsPartitionShardingPartition存儲依賴可跨越DB可跨越物理機器可跨越表空間,不同的物理屬性不能跨DB存儲存儲方式分布式集中式擴展性ScaleOut(橫向擴展)ScaleUp(升級設備)可用性無單點，需要處理跨數據事務存在單點(DB數據本身)應用場景web2.0多數傳統應用ShardingvsPartitionShardingP數據切分-SQL實現方式優點缺點垂直切分實現簡單擴展能力有限

強耦合的應用不容易垂直切分讀寫分離可有效分擔讀的壓力

主要在數據庫層擴展，應用修改小對讀寫均衡的應用擴展能有限

依賴于數據庫本身的同步能力水平切分SaaS普遍使用

擴展性強實施復雜數據切分-SQL實現方式優點缺點垂直切分實現簡單擴展能力有限垂直shardinguserphrAppDAL垂直shardinguserphrAppDAL水平shardingPhr33%Phr33%AppDALPhr34%水平shardingPhr33%Phr33%AppDAL讀寫分離phrphrAppDAL讀/寫讀讀寫分離phrphrAppDAL讀/寫讀SQL數據訪問區域(DAL)1.mysqlproxy

實現“讀寫分離（Read/WriteSplitting）”。基本的原理是讓主數據庫處理事務性查詢，而從數據庫處理SELECT查詢。數據庫復制被用來把事務性查詢導致的變更同步到集群中的從數據庫。2.Amoeba

Amoeba項目是分布式數據庫proxy開發框架。座落與Client、DBServer(s)之間。對客戶

端透明。具有負載均衡、高可用性、sql過濾、讀寫分離、可路由相關的query到目標數據庫、可并發請

求多臺數據庫合并結果。

主要解決：

*降低數據切分帶來的復雜多數據庫結構

*提供切分規則并降低數據切分規則給應用帶來的影響

*降低db與客戶端的連接數

*讀寫分離3.WebsphereIISQL數據訪問區域(DAL)1.mysqlproxyCase1Case1Case1數據生成分布規則：按照20會員每天采集一次監控，每次采集10個指標（都為數值型）計算，按照20萬會員2010年全年的數據量，共計生成7.3億條記錄。分布在4個節點中，每臺設備1.825億條。共計50GB。血壓標簽統計地區執行時間120~15090~12080~90test0np_034539ms15732123140882123TransactionNameMinimumAverageMaximumStd.Deviation90Percentquery0.0010.0343.820.1560.04Case1數據生成分布規則：血壓標簽統計地區執行時間120Sql數據擴展問題Sql數據擴展問題Case2

–hadoopHBase&Hive2003年Google三篇論文:GFS,MapReduce,Bigtable

Hbase是一個分布式開源數據庫，基于Hadoop分布式文件系統，模仿并提供了基于Google文件系統的Bigtable數據庫的所有功能。其目標是處理非常龐大的表，可以用普通的計算機處理超過10億行數據，并且有數百萬列元素組成的數據表。MapReduce是分布式計算軟件構架，它可以支持大數據量的分布式并行處理。

Case2–hadoopHBase&Hive2003Hadoop軟件棧Hadoop軟件棧Table&ColumnFamily

RowKey

Timestamp

ColumnFamily

血壓（高壓）血壓（低壓）phr_user1t312080t213090t1

phr_user2t514070t414585

RowKey:行鍵，Table的主鍵，Table中的記錄按照RowKey排序Timestamp:時間戳，每次數據操作對應的時間戳，可以看作是數據的versionnumberColumnFamily：列簇，Table在水平方向有一個或者多個ColumnFamily組成，一個ColumnFamily中可以由任意多個Column組成，即ColumnFamily支持動態擴展，無需預先定義Column的數量以及類型，所有Column均以二進制格式存儲，用戶需要自行進行類型轉換。Table&ColumnFamily

RowKeyCase2

–hadoopHBase&HiveCase2–hadoopHBase&HiveCase2-hadoop&Hive交易名稱交易響應時間（單位：秒）AverageTPSMinimumAverageMaximum90PercentInsert空表0.0010.0121.0760.03595.863Insert（3.06億）0.0010.0120.0590.03995.758交易名稱交易響應時間（單位：秒）AverageTPSMinimumAverageMaximum90PercentQuery0.0140.1454.2380.19627.47交易響應時間（單位：秒）4節點6節點8節點一個月數據140.007140.061147.029一年數據522.351285.998292.867Case2-hadoop&Hive交易名稱交易響應SQL與NoSQL整合方案-hadoop&HiveDBMS從MySQL讀寫部分數據讀NoSQLNoSQL同步1.DBMS保存全部數據，主要完成交易類數據的讀寫2.通過同步技術把DBMS的數據同步到NoSQL數據庫中3.NoSQL負責完成歷史數據的查詢統計分析等工作SQL與NoSQL整合方案-hadoop&HiveDNoSQL數據庫--MongoDBNoSQL數據庫--MongoDBMongoDB與MySQL混搭采用MySQL與mongoDB混搭的模式，利用NoSQL數據的列可以動態擴展的優勢來避免在關系數據庫為了擴展所采用行轉列導致的數據爆炸性增長的問題1.面向集合的存儲：適合存儲對象及JSON形式的數據。2.動態查詢：Mongo支持豐富的查詢表達式。3.完整的索引支持：包括文檔內嵌對象及數組。Mongo的查詢優化器會分析查詢表達式4.復制及自動故障轉移。不適用：高度事務性的系統傳統的商業智能應用MongoDB與MySQL混搭采用MySQL與mongoDSQL數據庫擴展的問題ID

<100ID<200AppDALID<300ID<400SQL數據庫擴展的問題ID<100ID<200AppDALNoSQL數據庫擴展phrphrAppDALphrphrNoSQL數據庫擴展phrphrAppDALphrphr數據緩存工作原理DBMS客戶端App

ServerCacheDBMSCacheCacheCache第一次，從數據庫讀取數據，并寫入緩存第二次，從緩存讀取數據，如果數據不存在，那么，在去數據庫查詢數據目的：避免磁盤IO提高效率，減輕數據庫壓力數據緩存工作原理DBMS客戶端AppServerCache開源緩存對比實現方式優點缺點Terracotta采用JVM的heap復制方式不是通過對象序列化的方式傳輸Java實現可以無縫整合到JEE應用本身可以提供集群字節碼級的監控可能會影響效率配置比較復雜memcachedC開發效率高對CPU資源要求低水平擴展性強非java應用需要通過socket調用不提供集群技術，需要自己實現，比較復雜Ehcache/OSCache可以運行在中間價同一個JVM中，執行效力高集群需要作緩存同步水平擴展能力有限需要占用JVM的heap開源緩存對比實現方式優點缺點Terracotta采用JVM的云平臺緩存方案客戶端App

ServerMemcacheEHCacheMemcacheMemcacheMemcacheApp

ServerEHCache采用Memcached作為分布式緩存為了保證系統執行效率采用ehCache作為二級緩存在ehcache設置緩存時間，過期后到Memcached組成的緩存池獲得數據。該方案也可以采用Terracotta云平臺緩存方案客戶端AppServerMemcacheEH應用服務服務區域業務系統的主要業務邏輯運行在應用服務器中，所以，它承擔了更大的壓力，面臨如下挑戰：1.大并發訪問需要做應用服務器集群2.系統為了更可用性和友好性支持無縫切換應用服務服務區域業務系統的主要業務邏輯運行在應用服務器中，所應用服務器session管理實現方式優點缺點典型做法session復制復制負載可以得到極好均衡，也可以保持對fail-over支持sesion復制對網絡壓力比較大。

需要應用服務器支持目前流行的中間件產品都支持stickysession實現簡單，在負載均衡層或是proxy層做配置即可

不會因為session同步給網絡帶來壓力不能實現完全負載均衡、無法實現failoverapache或是其它webserver做propxy基于cache集中式session應用服務器是無狀態，可實現完全負載均衡，不會帶來因為session復制帶來的網絡壓力實施復雜，對于部分功能需要定制開發使用Terracotta或是memcache等應用服務器session管理實現方式優點缺點典型做法sess云下有狀態應用方案-memached-session客戶端App

ServerMemcacheMemcacheMemcacheMemcacheApp

Servermemcached-session-manager具有如下特性：1.支持tomcat6和tomcat72.能夠保持sticky會話和nonesticky會話3.能夠支持tomcat失敗轉移4.能夠支持Memcached失敗轉移5.實現session序列化6.可以實現session的異步存儲7.Session修改更新Memcached8.JMX管理和監控云下有狀態應用方案-memached-session客戶端A云下有狀態應用方案-Terracotta客戶端App

ServerTerracoattTerracoattTerracoattTerracoattApp

Server1.Terracotta本身支持集群，避免單點故障(雙機或者多機鏡像)2.

Terracotta的基礎是分布式數據共享和線程協同3.不是通過對象序列化的方式傳輸，支持Field級別的變更同步4.不需要修改程序5.支持目前主流的中間價agentagent云下有狀態應用方案-Terracotta客戶端AppSWebserver區域ApachevsNginxvslighttpd反向代理等功能1.作為老牌HttpServer，ApacheHttpd在功能表現上令人滿意，配置相對簡單，功能豐富并且穩定，可以任意編譯添加所需功能的模塊。2.Nginx作為新興的HttpServer，在性能表現上令人滿意，功能相對豐富，作為功能相對簡單的應用前臺HttpServer是可以推薦的，而且HttpServer可以做到動態更改配置文件，不需要長時間中斷服務。3.Lighttpd性能表現很好，但是在功能上有很多不穩定之處。Webserver區域ApachevsNginxvsWebserver靜態資源分離靜態資源（圖片，js腳本，css等）使用單獨的服務器處理請求http

ServerApp

server瀏覽器靜態資源靜態資源動態請求動態請求動態請示動態請示Webserver靜態資源分離靜態資源（圖片，js腳本，c分布式文件作用

SaaS業務系統面臨著海量小圖片數據的存儲問題，這些圖片數據大小在幾K～幾十K不等但數目非常龐大，處理這些海量數據小文件傳統文件系統已經不能滿足要求，系統在scaling的過程中都遇到了這樣的問題：磁盤IO過高；備份困難；單點問題，容量和讀寫無法水平擴展，還存在故障的可能。使用分布式存儲技術來解決圖片數據管理和容量擴展等方面的問題客戶端App

ServerNAS存儲/磁盤陣列App

Server分布式文件作用SaaS業務系統面臨著海量小圖片數據分布式文件系統工作原理存儲節點，即StorageCluster，完成文件管理的所有功能。包括存儲、同步和提供存取接口；同時通過對metadata的管理實現了IO的并行和高效訪問。具有云存儲虛擬、自治、高效特點的實驗項目，支持多盤組、異構整合。Tracker，即跟蹤器主要負責IO調度，通過負載均衡方式實現可靠、快速的資源存取。

Client可以是以Service的方式對云存儲提供IO服務。MogileDFS

VS

FastDFS

分布式文件系統工作原理存儲節點，即StorageClustCase3

GIS系統地圖柵格數據測試Case3GIS系統地圖柵格數據測試消息隊列程序解耦消息可靠性到達異步通信提供效率消息隊列程序解耦企業級消息隊列1.消息嚴格的排序；2.支持事務3.信息通過持久化的方式保證安全可靠代表產品：1.Apache

ActiveMQ2.JbossMQ3.IBM

MQ4.Weblogic

JMS適合場景：企業級應用中消息可靠傳輸企業級消息隊列1.消息嚴格的排序；互聯網消息隊列1.消息不需要嚴格的排序；2.不支持事務大多數情況可接受3.讀寫數據非常快4.橫向擴展性好代表產品：Kestrel適合場景：1.互聯網應用中消息動態互聯網消息隊列1.消息不需要嚴格的排序；Case4

Kestrel性能表現線程并發數存入10000條消息總時間（單位：秒）平均TPS第一次第二次第三次平均13.1446286813.3789056913.2551921773.2595755163067.88102.3287159322.2632132852.2974953192.2964748454354.5502.6794187122.6436958022.5845161462.6358768873793.8Case4Kestrel性能表現線程并發數存入10000條負載均衡區域http重定向DNS負載均衡反向代理負載均衡IP負載均衡對應產品包括：nginxapachehttpdLVS(網絡第四層工作)F5(硬件，四層/七層)redware(硬件，四層/七層)負載均衡區域http重定向LVS結構工作模式：VirtualServerviaNetworkAddressTranslation（VS/NAT）

VirtualServerviaIPTunneling（VS/TUN）VirtualServerviaDirectRouting（VS/DR）協議內容TCPHTTP，FTP，PROXY，SMTP，POP3，IMAP4，DNS，LDAP，HTTPS，SSMTP等UDPDNS，NTP，ICP，視頻、音頻流播放協議等LVS結構工作模式：協議內容TCPHTTP，FTP，PROXLVS

HA結構LVSHA結構Case5熙康數據上傳業務Case5熙康數據上傳業務Case5熙康數據上傳業務該架構主要分為如下幾個部分：引入LVS主備的負載均衡模式引入基于LVS的Tomcat負載均衡引入ActiveMQ的Master/Slave的模式引入基于MMM的MySQL高可用模式引入基于Spring的多線程技術紅色部分可以考慮在未來架構中引入Memcached為了更好的利用系統資源，LVS，tomcat，ActiveMQ等均部署在基于XenServer的虛擬機上。Case5熙康數據上傳業務該架構主要分為如下幾個部分：Case5測試結果Case5測試結果其它技術單點登陸CMSPortal等其它技術單點登陸Part1：IT部署視圖演化及挑戰Part2：動態基礎設施Part3：SaaS關注技術Part4：Q&APart1：IT部署視圖演化及挑戰Copyright?2009NeusoftCorporation

Copyright?2009NeusoftCorpo謝謝！放映結束感謝各位觀看！讓我們共同進步謝謝！放映結束感謝各位觀看！讓我們共同進步SaaS關鍵技術

----開源解決方案Copyright?2009NeusoftCorporation解決方案技術中心SaaS關鍵技術

----開源解Part1：IT部署視圖演化及挑戰Part2：動態基礎設施Part3：SaaS架構關注技術Part4：Q&APart1：IT部署視圖演化及挑戰IT系統部署視圖演化-1IT系統部署視圖演化-1N輪視圖演化后架構N輪視圖演化后架構開源的SaaS項目解決方案演化面對的挑戰基礎設施可擴展計算資源快速的供給應用快速部署資源按需分配自動化管理的能力應用架構可擴展應用服務器可水平擴展數據庫水平可擴展異步消息隊列緩存機制應用負載均衡流程可定制功能可配置演化面對的挑戰基礎設施可擴展計算資源快速的供給應用快速部署資Part1：IT部署視圖演化及挑戰Part2：動態基礎設施Part3：SaaS架構關注技術Part4：Q&APart1：IT部署視圖演化及挑戰云計算關鍵特性計算服務化資源虛擬化管理智能化自服務化云計算關鍵特性計算服務化資源虛擬化管理智能化自服務化基礎設施供應生命周期基礎設施供應生命周期資源池動態伸縮CloudCloudDDDDDDDDD資源池動態伸縮CloudCloudDDDDDDDDDPart1：IT部署視圖演化及挑戰Part2：動態基礎設施Part3：SaaS關注技術Part4：Q&APart1：IT部署視圖演化及挑戰SaaS關鍵特性高可用性高伸縮性高性能高伸縮：多租戶，功能可配置，流程可配置SaaS關鍵特性高可用性高伸縮性高性能高伸縮：多租戶，功能可SaaS架構關注內容1.數據存儲區域2.數據訪問區域3.緩存區域4.應用服務服務區域5.Web服務器區域6.分布式文件區域7.MQ消息隊列區域8.負載均衡區域9.

其它技術SaaS架構關注內容1.數據存儲區域2.數據訪問區域3.緩數據存儲的挑戰SaaS數據存儲模式完全獨立模式（獨立數據庫模式）部分獨立模式（共享數據庫、獨立數據結構模式）完全共享模式（共享數據庫、共享數據結構模式）成長的煩惱高并發的數據讀寫訪問海量數據的高效讀寫訪問及管理高擴展及高可用性數據存儲的挑戰SaaS數據存儲模式完全獨立模式（獨立數據庫模傳統解決方案VS新興解決方案SQL

采用集群方式分擔系統壓力Partition方式Sharding方式

（垂直，水平）讀寫分離預留字段值對/行專列Xml擴展不足：擴展性不好成本高NoSQL內置集群支持很容易水平擴展強大數據備份功能支持Mapreduce功能不足：不支持SQL目前都是開業的沒有商業產品不支持或是局部支持事務傳統解決方案VS新興解決方案SQL采用集群方式分擔系統SQL集群技術-MySQL集群方案有點缺點速度適用場合NDB可用于負載均衡場合；

可用于高可靠性場合；

高伸縮性；

真正的數據庫冗余；

容易維護。

隨著數據庫的變大，對RAM的需求變得更大，因此成本很高幾乎比典型的單獨服務器（無千兆以太網，無SCI卡，存儲引擎相關的限制少）慢10倍。冗余，高可靠性，負載均衡MySQL/GFS-GNBD/HA(Active/Passive)高可靠性

某種程度的冗余

按照高可靠性進行伸縮

沒有負載均衡

沒有保證的冗余

無法對寫操作進行伸縮

對讀操作支持得較好需要高可靠性的、讀操作密集型的應用MySQL/DRBD/HA(Active/Passive)高可靠性；

一定程度的冗余；

以高可靠性名義來看是可伸縮的

沒有負載均衡

沒有保證的冗余

在寫負載方面沒有伸縮性

在讀寫方面相當于單獨服務器需要高可靠性、讀操作密集型的應用MySQLWriteMaster/MultipleMySQLReadSlaves(Active/Active)讀操作的高可靠性；

讀操作的負載均衡；

在讀操作負載均衡方面是可伸縮的

無寫操作的高可靠性；

無寫操作的負載均衡；

在寫操作方面無伸縮性

同單獨服務器；在讀操作方面支持得較好讀操作密集型的、需要高可靠性和負載均衡的應用Google

MySQL

MMM技術SQL集群技術-MySQL集群方案有點缺點速度適用場合NDBShardingvsPartitionShardingPartition存儲依賴可跨越DB可跨越物理機器可跨越表空間,不同的物理屬性不能跨DB存儲存儲方式分布式集中式擴展性ScaleOut(橫向擴展)ScaleUp(升級設備)可用性無單點，需要處理跨數據事務存在單點(DB數據本身)應用場景web2.0多數傳統應用ShardingvsPartitionShardingP數據切分-SQL實現方式優點缺點垂直切分實現簡單擴展能力有限

強耦合的應用不容易垂直切分讀寫分離可有效分擔讀的壓力

主要在數據庫層擴展，應用修改小對讀寫均衡的應用擴展能有限

依賴于數據庫本身的同步能力水平切分SaaS普遍使用

擴展性強實施復雜數據切分-SQL實現方式優點缺點垂直切分實現簡單擴展能力有限垂直shardinguserphrAppDAL垂直shardinguserphrAppDAL水平shardingPhr33%Phr33%AppDALPhr34%水平shardingPhr33%Phr33%AppDAL讀寫分離phrphrAppDAL讀/寫讀讀寫分離phrphrAppDAL讀/寫讀SQL數據訪問區域(DAL)1.mysqlproxy

實現“讀寫分離（Read/WriteSplitting）”。基本的原理是讓主數據庫處理事務性查詢，而從數據庫處理SELECT查詢。數據庫復制被用來把事務性查詢導致的變更同步到集群中的從數據庫。2.Amoeba

Amoeba項目是分布式數據庫proxy開發框架。座落與Client、DBServer(s)之間。對客戶

端透明。具有負載均衡、高可用性、sql過濾、讀寫分離、可路由相關的query到目標數據庫、可并發請

求多臺數據庫合并結果。

主要解決：

*降低數據切分帶來的復雜多數據庫結構

*提供切分規則并降低數據切分規則給應用帶來的影響

*降低db與客戶端的連接數

*讀寫分離3.WebsphereIISQL數據訪問區域(DAL)1.mysqlproxyCase1Case1Case1數據生成分布規則：按照20會員每天采集一次監控，每次采集10個指標（都為數值型）計算，按照20萬會員2010年全年的數據量，共計生成7.3億條記錄。分布在4個節點中，每臺設備1.825億條。共計50GB。血壓標簽統計地區執行時間120~15090~12080~90test0np_034539ms15732123140882123TransactionNameMinimumAverageMaximumStd.Deviation90Percentquery0.0010.0343.820.1560.04Case1數據生成分布規則：血壓標簽統計地區執行時間120Sql數據擴展問題Sql數據擴展問題Case2

–hadoopHBase&Hive2003年Google三篇論文:GFS,MapReduce,Bigtable

Hbase是一個分布式開源數據庫，基于Hadoop分布式文件系統，模仿并提供了基于Google文件系統的Bigtable數據庫的所有功能。其目標是處理非常龐大的表，可以用普通的計算機處理超過10億行數據，并且有數百萬列元素組成的數據表。MapReduce是分布式計算軟件構架，它可以支持大數據量的分布式并行處理。

Case2–hadoopHBase&Hive2003Hadoop軟件棧Hadoop軟件棧Table&ColumnFamily

RowKey

Timestamp

ColumnFamily

血壓（高壓）血壓（低壓）phr_user1t312080t213090t1

phr_user2t514070t414585

RowKey:行鍵，Table的主鍵，Table中的記錄按照RowKey排序Timestamp:時間戳，每次數據操作對應的時間戳，可以看作是數據的versionnumberColumnFamily：列簇，Table在水平方向有一個或者多個ColumnFamily組成，一個ColumnFamily中可以由任意多個Column組成，即ColumnFamily支持動態擴展，無需預先定義Column的數量以及類型，所有Column均以二進制格式存儲，用戶需要自行進行類型轉換。Table&ColumnFamily

RowKeyCase2

–hadoopHBase&HiveCase2–hadoopHBase&HiveCase2-hadoop&Hive交易名稱交易響應時間（單位：秒）AverageTPSMinimumAverageMaximum90PercentInsert空表0.0010.0121.0760.03595.863Insert（3.06億）0.0010.0120.0590.03995.758交易名稱交易響應時間（單位：秒）AverageTPSMinimumAverageMaximum90PercentQuery0.0140.1454.2380.19627.47交易響應時間（單位：秒）4節點6節點8節點一個月數據140.007140.061147.029一年數據522.351285.998292.867Case2-hadoop&Hive交易名稱交易響應SQL與NoSQL整合方案-hadoop&HiveDBMS從MySQL讀寫部分數據讀NoSQLNoSQL同步1.DBMS保存全部數據，主要完成交易類數據的讀寫2.通過同步技術把DBMS的數據同步到NoSQL數據庫中3.NoSQL負責完成歷史數據的查詢統計分析等工作SQL與NoSQL整合方案-hadoop&HiveDNoSQL數據庫--MongoDBNoSQL數據庫--MongoDBMongoDB與MySQL混搭采用MySQL與mongoDB混搭的模式，利用NoSQL數據的列可以動態擴展的優勢來避免在關系數據庫為了擴展所采用行轉列導致的數據爆炸性增長的問題1.面向集合的存儲：適合存儲對象及JSON形式的數據。2.動態查詢：Mongo支持豐富的查詢表達式。3.完整的索引支持：包括文檔內嵌對象及數組。Mongo的查詢優化器會分析查詢表達式4.復制及自動故障轉移。不適用：高度事務性的系統傳統的商業智能應用MongoDB與MySQL混搭采用MySQL與mongoDSQL數據庫擴展的問題ID

<100ID<200AppDALID<300ID<400SQL數據庫擴展的問題ID<100ID<200AppDALNoSQL數據庫擴展phrphrAppDALphrphrNoSQL數據庫擴展phrphrAppDALphrphr數據緩存工作原理DBMS客戶端App

ServerCacheDBMSCacheCacheCache第一次，從數據庫讀取數據，并寫入緩存第二次，從緩存讀取數據，如果數據不存在，那么，在去數據庫查詢數據目的：避免磁盤IO提高效率，減輕數據庫壓力數據緩存工作原理DBMS客戶端AppServerCache開源緩存對比實現方式優點缺點Terracotta采用JVM的heap復制方式不是通過對象序列化的方式傳輸Java實現可以無縫整合到JEE應用本身可以提供集群字節碼級的監控可能會影響效率配置比較復雜memcachedC開發效率高對CPU資源要求低水平擴展性強非java應用需要通過socket調用不提供集群技術，需要自己實現，比較復雜Ehcache/OSCache可以運行在中間價同一個JVM中，執行效力高集群需要作緩存同步水平擴展能力有限需要占用JVM的heap開源緩存對比實現方式優點缺點Terracotta采用JVM的云平臺緩存方案客戶端App

ServerMemcacheEHCacheMemcacheMemcacheMemcacheApp

ServerEHCache采用Memcached作為分布式緩存為了保證系統執行效率采用ehCache作為二級緩存在ehcache設置緩存時間，過期后到Memcached組成的緩存池獲得數據。該方案也可以采用Terracotta云平臺緩存方案客戶端AppServerMemcacheEH應用服務服務區域業務系統的主要業務邏輯運行在應用服務器中，所以，它承擔了更大的壓力，面臨如下挑戰：1.大并發訪問需要做應用服務器集群2.系統為了更可用性和友好性支持無縫切換應用服務服務區域業務系統的主要業務邏輯運行在應用服務器中，所應用服務器session管理實現方式優點缺點典型做法session復制復制負載可以得到極好均衡，也可以保持對fail-over支持sesion復制對網絡壓力比較大。

需要應用服務器支持目前流行的中間件產品都支持stickysession實現簡單，在負載均衡層或是proxy層做配置即可

不會因為session同步給網絡帶來壓力不能實現完全負載均衡、無法實現failoverapache或是其它webserver做propxy基于cache集中式session應用服務器是無狀態，可實現完全負載均衡，不會帶來因為session復制帶來的網絡壓力實施復雜，對于部分功能需要定制開發使用Terracotta或是memcache等應用服務器session管理實現方式優點缺點典型做法sess云下有狀態應用方案-memached-session客戶端App

ServerMemcacheMemcacheMemcacheMemcacheApp

Servermemcached-session-manager具有如下特性：1.支持tomcat6和tomcat72.能夠保持sticky會話和nonesticky會話3.能夠支持tomcat失敗轉移4.能夠支持Memcached失敗轉移5.實現session序列化6.可以實現session的異步存儲7.Session修改更新Memcached8.JMX管理和監控云下有狀態應用方案-memached-session客戶端A云下有狀態應用方案-Terracotta客戶端App

ServerTerracoattTerracoattTerracoattTerracoattApp

Server1.Terracotta本身支持集群，避免單點故障(雙機或者多機鏡像)2.

Terracotta的基礎是分布式數據共享和線程協同3.不是通過對象序列化的方式傳輸，支持Field級別的變更同步4.不需要修改程序5.支持目前主流的中間價agentagent云下有狀態應用方案-Terracotta客戶端AppSWebserver區域ApachevsNginxvslighttpd反向代理等功能1.作為老牌HttpServer，ApacheHttpd在功能表現上令人滿意，配置相對簡單，功能豐富并且穩定，可以任意編譯添加所需功能的模塊。2.Nginx作為新興的HttpServer，在性能表現上令人滿意，功能相對豐富，作為功能相對簡單的應用前臺HttpServer是可以推薦的，而且HttpServer可以做到動態更改配置文件，不需要長時間中斷服務。3.Lighttpd性能表現很好，但是在功能上有很多不穩定之處。Webserver區域ApachevsNginxvsWebserver靜態資源分離靜態資源（圖片，js腳本，css等）使用單獨的服務器處理請求http

ServerApp

server瀏覽器靜態資源靜態資源動態請求動態請求動態請示動態請示Webserver靜態資源分離靜態資源（圖片，js腳本，c分布式文件作用

SaaS業務系統面臨著海量小圖片數據的存儲問題，這些圖片數據大小在幾K～幾十K不等但數目非常龐大，處理這些海量數據小文件傳統文件系統已經不能滿足要求，系統在scaling的過程中都遇到了這樣的問題：磁盤IO過高；備份困難；單點問題，容量和讀寫無法水平擴展，還存在故障的可能。使用分布式存儲技術來解決圖片數據管理和容量擴展等方面的問題客戶端App

ServerNAS存儲/磁盤陣列App

Server分布式文件作用Saa