클라이언트 IM 데이터베이스 및 비즈니스 로직 구현 설계

Android IM 인스턴트 커뮤니케이션을 위한 다중 프로세스 미들웨어 설계 및 구현

모바일 측의 IM 데이터베이스 설계는 비즈니스와 밀접한 관련이 있는 경우가 많습니다.즉, 데이터베이스의 구조는 비즈니스 구현 방식을 직접 결정합니다.따라서 IM 개발에서 데이터베이스 설계는 전체 IM의 구현.

클라이언트에서 데이터베이스를 사용해야 하는 시나리오 또는 조건을 명확히 할 수 있으므로 데이터베이스의 설계 논리를 결정하는 데 도움이 됩니다. 물론 우리는 매우 복잡한 데이터베이스를 설계할 수 있는데, 설계된 데이터베이스가 눈앞에 나타나면 필요하지 않은 것이 무엇인지 알 수 있으며 이때 불필요한 것은 삭제할 수 있습니다.

클라이언트가 데이터베이스를 사용하기 위한 조건

1. 데이터는 지속적이어야 합니다. 비즈니스 데이터를 장기간 저장해야 하고 프로그램이 종료되어도 사라지지 않는 경우 영구 저장을 위해 데이터베이스를 사용해야 합니다.
2. 데이터를 자주 쿼리해야 합니다. 특정 키워드로 검색하는 등 비즈니스 데이터를 자주 조회해야 하는 경우 효율적인 조회를 위해 데이터베이스를 사용해야 합니다.
3. 데이터를 수정해야 합니다. 추가, 삭제, 업데이트 및 기타 작업과 같이 비즈니스 데이터를 자주 수정해야 하는 경우 데이터베이스를 사용하여 데이터를 수정해야 합니다.
4. 데이터는 여러 사용자와 시스템에 걸쳐 있어야 합니다. 비즈니스 데이터가 여러 사용자와 시스템에 걸쳐 있어야 하는 경우 데이터 공유 및 전달을 위해 데이터베이스를 사용해야 합니다.

데이터베이스를 설계할 때 비즈니스 요구 사항에 따라 설계해야 하며 데이터 구조, 데이터 액세스 및 성능과 같은 요소를 고려하여 데이터 보안, 무결성 및 가용성을 보장해야 합니다. 동시에 비즈니스 개발 요구를 충족할 수 있도록 데이터베이스의 확장성을 고려해야 합니다.

이것을 참조로 사용하여 테이블이 필요한지 여부를 결정할 수 있습니다.

분석하다

위챗을 예로 들어보자

먼저 IM 클라이언트의 업무를 분석한 후 업무와 결합하여 저장해야 할 사항을 정리한 후 데이터베이스를 설계해 보자. 이를 분석할 때 비즈니스 시나리오와 데이터 소스를 면밀히 따라야 합니다.

1.1 클라이언트 채팅 목록

im_chat_list로 기록합니다.

• 목적: IM 채팅 기록을 표시하기 위해 사용

• 데이터 소스: 온라인 데이터 + 오프라인 데이터

  • 온라인 데이터: 사용자가 온라인 상태일 때 긴 연결을 통해 데이터를 푸시하며 이때의 데이터를 온라인 데이터라고 합니다.
  • 오프라인 데이터: 사용자가 온라인 상태가 아니면 메시지가 서버에 캐시됩니다.사용자가 온라인 상태이면 오프라인 메시지를 동기화해야 하는데 이를 오프라인 데이터라고 합니다.

• 분석: 이 목록의 데이터는 다음과 같은 상태에 따라 점진적으로 증가하며 일괄적으로도 일회성일 수 있습니다.

1. 데이터가 로컬에 존재하는 경우 새로 추가된 데이터만 업데이트하려고 합니다.
2. 当本地没有数据时，我们需要全部的数据（按需求而定）

但归结起来，我们需要一张表，一张用于储存聊天列表的表，该表中的数据元素有：

• 头像
• 用户名
• 最新一条聊天内容
• 时间
• 未读数
• 群、订阅号、私聊（类型）

表1 消息列表

然后我们分析一下这个表，从面向对象的角度来看，他是不符合单一指责原则的，因为它既有用户消息又有聊天内容，还有消息列表。所以我们需要精简一下这张表，解析分析，看怎么精简。

1. 服务端面对上述“既有用户消息又有聊天内容，还有消息列表”的状况是更加糟糕的，因为他需要查询多张表才能拼出一条对应的数据，
2. 我们发现，每创建一条消息列表，不论是什么类型，都会出现对应的“用户概念”：

• 私聊： 用户就是对方的信息
• 群聊： 用户就是群的信息（群头像、昵称）
• 订阅号： 用户就是订阅号的信息

当用户信息发生变化时，我们需要更新用户信息，这是一个很独立的概念，所以我们需要一张表，用以存储用户信息（当然，就微信而言，存在好友关系时，我们必须有一张表用来存储所有用户的信息）

那怎么优化上述表呢？，很简单，我们将在表中添加一个聊天对方的id, 这个id 就是用户的id,在整个系统中，它是能表示用户的唯一属性，然后我们利用id 关联两个表，

更新消息列表

表2 消息列表

1.2 用户表

建立用户表

这样操作后，消息列表的职责变为消息列表和会话信息了，我们是为消息列表设计的，所以直接去分析消息，怎么去除它。

消息在IM项目中，肯定是需要单独存储的，因为用户聊天是增量的，我们必须持久化，才能避免大量的网络请求。此时我们分析消息列表和消息的关系，他们共同的元素是：

• 消息列表id

• 会话方id(用户id)

所以我们可以直接用消息列表中的user_id 关联聊天消息的表，以此完成最后一条消息的显示。此时消息列表变为：

1.3 聊天记录表

聊天记录表：

部分业务流程

更新的核心思想就是主要处理聊天记录表，其他表在聊天记录表的驱动下被动更新，但是同步离线消息场景需要单独处理。

流程图

首先明确一下需要参与的对象

1. 发送者A，接收者B
2. 消息表

• im_chat_list: 列表
• im_chat_0: 채팅기록 테이블 (그룹 채팅인 경우 채팅기록 테이블을 테이블로 나눌 수 있고, 사용자 속성에 따라 테이블로 나눌 수 있으며, 추후 공유할 기회가 있을 예정입니다.)
• im_user: 채팅 및 통화 상대방 사용자 정보 테이블

이 기사의 지능적인 분석은 여기서 끝납니다.이것은 가장 간단한 시나리오입니다.IM에서 오프라인 메시지, 지속적인 메시지 탐지 등을 모두 처리해야 합니다.더 알고 싶은 경우 직접 저에게 연락할 수 있습니다.