[发明专利]一种基于redis的排队方法和系统有效
申请号: | 201710391652.6 | 申请日: | 2017-05-27 |
公开(公告)号: | CN107135321B | 公开(公告)日: | 2019-12-06 |
发明(设计)人: | 陆洋智 | 申请(专利权)人: | 北京思特奇信息技术股份有限公司 |
主分类号: | H04M3/523 | 分类号: | H04M3/523 |
代理公司: | 11212 北京轻创知识产权代理有限公司 | 代理人: | 杨立<国际申请>=<国际公布>=<进入国 |
地址: | 100089 北京市海淀*** | 国省代码: | 北京;11 |
权利要求书: | 查看更多 | 说明书: | 查看更多 |
摘要: | |||
搜索关键词: | 一种 基于 redis 排队 方法 系统 | ||
本发明涉及一种基于redis的排队方法和系统。所述方法包括如下步骤:接收访客会话请求,生成请求ID,在排队列表中插入请求ID;获取曾服务客服列表,所有客服端的当前服务会话列表和当日已服务会话列表;获取所有在线客服ID,确定在线曾服务客服列表,所有在线客服端的在线当前服务会话列表和在线当日已服务会话列表;取出一个请求ID,根据曾服务权重、当前服务权重、当日已服务权重、在线曾服务客服列表、在线当前服务会话列表和在线当日已服务会话列表为请求ID确定匹配客服端。本发明实现了提升业务处理的能力和稳定性,均衡每个客服工作量。
技术领域
本发明属于通信技术领域,尤其涉及一种基于redis的排队方法和系统。
背景技术
在在线客服系统中,最核心的业务除了即时消息通讯外还有对访客会话请求的排队业务,传统的对访客会话请求的排队业务是将排队业务程序部署在单个服务器的内存中,并在内存中存储与访客会话请求对应的信息,内存只在单个服务器内时有效,内存中的排队业务程序不共享且不可分割,信息在内存中时才能对访客会话请求进行排队,无法进行分布式部署;当访客会话请求量增加时,单个服务器的处理能力低,用户体验度差;单个服务器宕机时排队业务中断,造成处理排队业务的系统稳定性差;排队机无法单独部署;排队过程只是从内存中获取一个访客会话请求,首选第一个客服端作为匹配客服端,此方式使得客服人员众多时每个客服的工作量不平衡。
发明内容
本发明所要解决的技术问题是针对现有技术的不足,提供一种基于redis的排队方法和系统。
本发明解决上述技术问题的技术方案如下:一种基于redis的排队方法,包括如下步骤:
S1,接收访客端发送的访客会话请求,根据访客会话请求生成请求ID,在预先创建的排队列表中插入请求ID;
S2,根据访客会话请求获取曾服务客服列表,获取所有客服端的当前服务会话列表和当日已服务会话列表;
S3,获取所有在线客服ID,根据所有在线客服ID和曾服务客服列表确定在线曾服务客服列表,根据所有在线客服ID、所有当前服务会话列表和当日已服务会话列表分别确定所有在线客服端的在线当前服务会话列表和在线当日已服务会话列表;
S4,从排队列表中取出一个请求ID,根据预设的曾服务权重、当前服务权重、当日已服务权重、在线曾服务客服列表、在线当前服务会话列表和在线当日已服务会话列表为所述一个请求ID确定匹配客服端。
本发明的有益效果是:通过根据访客会话请求生成请求ID,并将请求ID插入排队列表中,实现分布式部署,提升业务处理的能力和稳定性,提高用户体验度。通过曾服务权重、当前服务权重、当日已服务权重、在线曾服务客服列表、在线当前服务会话列表和在线当日已服务会话列表为取出的一个请求ID确定匹配客户端,实现了均衡每个客服的工作量,实现业务处理的可扩展性。
在上述技术方案的基础上,本发明还可以做如下改进:
进一步,所述S4步骤包括:
S41,从排队列表中取出一个请求ID;
S42,判断在线曾服务客服列表中是否有数据,是则执行S44,否则执行S43;
S43,根据预设的当前服务权重、当日已服务权重、在线当前服务会话列表和在线当日已服务会话列表为所述一个请求ID确定匹配客服端;
S44,根据预设的曾服务权重、当前服务权重、当日已服务权重、在线曾服务客服列表、在线当前服务会话列表和在线当日已服务会话列表为所述一个请求ID确定匹配客服端。
进一步,所述S43步骤包括:
该专利技术资料仅供研究查看技术是否侵权等信息,商用须获得专利权人授权。该专利全部权利属于北京思特奇信息技术股份有限公司,未经北京思特奇信息技术股份有限公司许可,擅自商用是侵权行为。如果您想购买此专利、获得商业授权和技术合作,请联系【客服】
本文链接:http://www.vipzhuanli.com/pat/books/201710391652.6/2.html,转载请声明来源钻瓜专利网。
- 上一篇:一种联络中心处理信息的方法和联络中心
- 下一篇:一种图像成型转换设备