在线客服技术的解决方案
发布网友
发布时间：2022-04-24 01:54
共3个回答
热心网友
时间：2023-10-20 05:09
1、 轮询
这是一种比较古老而简单的解决方案，也就是定时刷新，在线客服在聊天的时候，aJax在后台定时获取数据，如果接收到发送过来的消息的话，则将消息显示在聊天框上。
这种技术的缺点就是后台刷新太频繁了，而很多刷新都是没有数据返回了，导致性能的下降。
2、 长连接
这种技术有称为“长轮询”，它是基于轮询技术的，但有所改进，客户端向服务端发起请求的时候，服务端不会直接返回，而是会阻塞请求，直到服务器读取到消息后才返回，这个时候，客户端才调用回调函数，将读取到的消息显示出来。
这里讲的在线客服系统将选用该技术来实现。
图2. 基于长轮询的服务器推模型
消息
这种解决方案采用一个作为client的applet，它使用TCP/IP或者无连接的UDP、甚至多播协议来建立与消息中间键server的通讯，然后由server推送消息给client。你可以从例如SoftWired的iBus、IBM的MQSeries、BEA的WebLogic Event这些消息产品中直接挑选，或者自己使用基于socket的定制开发消息软件。
Comet技术Commet是一种使用HTTP长连接，无需浏览器安装插件的“服务器推”方案。它有两者方案：基于aJax的长轮询方式；基于iframe和htmlfile的流方式。这里，我们只关注里面的基于aJax的长轮询方式。
Pushlet是一个开源的Comet框架，其中在设计上有很多值得借鉴的地方，能够使用它来开发一个不是大规模的在线客服系统。而对于大型商用的在线客服系统，我觉得它还无法胜任。
负载均衡（分布式部署）一个正式商用的在线客服系统，不可能只在一个WEB服务器部署，这样子，性能和容量都很难扩展，所以必然是允许分布式部署的，通过负载均衡设备（或软件）来实现分布式访问。
如果采用分布式部署的话，那么就涉及到聊天的数据保存在哪里的问题。是保存在web服务器上，还是数据库呢？如果是单web服务器的话，那肯定是保存在web服务器上，其流程大概如下：
1、 用户发送消息是，系统将数据保存在web服务器（同时也保存数据库）上。
2、 客服对应的长连接获取web服务器上的数据，然后在客服的页面上显示出来。
3、 客服回复聊天信息，系统将数据保存到web服务器（同时也保存数据库）上。
4、 用户所在的长连接获取web服务器上的数据，然后在用户的页面上显示处理。
由于从web服务器上获取数据比在数据库获取数据的效率高，所以上面的逻辑是合理的，但是，基于分布式部署的环境下，他存在多个web服务器，那么发起聊天的消息应该保存在哪台服务器上呢？还是所有的服务器都保存一次呢？在分布式环境下存在一些像JBossCache等缓存同步的技术，但对应在线聊天系统，实时性的要求非常高，是否存在实时性的问题呢？
另外一个，基于安全的考虑，一般需要将用户所访问的功能放到一个web服务器集群上，客服所访问的功能放到另外一个web服务器集群上，两个web服务器集群的网络需要隔离，以防止黑客的攻击。这就又出现一个问题，如果用户发送的消息放到用户的web服务器上，那么客服如果获取到该消息呢？同理，用户的web服务器有如果获取客服web服务器对应的消息呢？
那么放到数据库来实现呢？把聊天记录都放到数据库中，用户和客服都从数据库获取聊天的信息。这样子的话，那么数据库的负荷将非常大，随着用户数的不断增加，数据库负荷越来越大，而且，在大用户下，存储都是非常频繁的，将所有人的聊天信息放到数据库上，是不明智的。还有一个安全上的考虑，一般实现用户的功能都不直接访问数据库，一般会经过一个中间的服务器作为中转，那么如果聊天信息从数据库取的话，效率则会更低。
那么，能不能像QQ那样，聊天双方直接建立连接，实时发送呢？其实，这是一种相对老点的技术，一般是采用Socket，或者UDP，实现双方的通讯。这种机制的缺点客户端可能需要采用applet插件或ActiveX插件，通讯时有比较大的性能消耗，最重要的一点，这些技术受网络的影响特别大，在一个环境下可以正常使用，在另外一个环境下，可能就无法正常使用了。所以，本文考虑的是采用aJax长轮询方式来实现的。
在这里，我建议客服的聊天数据从数据库读取，而用户的聊天数据从web服务器上读取。这是因为客服的数据相对比用户少很多，直接从数据库读取聊天数据，对数据库的性能影响较少，而用户的数量庞大，直接从数据库读取，无法满足要求。
那么，客服是将回复数据写到客服的web服务器，还是用户的web服务器呢？我的建议是写到用户的web服务器，因为用户的数据量非常庞大，用户从用户的web服务器获取数据，要比从客服的web服务器获取数据，性能要高得多。客服每次发送聊天信息的时候，往用户的web服务器写数据，虽然效率低，但由于客服的数据量小，并不影响性能。
另外，在分布式部署下，数据该记得所以的web服务器，还是某台特定的web服务器呢？我建议写到某个特定的web服务器上，这样避免客服每发送一条聊天信息，都要往所有的web服务器写数据，这会影响性能，但web服务器不断增加的时候，性能会随之下降。
那么，客服往哪台特定的web服务器写数据呢？用户又如何知道从哪台特定的web服务器上获取数据呢？这个，我们在用户登陆，负载均衡服务器给其分配到某个特定的服务器的时候，就可以将这个特定服务器的IP记录下来，客服就可以往这台机器发消息了，而用户也同样可以从该IP获取数据了。
热心网友
时间：2023-10-20 05:09
热心网友
时间：2023-10-20 05:10
智慧营销
以云计算和人工智能技术为基础，为具有主动呼出需求的企业提供大规模营销平台解决方案，并基于历史数据分析客户意向行为，助力销售代表持续转化商机。
部署灵活
一套平台，集中+分布部署，快速上线，统一管理。全国分布式座席即开即用。
智慧呼叫
灵活管理通信资源，有效提高接通率。号码状态检测，筛选出异常号码，提高座席拨打效率。
AI赋能座席
对话助手智能推荐话术。对历史数据聚类分析学习，提高座席业务能力。
即时营销
客服热线7*移动端处理客户资料、通话记录及录音，时刻把握商机。销售业务微信监控，实时了解客户进展。
热心网友
时间：2023-10-20 05:09
1、 轮询
这是一种比较古老而简单的解决方案，也就是定时刷新，在线客服在聊天的时候，aJax在后台定时获取数据，如果接收到发送过来的消息的话，则将消息显示在聊天框上。
这种技术的缺点就是后台刷新太频繁了，而很多刷新都是没有数据返回了，导致性能的下降。
2、 长连接
这种技术有称为“长轮询”，它是基于轮询技术的，但有所改进，客户端向服务端发起请求的时候，服务端不会直接返回，而是会阻塞请求，直到服务器读取到消息后才返回，这个时候，客户端才调用回调函数，将读取到的消息显示出来。
这里讲的在线客服系统将选用该技术来实现。
图2. 基于长轮询的服务器推模型
消息
这种解决方案采用一个作为client的applet，它使用TCP/IP或者无连接的UDP、甚至多播协议来建立与消息中间键server的通讯，然后由server推送消息给client。你可以从例如SoftWired的iBus、IBM的MQSeries、BEA的WebLogic Event这些消息产品中直接挑选，或者自己使用基于socket的定制开发消息软件。
Comet技术Commet是一种使用HTTP长连接，无需浏览器安装插件的“服务器推”方案。它有两者方案：基于aJax的长轮询方式；基于iframe和htmlfile的流方式。这里，我们只关注里面的基于aJax的长轮询方式。
Pushlet是一个开源的Comet框架，其中在设计上有很多值得借鉴的地方，能够使用它来开发一个不是大规模的在线客服系统。而对于大型商用的在线客服系统，我觉得它还无法胜任。
负载均衡（分布式部署）一个正式商用的在线客服系统，不可能只在一个WEB服务器部署，这样子，性能和容量都很难扩展，所以必然是允许分布式部署的，通过负载均衡设备（或软件）来实现分布式访问。
如果采用分布式部署的话，那么就涉及到聊天的数据保存在哪里的问题。是保存在web服务器上，还是数据库呢？如果是单web服务器的话，那肯定是保存在web服务器上，其流程大概如下：
1、 用户发送消息是，系统将数据保存在web服务器（同时也保存数据库）上。
2、 客服对应的长连接获取web服务器上的数据，然后在客服的页面上显示出来。
3、 客服回复聊天信息，系统将数据保存到web服务器（同时也保存数据库）上。
4、 用户所在的长连接获取web服务器上的数据，然后在用户的页面上显示处理。
由于从web服务器上获取数据比在数据库获取数据的效率高，所以上面的逻辑是合理的，但是，基于分布式部署的环境下，他存在多个web服务器，那么发起聊天的消息应该保存在哪台服务器上呢？还是所有的服务器都保存一次呢？在分布式环境下存在一些像JBossCache等缓存同步的技术，但对应在线聊天系统，实时性的要求非常高，是否存在实时性的问题呢？
另外一个，基于安全的考虑，一般需要将用户所访问的功能放到一个web服务器集群上，客服所访问的功能放到另外一个web服务器集群上，两个web服务器集群的网络需要隔离，以防止黑客的攻击。这就又出现一个问题，如果用户发送的消息放到用户的web服务器上，那么客服如果获取到该消息呢？同理，用户的web服务器有如果获取客服web服务器对应的消息呢？
那么放到数据库来实现呢？把聊天记录都放到数据库中，用户和客服都从数据库获取聊天的信息。这样子的话，那么数据库的负荷将非常大，随着用户数的不断增加，数据库负荷越来越大，而且，在大用户下，存储都是非常频繁的，将所有人的聊天信息放到数据库上，是不明智的。还有一个安全上的考虑，一般实现用户的功能都不直接访问数据库，一般会经过一个中间的服务器作为中转，那么如果聊天信息从数据库取的话，效率则会更低。
那么，能不能像QQ那样，聊天双方直接建立连接，实时发送呢？其实，这是一种相对老点的技术，一般是采用Socket，或者UDP，实现双方的通讯。这种机制的缺点客户端可能需要采用applet插件或ActiveX插件，通讯时有比较大的性能消耗，最重要的一点，这些技术受网络的影响特别大，在一个环境下可以正常使用，在另外一个环境下，可能就无法正常使用了。所以，本文考虑的是采用aJax长轮询方式来实现的。
在这里，我建议客服的聊天数据从数据库读取，而用户的聊天数据从web服务器上读取。这是因为客服的数据相对比用户少很多，直接从数据库读取聊天数据，对数据库的性能影响较少，而用户的数量庞大，直接从数据库读取，无法满足要求。
那么，客服是将回复数据写到客服的web服务器，还是用户的web服务器呢？我的建议是写到用户的web服务器，因为用户的数据量非常庞大，用户从用户的web服务器获取数据，要比从客服的web服务器获取数据，性能要高得多。客服每次发送聊天信息的时候，往用户的web服务器写数据，虽然效率低，但由于客服的数据量小，并不影响性能。
另外，在分布式部署下，数据该记得所以的web服务器，还是某台特定的web服务器呢？我建议写到某个特定的web服务器上，这样避免客服每发送一条聊天信息，都要往所有的web服务器写数据，这会影响性能，但web服务器不断增加的时候，性能会随之下降。
那么，客服往哪台特定的web服务器写数据呢？用户又如何知道从哪台特定的web服务器上获取数据呢？这个，我们在用户登陆，负载均衡服务器给其分配到某个特定的服务器的时候，就可以将这个特定服务器的IP记录下来，客服就可以往这台机器发消息了，而用户也同样可以从该IP获取数据了。
热心网友
时间：2023-10-20 05:09
热心网友
时间：2023-10-20 05:10
智慧营销
以云计算和人工智能技术为基础，为具有主动呼出需求的企业提供大规模营销平台解决方案，并基于历史数据分析客户意向行为，助力销售代表持续转化商机。
部署灵活
一套平台，集中+分布部署，快速上线，统一管理。全国分布式座席即开即用。
智慧呼叫
灵活管理通信资源，有效提高接通率。号码状态检测，筛选出异常号码，提高座席拨打效率。
AI赋能座席
对话助手智能推荐话术。对历史数据聚类分析学习，提高座席业务能力。
即时营销
客服热线7*移动端处理客户资料、通话记录及录音，时刻把握商机。销售业务微信监控，实时了解客户进展。
热心网友
时间：2023-10-20 05:09
1、 轮询
这是一种比较古老而简单的解决方案，也就是定时刷新，在线客服在聊天的时候，aJax在后台定时获取数据，如果接收到发送过来的消息的话，则将消息显示在聊天框上。
这种技术的缺点就是后台刷新太频繁了，而很多刷新都是没有数据返回了，导致性能的下降。
2、 长连接
这种技术有称为“长轮询”，它是基于轮询技术的，但有所改进，客户端向服务端发起请求的时候，服务端不会直接返回，而是会阻塞请求，直到服务器读取到消息后才返回，这个时候，客户端才调用回调函数，将读取到的消息显示出来。
这里讲的在线客服系统将选用该技术来实现。
图2. 基于长轮询的服务器推模型
消息
这种解决方案采用一个作为client的applet，它使用TCP/IP或者无连接的UDP、甚至多播协议来建立与消息中间键server的通讯，然后由server推送消息给client。你可以从例如SoftWired的iBus、IBM的MQSeries、BEA的WebLogic Event这些消息产品中直接挑选，或者自己使用基于socket的定制开发消息软件。
Comet技术Commet是一种使用HTTP长连接，无需浏览器安装插件的“服务器推”方案。它有两者方案：基于aJax的长轮询方式；基于iframe和htmlfile的流方式。这里，我们只关注里面的基于aJax的长轮询方式。
Pushlet是一个开源的Comet框架，其中在设计上有很多值得借鉴的地方，能够使用它来开发一个不是大规模的在线客服系统。而对于大型商用的在线客服系统，我觉得它还无法胜任。
负载均衡（分布式部署）一个正式商用的在线客服系统，不可能只在一个WEB服务器部署，这样子，性能和容量都很难扩展，所以必然是允许分布式部署的，通过负载均衡设备（或软件）来实现分布式访问。
如果采用分布式部署的话，那么就涉及到聊天的数据保存在哪里的问题。是保存在web服务器上，还是数据库呢？如果是单web服务器的话，那肯定是保存在web服务器上，其流程大概如下：
1、 用户发送消息是，系统将数据保存在web服务器（同时也保存数据库）上。
2、 客服对应的长连接获取web服务器上的数据，然后在客服的页面上显示出来。
3、 客服回复聊天信息，系统将数据保存到web服务器（同时也保存数据库）上。
4、 用户所在的长连接获取web服务器上的数据，然后在用户的页面上显示处理。
由于从web服务器上获取数据比在数据库获取数据的效率高，所以上面的逻辑是合理的，但是，基于分布式部署的环境下，他存在多个web服务器，那么发起聊天的消息应该保存在哪台服务器上呢？还是所有的服务器都保存一次呢？在分布式环境下存在一些像JBossCache等缓存同步的技术，但对应在线聊天系统，实时性的要求非常高，是否存在实时性的问题呢？
另外一个，基于安全的考虑，一般需要将用户所访问的功能放到一个web服务器集群上，客服所访问的功能放到另外一个web服务器集群上，两个web服务器集群的网络需要隔离，以防止黑客的攻击。这就又出现一个问题，如果用户发送的消息放到用户的web服务器上，那么客服如果获取到该消息呢？同理，用户的web服务器有如果获取客服web服务器对应的消息呢？
那么放到数据库来实现呢？把聊天记录都放到数据库中，用户和客服都从数据库获取聊天的信息。这样子的话，那么数据库的负荷将非常大，随着用户数的不断增加，数据库负荷越来越大，而且，在大用户下，存储都是非常频繁的，将所有人的聊天信息放到数据库上，是不明智的。还有一个安全上的考虑，一般实现用户的功能都不直接访问数据库，一般会经过一个中间的服务器作为中转，那么如果聊天信息从数据库取的话，效率则会更低。
那么，能不能像QQ那样，聊天双方直接建立连接，实时发送呢？其实，这是一种相对老点的技术，一般是采用Socket，或者UDP，实现双方的通讯。这种机制的缺点客户端可能需要采用applet插件或ActiveX插件，通讯时有比较大的性能消耗，最重要的一点，这些技术受网络的影响特别大，在一个环境下可以正常使用，在另外一个环境下，可能就无法正常使用了。所以，本文考虑的是采用aJax长轮询方式来实现的。
在这里，我建议客服的聊天数据从数据库读取，而用户的聊天数据从web服务器上读取。这是因为客服的数据相对比用户少很多，直接从数据库读取聊天数据，对数据库的性能影响较少，而用户的数量庞大，直接从数据库读取，无法满足要求。
那么，客服是将回复数据写到客服的web服务器，还是用户的web服务器呢？我的建议是写到用户的web服务器，因为用户的数据量非常庞大，用户从用户的web服务器获取数据，要比从客服的web服务器获取数据，性能要高得多。客服每次发送聊天信息的时候，往用户的web服务器写数据，虽然效率低，但由于客服的数据量小，并不影响性能。
另外，在分布式部署下，数据该记得所以的web服务器，还是某台特定的web服务器呢？我建议写到某个特定的web服务器上，这样避免客服每发送一条聊天信息，都要往所有的web服务器写数据，这会影响性能，但web服务器不断增加的时候，性能会随之下降。
那么，客服往哪台特定的web服务器写数据呢？用户又如何知道从哪台特定的web服务器上获取数据呢？这个，我们在用户登陆，负载均衡服务器给其分配到某个特定的服务器的时候，就可以将这个特定服务器的IP记录下来，客服就可以往这台机器发消息了，而用户也同样可以从该IP获取数据了。
热心网友
时间：2023-10-20 05:09
热心网友
时间：2023-10-20 05:10
智慧营销
以云计算和人工智能技术为基础，为具有主动呼出需求的企业提供大规模营销平台解决方案，并基于历史数据分析客户意向行为，助力销售代表持续转化商机。
部署灵活
一套平台，集中+分布部署，快速上线，统一管理。全国分布式座席即开即用。
智慧呼叫
灵活管理通信资源，有效提高接通率。号码状态检测，筛选出异常号码，提高座席拨打效率。
AI赋能座席
对话助手智能推荐话术。对历史数据聚类分析学习，提高座席业务能力。
即时营销
客服热线7*移动端处理客户资料、通话记录及录音，时刻把握商机。销售业务微信监控，实时了解客户进展。
