一种基于timeline模型的即时通讯多端同步的方法
技术领域
本发明涉及计算机通讯
技术领域
，具体为一种基于timeline模型的即时通讯多端同步的方法。背景技术
Timeline是一个对消息抽象的逻辑模型，该模型会帮助我们简化对消息同步和存储模型的理解，而消息同步库的设计和实现也是围绕Timeline的特性和需求来展开。Timeline模型是针对消息数据场景所设计的，能够满足消息数据场景对消息保序、海量消息存储、实时同步的特殊需求，同时支持全文检索与多维度组合查询。可以同时应用在IM、Feed流等消息场景的实现上。
TimeLine模型对数据库的要求非常高，主要包括：
1)表结构设计能够满足Timeline模型的功能要求：不要求关系模型，能够实现队列模型；
2)能够支持高并发写和范围读，规模在十万级TPS；
3)能够保存百TB级海量数据；
4)能够为数据定义生命周期。
目前主流实现IM的timeline模型采用tablElasticSearchtore(阿里云表格存储)
现有技术的缺陷和不足：
1)阿里云的表格存储价格在消息量大时价格昂贵，性价比低；
2)如果不购买价格高的套餐，性能差，经常出现请求超时现象；
3)数据保存在第三方，无法私有化保存数据。
鉴于此，我们提出一种基于timeline模型的即时通讯多端同步的方法。
发明内容
为了弥补以上不足，本发明提供了一种基于timeline模型的即时通讯多端同步的方法。
本发明的技术方案是：
一种基于timeline模型的即时通讯多端同步的方法，包括如下步骤：
步骤一：消息同步库的发送、读取与缓存；
步骤二：消息同步库存储到每个用户的消息队列；
步骤三：消息同步库的放大存储。
作为优选的技术方案，步骤一的具体操作为：所有消息发送至Rabbitmq服务器，消息消费程序从消息队列读取，由于群聊会有写放大的问题，此处采用批量插入的方式，群内的一条消息批量写入到N个成员的消息队列里，此处会出现消息的冗余存储，把消息内容存储到redis缓存空间中，插入ElasticSearch中的冗余的只有消息Id，大大减少了消息存储占用的空间。
作为优选的技术方案，同步库存储每一个用户的消息队列，每当有关于该用户的消息就会存储到该用户的消息队列中，为了实现该消息队列，存储的字段包括了sourceUid，此字段标识该消息属于谁的消息，isReaded标识消息是否已读，created标识消息存储的时间戳，msgId标识消息的ID，targetGid标识群消息的id，targetUid单聊时标识对方的id。
作为优选的技术方案，步骤三的具体操作为：一条单聊消息会插入到发送人的消息队列也会插入到接收人的消息队列，也就是单聊写放大两份，群聊写放大N份，消息内容写入Redis缓存中，过期时间设置为一个月，此外写一份到mysql数据库中，保证消息在缓存失效后可以从数据库中查询到，存入消息队列时不必写入完整消息，只需要记录消息id，查询时通过消息id就可以从redis或者msyql中查询出完整消息内容。
作为优选的技术方案，步骤三中存储消息写放大过程中，单聊放大2份，群聊放大N份，此处采用ElasticSearch提供的批量插入api，单聊的2份文档批量插入，群聊的N份消息也批量插入，大大提高了消息的存储效率。
作为优选的技术方案，步骤二中的消息存储时机为当消息抵达客户端时，客户端会有一个回执消息发送到服务器端，服务器端接收到这个消息，则可确认此消息已经抵达客户端，服务器此时存储消息。
作为优选的技术方案，步骤二中的消息存储方式为将消息按照群聊和单聊发送到消息队列Rabbitmq中进行异步存储消息，即当消息发送到消息队列之后，立即推送给客户端，此时消息可能还未存储，消息推送和消息存储是异步进行的。
作为优选的技术方案，步骤三中存储消息数据与放大存储方式如下：
单聊，队列存储详情：
From：发送人id；
To：接收人id；
IsReaded：消息是否已读；
Msgs：消息体；
Created：时间戳；
MsgId：消息唯一标识id；
群聊，队列存储详情：
Sender：发送人id；
Gid：群id；
IsReaded：消息是否已读；
Created：时间戳；
MsgId：消息唯一标识id；
Members：群成员数组信息；
放大存储即单聊时消息需要存储两份，调换sourceUid和targetGid，各存储一份，群聊时存储N份。
作为优选的技术方案，步骤三中的消息写放大：
单聊消息存储两份：
存储字段为：
sourceUid：当前消息发送人的id；
created：消息的时间戳；
Msgs：消息体的存储；
TargetUid：对方的id；
遍历members，每一个遍历的id作为sorceUid,其余字段：
Gid：群id；
msgid：消息id；
created：消息时间戳；
IsReaded：消息是否已读；
写放大即单聊时消息需要存储两份，调换sourceUid和targetGid，各存储一份，群聊时存储N份。
与现有技术相比，本发明的有益效果是：
本发明采用ElasticSearch开源免费的存储同步消息，极大的节约了成本，同时数据私有化存储，并且ElasticSearch出色的检索数据性能完美的满足了消息存储与查询的要求，本发明的存储方式采用批量存储的方式拥有非常好的存储性能，此外冗余的消息体只需存储一份，节省了数据存储的空间；当数据量比较小的情况下，可以直接将其插入单台机器的一个索引中，ElasticSearch的性能足够应付，当数据量变得比较大，可以将ElasticSearch的索引分片，将分片分配到不同的机器上，并行搜索以满足性能的要求，当插入海量数据到ElasticSearch的索引中时，一个分片中的数据变得很大，此时搜索性能就会下降，因为成本的考虑，不能随意横向扩容。可以根据数据的时间局部性，即时间近的数据往往访问频繁(即热数据)，时间远的数据往往访问较少(即冷数据)，可以将数据拆分到不同的索引中，热数据索引可以设置较多的分片，分配到性能较高的机器上。冷数据索引设置较少的分片以节约存储空间，分配到性能普通的机器上。这样可以在确保绝大多数访问性能的情况下，最大限度地节约成本。
附图说明
图1为本发明的存储流程示意图；
图2为本发明的TimeLine模型示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
在本发明的描述中，需要理解的是，术语“中心”、“纵向”、“横向”、“长度”、“宽度”、“厚度”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、“内”、“外”、“顺时针”、“逆时针”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的设备或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。
请参阅图1-2，本发明提供一种技术方案：
一种基于timeline模型的即时通讯多端同步的方法，包括如下步骤：
步骤一：消息同步库的发送、读取与缓存；
步骤二：消息同步库存储到每个用户的消息队列；
步骤三：消息同步库的放大存储。
作为本实施例的优选，步骤一的具体操作为：所有消息发送至Rabbitmq服务器，消息消费程序从消息队列读取，由于群聊会有写放大的问题，此处采用批量插入的方式，群内的一条消息批量写入到N个成员的消息队列里，此处会出现消息的冗余存储，把消息内容存储到redis缓存空间中，插入ElasticSearch中的冗余的只有消息Id，大大减少了消息存储占用的空间。
作为本实施例的优选，同步库存储每一个用户的消息队列，每当有关于该用户的消息就会存储到该用户的消息队列中，为了实现该消息队列，存储的字段包括了sourceUid，此字段标识该消息属于谁的消息，isReaded标识消息是否已读，created标识消息存储的时间戳，msgId标识消息的ID，targetGid标识群消息的id，targetUid单聊时标识对方的id。
作为本实施例的优选，步骤三的具体操作为：一条单聊消息会插入到发送人的消息队列也会插入到接收人的消息队列，也就是单聊写放大两份，群聊写放大N份，消息内容写入Redis缓存中，过期时间设置为一个月，此外写一份到mysql数据库中，保证消息在缓存失效后可以从数据库中查询到，存入消息队列时不必写入完整消息，只需要记录消息id，查询时通过消息id就可以从redis或者msyql中查询出完整消息内容。
作为本实施例的优选，步骤三中存储消息写放大过程中，单聊放大2份，群聊放大N份，此处采用ElasticSearch提供的批量插入api，单聊的2份文档批量插入，群聊的N份消息也批量插入，大大提高了消息的存储效率。
作为本实施例的优选，步骤二中的消息存储时机为当消息抵达客户端时，客户端会有一个回执消息发送到服务器端，服务器端接收到这个消息，则可确认此消息已经抵达客户端，服务器此时存储消息。
作为本实施例的优选，步骤二中的消息存储方式为将消息按照群聊和单聊发送到消息队列Rabbitmq中进行异步存储消息，即当消息发送到消息队列之后，立即推送给客户端，此时消息可能还未存储，消息推送和消息存储是异步进行的。
作为本实施例的优选，步骤三中存储消息数据与放大存储方式如下：
单聊，队列存储详情：
From：发送人id；
To：接收人id；
IsReaded：消息是否已读；
Msgs：消息体；
Created：时间戳；
MsgId：消息唯一标识id；
群聊，队列存储详情：
Sender：发送人id；
Gid：群id；
IsReaded：消息是否已读；
Created：时间戳；
MsgId：消息唯一标识id；
Members：群成员数组信息；
放大存储即单聊时消息需要存储两份，调换sourceUid和targetGid(聊天对象的id)，各存储一份，群聊时存储N份。
作为优选的技术方案，步骤三中的消息写放大：
单聊消息存储两份：
存储字段为：
sourceUid：当前消息发送人的id；
created：消息的时间戳；
Msgs：消息体的存储；
TargetUid：对方的id；
遍历members，每一个遍历的id作为sorceUid,其余字段：
Gid：群id；
msgid：消息id；
created：消息时间戳；
IsReaded：消息是否已读；
写放大即单聊时消息需要存储两份，调换sourceUid和targetGid，各存储一份，群聊时存储N份。
以上显示和描述了本发明的基本原理、主要特征和本发明的优点。本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的仅为本发明的优选例，并不用来限制本发明，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。本发明要求保护范围由所附的权利要求书及其等效物界定。
- 上一篇：石墨接头机器人自动装卡簧、装栓机
- 下一篇：数据的处理方法、装置及服务器
