UTM 用戶線程模型

Utm-簡介

 

Git@OSC: http://git.oschina.net/daemon_c/UTM  ( utm相關：http://git.oschina.net/daemon_c/QTM)

 

UTM-Demo

Git@OSC: http://git.oschina.net/daemon_c/UTM-demo (SmartFoxServer,Netty)

 

 

在一些金融交易處理、遊戲數據處理等邏輯較爲複雜的領域中，各個接口可能會交叉使用和修改一些資源數據，這樣就很容易致使一些併發的問題，若是對於每一個資源都要考慮如何保證其併發安全問題，那麼整個分析過程就會變得很複雜，而複雜的邏輯每每容易有所疏漏。

 

Utm就是設計來屏蔽單個用戶的併發問題的，就是用戶訪問本身的資源是不須要考慮其併發安全問題的（多個用戶訪問的資源依然須要處理），主要想法是將用戶的請求排序並調用線程池中的線程依次處理。

 

一個簡單的場景：用戶買入一個東西的總額是受限制的，用戶a發起兩次買入請求（請求1 和請求2）

在一般狀況下，須要在用戶買入請求中加入鎖或者使用原子類，從而避免 請求1 和 請求2 同時處理致使超過限制；

而在utm下則不須要考慮相似問題，用戶a的請求1執行完了纔會執行請求2。

而現實業務中相似的場景有不少，使用utm確實使開發的複雜度下降。

 

這樣就不會有說一個用戶的兩個請求被同時處理這樣的狀況，相對起來開發的複雜度就下降了不少，並且也意味着多個線程爭搶資源的機率減小了（一個用戶最多隻有一個請求正在被處理）。用戶的請求不會被併發處理，從單個用戶上來是比原來要慢點，但從硬件相對整個用戶羣來講，一般的應用的用戶的數量都會遠遠大於cpu的數量，因此這樣不會致使cpu利用不足問題，相反utm能更好的將cpu資源分配給各個用戶，競爭減小也意味着程序更高效了。Utm的核心qtm自己雖然會有一些鎖操做，但都是一些小鎖塊，應對多個用戶的每秒幾千甚至上萬個的請求並無什麼延遲，因此也就沒有打算開發基於CAS版本的qtm的打算（服務處理的瓶頸一般出在涉及IO方面，特別是數據庫處理，相比起來utm的開銷有點微不足道）。

 

 

特色：

1.      Utm保證用戶生命流程的完整性和執行順序。

（eg：一個用戶登陸，若是他已經登陸了，那麼舊的用戶會被先退出，而後新的用戶再登陸）

（eg：用戶發起 請求1 後 發起 請求2，則 請求1 必定先於 請求2 執行）

 

2.      用戶的請求被有序的執行，因此用戶訪問本身的資源是不須要考慮其併發安全問題，下降了開發的複雜度。

（eg：有一個用戶未讀消息的統計，在utm中就能夠直接是一個int類型保存在內存中，若是在其餘沒有保證併發控制的地方則至少要聲明爲AtomicInteger 或者使用鎖來維護這個字段）

 

3.      提供用戶資源接口，提供了用戶生命流程中的各個重要點的切面，讓開發者能夠更好的管理本身定義的用戶資源；並提供在異常狀況下恢復用戶隊列的處理。

（eg：用戶隊列：在用戶開始登錄標誌位設置成功後 申請，當用戶登陸鏈接檢查失敗、用戶退出的時候釋放）

 

4.      高併發性

Utm的核心qtm自己雖然有一些鎖操做，但都是一些小鎖塊，能夠應對多個用戶的每秒幾千甚至上萬個的請求（服務處理的瓶頸一般出在涉及IO方面，特別是數據庫處理，相比起來utm的開銷過小）；並提供實現異步操做的接口（掛起和恢復當前隊列，詳見9.用戶隊列管理）

 

5.      具備良好的 兼容性

Utm能夠很是容易得應用在不一樣的服務端（像SmartFoxServer, Netty等）

 

 

 

1.Utm簡介

2. Utm 模塊設計

3. Utm詳細實現-用戶生命流程

4. Utm詳細實現-用戶資源管理

5.Utm線程模型

6. Utm示例-公共部分

7. Utm示例-SmartFoxServer集成

8. Utm示例-Netty集成

9.(1.0.2版本更新)用戶隊列管理 與 用戶異常處理