事務型系統由sql遷移到nosql問題總結

場景：

業務系統：需要保證高一緻性的交易系統

nosql資料庫：簡單的key value型資料庫，用hash實作的key value。 在這樣的場景下通常會面臨的問題如下：

1、表中有多個索引的問題。

例如表 t_acct(a,b,c) 索引為a，b。業務系統會以a b為key做查詢，也會對b進行修改。

解決這樣的問題是把表進行拆分為,存入key value資料庫時，拆分為兩條資料

(a,a b c) (b, a b c)

但是這樣帶來兩個問題1、資料備援 2、單條記錄操作的原子型。資料備援可以忍受，但是操作的原子性是無法忍受的，對于這個問題後邊後又絕方案。 2、需要對表範圍查找的問題

對于key value資料庫，範圍查找的場景，暫時沒有看到相關解決方案。但是一般範圍查找都是offline的應用，可以通過準實時同步key value資料庫的資料到關系型資料庫中來解決。 3、單機事務的問題

通常key value型的記憶體資料庫，不支援事務，但是也有通過近似的機制來模拟事務的情況。

在redis上，事務是通過multi指令來簡單支援的。先發送指令，調用exec時一次執行所有指令。

redis> multi

OK

redis> incr a

QUEUED

redis> incr b

QUEUED

redis> exec

1. (integer) 1

2. (integer) 1

這樣大大減少了失敗的可能性。既可以近似看作事務，也可以保證高性能。 4、分布式事務的問題

通常銷售操作要對兩個表進行操作，使用者資訊表和訂單表，在分布式環境下就涉及到了分布式事務。

對于分布式事務ebay已經提出了解決方案，最重要的技術就是消息隊列和消息應用狀态表。

詳細說明可以參考 http://queue.acm.org/detail.cfm?id=1394128