php mysql分布式數(shù)據(jù)庫如何實現(xiàn)

當(dāng)前做分布式的廠商有幾家，我知道比較出名的有“華為云分布式數(shù)據(jù)庫DDM”和“阿里云分布式數(shù)據(jù)庫”，感興趣可以自行搜素了解下。

創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價比黃梅網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式黃梅網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋黃梅地區(qū)。費用合理售后完善，10年實體公司更值得信賴。

分布式數(shù)據(jù)庫的幾點概念可以了解一下。

數(shù)據(jù)分庫：

以表為單位，把原有數(shù)據(jù)庫切分成多個數(shù)據(jù)庫。切分后不同的表存儲在不同的數(shù)據(jù)庫上。

以表中的數(shù)據(jù)行記錄為單位，把原有邏輯數(shù)據(jù)庫切分成多個物理數(shù)據(jù)庫分片，表數(shù)據(jù)記錄分布存儲在各個分片上。

路由分發(fā)：

在分布式數(shù)據(jù)庫中，路由的作用即將SQL語句進(jìn)行解析，并轉(zhuǎn)發(fā)到正確的分片上，保證SQL執(zhí)行后得到正確的結(jié)果，并且節(jié)約QPS資源。

讀寫分離：

數(shù)據(jù)庫中對計算和緩存資源消耗較多的往往是密集或復(fù)雜的SQL查詢。當(dāng)系統(tǒng)資源被查詢語句消耗，反過來會影響數(shù)據(jù)寫入操作，進(jìn)而導(dǎo)致數(shù)據(jù)庫整體性能下降，響應(yīng)緩慢。因此，當(dāng)數(shù)據(jù)庫CPU和內(nèi)存資源占用居高不下，且讀寫比例較高時，可以為數(shù)據(jù)庫添加只讀數(shù)據(jù)庫。

php的memcached分布式hash算法,如何解決分布不均?crc32這個算法沒辦法把key值均勻的分布出去

memcached的總結(jié)和分布式一致性hash

當(dāng)前很多大型的web系統(tǒng)為了減輕數(shù)據(jù)庫服務(wù)器負(fù)載，會采用memchached作為緩存系統(tǒng)以提高響應(yīng)速度。

目錄： （）

memchached簡介

hash

取模

一致性hash

虛擬節(jié)點

源碼解析

參考資料

1. memchached簡介

memcached是一個開源的高性能分布式內(nèi)存對象緩存系統(tǒng)。

其實思想還是比較簡單的，實現(xiàn)包括server端（memcached開源項目一般只單指server端）和client端兩部分:

server端本質(zhì)是一個in-memory key-value store，通過在內(nèi)存中維護(hù)一個大的hashmap用來存儲小塊的任意數(shù)據(jù)，對外通過統(tǒng)一的簡單接口（memcached protocol）來提供操作。

client端是一個library，負(fù)責(zé)處理memcached protocol的網(wǎng)絡(luò)通信細(xì)節(jié)，與memcached server通信，針對各種語言的不同實現(xiàn)分裝了易用的API實現(xiàn)了與不同語言平臺的集成。

web系統(tǒng)則通過client庫來使用memcached進(jìn)行對象緩存。

2. hash

memcached的分布式主要體現(xiàn)在client端，對于server端，僅僅是部署多個memcached server組成集群，每個server獨自維護(hù)自己的數(shù)據(jù)（互相之間沒有任何通信），通過daemon監(jiān)聽端口等待client端的請求。

而在client端，通過一致的hash算法，將要存儲的數(shù)據(jù)分布到某個特定的server上進(jìn)行存儲，后續(xù)讀取查詢使用同樣的hash算法即可定位。

client端可以采用各種hash算法來定位server：

取模

最簡單的hash算法

targetServer = serverList[hash(key) % serverList.size]

直接用key的hash值（計算key的hash值的方法可以自由選擇，比如算法CRC32、MD5,甚至本地hash系統(tǒng)，如java的hashcode）模上server總數(shù)來定位目標(biāo)server。這種算法不僅簡單，而且具有不錯的隨機分布特性。

