資料庫集群好處

① 資料庫集群技術有哪些

資料庫集群技術
1)提高資料庫處理速度的技術
目前有四種提高資料庫處理速度的辦法：
◆ 提高磁碟速度：這包括RAID和其他磁碟文件分段的處理。主要的思想是提高磁碟的並發度（多個物理磁碟存放同一個文件）。盡管實現方法各不相同，但是它們最後的目的都是提供一個邏輯資料庫的存儲映象。我們要評價的六個系統都能有效地利用這些技術。由於ICX已經有最大的磁碟冗餘度，RAID 磁碟系統的設置應該側重於速度，而不是數據冗餘。這樣磁碟利用的效益就會提高。
◆ 分散數據的存放：主要思想是利用多個物理伺服器來存放數據集的不同部分（一個資料庫表格分散到多個伺服器或者每個伺服器分管幾個內容不同的表格）。這些辦法不但可以擴展數據集（數據集的可擴性），而且使得不同的伺服器進行並行計算成為可能。例如，對於ORACLE的RAC來講，由於它是共享磁碟的體系結構，你只需要簡單地增加一個伺服器節點，RAC就能自動地將這節點加入到它的集群服務中去。RAC會自動地將數據分配到這節點上，並且會將接下來的資料庫訪問自動分布到合適的物理伺服器上，而不用修改應用程序。對於UDB來講，因為它是非共享磁碟的體系結構，因此就必須手工修改數據的分區，MSCS和ASE也是同樣的情況。Mysql也需要手工分區，並且是這幾種資料庫中支持分區的自動化程度最低的，也就是說，應用程序需要自己負責資料庫的分布式訪問。不管數據存放是如何實現的，分布式存放數據的缺點是對資料庫的可用性有負面影響。任何一台伺服器的損壞都會影響整個系統的可用性。但是，這是迄今為止各大資料庫廠商能提供的業界最好的資料庫集群技術了。ICX是一種基於中間件的資料庫集群技術，它對客戶端和資料庫伺服器都是透明的。因此，ICX可以用來集群幾個資料庫集群（一個邏輯資料庫），也可以用於集群幾個物理資料庫伺服器（來增強一個分管關鍵數據的物理伺服器）。
◆ 對稱多處理器系統：此技術的思想是利用多處理機硬體技術來提高資料庫的處理速度。但是，除了ICX，所有其它的資料庫集群技術只支持單一的可修改的邏輯資料庫。絕大部分的資料庫事務處理是磁碟密集型的，純計算負荷很小的，對稱多處器技術在資料庫上的應用的實際收益是很有限的。這也說明了為什麼實際應用中最多隻用了四個CPU的原因。所有的基於資料庫引擎的集群都支持這個技術，ICX對SMP技術是中性的，因為它能把多個資料庫伺服器集合在一起構成一個集群，也能將多個現存的資料庫集群集合在一起，構成集群的集群。
◆ 交易處理負載均衡：此技術的思想是在保持數據集內容同步的前提下，將只讀操作分布到多個獨立的伺服器上運行。因為絕大多數的資料庫操作是瀏覽和查詢,，如果我們能擁有多個內容同步的資料庫伺服器，交易負載均衡就具有最大的潛力（可以遠遠大於上面敘述的最多達四個處理器的對稱多處理器系統）來提高資料庫的處理速度，同時會具有非常高的數據可用性（真正達到5個9，即99.999%）。所有基於資料庫引擎的集群系統都只支持一個邏輯資料庫映象和一個邏輯或物理的備份。這個備份的主要目的是預防數據災難。因此，備份里的數據只能通過復制機制來更新，應用程序是不能直接更新它的。利用備份數據進行交易負載均衡只適用於一些非常有限的應用，例如報表統計、數據挖掘以及其它非關鍵業務的應用。只有ICX能夠做到同步復制多個資料庫伺服器從而達到在保持數據一直性前提下的真正的負載平衡。
上述所有技術在實際部署系統的時候可以混合使用以達到最佳效果。
2）提高資料庫可用性的技術
根據物理法則，提高冗餘度是提高資料庫可用性的唯一途徑。
提高資料庫冗餘度大致有四種方法：
◆ 硬體級的冗餘：主要思想是讓多處理機同時執行同樣的任務用以屏蔽瞬時和永久的硬體錯誤。有兩種具體的實現方法：構造特殊的冗餘處理機和使用多個獨立的資料庫伺服器。冗餘處理機的造價昂貴，效益很低。實際應用日漸減少。基於資料庫的集群系統都是用多個獨立的資料庫伺服器來實現一個邏輯資料庫，在任意瞬間，每台處理器運行的都是不同的任務。這種系統可以屏蔽單個或多個伺服器的損壞，但是因為沒有處理的冗餘度，每次恢復的時間比較長，它們需要把被損壞的服務進程在不同的伺服器上從新建立起來。ICX讓多個獨立的資料庫伺服器作同樣的處理。發現處理器問題時的切換不需要重建進程的狀態，所以故障屏蔽是極快的。
◆ 通訊鏈路級的冗餘：冗餘的通訊鏈路可以屏蔽瞬時和永久的通訊鏈路級的錯誤。基於資料庫引擎的集群系統有兩種結構：共享磁碟和獨立磁碟。RAC, MSCS 和 MySQL CS可以認為是共享磁碟的集群系統。UDB和ASE 是獨立磁碟的集群系統。共享磁碟集群系統對網路系統的要求很高，所以通訊的冗餘度最小。獨立磁碟集群系統可以把磁碟系統獨立管理，通訊冗餘度較高。 ICX的通訊鏈路級的冗餘度最高，因為它使用的是多個獨立的資料庫伺服器和獨立的磁碟系統。 ICX也可以用於共享磁碟系統。 但是冗餘度會相應降低。
◆ 軟體級的冗餘：由於現代操作系統和資料庫引擎的高度並發性，由競爭條件、死鎖、以及時間相關引發的錯誤占據了非正常停機服務的絕大多數原因。採用多個冗餘的運行資料庫進程能屏蔽瞬時和永久的軟體錯誤。基於資料庫引擎的集群系統都用多個處理器來實現一個邏輯資料庫，它們只能提供部分軟體冗餘，因為每一瞬間每個處理器執行的都是不同的任務。只有ICX可以提供最大程度的軟體級冗餘。
◆ 數據冗餘：有兩類冗餘數據集。
被動更新數據集：所有目前的數據復制技術(同步或非同步)，例如磁碟鏡像（EMC的TimeFinder系列）、資料庫文件復制（如DoubleTake, Veritas and Legato）以及資料庫廠商自帶的資料庫備份工具都只能產生被動復制數據集。通常，為了實現復制功能，需要消耗掉主伺服器5%（非同步）到30%（同步）的處理能力。被動更新的數據一般只用於災難恢復.被動更新數據集還有兩個致命的問題：一旦主處理機故障造成數據損壞，被動更新的數據集也會被破壞。另外，和主動更新系統相比，被動更新系統對數據網路的帶寬要求更高。這是因為它缺少交易的信息，很多數據復制是盲目的。
主動更新數據集：這種數據集需要一台（或多台）獨立的備份資料庫伺服器來管理，由於這種數據集及時可用，它可以有多種用途，例如報表生成，數據挖掘，災難恢復甚至低質量負載均衡。 同樣地，這里也有同步和非同步兩種技術。
◆ 非同步主動復制數據集：這種技術是先把事務處理交給主伺服器來完成，然後這些事務處理再被串列地交給備份伺服器以執行同樣的操作來保證數據的一致性。這種技術生成的數據集和主數據集有一個時間差，所以僅適用於災難恢復、數據挖掘、報表統計以及有限的在線應用。所有的商用資料庫都支持非同步主動復制技術。這種辦法的難度在於復制隊列的管理上，這個隊列是用來屏蔽主伺服器和備份伺服器之間的速度差異的。因為主伺服器可以盡可能地利用所有軟硬體的並發性來處理並發的事務，而備份伺服器只能串列地復制，在高負荷事務處理的情況下，復制隊列經常可能溢出。因為沒有任何辦法來控制事務處理請求的速度，在高負荷事務處理的情況下，復制隊列只能經常性地重建。因為所有現代資料庫系統都支持熱備份和LOG SHIPPING。通過精心策劃，應該可以實現不關閉主伺服器而重建隊列。ICX也支持非同步主動復制. ICX的復制隊列的重建是通過ICX的自動數據同步軟體來完成的，所以不需要人工操作。
◆ 同步主動復制數據集：這種技術要求所有的並發事務處理在所有的資料庫伺服器上同時完成。一個直接的好處就是沒有了隊列的管理問題，同時也可以通過負載均衡實現更高的性能和更高的可用性。這種技術也有兩種完全不同的實現方法：完全串列化和動態串列化。完全串列化的事務處理來自於主資料庫的事務處理引擎，RAC, UDB, MSCS (SQL Server 2005) 和 ASE是用完全串列化並結合兩階段提交協議來實現的，這種設計的目標就是為了獲得一份可用於快速災難恢復的數據集。這種系統有兩個關鍵的問題。第一，兩階段提交協議是一種「ALL OR NOTHING」的協議。仔細研究兩階段提交協議後就能發現，為了獲取這備份數據集，事務處理的可用性會降低一半。第二，完全串列化的做法又引進了主-從資料庫伺服器速度不匹配的問題。強制同步造成整個系統的速度被降低到完全串列化的水平。相反，ICX-UDS採用了動態串列復制引擎。這設計可以充分利用多個獨立資料庫的處理能力。ICX避免了使用兩階段提交協議，因此一個事務處理只有在集群中的所有伺服器全都同時崩潰的情況下才會回滾。
為了防災，必須使用遠程網路。 所以我們在這里討論遠程數據復制的辦法。這里大概有四種辦法。
◆ 動態遠程非同步復制：這種辦法是指主伺服器通過遠程網串列地把交易復制到備份伺服器上。由於主-副之間的速度不匹配，隊列管理的問題就很突出。 由於遠程網的速度一般都比較慢，隊列溢出的概率大大增加。所有的集群系統都支持這種復制辦法，只是隊列管理的辦法不同而已。DM，FM和RAID都不能支持這種辦法。RAID只能在區域網內工作。
◆ 動態遠程同步復制.：這種辦法是指主伺服器通過遠程網並行地把交易復制備份伺服器上。只有ICX 具有這種能力。
◆ 靜態遠程非同步復制.：這種辦法是指通過遠程網把數據串列地復制（不通過資料庫伺服器）到異地。DM和FM支持這種復制辦法。因為串列處理和隊列管理的關系，這對於處理量大的系統不適用。但是這種復制辦法對應用是透明的，所有集群系統都可採用.
◆ 靜態遠程同步復制.：這種辦法也是指通過遠程網把數據串列地復制（不通過資料庫伺服器）到異地。不同的是，這里沒有隊列管理。取代隊列管理的是發送端的一個新的協議：每次發送都要等接受端確認復製成功。否則回滾。DM和FM都支持這種復制辦法。這種辦法只能在短距離范圍內工作， 大約5 英里光纖的樣子。如果超出這個距離范圍的話，顯然事務處理回滾的概率就會很高。但是這種復制辦法對應用是透明的，所有集群系統都可採用。
3）提高資料庫安全和數據集可擴展的技術
在提高資料庫安全性和數據集可擴性這兩方面，可以創新的空間是很小的。資料庫最常見的安全辦法是口令保護，要麼是分布式的，要麼是集中式的。在資料庫前面增加防火牆會增加額外的延遲，因此，盡管許多安全侵犯事件是來自於公司內部，但是資料庫防火牆還是很少被採用。如果資料庫集群技術是基於中間件技術實現的，就有可能在不增加額外延遲的情況下 ，在數據經過的路徑上實現防火牆功能。ICX完全實現了這種思想。
資料庫數據集的可擴性只能通過將數據分布到多個獨立的物理伺服器上來實現。為了彌補可用性的損失，ICX能被用來提高整個邏輯資料庫或者部分重要伺服器的處理速度，可用性和安全性。

