スクラッチIM（インスタントメッセージング）サーバー（B）から開発

良いニュース：IM1.0.0バージョンは、オンラインの友人、サポート機能となっています。

ウィスパーは、テキスト/ファイルを送信します
送信済み/配信/領収書を読んで
LDAPサポートを使用してログイン
外部からの支援のログイン認証システムへのアクセス
クライアント開発のためのクライアントjarパッケージを提供

軽量サーバーのIMを構築するために最初からみんなでこの記事のお得な情報は、IMの全体的なアーキテクチャと設計のアイデア私の最後のブログの記事では、をクリックしてください学生を見たことがない、の話されている（スクラッチIMから開発しますインスタントメッセージング）サーバー。

これは、あなたの実装の詳細をもたらすでしょう。私は三つの側面が完全かつ信頼性の高いIMシステムを構築する方法を説明します。

確実
セキュリティ
ストレージの設計

確実

信頼性とは何ですか？IMシステムでは、信頼性の定義は、少なくともあるメッセージを失うことはありません、メッセージは繰り返さない、ない順不同で言って、この3点を満たすために良いチャットの経験を持っています。

メッセージが失われることはありません

私たちは失われていないメッセージを開始し始めます。

まず、上の設計を見直しサーバアーキテクチャ：

私たちは、について考え始めるために簡単な例から始め：アリスがボブにメッセージを送信すると、あなたはそのようなリンクを通過することもできます。
ルート

クライアント - >接続
コネクタ - >転送
転送 - >コネクタ
コネクタ - >クライアント

TCPプロトコルは信頼性があるが、この全体のリンクの各リンクは、間違って行く可能性があるが、それは唯一の信頼できるリンク層、アプリケーション層は信頼性を保証することはできません保証することができます。

例如在第一步中，connector收到了从client发出的消息，但是转发给transfer失败，那么这条消息Bob就无法收到，而Alice也不会意识到消息发送失败了。

如果Bob状态是离线，那么消息链路就是：

client-->connector
connector-->transfer
transfer-->mq

如果在第三步中，transfer收到了来自connector的消息，但是离线消息入库失败，
那么这个消息也是传递失败了。
为了保证应用层的可靠，我们必须要有一个ack机制，使发送方能够确认对方收到了这条消息。

具体的实现，我们模仿tcp协议做一个应用层的ack机制。

tcp的报文是以字节（byte）为单位的，而我们以message单位。
ACK
发送方每次发送一个消息，就要等待对方的ack回应，在ack确认消息中应该带有收到的id以便发送方识别。

其次，发送方需要维护一个等待ack的队列。 每次发送一个消息之后，就将消息和一个计时器入队。

另外存在一个线程一直轮询队列，如果有超时未收到ack的，就取出消息重发。

超时未收到ack的消息有两种处理方式：

和tcp一样不断发送直到收到ack为止。
设定一个最大重试次数，超过这个次数还没收到ack，就使用失败机制处理，节约资源。例如如果是connector长时间未收到client的ack，那么可以主动断开和客户端的连接，剩下未发送的消息就作为离线消息入库，客户端断连后尝试重连服务器即可。

不重复、不乱序

有的时候因为网络原因可能导致ack收到较慢，发送方就会重复发送，那么接收方必须有一个去重机制。
去重的方式是给每个消息增加一个唯一id。这个唯一id并不一定是全局的，只需要在一个会话中唯一即可。例如某两个人的会话，或者某一个群。如果网络断连了，重新连接后，就是新的会话了，id会重新从0开始。

接收方需要在当前会话中维护收到的最后一个消息的id，叫做lastId。
每次收到一个新消息，就将id与lastId作比较看是否连续，如果不连续，就放入一个暂存队列 queue中稍后处理。

例如：

当前会话的lastId=1，接着服务器收到了消息msg(id=2)，可以判断收到的消息是连续的，就处理消息，将lastId修改为2。
但是如果服务器收到消息msg(id=3)，就说明消息乱序到达了，那么就将这个消息入队，等待lastId变为2后，（即服务器收到消息msg(id=2)并处理完了），再取出这个消息处理。

因此，判断消息是否重复只需要判断msgId>lastId && !queue.contains(msgId)即可。如果收到重复的消息，可以判断是ack未送达，就再发送一次ack。

接收方收到消息后完整的处理流程如下：

伪代码如下：

class ProcessMsgNode{
    /**
     * 接收到的消息
     */
    private Message message;
    /**
     * 处理消息的方法
     */
    private Consumer<Message> consumer;
}

public CompletableFuture<Void> offer(Long id,Message     message,Consumer<Message> consumer) {
    if (isRepeat(id)) {
    //消息重复
        sendAck(id);
        return null;
    }
    if (!isConsist(id)) {
    //消息不连续
        notConsistMsgMap.put(id, new ProcessMsgNode(message, consumer));
        return null;
    }
    //处理消息
    return process(id, message, consumer);
}