但是問題也很明顯，server總數(shù)不能輕易變化。因為如果增加/減少memcached server的數(shù)量，對原先存儲的所有key的后續(xù)查詢都將定位到別的server上，導(dǎo)致所有的cache都不能被命中而失效。

一致性hash

為了解決這個問題，需要采用一致性hash算法（consistent hash）

相對于取模的算法，一致性hash算法除了計算key的hash值外，還會計算每個server對應(yīng)的hash值，然后將這些hash值映射到一個有限的值域上（比如0~2^32）。通過尋找hash值大于hash(key)的最小server作為存儲該key數(shù)據(jù)的目標(biāo)server。如果找不到，則直接把具有最小hash值的server作為目標(biāo)server。

為了方便理解，可以把這個有限值域理解成一個環(huán)，值順時針遞增。

如上圖所示，集群中一共有5個memcached server，已通過server的hash值分布到環(huán)中。

如果現(xiàn)在有一個寫入cache的請求，首先計算x=hash(key)，映射到環(huán)中，然后從x順時針查找，把找到的第一個server作為目標(biāo)server來存儲cache，如果超過了2^32仍然找不到，則命中第一個server。比如x的值介于A~B之間，那么命中的server節(jié)點應(yīng)該是B節(jié)點

可以看到，通過這種算法，對于同一個key，存儲和后續(xù)的查詢都會定位到同一個memcached server上。

那么它是怎么解決增/刪server導(dǎo)致的cache不能命中的問題呢？

假設(shè)，現(xiàn)在增加一個server F，如下圖

此時，cache不能命中的問題仍然存在，但是只存在于B~F之間的位置（由C變成了F），其他位置（包括F~C）的cache的命中不受影響（刪除server的情況類似）。盡管仍然有cache不能命中的存在，但是相對于取模的方式已經(jīng)大幅減少了不能命中的cache數(shù)量。

虛擬節(jié)點

但是，這種算法相對于取模方式也有一個缺陷：當(dāng)server數(shù)量很少時，很可能他們在環(huán)中的分布不是特別均勻，進(jìn)而導(dǎo)致cache不能均勻分布到所有的server上。

如圖，一共有3臺server – 1，2，4。命中4的幾率遠(yuǎn)遠(yuǎn)高于1和2。

為解決這個問題，需要使用虛擬節(jié)點的思想：為每個物理節(jié)點（server）在環(huán)上分配100～200個點，這樣環(huán)上的節(jié)點較多，就能抑制分布不均勻。

當(dāng)為cache定位目標(biāo)server時，如果定位到虛擬節(jié)點上，就表示cache真正的存儲位置是在該虛擬節(jié)點代表的實際物理server上。

另外，如果每個實際server的負(fù)載能力不同，可以賦予不同的權(quán)重，根據(jù)權(quán)重分配不同數(shù)量的虛擬節(jié)點。

// 采用有序map來模擬環(huán)

this.consistentBuckets = new TreeMap();

MessageDigest md5 = MD5.get();//用MD5來計算key和server的hash值

// 計算總權(quán)重

if ( this.totalWeight for ( int i = 0; i this.weights.length; i++ )

this.totalWeight += ( this.weights[i] == null ) ? 1 : this.weights[i];

} else if ( this.weights == null ) {

this.totalWeight = this.servers.length;

}

// 為每個server分配虛擬節(jié)點

