有可能造成影響，而且是很有可能造成影響。這也就是所謂的“一粒老鼠屎壞了一鍋湯”。不少的DBA都遇到過類似問題，就是一臺服務(wù)器上的多個應(yīng)用數(shù)據(jù)，由于其中一個應(yīng)用的程序編寫問題，導(dǎo)致這臺服務(wù)器上所有應(yīng)用都受到牽連。不過按照你的描述，如果只是A1的死鎖，那么A2是不會有問題的。但如果是是A1有太多的表掃描或者復(fù)雜運(yùn)算導(dǎo)致資源緊張，那是會影響到A2的。
公司主營業(yè)務(wù)：網(wǎng)站制作、網(wǎng)站建設(shè)、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。成都創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會用頭腦與智慧不斷的給客戶帶來驚喜。成都創(chuàng)新互聯(lián)推出銅川免費(fèi)做網(wǎng)站回饋大家。
數(shù)據(jù)庫的并發(fā)一般都是指整個服務(wù)器的并發(fā)，不論這個數(shù)據(jù)庫服務(wù)器上有幾個庫
大數(shù)據(jù)并發(fā)處理解決方案：
1、HTML靜態(tài)化
效率最高、消耗最小的就是純靜態(tài)化的html頁面，所以盡可能使網(wǎng)站上的頁面采用靜態(tài)頁面來實(shí)現(xiàn)，這個最簡單的方法其實(shí)也是最有效的方法。但是對于大量內(nèi)容并且頻繁更新的網(wǎng)站，無法全部手動去挨個實(shí)現(xiàn)，于是出現(xiàn)了常見的信息發(fā)布系統(tǒng)CMS，像常訪問的各個門戶站點(diǎn)的新聞頻道，甚至他們的其他頻道，都是通過信息發(fā)布系統(tǒng)來管理和實(shí)現(xiàn)的，信息發(fā)布系統(tǒng)可以實(shí)現(xiàn)最簡單的信息錄入自動生成靜態(tài)頁面，還能具備頻道管理、權(quán)限管理、自動抓取等功能，對于一個大型網(wǎng)站來說，擁有一套高效、可管理的CMS是必不可少的。
2、圖片服務(wù)器分離
對于Web服務(wù)器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，于是有必要將圖片與頁面進(jìn)行分離，這是基本上大型網(wǎng)站都會采用的策略，他們都有獨(dú)立的圖片服務(wù)器，甚至很多臺圖片服務(wù)器。這樣的架構(gòu)可以降低提供頁面訪問請求的服務(wù)器系統(tǒng)壓力，并且可以保證系統(tǒng)不會因?yàn)閳D片問題而崩潰，在應(yīng)用服務(wù)器和圖片服務(wù)器上，可以進(jìn)行不同的配置優(yōu)化，比如apache在配置ContentType的時候可以盡量少支持，盡可能少的LoadModule，保證更高的系統(tǒng)消耗和執(zhí)行效率。 這一實(shí)現(xiàn)起來是比較容易的一現(xiàn)，如果服務(wù)器集群操作起來更方便，如果是獨(dú)立的服務(wù)器，新手可能出現(xiàn)上傳圖片只能在服務(wù)器本地的情況下，可以在令一臺服務(wù)器設(shè)置的IIS采用網(wǎng)絡(luò)路徑來實(shí)現(xiàn)圖片服務(wù)器，即不用改變程序，又能提高性能，但對于服務(wù)器本身的IO處理性能是沒有任何的改變。
3、數(shù)據(jù)庫集群和庫表散列
大型網(wǎng)站都有復(fù)雜的應(yīng)用，這些應(yīng)用必須使用數(shù)據(jù)庫，那么在面對大量訪問的時候，數(shù)據(jù)庫的瓶頸很快就能顯現(xiàn)出來，這時一臺數(shù)據(jù)庫將很快無法滿足應(yīng)用，于是需要使用數(shù)據(jù)庫集群或者庫表散列。
4、緩存
緩存一詞搞技術(shù)的都接觸過，很多地方用到緩存。網(wǎng)站架構(gòu)和網(wǎng)站開發(fā)中的緩存也是非常重要。架構(gòu)方面的緩存，對Apache比較熟悉的人都能知道Apache提供了自己的緩存模塊，也可以使用外加的Squid模塊進(jìn)行緩存，這兩種方式均可以有效的提高Apache的訪問響應(yīng)能力。
網(wǎng)站程序開發(fā)方面的緩存，Linux上提供的Memory Cache是常用的緩存接口，可以在web開發(fā)中使用，比如用Java開發(fā)的時候就可以調(diào)用MemoryCache對一些數(shù)據(jù)進(jìn)行緩存和通訊共享，一些大型社區(qū)使用了這樣的架構(gòu)。另外，在使用web語言開發(fā)的時候，各種語言基本都有自己的緩存模塊和方法，PHP有Pear的Cache模塊，Java就更多了，.net不是很熟悉，相信也肯定有。
5、鏡像
鏡像是大型網(wǎng)站常采用的提高性能和數(shù)據(jù)安全性的方式，鏡像的技術(shù)可以解決不同網(wǎng)絡(luò)接入商和地域帶來的用戶訪問速度差異，比如ChinaNet和EduNet之間的差異就促使了很多網(wǎng)站在教育網(wǎng)內(nèi)搭建鏡像站點(diǎn)，數(shù)據(jù)進(jìn)行定時更新或者實(shí)時更新。在鏡像的細(xì)節(jié)技術(shù)方面，這里不闡述太深，有很多專業(yè)的現(xiàn)成的解決架構(gòu)和產(chǎn)品可選。也有廉價的通過軟件實(shí)現(xiàn)的思路，比如Linux上的rsync等工具。
6、負(fù)載均衡
負(fù)載均衡將是大型網(wǎng)站解決高負(fù)荷訪問和大量并發(fā)請求采用的終極解決辦法。 負(fù)載均衡技術(shù)發(fā)展了多年，有很多專業(yè)的服務(wù)提供商和產(chǎn)品可以選擇。
硬件四層交換
第四層交換使用第三層和第四層信息包的報(bào)頭信息，根據(jù)應(yīng)用區(qū)間識別業(yè)務(wù)流，將整個區(qū)間段的業(yè)務(wù)流分配到合適的應(yīng)用服務(wù)器進(jìn)行處理?！〉谒膶咏粨Q功能就象是虛IP，指向物理服務(wù)器。它傳輸?shù)臉I(yè)務(wù)服從的協(xié)議多種多樣，有HTTP、FTP、NFS、Telnet或其他協(xié)議。這些業(yè)務(wù)在物理服務(wù)器基礎(chǔ)上，需要復(fù)雜的載量平衡算法。在IP世界，業(yè)務(wù)類型由終端TCP或UDP端口地址來決定，在第四層交換中的應(yīng)用區(qū)間則由源端和終端IP地址、TCP和UDP端口共同決定。
在硬件四層交換產(chǎn)品領(lǐng)域，有一些知名的產(chǎn)品可以選擇，比如Alteon、F5等，這些產(chǎn)品很昂貴，但是物有所值，能夠提供非常優(yōu)秀的性能和很靈活的管理能力。Yahoo中國當(dāng)初接近2000臺服務(wù)器使用了三四臺Alteon就搞定了。
想要知道如何處理數(shù)據(jù)并發(fā)，自然需要先了解數(shù)據(jù)并發(fā)。
什么是數(shù)據(jù)并發(fā)操作呢？
就是同一時間內(nèi)，不同的線程同時對一條數(shù)據(jù)進(jìn)行讀寫操作。
在互聯(lián)網(wǎng)時代，一個系統(tǒng)常常有很多人在使用，因此就可能出現(xiàn)高并發(fā)的現(xiàn)象，也就是不同的用戶同時對一條數(shù)據(jù)進(jìn)行操作，如果沒有有效的處理，自然就會出現(xiàn)數(shù)據(jù)的異常。而最常見的一種數(shù)據(jù)并發(fā)的場景就是電商中的秒殺，成千上萬個用戶對在極端的時間內(nèi)，搶購一個商品。針對這種場景，商品的庫存就是一個需要控制的數(shù)據(jù)，而多個用戶對在同一時間對庫存進(jìn)行重寫，一個不小心就可能出現(xiàn)超賣的情況。
針對這種情況，我們?nèi)绾斡行У奶幚頂?shù)據(jù)并發(fā)呢？
第一種方案、數(shù)據(jù)庫鎖
從鎖的基本屬性來說，可以分為兩種：一種是共享鎖（S），一種是排它鎖（X）。在MySQL的數(shù)據(jù)庫中，是有四種隔離級別的，會在讀寫的時候，自動的使用這兩種鎖，防止數(shù)據(jù)出現(xiàn)混亂。
這四種隔離級別分別是：
讀未提交（Read Uncommitted）
讀提交（Read Committed）
可重復(fù)讀（Repeated Read）
串行化（Serializable）
當(dāng)然，不同的隔離級別，效率也是不同的，對于數(shù)據(jù)的一致性保證也就有不同的結(jié)果。而這些可能出現(xiàn)的又有哪些呢？
臟讀（dirty read）
當(dāng)事務(wù)與事務(wù)之間沒有任何隔離的時候，就可能會出現(xiàn)臟讀。例如：商家想看看所有的訂單有哪些，這時，用戶A提交了一個訂單，但事務(wù)還沒提交，商家卻看到了這個訂單。而這時就會出現(xiàn)一種問題，當(dāng)商家去操作這個訂單時，可能用戶A的訂單由于部分問題，導(dǎo)致數(shù)據(jù)回滾，事務(wù)沒有提交，這時商家的操作就會失去目標(biāo)。
不可重復(fù)讀（unrepeatable read）
一個事務(wù)中，兩次讀操作出來的同一條數(shù)據(jù)值不同，就是不可重復(fù)讀。
例如：我們有一個事務(wù)A，需要去查詢一下商品庫存，然后做扣減，這時，事務(wù)B操作了這個商品，扣減了一部分庫存，當(dāng)事務(wù)A再次去查詢商品庫存的時候，發(fā)現(xiàn)這一次的結(jié)果和上次不同了，這就是不可重復(fù)讀。
幻讀（phantom problem）
一個事務(wù)中，兩次讀操作出來的結(jié)果集不同，就是幻讀。
例如：一個事務(wù)A，去查詢現(xiàn)在已經(jīng)支付的訂單有哪些，得到了一個結(jié)果集。這時，事務(wù)B新提交了一個訂單，當(dāng)事務(wù)A再次去查詢時，就會出現(xiàn)，兩次得到的結(jié)果集不同的情況，也就是幻讀了。
那針對這些結(jié)果，不同的隔離級別可以干什么呢？
“讀未提（Read Uncommitted）”能預(yù)防啥？啥都預(yù)防不了。
“讀提交（Read Committed）”能預(yù)防啥？使用“快照讀（Snapshot Read）”方式，避免“臟讀”，但是可能出現(xiàn)“不可重復(fù)讀”和“幻讀”。
“可重復(fù)讀（Repeated Red）”能預(yù)防啥？使用“快照讀（Snapshot Read）”方式，鎖住被讀取記錄，避免出現(xiàn)“臟讀”、“不可重復(fù)讀”，但是可能出現(xiàn)“幻讀”。
“串行化（Serializable）”能預(yù)防啥？有效避免“臟讀”、“不可重復(fù)讀”、“幻讀”，不過運(yùn)行效率奇差。
好了，鎖說完了，但是，我們的數(shù)據(jù)庫鎖，并不能有效的解決并發(fā)的問題，只是盡可能保證數(shù)據(jù)的一致性，當(dāng)并發(fā)量特別大時，數(shù)據(jù)庫還是容易扛不住。那解決數(shù)據(jù)并發(fā)的另一個手段就是，盡可能的提高處理的速度。
因?yàn)閿?shù)據(jù)的IO要提升難度比較大，那么通過其他的方式，對數(shù)據(jù)進(jìn)行處理，減少數(shù)據(jù)庫的IO，就是提高并發(fā)能力的有效手段了。
最有效的一種方式就是：緩存
想要減少并發(fā)出現(xiàn)的概率，那么讀寫的效率越高，讀寫的執(zhí)行時間越短，自然數(shù)據(jù)并發(fā)的可能性就變小了，并發(fā)性能也有提高了。
還是用剛才的秒殺舉例，我們?yōu)榈木褪潜ＷC庫存的數(shù)據(jù)不出錯，賣出一個商品，減一個庫存，那么，我們就可以將庫存放在內(nèi)存中進(jìn)行處理。這樣，就能夠保證庫存有序的及時扣減，并且不出現(xiàn)問題。這樣，我們的數(shù)據(jù)庫的寫操作也變少了，執(zhí)行效率也就大大提高了。
當(dāng)然，常用的分布式緩存方式有：Redis和Memcache，Redis可以持久化到硬盤，而Memcache不行，應(yīng)該怎么選擇，就看具體的使用場景了。
當(dāng)然，緩存畢竟使用的范圍有限，很多的數(shù)據(jù)我們還是必須持久化到硬盤中，那我們就需要提高數(shù)據(jù)庫的IO能力，這樣避免一個線程執(zhí)行時間太長，造成線程的阻塞。
那么，讀寫分離就是另一種有效的方式了
當(dāng)我們的寫成為了瓶頸的時候，讀寫分離就是一種可以選擇的方式了。
我們的讀庫就只需要執(zhí)行讀，寫庫就只需要執(zhí)行寫，把讀的壓力從主庫中分離出去，讓主庫的資源只是用來保證寫的效率，從而提高寫操作的性能。
重慶分公司
重慶分公司
