系统设计 on codedump notes

C++11中的内存模型下篇 - C++11支持的几种内存模型

Sat, 14 Dec 2019 22:41:22 +0800

在本系列的上篇，介绍了内存模型的基本概念，接下来看C++11中支持的几种内存模型。

几种关系术语 #

在接着继续解释之前，先了解一下几种关系术语。

sequenced-before #

sequenced-before用于表示单线程之间，两个操作上的先后顺序，这个顺序是非对称、可以进行传递的关系。

它不仅仅表示两个操作之间的先后顺序，还表示了操作结果之间的可见性关系。两个操作A和操作B，如果有A sequenced-before B，除了表示操作A的顺序在B之前，还表示了操作A的结果操作B可见。

happens-before #

与sequenced-before不同的是，happens-before关系表示的不同线程之间的操作先后顺序，同样的也是非对称、可传递的关系。

如果A happens-before B，则A的内存状态将在B操作执行之前就可见。在上一篇文章中，某些情况下一个写操作只是简单的写入内存就返回了，其他核心上的操作不一定能马上见到操作的结果，这样的关系是不满足happens-before的。

synchronizes-with #

synchronizes-with关系强调的是变量被修改之后的传播关系（propagate），即如果一个线程修改某变量的之后的结果能被其它线程可见，那么就是满足synchronizes-with关系的。

显然，满足synchronizes-with关系的操作一定满足happens-before关系了。

C++11中支持的内存模型 #

从C++11开始，就支持以下几种内存模型：

enum memory_order {
    memory_order_relaxed,
    memory_order_consume,
    memory_order_acquire,
    memory_order_release,
    memory_order_acq_rel,
    memory_order_seq_cst
};

与内存模型相关的枚举类型有以上六种，但是其实分为四类，如下图所示，其中对一致性的要求逐渐减弱，以下来分别讲解。

c++model

memory_order_seq_cst #

这是默认的内存模型，即上篇文章中分析过的顺序一致性内存模型，由于在上篇中的相关概念已经做过详细的介绍，这里就不再阐述了。仅列出引用自《C++ Concurrency In Action》的示例代码。

#include <atomic>
#include <thread>
#include <assert.h>

std::atomic<bool> x,y;
std::atomic<int> z;

void write_x()
{
    x.store(true,std::memory_order_seq_cst);
}

void write_y()
{
    y.store(true,std::memory_order_seq_cst);
}

void read_x_then_y()
{
    while(!x.load(std::memory_order_seq_cst));
    if(y.load(std::memory_order_seq_cst))
        ++z;
}

void read_y_then_x()
{
    while(!y.load(std::memory_order_seq_cst));
    if(x.load(std::memory_order_seq_cst))
        ++z;
}

int main()
{
    x=false;
    y=false;
    z=0;
    std::thread a(write_x);
    std::thread b(write_y);
    std::thread c(read_x_then_y);
    std::thread d(read_y_then_x);
    a.join();
    b.join();
    c.join();
    d.join();
    assert(z.load()!=0);
}

由于采用了顺序一致性模型，因此最后的断言不可能发生，即在程序结束时不可能出现z为0的情况。

C++11中的内存模型上篇 - 内存模型基础

Sat, 14 Dec 2019 10:10:15 +0800

前段时间花了些精力研究C++11引入的内存模型相关的操作，于是把相关的知识都学习了一下，将这个学习过程整理为两篇文档，这是第一篇，主要分析内存模型的一些基础概念，第二篇展开讨论C++11相关的操作。

CPU架构的演进 #

早期的CPU，CPU之间能共享访问的只有内存，此时的结构大体如图：

memory

随着硬件技术的发展，内存的访问已经跟不上CPU的执行速度，此时内存反而变成了瓶颈。为了加速读写速度，每个CPU也都有自己内部才能访问的缓存，结构变成了这样：

multicore

其中：

有多个CPU处理器，每个CPU处理器内部又有多个核心。
存在只能被一个CPU核心访问的L1 cache。
存在只能被一个CPU处理器的多个核心访问的L2 cache。
存在能被所有CPU处理器都能访问到的L3 cache以及内存。
L1 cache、L2 cache、L3 cache的容量空间依次变大，但是访问速度依次变慢。

当CPU结构发生变化，增加了只能由内部才能访问的缓存之后，一些在旧架构上不会出现的问题，在新的架构上就会出现。而本篇的主角内存模型（memory model），其作用就是规定了各种不同的访问共享内存的方式，不同的内存模型，既需要编译器的支持，也需要硬件CPU的支持。

