如何分布式並發修改資料庫

❶ 深入理解分布式事務，高並發下分布式事務的解決方案

1、什麼是分布式事務

分布式事務就是指事務的參與者、支持事務的伺服器、資源伺服器以及事務管理器分別位於不同的分布式系統的不同節點之上。以上是網路的解釋，簡單的說，就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的伺服器上，且屬於不同的應用，分布式事務需要保證這些小操作要麼全部成功，要麼全部失敗。本質上來說，分布式事務就是為了保證不同資料庫的數據一致性。

2、分布式事務的產生的原因

2.1、資料庫分庫分表

當資料庫單表一年產生的數據超過1000W，那麼就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以後有空詳細說，簡單的說就是原來的一個資料庫變成了多個資料庫。這時候，如果一個操作既訪問01庫，又訪問02庫，而且要保證數據的一致性，那麼就要用到分布式事務。

2.2、應用SOA化

所謂的SOA化，就是業務的服務化。比如原來單機支撐了整個電商網站，現在對整個網站進行拆解，分離出了訂單中心、用戶中心、庫存中心。對於訂單中心，有專門的資料庫存儲訂單信息，用戶中心也有專門的資料庫存儲用戶信息，庫存中心也會有專門的資料庫存儲庫存信息。這時候如果要同時對訂單和庫存進行操作，那麼就會涉及到訂單資料庫和庫存資料庫，為了保證數據一致性，就需要用到分布式事務。

以上兩種情況表象不同，但是本質相同，都是因為要操作的資料庫變多了！

3、事務的ACID特性

3.1、原子性（A）

所謂的原子性就是說，在整個事務中的所有操作，要麼全部完成，要麼全部不做，沒有中間狀態。對於事務在執行中發生錯誤，所有的操作都會被回滾，整個事務就像從沒被執行過一樣。

3.2、一悔凱兄致性（C）

事務的執行必須保證系統的一致性，就拿轉賬為例，A有500元，B有300元，如果在一個事務里A成功轉給B50元，那麼不管並發多少，不管發生什麼，只要事務執行成功了，那麼最後A賬戶一定是450元，B賬戶一定是350元。

3.3、隔離性（I）

所謂的隔離性就是說，事務與事務之間不會互相影響，一個事務的中間狀態不會被其他事務感知。

3.4、持久性（D）

所謂的持久性，就是說一單事務完成了，那麼事務對數據所做的變更就完全保存在了資料庫中，即使發生停電，系統宕機也是如此。

4、分布式事務的應用場景

4.1、支付

最經典的場景就是支付了，一筆支付，是對買家賬戶進行扣款，同時對賣家賬戶進行加錢，這些操作必須在一個事務里執行，要麼全孫毀部成功，要麼全部失敗。而對於買家賬戶屬於買家中心，對應的是買家資料庫，而賣家賬戶屬於賣家中心，對應的是賣家資料庫，對不同資料庫的操作必然需要引入分布式事務。

4.2、在線下單

買家在電商平台下單，往往會涉及到兩個動作，一個是扣庫存，第二個是更新訂單狀態，庫存和訂單一般屬於不同的資料庫，需要使用分布式事務保證數據一致性。

5、常見的分布式事務解決方案

5.1、基於XA協議的兩階段提交

XA是一個分布式事務協議，由Tuxedo提出。XA中大致分為兩部分：事務管理器和本地資源管理器。其中本地資源管理器往往由資料庫實現，比如Oracle、DB2這些商業資料庫都實現了XA介面，而事務管理器作為全局的調度者，負責各個本地資源的提交和回滾。XA實現分布式事務的原理如下：

總的來說，XA協議比較簡單，而且一旦商業資料庫實現了XA協議，使用分布式事務的成本也比較低。但是，XA也有致命的缺點，那就是性能不理想，特別是在交易下單鏈路，往往並發量很高，XA無法滿足高並發場景。XA目前在商業資料庫支持的比較理想，在mysql資料庫中支持的不太理想，mysql的XA實現，沒有記錄prepare階段日誌，主備切換回導致主庫與備庫數據不一致。許多nosql也沒有支持XA，這讓XA的應用場景變得非常狹隘。

