大型分布式系統(tǒng)原理概述

分布式系統(tǒng)三要素

? CPU:處理器

? Memory:內(nèi)存

? IO:外存

? MultiCore:多核心

? LocalDisk:本地磁盤(pán)

? Networker:網(wǎng)絡(luò)，網(wǎng)絡(luò)存儲(chǔ)

? RDMA:遠(yuǎn)程內(nèi)存直接訪問(wèn)

? NUMA:分布式系統(tǒng)CPU和內(nèi)存進(jìn)行整合，對(duì)內(nèi)存進(jìn)行捆綁，是硬件層級(jí)的，（相似與ThreadLocal,將數(shù)據(jù)和實(shí)時(shí)運(yùn)行線程綁定到一起），網(wǎng)卡直接繞過(guò)CPU共享內(nèi)存，速度非?？?/p>

?

分布式系統(tǒng)三要素的進(jìn)化

? 桌面級(jí)八核心十六線程CPU于2014年誕生，2015年Intel預(yù)計(jì)發(fā)布18核心桌面級(jí)CPU

? NUMA在大中型系統(tǒng)上一直非常盛行，NUMA能很好提升系統(tǒng)吞吐能力，特別對(duì)于Java以及數(shù)據(jù)這樣占用大內(nèi)存的系統(tǒng)，但一直以來(lái)沒(méi)有得到 DBA 們足夠的重視、 Java領(lǐng)域也很少有人研究

? RDMA（遠(yuǎn)程內(nèi)存直接訪問(wèn)，網(wǎng)絡(luò)傳輸協(xié)議，類似TCP,更低延遲）是超高性能計(jì)算UHPC的重要基礎(chǔ)之一，而Direct Socket Protocol （SDP）作為RDMA的傳輸協(xié)議已經(jīng)在很多關(guān)鍵領(lǐng)域取代了TCP，Java7也正式開(kāi)始支持SDP，跨入了UHPC的領(lǐng)地。

? IO方面，萬(wàn)兆網(wǎng)正在崛起，萬(wàn)兆網(wǎng)的ISCSI存儲(chǔ)， 單通道可達(dá)到500MB/s， 每秒500,000個(gè)IO能力，而目前主流的SSD硬盤(pán)的速度是400-550MB/s。

? ===>虛擬化，大勢(shì)所趨

NUMA與RMDA（Java）

?

? 兩個(gè)核心的CPU，里面有自己的本地線程，內(nèi)存塊整個(gè)分為兩塊，Memory1和Memory2,每個(gè)內(nèi)存核心綁定它的內(nèi)存和IO的PC卡劃成兩個(gè)Domain域，這兩個(gè)通過(guò)總線通信，這是一個(gè)典型的分布式系統(tǒng)，將計(jì)算能力和內(nèi)存進(jìn)行了分布，BUS相當(dāng)于總線，這是一個(gè)經(jīng)典的分布式架構(gòu)，它把軟件架構(gòu)思想用到了硬件中

RMDA可以用InfiniBand也可以用專用網(wǎng)卡，SDP通信的時(shí)候應(yīng)用端程序把數(shù)據(jù)寫(xiě)到緩沖區(qū)，緩沖區(qū)直接到網(wǎng)卡傳輸出去，OS旁路，CPU就是旁路，CPU不涉及到數(shù)據(jù)的傳輸，比如說(shuō)現(xiàn)在要傳輸一個(gè)流量，OS不會(huì)產(chǎn)生傳輸?shù)闹袛?，?yīng)用緩沖區(qū)放到OS中，這是一個(gè)零拷貝的技術(shù)，所以它延遲非常低， 它把OS、CPU旁路了，所以響應(yīng)性能是非常高的

? 這個(gè)技術(shù)會(huì)在大數(shù)據(jù)時(shí)代發(fā)揮非常重要的作用，這種情況下，如果有硬件大的要求，那么實(shí)際網(wǎng)絡(luò)傳輸會(huì)很快從一個(gè)節(jié)點(diǎn)到另一個(gè)節(jié)點(diǎn)，那么它的計(jì)算會(huì)加快很多

硬盤(pán)成了主角？

? 這種硬盤(pán)把CPU、內(nèi)存、網(wǎng)卡綁定在自身上，這種硬盤(pán)已經(jīng)構(gòu)成了一個(gè)小型的計(jì)算機(jī)，而且直接提供了因特網(wǎng)的傳輸節(jié)點(diǎn)，這樣就可以在1U和2U的機(jī)架里面放很多塊硬盤(pán)，很多小塊密集在一起就構(gòu)成了一個(gè)大的密集存儲(chǔ)，它是一個(gè)嵌入的定制系統(tǒng)，它的IO傳輸效率非常高，它是TCP的網(wǎng)絡(luò)節(jié)點(diǎn)，如果在之上放一個(gè)萬(wàn)兆交換機(jī)就直接構(gòu)成了存儲(chǔ)模塊，而且價(jià)格低廉性能高，拓展性高，專供云計(jì)算

最成功的企業(yè)級(jí)分布式系統(tǒng)架構(gòu)——J2EE

? Java在很多人看來(lái)等同于J2EE（企業(yè)級(jí)的應(yīng)用開(kāi)發(fā)框架），這是其他任何語(yǔ)言都沒(méi)有過(guò)的奇跡

? 1999年J2EE誕生，J2EE一出臺(tái)就能夠?yàn)槿藗兲峁┮环暾⒅庇^而不失深邃的圖景

? 到2000年底為止，共有15家廠商能夠提供完整的J2EE解決方案，這些中的大多數(shù)都是IT界的大佬

? 2008年J2EE里的實(shí)力派BEA公司被Oracle 85億收購(gòu)， 對(duì)比2009年74億收購(gòu)了SUN

