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

典型的后台任务处理应用包括工单处理、火车票预订系统、机票选座等.我们所面对的问题是为运营人员创建工单.一次可以为多个运营人员创建多个工单.这个应用场景和火车票购买非常类似.工单相对来说更加抽象,所以,下文会结合火车票购买和运营人员工单分配这两种场景同时讲解.

典型的工单创建要经历两个阶段：数据筛选阶段、工单创建阶段.例如,在火车票预订场景,数据筛选阶段用户选择特定时间、特定类型的火车,而在工单创建阶段,用户下单购买火车票.

挑战

工单创建往往会面临如下挑战：

• 数据一致性问题.以火车票预订为例,用户筛选火车票和最终购买之间往往有一定的时延,意味着两个操作之间数据是不一致的.在筛选阶段,工程师们需决定是否进行车票锁定,如果不锁定,则无法保证出票成功.反之,如果在筛选地时候锁定车票,则会大大降低系统效率和出票吞吐量.

• 约束问题.工单创建需要满足很多约束,主要包含两种类型：动态约束,与操作者的操作行为有关,例如购买几张火车票的决定往往发生在筛选最后阶段.隐性约束,这种约束很难通过界面进行展示,例如一个用户购买了5张火车票,这些票应该是在同一个车厢的临近位置.

• 优化问题.工单创建往往是约束下的优化,这是典型的统筹优化问题,而统筹优化往往需要比较长的时间.
• 响应时间问题.对于多任务工单,一个请求意味着多个任务产生.这些任务的创建往往需要遵循事务性原则,即All or Nothing.在数据层面,这意味着工单之间需要满足串行化需求(Serializability).大数据量的串行化往往意味着锁冲突延迟甚至失败.无论是延迟机制所导致的长时延,还是高创建失败率,都会大大伤害用户体验.

构思

如果将用户筛选的最终规则做为消息存储下来,并发送给工单创建系统.此时,工单创建系统将具备创建工单所需的全局信息,具备在满足各种约束的条件下进行统筹优化的能力.如果工单创建阶段采用单实例部署,就可以避免数据锁定问题,同时也意味着没有锁冲突,所以也不会有死锁或任务延迟问题.

居于以上思路,在多工单处理系统的模型中,筛选阶段的规则创建系统将充当生产者角色,工单创建系统将充当消费者角色,筛选规则将作为消息在两者之间进行传递.这就是典型的分布式队列编程架构.根据工单创建量的不同,可以采用数据库或开源的分布式消息中间件作为分布式队列.

架构

（编辑：网站开发网_盐城站长网 ）

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