for ( int i = 0; i servers.length; i++ ) {

// 計算當(dāng)前server的權(quán)重

int thisWeight = 1;

if ( this.weights != null this.weights[i] != null )

thisWeight = this.weights[i];

// factor用來控制每個server分配的虛擬節(jié)點數(shù)量

// 權(quán)重都相同時，factor=40

// 權(quán)重不同時，factor=40*server總數(shù)*該server權(quán)重所占的百分比

// 總的來說，權(quán)重越大，factor越大，可以分配越多的虛擬節(jié)點

double factor = Math.floor( ((double)(40 * this.servers.length * thisWeight)) / (double)this.totalWeight );

for ( long j = 0; j factor; j++ ) {

// 每個server有factor個hash值

// 使用server的域名或IP加上編號來計算hash值

// 比如server - "172.45.155.25:11111"就有factor個數(shù)據(jù)用來生成hash值：

// 172.45.155.25:11111-1, 172.45.155.25:11111-2, ..., 172.45.155.25:11111-factor

byte[] d = md5.digest( ( servers[i] + "-" + j ).getBytes() );

// 每個hash值生成4個虛擬節(jié)點

for ( int h = 0 ; h 4; h++ ) {

Long k =

((long)(d[3+h*4]0xFF) 24)

| ((long)(d[2+h*4]0xFF) 16)

| ((long)(d[1+h*4]0xFF) 8 )

| ((long)(d[0+h*4]0xFF));

// 在環(huán)上保存節(jié)點

consistentBuckets.put( k, servers[i] );

}

}

// 每個server一共分配4*factor個虛擬節(jié)點

}

// 采用有序map來模擬環(huán)

this.consistentBuckets = new TreeMap();

MessageDigest md5 = MD5.get();//用MD5來計算key和server的hash值

// 計算總權(quán)重

if ( this.totalWeight for ( int i = 0; i this.weights.length; i++ )

this.totalWeight += ( this.weights[i] == null ) ? 1 : this.weights[i];

} else if ( this.weights == null ) {

this.totalWeight = this.servers.length;

}

// 為每個server分配虛擬節(jié)點

for ( int i = 0; i servers.length; i++ ) {

// 計算當(dāng)前server的權(quán)重

int thisWeight = 1;

if ( this.weights != null this.weights[i] != null )

thisWeight = this.weights[i];

// factor用來控制每個server分配的虛擬節(jié)點數(shù)量

// 權(quán)重都相同時，factor=40

// 權(quán)重不同時，factor=40*server總數(shù)*該server權(quán)重所占的百分比

// 總的來說，權(quán)重越大，factor越大，可以分配越多的虛擬節(jié)點

double factor = Math.floor( ((double)(40 * this.servers.length * thisWeight)) / (double)this.totalWeight );

for ( long j = 0; j factor; j++ ) {

// 每個server有factor個hash值

// 使用server的域名或IP加上編號來計算hash值

// 比如server - "172.45.155.25:11111"就有factor個數(shù)據(jù)用來生成hash值：

// 172.45.155.25:11111-1, 172.45.155.25:11111-2, ..., 172.45.155.25:11111-factor

byte[] d = md5.digest( ( servers[i] + "-" + j ).getBytes() );

// 每個hash值生成4個虛擬節(jié)點

for ( int h = 0 ; h 4; h++ ) {

Long k =

((long)(d[3+h*4]0xFF) 24)

| ((long)(d[2+h*4]0xFF) 16)

| ((long)(d[1+h*4]0xFF) 8 )

| ((long)(d[0+h*4]0xFF));

// 在環(huán)上保存節(jié)點

consistentBuckets.put( k, servers[i] );

}

}

// 每個server一共分配4*factor個虛擬節(jié)點

}

// 用MD5來計算key的hash值

MessageDigest md5 = MD5.get();

md5.reset();

md5.update( key.getBytes() );

byte[] bKey = md5.digest();

// 取MD5值的低32位作為key的hash值

long hv = ((long)(bKey[3]0xFF) 24) | ((long)(bKey[2]0xFF) 16) | ((long)(bKey[1]0xFF) 8 ) | (long)(bKey[0]0xFF);

// hv的tailMap的第一個虛擬節(jié)點對應(yīng)的即是目標(biāo)server

SortedMap tmap = this.consistentBuckets.tailMap( hv );

return ( tmap.isEmpty() ) ? this.consistentBuckets.firstKey() : tmap.firstKey();

更多問題到問題求助專區(qū)（）

網(wǎng)站服務(wù)器配置怎么選擇啊？需要注意哪些？