? J2EE規(guī)范是一系列符合工業(yè)級(jí)技術(shù)和質(zhì)量標(biāo)準(zhǔn)的規(guī)范，學(xué)術(shù)機(jī)構(gòu)、業(yè)內(nèi)廠商都廣泛參與討論和規(guī)劃，擁有一個(gè)龐大的社區(qū)

? 直到今天，J2EE里的JDBC、 Servlet/JSP等技術(shù)仍然是企業(yè)級(jí)應(yīng)用開(kāi)發(fā)必不可缺少的關(guān)鍵技術(shù)

奠定分布式系統(tǒng)架構(gòu)基礎(chǔ)的那些組件

? 三層結(jié)構(gòu)，客戶端、中間層（WEB(servlet)/EJB）,

JNDI:提供查詢服務(wù)，服務(wù)定位，技術(shù)中間件，比如說(shuō)協(xié)議+IP+端口，基礎(chǔ)設(shè)施

JMS:消息中間件

RMI:RPC遠(yuǎn)程服務(wù)調(diào)用，兩者通信，相當(dāng)于訪問(wèn)本地方法一樣訪問(wèn)遠(yuǎn)程方法，基礎(chǔ)設(shè)施

大數(shù)據(jù)和移動(dòng)互聯(lián)網(wǎng)引發(fā)的革新

? 移動(dòng)互聯(lián)網(wǎng)=用戶數(shù)據(jù)，特點(diǎn)就是隨時(shí)接納用戶數(shù)據(jù)，所有互聯(lián)網(wǎng)公司競(jìng)爭(zhēng)燒錢(qián)就是為了攢用戶，用戶會(huì)產(chǎn)生很多數(shù)據(jù)，這些數(shù)據(jù)非常有價(jià)值，這種價(jià)值挖掘經(jīng)過(guò)大數(shù)據(jù)處理，這種數(shù)據(jù)處理規(guī)模非常大，跟傳統(tǒng)的企業(yè)級(jí)開(kāi)發(fā)不一樣，它需要專用的軟件和算法來(lái)處理這些數(shù)據(jù)，這些數(shù)據(jù)處理的目的就是預(yù)測(cè)機(jī)會(huì)商機(jī)，這些機(jī)會(huì)商機(jī)意為著更早的轉(zhuǎn)化更多的金錢(qián)，這些圍繞著大數(shù)據(jù)， 這里面有一個(gè)很重要的因素叫做時(shí)間，如果一個(gè)人 一周后得到結(jié)果和另一個(gè)人一周后得到結(jié)果，這種數(shù)據(jù)就喪失更多的價(jià)值， 因此時(shí)間是非常關(guān)鍵制約點(diǎn)，導(dǎo)致大數(shù)據(jù)發(fā)生了很多變動(dòng)，就是實(shí)時(shí)，像Hadoop這種批處理的離線數(shù)據(jù)處理更多了轉(zhuǎn)向了Spark和Storm這種實(shí)時(shí)性，數(shù)據(jù)上往往加上時(shí)間的緯度，可以把不同的數(shù)據(jù)根據(jù)不同的數(shù)據(jù)進(jìn)行處理，快速高效的進(jìn)行處理，可以做行為軌跡分析

云計(jì)算所引導(dǎo)的軟件定義世界，意味著什么

? 云計(jì)算的三個(gè)突出特點(diǎn)，硬件虛擬化、軟件定義網(wǎng)絡(luò)、軟件定義存儲(chǔ)，這意味一個(gè)軟件架構(gòu)師可以從軟件角度架構(gòu)整個(gè)項(xiàng)目，從部署到上線

一切都在悄然進(jìn)化著，一個(gè)我們熟悉而又陌生的新世界

? 開(kāi)源、分布式系統(tǒng)中重要的中間件或基礎(chǔ)設(shè)施

分布式系統(tǒng)之網(wǎng)絡(luò)篇

80%的程序員所欠缺的網(wǎng)絡(luò)知識(shí)

服務(wù)器網(wǎng)卡的一些秘密

? 硬件不同

? 傳統(tǒng)的PC機(jī)器的PCI接口66MHz 133Mb/s而服務(wù)器的主板支持PCI-E X16 8bit 2.5GHz 8Gb/sTCP/IP卸載引擎(TOE)技術(shù)

? 價(jià)格昂貴

? 性能出眾

? Intel x520-t2 10Gbase-t萬(wàn)兆網(wǎng)卡（4800元報(bào)價(jià)）測(cè)試，單端口單向?qū)嶋H測(cè)試結(jié)果是1248MB/s(9984Mbps)， 達(dá)到理論峰值的99.84%

? 技術(shù)門(mén)檻高

? intel、BROADCOM、H3C(新IT基礎(chǔ)架構(gòu)領(lǐng)導(dǎo)者)

MAC地址、 IP、子網(wǎng)掩碼、網(wǎng)關(guān)及路由

掩碼、網(wǎng)關(guān)及路由.png)

VLAN的原理

管理網(wǎng)絡(luò)、業(yè)務(wù)網(wǎng)絡(luò)、存儲(chǔ)網(wǎng)絡(luò)

網(wǎng)絡(luò)的最前沿技術(shù)之網(wǎng)絡(luò)虛擬化

服務(wù)器虛擬化技術(shù)與網(wǎng)絡(luò)虛擬化技術(shù)相輔相成

Open vswitch


SDN&網(wǎng)絡(luò)虛擬化

關(guān)于NIO與AIO的那些小秘密

Linux AIO的奇葩十年路


Java NIO VS AIO

