大型保险公司IM推送核心平台

项目介绍：构建企业级统一基础IM推送服务，支持多系统多渠道多媒体推送。基于公司自研产品为客户定制化开发IM推送核心平台，打通客服系统APP端/Web端/公众号端；重构内部沟通IM系统，实现手机端/PC端多端接入；开发业务系统异步消息推送平台，解耦各业务系统直连模式。

项目功能：包括接入SDK、接入服务、消息缓存、消息路由、群组管理等功能，实现TCP Socket/Web Socket/HTTP短连三种接入模式。

技术难点：

1. 高并发难点：高并发低延迟架构设计，系统支撑均值2万/峰值10万TPS消息处理能力，数据库支撑2万TPS写并发操作。
2. 高可靠难点：搭建不同可靠性消息发送链路，支持同城两机房灾备部署，全链路确保消息不漏发、不重发、不乱序。
3. 海量数据存储难点：单日300GB+数据库存储容量，6TB文件存储容量，总量54TB数据库存储容量，1.5PB文件存储容量。

项目职责：

1. 平台顶层架构设计：识别技术复杂度，选择Timeline模型等架构设计理论依据及架构设计方法，制定架构评审360度环评标准。
2. 故障分析隐患预案：制定FMEA列表，分析故障模式与影响范围，排除架构高可用隐患。
3. 通道化发送链路设计：结合Timeline模型实现高可靠消息发送通道设计，制定全链路性能优化方案，规划系统扩展技术方案。

方案设计：

一、高性能消息推送方案设计

1. 系统容量评估：评估系统数据容量/线路容量，量化IM接入服务并发访问均值/峰值以及不同时间段并发访问分布特征，评估DB/缓存/MQ中间件读写均值/峰值及存储占用，明确消息发送时延要求；线路容量2500Mb，日活用户310万；客服/单聊消息发送时延低于2s，5人以内群聊时延低于2s，5--100人群聊时延低于5s，100--10000群聊时延低于30s；系统交互消息时延30秒以内；通知服务消息时延60分钟；单实例CPU使用率低于80%。
2. 高性能接入服务设计：性能指标评估并制定性能优化策略。接入服务性能指标评估：单实例并发连接数15万，部署实例数8，单实例上行QPS均值2500/峰值1.25万，下行QPS均值1.25万/峰值6.25万，线路容量600Mb，机器配置8C16G/千兆网卡；结合Netty高性能进行多方面优化，对象池化技术降低40%内存占用；消息合并批量发送，提升发送吞吐量20%，降低带宽占用20%；局部无锁化串行设计，登录用户Session分为32个Bucket，每个Bucket由单独线程串行处理IO事件，降低遍历时间复杂度，减少锁争抢；Protobuf序列化压缩消息体积20%；线程池分配：boss线程1/work线程16/登录线程48/MQ生成端线程64/Bucket线程32；
3. 分库分表方案设计：指标评估与分库分表方案选型。评估各类消息存储指标：数据量/存储容量/读写并发数/读写延时；根据读写业务场景制定分库分表策略，按接收人userID/ChatID/发送时间多维度分库分表；根据存储指标计算分库分表数，总计分库31个，服务通知库数量2/表数量180，客服聊天库数量12/表数量900。制定超期数据备份/清理/表空间收缩流程；
4. 高性能缓存方案设计：进行缓存数据评估，制定数据压缩/性能提升方案。评估各类缓存数据指标：数据量/内存占用/读写并发数，缓存数据包括用户信息/登录Session/群组关系/离线消息（并发5万QPS/1亿数据量/2T容量占用）；多维度优化离线消息缓存，制定缓存淘汰策略，优化缓存字段数量及类型，确保使用ziplist存储结构以减少内存占用，使用ProtoStuff压缩缓存对象，使用lua脚本批量执行操作减少网络访问，压缩离线消息缓存容量到70G以内；总计14个Redis集群：用户信息集群1个、登录Session集群2个、群组关系集群3个、离线消息集群8个。
5. 高性能MQ方案设计：指标评估/集群划分，生产端模型和消费模型制定。评估各业务场景下Kafka生产端消息写入并发均值/峰值、各业务消费组消费速率，写入数据包括通知服务消息/客服消息/聊天消息（生产端均值5000QPS峰值2.5万QPS/消费端2.5万QPS）/系统交互消息；生产端根据消息写入可用性一致性要求选择同步写入或异步写入；按照消息类型划分为8个topic，根据吞吐量将每个topic分为16--64个partition；消费端线程分为消费线程池与业务线程池，消费线程负责拉取消息与手动ack消息处理结果，业务线程池负责业务逻辑执行，根据消息处理耗时与消费端吞吐量设置业务处理线程数。
6. 全栈性能调优方案设计：制定开发/压测/上线后三阶段性能调优策略与性能指标，评审微基准/宏基准性能测试方法。调优内容包括Java编程调优（字符串使用/容器对象选型）、多线程调优（锁优化/并发容器选型/减少运行时上下文切换）、JVM调优（JIT即时编译/GC调优/JVM内存分配）、设计模式调优（单例模式/原型模式/享元模式）、数据库调优（SQL调优/事务优化/索引优化/参数优化）。自下而上分析问题/自上而下逐级优化，调优成果：系统吞吐量提升25%，资源使用率降低20%，数据库吞吐量提升15%

二、高可靠消息推送方案设计