② 淺談資料庫集群軟體優缺點有哪些

集群（Cluster）是由兩台或多台節點機（伺服器）構成的一種鬆散耦合的計算節點集合，為用戶提
供網路服務或應用程序(包括資料庫、Web服務和文件服務等)的單一客戶視圖，同時提供接近容錯機的故
障恢復能力。集群系統一般通過兩台或多台節點伺服器系統通過相應的硬體及軟體互連，每個群集節點都
是運行其自己進程的獨立伺服器。這些進程可以彼此通信，對網路客戶機來說就像是形成了一個單一系統，
協同起來向用戶提供應用程序、系統資源和數據。除了作為單一系統提供服務，集群系統還具有恢復服務
器級故障的能力。集群系統還可通過在集群中繼續增加伺服器的方式，從內部增加伺服器的處理能力，並
通過系統級的冗餘提供固有的可靠性和可用性。
二、集群的分類：
1、高性能計算科學集群：
以解決復雜的科學計算問題為目的的IA集群系統。是並行計算的基礎，它可以不使用專門的由十至
上萬個獨立處理器組成的並行超級計算機，而是採用通過高速連接來鏈接的一組1/2/4 CPU的IA伺服器，
並且在公共消息傳遞層上進行通信以運行並行應用程序。這樣的計算集群，其處理能力與真正超級並行
機相等，並且具有優良的性價比。
2、負載均衡集群：
負載均衡集群為企業需求提供更實用的系統。該系統使各節點的負載流量可以在伺服器集群中盡可
能平均合理地分攤處理。該負載需要均衡計算的應用程序處理埠負載或網路流量負載。這樣的系統非
常適合於運行同一組應用程序的大量用戶。每個節點都可以處理一部分負載，並且可以在節點之間動態
分配負載，以實現平衡。對於網路流量也如此。通常，網路伺服器應用程序接受了大量入網流量，無法
迅速處理，這就需要將流量發送給在其它節點。負載均衡演算法還可以根據每個節點不同的可用資源或網
絡的特殊環境來進行優化。

