即时消息.docx

即时消息.docx

《即时消息.docx》由会员分享，可在线阅读，更多相关《即时消息.docx（16页珍藏版）》请在冰豆网上搜索。

即时消息

即时消息功能设计

2012年5月

文档修订

版本

日期

更改人

审阅人

描述（注明修改的条款或页）

1.0

XXX

XXX

目录

1需求概述4

1.1专业词语4

1.2架构介绍4

2功能设计5

2.1用户在线状态5

2.2在线客服分配5

2.3保存最近联系人6

2.4保存聊天记录6

2.5工作量统计7

2.6在线用户搜索7

3数据库表设计7

3.1ER关系图7

3.2表结构设计8

3.3重要SQL10

4接口设计10

4.1消息内容10

4.2Java与Node之间通信的接口11

4.3NodeJS的监听事件12

4.4协作平台需要提供的数据12

5易用性12

6性能12

7决策讨论13

1需求概述

使用简单明了的一段话来描述需求，让看文档的人员能够把握本文档的大概。

（必须写）

1.1专业词语

一些专业术语的描述。

（没有可以不写）

1.2架构介绍

技术架构采用分层方式，将后台架构分为三层，一层是Nodejs，主要用来持有连接和信息的转发，另外一层是业务逻辑层，使用java实现业务的处理，业务主要包括在线客服分配、分发消息、保存聊天记录、保存最近联系人等业务逻辑。

最后一层是数据层，主要由缓存服务器和Mysql数据组成。

整体架构图如下：

上图中，NodeServer其实是就是类似于apache或nginx的作用，只是一个连接持有和信息转发的作用。

另外NodeServer和Java业务逻辑Server都是可以扩展的，随着用于数量的增加，增加机器来提高系统的性能。

2功能设计

2.1用户在线状态

1、在线状态信息

在线状态信息是用户的一些基本的信息，包括登录信息、登录状态、连接ID等，服务器端将这些信息存放到Redis和mysql数据库中。

用户状态信息包括三种，一种是基本信息，包括用户名称、用户连接、node服务器地址、客户端类型、用户类型、在线状态、用户技能等。

第二种是用户的扩展信息，比如用户所属公司、所属部门、所属群组等。

第三种是客户端的信息，比如窗口打开状态，列表是否展开等。

主要用于打开多个网页后，每个网页上的即时消息框的状态信息同步，用户体验更好。

其中,第一种信息存放在数据库和redis中，第二种数据只存放在数据库中，第三种数据只存放在redis中。

存放在数据库中的目的是为了方便查询，例如：

查询在线客服，查询某个公司下的所有在线客服。

2、用户好友在线状态推送

（1）、用户登录后，将好友列表传送到服务器端，服务器根据redis中的数据，进行组织在线状态信息，一次性推送到客户端，这样客户端就显示哪些用户在线。

（2）、用户的登录、登出和改变在线状态，都会即时告知所有的在线好友自己的在线状态。

（3）、对于同一个用户，开启多个网页的情况，需要进行一个用户的多个连接之间的状态同步，也就是上面说的第三种在线信息。

2.2在线客服分配

客服分类：

在线客服可以按照某种类型进行划分，比如按照组织结构进行划分，某个公司的在线客服，某个工业的在线客服。

在线客服分配流程：

1、具有在线客服技能的用户登录以后，在线状态等表中会记录她的基本信息，最基本的两个必须的信息是用户技能和用户所属类型（组织），用户技能为客服。

2、普通用户登录后，选择某种类型的在线客服，前端浏览器会将在线客服所属类型等信息传给服务器端。

3、服务器接收到请求后，进行数据库查询，查询所属类型的为浏览器传过来的，用户技能为在线客服的，状态为空闲的在线客服列表。

4、从查询出来的在线客服列表中，选择一个当前服务用户数最少的在线客服，推送到客户端，并记录在redis中。

5、普通用户的客户端收到数据后，展开聊天窗口，并提示“当前某某客户为你服务”的系统消息。

6、一切就绪后，就可以正常的进行对话交流了。

2.3保存最近联系人

最近联系人的功能是普通用户和在线客服都应该具有的功能，相比之下，在线客服的需求更强烈一些，下面主要从两个方面描述在线客服为什么需要最近联系人的功能。

