一种支持高并发、高可用的电子商城客服系统的制作方法

本发明属于信息技术领域，特别涉及一种支持高并发、高可用的电子商城客服系统。

背景技术：

电子商城系统通常会设置客服系统为客户服务，但是现有的客服系统存在如下问题：

1、响应较慢，由于采用客户端轮询的方式，用户得到客服的响应不够及时；

2、不支持支持海量数据，由于采用聊天记录保存再数据库，当累计数据达到上亿级别的时候，查询性能会很低，响应慢，需要定时删除旧的数据，难于维护且不利于统计分析运营数据；

3、不支持高并发、高可用，当在线用户量很高的时候，以及客户端轮询的机制，数据库承载很高的并发压力，数据库性能下降，客服系统可能出现拒绝服务等。

技术实现要素：

为解决上述技术问题，本发明公开了一种支持高并发、高可用的电子商城客服系统。本发明用kafka集群，对“客服服务”和“推送服务”做了解耦，在应对大量并发的消息发送时，“推送服务”能有条不紊从kafka集群消费队列数据，然后快速的推送给接收者；推送服务采用websocket服务器集群，集群的每个节点采用自身ip作为kafka的groupid，实现websocket服务器集群可扩展，高可用。

本发明的目的通过下述技术方案实现：

一种支持高并发、高可用的电子商城客服系统，包括客服服务端，由提供http服务的web服务器集群构成，用于客服登录、消息的上传、坐席管理、用户接待管理、消息保存到数据源、消息推送到kafka队列和供客户通过http接口登陆及发送消息；推送服务单元，用于订阅kafka消息队列、消息队列的消息；

kafka集群，用于提供消息队列的发布与订阅；

数据源，用于将坐席管理和用户接待管理数据持久化；

用户发送消息后进行队列排队，客服自客服服务端登陆推送服务单元得到分配到自身的用户队列信息；客服从数据源查询发送消息的用户的接待状态，若查询不到则将对应用户设置为“未接待”状态并持久化到数据源，并推送一条“用户等候接待”消息到kafka集群；kafka集群将“用户等候接待”消息通过websocket广播给所有的客服，所有的客服所在的前端浏览器收到“用户等候接待”消息后将“用户等候接待”消息对应的消息内的用户加入到“等候队列”；当某一客服服务端的客服接待消息内的用户后，客服服务端将息内的用户标记为“已接待”状态；并持久化到数据源，同时向kafka集群推送“用户已接待”的消息，将所有队列排队中的所述消息内的用户移除。

进一步的改进，所述数据源为mysql数据库。

进一步的改进，所述推送服务单元由websocket服务器集群组成。

进一步的改进，用户通过客服服务端的http接口发送消息给客服服务端，“客服服务端接收到消息后对消息的内容进行封装得到“消息体”，包括消息类型、发送者、接收者、内容类型和消息内容；

所述websocket服务器集群的每个节点采用自身ip作为kafka集群的集群id，节点消费相同的“消息体”，每个节点确定消费到的“消息体”内的“接收者”是否已经连接到本节点，如果没连接则丢弃该消息，否则推送“消息体”内的消息内容给“接收者”；这样当某个节点出现故障，“接收者”重连到另一个节点，由于另一个节点也消费到了同一份“消息体”，就可以将“消息体”内的消息内容推送给“接收者”，防止因为节点故障消息内容无法推送到目标用户，达到客服系统高可用的目的。

进一步的改进，还包括用于管理订单的订单管理系统和用于管理商品的商品管理系统；

若所述消息是一个订单消息，则从订单管理系统查询订单的详细信息，所述订单的详细信息包括订单价格、下单时间和收货地址，将订单的详细信息封装成json格式的“消息体”；“消息体”中消息类型为“聊天消息”，发送者为用户a，接收者为客服b，内容类型为“订单类型”，消息内容为订单的详细信息。

进一步的改进，若消息是一个商品消息，则商品管理系统查询商品的详细信息，商品的详细信息包括商品价格、商品名称和、商品规格，将品的详细信息封装成json格式的“消息体”，“消息体”中消息类型为“聊天消息”，发送者为用户a，接收者为用户b，内容类型为“商品类型”，消息内容为商品的详细信息。

进一步的改进，客服服务端封装好“消息体”后，将消息体保存到es，同时将消息体推送到kafka消息队列。

进一步的改进，还包括cdn资源存储，用于加速资源文件的下载与上传；所述资源文件包括图片和视频。

本发明的优点:

1、去除客户端轮询的机制，利用websocket技术，可以做到让服务端主动推送消息给客户端，这样客户端就可以得到快速响应。

2、聊天记录等海量数据，从持久化到mysql改为持久化到elasticsearch(简称es)。由于es是一个分布式可扩展的实时搜索和分析引擎，可以扩展到上百台服务器，处理pb级别的结构化或非结构化数据，所以即便我们的聊天记录等累计到几十亿的数据量级别，仍然可以满足快速查询聊天记录和统计运营数据的需求。