③ 如何保證資料庫集群中id的唯一性，假設每秒鍾並發20萬次

用雪花演算法的工具類,1秒內可以生成26萬不重復的值,資料庫的主鍵不要自增,手動設置

java">packageentity;

importjava.lang.management.ManagementFactory;
importjava.net.InetAddress;
importjava.net.NetworkInterface;

/**
*<p>名稱：IdWorker.java</p>
*<p>描述：分布式自增長ID</p>
*<pre>
*Twitter的SnowflakeJAVA實現方案
*</pre>
*核心代碼為其IdWorker這個類實現，其原理結構如下，我分別用一個0表示一位，用—分割開部分的作用：
*1||0------00000---00000---000000000000
*在上面的字元串中，第一位為未使用（實際上也可作為long的符號位），接下來的41位為毫秒級時間，
*然後5位datacenter標識位，5位機器ID（並不算標識符，實際是為線程標識），
*然後12位該毫秒內的當前毫秒內的計數，加起來剛好64位，為一個Long型。
*這樣的好處是，整體上按照時間自增排序，並且整個分布式系統內不會產生ID碰撞（由datacenter和機器ID作區分），
*並且效率較高，經測試，snowflake每秒能夠產生26萬ID左右，完全滿足需要。
*<p>
*64位ID(42(毫秒)+5(機器ID)+5(業務編碼)+12(重復累加))
*
*@authorPolim
*/
publicclassIdWorker{
//時間起始標記點，作為基準，一般取系統的最近時間（一旦確定不能變動）
privatefinalstaticlongtwepoch=1288834974657L;
//機器標識位數
=5L;
//數據中心標識位數
=5L;
//機器ID最大值
=-1L^(-1L<<workerIdBits);
//數據中心ID最大值
=-1L^(-1L<<datacenterIdBits);
//毫秒內自增位
=12L;
//機器ID偏左移12位
=sequenceBits;
//數據中心ID左移17位
=sequenceBits+workerIdBits;
//時間毫秒左移22位
=sequenceBits+workerIdBits+datacenterIdBits;

=-1L^(-1L<<sequenceBits);
/*上次生產id時間戳*/
=-1L;
//0，並發控制
privatelongsequence=0L;

privatefinallongworkerId;
//數據標識id部分
privatefinallongdatacenterId;

publicIdWorker(){
this.datacenterId=getDatacenterId(maxDatacenterId);
this.workerId=getMaxWorkerId(datacenterId,maxWorkerId);
}
/**
*@paramworkerId
*工作機器ID
*@paramdatacenterId
*序列號
*/
publicIdWorker(longworkerId,longdatacenterId){
if(workerId>maxWorkerId||workerId<0){
(String.format("workerIdcan'tbegreaterthan%dorlessthan0",maxWorkerId));
}
if(datacenterId>maxDatacenterId||datacenterId<0){
(String.format("datacenterIdcan'tbegreaterthan%dorlessthan0",maxDatacenterId));
}
this.workerId=workerId;
this.datacenterId=datacenterId;
}
/**
*獲取下一個ID
*
*@return
*/
publicsynchronizedlongnextId(){
longtimestamp=timeGen();
if(timestamp<lastTimestamp){
thrownewRuntimeException(String.format("Clockmovedbackwards.Refusingtogenerateidfor%dmilliseconds",lastTimestamp-timestamp));
}

if(lastTimestamp==timestamp){
//當前毫秒內，則+1
sequence=(sequence+1)&sequenceMask;
if(sequence==0){
//當前毫秒內計數滿了，則等待下一秒
timestamp=tilNextMillis(lastTimestamp);
}
}else{
sequence=0L;
}
lastTimestamp=timestamp;
//ID偏移組合生成最終的ID，並返回ID
longnextId=((timestamp-twepoch)<<timestampLeftShift)
|(datacenterId<<datacenterIdShift)
|(workerId<<workerIdShift)|sequence;

returnnextId;
}

privatelongtilNextMillis(finallonglastTimestamp){
longtimestamp=this.timeGen();
while(timestamp<=lastTimestamp){
timestamp=this.timeGen();
}
returntimestamp;
}

privatelongtimeGen(){
returnSystem.currentTimeMillis();
}

/**
*<p>
*獲取maxWorkerId
*</p>
*/
(longdatacenterId,longmaxWorkerId){
StringBuffermpid=newStringBuffer();
mpid.append(datacenterId);
Stringname=ManagementFactory.getRuntimeMXBean().getName();
if(!name.isEmpty()){
/*
*GETjvmPid
*/
mpid.append(name.split("@")[0]);
}
/*
*MAC+PID的hashcode獲取16個低位
*/
return(mpid.toString().hashCode()&0xffff)%(maxWorkerId+1);
}

/**
*<p>
*數據標識id部分
*</p>
*/
(longmaxDatacenterId){
longid=0L;
try{
InetAddressip=InetAddress.getLocalHost();
NetworkInterfacenetwork=NetworkInterface.getByInetAddress(ip);
if(network==null){
id=1L;
}else{
byte[]mac=network.getHardwareAddress();
id=((0x000000FF&(long)mac[mac.length-1])
|(0x0000FF00&(((long)mac[mac.length-2])<<8)))>>6;
id=id%(maxDatacenterId+1);
}
}catch(Exceptione){
System.out.println("getDatacenterId:"+e.getMessage());
}
returnid;
}


publicstaticvoidmain(String[]args){
//推特26萬個不重復的ID
IdWorkeridWorker=newIdWorker(0,0);
for(inti=0;i<2600;i++){
System.out.println(idWorker.nextId());
}
}

}