我们从一个最简单的多线程访问变量问题谈起。

简单的多线程访问数据问题 #

假设在程序执行之前，A=B=0，有两个线程同时分别执行如下的代码：

线程1	线程2
1. A=1	3. B=2
2. print(B)	4. print(A)

问上述程序的执行结果如何？

这个问题是一个简单的排列组合问题，其结果有：

2（先选择A或B输出）* 2（输出修改前还是之后的结果）* 1（前面第一步选择了一个变量之后，现在只能选剩下的变量）* 2（输出修改前还是之后的结果） = 8

其可能的结果包括：(0,0)、(1,0)、(0,2)、(1,2)、(0,1)、(2,0)、(2,1)。（这里只有7个结果，是因为有两个(0,0)，所以少了一个）。

由于多个线程交替执行，可能有以下几种结果，下面来分别解析。

两个线程依次执行 #

最简单的情况，就是这两个线程依次执行，即一个线程执行完毕之后再执行另一个线程的指令，这种情况下有两种可能：

1->2->3->4

这种情况先执行完毕线程1，再执行线程2，最后输出的结果是(0,1)。

sc1

3->4->1->2

这种情况先执行完毕线程2，再执行线程1，最后输出的结果是(0,2)。

sc2

两个线程交替执行 #

这样情况下，先执行的可能是线程1或者线程2，来看线程1先执行的情况。

1->3->2->4

这种情况下的输出是（2,1）。

sc3

1->3->4->2

这种情况下的输出是（1,2）。

sc4

以上是第一条指令先执行线程1执行的情况，同样地也有先执行线程2指令的情况（3-1->4->2和3->1->2-4），这里不再列出，有兴趣的读者可以自行画图理解。

不可能出现的情况 #

除了以上的情况之外，还有一种可能是输出(0,0)，但是这种输出在一般情况下不可能出现（我们接下来会解释什么情况下可能出现），下面来做解释。

对比脚本型和编译型游戏服务器的热更新方案

Fri, 06 Dec 2019 22:40:49 +0800

本文对比游戏服务器中C++搭配脚本语言（Lua、Python）以及纯编译型语言（C++、Golang）来进行开发时，进行线上服务器热更新的方案。

游戏开发模式 #

在开始下文之前，有必要简单描述一下游戏服务与web服务的区别。

长连接 VS 短连接 #

游戏服务对外与客户端之间的链接多是长连接形式，而web服务多是短连接。

有状态服务 VS 无状态服务 #

游戏服务内，需要维持着玩家的状态数据，如玩家属性、位置等，web请求多是无状态服务。

启动时间 #

由于前面提到的游戏服务是有状态服务，因此游戏服务器启动的时候，需要从持久化存储中将数据加载到内存中，这意味着游戏服务器的启动时间会很长，一般一次需要几分钟，web服务器相对轻量很多，因为需要访问的持久化数据在另外的存储服务器上。

开发周期 #

游戏服务的开发周期短，有一些游戏一周就需要进行一次维护，这意味着在这一周内策划（对应互联网中的产品经理）提出的需求都要完成上线。

从以上对比可以看到，游戏业务的特点是更新频繁，而启动一个服务器的时间又比较长。在进行开发的过程中，如果使用纯编译型语言进行开发，那么流程就是如下所示：

cpp-dev

可以看到，上面是一个比较长的开发功能流程，而如果还考虑到开发周期短这个特点，显然是不能匹配游戏开发这种业务的特征的，此时就需要“热更新”功能才能提高开发效率。

以下就脚本语言与编译型语言如何实现“热更新”展开讨论。

C++搭配脚本语言 #

这种方案是笔者见过的方案，其一般的做法是：C++来实现底层的框架（网络、与数据库通信等），接收到数据包之后，将数据传递给脚本层，由脚本来处理具体的业务逻辑。

script-level

这种也是软件设计中常见的分层方案：底层的模块为上层的模块服务，同时底层模块也变动的较少。

由于嵌入到进程里面的脚本语言引擎，本质上是将脚本语言代码翻译成内存中的Opcode来执行，因此这类型游戏服务器实现“热更新”方案很简单：将新的脚本同步到服务器上，然后给服务器发出一个信号，重新读取脚本代码到内存中即可。

有了这个架构之后，原先的开发模式就变成了下图：

script-dev