5.2、消息事務+最終一致性

所謂的消息事務就是基於消息中間件的兩階段提交，本質上是對消息中間件的一種特殊利用，它是將本地事務和發消息放在了一個分布式事務里，保證要麼本地操作成功成功並且對外發消息成功，要麼兩者都失敗，開源的RocketMQ就支持這一特性，具體原理如下：

1、A系統向消息中間件發送一條預備消息

2、碧襲消息中間件保存預備消息並返回成功

3、A執行本地事務

4、A發送提交消息給消息中間件

通過以上4步完成了一個消息事務。對於以上的4個步驟，每個步驟都可能產生錯誤，下面一一分析：

步驟一出錯，則整個事務失敗，不會執行A的本地操作步驟二出錯，則整個事務失敗，不會執行A的本地操作步驟三出錯，這時候需要回滾預備消息，怎麼回滾？答案是A系統實現一個消息中間件的回調介面，消息中間件會去不斷執行回調介面，檢查A事務執行是否執行成功，如果失敗則回滾預備消息步驟四齣錯，這時候A的本地事務是成功的，那麼消息中間件要回滾A嗎？答案是不需要，其實通過回調介面，消息中間件能夠檢查到A執行成功了，這時候其實不需要A發提交消息了，消息中間件可以自己對消息進行提交，從而完成整個消息事務基於消息中間件的兩階段提交往往用在高並發場景下，將一個分布式事務拆成一個消息事務（A系統的本地操作+發消息）+B系統的本地操作，其中B系統的操作由消息驅動，只要消息事務成功，那麼A操作一定成功，消息也一定發出來了，這時候B會收到消息去執行本地操作，如果本地操作失敗，消息會重投，直到B操作成功，這樣就變相地實現了A與B的分布式事務。原理如下：

雖然上面的方案能夠完成A和B的操作，但是A和B並不是嚴格一致的，而是最終一致的，我們在這里犧牲了一致性，換來了性能的大幅度提升。當然，這種玩法也是有風險的，如果B一直執行不成功，那麼一致性會被破壞，具體要不要玩，還是得看業務能夠承擔多少風險。

5.3、TCC編程模式

所謂的TCC編程模式，也是兩階段提交的一個變種。TCC提供了一個編程框架，將整個業務邏輯分為三塊：Try、Confirm和Cancel三個操作。以在線下單為例，Try階段會去扣庫存，Confirm階段則是去更新訂單狀態，如果更新訂單失敗，則進入Cancel階段，會去恢復庫存。總之，TCC就是通過代碼人為實現了兩階段提交，不同的業務場景所寫的代碼都不一樣，復雜度也不一樣，因此，這種模式並不能很好地被復用。

6、總結

分布式事務，本質上是對多個資料庫的事務進行統一控制，按照控制力度可以分為：不控制、部分控制和完全控制。不控制就是不引入分布式事務，部分控制就是各種變種的兩階段提交，包括上面提到的消息事務+最終一致性、TCC模式，而完全控制就是完全實現兩階段提交。部分控制的好處是並發量和性能很好，缺點是數據一致性減弱了，完全控制則是犧牲了性能，保障了一致性，具體用哪種方式，最終還是取決於業務場景。作為技術人員，一定不能忘了技術是為業務服務的，不要為了技術而技術，針對不同業務進行技術選型也是一種很重要的能力

❷ 分布式資料庫系統(DDBS)概述

一 什麼是分布式資料庫

分布式資料庫系統是在集中式資料庫系統的基礎上發展來的 是資料庫技術與網路技術結合的產物

分布式資料庫系統有兩種 一種是物理上分布的 但邏輯上卻是集中的 這種分布式資料庫只適宜用途比較單一的 不大的單位或部門 另一種分布式資料庫系統在物理上和邏輯上都是分布的 也就是所謂聯邦式分布資料庫系統 由於組成聯邦的各個子資料庫系統是相對 自治 的 這種系統可以容納多種不同用途的 差異較大的資料庫 比較適宜於大范圍內資料庫的集成

分布式資料庫系統(DDBS)包含分布式資料庫管理系統(DDBMS)和分布式資料庫(DDB)