1. 系统可用性规划：结合CAP理论/BASE理论梳理数据软状态与最终一致性策略，梳理各类消息一致性要求，以及功能可用性分级。软状态流程：消息发送流程/消息存储流程采用不同消费分组不同消费速率异步执行，不保证数据实时一致性，30秒内保证最终一致性。消息一致性：系统交互消息强一致性要求，确保不丢/不乱序，可损失部分可用性；客服/聊天消息中等一致性要求，确保消息不丢，乱序/重复率低于1‰；功能可用性分级：系统交互模块99.9%可用性要求，强一致性要求，消息延迟60秒以内；客服聊天模块99.99%可用性要求，单聊延迟2秒以内，群聊延迟30秒以内。
2. 串行化通道设计：实现从发送端SDK/接入服务/Kafka集群/转发服务/接收端SDK全流程串行通道，同一接收人消息分配到同一通道串行处理，确保消息顺序性，通道间并行执行。发送端SDK生成消息递增ID/消息发送确认机制/消息自动重发机制确保消息不漏发不乱序；接入服务消息流入IO阶段由Netty确保Channel内消息顺序执行，业务线程采用OrderedMemoryAwareThreadPoolExecutor实现，确保同一Channel内消息顺序执行；Kafka生产端通过接收人userID与partition数量取模，确保同一接收人消息写入同一partition；消费端自定义顺序线程池实现同一接收人消息顺序消费，通过路由策略（接收人userID/partition分区数%线程数=线程编号）将同一接收人消息分配给同一线程处理；接入服务消息流出阶段为每个接收人使用顺序队列缓存待发送消息，通过Bucket独立线程顺序发送消息；接收端SDK消息自动排序/自动去重/接收确认/定时拉取离线消息等兜底方案，确保消息不遗漏不乱序不重复。
3. 高可靠接入服务设计：接入服务高可用策略包括接入服务负载均衡策略/链路可用性设计/入站出站流量控制/内存保护策略。采用SDK端负载均衡策略，http方式拉取接入服务实例信息，选择负载系数较低实例建立Socket连接。链路可用性设计包括客户端心跳检测和服务端空闲检测，客户端N秒内未收到数据包发送心跳检测包；服务端采用IdleStateHandler检测链路空闲状态，空闲N秒后自动断开连接或主动发送心跳检测包。流量控制包括流量整形与出站高低水位设置，流量整形分为全局流量/链路流量控制，聊天接入服务全局流量整形阈值入站15MB/出站75MB，链路流量整形阈值入站10KB/出站50KB；发送队列高水位阈值64KB/低水位阈值32KB。内存保护采用对象池化技术减少频繁申请/释放内存，减少内存碎片；超长消息分段传输，限制消息体长度512B，避免接收端内存溢出；合理配置JVM内存占用，堆内存（-Xms 和-Xmx：11G）、堆外内存（-XX:MaxDirectMemorySize：1G）、年轻代/老年代比例（-XX:NewRatio=3）。
4. 同城异区两机房灾备部署方案：双机房高可用原则：与客户相关功能/重点用户相关功能实现双机房高可用部署；只保证重点用户离线消息实现双机房缓存；数据库不做双机房高可用部署。业务分级/用户分级：系统交互/服务通知推送功能不做跨机房连接；客服系统实现跨机房登录；聊天系统重点用户实现跨机房登录和离线消息跨机房缓存，普通用户不做跨机房登录，用户按所属机构分配登录机房。双机房数据同步策略：离线消息缓存通过MQ实现双机房同步，确保最终一致性，最终一致性前存在消息不一致风险；跨机房消息路由策略：根据消息接收人所属机构判断用户是否连接本机房，若需跨机房则将消息写入跨机房MQ。
5. MQ高可用方案设计：制定MQ生产端/MQ集群/消费端高可用策略，生产端配置至少2副本写入成功后返回写入成功，业务场景不同选择同步/异步发送模式，制定不同场景下写入失败策略；每个partition采用1主2从3副本，确保消息可靠存储；消费端采用手动ack机制，按顺序提交消息ack，避免消息丢失乱序；制定消费失败和partition主从切换导致消息重复解决策略。
6. 业务降级/隔离方案：根据业务分级以及各业务可用性要求制定业务隔离方案以及降级策略。业务分级：优先确保客服/聊天业务正常。自动降级场景：接收人消息推送队列满或到达发送队列高水位阈值，自动停止推送服务通知。业务隔离：按不同CAP要求/消息不同处理速率/消息不同处理流程进行集群隔离，按消息扩散规模进行线程池隔离。

三、高扩展架构设计

1. 高扩展架构拆分：架构扩展目标：应对逐年业务递增和活动期间流量上涨。架构扩展方式：面相流程拆分/面向服务拆分/面向功能拆分，面向流程拆分将系统形成分层架构：SDK层/接入层/MQ层/消息处理层/消息缓存层/消息存储层，各层独立扩展，减少相邻层耦合。面向服务拆分形成接入服务/离线消息服务/路由服务/消息存储服务等，各服务集群部署，独立扩展。
2. 集群部署规划：系统2机房高可用部署，内外网各部署一个集群，总计4个集群，部署服务实例数98个：接入服务8/离线消息服务12/消息存储服务20/离线消息查询服务30/消息出站路由服务16/ID生成8/管理服务4；中间件集群包括：Kafka集群4/Redis集群14/MySQL集群31