可以看到，前面编译型语言中编译和重启服务器这两部最消耗时间的步骤，变成了热更新脚本，这样就不需要重启服务器来验证功能，开发效率提高了很多。

编译型语言实现热更新 #

从上面的分析可以看到，因为编译型语言存在需要重启服务器的步骤，导致了以下两个问题：

客户端连接需要断开，因为游戏服务是长连接。
重启服务器时需要耗费大量的时间将持久化存储的数据加载到内存中，这样启停过程中的客户端请求就会丢失。

下面依次看看如何解决这两个问题。

维护客户端连接，可以再引入一个网关组件，由网关来维护连接，这样服务器重启流程中客户端对内部游戏服务器的启停并无感知。

为了在启动新版本服务器的过程中继续服务客户端请求，并且新版本服务器上线之后能接着当前的玩家属性继续操作，可以考虑将数据存入共享内存中，这样即便进程退出共享内存还存在。这样做的思路是“代码与数据分离”。

如果要实现这个方案，又要做到以下两点：

设计一套面向共享内存的数据结构，至少应该能支持常见的链表、数组、字典等类型。
数据结构的设计需要考虑可扩展性以及前后兼容性，因为可能出现两个前后版本中，有一些字段不存在或者有一些字段新增的情况。

有了以上的介绍，下图中就是为了支持热更新的编译型语言的架构方案：

cpp-hotrefresh

其中：

网关负责维护与客户端的连接，同时也知道当前访问的是哪个游戏服务器。当新版本服务器启动完毕之后，向网关发送一个指令，让网关在收到这个指令之后的所有客户端请求，都转发到新的游戏服务器上，这样就完成了一个看似没有重启的“热更新”。
数据保存在共享内存中，这样即使在启动新版本服务器的时候也能继续服务客户端的请求。另外需要注意的是，启动的时候服务器需要判断一下是否已经有一个进程存在，如果存在进程且有共享内存数据的情况下，不需要再从持久化存储中加载数据到内存中。

方案对比 #

以下来对比一下两种技术方案的优缺点。

特性	脚本型游戏服务器	编译型游戏服务器	备注
开发效率	高	低	脚本语言没有编译步骤
性能	低	高	脚本语言执行性能不如编译型语言
架构难度	低	高	编译型语言为了实现热更新，需要解决：网关维护连接，代码数据分离，数据存入共享内存等，而脚本型语言只需要实现热更新脚本即可
重构难度	高	低	“脚本语言一时爽，代码重构火葬场”

IM服务器设计-如何解决消息的乱序

Sun, 13 Oct 2019 10:59:16 +0800

IM消息需要面对的另一个难题：如何保证收到的消息不乱序。下面先展开看看要解决这个难题有哪些障碍。

消息乱序的原因 #

时间难以保证 #

既然谈到“顺序”，就必然有一个衡量的标准，然而无论是使用客户端时间还是服务器时间都难以作为这个标准来衡量消息的先后顺序。

msg

如上图中，一个IM系统在多个客户端，在不同的接入网关进行接入，进而又在不同的逻辑处理服务器上进行处理，不论是客户端本身，还是服务器（网络、逻辑服务器），各自机器上的时间都不相同，因此无法以机器本地的时间来作为衡量消息顺序的标准。

网络顺序无法保证 #

考虑到只有一个客户端连接上一个网关的场景，即使在这样的场景中，消息的先后顺序也因为网络的因素难以得到保证。

msg-network

如上图中，网关试图向客户端依次发送消息1、2这两条消息，可能出现下面的问题：

网关向客户端发送消息1，此时客户端的网络状况不好，导致该消息可能会丢失或者重传。
网关没有等待消息1的发送结果，继续发送了消息2，而此时客户端的网络状况变好，这条消息比消息1更快的被客户端收到。

以上的场景，可能会有人想到一种处理模式：网关只有在客户端应答收到了消息1之后再继续发送消息2，这样就不会出现网络原因导致的消息乱序问题了。然而这样的话，消息相当于串行发送了，效率并不高。

多线程因素导致的乱序 #

客户端、服务器都可能存在多个发送、接收线程，这也是导致消息乱序的原因之一。

解决策略 #

前面分析了消息乱序的几个成因，下面就逐个分析都应该怎么解决。

消息序列号 #

前面提过的第一个问题：消息的时序标准问题，无法以客户端或者服务器本地的时间来作为衡量的标准，此时可以引入一个产生递增ID的组件，由这一组件来统一生成递增、不回退的消息序列号用于衡量消息的先后顺序。