④ 阿里雲分布式資料庫服務DRDS誰使用過 簡單講講！

淘寶開源的TDDL和cobar的結合，放到了阿里雲上就是DRDS，是商品，服務，可以購買使用的。可以在阿里雲官網上注冊免費試用。

=====================================================
隨著互聯網時代的到來，計算機要管理的數據量呈指數級別地飛速上漲，而我們卻完全無法對用戶數做出准確預估。我們的系統所需要支持的用戶數，很可能在短短的一個月內突然爆發式地增長幾千倍，數據也很可能快速地從原來的幾百GB飛速上漲到了幾百個TB。如果在這爆發的關鍵時刻，系統不穩定或無法訪問，那麼對於業務將會是毀滅性的打擊。
伴隨著這種對於系統性能、成本以及擴展性的新需要，以HBase、MongoDB為代表的NoSQL資料庫和以阿里DRDS、VoltDB、ScaleBase為代表的分布式NewSQL資料庫如雨後春筍般不斷涌現出來。
本文將會介紹阿里DRDS的技術理念、發展歷程、技術特性等內容。
DRDS設計理念
從20世紀70年代關系資料庫創立開始，其實大家在資料庫上的追求就從未發生過變化：更快的存取數據，可以按需擴縮以承載更大的訪問量和更大的數據量，開發容易，硬體成本低，我們可以把這叫做資料庫領域的聖杯。
為了支撐更大的訪問量和數據量，我們必然需要分布式資料庫系統，然而分布式系統又必然會面對強一致性所帶來的延遲提高的問題，因為網路通信本身比單機內通信代價高很多，這種通信的代價就會直接增加系統單次提交的延遲。延遲提高會導致資料庫鎖持有時間變長，使得高沖突條件下分布式事務的性能不升反降（這個具體可以了解一下Amdahl定律），甚至性能距離單機資料庫都還有明顯的差距。
從上面的說明，我們可以發現，問題的關鍵並不是分布式事務做不出來，而是做出來了卻因為性能太差而沒有什麼卵用。資料庫領域的高手們努力了40年，但至今仍然沒有人能夠很好地解決這個問題，Google Spanner的開發負責人就經常在他的Blog上談論延遲的問題，相信也是飽受這個問題的困擾。
面對這個難題，傳統的關系資料庫選擇了放棄分布式的方案，因為在20世紀70~80年代，我們的資料庫主要被用來處理企業內的各類數據，面對的用戶不過幾千人，而數據量最多也就是TB級別。用單台機器來處理事務，用個磁碟陣列處理一下磁碟容量不夠的問題，基本上就能解決一切問題了。
然而，信息化和互聯網的浪潮改變了這一切，我們突然發現，我們服務的對象發生了根本性變化，從原來的幾千人，變成了現在的幾億人，數據量也從TB級別到了PB級別甚至更多。存在單點的單機系統無論如何努力，都會面對系統處理能力的天花板。原來的這條路，看起來是走不下去了，我們必須想辦法換一條路來走。
可是，分布式資料庫所面對的強一致性難題卻像一座高山，人們努力了無數個日日夜夜，但能翻越這座山的日子看來仍然遙遙無期。
於是，有一群人認為，強一致性這件事看來不怎麼靠譜，那徹底繞開這個問題是不是個更好的選擇？他們發現確實有那麼一些場景是不需要強一致事務的，甚至連SQL都可以不要，最典型的就是日誌流水的記錄與分析這類場景。而去掉了事務和SQL，介面簡單了，性能就更容易得到提升，擴展性也更容易實現，這就是NoSQL系統的起源。
雖然NoSQL解決了性能和擴展性問題，但這種繞開問題的方法給用戶帶來了很多困擾，系統的開發成本也大大提升。這時候就有另外一群人，他們覺得用戶需要SQL，覺得用戶也需要事務，問題的關鍵在於我們要努力地往聖杯的方向不斷前進。在保持系統的擴展性和性能的前提下，付出盡可能小的代價來滿足業務對資料庫的需要。這就是NewSQL這個理念的由來。
DRDS也是一個NewSQL的系統，它與ScaleBase、VoltDB等系統類似，都希望能夠找到一條既能保持系統的高擴展性和高性能，又能盡可能保持傳統資料庫的ACID事務和SQL特性的分布式資料庫系統。
DRDS發展歷程
在一開始，TDDL的主要功能就是做資料庫切分，一個或一組SQL請求提交到TDDL，TDDL進行規則運算後得知SQL應該被分發到哪個機器，直接將SQL轉發到對應機器即可（如圖1）。

