UTM用戶線程模型
UTM 用戶線程模型
在一些金融交易處理、游戲數(shù)據(jù)處理等邏輯較為復雜的領域中，各個接口可能會交叉使用和修改一些資源數(shù)據(jù)，這樣就很容易導致一些并發(fā)的問題，如果對于每個資源都要考慮如何保證其并發(fā)安全問題，那么整個分析過程就會變得很復雜，而復雜的邏輯往往容易有所疏漏。
Utm就是設計來屏蔽單個用戶的并發(fā)問題的，就是用戶訪問自己的資源是不需要考慮其并發(fā)安全問題的（多個用戶訪問的資源依然需要處理），主要想法是將用戶的請求排序并調用線程池中的線程依次處理。
一個簡單的場景：用戶買入一個東西的總額是受限制的，用戶a發(fā)起兩次買入請求（請求1 和 請求2） 在通常情況下，需要在用戶買入請求中加入鎖或者使用原子類，從而避免 請求1 和 請求2 同時處理導致超過限制； 而在utm下則不需要考慮類似問題，用戶a的請求1執(zhí)行完了才會執(zhí)行請求2。 而現(xiàn)實業(yè)務中類似的場景有很多，使用utm確實使開發(fā)的復雜度降低。
這樣就不會有說一個用戶的兩個請求被同時處理這樣的情況，相對起來開發(fā)的復雜度就降低了很多，而且也意味著多個線程爭搶資源的概率減少了（一個用戶 最多只有一個請求正在被處理）。用戶的請求不會被并發(fā)處理，從單個用戶上來是比原來要慢點，但從硬件相對整個用戶群來說，通常的應用的用戶的數(shù)量都會遠遠 大于cpu的數(shù)量，所以這樣不會導致cpu利用不足問題，相反utm能更好的將cpu資源分配給各個用戶，競爭減少也意味著程序更高效了。Utm的核心 qtm本身雖然會有一些鎖操作，但都是一些小鎖塊，應對多個用戶的每秒幾千甚至上萬個的請求并沒有什么延遲，所以也就沒有打算開發(fā)基于CAS版本的qtm 的打算（服務處理的瓶頸通常出在涉及IO方面，特別是數(shù)據(jù)庫處理，相比起來utm的開銷有點微不足道）。
特點：
-
Utm保證用戶生命流程的完整性和執(zhí)行順序。 （eg：一個用戶登錄，如果他已經(jīng)登錄了，那么舊的用戶會被先退出，然后新的用戶再登錄） （eg：用戶發(fā)起 請求1 后 發(fā)起 請求2，則 請求1 一定先于 請求2 執(zhí)行）
-
用戶的請求被有序的執(zhí)行，所以用戶訪問自己的資源是不需要考慮其并發(fā)安全問題，降低了開發(fā)的復雜度。 （eg：有一個用戶未讀消息的統(tǒng)計，在utm中就可以直接是一個int類型保存在內存中，如果在其他沒有保證并發(fā)控制的地方則至少要聲明為AtomicInteger 或者使用鎖來維護這個字段）
-
提供用戶資源接口，提供了用戶生命流程中的各個重要點的切面，讓開發(fā)者可以更好的管理自己定義的用戶資源。 （eg：用戶隊列：在用戶開始登陸標志位設置成功后 申請，當用戶登錄連接檢查失敗、用戶退出的時候 釋放）
-
高并發(fā)性 Utm的核心qtm本身雖然有一些鎖操作，但都是一些小鎖塊，可以應對多個用戶的每秒幾千甚至上萬個的請求。 （服務處理的瓶頸通常出在涉及IO方面，特別是數(shù)據(jù)庫處理，相比起來utm的開銷太?。?/p>
-
具有良好的 兼容性 Utm可以非常容易得應用在不同的服務端（像SmartFoxServer, Netty等）
詳情見utm-x.x.x.doc