然而这里还有可以细化讨论的部分：这个组件生成的ID，是否需要全局唯一？即不论单聊、群聊都需要保证生成出来的序列号唯一。

这个全局唯一性不是必要的，原因在于不同的聊天，能保证消息在自己的频道唯一、递增即可。有了这个前提，这个组件生成ID的流程大体如下：

处理该聊天的逻辑服务器ID。
每个聊天频道（单聊、群聊）有自己一个独立的频道ID。
每个频道内部，保证能够产生一个递增、不回退的序列号。

这样，消息序列号实际上由三部分部分组成：逻辑服务器ID-频道ID-频道内的消息序列号。

群聊消息的处理 #

有了前面的消息序列号，已经解决了第一个问题：消息的时序标准问题。然而这样还不足够，考虑到下图中的群聊场景：

group-msg

在上图中：

两个客户端依次发出消息A和消息B。
在两个不同的处理群聊消息的服务器中，由于种种原因，反倒是消息B比消息A先到。

从上面可以看出，群聊消息乱序的原因在于：同一个群聊的消息，最后被分派到了两个不同的逻辑服务器上处理。

还是继续沿用上面生成消息序列号的思路：如果是同一个聊天频道的消息，就放在一起处理。因此可以变成下图中的处理方式：

group-msg-2

上图中，根据群聊消息的群ID来选择逻辑服务器，这样同一个群的消息都能落在同一个服务器中来处理了。

可以看到，这里并不需要使用一个“分布式唯一递增ID”这样的组件来产生ID，因为这里的问题简化成了：只需要该消息序列号在所在的逻辑服务器处理的聊天频道中唯一且递增就可以了。问题的重新分析和定义，让这个处理变得简单了很多。

网络乱序的处理 #

接着处理由于网络原因导致的乱序，TCP协议中也有类似处理网络乱序的手段，简单来说：

TCP协议栈中有缓冲区缓存收到的数据。
发送端使用序列号ACK来确认接收端收到的数据，比如1、2、3三个序列号的数据，如果先接收到1，此时发送端会收到ACK 1的消息，但是在这之后如果消息3先于消息2被接收端收到，此时发送端仍然会ACK消息1，表示消息3这条消息是乱序的。
有了缓冲区和确认序列号，就知道哪些数据可以由协议栈提供给应用层。

tcp-stack

如上图中：

接收方TCP协议栈中依次存有消息1和3，而消息2还未接收到。
消息1被发送方确认，此时消息1可以提供给应用层。
由于消息2没有接收到，因此消息3是乱序消息，不能提供给应用层。

从中得到的启发是：收发队列是可以有发送者来掌控的，发送者知道消息的顺序，虽然不能保证消息收发的前后顺序，但是由于引入了缓冲区，只有被确认的消息才可以被消费，这样可以通过发送者的ACK确认，来保证消息的顺序消费。

以上的思路，可以沿用到网络乱序消息的处理中。

最终方案 #

综合以上的分析，消息乱序问题可以使用下面的方式来解决。

客户端消息缓存队列 #

客户端内部，维持一个缓存消息的队列，每个消息都有对应的消息序列号，收到消息之后需要与网关进行确认，以此确认这条消息是否是按序接收的消息，只有这样的消息才能提供给应用层消费。

IM服务器设计-网关接入层

Sun, 18 Aug 2019 16:55:17 +0800

IM服务系列文章：

网关接入层负责维护与客户端之间的长连接，由于它是唯一一个与客户端进行直接通信的服务入口，维护着大量的客户端连接，其设计原则应该满足：

安全
稳定
快速

具体来说，需要考虑不少的问题：

用什么数据结构保存与客户端的连接？
如何清除死链？
在网关宕机的情况下如何容错？
服务如何降级？

以下具体展开。

基础设计 #

简而言之，网关内部维护着一个map，其中保存着客户端相关的ID与对应连接的映射关系。

map

内部服务需要应答客户端时，经历如下步骤：

到redis中查询路由信息，即客户端连接到了哪个网关，将消息发送给该网关。
网关服务在上面的map中找到对应的客户端连接，将消息发送给客户端。

死链的处理 #

由于网关上维护着大量的客户端连接，需要通过收发心跳报的方式检查死链，具体做法是：