? AIO帶來(lái)了編程的大幅簡(jiǎn)化和優(yōu)化
? AIO性能目前不如NIO
? AIO當(dāng)前比較適合大文件的讀寫(xiě)
? 現(xiàn)階段網(wǎng)絡(luò)編程主要還是NIO

NIO最佳實(shí)踐

Reactor線程的數(shù)量

Direct Buffer Pool的使用

Reactor線程與異步線程池的合理使用

國(guó)內(nèi)最好的NIO實(shí)踐，就在開(kāi)源項(xiàng)目Mycat里

Java AIO編程框架


網(wǎng)絡(luò)編程中的一朵金花之Netty

為什么選擇Netty

? NIO入門(mén)門(mén)檻高，精通很困難

? 除了NIO本身，企業(yè)級(jí)的Socket Server還需要大量外圍代碼開(kāi)發(fā)

? Netty是業(yè)界最流行的NIO框架之一，幾乎沒(méi)有對(duì)手

? Netty的作者也是開(kāi)發(fā)了大名鼎鼎的Apache Mina的作者

Netty的優(yōu)勢(shì)

? 多種Reactor線程池模式

? 網(wǎng)絡(luò)數(shù)據(jù)串行處理，減少線程切換

? 強(qiáng)大的Buffer池

? 嫻熟的高并發(fā)編程技巧（Volatile、CAS、 ThreadLocal等的使用）

? 作者很多年網(wǎng)絡(luò)編程經(jīng)驗(yàn)的積累與提升

Netty默認(rèn)提供了對(duì)Google Protobuf的支持，通過(guò)擴(kuò)展Netty的編解碼接口，用戶可以實(shí)現(xiàn)其它的高性能序列化框架，例如Thrift的壓縮二進(jìn)制編解碼框架

提供了對(duì)Google Protobuf的支持，通過(guò)擴(kuò)展Netty的編解碼接口，用戶可以實(shí)現(xiàn)其它的高性能序列化框架，例如Thrift的壓縮二進(jìn)制編解碼框架 .png)

Vert.x—— JVM上的Node.js


網(wǎng)絡(luò)編程中的瑞士軍刀之Zookeeper

Zookpeer能做什么

? 類似JNDI的命名服務(wù)

? 實(shí)現(xiàn)分布式系統(tǒng)中的配置服務(wù)

? 提供簡(jiǎn)單好用的分布式同步服務(wù)

? 提供簡(jiǎn)單好用的分布式協(xié)調(diào)框架

? 可以作為一個(gè)簡(jiǎn)單的可靠的消息隊(duì)列

Zookpeer的原理

? ZK提供類似文件目錄樹(shù)的數(shù)據(jù)結(jié)構(gòu)，每個(gè)節(jié)點(diǎn)可以設(shè)置byte[]數(shù)據(jù)

? 節(jié)點(diǎn)類型可以是持久化保存的，也可以是臨時(shí)的(EPHEMERAL)

Zookeeper 特點(diǎn)

? 原子性：更新要么成功，要么失敗，不會(huì)出現(xiàn)部分更新

? 可靠性：一旦數(shù)據(jù)更新成功，將一直保持，直到新的更新

? 單一性 ：無(wú)論客戶端連接哪個(gè)server，都會(huì)看到同一個(gè)視圖

? 及時(shí)性：客戶端會(huì)在一個(gè)確定的時(shí)間內(nèi)得到最新的數(shù)據(jù)。

? 等待無(wú)關(guān)：慢的或者失效的client不得干預(yù)快速的client的請(qǐng)求，使得每個(gè)client都能有效的等待

? 順序一致性：按照客戶端發(fā)送請(qǐng)求的順序更新數(shù)據(jù)，包括全局有序和偏序兩種：全局有序是指如果在一臺(tái)服務(wù)器上消息a在消息b前發(fā)布，則在所有Server上消息a都將在消息b前被發(fā)布；偏序是指如果一個(gè)消息b在消息a后被同一個(gè)發(fā)送者發(fā)布，a必將排在b前面

ZK應(yīng)用場(chǎng)景之命名服務(wù)

? ZK創(chuàng)建一個(gè)節(jié)點(diǎn)后，節(jié)點(diǎn)的路徑就是全局唯一的，可以作為全局名稱使用

?

ZK應(yīng)用場(chǎng)景之分布式配置管理

?

ZK應(yīng)用場(chǎng)景之分布式集群管理

? 每個(gè)節(jié)點(diǎn)（進(jìn)程）啟動(dòng)的時(shí)候在ZK路徑GroupMembers下建立子路徑（節(jié)點(diǎn)ID為路徑名），通信地址Endpoint則寫(xiě)到路徑的Data中

? 每個(gè)節(jié)點(diǎn)監(jiān)聽(tīng)ZK路徑GroupMembers，當(dāng)集群中增加新節(jié)點(diǎn)或故障節(jié)點(diǎn)下線，每個(gè)節(jié)點(diǎn)都會(huì)獲得通知

?

ZK應(yīng)用場(chǎng)景之消息隊(duì)列

? 消息發(fā)送方在ZK上創(chuàng)建一個(gè)Path，發(fā)送消息時(shí)，將消息信息設(shè)置為該P(yáng)ath的內(nèi)容，而消息接收方則監(jiān)聽(tīng)此Path，實(shí)現(xiàn)了簡(jiǎn)單可靠的發(fā)布訂閱模式的消息隊(duì)列

?

ZK應(yīng)用場(chǎng)景之分布式鎖

? Zookeeper能保證數(shù)據(jù)的強(qiáng)一致性，用戶任何時(shí)候都可以相信集群中每個(gè)節(jié)點(diǎn)的數(shù)據(jù)都是相同的。一個(gè)用戶創(chuàng)建一個(gè)節(jié)點(diǎn)作為鎖，另一個(gè)用戶檢測(cè)該節(jié)點(diǎn)，如果存在，代表別的用戶已經(jīng)鎖住，如果不存在，則可以創(chuàng)建一個(gè)節(jié)點(diǎn)，代表?yè)碛幸粋€(gè)鎖