在分布式資料庫系統中 一個應用程序可以對資料庫進行透明操作 資料庫中的數據分別在不同的局部資料庫中存儲 由不同的DBMS進行管理 在不同的機器上運行 由不同的操作系統支持 被不同的通信網路連接在一起

一個分布式資料庫在邏輯上是一個統一的整體 即在用戶面前為單個邏輯資料庫 在物理上則是分別存儲在不同的物理節點上 一個應用程序通過網路的連接可以訪問分布在不同地理位置的資料庫 它的分布性表現在資料庫中的數據不是存儲在同一場地 更確切地講 不存儲在同一計算機的存儲設備上 這就是與集中式資料庫的區別 從用戶的角度看 一個分布式資料庫系統在邏輯上和集中式資料庫系統一樣 用戶可以在任何一個場地執行全局應用 就好那些數據是存儲在同一台計算機上 有單個資料庫管理系統(DBMS)管理一樣 用戶並沒有什麼感覺不一樣

分布式資料庫中每一個資料庫伺服器合作地維護全局資料庫的一致性

分布式資料庫系統是一個客戶/伺服器體系結構

在橡仿系統中的每一台計算機稱為結點 如果一結點具有管理資料庫軟體 該結點稱為資料庫伺服器 如果一個結點為請求伺服器的信息的一應用 該結點稱為客戶 在ORACLE客戶 執行資料庫應用 可存取數據信息和與用戶交互 在伺服器 執行ORACLE軟體 處理對ORACLE資料庫並發 共享數據存取 ORACLE允許上述兩部分在同一台計算機上 但當客戶部分和伺服器部分是由網連接的不同計算機上時 更有效

分布處理是由多台處理機分擔單個任務的處理 在ORACLE資料庫系統中分布處理的例子如

客戶和伺服器是位於網路連接的不同計算機上

單台計算機上有多個處理器 不同處理器分別執行客戶應用

參與分布式資料庫的每一伺服器是分別地獨立地管理資料庫 好像每一資料庫不是網路化的資料庫 每一個資料庫獨立地被管理 稱為場地自治性 場地自治性有下列好處

◆系統的結點可反映公司的邏輯組織

◆由局部數據梁培纖庫管理員控制局部數據 這樣每一個資料庫管理員責任域要小一些 可更好管理

◆只要一個資料庫和網路是可用 那麼全局資料庫可部分可用 不會因一個資料庫的故障而停止全部操作或引起性能瓶頸

◆故障恢復通常在單個結點上進行

◆每個局部資料庫存在一個數據字典

◆結點可獨立地升級軟體

可從分布式資料庫的所有結點存取模式對象 因此正像非分布的局部的DBMS 必須提供一種機制 可在局部資料庫中引用一個對象 分布式DBMS必須提供一種命名模式 以致中清分布式資料庫中一個對象可在應用中唯一標識和引用 一般在層次結構的每一層實施唯一性 分布式DBMS簡單地擴充層次命名模型 實施在網路上唯一資料庫命名 因此一個對象的全局對象名保證在分布式資料庫內是唯一

ORACLE允許在SQL語句中使用全局對象名引用分布式資料庫中的模式對象(表 視圖和過程) 在ORACLE中 一個模式對象的全局名由三部分組成 包含對象的模式名 對象名 資料庫名 其形式如

SCOTT EMP@SALES DIVISION ACME

一個遠程查詢為一查詢 是從一個或多個遠程表中選擇信息 這些表駐留在同一個遠程結點

一個分布式查詢可從兩個或多個結點檢索數據 一個分布式更新可修改兩個或兩個以上結點的數據

一個遠程事務為一個事務 包含一人或多個遠程語句 它所引用的全部是在同一個遠程結點上 一個分布式事務中一個事務 包含一個或多個語句修改分布式資料庫的兩個或多個不同結點的數據

在分布式資料庫中 事務控制必須在網路上直轄市 保證數據一致性 兩階段提交機制保證參與分布式事務的全部資料庫伺服器是全部提交或全部回滾事務中的語句