网关针对每个连上的连接，都创建一个定时器。
网关跟客户端的每次交互之后，网关都对应的更新一下该客户端的心跳时间为当前时间。
客户端内部同样也维护一个定时器，每次定时器超时时，判断当前是否已经有一段时间没有跟网关通信了，此时将发出心跳消息进行保活。
当该每个定时器到期时，检查客户端的心跳时间距离当前时间已经超过一个阈值了，那么将认为该客户端已经失连，将清除掉该连接。

需要注意的是，客户端的定时器应该小于网关层给每个连接加上的定时器。

keepalive

容错设计 #

网关有可能宕机，此时要考虑到这种情况下的容错处理。

这里的原则有两条：

客户端一旦发现前面连接的网关宕机，将尝试重连。
内部服务要通过网关层应答给客户端的消息，一旦发现由于网关宕机而无法发出，将直接丢弃，由客户端重新尝试重连。

以下来详细解释一下这两个原则。

客户端重连 #

客户端内部维护着一个发出消息的消息队列，仅在收到服务器的处理应答之后才可以从其中清除相应的消息。注意，这里每个客户端的消息ID需要做到严格递增。

messagequeue

比如，上图中发出但是未收到应答的消息有三条，消息ID依次递增，分别是100、101、102。此时如果收到服务器应答消息101已经被确认处理，那么在这个序号之前的消息100以及101都可以被认为已经被服务器正常接收并且处理完毕，此时可以从消息队列中删除掉序号101之前的消息了。

反之，客户端同时还维护另外一个定时器，一段时间没有收到连接的网关消息时，将向网关发出心跳消息，如果仍然没有回复则认为网关出现异常，将重新走正常的登录流程尝试选择另外一台网关登录。重连之后，将重新发送消息队列中已经存在的消息。

重连策略 #

当一台网关出现问题需要客户端进行重连时，还需要考虑到不要因为重连问题导致了其他网关服务器也受影响，产生雪崩效应，此时还需要考虑以下几点：

打散重连时间：需要进行重连的客户端，在一个时间范围内选择一个随机的时间，这样将这些客户端的重连时间打散，不至于一下子都连接上来。
指数退避：一次重连不上时，客户端还需要再次尝试进行多次重连，然而重连的时间需要像TCP协议那样在阻塞恢复时做指数退避，即第一次重连时间是1秒后，第二次2秒后，第三次4秒后，等等。这个策略也是为了避免由于重连导致的服务雪崩。
服务器保护：上面两条是客户端的重连策略，然而服务器自身也需要进行保护，当服务器判断自己当前的负载到一定程度时，将拒绝客户端的连接请求。

内部服务丢弃应答消息 #

同样的，内部服务也只是通过网关层与客户端进行通信，当处理了一些消息之后需要应答客户端，此时发现对应的网关已经宕机，那么应该丢弃掉这些应答消息，等待客户端重连之后重新将前面没有收到应答的消息发出来。

如果是这个处理原则的话，对应的就需要服务器的逻辑中做到“幂等性（idempotent）”了，即同一个操作，一次请求与多次请求的结果是一样的。比如，逻辑服务器可以通过客户端的消息ID来判断这条消息之前是否已经被处理过，如果是的话可以直接忽略处理应答处理即可。

服务保证 #

每个网关服务器可以容纳的长连接总数是固定的，到了一定程度系统资源就消耗的差不多了，应答的延迟也提高了。所以，网关层还需要考虑到服务的可用性。

比如，可以向管理网关的服务器上报如下数据：

当前维护的连接数量。
当前应答延迟指标，90%的延迟到多少，99%的应答延迟到多少，等等。
当前系统资源的消耗情况，比如CPU占用、内存占用等等。

这样，可以有依据来判断该网关是否还能继续接收新的连接，如果不能接收连接可以返回一批当前可用的其他网关服务列表给客户端重新发起连接，同时将当前不可用的网关从返回给客户端的网关列表中删除，这样下次就不会再来这个网关进行连接。

qos

如上图中，有如下步骤：

网关都向网关管理服务上报自己当前的服务状态，管理服务发现网关A已经接近服务极限，此时将通知网关A此时不能再接收新的连接，同时还告知当前可用的网关B和C地址。
客户端向网关A发起请求，此时网关A拒绝该连接请求，并且返回网关B和C的服务列表给客户端。
客户端选择网关C进行连接。

可以看到，这实际上是“服务降级”的一种做法。

服务调用的演进历史

Sat, 29 Jun 2019 12:47:07 +0800