Zookeeper的性能調(diào)優(yōu)和規(guī)模

? ZK的日志文件和snapshort文件分別放在兩塊硬盤(pán)上

? Leader節(jié)點(diǎn)不允許Client連接

? 網(wǎng)上所能見(jiàn)到的信息，最大為1萬(wàn)個(gè)連接（客戶端），
5節(jié)點(diǎn)的ZK集群

Zookeeper客戶端Curator

? “Guava is to Java what Curator is to Zookeeper Patrick Hunt,Zookeeper committer”

? Fluent Style風(fēng)格

? 格.png)

? NetFlix出品

? 極大程度上減少了程序猿的負(fù)擔(dān)
? 接管了Client與Server的連接重連問(wèn)題
? 提供了各種常用ZK應(yīng)用場(chǎng)景的抽象封裝（如共享鎖服務(wù)、 Leader選舉）

Curator的關(guān)鍵用法

? 列出子目錄： CuratorFramework.getChildren().forPath(path)

?

public boolean exists(String parentPath,String path) throws Exception{    Stat stat = zk.checkExists().forPath(parentPath+"/"+path);    return (stat != null );}
1
2
3
4
1
2
3
4

? 創(chuàng)建目錄

? result = zk.create().withMode(createMode).forPath(path,nodeData);

? 監(jiān)聽(tīng)ZK節(jié)點(diǎn)的變化并做出相應(yīng)的處理

?

Curator的幾個(gè)問(wèn)題

若ZK Server還未啟動(dòng)，用戶程序先啟動(dòng)了，則雖然Curator能夠后來(lái)自動(dòng)重連上，但之前的創(chuàng)建節(jié)點(diǎn)和監(jiān)聽(tīng)事件將不會(huì)起效.

List<PathChildrenCache> allZKWathers = new LinkedList<PathChildrenCache>();PathChildrenCache cache = new PathChildrenCache(zk, path, false);cache.getListenable().addListener(plis);cache.start();allZKWathers.add(cache);
1
2
3
4
5
1
2
3
4
5

方法一：

? org.apache.zookeeper.Watcher來(lái)監(jiān)聽(tīng)Connection的狀態(tài)，CuratorZookeeperClient(connectString,TimeoutMs, int connectionTimeoutMs,watcher, retryPolicy)
當(dāng)連接建立后觸發(fā)PathChildrenCache的rebuild方法，重新監(jiān)聽(tīng)路徑
方法二：定時(shí)線程，每隔幾分鐘調(diào)用PathChildrenCache的rebuild方法

Netty+Zookeeper實(shí)踐項(xiàng)目分析

分布式系統(tǒng)之文件

Linux文件系統(tǒng)的進(jìn)化

? 兩種文件系統(tǒng)

? 日志型的與非日志型的

? 非日志型文件系統(tǒng)

? ext2、 FAT、 VFAT、 HPFS（OS/2）、 NTFS、 Sun的UFS等

? 日志型文件系統(tǒng)

? ext3 許多流行的Linux發(fā)行版默認(rèn)的文件系統(tǒng)

? ext4 由ext3增加許多顯著特性和擴(kuò)展進(jìn)化而來(lái)的文件系統(tǒng)

? ReiserFS 全新設(shè)計(jì)的文件系統(tǒng)

? JFS IBM移植的UNIX文件系統(tǒng)

? XFS 為高性能和大文件設(shè)計(jì)的文件系統(tǒng)

? Btrfs 校檢copy-on-write(寫(xiě)入時(shí)復(fù)制)文件系統(tǒng)

? ext4(6) —–> XFS(7)

? 當(dāng)前文件系統(tǒng)中的幾個(gè)強(qiáng)者

? Facebook已經(jīng)開(kāi)始全線換用btrfs

? 紅帽的Red 6使用ext4， 7則使用了XFS

? 浙江省十二五重大科技專項(xiàng)資助項(xiàng)目研究了ZFS在基于hadoop的視頻存儲(chǔ)系統(tǒng)中的應(yīng)用

? 經(jīng)典的第一代分布式文件系統(tǒng)NFS

傳統(tǒng)的分布式文件系統(tǒng)

經(jīng)典的第一代分布式文件系統(tǒng)NFS

?

? 一個(gè)分布式文件系統(tǒng)中有兩種不同的軟件：客戶端文件系統(tǒng)
和文件服務(wù)器。它們的行為共同決定分布式文件系統(tǒng)的行為

對(duì)后來(lái)的分布式文件系統(tǒng)有重要影響的AFS

新型分布式文件系統(tǒng)

PVFS， Linux開(kāi)源的并行虛擬文件系統(tǒng)

? 源的并行虛擬文件系統(tǒng).png)

? 管理節(jié)點(diǎn)： 即元數(shù)據(jù)服務(wù)器，負(fù)責(zé)管理所有的文件元數(shù)
據(jù)信息；

? I/O節(jié)點(diǎn)： 運(yùn)行I/O服務(wù)器，負(fù)責(zé)分布式文件系統(tǒng)中數(shù)據(jù)
的存儲(chǔ)和檢索；

? 計(jì)算節(jié)點(diǎn)： 處理應(yīng)用訪問(wèn)，通過(guò)PVFS專有的libpvfs接口
庫(kù)，從底層訪問(wèn)PVFS服務(wù)器。

Lustre ，專門(mén)針對(duì)高性能計(jì)算的基于對(duì)象存儲(chǔ)的分布式文件系統(tǒng)

