业务初创难题
在业务初创期，闲鱼这款app急需尽快上线来验证业务效果。在技术建设方面，得完成消息系统从无到有的搭建。然而，因为会话模型和淘系不一样，淘系已有的消息系统在短期内满足不了闲鱼的业务需求。要是闲鱼完全自建消息系统，又要耗费大量时间，这让初创的业务推进异常艰难。
架构模式困境
1.0版的架构模式下，获取消息数据采用全量拉模式，客户端纯粹做UI展示，不进行数据存储。这种模式存在很大问题，全量拉取数据耗时又耗资源，在业务快速发展阶段，明显无法满足需求，让消息系统的运行效率大打折扣，给后续的业务拓展埋下了隐患。
客户端数据库革新
为了解决上述问题，客户端建立数据库来存储消息数据。消息同步从全量拉取优化为全量和增量同步结合的模式。增量同步时，客户端存储消息位点信息，将其与服务端最新位点比较，只同步增量消息。例如，当客户端在线时，接收到推送的消息位点等于当前端上域版本加1，在本地消息数据库进行合并就行。
域环的关键作用
域环就像是有着固定容量的用户消息收件箱，用户的所有消息都会同步到这里。为减少全量消息同步，根据用户下次进入闲鱼需要同步的平均消息量来规划个人域环容量。而且域环版本代表用户当前消息位点，消息进入个人域环时通过tair的counter实现域环版本严格连续递增，用来进行全量、增量同步判断。
增长期的舆情问题
随着闲鱼业务生态不断丰富，IM会话和消息内容类型持续扩展，用户量也快速增加。这时候，用户反馈消息收不到、消息延迟等舆情问题越来越突出。这是因为消息推送走厂商通道，厂商通道实时性较差，对消息推送优先级设定有差异，导致用户能明显感觉到消息延迟。
现存技术的几大问题
目前的消息推送链路没有ack机制，服务端以为消息发出去了，可客户端实际没收到，用户下次打开app才能看到，这让用户感知到消息延迟。而且消息同步的推模式和拉模式，客户端没做隔离，异步处理导致在极端情况下消息数据库处理异常，引发消息丢失。另外，业务丰富孵化出多种业务，各类消息发送链路共用域环与数据存储，造成稳定性问题。