圖1 TDDL資料庫切分
開始的時候，這種簡單的路由策略能夠滿足用戶的需要，我們開始的那些應用，就是通過這樣非常簡單的方式完成了他所有的應用請求。我們也認為，這種方案簡單可靠，已經足夠好用了。
然而，當我們服務的應用從十幾個增長到幾百個的時候，大量的中小應用加入，大家紛紛表示，原來的方案限制太大，很多應用其實只是希望做個讀寫分離，希望能有更好的SQL兼容性。
於是，我們做了第一次重大升級，在這次升級里，我們提出了一個重要的概念就是三層架構，Matrix對應資料庫切分場景，對SQL有一定限制，Group對應讀寫分離和高可用場景，對SQL幾乎沒有限制。如圖2所示。

圖2 資料庫升級為三層架構
這種做法立刻得到了大家的認可，TDDL所提供的讀寫分離、分庫分表等核心功能，也成為了阿里集團內資料庫領域的標配組件，在阿里的幾乎所有應用上都有應用。最為難得的是，這些功能從上線後，到現在已經經歷了多年雙11的嚴酷考驗，從未出現過嚴重故障（p0、p1級別故障屬於嚴重故障）。資料庫體系作為整個應用系統的重中之重，能做到這件事，真是非常不容易。
隨著核心功能的穩定，自2010年開始，我們集中全部精力開始關注TDDL後端運維系統的完善與改進性工作。在DBA團隊的給力配合下，圍繞著TDDL，我們成功做到了在線數據動態擴縮、非同步索引等關鍵特徵，同時也比較成功地構建了一整套分布式資料庫服務管控體系，用戶基本上可以完全自助地完成整套資料庫環境的搭建與初始化工作。
大概是2012年，我們在阿里雲團隊的支持下，開始嘗試將TDDL這套體系輸出到阿里雲上，也有了個新的名字：阿里分布式資料庫服務（DRDS），希望能夠用我們的技術服務好更多的人。
不過當我們滿懷自信地把自己的軟體拿到雲上的時候，卻發現我們的軟體距離用戶的要求差距很大。在內部因為有DBA的同學們幫助進行SQL review，所以SQL的復雜度都是可控的。然而到了雲上，看了各種渠道提過來的兼容性需求，我們經常是不自覺地發出這樣的感嘆：「啊？原來這種語法MySQL也是可以支持的？」
於是，我們又進行了架構升級，這次是以兼容性為核心目標的系統升級工作，希望能夠在分布式場景下支持各類復雜的SQL，同時也將阿里這么多年來在分布式事務上的積累都帶到了DRDS裡面。
這次架構升級，我們的投入史無前例，用了三年多才將整個系統落地完成。我們先在內部以我們自己的業務作為首批用戶上線，經過了內部幾百個應用的嚴酷考驗以後，我們才敢拿到雲上，給到我們的最終用戶使用。
目前，我們正在將TDDL中更多的積累輸出到雲上，同時也努力優化我們的用戶界面。PS：其實用戶界面優化對我們這種專注於高性能後端技術的團隊來說，才是最大的技術挑戰，連我也去學了AngularJS，參與了用戶UI編。
DRDS主要功能介紹
發展歷史看完了，下面就由我來介紹一下目前我們已經輸出到雲上的主要功能。
【分布式SQL執行引擎】
分布式SQL引擎主要的目的，就是實現與單機資料庫SQL引擎的完全兼容。目前我們的SQL引擎能夠做到與MySQL的SQL引擎全兼容，包括各類join和各類復雜函數等。他主要包含SQL解析、優化、執行和合並四個流程，如圖3中綠色部分。

圖3 SQL引擎實現的主要流程
雖然SQL是兼容的，但是分布式SQL執行演算法與單機SQL的執行演算法卻完全不同，原因也很簡單，網路通信的延遲比單機內通信的延遲大得多。舉個例子說明一下，我們有份文件要從一張紙A上謄寫到另外一張紙B上，單機系統就好比兩張紙都在同一個辦公室里，而分布式資料庫則就像是一張紙在北京，一張紙在杭州。
自然地，如果兩張紙在同一個辦公室，因為傳輸距離近，逐行謄寫的效率是可以接受的。而如果距離是北京到杭州，用逐行謄寫的方式，就立刻顯得代價太高了，我們總不能看一行，就打個「飛的」去杭州寫下來吧。在這種情況下，還是把紙A上的信息拍個照片，【一整批的】帶到杭州去處理，明顯更簡單一些。這就是分布式資料庫特別強調吞吐調優的原因，只要是涉及到跨機的所有查詢，都必須盡可能的積攢一批後一起發送，以減少系統延遲提高帶來的不良影響。
【按需資料庫集群平滑擴縮】
DRDS允許應用按需將新的單機存儲加入或移出集群，DRDS則能夠保證應用在遷移流程中實現不停機擴容縮容。

圖4 DRDS按需進行平滑擴縮
在內部的資料庫使用實踐中，這個功能的一個最重要應用場景就是雙11了。在雙11之前，我們會將大批的機器加入到我們的資料庫集群中，抗過了雙11，這批機器就會下線。
當DRDS來到雲上，我們發現雙11其實不僅僅隻影響阿里內部的系統。在下游的各類電商輔助性系統其實也面對巨大壓力。在雙11前5天，網聚寶的熊總就找到我說，擔心撐不過雙11的流量，怕系統掛。於是我們就給他介紹了這個自動擴容的功能怎麼用，他買了一個月的資料庫，掛接在DRDS上。資料庫能力立刻翻倍，輕松抗過了雙11，也算是我印象比較深刻的一個案例了。
因為我們完全無法預測在什麼時間點系統會有爆發性的增長，而如果在這時候系統因為技術原因不能使用，就會給整個業務帶來毀滅性的影響，風口一旦錯過，就追悔莫及了。我想這就是雲計算特別強調可擴展能力的原因吧。
【小表廣播】
小表廣播也是我們在分布式資料庫領域內最常用的工具之一，他的核心目的其實都是一個——盡可能讓查詢只發生在單機。
讓我們用一個例子來說明，小表廣播的一般使用場景。

