产品知识库-高并发IM系统架构优化实践.docxVIP

高并发IM系统架构优化实践在构建社交IM和朋友圈应用时，一个基本的需求是将用户发送的消息和朋友圈更新及时准确的更新给该用户的好友。为了做到这一点，通常需要为用户发送的每一条消息或者朋友圈更新设置一个序号或者ID，并且保证递增，通过这一机制来确保所有的消息能够按照完整并且以正确的顺序被接收端处理。当消息总量或者消息发送的并发数很大的时候，我们通常选择NoSQL存储产品来存储消息，但常见的NoSQL产品都没有提供自增列的功能，因此通常要借助外部组件来实现消息序号和ID的递增，使得整体的架构更加复杂，也影响了整条链路的延时。功能介绍表格存储新推出的?主键列递增?功能可以有效地处理上述场景的需求。具体做法为在创建表时，声明主键中的某一列为自增列，在写入一行新数据的时候，应用无需为自增列填入真实值，只需填入一个占位符，表格存储系统在接收到这一行数据后会自动为自增列生成一个值，并且保证在相同的分区键范围内，后生成的值比先生成的值大.主键列自增功能具有以下几个特性：表格存储独有的系统架构和主键自增列实现方式，可以保证生成的自增列的值唯一，且?严格递增?。目前支持多个主键，第一个主键为分区键，为了数据的均匀分布，不允许设置分区健为自增列。因为分区健不允许设置为自增列，所以主键列自增是?分区键级别的自增?。除了分区键外，其余主键中的任意一个都可以被设置为递增列。对于每张表，目前?只允许设置一个主键列为自增列?。属性列不允许设置为自增列。自增列自动生成的值为?64位的有符号长整型?。自增列功能是?表级别?的，同一个实例下面可以有自增列的表，也可以有非自增列的表。仅支持在创建表的时候设置自增列，对于已存在的表不支持升级为自增列。介绍了表格存储的主键列自增功能后，下面通过具体的场景介绍下如何使用。场景我们继续文章开头的例子，通过构建一个IM聊天工具，演示主键列自增功能的作用和使用方法。功能我们要做的IM聊天软件需要支持下列功能：支持用户一对一聊天支持用户群组内聊天支持同一个用户的多终端消息同步现有架构第一步，确定消息模型上图展示这一消息模型发送方发送了一条消息后，消息会被客户端推送给后台系统后台系统会先存储消息存储成功后，会推送消息给接收方的客户端第二步，确定后台架构后台架构主要分为两部分：逻辑层和存储层。逻辑层包括应用服务器，队列服务和自增ID生成器，是整个后台架构的核心，处理消息的接收、推送、通知，群消息写复制等核心业务逻辑。存储层主要是用来持久化消息数据和其他一些需要持久化的数据。对于一对一聊天，发送方发送消息给应用服务器后，应用服务器将消息存到接收方为主键的表中，同时通知应用服务器中的消息推送服务有新消息了，消息推送服务会将上次推送给接收方的最后一条消息的消息ID作为起始主键，从存储系统中读取之后的所有消息，然后将消息推送给接收方。对于群组内的聊天，逻辑会更加复杂，需要通过异步队列来完成消息的扩散写，也就是说发到群组内的一条消息会给群组内的每个人都存一份。上图展示了省略掉存储层后的群消息发送过程。使用扩散写而非扩散读，主要是由于以下两点原因：群组内成员一般都不多，存储成本并不高，而且有压缩，成本更低。消息扩散写到每个人的存储中（收件箱）后，为每个接收方推送消息时，只需要检查自己的收件箱即可，这时候，群聊和单聊的处理逻辑一样，实现简单。发送方发送了一条消息后，这条消息被客户端推送给应用服务器，应用服务器根据接收者的ID，将消息分发给其中一个队列，同一个接收者的消息位于同一个队列中，在队列中，顺序的处理每条消息，先从自增ID生成器中获取一个新的消息ID，然后将这条消息写入表格存储系统。写成功后再写入下一条消息。同一个接收方的消息会尽量在一个队列中，一个队列中可能会有多个接收方的消息。群组内聊天时可能会出现同一个时刻两个用户同时发送了消息，这两个消息可能会进入不同的应用服务器，但是应用服务器会将同一个接收方的消息发给同一个队列服务，这时候，对于同一个接收方，这两条消息就会处于同一个队列中，如下图：每个队列中的数据串行处理，每次写入表格存储的时候，分配一个新的ID，比之前的ID要大，为了保证消息可以严格递增，避免前一个消息写失败导致无法严格递增的情况出现，需要在写入数据到存储系统的时候，持有一个用户级别的锁，在没有写成功之前，同用户的其他消息不能继续写，以免当前消息写失败后导致乱序，当写成功后，释放这个锁，下一个消息继续。上一步中，如果队列宕机，这些消息需要重新处理，这时候，原有消息就会进入一个新的队列，这时候新的队列需要一个新的消息ID，但要比之前已有的消息ID更大，而这个新队列并不知道之前的最大ID是啥，所以，这里每个队列没法自主创建自增ID，而需要一个全局的自增ID生成器。为了支持多终端，在应用服务器中会为每个终端持有一个session，每个s