3、设计一个单独的“推送服务”，该服务有websocket服务器集群组成，其订阅kafka集群的消息，由于kafka具有高扩展性、削峰填谷、可恢复性、顺序保证、送达保证、异步通信等特性，非常适合作为我们推送服务的中间件。当高峰期有大量并发消息需要推送时，先经过kafka消息队列，而后由websocket服务器集群均匀平稳从kafka消息队列消费，可以避免高峰期大量并发带给“推送服务”的压力。

4、websocket服务器集群的每个节点采用自身ip作为kafka的groupid，这样每个节点可以一起消费topic相同的消息(每个节点消费的数据是相同的)，每个节点根据消费到的“消息体”内的“接收者”是否已经连接到本节点，如果没连接则丢弃该消息，否则推送该消息给“接收者”。这样当某个节点出现故障，“接收者”重连到另一个节点，由于另一个节点也消费到了同一份消息，就可以将该消息推送给“接收者”，不会因为节点故障就无法推送到目标用户，因此达到客服系统高可用的目的。

附图说明

图1为用户的接待排队流程图；

图2为推送服务工作流程图。

具体实施方式

下面结合实施例对本发明作进一步详细的描述，但本发明的实施方式不限于此。

本发明的客服系统主要由客服服务、kafka集群、推送服务、数据源(mysql和es)、cdn资源存储等模块构成。下面是对各模块机器功能的介绍：

1.客服服务，由提供http服务的web服务器集群构成，其主要有用户登录、消息的上传、坐席管理、用户接待管理、消息保存到数据源、消息推送到kafka队列、从电子商城查询订单与商品信息、消息体的封装等功能。

2.kafka集群，主要提供消息队列的发布与订阅功能。

3.推送服务，由提供websocket服务的web服务器集群构成，其主要功能：订阅kafka消息队列、消费消息队列的消息、拆解消息体发送给对应的客服和用户。

4.数据源，mysql数据库负责将坐席管理、用户接待管理等数据持久化，es负责将用户与客服聊天记录的消息体持久化

5.cdn资源存储，负责加速图片、视频等资源文件的下载与上传。

客服坐席“主动接待”用户的过程步骤如下所示：

1、用户a调用“客服服务”的http接口发送消息；

2、客服b登录客服后台，与“推送服务”的某台websocket服务器建立连接，订阅“推送服务”发送给客服b自己关于“用户接待”的消息；

3、“客服服务”从mysql数据源查询发送该消息的用户a的接待状态，若查询不到则将该用户a设置为“未接待”状态并持久化到mysql数据源，并推送一条“用户等候接待”的消息到kafka集群；

4、“推送服务”由于提前订阅了上述消息，于是可以从kafka集群获得该消息；

5、而后把该消息通过websocket广播给所有的客服，所有的客服所在的前端浏览器收到该消息后将消息内的用户加入到“等候队列”。

6、客服的前端浏览器会根据策略主动或被动的从“等候队列”加入到“正在接待队列”(比如空闲的前端浏览器会自动去接待用户，繁忙的前端浏览器会等候客服主动接待用户)，同时调用“客服服务”的“接待用户”http接口去更改用户的接待状态；

7、我们假设客服b接待了用户a，并调用了上述“接待用户”http接口，此时“客服服务”将用户a标记为“已接待”状态且被客服b接待，并持久化到mysql数据源，同时向kafka推送“用户已接待”的消息。

8、“推送服务”由于提前订阅了上述消息，于是可以从kafka集群获得该消息，而后把该消息广播给了所有客服，其他客服收到该消息，认为用户a已经被客服b接待，因此将前端浏览器的“等候队列”里自动把用户a移除，这样除了客服b其他所有的客服都不会接待用户a了，至此客服接待用户的详细过程结束。

用户首次进入聊天界面，聊天记录初始化的详细步骤如下：

1、用登录客服后台，“客服服务”对用户进行相应的登录鉴权；

2、用户的前端浏览器自动向“客服服务”请求最近的聊天记录；

3、“客服服务”从es查询最近该用户发出的聊天消息、最近客服发给该用户的聊天消息。

4、“客服服务”将查询到的上述聊天消息返回给用户，用户前端浏览器展示上述返回的聊天消息。

用户发送消息给客服的详细流程如下：：

1、用户a登录客服后台；

2、客服b所在前端浏览器与“推送服务”建立websocket连接并验证登录状态，订阅推送给自身的广播消息。

3、用户a调用“客服服务”的http接口发送一条消息给客服b，“客服服务”接收到消息后对消息的内容进行封装，封装后的“消息体”由消息类型、发送者、接收者、内容类型、消息内容等组成。

4、若消息是一个订单消息，则从电子商城的“订单管理系统”查询订单的详细信息，比如订单价格、下单时间、收货地址等信息，将上述订单信息按客服系统约定的固定格式封装成json格式的“消息体”。该“消息体”中消息类型为“聊天消息”，发送者为用户a，接收者为客服b，内容类型为“订单类型”，消息内容为订单的详细信息。

