ITPub博客

经历野蛮发展阶段后，58到家存在众多消息收发场景及不同技术。案例分享总结多个业务场景下消息收发的难点与挑战，梳理各项技术的特点，结合实际业务及研发需求，构建了一套通用消息投递方案。方案建立统一的端到端、端到服务器、服务器到端的消息通道，对业务方屏蔽不同技术的差异，提供消息到达率等核心指标的监控统计。实现业务线能够快速接入各类消息服务的目标。

公司要做一个IM系统，现阶段人力资源很有限，产品、研发、测试目前就我一个人。跟领导沟通后决定先采用开源原件tigase先解决有无问题，后续人员到位后进行重构。本文主要介绍生产环境下tigase的安装问题（此次安装是在测试机器中进行，但是周边环境近似生产环境）。

随着业务的发展，多个业务线接入了IM系统，IM系统长连接的安全问题变得很重要。瓜子有统一登录认证系统SSO，IM长连接通道也利用这个系统做安全认证，结构如下图。

我们当前的IM虽然进行了微服务化，但是核心的消息投递模式仍然采用下图描绘的方式，参看《一个海量在线用户即时通讯系统（IM）的完整设计》。

通过《基于TimeLine模型的消息同步机制》一文，我们了解到Timeline模型有非常多的优点，也是钉钉采用的消息同步机制。实际工作中，我们也将该模型应用在了C端用户的消息场景中。实施过程中也遇到了一些问题，积累了一些经验。本文将介绍极端情况丢失消息的问题及解决办法。

项目中采用Redis SortedSet存储用户的离线消息，score值存储的msgid（消息ID）。msgid采用snowflake算法生成，按照时间有序。（参看《一个海量在线用户即时通讯系统（IM）的完整设计》）

瓜子业务重线下，用户网上看车、预约到店、成交等许多环节都发生在线下。瓜子智能在线客服系统的目的是要把这些线下的活动搬到线上，对线下行为进行追溯，积累相关数据。系统连接用户、客服、电销、销售、AI机器人、业务后台等多个角色及应用，覆盖网上咨询、浏览、预约看车、到店体验、后服、投诉等众多环节，各个角色间通过可直接操作的卡片传递业务。

项目中一直有计算DAU这类的需求，业务开发者往往埋个点，其他是事情就交给数据团队了。如果自己要做一个这样的计数器怎么做呢？一个朴素的想法是通过hashmap实现，时间复杂度是O(1)。这个方法在计数对象较少的情况下还是不错的，但是如果计数对象很多（比如计算独立访问IP），意味着hashmap的key非常多，内存消耗是非常大。

正如我在前面章节强调的，HBase数据模型跟关系型数据库系统有非常大的差异。因此，设计Hbase的数据表的方法和思路跟关系型数据库不一样。设计HBASE表应该在具体业务场景的上下文中回答以下问题

有关系行数据库经验的人（比如我），在最初接触HBase这样的数据库时，对数据结构的理解容易遇到障碍。会不自觉的将HBase的行、列等概念映射成关系型数据库的行、列。为了加速理解HBase的一些概念，翻译了这篇文章《Understanding HBase and BigTable》（HBase官方文档推荐阅读文章）。