針對(duì)高性能計(jì)算的基于對(duì)象存儲(chǔ)的分布式文件系統(tǒng).png)

條帶化

gluster fs:代替Lustre的開(kāi)源的分布式文件系統(tǒng)

Google文件系統(tǒng)（GoogleFS）

HDFS（Hadoop）

ceph：新一代的復(fù)合型分布式文件系統(tǒng)

? Ceph是統(tǒng)一存儲(chǔ)系統(tǒng)，支持三種接口。

? Object： 有原生的API， 而且也兼容Swift和S3的API

? Block： 支持精簡(jiǎn)配置、快照、克隆

? File： Posix接口，支持快照

互聯(lián)網(wǎng)領(lǐng)域中的小文件系統(tǒng)

? MogileFS——影響最大的互聯(lián)網(wǎng)小文件系統(tǒng)

? FastDFS——窮人的解決方案（國(guó)產(chǎn)小有名氣）

? TFS——淘寶的HDFS Copy版本

? GridFS——

MogileFS架構(gòu)和原理

?

? 在MogileFS分布式文件存儲(chǔ)系統(tǒng)中，文件通過(guò) KEY 來(lái)引用， KEY 在同一個(gè)domain（存儲(chǔ)域）下是唯一的，每個(gè)存儲(chǔ)域可以定義不同的文件類別Class，可以針對(duì)不同的存儲(chǔ)類別設(shè)置存儲(chǔ)不同份數(shù)的文件副本

MogileFS的特性

? 應(yīng)用層 — 不需要特殊的核心組件

? 無(wú)單點(diǎn)失敗 — MogileFS分布式文件存儲(chǔ)系統(tǒng)安裝的三個(gè)組件（存儲(chǔ)節(jié)點(diǎn)、跟蹤器、跟蹤用的數(shù)據(jù)庫(kù)）,均可運(yùn)行在多個(gè) 機(jī)器上,因此沒(méi)有單點(diǎn)失敗， 推薦至少兩臺(tái)機(jī)器。

? 自動(dòng)的文件復(fù)制 — 基于不同的文件“分類” ,文件可以被自動(dòng)的復(fù)制到多個(gè)有足夠存儲(chǔ)空間的存儲(chǔ)節(jié)點(diǎn)上,這樣可以滿足這個(gè)“類別”的最少?gòu)?fù)制要求.比如你有一個(gè)圖片網(wǎng)站,你可以設(shè)置原始的JPEG圖片需要復(fù)制 至少三份,但實(shí)際只有1or2份拷貝,如果丟失了數(shù)據(jù),那么MogileFS分布式文件存儲(chǔ)系統(tǒng)可以重新建立遺失的拷貝數(shù)

? “比RAID好多了” —RAID磁盤(pán)是冗余的,但主機(jī)不是,如果你整個(gè)機(jī)器壞了,那么文件也將不能訪問(wèn). MogileFS分布式文件存儲(chǔ)系統(tǒng)在不同的機(jī)器之間進(jìn)行文件復(fù)制,因此文件始終是可用的

? 不需要RAID — 在MogileFS中的磁盤(pán)可以是做了RAID的也可以是沒(méi)有,如果是為了安全性著想的話RAID沒(méi)有必要買(mǎi)了,因?yàn)镸ogileFS分布式文件存儲(chǔ)系統(tǒng)已經(jīng)提供了.

? 簡(jiǎn)單的命名空間 –文件通過(guò)一個(gè)給定的key來(lái)確定,是一個(gè)全局的命名空間

? 不用共享任何東西 — MogileFS分布式文件存儲(chǔ)系統(tǒng)不需要依靠昂貴的SAN來(lái)共享磁盤(pán),每個(gè)機(jī)器只用維護(hù)好自己的磁盤(pán).

? 傳輸中立,無(wú)特殊協(xié)議 — MogileFS分布式文件存儲(chǔ)系統(tǒng)客戶端可以通過(guò)NFS或HTTP來(lái)和MogileFS的存儲(chǔ)節(jié)點(diǎn)來(lái)通信,但首先需要告知跟蹤器一下

MogileFS+Nginx的負(fù)載均衡部署方案

FastDFS架構(gòu)和原理

每個(gè)存儲(chǔ)服務(wù)器都需要定時(shí)將自身的信息上報(bào)給tracker，這些信息就包括了本地同步時(shí)間（即，同步
到的最新文件的時(shí)間戳）。而tracker根據(jù)各個(gè)存儲(chǔ)服務(wù)器的上報(bào)情況，就能夠知道剛剛上傳的文件，在該存儲(chǔ)組中是否已完成了同步

FastDFS的FID

? 精巧的FID：

FastDFS的特性

? FastDFS和MogileFS相比，沒(méi)有文件索引數(shù)據(jù)庫(kù)，C語(yǔ)義開(kāi)發(fā)，TCP Socket方式，整體性能更高

? 相對(duì)于MogileFS更為簡(jiǎn)單

? FastDFS的日志記錄非常詳細(xì)，便于排除問(wèn)題

? 安裝配置相對(duì)簡(jiǎn)單

? 目前只有一個(gè)人維護(hù)，是潛在的風(fēng)險(xiǎn)

TFS原理和架構(gòu)

?

TFS文件名的結(jié)構(gòu)

?

TFS的特性

? 總體參考HDFS架構(gòu)和原理，細(xì)節(jié)方面則考慮的是小文件(<1M)的優(yōu)化訪問(wèn)

? 在TFS的設(shè)計(jì)里面對(duì)應(yīng)著是一個(gè)block同時(shí)只能有一個(gè)寫(xiě)或者更新操作。

? 隨著寫(xiě)壓力的增加，讀文件的TPS會(huì)大幅下滑。