ORACLE分布式資料庫系統結構可由ORACLE資料庫管理員為終端用戶和應用提供位置透明性 利用視圖 同義詞 過程可提供ORACLE分布式資料庫系統中的位置透明性

ORACLE提供兩種機制實現分布式資料庫中表重復的透明性 錶快照提供非同步的表重復;觸發器實現同步的表的重復 在兩種情況下 都實現了對表重復的透明性

在單場地或分布式資料庫中 所有事務都是用MIT或ROLLBACK語句中止

二 分布式資料庫系統的分類

( ) 同構同質型DDBS 各個場地都採用同一類型的數據模型(譬如都是關系型) 並且是同一型號的DBMS

( )同構異質型DDBS 各個場地採用同一類型的數據模型 但是DBMS的型號不同 譬如DB ORACLE SYBASE SQL Server等

( )異構型DDBS 各個場地的數據模型的型號不同 甚至類型也不同 隨著計算機網路技術的發展 異種機聯網問題已經得到較好的解決 此時依靠異構型DDBS就能存取全網中各種異構局部庫中的數據

三 分布式資料庫系統主要特點

DDBS的基本特點

( )物理分布性 數據不是存儲在一個場地上 而是存儲在計算機網路的多個場地上

邏輯整體性 數據物理分布在各個場地 但邏輯上是一個整體 它們被所有用戶(全局用戶)共享 並由一個DDBMS統一管理

( )場地自治性 各場地上的數據由本地的DBMS管理 具有自治處理能力 完成本場地的應用(局部應用)

( )場地之間協作性 各場地雖然具有高度的自治性 但是又相互協作構成一個整體

DDBS的其他特點

( )數據獨立性

( )集中與自治相結合的控制機制

( )適當增加數據冗餘度

( )事務管理的分布性

四 分布式資料庫系統的優點

( )更適合分布式的管理與控制

分布式資料庫系統的結構更適合具有地理分布特性的組織或機構使用 允許分布在不同區域 不同級別的各個部門對其自身的數據實行局部控制 例如 實現全局數據在本地錄入 查詢 維護 這時由於計算機資源靠近用戶 可以降低通信代價 提高響應速度 而涉及其他場地資料庫中的數據只是少量的 從而可以大大減少網路上的信息傳輸量;同時 局部數據的安全性也可以做得更好

( )具有靈活的體系結構

集中式資料庫系統強調的是集中式控制 物理資料庫是存放在一個場地上的 由一個DBMS集中管理 多個用戶只可以通過近程或遠程終端在多用戶操作系統支持下運行該DBMS來共享集中是資料庫中的數據 而分布式資料庫系統的場地局部DBMS的自治性 使得大部分的局部事務管理和控制都能就地解決 只有在涉及其他場地的數據時才需要通過網路作為全局事務來管理 分布式DBMS可以設計成具有不同程度的自治性 從具有充分的場地自治到幾乎是完全集中式的控制

( )系統經濟 可靠性高 可用性好

與一個大型計算機支持一個大型的集中式資料庫在加一些進程和遠程終端相比 由超級微型計算機或超級小型計算機支持的分布式資料庫系統往往具有更高的性價比和實施靈活性 分布式系統比集中式系統具有更高的可靠性和更好的可用性 如由於數據分布在多個場地並有許多復制數據 在個別場地或個別通信鏈路發生故障時 不致於導致整個系統的崩潰 而且系統的局部故障不會引起全局失控

( )在一定條件下響應速度加快

如果存取的數據在本地資料庫中 那麼就可以由用戶所在的計算機來執行 速度就快

( )可擴展性好 易於集成現有系統 也易於擴充

對於一個企業或組織 可以採用分布式資料庫技術在以建立的若干資料庫的基礎上開發全局應用 對原有的局部資料庫系統作某些改動 形成一個分布式系統 這比重建一個大型資料庫系統要簡單 既省時間 又省財力 物力 也可以通過增加場地數的辦法 迅速擴充已有的分布式資料庫系統

五 分布式資料庫系統的劣勢

( )通信開銷較大 故障率高

例如 在網路通信傳輸速度不高時 系統的響應速度慢 與通信相關的因素往往導致系統故障 同時系統本身的復雜性也容易導致較高的故障率 當故障發生後系統恢復也比較復雜 可靠性有待提高

