本文由阿里闲鱼技术团队今朝、有攸分享本次有修订。1、引言闲鱼即时消息系统历经数代迭代目前已能稳定的支撑亿级消息体量。在此消息系统的建设过程中我们经历了从简单到复杂、从困扰到破局每一次的技术改变都是为了更好的解决当下业务所面临的问题。本文分享的是闲鱼即时消息系统架构从零开始的技术变迁之路以期更多的同行们在此基础上汲取经验得到有价值的启发。2、1.0版业务初创期、最小化可用2.1 技术背景2014年启动闲置交易独立APP “闲鱼”一期构建完成APP主链路包含商品发布→搜索→商品详情→IM会话→交易。作为初创app业务需尽快上线验证效果技术建设上需要完成闲鱼消息从无到有的系统搭建。2.2 技术方案作为即时通讯系统最小化能力包含1消息存储会话、摘要、消息2消息同步推、拉3消息通道长连接、厂商推送。与一般IM会话模型不同的是闲鱼会话以商品为主体“人人商品”为要素构建会话。因会话模型的差异淘系已有的消息系统短期内无法满足业务需求而闲鱼完全自建消息系统耗时巨大。为了保障业务高效上线技术选型上最大化复用已有系统能力避免重复造轮子。所以我们的技术方案是1数据模型与底层存储依赖淘系私信体系进行建设2消息数据获取上客户端全量从服务端拉取消息数据3通讯协议使用来往SDK及mtop。总体架构如下图以此模式完成快速交付保障了业务最小化可用3、2.0版用户量增速快、需要重建消息系统3.1 技术背景闲鱼用户量正快速突破100万即时消息服务的调用量暴涨。在这样的背景下用户反馈消息数据获取的卡顿、白屏成为常态大量的消息Push发送下系统告警频发。造成这些问题的原因1.0版的架构模式下获取消息数据全量拉模式客户端纯UI不做数据存储。具体就是1当用户需要查看消息数据时数据拉取成功与否取决于网络、数据访问速度偶发性的造成卡顿、白屏2中心化的数据存储读远大于写高并发下服务端负载过大。针对第2点比如1W个用户同时在线聊天按照当前架构并发拉取全量消息估算5万QPS。不妨假设同时在线聊天用户数10万时对服务端压力可想而知。3.2 技术方案基于上述问题我们决定重建消息系统架构以应对未来更大的用户增量。回归到IM系统的核心功能3.2.1消息存储模型1会话模型由owner、itemid、user、sessionType 来标识唯一会话增加扩展属性支持个性化2摘要模型作为用户会话视图同一会话的不同用户可个性化呈现由userid、sid标识唯一摘要3消息模型由sender、消息内容、消息版本、sid组成。sid消息版本唯一确定一条消息4指令模型是一种双端约定由服务端下发客户端执行的指令集。如免打扰指令、删除指令等。3.2.2消息通道1在线通道使用淘宝无线ACCS长连接提供的全双工、低延时、高安全的通道服务2离线通道使用淘宝消息推送平台AGOO. 其屏蔽了各主流厂商对接的复杂度直接对业务系统提供服务。3.2.3消息同步模型1客户端建立数据库存储消息数据当消息数据存储在本地设备上消息同步从全量拉取优化为全量增量同步结合的模式。增量和全量同步具体指的是a. 增量同步客户端存储消息位点信息通过与服务端最新位点比较仅同步增量消息b. 全量同步当用户卸载重装或位点gap过大时客户端全量拉取历史消息数据进行端上数据重建。2服务端建设个人消息域环(收件箱模型)以和客户端进行增量数据同步。同时1.0版本架构中存在的读多写少的问题通过个人域环的写扩散来平衡读写压力。下图为一条消息从发送到接收的过程以及服务端和客户端的执行流程如上图所示假设Ua给Ub发送一条消息消息写扩散至Ua和Ub的各自的域环中1当客户端online时接收到推送的消息位点当前端上域版本1本地消息数据库merge即可2当客户端offline时仅进行离线推送通知当用户重新上线时进行数据同步由服务端判断触发增量同步还是全量同步。针对第2点具体逻辑是1如果域环版本差值小于阀值增量同步后进行本地消息数据库merge2当域环版本差值大于阀值进行全量消息拉取做端上数据重建。整个同步逻辑基于闲鱼的即时消息域环域环可以看作是有着固定容量的用户消息收件箱给一个用户发送的所有消息都会同步到他的域环中。具体就是1域环存储域环需要支持高并发数据读写使用阿里分布式KV存储系统tair来实现2域环容量为减少全量消息同步以用户下次进入闲鱼需要同步的平均消息量来规划个人域环容量。同时利用FIFO循环覆盖历史数据3域环版本用户当前消息位点在消息进入个人域环时通过tair的counter实现域环版本严格连续递增用于全量、增量同步判断。上述建设完成后闲鱼具备了自己独立的即时消息系统当下遇到的问题得到了缓解用户体验度有大幅提升。4、3.0版随着业务快速发展系统稳定性需得到保障4.1 技术背景随着闲鱼业务生态的丰富IM会话与消息内容类型不断扩展同时在用户量的快速增长下用户反馈消息收不到、消息延迟等舆情问题日渐突出。4.2 问题分析问题1闲鱼app进程无有效保活机制app退到后台后进程很快就会被系统挂起导致长连接中断。此时消息推送走厂商通道而厂商通道的实时性较差且对消息推送的优先级设定有差异从而造成用户感知消息延迟。问题2accs在线消息推送时平均延时较短但存在假连情况。而且目前的消息推送链路无ack机制造成服务端以为消息发出去了但实际上客户端并没有收到用户下次打开app后才能看到消息用户感知消息延迟。PS造成假连接的原因主要是用户退到后台accs长连中断但是设备状态更新有延时。问题3目前消息同步的推模式(accs push)、拉模式(mtop)客户端未做隔离异步进行处理导致在某些极端情况下消息数据库处理异常引发消息丢失。如某用户上线后连续收到多条消息其中一条触发域黑洞在进行消息同步端上数据重建时小概率处理出错。问题4大部分线上消息问题发现靠舆情反馈如消息错乱出问题后系统无感知、无补救措施且排查困难仅能跟随版本做修复。问题5业务不断丰富孵化出基于消息系统的服务号及小程序内容营销、消息群组等各类消息发送链路共用域环与数据存储造成稳定性问题。如个人域环的消息包括IM聊天和营销消息IM聊天由用户触发需要保证强到达而营销消息一般是由系统通过班车等方式批量发送消息量级大tps高影响IM服务稳定性。4.3 解案决方案基于上述分析我们逐个问题进行专项解决。1消息重发与推拉隔离如上图所示a. ACK保障消息及时到达。服务端下行accs消息时将消息加入重试队列并延迟重试客户端在收到accs消息并处理成功后给服务端回一个ack服务端收到ack后更新消息到达状态并终止重试以此避免设备假连或网络不稳定的情况b. 重发根据延迟重发策略决定何时重发消息保障消息确定性到达。自适应延迟重发策略是指新消息先通过4次固定N秒的短延迟来探测设备的网络状况然后根据网络状况来递增固定步长M的延迟策略这种策略可以保障在最短的时间内使用最少的重发次数将消息投递成功c. 消息队列端上引入消息队列按顺序处理消息保证消息处理的准确性。同时进行推拉隔离保障队列有序消费解决了复杂状况下并发处理消息数据合并出错的问题。2数据存储拆分闲鱼每天发送的即时消息中有一半以上是营销消息营销消息的发送具有明显的波峰波谷流量高峰期会导致消息数据库抖动影响IM消息。我来对消息、摘要、域环存储做业务隔离以适应不同业务场景对稳定性不同的要求。具体做法是1IM消息需要极高的稳定性保证其消息及摘要继续使用mysql存储2营销消息存储周期短稳定性要求低于IM采用Lindorm存储3域环做实例级别隔离保证IM域环的容量不会被其他消息占用从而影响到消息同步。PSLindorm是一种多模型的云原生数据库服务具有成本低、自定义TTL、容量横向扩展等优势。3线上问题发现与恢复保障稳定性的关键要素是做好各种核心指标的监控而监控首先要有数据来源对服务端客户端的关键链路节点埋点基于集团UT、SLS通过blink进行实时清洗、计算最终形成统一规范的日志数据落至SLS以供实时监控及链路排查。消息系统的核心目标是保障用户消息发的出、收得到且及时收到所以我们通过计算发送成功率、到达率、消息延迟来监控系统的稳定性。此外为了解决用户舆情排查困难的问题1我们设计了一套指令集通过约定指令协议服务端向指定用户下发指令客户端执行对应指令进行异常数据上报提高排查效率2扩展了强制全量同步、数据校正等指令定向修复用户消息数据问题相较以往出现严重bug只能让用户卸载重装解决这种方式显然对用户是更友好的。经过一系列专项治理技术类舆情下降50%从0到1建设了消息稳定性体系用户体验进一步提升。5、展望未来闲鱼作为电商交易APP 其中IM是交易的前置链路IM的产品体验极大影响用户交易效率。前段时间进行用户调研从闲鱼IM的NPS低于预期NPS是用户忠诚度衡量指标 推荐者%-贬损者%。从用户反馈来看1部分用户对产品功能有较强烈的诉求诸如消息搜索、分组等2大部分用户对发送消息过程中的违规问题难以理解3仍有较多舆情反馈消息收不到或延迟。映射到目前闲鱼的即时消息系统上我们的系统架构依然有很多需要持续改进的地方。典型的如同步协议冗余在需求迭代过程中容易引发问题、有效保活机制的缺失对消息即时送达的影响、小众机型离线消息收不到、多年的数据积累在线库臃肿等问题影响着闲鱼业务迭代速度与NPS。作为技术团队下一步将提升NPS作为核心技术目标闲鱼的即时消息系统4.0版架构正在路上 ......6、参考资[1] 浅谈IM系统的架构设计》[2] 简述移动端IM开发的那些坑架构设计、通信协议和客户端[3] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)[4] 一套原创分布式即时通讯(IM)系统理论架构方案[5] 从零到卓越京东客服即时通讯系统的技术架构演进历程[6] 蘑菇街即时通讯/IM服务器开发之架构选择[7] 一套亿级用户的IM架构技术干货(上篇)整体架构、服务拆分等[8] 从新手到专家如何设计一套亿级消息量的分布式IM系统[9] 企业微信的IM架构设计揭秘消息模型、万人群、已读回执、消息撤回等[10] 融云技术分享全面揭秘亿级IM消息的可靠投递机制[11] 闲鱼IM的在线、离线聊天数据同步机制优化实践[12] 深度揭秘钉钉即时消息服务DTIM的技术设计[13] 基于实践一套百万消息量小规模IM系统技术要点总结[14] 跟着源码学IM(十)基于Netty搭建高性能IM集群含技术思路源码[15] 一套十万级TPS的IM综合消息系统的架构实践与思考[16] 海量用户IM聊天室的架构设计与实践[17] 企业微信针对百万级组织架构的客户端性能优化实践[18] 小红书万亿级社交网络关系下的图存储系统的架构设计与实践[19] 一套分布式IM即时通讯系统的技术选型和架构设计[20] 微信团队分享来看看微信十年前的IM消息收发架构你做到了吗[21] 携程技术分享亿级流量的办公IM及开放平台技术实践[22] 转转平台IM系统架构设计与实践(一)整体架构设计[23] 支持百万人超大群聊的Web端IM架构设计与实践[24] B站IM消息系统的新架构升级实践[25] 如何保障分布式IM聊天系统的消息有序性即消息不乱即时通讯技术学习- 移动端IM开发入门文章《新手入门一篇就够从零开发移动端IM》- 开源IM框架源码https://github.com/JackJiang2011/MobileIMSDK备用地址点此本文同步发布于 http://www.52im.net/thread-3699-1-1.html
本文由阿里闲鱼技术团队今朝、有攸分享本次有修订。1、引言闲鱼即时消息系统历经数代迭代目前已能稳定的支撑亿级消息体量。在此消息系统的建设过程中我们经历了从简单到复杂、从困扰到破局每一次的技术改变都是为了更好的解决当下业务所面临的问题。本文分享的是闲鱼即时消息系统架构从零开始的技术变迁之路以期更多的同行们在此基础上汲取经验得到有价值的启发。2、1.0版业务初创期、最小化可用2.1 技术背景2014年启动闲置交易独立APP “闲鱼”一期构建完成APP主链路包含商品发布→搜索→商品详情→IM会话→交易。作为初创app业务需尽快上线验证效果技术建设上需要完成闲鱼消息从无到有的系统搭建。2.2 技术方案作为即时通讯系统最小化能力包含1消息存储会话、摘要、消息2消息同步推、拉3消息通道长连接、厂商推送。与一般IM会话模型不同的是闲鱼会话以商品为主体“人人商品”为要素构建会话。因会话模型的差异淘系已有的消息系统短期内无法满足业务需求而闲鱼完全自建消息系统耗时巨大。为了保障业务高效上线技术选型上最大化复用已有系统能力避免重复造轮子。所以我们的技术方案是1数据模型与底层存储依赖淘系私信体系进行建设2消息数据获取上客户端全量从服务端拉取消息数据3通讯协议使用来往SDK及mtop。总体架构如下图以此模式完成快速交付保障了业务最小化可用3、2.0版用户量增速快、需要重建消息系统3.1 技术背景闲鱼用户量正快速突破100万即时消息服务的调用量暴涨。在这样的背景下用户反馈消息数据获取的卡顿、白屏成为常态大量的消息Push发送下系统告警频发。造成这些问题的原因1.0版的架构模式下获取消息数据全量拉模式客户端纯UI不做数据存储。具体就是1当用户需要查看消息数据时数据拉取成功与否取决于网络、数据访问速度偶发性的造成卡顿、白屏2中心化的数据存储读远大于写高并发下服务端负载过大。针对第2点比如1W个用户同时在线聊天按照当前架构并发拉取全量消息估算5万QPS。不妨假设同时在线聊天用户数10万时对服务端压力可想而知。3.2 技术方案基于上述问题我们决定重建消息系统架构以应对未来更大的用户增量。回归到IM系统的核心功能3.2.1消息存储模型1会话模型由owner、itemid、user、sessionType 来标识唯一会话增加扩展属性支持个性化2摘要模型作为用户会话视图同一会话的不同用户可个性化呈现由userid、sid标识唯一摘要3消息模型由sender、消息内容、消息版本、sid组成。sid消息版本唯一确定一条消息4指令模型是一种双端约定由服务端下发客户端执行的指令集。如免打扰指令、删除指令等。3.2.2消息通道1在线通道使用淘宝无线ACCS长连接提供的全双工、低延时、高安全的通道服务2离线通道使用淘宝消息推送平台AGOO. 其屏蔽了各主流厂商对接的复杂度直接对业务系统提供服务。3.2.3消息同步模型1客户端建立数据库存储消息数据当消息数据存储在本地设备上消息同步从全量拉取优化为全量增量同步结合的模式。增量和全量同步具体指的是a. 增量同步客户端存储消息位点信息通过与服务端最新位点比较仅同步增量消息b. 全量同步当用户卸载重装或位点gap过大时客户端全量拉取历史消息数据进行端上数据重建。2服务端建设个人消息域环(收件箱模型)以和客户端进行增量数据同步。同时1.0版本架构中存在的读多写少的问题通过个人域环的写扩散来平衡读写压力。下图为一条消息从发送到接收的过程以及服务端和客户端的执行流程如上图所示假设Ua给Ub发送一条消息消息写扩散至Ua和Ub的各自的域环中1当客户端online时接收到推送的消息位点当前端上域版本1本地消息数据库merge即可2当客户端offline时仅进行离线推送通知当用户重新上线时进行数据同步由服务端判断触发增量同步还是全量同步。针对第2点具体逻辑是1如果域环版本差值小于阀值增量同步后进行本地消息数据库merge2当域环版本差值大于阀值进行全量消息拉取做端上数据重建。整个同步逻辑基于闲鱼的即时消息域环域环可以看作是有着固定容量的用户消息收件箱给一个用户发送的所有消息都会同步到他的域环中。具体就是1域环存储域环需要支持高并发数据读写使用阿里分布式KV存储系统tair来实现2域环容量为减少全量消息同步以用户下次进入闲鱼需要同步的平均消息量来规划个人域环容量。同时利用FIFO循环覆盖历史数据3域环版本用户当前消息位点在消息进入个人域环时通过tair的counter实现域环版本严格连续递增用于全量、增量同步判断。上述建设完成后闲鱼具备了自己独立的即时消息系统当下遇到的问题得到了缓解用户体验度有大幅提升。4、3.0版随着业务快速发展系统稳定性需得到保障4.1 技术背景随着闲鱼业务生态的丰富IM会话与消息内容类型不断扩展同时在用户量的快速增长下用户反馈消息收不到、消息延迟等舆情问题日渐突出。4.2 问题分析问题1闲鱼app进程无有效保活机制app退到后台后进程很快就会被系统挂起导致长连接中断。此时消息推送走厂商通道而厂商通道的实时性较差且对消息推送的优先级设定有差异从而造成用户感知消息延迟。问题2accs在线消息推送时平均延时较短但存在假连情况。而且目前的消息推送链路无ack机制造成服务端以为消息发出去了但实际上客户端并没有收到用户下次打开app后才能看到消息用户感知消息延迟。PS造成假连接的原因主要是用户退到后台accs长连中断但是设备状态更新有延时。问题3目前消息同步的推模式(accs push)、拉模式(mtop)客户端未做隔离异步进行处理导致在某些极端情况下消息数据库处理异常引发消息丢失。如某用户上线后连续收到多条消息其中一条触发域黑洞在进行消息同步端上数据重建时小概率处理出错。问题4大部分线上消息问题发现靠舆情反馈如消息错乱出问题后系统无感知、无补救措施且排查困难仅能跟随版本做修复。问题5业务不断丰富孵化出基于消息系统的服务号及小程序内容营销、消息群组等各类消息发送链路共用域环与数据存储造成稳定性问题。如个人域环的消息包括IM聊天和营销消息IM聊天由用户触发需要保证强到达而营销消息一般是由系统通过班车等方式批量发送消息量级大tps高影响IM服务稳定性。4.3 解案决方案基于上述分析我们逐个问题进行专项解决。1消息重发与推拉隔离如上图所示a. ACK保障消息及时到达。服务端下行accs消息时将消息加入重试队列并延迟重试客户端在收到accs消息并处理成功后给服务端回一个ack服务端收到ack后更新消息到达状态并终止重试以此避免设备假连或网络不稳定的情况b. 重发根据延迟重发策略决定何时重发消息保障消息确定性到达。自适应延迟重发策略是指新消息先通过4次固定N秒的短延迟来探测设备的网络状况然后根据网络状况来递增固定步长M的延迟策略这种策略可以保障在最短的时间内使用最少的重发次数将消息投递成功c. 消息队列端上引入消息队列按顺序处理消息保证消息处理的准确性。同时进行推拉隔离保障队列有序消费解决了复杂状况下并发处理消息数据合并出错的问题。2数据存储拆分闲鱼每天发送的即时消息中有一半以上是营销消息营销消息的发送具有明显的波峰波谷流量高峰期会导致消息数据库抖动影响IM消息。我来对消息、摘要、域环存储做业务隔离以适应不同业务场景对稳定性不同的要求。具体做法是1IM消息需要极高的稳定性保证其消息及摘要继续使用mysql存储2营销消息存储周期短稳定性要求低于IM采用Lindorm存储3域环做实例级别隔离保证IM域环的容量不会被其他消息占用从而影响到消息同步。PSLindorm是一种多模型的云原生数据库服务具有成本低、自定义TTL、容量横向扩展等优势。3线上问题发现与恢复保障稳定性的关键要素是做好各种核心指标的监控而监控首先要有数据来源对服务端客户端的关键链路节点埋点基于集团UT、SLS通过blink进行实时清洗、计算最终形成统一规范的日志数据落至SLS以供实时监控及链路排查。消息系统的核心目标是保障用户消息发的出、收得到且及时收到所以我们通过计算发送成功率、到达率、消息延迟来监控系统的稳定性。此外为了解决用户舆情排查困难的问题1我们设计了一套指令集通过约定指令协议服务端向指定用户下发指令客户端执行对应指令进行异常数据上报提高排查效率2扩展了强制全量同步、数据校正等指令定向修复用户消息数据问题相较以往出现严重bug只能让用户卸载重装解决这种方式显然对用户是更友好的。经过一系列专项治理技术类舆情下降50%从0到1建设了消息稳定性体系用户体验进一步提升。5、展望未来闲鱼作为电商交易APP 其中IM是交易的前置链路IM的产品体验极大影响用户交易效率。前段时间进行用户调研从闲鱼IM的NPS低于预期NPS是用户忠诚度衡量指标 推荐者%-贬损者%。从用户反馈来看1部分用户对产品功能有较强烈的诉求诸如消息搜索、分组等2大部分用户对发送消息过程中的违规问题难以理解3仍有较多舆情反馈消息收不到或延迟。映射到目前闲鱼的即时消息系统上我们的系统架构依然有很多需要持续改进的地方。典型的如同步协议冗余在需求迭代过程中容易引发问题、有效保活机制的缺失对消息即时送达的影响、小众机型离线消息收不到、多年的数据积累在线库臃肿等问题影响着闲鱼业务迭代速度与NPS。作为技术团队下一步将提升NPS作为核心技术目标闲鱼的即时消息系统4.0版架构正在路上 ......6、参考资[1] 浅谈IM系统的架构设计》[2] 简述移动端IM开发的那些坑架构设计、通信协议和客户端[3] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)[4] 一套原创分布式即时通讯(IM)系统理论架构方案[5] 从零到卓越京东客服即时通讯系统的技术架构演进历程[6] 蘑菇街即时通讯/IM服务器开发之架构选择[7] 一套亿级用户的IM架构技术干货(上篇)整体架构、服务拆分等[8] 从新手到专家如何设计一套亿级消息量的分布式IM系统[9] 企业微信的IM架构设计揭秘消息模型、万人群、已读回执、消息撤回等[10] 融云技术分享全面揭秘亿级IM消息的可靠投递机制[11] 闲鱼IM的在线、离线聊天数据同步机制优化实践[12] 深度揭秘钉钉即时消息服务DTIM的技术设计[13] 基于实践一套百万消息量小规模IM系统技术要点总结[14] 跟着源码学IM(十)基于Netty搭建高性能IM集群含技术思路源码[15] 一套十万级TPS的IM综合消息系统的架构实践与思考[16] 海量用户IM聊天室的架构设计与实践[17] 企业微信针对百万级组织架构的客户端性能优化实践[18] 小红书万亿级社交网络关系下的图存储系统的架构设计与实践[19] 一套分布式IM即时通讯系统的技术选型和架构设计[20] 微信团队分享来看看微信十年前的IM消息收发架构你做到了吗[21] 携程技术分享亿级流量的办公IM及开放平台技术实践[22] 转转平台IM系统架构设计与实践(一)整体架构设计[23] 支持百万人超大群聊的Web端IM架构设计与实践[24] B站IM消息系统的新架构升级实践[25] 如何保障分布式IM聊天系统的消息有序性即消息不乱即时通讯技术学习- 移动端IM开发入门文章《新手入门一篇就够从零开发移动端IM》- 开源IM框架源码https://github.com/JackJiang2011/MobileIMSDK备用地址点此本文同步发布于 http://www.52im.net/thread-3699-1-1.html
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