根據(jù)自己多年銷售、運營服務(wù)器的經(jīng)驗說一下

選擇云主機（云服務(wù)器）和選擇其他主機的方法類似，要選擇合適的云主機就需要對自己的網(wǎng)站情況以及云主機的各項配置

參數(shù)有一定了解，具體如下：

首先是網(wǎng)站的情況：

1、網(wǎng)站的類型：比如網(wǎng)站是靜態(tài)還是動態(tài)為主，使用的什么的網(wǎng)站程序，對運行環(huán)境有何要求，是否需要配置特定的環(huán)境，這將影響到操作系統(tǒng)、存儲模式的選擇。

2、網(wǎng)站的訪問量：網(wǎng)站的日均訪問人數(shù)和平均同時在線人數(shù)有多少，這將影響到CPU、內(nèi)存、帶寬等選擇。

3、網(wǎng)站的數(shù)據(jù)大小：網(wǎng)站目前的數(shù)據(jù)有多大，未來是否會快速增加，這將影響到硬盤的選擇。

4、網(wǎng)站的目標(biāo)用戶：網(wǎng)站是面向全國用戶還是本地用戶，這將影響到機房線路的選擇。

在確定網(wǎng)站情況之后可以結(jié)合云主機的各項配置參數(shù)進(jìn)行估算選擇：

云主機參數(shù)配置

1.CPU：CPU代表主機的運算能力，如果網(wǎng)站流量較大，動態(tài)頁面比較多，建議選擇2核以上CPU。

2.內(nèi)存：內(nèi)存也是決定網(wǎng)站打開速度的重要因素，內(nèi)存越大，可用緩存越大，打開速度也就越快，windows操作系統(tǒng)不支持選擇512MB內(nèi)存。

3.硬盤：硬盤的大小要根據(jù)網(wǎng)站的大小來決定，在選擇時應(yīng)該考慮到剩余空間。另外硬盤的I/O讀取速度直接決定文件讀取的快慢，新麥互聯(lián)云主機硬盤的讀取速度比其他網(wǎng)站快很多，一般情況下都夠用。

4.帶寬：云主機沒有流量限制，所以主要考慮帶寬。帶寬是一個網(wǎng)站打開速度的直接體現(xiàn)，帶寬越大，訪問的時候，打開速度就越快。訪問人數(shù)較多的網(wǎng)站，建議選擇大的帶寬。

5.操作系統(tǒng)：操作系統(tǒng)的選擇和個人的熟悉情況和網(wǎng)站具體情況有關(guān)，對哪種操作系統(tǒng)比較了解就選擇哪種操作系統(tǒng)，另外windows系統(tǒng)對asp程序支持較好，不過占用內(nèi)存較多，而Linux系統(tǒng)對php程序支持較好，更省內(nèi)存，并且有的程序可能只支持某個操作系統(tǒng)。

6.機房線路：線路選擇合適的機房。

7.存儲模式：分布式存儲數(shù)據(jù)保留四份，而SSD固態(tài)硬盤適合對I/O讀取速度有更高要求的用戶。

如果還是不能確定選擇何種配置，可以先購買一個標(biāo)準(zhǔn)配置運行一段時間進(jìn)行觀察，如果發(fā)現(xiàn)配置不夠可以隨時升級

php 高并發(fā)解決思路解決方案

php 高并發(fā)解決思路解決方案，如何應(yīng)對網(wǎng)站大流量高并發(fā)情況。本文為大家總結(jié)了常用的處理方式，但不是細(xì)節(jié)，后續(xù)一系列細(xì)節(jié)教程給出。希望大家喜歡。

一 高并發(fā)的概念

在互聯(lián)網(wǎng)時代，并發(fā)，高并發(fā)通常是指并發(fā)訪問。也就是在某個時間點，有多少個訪問同時到來。

二 高并發(fā)架構(gòu)相關(guān)概念