圖5 小表廣播場景
圖5中，如果我想知道買家id等於0的用戶在商城裡面買了哪些商品，我們一般會先將這兩個表join起來，然後再用where平台名=」商城」 and buyerID = 0找到符合要求的數據。然而這種join的方式，會導致大量的針對左表的網路I/O。如果要取出的數據量比較大，系統延遲會明顯上升。
這時候，為了提升性能，我們就必須要減少跨機join的網路代價。我們比較推薦應用做如下處理，將左表復制到右表的每一個庫上。這樣，join操作就由分布式join一下變回到本地join，系統的性能就有很大的提升了，如圖6所示。

圖6
【分布式事務套件】
在阿里巴巴的業務體系中存在非常多需要事務類的場景，下單減庫存，賬務，都是事務場景最集中的部分。
而我們處理事務的方法卻和傳統應用處理事務的方案不大一樣，我們非常強調事務的最終一致性和非同步化。利用這種方式，能夠極大地降低分布式系統中鎖持有的時間，從而極大地提升系統性能。

圖7 DRDS分布式事務解決套件
這種處理機制，是我們分布式事務能夠以極低成本大量運行的最核心法門。在DRDS平台內，我們將這些方案產品化，為了DRDS的分布式事務解決套件。
利用他們，能夠讓你以比較低的成本，實現低延遲，高吞吐的分布式事務場景。
DRDS的未來
阿里分布式資料庫服務DRDS上線至今，大家對這款產品的熱情超出了我們的預期，短短半年內已經有幾千個申請。
盡管還在公測期，但是大家就已經把關繫到身家性命的寶貴在線數據業務放到了DRDS上，我能夠感受到這份沉甸甸的信賴，也不想辜負這份信賴。
經過阿里內部幾千個應用的不斷歷練，DRDS已經積累出一套強大的分布式SQL執行引擎和和一整套分布式事務套件。
我也相信，這些積累能夠讓用戶在基本保持單機資料庫的使用習慣的前提下，享受到分布式資料庫高性能可擴展的好處。
在平時的DRDS支持過程中，我面對最多的問題就是，DRDS能不能夠在不改變任何原有業務邏輯和代碼的前提下，實現可自由伸縮和擴展呢？十分可惜的是，關系資料庫發展至今，還沒有找到既能保留傳統資料庫一切特性，又能實現高性能可擴展資料庫的方法。
然而，雖不能至，吾心嚮往之！我們會以「可擴展，高性能」為產品核心，堅定地走在追尋聖杯的路上，並堅信最終我們一定能夠找尋到它神聖的所在。
作者簡介：王晶昱，花名沈詢，阿里巴巴資深技術專家。目前主要負責阿里的分布式資料庫DRDS（TDDL）和阿里的分布式消息服務ONS（RocketMQ/Notify）兩個系統。

⑤ php 是什麼是什麼

PHP，是英文超文本預處理語言Hypertext Preprocessor的縮寫。
一、概念。
PHP 是一種 HTML 內嵌式的語言，是一種在伺服器端執行的嵌入HTML文檔的腳本語言，語言的風格有類似於C語言，被廣泛地運用。
二、解析。
PHP 獨特的語法混合了C、Java、Perl以及PHP自創的語法。它可以比CGI或者Perl更快速地執行動態網頁。用PHP做出的動態頁面與其他的編程語言相比，PHP是將程序嵌入到HTML文檔中去執行，執行效率比完全生成HTML標記的CGI要高許多；PHP還可以執行編譯後代碼，編譯可以達到加密和優化代碼運行，使代碼運行更快。
三、特點。
1、PHP 獨特的語法混合了 C、Java、Perl 以及 PHP 自創新的語法。
2、PHP安裝它可以比 CGI或者Perl更快速的執行動態網頁。用PHP做出的動態頁面與其他的編程語言相比。
3、PHP是將程序嵌入到HTML文檔中去執行，執行效率比完全生成htmL標記的CGI要高許多； PHP具有非常強大的功能，所有的CGI的功能PHP都能實現。
4、支持幾乎所有流行的資料庫以及操作系統。最重要的是PHP可以用C、C++進行程序的擴展。

⑥ oracle資料庫的優勢有哪些

oracle 優勢很多，大部分銀行保險電信大部分是用oracle處理的
優勢主要 有
1、處理速度快，非常快
2、安全級別高。支持快閃以及完美的恢復，即使硬體壞了 也可以恢復到故障發前的1s
3、幾台資料庫做集群資料庫，可以做到幾秒s以內故障轉移，而且數據物理完全一致，現在集群一直是最優秀的解決方案，對於銀行保險沒有其他太多的選項{數據不丟，快速切換，負載均衡}
4、網格控制，以及 數據倉庫方面 也非常強大
對了免費 以及 開源的 言論 都是錯誤的。。。oracle產品及服務都是付費的，而且價格不菲。比其他資料庫要貴，物有所值。oracle不是開源的。不過可以在redhat 或者其他開源操作系統上安裝。
mysql在sun沒被oracle收購是開源的,免費的,之後oracle公司打算 把mysql打造成不開源，收費模式的。

⑦ 如何在虛擬機中創建共享磁碟用來做資料庫集群

