一篇文了解分布式队列编程：从模型、实战到优化

状态机描述的是针对单个请求操作所引起状态变化,排重优化需要解决队列中所有请求的排重问题,需要对所有请求的状态机进行管理.这里只考虑单虚拟机内部对所有请求状态机的管理,对于跨虚拟机的管理可以采用类似的方法.对于多状态机管理主要包含三个方面：一致性问题、完整性问题和请求缓存驱逐问题.

一致性问题

一致性在这里要求同一请求的不同消费者只会操作一个状态机.由于每个请求都产生一个状态机,系统将会包含大量的状态机.为了兼顾性能和一致性,我们采用ConcurrentHashMap保存所有的状态机.用ConcurrentHashMap而不是对整个状态机队列进行加锁,可以提高并行处理能力,使得系统可以同时操作不同状态机.

为了避免处理同一请求的多消费者线程同时对ConcurrentHashMap进行插入所导致状态机不一致问题,我们利用了ConcurrentHashMap的putIfAbsent()方法.代码方案如下,key2Status用于存储所有的状态机.

消费者在处理请求之前,从状态机队列中读取排重状态机TrafficAutomate.如果没有找到,则创建一个新的状态机,并通过putIfAbsent()方法插入到状态机队列中.

完整性问题

完整性要求保障状态机Init,Decline四种状态正确、状态之间的转换也正确.由于状态机的操作非常轻量级,兼顾完整性和降低代码复杂度,我们对状态机的所有方法进行加锁.

请求缓存驱逐问题(Cache Eviction)

如果不同请求的数量太多,内存永久保存所有请求的状态机的内存开销太大.所以,某些状态机需要在恰当的时候被驱逐出内存.这里有两个思路：

• 当状态机返回Init状态时,清除出队列.
• 启动一个后台线程,定时扫描状态机队列,采用LRU等标准缓存清除机制.

标识问题

每个请求对应于一个状态机,不同的状态机采用不同的请求进行识别.

对于同一状态机的不同消费者,在单虚拟机方案中,我们采用线程id进行标识.

实施

排重优化的主要功能都是通过排重状态机(TrafficAutomate)和状态机队列(QueueCoordinator)来实施的.排重状态机描述的是针对单个请求的排重问题,状态机队列解决所有请求状态机的排重问题.

状态机实施(TrafficAutomate)

根据状态机模型,其主要操作为enQueue和deQueue,其状态由头部请求和尾部请求的状态共同决定,所以需要定义两个变量为head和tail,用于表示头部请求和尾部请求.为了确保多线程操作下状态机的完整性(Integraty),所有的操作都将加上锁.

enQueue操作

当一个消费者执行enQueue操作时：如果此时尾部请求不为空,根据等待唯一性要求,返回DECLINE,当前消费者应该抛弃该请求；如果头部请求为空,返回ACCPET,当前消费者应该立刻处理该消息；否则,返回BLOCK,该消费者应该等待,并不停的查看状态机的状态,一直到头部请求处理完成.enQueue代码如下：

deQueue操作

对于deQueue操作,首先将尾部请求赋值给头部请求,并将尾部请求置为无效.deQueue代码如下：

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!