TFS的淘寶部署案例

? 淘寶網(wǎng)圖片存儲(chǔ)與處理系統(tǒng)全局拓?fù)?/strong>

圖片服務(wù)器前端還有一級(jí)和二級(jí)緩存服務(wù)器，盡量讓圖片在緩存中命中，最大程度的避免圖片熱點(diǎn)，實(shí)際上后端到達(dá)TFS的流量已經(jīng)非常離散和平均。

分布式系統(tǒng)之內(nèi)存

內(nèi)存計(jì)算

服務(wù)器內(nèi)存究竟能多大、能多貴、能多快

?

預(yù)計(jì)未來(lái)5到10年，關(guān)系數(shù)據(jù)庫(kù)將徹底消失，屆時(shí)所有的SAP產(chǎn)品都將使用HANA——2011年

? 內(nèi)存計(jì)算的模式將能幫助企業(yè)分析數(shù)據(jù)的速度提升10萬(wàn)倍（相比傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)）。這也就意味著以前需要數(shù)小時(shí)的分析現(xiàn)在幾秒鐘內(nèi)就可以完成?！?
? Bussmann所在的團(tuán)隊(duì)在2010年10月份的時(shí)候，通過(guò)概念證明SAP數(shù)據(jù)分析速度有望提升14000倍，以前需要花費(fèi)5小時(shí)分析處理完數(shù)據(jù)，現(xiàn)在僅需要1秒鐘則可以迅速完成。

SAP HANA超級(jí)內(nèi)存數(shù)據(jù)庫(kù)

內(nèi)存數(shù)據(jù)庫(kù).png)

分布式內(nèi)存整合計(jì)算的典型代表Pivotal GemFire

存整合計(jì)算的典型代表Pivotal GemFire.png)

Gemfire+12306讓中國(guó)人回家過(guò)年更方便？

部署數(shù)百個(gè)Pivotal Gemfire節(jié)點(diǎn)

百個(gè)Pivotal Gemfire節(jié)點(diǎn).png)

在2015年春運(yùn)購(gòu)票高峰之前，考慮到超大并發(fā)會(huì)造成網(wǎng)絡(luò)流量大以及阻塞的問(wèn)題，今年特別在阿里云建立一個(gè)數(shù)據(jù)中心，由阿里云提供“虛擬機(jī)”
的租賃服務(wù)，將基于Gemfire實(shí)現(xiàn)余票查詢功能的系統(tǒng)以及Web服務(wù)部署在這些虛擬機(jī)上，以分流“余票查詢”請(qǐng)求Gemfire+12306讓中國(guó)人回家過(guò)年更方便？部署數(shù)百個(gè)Pivotal Gemfire節(jié)點(diǎn)技術(shù)改造之后，在只采用10幾臺(tái)X86服務(wù)器實(shí)現(xiàn)了以前數(shù)十臺(tái)小型機(jī)的余票計(jì)算和查詢能力，單次
查詢的最長(zhǎng)時(shí)間從之前的15秒左右下降到0.2秒以下，縮短了75倍以上。 2012年春運(yùn)的極端高流量并發(fā)情況下，系統(tǒng)幾近癱瘓。而在改造之后，支持每秒上萬(wàn)次的并發(fā)查詢，高峰期間達(dá)到2.6萬(wàn)個(gè)查詢/秒吞吐量，整個(gè)系統(tǒng)效率顯著提高。舊系統(tǒng)每秒只能支持300-400個(gè)查詢/秒的吞吐量

內(nèi)存計(jì)算為什么這么快

? 當(dāng)前計(jì)算架構(gòu)的瓶頸在存儲(chǔ)，處理器的速度按照摩爾定律翻番增長(zhǎng)，而磁盤(pán)存儲(chǔ)的速度增長(zhǎng)很緩慢，由此造成巨大高達(dá)10萬(wàn)倍的差距

IMDG

? In Memory Data Grid（“內(nèi)存數(shù)據(jù)網(wǎng)格”）

? 首先自然是網(wǎng)格式分布式存儲(chǔ)

? 所有數(shù)據(jù)存于內(nèi)存（RAM）

? 存儲(chǔ)服務(wù)器數(shù)量可隨時(shí)增減

? 數(shù)據(jù)模型是非關(guān)系模型， 而是基于對(duì)象模型

? 在網(wǎng)格內(nèi)的某一臺(tái)存儲(chǔ)服務(wù)器的啟動(dòng)和關(guān)閉不會(huì)影響到網(wǎng)格內(nèi)的其他服務(wù)器

IMDG產(chǎn)品

Hazelcast & GridGain

Hazelcast是什么

? 2008年開(kāi)源項(xiàng)目，目標(biāo)是一個(gè)簡(jiǎn)單的分布式Java Map

? 目前的定位是Java分布式內(nèi)存網(wǎng)格

Hazelcast架構(gòu)

Hazelcast企業(yè)版的最強(qiáng)特性之堆外緩存

默認(rèn)512M OS的內(nèi)存池，分為默認(rèn)4M大小的管理單元，默認(rèn)采用ThreadLocal方式管理內(nèi)存單元。
存在用來(lái)存放Index、偏移量等Metadata信息的內(nèi)存單元， MetaData的占用空間默認(rèn)是12%

GridGain

? 作為另一款主流的開(kāi)源數(shù)據(jù)網(wǎng)格產(chǎn)品，GridGain是Hazelcast的強(qiáng)有力競(jìng)爭(zhēng)者。同樣提供了社區(qū)版和商業(yè)版，近日GridGain的開(kāi)源版本已經(jīng)進(jìn)入Apache孵化器項(xiàng)目Ignite(一款開(kāi)源的內(nèi)存計(jì)算(In-MemoryComputing)IMC中間件)，目前Apache正在遷移GridGain開(kāi)源版本的代碼到Ignite項(xiàng)目