一、使用目的a. 模擬現有集群中的環境，快速定位故障原因，處理運維集群故障。b. 在虛擬環境中模擬集群，對初學者的學習集群知識有很大的幫助。c. 對想研究集群技術的人來講，這是一個很好的幫助工具。 二、技術背景1、 iSCSI基礎iSCSI是一種新興的存儲協議，全稱是Internet SCSI，和傳統的SCSI設備不同，iSCSI存儲設備使用IP網路來進行數據的傳輸。這樣的好處就是網路中的任何一台主機都可以使用iSCSI存儲設備作為自己的存儲設備，缺點就是比較依賴IP網路的傳輸性能，所以通常情況下推薦在1000M網路中使用iSCSI存儲設備。首先介紹一下iSCSI存儲中所使用的組件。iSCSI存儲使用以下三個組件：發起方（Initiator）：安裝在需要使用iSCSI存儲設備的主機上的客戶端軟體，提供連接iSCSI存儲設備並進行數據讀寫的驅動程序；目標（Target）：iSCSI存儲設備，提供數據存儲服務；入口（Portal）：由IP地址和埠（默認為TCP 3260）組成，發起方通過入口來連接目標。連接過程：發起方通過入口來連接目標，目標通常通過發起方的IQN（發起方完全限定名稱）來識別發起方的連接。此外，你還可以配置CHAP身份驗證和IPSec加密，通常情況下，不推薦使用IPSec加密，更佔用伺服器性能。 從實驗的目的簡單來講，就是在一台伺服器上用ISCSI工具建立一個共享存儲，其他的客戶端通過ISCSI客戶端工具來建立和伺服器端的連接，這樣，所有的客戶端就共享這一個存儲，從而達到我們實驗的目的（因為建立資料庫集群需要共享磁碟做支撐） 三、工具介紹1、 建立共享存儲磁碟的工具。主要介紹兩種在伺服器中創建共享磁碟的工具Wintarget和StarWind。其中Wintarget是微軟公司研發的，而StarWind是由Rocket Division Software LTD研發的。2、 客戶端連接工具主要是Microsoft iSCSI Initiator，簡稱Initiator。3、 工具使用組合a.Wintarget+ Initiator組合b.StarWind+ Initiator 四、操作步驟1、使用組合a的操作指南在這里使用兩台虛擬機來做實驗，一個作為提供共享存儲的服務端，IP地址：192.168.200.191，一個作為連接存儲的客戶端，IP地址：192.168.200.200。此時虛擬機的NetWorking中Adapter選擇是local only.a. 在IP地址是192.168.200.191的伺服器上，安裝服務端軟體Wintarget.使用默認配置，選擇下一步，直到完成安裝。b. 在IP地址是192.168.200.200的伺服器上，安裝客戶端軟體Initiator.使用默認配置，選擇下一步，直到完成安裝。c. 配置服務端共享磁碟，在IP地址為192.168.200.191的伺服器上配置。步驟1、從「開始--所有程序—管理工具」列表中找到Microsoft ISCSI Software Target工具，並打開，打開以後的界面如下圖所示：步驟2、新建一個ISCSI Targets,也就是供客戶端連接的目標。右鍵單擊「iscsi targets」節點，選擇「create iscsi target」,則進入創建iscsi目標向導的界面，如下圖：點擊「下一步」，在視圖中的「ISCSI Target Name」輸入框中輸入一個唯一的供客戶端連接的目標名，比如clientISCSI,而Description輸入框可以忽略。如下圖：點擊「下一步」，設置訪問「clientISCSI」目標的客戶端的標識，如下圖所示：設置客戶端連接的標識有很多，可以是DNS名稱，IP地址，MAC地址等，在這里選擇IP地址來設置，點擊「advanced」,則彈出「advanced identifiers」對話框，再點擊對話框上的「Add」，則出現「Add/Edit identifier」對話框，在identifier Type列表中選擇：IP Address,在value中輸入客戶端訪問的ip地址：192.168.200.200。如下圖所示：點擊「OK」，返回「advanced identifiers」對話框，點擊「OK」，回到設置訪問「clientISCSI」客戶端訪問標識界面，點擊「下一步」，直到點擊「完成」。在點擊「完成」按鈕以後，將在在控制台中的「Iscsi targets」列表中出現「clientISCSI」節點。如下圖：步驟3、設置「clientISCSI」目標連接的共享虛擬磁碟，右鍵單擊「clientISCSI」節點，選擇「Create Virtual Disk for Iscsi Target」,則進入「Create Virtual Disk for Iscsi Target」創建向導。如下圖：點擊「下一步」，設置虛擬共享磁碟的文件存儲路徑，如下圖所示：點擊「下一步」，設置虛擬共享磁碟的存儲大小，如下圖：點擊「下一步」，設置虛擬磁碟描述，如下圖：點擊「下一步」，直到點擊「完成」。在創建完成以後，在控制台列表中的顯示如下：此時，所創建的虛擬共享磁碟的狀態是「idle(空閑)」，當如果有客戶端連接到服務端以後，則該狀態顯示為：這樣，服務端的設置就基本完成。d. 配置客戶端的連接，在IP地址為192.168.200.200的伺服器上配置。在未進行客戶端連接設置之前，我們來看一下客戶端磁碟管理里磁碟情況，如下圖：下面講述客戶端的設置。步驟1、打開「Microsoft iSCSI Initiator」管理控制台。如下圖所示：點擊「Discovery」選項卡，在此選項卡中，點擊「Add」按鈕，則彈出「Add Target Portal」對話框，在「IP address or DNS name」文本框中輸入需要連接的服務端的IP地址，和埠號（一般埠默認為3260），使用預設的埠設置。如下圖：點擊「OK」，返回「Iscsi Initiator」屬性界面，然後點擊「Targets」選項卡，則在此選卡的「Targets」列表框顯示了連接的狀態，如下圖：此時的狀態是「inactive」,表示是「不活動的」，說明還沒有和服務端連接上，這時我們需要點擊「log on」按鈕，則彈出「log on to target」對話框，同時選擇「automatically restore this connection when the system boots」，如下圖所示：點擊「OK」，返回屬性界面，則在此選卡的「Targets」列表框顯示了連接的狀態為：connected，如下圖：步驟2、在完成以上設置以後，再來看一下客戶端磁碟管理里磁碟情況，如下圖：此時，出現了一個沒有初始化的磁碟，這樣按照磁碟管理的方式，初始化磁碟，建立分區，即可。如下圖：這樣組合a的操作指南就完畢了，如果有多個客戶端連接服務端，則需要在服務端對應「iscsi targets」中設置客戶端訪問的IP地址，如有多個客戶端訪問「clientISCSI」則需要在節點「clientISCSI」屬性中，添加客戶端訪問的許可權，如下圖：同時在客戶端的配置，就和上面講述的客戶端設置一樣，即可完成。2、使用組合b的操作指南同樣在這里使用兩台虛擬機來做實驗，一個作為提供共享存儲的服務端，IP地址：192.168.200.191，一個作為連接存儲的客戶端，IP地址：192.168.200.200。此時虛擬機的NetWorking中Adapter選擇是local only.a. 在IP地址是192.168.200.191的伺服器上，安裝服務端軟體StarWind.使用默認配置，選擇下一步，直到完成安裝。安裝過程省略。b. 在IP地址是192.168.200.200的伺服器上，安裝客戶端軟體Initiator.使用默認配置，選擇下一步，直到完成安裝。c. 配置服務端共享磁碟，在IP地址為192.168.200.191的伺服器上配置。步驟1、從「開始」－「所有程序」－「Rocket Division Software」－「StarWind」選擇「StarWind」，打開StarWind的管理界面如下圖：右鍵單擊「connections」節點下的localhost:3260，選擇「connect」，如圖所示：選擇「connect」以後，灰色的圖標變成了藍色的可用圖標，如圖下圖所示：即此時可以此連接的埠下建立共享的虛擬磁碟，即localhost:3260,也就是安裝該軟體的伺服器端。右鍵單擊「localhost:3260」，選擇「Add device」,則進入建立虛擬磁碟向導界面，選擇「Image File Device」,如下圖所示：點擊「下一步」，選擇「Create new Image」，如下圖所示：點擊「下一步」，為建立的虛擬磁碟文件選擇存儲路徑，其他的選項採用預設設置，如下圖：點擊「下一步」，選擇通過iscsi客戶端訪問的mode,一般選擇下列設置，如下圖所示：點擊「下一步」，選擇一個「target name」(此命名好像不能有下劃線)，主要用於客戶端連接服務端時，會顯示出來。輸入我們命名為：iscsig，如下圖：點擊「下一步」，直到向導完成。則刷新節點「localhost:3260」,則會出現如下圖所示的虛擬磁碟列表。這樣，在伺服器端的設置，就完畢了，而客戶端的設置如同組合a中客戶端的設置一樣，在這里就不做介紹了。 說明：本文介紹兩種工具最基本的配置共享虛擬磁碟的方法的目的在於為了虛擬機做資料庫群集，而並不是講解這兩種工具本身的，如果真正想對這兩種工具有深入的研究，請參考以下資料。 寫的比較匆忙，文檔里難免沒有錯誤，如果有，還請諒解，希望大家可以相互交流，謝謝。 轉載自