1、如果在线客服对普通用户咨询的问题不能立即回复，需要等一段时间再回复，由于普通用户与在线客服之间不是好友关系，那么最近联系人是唯一能找到对应普通用户的地方。

2、聊天记录的查询需要点击某个人，查看与他的聊天记录，最近联系人是最佳的点击地方。

最近联系人的显示，分段进行显示，刚开始只显示5-10条最近联系人，更多联系人靠用户点击后拉取。

2.4保存聊天记录

聊天记录的保存，主要是两种，一种是正常的聊天记录，另外一种是离线消息，两种记录都存放在一个表中，使用状态来区分，具体数据结构参考《3.2表结构设计》中的内容。

用户登录后，将离线消息推送到客户端。

2.5工作量统计

业务流程：

1、当普通用户与客服发送第一条消息后，就会记录当前会话的开始时间（可以记录在redis中）。

2、普通用户与客服聊天结束后，客服会询问“还有其他问题”，如果没有，那么客服会点击“结束本次会话”的按钮。

3、普通用户会接收到一个评价分数的选择框，为当前客服打分。

4、将本次会话的信息存放到数据库中，并且清楚redis中缓存的一些相关信息。

2.6在线用户搜索

本功能主要提供给在线客服使用，普通用户不具备此功能。

主要按照公司、部分、营销部等方面进行在线用户查询

3数据库表设计

3.1ER关系图

如果表实体比较多，可以画ER图，来展现表之间的关联关系。

3.2表结构设计

在线状态表

IM_USER_STATUS

字段编号

字段名称

主键

必须

类型

备注

USER_ID

用户编码

是

是

VARCHAR（30）

　用户编码

CONNECTION_ID

连接编号

是

是

VARCHAR（30）

　连接编码

CONNECTION_IP

连接所在服务器

是

是

VARCHAR（30）

用于分发数据

CLIENT_TYPE

客户端类型

否

否

INT（4）

电脑、手机、pad等

USER_NAME

用户昵称

否

是

VARCHAR（50）

USER_TYPE

用户类型

否

否

VARCHAR（10）

主要用来发送权限的过滤。

（比如：

给某个公司下所有在线零售户推送或发送消息）

STATUS

在线状态

　否

是　

INT（4）

空闲、繁忙等状态

USER_SKILL

用户技能

　否

否　

INT（4）

用来标识是否是客服

SERVICE_NUM

当前服务用户数

否

INT（4）

主要用来进行客服的分配

在线信息扩展

IM_USER_EXT

字段编号

字段名称

主键

必须

类型

备注

USER_ID

用户编码

是

是

VARCHAR（30）

EXT_TYPE

扩展类型

是

是

VARCHAR（15）

　比如总公司，公司、营销部、群组等、虚拟组，根据业务情况进行扩展。

EXT_VALUE

扩展value

否

是

VARCHAR（30）

公司ID、群组ID等。

最近联系人

IM_RECENT_CONTACT

字段编号

字段名称

主键

必须

类型

备注

USER_ID

用户编码

是

是

VARCHAR（30）

CONTACT_ID

联系人

是

是

VARCHAR（30）

CONTACT_NAME

联系人昵称

否

否

VARCHAR（50）

DATE_TIME

时间排序

是

LONG

可以使用时间

聊天记录

IM_CHAT_RECORD

字段编号

字段名称

主键

必须

类型

备注

ID

唯一的编码

是

是

VARCHAR（32）

FROM_ID

发送者ID

是

VARCHAR（30）

发送者

FROM_NAME

发送者名称

VARCHAR（50）

TO_ID

接收者ID

是

VARCHAR（30）

可以是用户ID或者群ID

TO_NAME

接收者名称

是

VARCHAR（50）

接收名称

TO_TYPE

接收者类型

否

INT

0，用户id，1，群组ID

CHAT_DATE

发送日期

是

CHAR（10）

具体日期

CHAT_TIME

发送时间

是

CHAR（6）

时分秒

MSG

消息内容

是

VARCHAR（500）

消息内容

MSG_STATUS

消息状态

否

INT

0离线、1正常

在线客服会话记录

IM_SERVICE_SESSION_RECORD

字段编号

字段名称

主键

必须

类型