( )數據的存取結構復雜

一般來說 在分布時資料庫中存取數據 比在集中時資料庫中存取數據更復雜 開銷更大

( )數據的安全性和保密性較難控制

在具有高度場地自治的分布時資料庫中 不同場地的局部資料庫管理員可以採用不同的安全措施 但是無法保證全局數據都是安全的 安全性問題式分布式系統固有的問題 因為分布式系統式通過通信網路來實現分布控制的 而通信網路本身卻在保護數據的安全性和保密性方面存在弱點 數據很容易被竊取

分布式資料庫的設計 場地劃分及數據在不同場地的分配比較復雜 數據的劃分及分配對系統的性能 響應速度及可用性等具有極大的影響 不同場地的通信速度與局部資料庫系統的存取部件的存取速度相比 是非常慢的 通信系統有較高的延遲 在CPU上處理通信信息的代價很高 分布式資料庫系統中要注意解決分布式資料庫的設計 查詢處理和優化 事務管理及並發控制和目錄管理等問題

六 分布式資料庫系統 數據分片

類型

水平分片

按一定的條件把全局關系的所有元組劃分成若干不相交的子集 每個子集為關系的一個片段

垂直分片

把一個全局關系的屬性集分成若乾子集 並在這些子集上作投影運算 每個投影稱為垂直分片

導出分片

又稱為導出水平分片 即水平分片的條件不是本關系屬性的條件 而是其他關系屬性的條件

混合分片

以上三種方法的混合 可以先水平分片再垂直分片 或先垂直分片再水平分片 或其他形式 但他們的結果是不相同的

條件

( )完備性條件

必須把全局關系的所有數據映射到片段中 決不允許有屬於全局關系的數據卻不屬於它的任何一個片段

( )可重構條件

必須保證能夠由同一個全局關系的各個片段來重建該全局關系 對於水平分片可用並操作重構全局關系;對於垂直分片可用聯接操作重構全局關系

( )不相交條件

要求一個全局關系被分割後所得的各個數據片段互不重疊(對垂直分片的主鍵除外)

七 分布式資料庫系統 數據分配方式

( )集中式 所有數據片段都安排在同一個場地上

( )分割式

所有數據只有一份 它被分割成若干邏輯片段 每個邏輯片段被指派在一個特定的場地上

( )全復制式 數據在每個場地重復存儲 也就是每個場地上都有一個完整的數據副本

( )混合式 這是一種介乎於分割式和全復制式之間的分配方式

八 分布式資料庫系統 體系結構

數據分片和數據分配概念的分離 形成了 數據分布獨立型 概念

數據冗餘的顯式控制 數據在各個場地的分配情況在分配模式中一目瞭然 便於系統管理

局部DBMS的獨立性 這個特徵也稱為 局部映射透明性 此特徵允許我們在不考慮局部DBMS專用數據模型的情況下 研究DDB管理的有關問題

九 分布式資料庫管理系統

接受用戶請求 並判定把它送到哪裡 或必須訪問哪些計算機才能滿足該要求

訪問網路數據字典 了解如何請求和使用其中的信息

如果目標數據存儲於系統的多個計算機上 就必須進行分布式處理

通信介面功能 在用戶 局部DBMS和其他計算機的DBMS之間進行協調

在一個異構型分布式處理環境中 還需提供數據和進程移植的支持 這里的異構型是指各個場地的硬體 軟體之間存在著差別

分布式資料庫管理系統

❸ 如何處理大量數據並發操作

處理大量數據並發操作可以採用如下幾種方法:

1.使用緩存：使用程序直接保存到內存中。或者使用緩存框架: 用一個特定的類型值來保存，以區別空數據和未緩存的兩種狀態。

2.資料庫優化：表結構優化;SQL語句優化，語法優化和處理邏輯優化;分區;分表;索引優化;使用存儲過程代替直接操作。

3.分離活躍和攜數據:可以分為活躍用戶和不活躍用戶。

4.批量讀取和延遲修改: 高並發情況可以將多個查詢請求合並到一個。高並發且頻繁修改的可以暫存緩存中。