? GridGain在開(kāi)源版本中就提供了堆外存儲(chǔ)功能， 當(dāng)堆和非堆內(nèi)存都不足時(shí)，還可以開(kāi)啟SWAP，將數(shù)據(jù)溢出到磁盤(pán)

? GridGain使用2PC(兩階段提交)協(xié)議實(shí)現(xiàn)分布式事務(wù)，事務(wù)級(jí)別支持三種事務(wù)隔離級(jí)別

? GGFS(GridGain In-Memory File System)， 類似Spark生態(tài)圈中的Tachyon， 能夠加速M(fèi)apReduce任務(wù)的執(zhí)行

? 流式數(shù)據(jù)/事件處理，可以作為CEP事件處理器

Apache Ignite項(xiàng)目憑借其業(yè)界領(lǐng)先的事務(wù)處理能力在新興的混合型的OLTP/ OLAP用例方面更勝一籌。特別是針對(duì)Hadoop， Apache Ignite將為現(xiàn)有的Map/Reduce， Pig或Hive作業(yè)提供即插即用式的加速，避免了推倒重來(lái)的做法
Apache Ignite成為未來(lái)的快速數(shù)據(jù)世界（Fast Data world），如同Hadoop是今天的大數(shù)據(jù)。

GridGain是一個(gè)融合了各種實(shí)時(shí)/內(nèi)存計(jì)算技術(shù)的平臺(tái)

Memcached

? Web系統(tǒng)中使用最為廣泛的分布式Key/value緩存中間件

Memcached最佳實(shí)踐

? 最適合存儲(chǔ)小數(shù)據(jù)，并且存儲(chǔ)的數(shù)據(jù)是大小一致的

? Memcached在很多時(shí)候都是作為數(shù)據(jù)庫(kù)前端cache使用

? 虛機(jī)上不適合部署Memcached

? 確保Memcached的內(nèi)存不會(huì)被Swap出去

? 不能便利所有數(shù)據(jù)，這將導(dǎo)致嚴(yán)重性能問(wèn)題

? Local Cache+ Memcached這種分層Cache還是很有價(jià)值

? Memcached啟動(dòng)預(yù)熱是一個(gè)好辦法

Redis

? 是Memcached的一個(gè)強(qiáng)有力的補(bǔ)充，同時(shí)也是一個(gè)有顯著
不同的新產(chǎn)品

? Redis擴(kuò)展了key-Value的范圍， Value可以是List， Set，Hashes， Sorted Set等數(shù)據(jù)結(jié)構(gòu)，同時(shí)增加了新指令針對(duì)這些數(shù)據(jù)結(jié)構(gòu)：如Set的union， List的pop等操作指令

? 比如Subscribe/publish命令，以支持發(fā)布/訂閱模式這樣的通知機(jī)制等等

? redis通過(guò)Multi / Watch /Exec等命令可以支持事務(wù)的概念，原子性的執(zhí)行一批命令。

? Redis 3.0開(kāi)始實(shí)現(xiàn)Cluster方案，但沒(méi)有采用一致性Hash

Redis事務(wù)問(wèn)題

?

redis 數(shù)據(jù)集結(jié)構(gòu)體 redisDB 和客戶端結(jié)構(gòu)體 redisClient
都會(huì)保存鍵值監(jiān)視的相關(guān)數(shù)據(jù)

一個(gè)Redis集群包含16384個(gè)哈希槽(hash slot)，數(shù)據(jù)庫(kù)中的每個(gè)鍵都屬于這個(gè)16384個(gè)哈希槽的其中一個(gè)，集群使用公式CRC16(key) % 16384來(lái)計(jì)算鍵key屬于哪個(gè)槽，其中CRC16(key)語(yǔ)句用于計(jì)算鍵key的CRC16校驗(yàn)和。

Redis vs Memcache

? 簡(jiǎn)單數(shù)據(jù)結(jié)構(gòu)下Memcache的多線程架構(gòu)有優(yōu)勢(shì)

? 僅僅從用做緩存的角度， Memcache還是無(wú)法被替代

? Redis具備向數(shù)據(jù)庫(kù)考慮的能力，但這些方面并沒(méi)有特別強(qiáng)的優(yōu)勢(shì)

? 不要求關(guān)系數(shù)據(jù)庫(kù)質(zhì)量級(jí)別的交易時(shí)， Redis可以取代一些特定場(chǎng)合的數(shù)據(jù)庫(kù)操作，比如秒殺這樣的系統(tǒng)

分布式系統(tǒng)存儲(chǔ)之基于內(nèi)存的兩表Join

A表為Person { id、 name }
B表為Order{id,orderId,amount（金額） }
關(guān)聯(lián)關(guān)系為order.orderid=person.id
求計(jì)算結(jié)果 select p.id,sum(o.amount),count(*) from person p ,order o where
order.orderid=person.id order by sum limit 1000
Person、 Order的數(shù)據(jù)分別存在CSV文件中 ，數(shù)量各自是1億、 10億，數(shù)據(jù)隨機(jī)制造，保證基本都有關(guān)聯(lián)
采用Hazelcast或GridGain的API完成，需要找出這兩個(gè)產(chǎn)品中最合適的API來(lái)完成Join、 Group、 Order等操作

分布式系統(tǒng)之分布式數(shù)據(jù)庫(kù)篇

分布式數(shù)據(jù)庫(kù)那點(diǎn)事

Oracle怎么實(shí)現(xiàn)分布式——Oracle Rac

現(xiàn)分布式——Oracle Rac.png)

?

