1.業務系統：需要保證高一致性的交易系統；

　2.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時一次執行所有指令。

　　這樣大大減少了失敗的可能性。既可以近似看作事務，也可以保證高效能。

　　4、分散式事務的問題

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

　　對於分散式事務ebay已經提出瞭解決方案，最重要的技術就是訊息佇列和訊息應用狀態表。

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