这是2019年给组内分享时整理的一篇服务调用演进历史的科普文。写作本文的时候，我自己最大的感受是：如果能清楚理解演化历史中的一些原则和思路，就会发现现在的变化并不新鲜。它们不是今天才有，也不会止于今天的演化。在技术大发展的今天，更多的关注本质才能让我们不至于在变化中失去方向。

这个题目稍微有点大，纯粹是一篇科普文，将我所了解到的解决“服务调用”相关的技术演进历史简述一下，本文专注于演化过程中每一步的为什么（Why）和是什么（What）上面，尽量不在技术细节（How）上面做太多深入。

服务的三要素 #

一般而言，一个网络服务包括以下的三个要素：

地址：调用方根据地址访问到网络接口。地址包括以下要素：IP地址、服务端口、服务协议（TCP、UDP，etc）。
协议格式：协议格式指的是该协议都有哪些字段，由接口提供者与协议调用者协商之后确定下来。
协议名称：或者叫协议类型，因为在同一个服务监听端口上面，可能同时提供多种接口服务于调用方，这时候需要协议类型（名称）来区分不同的网络接口。

需要说明在服务地址中：

IP地址提供了在互联网上找到这台机器的凭证。
协议以及服务端口提供了在这台机器上找到提供服务的进程的凭证。

service address

这都属于TCPIP协议栈的知识点，不在这里深入详述。

下图中，以最简单的一个HTTP请求，来拆解请求URL中的服务要素：

http-request

其中：

http：指明使用的是哪种应用层协议，同类型的还有“https”、“ftp”等。
www.abc.com：域名地址，最终会由DNS域名解析服务器解析成数字的IP地址。
8080：前面解析成数字化的IP地址之后，就可以访问到具体提供服务的机器上，但是上面提供服务的进程可能有很多，这时候就需要端口号来告诉协议栈到底是访问哪个进程提供的服务了。
hello：该服务进程中，可能提供多个接口供访问，所以需要接口名+协议（即前面的http）告诉进程访问哪个协议的哪个接口。
msg=world：不同的接口，需要的参数不同，最后跟上的查询参数（query param）告诉服务请求该接口服务时传入的参数。

以上，简单的把网络服务的几个要素进行了描述。

这里还需要对涉及到服务相关的一些名词做解释。

服务实例：服务对应的IP地址加端口的简称。需要访问服务的时候，需要先寻址知道该服务每个运行实例的地址加端口，然后才能建立连接进行访问。
服务注册：某个服务实例宣称自己提供了哪些服务，即某个IP地址+端口都提供了哪些服务接口。
服务发现：调用方通过某种方式找到服务提供方，即知道服务运行的IP地址加端口。

基于IP地址的调用 #

最初的网络服务，通过原始的IP地址暴露给调用者。这种方式有以下的问题：

IP地址是难于记忆并且无意义的。
另外，从上面的服务三要素可以看到，IP地址其实是一个很底层的概念，直接对应了一台机器上的一个网络接口，如果直接使用IP地址进行寻址，更换机器就变的很麻烦。

“尽量不使用过于底层的概念来提供服务”，是这个演化流程中的重要原则，好比在今天已经很少能够看到直接用汇编语言编写代码的场景了，取而代之的，就是越来越多的抽象，本文中就展现了服务调用这一领域在这个过程中的演进流程。

在现在除非是测试阶段，否则已经不能直接以IP地址的形式将服务提供出去了。

域名系统 #

前面的IP地址是给主机做为路由器寻址的数字型标识，并不好记忆。此时产生了域名系统，与单纯提供IP地址相比，域名系统由于使用有意义的域名来标识服务，所以更容易记忆。另外，还可以更改域名所对应的IP地址，这为变换机器提供了便利。有了域名之后，调用方需要访问某个网络服务时，首先到域名地址服务中，根据DNS协议将域名解析为相应的IP地址，再根据返回的IP地址来访问服务。

从这里可以看到，由于多了一步到域名地址服务查询映射IP地址的流程，所以多了一步解析，为了减少这一步带来的影响，调用方会缓存解析之后的结果，在一段时间内不过期，这样就省去了这一步查询的代价。

协议的接收与解析 #

以上通过域名系统，已经解决了服务IP地址难以记忆的问题，下面来看协议格式解析方面的演进。

一般而言，一个网络协议包括两部分：

协议包头：这里存储协议的元信息（meta infomation），其中可能会包括协议类型、报体长度、协议格式等。需要说明的是，包头一般为固定大小，或者有明确的边界（如HTTP协议中的\r\n结束符），否则无法知道包头何时结束。
协议包体：具体的协议内容。