? 1.多節(jié)點(diǎn)負(fù)載均衡;

? 2.通過(guò)并行執(zhí)行技術(shù)提高事務(wù)響應(yīng)時(shí)間—-通常用于數(shù)據(jù)分
析系統(tǒng);

? 3.通過(guò)橫向擴(kuò)展提高每秒交易數(shù)和連接數(shù) ;—-通常對(duì)于聯(lián)

機(jī)事務(wù)系統(tǒng);

? 4.節(jié)約硬件成本，可以用多個(gè)廉價(jià)PC服務(wù)器代替昂貴的小
型機(jī)或大型機(jī)，同時(shí)節(jié)約相應(yīng)維護(hù)成本;
? 5.可擴(kuò)展性好，可以方便添加刪除節(jié)點(diǎn)，擴(kuò)展硬件資源;

往往人們會(huì)認(rèn)為RAC有2個(gè)節(jié)點(diǎn)性能就會(huì)提升2倍，這是一個(gè)誤區(qū)，由于要保證數(shù)據(jù)的一致性往往性能會(huì)消耗在內(nèi)存間的數(shù)據(jù)塊相互拷貝和交叉上，因此不一定性能會(huì)好于單
節(jié)點(diǎn)，而且節(jié)點(diǎn)越多性能曲線就會(huì)下降越快

Oracle Rac的緩存融合技術(shù)（Cache fusion）

（Cache fusion）1.png)

1.保證緩存的一致性
2.減少共享磁盤(pán)IO的消耗
3.在RAC環(huán)境中多個(gè)節(jié)點(diǎn)保留了同一份的DB CACHE

（Cache fusion）2.png)

Oracle Rac雙節(jié)點(diǎn)HA的原理和流程

點(diǎn)HA的原理和流程.png)

在生產(chǎn)使用中，突然instance1 shutdown，那么在其上面沒(méi)有完成的事物如何處理呢。
? 1）當(dāng)實(shí)例1 crash后，實(shí)例2通過(guò)VIP就可以知道實(shí)例1已經(jīng)down了。
? 2）此時(shí)需要處理的有2部分?jǐn)?shù)據(jù)，一部分是commit的數(shù)據(jù)，一部分非commit數(shù)據(jù)
? 3）對(duì)于已經(jīng)commit寫(xiě)入redo日志但是還沒(méi)有來(lái)得及寫(xiě)入數(shù)據(jù)文件的記錄，實(shí)例2可以訪問(wèn)實(shí)例1的redo log并從最后一次check point之后的信息開(kāi)始實(shí)例恢復(fù)。把數(shù)據(jù)同步到最新?tīng)顟B(tài)。
? 4）對(duì)于沒(méi)有commit的數(shù)據(jù)利用undo舊映像進(jìn)行回滾事物。

MySQL Cluster

MySQL集群是一種在無(wú)共享架構(gòu)（SNA， Share NothingArchitecture）系統(tǒng)里應(yīng)用內(nèi)存數(shù)據(jù)庫(kù)集群的技術(shù)。這種無(wú)共享的架構(gòu)可以使得系統(tǒng)使用低廉的硬件獲取高的可擴(kuò)
展性。 mysql集群是一種分布式設(shè)計(jì)，目標(biāo)是要達(dá)到?jīng)]有任何單點(diǎn)故障點(diǎn)。因此，任何組成部分都應(yīng)該擁有自己的內(nèi)存和磁盤(pán)。


優(yōu)點(diǎn)：
? 1) 99.999 ％的高可用性
? 2) 快速的自動(dòng)失效切換
? 3) 靈活的分布式體系結(jié)構(gòu)，沒(méi)有單點(diǎn)故障
? 4) 高吞吐量和低延遲
? 5) 可擴(kuò)展性強(qiáng)，支持在線擴(kuò)容

VoltDB

VoltDB Streaming Data Pipeline


分布式數(shù)據(jù)庫(kù)熱點(diǎn)技術(shù)

數(shù)據(jù)分片與擴(kuò)容

CAP理論

CA，沒(méi)有擴(kuò)展性，如MySQL、 Oracle等
CP ，不能忍受節(jié)點(diǎn)宕機(jī)，有Oracle RAC、 Sybase集群等
AP，犧牲數(shù)據(jù)一致性，多數(shù)NoSQL系統(tǒng)采用

ACID vs BASE

BASE, 最終一致性這個(gè)理論由 B asically A vailable, S oftstate, E ventual consistency 組成。核心的概念是Eventual consistency ——最終一致性。它局部的放棄了 CAP 理論中的“完全”一致性，提供了更好的可用性和分區(qū)容忍度。RYW ( Read-Your-Writes ) consistencyRYW consistency 是最終一致性的補(bǔ)充，它保證業(yè)務(wù)在會(huì)話中一定能讀到上一次寫(xiě)入的數(shù)據(jù)

分布式事務(wù)——跨多個(gè)資源保證事務(wù)一致性

X/Open DTP模型



淘寶XA案例分析

事務(wù)補(bǔ)償機(jī)制——避免XA的低性能

跨節(jié)點(diǎn)查詢和Join

? 當(dāng)兩個(gè)表的數(shù)據(jù)分布在多個(gè)節(jié)點(diǎn)上時(shí)，這兩個(gè)表之間的Join就是一個(gè)困難的事情

Mycat入門(mén)

? 分布式數(shù)據(jù)庫(kù)中間件
? 基于阿里開(kāi)源的Cobar
? 被用于眾多互聯(lián)網(wǎng)項(xiàng)目
? 中國(guó)最活躍的Mycat社區(qū)

Mycat原理

Mycat全局表

Mycat ER分片


跨分片解決方案匯總

打造完美高可靠業(yè)務(wù)系統(tǒng)