5、若消息是一个商品消息，则电子商城的“商品管理系统”查询商品的详细信息，比如商品价格、商品名称、商品规格等信息，将上述商品信息按客服系统约定的固定格式封装成json格式的“消息体”。该“消息体”中消息类型为“聊天消息”，发送者为用户a，接收者为用户b，内容类型为“商品类型”，消息内容为商品的详细信息。

6、“客服服务”封装好“消息体”后，将消息体保存到es，同时将消息体推送到kafka消息队列。

7、“推送服务”订阅并消费该消息队列，找到该消息体中接收者并通过websoket发送给对应的客服b，客服b所在前端浏览器获取到消息体并展示在浏览器。

本系统的主要功能有:

a客服管理，主要包括新增客服、编辑分组、删除客服、在线状态查询、接待会话数查询等功能。

b会话分配规则，主要有排队规则、分组分配规则、客服分配规则。

c用户排队管理，主要有接入用户、转接用户、排队时常查询等功能。

d历史会话，主要有用户昵称、接待客服、会话渠道、会话起始结束时间、会话时长等查询。

推送服务工作流程如图2所示：推送服务的websocket服务器节点启动后，以自身内部ip作为kafka的groupid订阅消息，这样所有节点可以订阅到相同的一份消息，用户连接到其中一个websocket节点，当客服给用户发送一个消息后，所有websocket服务器节点会从kafka队列获得相同的这个消息，因为只有一个websocket节点与用户有连接，所以所有的节点判断该用户是否连接在自身节点上，是的话将消息推送给用户，否则将该消息丢弃。这样所有的websocket节点是平行、可动态扩展的，可满足海量在线用户的连接。

用户接待排队流程如图1所示，描述了“自动分配”(由排队队列变化、关闭会话、客服变为“空闲”触发)和“主动分配”(客服接入和客服转接)的工作流程。

根据需要排队的顺序和分配规则根据需要有所不同，具体如下：

客服系统后台提供租户的配置功能:排队列表规则、分组分配规则、客服分配规则。

排队列表规则有2种方案：a、新进入排队的用户优先分配；b、等待时间长的用户优先分配。分组分配规则有2种方案：a、各分组优先级相同；b、各分组优先级不同(比如先分配给”售前组”、在分配给”售后组”)。客服分配规则有2种方案：a、接待量占比小的优先分配(接待量占比＝接待中用户数量/个人最大接待量)；b、接待量占比小优先分配(接待中用户数量)。

2、使用redis列表用作用户排队队列，由于每个租户的策略不一样，我们给每个租户单独分配一个排队队列。系统每次往排队队列新增用户时候，使用redis的lpush命令插入到队列的尾部，从队列抽取用户的时候根据租户策略(若策略是“新进入排队的用户优先分配”，则使用redis的lpop从redis列表尾部抽取用户，若策略是“等待时间长的用户优先分配”，使用redis的rpop从redis列表头部抽取用户)。

3、分组分配规则，若租户策略为“各分组优先级相同”，则租户下的客服优先级相同，若租户策略为“各分组优先级不同”，则租户下优先级高的“客服组”优先安排接待，如果该“客服组”全员接待繁忙或接待数超过其“最大接待量”，则安排优先级次一级的“客服组”接待用户。

4、客服分配规则，若租户策略为“接待量占比小的优先分配”，则计算每个客服的“接待量占比”(当前接待中用户数量/个人最大接待量)，计算结果值越小则客服优先级越大，越优先安排接待用户，若租户策略为“接待量优先分配”，则直接对比客服当前接待中用户数量，数量越小的客服优先级值越大，越优先安排接待用户。

根据上述规则客服系统的用户排队流程如下：

1.用户登录客服系统、发送消息

2.判断该用户是否已被接待，若被接待则不用排队，若用户没有别客服接待，则进入用户排队队列(每个租户有独立的排队队列)

3.判断用户排队队列是否有人，且租户下的客服是否空闲，且客服接待数未超过其“最大接待量”。

4.若不满足上述条件，则等待触发条件(有用户进入排队、客服上线变更状态为“空闲”、客服关闭会话结束接待旧用户)后重新进行“步骤3”。若满足上述条件，则根据租户的“分组分配规则”策略找到a个优先级高的客服，然后根据“客服分配规则”策略从这a个客服中找到优先级更高的n个客服。

5.根据租户的“排队列表规则”，若策略为“新进入排队的用户优先分配”，则从用户排队队列尾部抽取n个用户，反之从头部抽取n个用户。然后将这些用户分配给步骤4中的n个客服。

6.服务的发送广播给租户下所有客服，这些用户已经被客服接待。前端收到广播消息，将自身排队队列更新。

以上是客服系统的自动排队设计，手工分配(客服后台转接和客服接入)则不用排队等候系统分配，直接将用户从排队抽取，并分配给相应的客服，然后进行步骤6。

尽管本发明的实施方案已公开如上，但并不仅仅限于说明书和实施方案中所列运用，它完全可以被适用于各种适合本发明的领域，对于熟悉本领域的人员而言，可容易地实现另外的修改，因此在不背离权利要求及等同范围所限定的一般概念下，本发明并不限于特定的细节和这里所示出叙述。