无论是HTTP协议，又或者是自定义的二进制网络协议，大体都由这两部分组成。

protocol format

由于很多时候不能一口气接收完毕客户端的协议数据，因此在接收协议数据时，一般采用状态机来做协议数据的接收：

protocol statemachine

接收完毕了网络数据，在协议解析方面却长期停滞不前。一个协议，有多个字段（field），而这些不同的字段有不同的类型，简单的raw类型（如整型、字符串）还好说，但是遇到复杂的类型如字典、数组等就比较麻烦。

当时常见的手段有以下几种：

使用json或者xml这样的数据格式。好处是可视性强，表达起上面的复杂类型也方便，缺陷是容易被破解，传输过去的数据较大。
自定义二进制协议。每个公司做大了，在这一块难免有几个类似的轮子。笔者见过比较典型的是所谓的TLV格式（Type-Length-Value），自定义二进制格式最大的问题出现在协议联调与协商的时候，由于可视性比较弱，有可能这边少了一个字段那边多了一个字段，给联调流程带来麻烦。

上面的问题一直到Google的Protocol Buffer（以下简称PB）出现之后才得到很大的改善。PB出现之后，也有很多类似的技术出现，如Thrift、MsgPack等，不在这里阐述，将这一类技术都以PB来描述。

与前面的两种手段相比，PB具有以下的优点：

使用proto格式文件来定义协议格式，proto文件是一个典型的DSL（domain-specific language）文件，文件中描述了协议的具体格式，每个字段都是什么类型，哪些是可选字段哪些是必选字段。有了proto文件之后，C\S两端是通过这个文件来进行协议的沟通交流的，而不是具体的技术细节。
PB能通过proto文件生成各种语言对应的序列化反序列化代码，给跨语言调用提供了方便。
PB自己能够对特定类型进行数据压缩，减少数据大小。

服务网关 #

有了前面的演化之后，写一个简单的单机服务器已经不难。然而，当随着访问量的增大，一台机器已经不足以支撑所有的请求，此时就需要横向扩展多加一些业务服务器。

IM服务器设计-消息存储

Sat, 08 Jun 2019 20:18:47 +0800

这部分专门讲述IM消息存储的设计。消息存储的难度在于，要考虑以下的场景：

离线消息存储。即发送消息时对方不在线该怎么处理。
单聊、群聊消息。
随着用户量越来越大，应该以后如何扩展。

读扩散 VS 写扩散 #

消息同步模型中，有写扩散和读扩散这两种模型。在开始讨论之前需要先了解两个相关的概念：

收件箱（inbox）：该用户收到的消息。
发件箱（outbox）：该用户发出的消息。

写扩散（push） #

写扩散就是经常说的push模式，即每个消息都直接发送到该用户的收件箱中。其优缺点如下：

优点：读优化，用户每次只需要去读取自己收件箱中的消息即可。
缺点：写很重，如果这个消息是一条群消息，那么一个群成员发送出去的消息将拷贝到所有其余群成员的收件箱中。

im msg push

读扩散（pull） #

读扩散就是pull模式，用户每次到消息发送者的发件箱去拉取消息，优缺点如下：

优点：写优化，每次发送的消息只需要写到一个地方，由收件者自己去拉取消息即可。
缺点：读操作很重，假设一个用户有一千个好友，重新登录时需要拉取这些好友所有的离线消息。

im msg pull

最终选择的是以pull模式为主的模式，理由在于：

IM业务属于『写多读少』类型的业务，如果使用push模式，将造成消息的大量冗余。
pull模式读操作较重的缺陷可以通过其他方式来优化解决。

下面来看具体的设计。

表设计 #

在数据库设计中，仅使用一个发送消息表来存储消息的具体内容，而另外有一个消息接收表用来存储消息的ID信息而不是具体内容，这样用户查询消息时，大体流程如下：

首先拉取接收消息表中的信息。
根据接收消息表中的ID以及发送者ID信息到发送信息表来具体查询消息。

im msg

用户发送消息表 #

无论是单聊还是群聊消息，都使用这个表来存储发送出去的消息。

im_message_send（msg_id,msg_from,msg_to,msg_seq,msg_content,send_time,msg_type）

其中：