1、QPS (每秒查詢率) : 每秒鐘請求或者查詢的數(shù)量，在互聯(lián)網(wǎng)領(lǐng)域，指每秒響應(yīng)請求數(shù)(指 HTTP 請求)

2、PV（Page View）：綜合瀏覽量，即頁面瀏覽量或者點擊量，一個訪客在 24 小時內(nèi)訪問的頁面數(shù)量

--注：同一個人瀏覽你的網(wǎng)站的同一頁面，只記做一次 pv

3、吞吐量（fetches/sec） ：單位時間內(nèi)處理的請求數(shù)量 （通常由 QPS 和并發(fā)數(shù)決定）

4、響應(yīng)時間：從請求發(fā)出到收到響應(yīng)花費的時間

5、獨立訪客（UV）：一定時間范圍內(nèi)，相同訪客多次訪問網(wǎng)站，只計算為 1 個獨立訪客

6、帶寬：計算帶寬需關(guān)注兩個指標(biāo)，峰值流量和頁面的平均大小

7、日網(wǎng)站帶寬： PV/統(tǒng)計時間（換算到秒） * 平均頁面大小（kb）* 8

三 需要注意點：

1、QPS 不等于并發(fā)連接數(shù)（QPS 是每秒 HTTP 請求數(shù)量，并發(fā)連接數(shù)是系統(tǒng)同時處理的請求數(shù)量）

2、峰值每秒請求數(shù)（QPS）= （總 PV 數(shù)*80%）/ （六小時秒數(shù)*20%）【代表 80%的訪問量都集中在 20%的時間內(nèi)】

3、壓力測試： 測試能承受的最大并發(fā)數(shù) 以及測試最大承受的 QPS 值

4、常用的性能測試工具【ab，wrk，httpload，Web Bench，Siege，Apache JMeter】

四 優(yōu)化

1、當(dāng) QPS 小于 50 時

優(yōu)化方案:為一般小型網(wǎng)站,不用考慮優(yōu)化

2、當(dāng) QPS 達(dá)到 100 時,遇到數(shù)據(jù)查詢瓶頸

優(yōu)化方案: 數(shù)據(jù)庫緩存層,數(shù)據(jù)庫的負(fù)載均衡

3、當(dāng) QPS 達(dá)到 800 時, 遇到帶寬瓶頸

優(yōu)化方案:CDN 加速,負(fù)載均衡

4、當(dāng) QPS 達(dá)到 1000 時

優(yōu)化方案: 做 html 靜態(tài)緩存

5、當(dāng) QPS 達(dá)到 2000 時

優(yōu)化方案: 做業(yè)務(wù)分離,分布式存儲

五、高并發(fā)解決方案案例:

1、流量優(yōu)化

防盜鏈處理(去除惡意請求)

2、前端優(yōu)化

(1) 減少 HTTP 請求[將 css,js 等合并]

(2) 添加異步請求(先不將所有數(shù)據(jù)都展示給用戶,用戶觸發(fā)某個事件,才會異步請求數(shù)據(jù))

(3) 啟用瀏覽器緩存和文件壓縮

(4) CDN 加速

(5) 建立獨立的圖片服務(wù)器(減少 I/O)

3、服務(wù)端優(yōu)化

(1) 頁面靜態(tài)化

(2) 并發(fā)處理

(3) 隊列處理

4、數(shù)據(jù)庫優(yōu)化

(1) 數(shù)據(jù)庫緩存

(2) 分庫分表,分區(qū)

(3) 讀寫分離

(4) 負(fù)載均衡

5、web 服務(wù)器優(yōu)化

(1) nginx 反向代理實現(xiàn)負(fù)載均衡

(2) lvs 實現(xiàn)負(fù)載均衡

本文題目：php分布式數(shù)據(jù)存儲,php分布式架構(gòu)
分享地址：http://chinadenli.net/article8/hshgop.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供移動網(wǎng)站建設(shè)、軟件開發(fā)、營銷型網(wǎng)站建設(shè)、標(biāo)簽優(yōu)化、網(wǎng)站內(nèi)鏈、動態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)