帮助中国移动设计10086的排队小模块

今天发现了伍迷的《大话数据结构》系列，应该不错，从第一篇开始阅读。因为之前就阅读过他的《大话设计模式》，觉得通俗易懂，而且从浅入深，结合实际情况，是一本不可多得的好书。

读到《《大话数据结构》第1章 数据结构绪论 1.2 你数据结构怎么学的？》这篇的时候，就出现了一个小的场景。他的学生小菜在工作中被分配了一个任务，完成一个客户排队模块的代码。小菜就建立一张表，保存每次的队列内容，客服空闲了，就拿出最早插入一条来给客服处理。结果被项目经理批了一顿，说他没有学过数据结构，用数据库干什么。小菜回去就改成了一个数组，不用数据库了，怕溢出就设置数组长度为100。小菜还是怕有问题，就请假了她的表哥大鸟。大鸟表哥还是那句话“你的数据结构怎么学的？”，然后指点小鸟改用数据结构中的【队列】来实现，就不用考虑溢出，也不用考虑处理一条请求之后，需要移动原队列数据的位置。

在博文的回复中，金色海洋就提出了：

客户排队模块?是什么场景什么需求呢？ 
估计弄来弄去还是离不开数据库。

伍迷回复到：

@金色海洋（jyk） 
你不妨想想10086打进去后，听音乐等待客服的情景。是你，你打算如何实现？

就这样，就引出了今天的题目：“帮助中国移动设计10086的排队小模块”。

那么到底这个排队小模块该如何设计呢？用不用数据库呢？如何用数据库呢？什么时候用呢？用不用有什么区别呢？在下面我会提出自己的一些小观点，还请各位看完之后，踊跃提出自己的见解，给出更好的答案。那么，我先抛砖引玉了。（以下都是我的个人观点，有偏颇的地方，还请各位及时指出，本人先谢过了）

按照伍迷文中的意思，以及他的答复，我猜测是他的意思是不需要数据库的辅助，直接使用一个队列Queue，利用队列的特点，先进先出，没有空间限制，不用检查溢出。进来一个请求就入队，如果有客服空闲，就出队一个请求，交给空闲的客服进行处理。

我想用到客服系统的用户，肯定是服务的对象量上来了，不是搞几个电话，每个人守着接电话就可以解决的了，需要一个系统来协调这些请求。但是请求的量大了的话，都放在内存的一个队列中，内存占用会越来越多，就算能加内存估计也会不够用的吧。光从这点看，只用内存队列应该就满足不了实际需求了吧。

我觉得应该辅助以数据库。当然了，不是每进来一条都插入数据库，然后再取出来给空闲的客服，那么这样也太浪费了。不过我想，如果需要记录这些客服请求的详细信息的话，而且客服一般都需要客户最后进行评价，每条都记录也就在所难免了。

队列还是需要的，但是可以限制一个上限，让他不至于无限的扩大，超出上限的那些请求先进入数据库，然后再等队列元素不足上限的时候，取一些来填补到队列中。

当然也不是队列一有不足，就取一条出来，那么就和插入一条，然后取出一条没有区别了。是给队列设计一个最小值，小于最小值之后，就从数据库获取max-min条请求来进行处理。

但是我又想到，请求就算记录到数据库，也不能切断请求连接，因为客户还在等回复呢。切断了意味着还需要再次回拨回去，应该没有这么做的吧。客户等待的过程中，都是告诉客户坐席忙，然后让客户决定【继续等待】还是【挂断稍后再打来】，继续等待的就播放一段音乐给客户。所以继续等待的客户请求还是需要保存在队列中，否则没有办法继续通话了。

数据记录肯定是需要的，应该不会是在请求来了之后就记录吧，有可能会是在处理完毕之后，连带客户的评价，一起进入一个进行数据记录的队列，等待数据的持久化。当然，这就意味着，那些挂断的客户请求就丢失了，可能还是需要先记录的，处理之后，评价之后更新相应的信息。而且，在更新的时候，会检查是否存在之前的记录，如果存在就是更新操作，没有的话，就是插入操作，连带请求信息一起插入。

看来这些请求还是都在队列中的，但是一直都占用内存肯定也不是办法吧。应该有更好的解决方式。

我又想了一种，还是将请求分成两部分，一部分在内存的队列中，一部分估计还是要持久化到某种设备中的，然后需要内存维护一个未处理的请求列表，这个列表包含全部的请求，保存内存队列中的未处理请求和被持久化的未处理请求。如果当前请求都处理完毕，或者当前未处理请求小于一个数值，就从持久化的未处理请求中，激活一些放入内存队列中。

当然，还需要考虑多台服务器的情况，分布式的数据存放和共享。共享一个请求队列，和持久化队列。

 

没有什么结论，上面就是我想到的一些办法和遇到的一些疑惑，有哪位可以帮助我解释一下呢？大家也可以提出自己的见解，我们一起来完善这样一个模块。

本文转自 virusswb 51CTO博客，原文链接：http://blog.51cto.com/virusswb/548679，如需转载请自行联系原作者