5.讀寫分離: 資料庫伺服器配置多個，配置主從資料庫。寫用主資料庫，讀用從資料庫。

6.分布式資料庫: 將不同的表存放到不同的資料庫中，然後再放到不同的伺服器中。

7.NoSql和Hadoop: NoSql，not only SQL。沒有關系型資料庫那麼多限制，比較靈活高效。Hadoop，將一個表中的數據分層多塊，保存到多個節點（分布式）。每一塊數據都有多個節點保正燃存（集群）。集群可以並行處理相同的數據，還可以保證數據的完整性。

拓展資料:

大數據（big data），指無法在一定時間范圍內用常規軟體工具進行捕捉、管理和處理的數據集合，是需要新處理模式才能具有更強的決策力、洞察發現力和流程優化能力的海量、高增長率喚清伏和多樣化的信息資產。

在維克托·邁爾-舍恩伯格及肯尼斯·庫克耶編寫的《大數據時代》中大數據指不用隨機分析法（抽樣調查）這樣捷徑，而採用所有數據進行分析處理。大數據的5V特點（IBM提出）：Volume（大量）、Velocity（高速）、Variety（多樣）、Value（低價值密度）、Veracity（真實性）。

❹ 如何處理資料庫並發問題

想要知道如何處理數據並發，自然需要先了解數據並發。

什麼是數據並發操作呢？
就是同一時間內，不同的線程同時對一條數據進行讀寫操作。

在互聯網時代，一個系統常常有很多人在使用，因此就可能出現高並發的現象，也就是不同的用戶同時對一條數據進行操作，如果沒有有效的處理，自然就會出現數據的異常。而最常見的一種數據並發的場景就是電商中的秒殺，成千上萬個用戶對在極端的時間內，搶購一個商品。針對這種場景，商品的庫存就是一個需要控制的數據，而多個用戶對在同一時間對庫存進行重寫，一個不小心就可能出現超賣的情況。

針對這種情況，我們如何有效的處理數據並發呢？

第一種方案、資料庫鎖
從鎖的基本屬性來說，可以分為兩種：一種是共享鎖（S），一種是排它鎖（X）。在MySQL的資料庫中，是有四種隔離級別的，會在讀寫的時候，自動的使用這兩種鎖，防止數據出現混亂。

這四種隔離級別分別是：

讀未提交（Read Uncommitted）
讀提交（Read Committed）
可重復讀（Repeated Read）
串列化（Serializable）
當然，不同的隔離級別，效率也是不同的，對於數據的一致性保證也就有不同的結果。而這些可能出現的又有哪些呢？

臟讀（dirty read）

當事務與事務之間沒有任何隔離的時候，就可能會出現臟讀。例如：商家想看看所有的訂單有哪些，這時，用戶A提交了一個訂單，但事務還沒提交，商家卻看到了這個訂單。而這時就會出現一種問題，當商家去操作這個訂單時，可能用戶A的訂單由於部分問題，導致數據回滾，事務沒有提交，這時商家的操作就會失去目標。

不可重復讀（unrepeatable read）

一個事務中，兩次讀操作出來的同一條數據值不同，就是不可重復讀。

例如：我們有一個事務A，需要去查詢一下商品庫存，然後做扣減，這時，事務B操作了這個商品，扣減了一部分庫存，當事務A再次去查詢商品庫存的時候，發現這一次的結果和上次不同了，這就是不可重復讀。

幻讀（phantom problem）

一個事務中，兩次讀操作出來的結果集不同，就是幻讀。

例如：一個事務A，去查詢現在已經支付的訂單有哪些，得到了一個結果集。這時，事務B新提交了一個訂單，當事務A再次去查詢時，就會出現，兩次得到的結果集不同的情況，也就是幻讀了。

那針對這些結果，不同的隔離級別可以干什麼呢？

「讀未提（Read Uncommitted）」能預防啥？啥都預防不了。

「讀提交（Read Committed）」能預防啥？使用「快照讀（Snapshot Read）」方式，避免「臟讀」，但是可能出現「不可重復讀」和「幻讀」。