msg_id：消息ID。
msg_from：消息发送者UID。
msg_to：消息接收者。如果是单聊消息那么就是用户UID，如果是群聊消息就是群ID。
msg_seq：客户端发送消息时带上的序列号，主要用于消息排重以及通知客户端消息发送成功之用。
msg_content：消息内容。
send_time：消息发送时间。
msg_type：消息类型，如单聊、群聊消息等。

用户接收消息表 #

im_message_recieve（id,msg_from,msg_to,msg_id,flag）

其中：

id：这个表的ID，自增。
msg_from：消息发送者ID。
msg_to：消息接收者ID。
msg_id：消息ID，对应发送消息表中的ID。
flag：标志位，表示该消息是否已读。

接收消息表的信息并没有很多，因为主体部分如消息内容、发送消息时间等都在发送消息表中。

im msg table

分库分表及访问策略 #

发送消息表，根据msg_from字段做为分库分表的依据，而接收消息表则使用msg_to字段做为分库分表的依据。

IM服务器设计-基础

Sat, 08 Jun 2019 11:09:10 +0800

IM做为非常经典的服务器系统，其设计时候的考量具备代表性，所以这一次花几个篇幅讨论其相关设计。

主要内容相当部分参考了一套海量在线用户的移动端IM架构设计实践分享一文，在此之上补充了更好的消息存储设计以及集群设计。

整体架构 #

im arch

以上架构图中，分为几个部分：

客户端：支持IOS、Android系统。
接入层：负责维护与客户端之间的长连接。
逻辑层：负责IM系统中各逻辑功能的实现。
存储层：存储IM系统相关的数据，主要包括Redis缓存系统（用于保存用户状态及路由数据）、消息数据。

上图中几部分的交互如下：

客户端通过gate接入IM服务器。在这里，客户端与gate之间保持TCP长连接，客户端使用DNS查询域名返回最近的gate地址进行连接。
Gate的作用：保持与客户端之间的长连接，将请求数据转发给后面的逻辑服务LogicServer。LogicServer最上面是一个消息路由服务Router，根据请求的类型转发到后面具体的逻辑服务器。其中c代表客户端，s代表服务器，g代表群组，因此比如c2c服务就是处理客户端之间消息的服务器，而auth服务是处理客户端登录请求的服务器。
逻辑类服务器与存储层服务打交道，其中：redis用于存储用户在线状态、用户路由数据（用户路由数据就是指用户在哪个gate服务上维护长连接），而DB用于存储用户的消息数据，这部分留待下一部分讲解。
以上的接入层、逻辑层由于本身不存储状态，因此都可以进行横向扩展。看似Gate维护着长连接，但是即使一个Gate宕机，客户端检测到之后可以重新发起请求接入另一台Gate服务器。

数据存储 #

路由数据：存放在Redis中，格式为（UID,客户端在哪个gate登录）。
消息数据：存储在DB中，部分也会缓存在缓存中方便查询，这部分做为下一部分文章的重点来讲解，不在这部分展开讨论。

核心交互流程 #

统一登录系统 #

登录授权（auth） #

im login

客户端通过统一登录系统验证登录密码等。
SSO验证客户端用户名密码之后，生成登录token并返回给客户端。
客户端使用UID和返回的token向gate发起授权验证请求。
gate同步调用logic server的验证接口。
logic server请求SSO系统验证token合法性。

SSO向auth系统返回验证token结果。
如果验证成功，auth系统在redis中存储客户端的路由信息，即客户端在哪个gate上登录。

auth系统向gate返回验证登录结果。
gate向客户端返回授权结果。

登出（logout） #

im logout

客户端向gate发出logout请求。
gate设置客户端UID对应的peer无效，然后应答客户端登出成功。
gate向logic server发出登录请求。
处理该类请求的c2s服务器，清除redis中的客户端路由信息。

踢人（kickout） #

用户请求授权时，可能在另一个设备（同类型设备，比如一台苹果手机登录时发现一台安卓手机也在登录这个账号）开着软件处于登录状态。这种情况需要系统将那个设备踢下线。

im kickout

新的客户端登陆流程同上面的登陆认证流程，只不过在auth模块完成认证之后，会做如下的操作：

根据UID到redis中查询路由数据，如果不存在说明前面没有登陆过，那么就像登陆流程一样返回即可。
否则说明前面已经有其他设备登陆了，将向前面的gate发送踢人请求，然后保存新的路由信息到redis中。
gate接收到踢人请求，踢掉客户端之后断掉与客户端的连接。

客户端上报消息（c2s消息） #

im c2s msg