UTM用户线程模型

UTM 用户线程模型

在一些金融交易处理、游戏数据处理等逻辑较为复杂的领域中，各个接口可能会交叉使用和修改一些资源数据，这样就很容易导致一些并发的问题，如果对于每个资源都要考虑如何保证其并发安全问题，那么整个分析过程就会变得很复杂，而复杂的逻辑往往容易有所疏漏。

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的开销太小）

5. 具有良好的 兼容性 Utm可以非常容易得应用在不同的服务端（像SmartFoxServer, Netty等）

详情见utm-x.x.x.doc