⑧ 伺服器宕機會有什麼樣的後果安全可靠的伺服器要怎麼選擇

伺服器宕機有可能是網路故障，有可能是突發的訪問量暴增、伺服器處理不過來的問題。

伺服器處理和響應不過來，會導致丟棄部分請求不予處理，更嚴重的會導致服務端崩潰。

防止由於伺服器宕機可能導致的數據丟失問題的解決辦法有：

一、數據備份與「多雲」

如果是物理機，要做好數據備份，比如做raid；如果是選擇的公有雲，則最好把數據分存在不同的服務商那裡。

二、web伺服器配置優化

對Web伺服器進行配置優化，比如：調整內存數量、線程數量等；提供多個能提供相同服務的Web伺服器，以實現負載均衡；仔細規劃Web伺服器上部署的應用規模；對Web伺服器進行集群。

三、資料庫集群，進行讀寫分離

⑨ postgreSQL資料庫有什麼用啊

優點事實上， PostgreSQL 的特性覆蓋了 SQL-2/SQL-92 和 SQL-3/SQL-99，首先，它包括了可以說是目前世界上最豐富的數據類型的支持，其中有些數據類型可以說連商業資料庫都不具備， 比如 IP 類型和幾何類型等；其次，PostgreSQL 是全功能的自由軟體資料庫，很長時間以來，PostgreSQL 是唯一支持事務、子查詢、多版本並行控制系統、數據完整性檢查等特性的唯一的一種自由軟體的資料庫管理系統。直到最近才有 Inprise 的 InterBase 以及 SAP 等廠商將其原先專有軟體開放為自由軟體之後才打破了這個唯一。最後，PostgreSQL擁有一支非常活躍的開發隊伍，而且在許多黑客的努力下，PostgreSQL 的質量日益提高。
從技術角度來講，PostgreSQL 採用的是比較經典的 C/S （client/server）結構，也就是一個客戶端對應一個伺服器端守護進程的模式，這個守護進程分析客戶端來的查詢請求，生成規劃樹，進行數據檢索並最終把結果格式化輸出後返回給客戶端。為了便於客戶端的程序的編寫，由資料庫伺服器提供了統一的客戶端 C 介面。而不同的客戶端介面都是源自這個 C 介面，比如 ODBC，JDBC，Python，Perl ，Tcl，C/C++，ESQL 等， 同時也要指出的是，PostgreSQL 對介面的支持也是非常豐富的，幾乎支持所有類型的資料庫客戶端介面。這一點也可以說是 PostgreSQL 一大優點。
缺點
從 Postgres 開始，PostgreSQL 就經受了多次變化。
首先，早期的 PostgreSQL 繼承了幾乎所有 Ingres, Postgres, Postgres95 的問題：過於學院味，因為首先它的目的是資料庫研究，因此不論在穩定性， 性能還是使用方便方面，長期以來一直沒有得到重視，直到 PostgreSQL 項目開始以後，情況才越來越好，目前，PostgreSQL 已經完全可以勝任任何中上規模範圍內的應用范圍的業務。目前有報道的生產資料庫的大小已經有 TB 級的數據量，已經逼近 32 位計算的極限。不過學院味也給 PostgreSQL 帶來一個意想不到的好處：大概因為各大學的軟硬體環境差異太大的緣故，它是目前支持平台最多的資料庫管理系統的一種，所支持的平台多達十幾種，包括不同的系統，不同的硬體體系。至今，它仍然保持著支持平台最多的資料庫管理系統的稱號。
其次，PostgreSQL 的確還欠缺一些比較高端的資料庫管理系統需要的特性，比如資料庫集群，更優良的管理工具和更加自動化的系統優化功能 等提高資料庫性能的機制等。