Swift系统中的Topic与其它消息系统的类似，它是一堆相关消息的集合，通常由业务自定义。在Swift中，Topic是由65536个逻辑分区组成，编号是[0 - 65535]。在Swift消息系统内部，Topic是由Partition组成的，每个Partition负责一个range的逻辑Partition读写。

在用户层面，用户看不到Swift的物理Partition，写消息时要么需要提供一个hash字段（由Swift client自动映射到相应的逻辑分区）要么提供一个0-65535的逻辑编号。Swift根据Topic下每个Partition的服务range，把消息写入相应Partition的writer中。Writer可以通过同步与异步方式把消息append到对应的物理Partition中。

Topic的物理Partition个数影响整个Topic的读写能力，通过逻辑Partition与物理Partition映射，当Topic的服务能力不足时，可以动态的扩展物理Partition来提升读写能力。另外，物理Partition是Swift的基本调度单元，Admin会根据每个Broker worker负载，尽可能平衡地调度Partition。

先前提到传统的消息系统为了保证消息的可靠性，在写消息时需要先落盘，以防机器挂掉时消息丢失。Swift也提供类似的模式，但落盘的对象是分布式文件系统如HDFS。这种模式下正常写落盘消息延时的毫秒级，当HDFS压力大时，会变成秒级，所以其性能不太稳定。

Swift 设计了一种client与Broker之间,Broker与HDFS之间的消息写入与确认协议来保证消息高效可靠的写入与持久化，其机制类似TCP的滑动窗口协议。下图是消息异步安全发送的示意图。Broker在分配到Partition进行服务时，会生成一个标记，其由Partition的版本号(V)，Broker加载Partition时间戳(S)以及消息持久化的checkpoint (C)组成。Client在向Admin定位到Partition所在Broker的时候也会获取Partition的版本号(V)。版本号V主要在Topic属性发生变化时（例如Partition的个数等）会更新。时间戳在每次Partition发生重新加载或调度都会发生变化。

1. 用户通过客户端写入一条消息，client定位到写哪个物理Partition，同时把消息写入到对应的buffer中。用户写消息时，还可以给每条消息设置一个递增编号，Swift client会自动映射写消息进度与编号的关系。在异步模式中，client会有专门的提交线程与Broker进行通信。

   
   

2. Client第一次向Partition发送消息时，Broker会验证Partition的版本V0, 匹配后才会接受消息，同时会把三元组(V，S, C)返回。client收到accept消息后，会更新已接受消息的光标和协议的三元组信息。

   
   

3. 客户端可以持续地写入消息，同时Broker把Partition中的消息做异步持久化，当持久化成功时，会更新持久化信息(Ca)。持久化成功的消息在内存中不会马上删除，只有内存不足时才会被回收。

   
   

4. Client的后台发送线程继续工作，发送消息b，同时请求带上了(V0,S0)。

   
   

5. Broker端验证(V0,S0)，收受消息b，顺便把持久化信息也返回(V0,S0,Ca), client接收到accept信息后，更新已发送的光标到b，同时更新已接受的光标到a。消息a已经持久化成功，在使用的内存将会被writer回收。Writer更新checkpoint (Ca)给用户层，表示消息a已经持久化。

   
   

6. 同3一样，client继续写消息c，Broker继续持久化消息b。

   
   

7. 此时Partition发生了调度（例如被分配到了其它机器），其HDFS上的文件消息马上可以读取到，但内存中的消息会被清空。此时Partition加载时间戳变成了S1。Client向Admin重新定位到Partition的服务Broker写入的消息c和(V0,S0)。

   
   

8. Broker检查client发送的(V0,S0)与自身的(V0,S1)不相等，将拒绝此次消息的写入。主要基于消息在Partition内要求保序考虑。此时client还不知道b是否被序列化成功，Partition重新被加载b是否被序列化成功的信息也会被丢弃(无状态)，所以它也不知道。因Broker返回(V0,S1,C0)，要求client重新发送未持久化的所有消息。

   
   

9. Client 重置已发送光标到b之前，更新S1并重新发送消息b和c。

   
   

10. Broker检验client的(V0,S1)并收受消息b和c，这时消息b会被再次持久化到HDFS上。Client重新更新已发送光标到c。如果此后无新消息的写入，且buffer中的消息还有未被持久化的，client会发起一次空写操作获取最新的持久化信息。

步骤1-10是异步消息写入的工作方式，用户层可以获取到当前持久化消息的checkpoint，可以自己记录发送进度以便回滚。如果不方便记录发送进度，可以在写完一段数据后，调用flush方法强制把数据从client的buffer放到Broker的buffer中。此时消息虽然没有被持久化，但在client与Partition各存一份。所以只有在Broker与client同时挂掉才出现消息丢失，因此我们认为这种方法也是比较安全的。

Swift Partition的写buffer缓存所有写入的消息，只有当空间不足时，消息内存空间才会被回收。对文件上的消息读取，也会以块buffer的方式做缓存。Partition之间的buffer和文件cache buffer都是共享存储，由统一的回收模块管理。其保证冷门的Partition基本不消耗资源，热门的Partition可以利用非常的多资源。正常情况下，Swift的内存可以缓存1-10分钟的消息，所以消费消息时基本上从内存读取，读的性能也会很高效。在这个协议下，写HDFS发生偶尔抖动也不会影响消息的时效性，实际中HDFS在10分钟内的挂机也不影响消息的实时传递。

相比较其他消息中间件，如Kafka、Metaq，Swift多了一个Admin的角色。Admin的存在使得对集群的操作有统一的入口，系统的容错性也更为强大。

Swift Admin的另一个重要功能就是进行Partition的动态调度，简单来说就是将所有的逻辑Partition向Broker上进行任务分配的过程。

Broker是Swift消息发送和读取的载体，由Admin通过调用hippo进行启动和调度。Broker是单独的一个进程，单台物理机器可以运行多个Broker。Broker加载的最小单位是Topic的Partition，一个进程内可以加载相同Topic的多个不同Partition。Partition由所在的分组名称、Topic的名字以及列数所决定。

Broker在接收消息时，默认先写到内存中，然后由后台线程进行消息的持久化，一般是写到HDFS上，这样可以保证Broker在迁移或者重启后仍然可以读到消息。读消息时也是先从内存消息中读取，读取不到再从HDFS中进行读取，以保证消息读取的效率。

Broker与Admin之间通过zookeeper进行通信，Admin会将需要Broker加载的Partition信息放到zk的指定路径的文件中，文件名即Broker机器地址，对应的Broker会监控此路径，当内容发生变化时进行任务的读取，即Partition的加载。同时Broker会实时向Admin汇报心跳，内容即加载Partition的信息，Admin再根据Broker的心跳信息进行决策。