备注

ID

编码

是

是

VARCHAR（32）

也是后面为其评价的索引ID。

SERVICE_ID

客服ID

是

VARCHAR（30）

客服的userId

CLIENT_ID

客户ID

是

VARCHAR（30）

服务的客户

START_TIME

开始时间

是

CHAR（17）

开始时间

END_TIME

结束时间

是

CHAR（17）

结束时间

INTER_MINUTES

服务时间

是

INT

间隔时长（分钟）

SCORE

评分

否

INT

客户给的评分

3.3重要SQL

一些重要逻辑对应的SQL。

4接口设计

4.1消息内容

消息内容一般包括四种类型，状态类、消息类、提示类和操作类。

为了方便处理，将消息和提示合并在一起。

1、状态类

structStatus

{

1:

stringtype;//（0000：

登录；0001：

登出；0002：

修改状态）

2:

stringuser_id;

3:

stringconnection_id;

4:

stringconnection_ip;

5:

i32client_type;

6:

stringuser_name;

7:

stringuser_type;

8:

i32status;

9:

i32user_skill;

10:

mapuser_ext;//键：

扩展type，值value（对应IM_USER_EXT中的EXT_TYPE和EXT_VALUE）

11:

stringext;//扩展状态，如窗口的最小化，打开的窗口等

}

2、消息通信类

structMessage

{

1:

stringtype;//方法类型（1100：

单个用户，1200：

发给一组用户，1300：

发给某种类型的用户，这时候必须传to_type）

2:

stringfrom;//发送者

3:

stringto;//接收者

4:

stringfrom_name;//发送者名称

5:

stringto_name;//接收者名称

6:

stringmsg;//消息内容

7:

stringto_type;//接收者类型，对应IM_USER_EXT表中的EXT_TYPE字段

8:

stringchat_date;//日期

9:

stringchat_time;//时间

10:

stringconnection_id;//连接id，只有推送的时候用到

11:

stringmsg_status;//消息状态（0：

在线消息；1：

离线消息）

}

3、操作类

structOperate

{

1:

stringtype;//（2100：

获取在线用户；2200：

获取用户状态；2300：

获取最近联系人；2400：

获取聊天记录；2500：

获取在线客服）

2:

mapquery_ext;//查询条件之一（type,0：

对应IM_USER_EXT中的EXT_VALUE；1：

只用查询条件二；2：

key=start和key=size，用于分页；3：

key=start和key=size，用于分页；4：

和0一样的条件）

3:

stringuser_list;//查询条件之二（用户列表之类，比如查询多个已知用户的在线状态）

4:

listresult_status;//查询结果（用户状态）

5:

listresult_message;//查询结果（数据通信对象）

}

4.2Java与Node之间通信的接口

使用thrift进行通信。

//java业务服务，供Nodejs调用

serviceJava_Service

{

voidchangeStatus（1:

Statusstatus）;//改变客户端状态，包括登录、登出、繁忙设置等

voidsendMessage（1:

Messagemessage）;//发送消息

voidsendOperate（1:

Operateprerate）;//发送操作

}

//Node提供的服务，供java调用

serviceNode_Service

{

voidconnect（1:

stringip,2:

i32port）;//java连接nodejs，连接成功后nodejs反连java

voidpushMessage（1:

Messagemessage）;//推送消息

voidpushOperate（1:

Operateoperate）;//推送操作结果

}

4.3NodeJS的监听事件

服务器监听：

1、sendMessage

2、sendOperate

3、changeStatus

客户端监听：

1、receiveStatus

2、receiveMessage

3、receiveOperateResult

4.4协作平台需要提供的数据

需要提供用户信息、好友数据和群组信息三类数据。

1、用户信息

《2.1用户在线状态》中提到的第一和第二种信息。

2、好友列表

树形好友列表

3、群组信息

群组列表。

5易用性

说明自己的功能哪些是易用性的提高。

6性能

将所有的用户在线信息都放在redis中,然后将用户相关的

redis存放结构如下：

键1键2值

UserID

connections

多个连接ID，使用；分割

status

用户状态（忙碌、空闲）

ext

多个窗口的信息，包括与谁聊天，另外还可以记录聊天开始的时间（用于客服统计）

公司名称

111

7决策讨论