又一個多月沒冒泡了，其實最近學了些東西，但是沒有安排時間整理成博文，後續再奉上。最近還寫了一個發郵件的元件以及效能測試請看 《NET開發郵件傳送功能的全面教程(含郵件元件原始碼)》 ，還弄了個MSSQL引數化語法生成器，會在9月整理出來，有興趣的園友可以關注下我的部落格。

分享原由，最近公司用到，並且在找最合適的方案，希望大家多參與討論和提出新方案。我和我的小夥伴們也討論了這個主題，我受益匪淺啊……

博文示例：

今天分享的主題是：如何在高併發分散式系統中生成全域性唯一Id。

但這篇博文實際上是“半分享半討論”的博文：

1)半分享是我將說下我所瞭解到的關於今天主題所涉及的幾種方案。

2)半討論是我希望大家對各個方案都說說自己的見解，更加希望大家能提出更好的方案。（我還另外提問在此：，若你們有見解和新方案就在本博文留言吧，方便我整理更新到博文中，謝謝！）

我瞭解的方案如下……………………………………………………………………

1、使用資料庫自增Id

優勢：編碼簡單，無需考慮記錄唯一標識的問題。

缺陷：

1)在大表做水平分表時，就不能使用自增Id，因為Insert的記錄插入到哪個分表依分表規則判定決定，若是自增Id，各個分表中Id就會重複，在做查詢、刪除時就會有異常。

2)在對錶進行高併發單記錄插入時需要加入事物機制，否則會出現Id重複的問題。

3)在業務上操作父、子表（即關聯表）插入時，需要在插入資料庫之前

獲取max(id)用於標識父表和子表關係，若存在併發獲取max(id)的情況，max(id)會同時被別的執行緒獲取到。

4)等等。

結論：適合小應用，無需分表，沒有高併發效能要求。

2、單獨開一個數據庫，獲取全域性唯一的自增序列號或各表的MaxId

1)使用自增序列號表

專門一個數據庫，生成序列號。開啟事物，每次操作插入時，先將資料插入到序列表並返回自增序列號用於做為唯一Id進行業務資料插入。

注意：需要定期清理序列表的資料以保證獲取序列號的效率；插入序列表記錄時要開啟事物。

使用此方案的問題是：每次的查詢序列號是一個性能損耗；如果這個序列號列暴了，那就杯具了，你不知道哪個表使用了哪個序列，所以就必須換另一種唯一

Id方式如GUID。

2)使用MaxId表儲存各表的MaxId值

專門一個數據庫，記錄各個表的MaxId值，建一個儲存過程來取Id，邏輯大致為：開啟事物，對於在表中不存在記錄，直接返回一個預設值為1的鍵值，同時插入該條記錄到table_key表中。而對於已存在的記錄，key值直接在原來的key基礎上加1更新到MaxId表中並返回key。

使用此方案的問題是：每次的查詢MaxId是一個性能損耗；不過不會像自增序列表那麼容易列暴掉，因為是擺表進行劃分的。

我擷取此文中的sql語法如下：

第一步：建立表
create table table_key
(
       table_name   varchar(50) not null primary key,
       key_value    int         not null
)


第二步：建立儲存過程來取自增ID
create procedure up_get_table_key
(
   @table_name     varchar(50),
   @key_value      int output
)
as
begin
     begin tran
         declare @key  int
         
         --initialize the key with 1
         set @key=1
         --whether the specified table is exist
         if not exists(select table_name from table_key where [email protected]_name)
            begin
              insert into table_key values(@table_name,@key)        --default key vlaue:1
            end
         -- step increase
         else    
            begin
                select @key=key_value from table_key with (nolock) where [email protected]_name
                set @[email protected]+1
                --update the key value by table name
                update table_key set [email protected] where [email protected]_name
            end
        --set ouput value
    set @[email protected]

    --commit tran
    commit tran
        if @@error>0
      rollback tran
end

感謝園友的好建議：

1.（@輝_輝）建議給table_key中為每個表初始化一條key為1的記錄，這樣就不用每次if來判斷了。

2.（程式碼層上使用如下事物程式碼會導致併發重複問題.

TransactionOptions option = new TransactionOptions();
option.IsolationLevel = IsolationLevel.ReadUncommitted;
option.Timeout = new TimeSpan(0, 10, 0);
 
using (TransactionScope transaction = new TransactionScope(TransactionScopeOption.RequiresNew, option))
{
        //呼叫儲存過程
}

在諮詢過DBA後，這個儲存過程提高資料庫隔離級別會加大資料庫訪問壓力，導致響應超時問題。所以這個建議我們只能在程式碼編寫宣導上做。

3.（@土豆烤肉）儲存過程中不使用事物，一旦使用到事物效能就急劇下滑。直接使用UPDATE獲取到的更新鎖，即SQL SERVER會保證UPDATE的順序執行。（已在使用者過千萬的併發系統中使用）

create procedure [dbo].[up_get_table_key]
(
   @table_name     varchar(50),
   @key_value      int output
)
as
begin

	SET NOCOUNT ON;
	DECLARE @maxId INT
	UPDATE table_key
	SET @maxId = key_value,key_value = key_value + 1 
	WHERE [email protected]_name
	SELECT @maxId

end

結論：適用中型應用，此方案解決了分表，關聯表插入記錄的問題。但是無法滿足高併發效能要求。同時也存在單點問題，如果這個資料庫cash掉的話……

我們目前正頭痛這個問題，因為我們的高併發常常出現數據庫訪問超時，瓶頸就在這個MaxId表。我們也有考慮使用分散式快取（eg：memcached）快取第一次訪問MaxId表資料，以提高再次訪問速度，並定時用快取資料更新一次MaxId表，但我們擔心的問題是：

a)倘若快取失效或暴掉了，那快取的MaxId沒有更新到資料庫導致資料丟失，必須停掉站點來執行Select max(id)各個表來同步MaxId表。

b)分散式快取不是一儲存下去，其他伺服器上就立馬可以獲取到的，即資料存在不確定性。（其實也是快取的一個誤用，快取應該用來存的是頻繁訪問並且很少改動的內容）

改進方案：

整體思想：建立兩臺以上的資料庫ID生成伺服器，每個伺服器都有一張記錄各表當前ID的MaxId表，但是MaxId表中Id的增長步長是伺服器的數量，起始值依次錯開，這樣相當於把ID的生成雜湊到每個伺服器節點上。例如：如果我們設定兩臺資料庫ID生成伺服器，那麼就讓一臺的MaxId表的Id起始值為1（或當前最大Id+1），每次增長步長為2，另一臺的MaxId表的ID起始值為2（或當前最大Id+2），每次步長也為2。這樣就將產生ID的壓力均勻分散到兩臺伺服器上，同時配合應用程式控制，當一個伺服器失效後，系統能自動切換到另一個伺服器上獲取ID，從而解決的單點問題保證了系統的容錯。（Flickr思想）

但是要注意：1、多伺服器就必須面臨負載均衡的問題；2、倘若新增新節點，需要對原有資料重新根據步長計算遷移資料。

相關推薦