private CompletableFuture<Void> process(Long id, Message message, Consumer<Message> consumer) {
    return CompletableFuture
        .runAsync(() -> consumer.accept(message))
        .thenAccept(v -> sendAck(id))
        .thenAccept(v -> lastId.set(id))
        .thenComposeAsync(v -> {
            Long nextId = nextId(id);
            if (notConsistMsgMap.containsKey(nextId)) {
                //队列中有下个消息
                ProcessMsgNode node = notConsistMsgMap.get(nextId);
                return process(nextId, node.getMessage(), consumer);
            } else {
                //队列中没有下个消息
                CompletableFuture<Void> future = new CompletableFuture<>();
                future.complete(null);
                return future;
            }
        })
        .exceptionally(e -> {
            logger.error("[process received msg] has error", e);
            return null;
        });
}

安全性

无论是聊天记录还是离线消息，肯定都会在服务端存储备份，那么消息的安全性，保护客户的隐私也至关重要。
因此所有的消息都必须要加密处理。
在存储模块里，维护用户信息和关系链有两张基础表，分别是im_user用户表和im_relation关系链表。

im_user表用于存放用户常规信息，例如用户名密码等，结构比较简单。
im_relation表用于记录好友关系，结构如下：

CREATE TABLE `im_relation` (
  `id` bigint(20) COMMENT '关系id',
  `user_id1` varchar(100) COMMENT '用户1id',
  `user_id2` varchar(100) COMMENT '用户2id',
  `encrypt_key` char(33) COMMENT 'aes密钥',
  `gmt_create` timestamp DEFAULT CURRENT_TIMESTAMP,
  `gmt_update` timestamp DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, 
  PRIMARY KEY (`id`),
  UNIQUE KEY `USERID1_USERID2` (`user_id1`,`user_id2`)
);

user_id1和user_id2是互为好友的用户id，为了避免重复，存储时按照user_id1<user_id2的顺序存，并且加上联合索引。
encrypt_key是随机生成的密钥。当客户端登录时，就会从数据库中获取该用户的所有的relation，存在内存中，以便后续加密解密。
当客户端给某个好友发送消息时，取出内存中该关系的密钥，加密后发送。同样，当收到一条消息时，取出相应的密钥解密。

客户端完整登录流程如下：
ログインプロセス

client调用rest接口登录。
client调用rest接口获取该用户所有relation。
client向connector发送greet消息，通知上线。
connector拉取离线消息推送给client。
connector更新用户session。

那为什么connector要先推送离线消息再更新session呢？我们思考一下如果顺序倒过来会发生什么：

用户Alice登录服务器
connector更新session
推送离线消息
此时Bob发送了一条消息给Alice

如果离线消息还在推送的过程中，Bob发送了新消息给Alice，服务器获取到Alice的session，就会立刻推送。这时新消息就有可能夹在一堆离线消息当中推过去了，那这时，Alice收到的消息就乱序了。

而我们必须保证离线消息的顺序在新消息之前。

那么如果先推送离线消息，之后才更新session。在离线消息推送的过程中，Alice的状态就是“未上线”，这时Bob新发送的消息只会入库im_offline，im_offline表中的数据被读完之后才会“上线”开始接受新消息。这也就避免了乱序。

存储设计

存储离线消息

ユーザーがオンラインでない場合は、オフラインメッセージは、サーバー上に保存されるようにバインドされ、ユーザーはオンライン上で待機し、それらを押し上げます。少し休日の後に理解し、オフラインメッセージの保存は非常に簡単です。オフラインメッセージテーブルの増加はim_offline次のように、テーブル構造です。

CREATE TABLE `im_offline` (
  `id` int(11) COMMENT '主键',
  `msg_id` bigint(20) COMMENT '消息id',
  `msg_type` int(2) COMMENT '消息类型',
  `content` varbinary(5000) COMMENT '消息内容',
  `to_user_id` varchar(100) COMMENT '收件人id',
  `has_read` tinyint(1) COMMENT '是否阅读',
  `gmt_create` timestamp COMMENT '创建时间',
  PRIMARY KEY (`id`)
);

msg_typeメッセージタイプ（とを区別するためchat、ack）、contentバイト配列の形式で格納されたメッセージ暗号化されたコンテンツ。
場合は、ユーザーに基づいて回線状態to_user_id=用户idを記録することができ引っ張っ。

重複メッセージをオフラインを防ぐためにプッシュ

私たちは、マルチポートログについては、アリスが、同時に2つのデバイスを上陸させた。この場合、同時に、我々は一度だけ読み込まれ、オフラインメッセージを確実にするために、いくつかのメカニズムが必要だと思います。

ここでの使用CASメカニズムを達成するために：

まず、すべての削除has_read=falseのフィールドを。
各メッセージのチェックhas_readそうならばtrueに、値がfalseであるかどうかを。これはアトミック操作です。

update im_offline set has_read = true where id = ${msg_id} and has_read = false

成功したプッシュを変更し、プッシュは故障ではありません。

私はここで、学生はすでに自分で利用できるIMサービスの完全なエンドを構築することができると信じています。その他の質問は、コメントゲストブック〜を喜ばせます

ライン、githubのリンク上IM1.0.0バージョン：
https://github.com/yuanrw/IMは
〜あなたがスターそれのポイントを作るために持っていると思います！