「可重復讀（Repeated Red）」能預防啥？使用「快照讀（Snapshot Read）」方式，鎖住被讀取記錄，避免出現「臟讀」、「不可重復讀」，但是可能出現「幻讀」。

「串列化（Serializable）」能預防啥？有效避免「臟讀」、「不可重復讀」、「幻讀」，不過運行效率奇差。

好了，鎖說完了，但是，我們的資料庫鎖，並不能有效的解決並發的問題，只是盡可能保證數據的一致性，當並發量特別大時，資料庫還是容易扛不住。那解決數據並發的另一個手段就是，盡可能的提高處理的速度。

因為數據的IO要提升難度比較大，那麼通過其他的方式，對數據進行處理，減少資料庫的IO，就是提高並發能力的有效手段了。

最有效的一種方式就是：緩存
想要減少並發出現的概率，那麼讀寫的效率越高，讀寫的執行時間越短，自然數據並發的可能性就變小了，並發性能也有提高了。

還是用剛才的秒殺舉例，我們為的就是保證庫存的數據不出錯，賣出一個商品，減一個庫存，那麼，我們就可以將庫存放在內存中進行處理。這樣，就能夠保證庫存有序的及時扣減，並且不出現問題。這樣，我們的資料庫的寫操作也變少了，執行效率也就大大提高了。

當然，常用的分布式緩存方式有：Redis和Memcache，Redis可以持久化到硬碟，而Memcache不行，應該怎麼選擇，就看具體的使用場景了。

當然，緩存畢竟使用的范圍有限，很多的數據我們還是必須持久化到硬碟中，那我們就需要提高資料庫的IO能力，這樣避免一個線程執行時間太長，造成線程的阻塞。

那麼，讀寫分離就是另一種有效的方式了
當我們的寫成為了瓶頸的時候，讀寫分離就是一種可以選擇的方式了。

我們的讀庫就只需要執行讀，寫庫就只需要執行寫，把讀的壓力從主庫中分離出去，讓主庫的資源只是用來保證寫的效率，從而提高寫操作的性能。

❺ 如何處理高並發

處理高並發的六種方法

1：系統拆分，將一個系統拆分為多個子系統，用bbo來搞。然後每個系統連一個資料庫，這樣本來就一個庫，現在多個資料庫，這樣就可以抗高並發。

2：緩存，必須得用緩存。大部分的高並發場景，都是讀多寫少，那你完全可以在資料庫和緩存里都寫一份，然後讀的時候大量走緩存不就得了。畢竟人家redis輕輕鬆鬆單機幾萬的並發啊。沒問題的。所以你可以考的慮考慮你的項目里，那些承載主要請求讀場景，怎麼用緩存來抗高並發。

3：MQ(消息隊列)，必須得用MQ。可能你還是會出現高並發寫的場景，比如說一個業務操作里要頻繁搞資料庫幾十次，增刪改增刪改，瘋了。那高並發絕對搞掛你的系統，人家是緩存你要是用redis來承載寫那肯定不行，數據隨時就被LRU(淘汰掉最不經常使用的)了，數據格式還無比簡單，沒有事務支持。所以該用mysql還得用mysql啊。那你咋辦？用MQ吧，大量的寫請求灌入MQ里，排隊慢慢玩兒，後邊系統消費後慢慢寫，控制在mysql承載范圍之內。所以你得考慮考慮你的項目里，那些承載復雜寫業務邏輯的場景里，如何用MQ來非同步寫，提升並發性。MQ單機抗幾萬並發也是ok的。

4：分庫分表，可能到了最後資料庫層面還是免不了抗高並發的要求，好吧，那麼就將一個資料庫拆分為多個庫，多個庫來抗更高的並發；然後將一個表拆分為多個表，每個表的數據量保持少一點，提高sql跑的性能。

5：讀寫分離，這個就是說大部分時候資料庫可能也是讀多寫少，沒必要所有請求都集中在一個庫上吧，可以搞個主從架構，主庫寫入，從庫讀取，搞一個讀寫分離。讀流量太多的時候，還可以加更多的從庫。

6：solrCloud:
SolrCloud(solr 雲)是Solr提供的分布式搜索方案，可以解決海量數據的 分布式全文檢索，因為搭建了集群，因此具備高可用的特性，同時對數據進行主從備份，避免了單點故障問題。可以做到數據的快速恢復。並且可以動態的添加新的節點，再對數據進行平衡,可以做到負載均衡：

❻ java 如何並發更新資料庫同一條數據

分2分情況：

一.普通的單應用並發，使用關鍵字synchronized就可以實現。

二.多應用或多台並發，這時在由於2者並非同一應用，使用synchronized並不能滿足要求。此時，有下面幾種方案：

1. 資料庫行級鎖，優點是簡單粗暴，缺點是容易死鎖，非資料庫專業人事建議不使用。

2. 寫入請求分離成一個獨立項目，這就回到了第一種情況，優點是實現技術難度低，缺點是高並發性能相對不是很高。

3. 使用分布式事務管理，這個是目前高並發處理的最優方案了。

最後要說的沒有差的方案，每個方案都有其適用環境，請根據自身需求選擇對應方案。

❼ 雙十一是怎麼保證高並發，分布式系統中，數據一致性

前言 在系統開發過程中，經常遇到數據重復插入、重復更新、消息重發發送等等問題，因為應用系統的復雜邏輯以及網路交互存在的不確定性，會導致這一重復現象，但是有些邏輯是需要有冪等特性的，否則造成的後果會比較嚴重，例如訂單重復創建，這時候帶來的問題可是非同一般啊。 什麼是系統的冪等性 冪等是數據中得一個概念，表示N次變換和1次變換的結果相同。 高並發的系統如何保證冪等性？ 1.查詢 查詢的API，可以說是天然的冪等性，因為你查詢一次和查詢兩次，對於系統來講，沒有任何數據的變更，所以，查詢一次和查詢多次一樣的。 2.MVCC方案 多版本並發控制，update with condition，更新帶條件，這也是在系統設計的時候，合理的選擇樂觀鎖，通過version或者其他條件，來做樂觀鎖，這樣保證更新及時在並發的情況下，也不會有太大的問題。 例如：update table_xxx set name=#name#,version=version+1 where version=#version# ,或者是 update table_xxx set quality=quality-#subQuality# where quality-#subQuality# >= 0 。 3.單獨的去重表 如果涉及到的去重的地方特別多，例如ERP系統中有各種各樣的業務單據，每一種業務單據都需要去重，這時候，可以單獨搞一張去重表，在插入數據的時候，插入去重表，利用資料庫的唯一索引特性，保證唯一的邏輯。 4.分布式鎖 還是拿插入數據的例子，如果是分布是系統，構建唯一索引比較困難，例如唯一性的欄位沒法確定，這時候可以引入分布式鎖，通過第三方的系統，在業務系統插入數據或者更新數據，獲取分布式鎖，然後做操作，之後釋放鎖，這樣其實是把多線程並發的鎖的思路，引入多多個系統，也就是分布式系統中得解決思路。 5.刪除數據 刪除數據，僅僅第一次刪除是真正的操作數據，第二次甚至第三次刪除，直接返回成功，這樣保證了冪等。 6.插入數據的唯一索引 插入數據的唯一性，可以通過業務主鍵來進行約束，例如一個特定的業務場景，三個欄位肯定確定唯一性，那麼，可以在資料庫表添加唯一索引來進行標示。 這里有一個場景，API層面的冪等，例如提交數據，如何控制重復提交，這里可以在提交數據的form表單或者客戶端軟體，增加一個唯一標示，然後服務端，根據這個UUID來進行去重，這樣就能比較好的做到API層面的唯一標識。 7.狀態機冪等 在設計單據相關的業務，或者是任務相關的業務，肯定會涉及到狀態機，就是業務單據上面有個狀態，狀態在不同的情況下會發生變更，一般情況下存在有限狀態機，這時候，如果狀態機已經處於下一個狀態，這時候來了一個上一個狀態的變更，理論上是不能夠變更的，這樣的話，保證了有限狀態機的冪等。 以上就是高並發系統數據冪等的解決方案的資料整理，後續繼續補充相關知識，謝謝大家對本站的支持！