【T112017-数据工程和技术分会场】基于内存的分布式计算实践_27页_2mb

基于内存的分布式计算总结

核心内容

本文档主要介绍TalkingData企业产品研发团队在面对高日活APP带来的MySQL binlog存储瓶颈问题时，所设计并实现的分布式缓存计算框架Blade。该框架旨在通过内存缓存优化bitmap索引的更新操作，从而解决高并发下频繁更新导致的存储和性能问题。

主要观点

• 问题背景：随着APP日活量的增加，MySQL的binlog增长迅速，导致存储空间不足，影响系统稳定性。
• 传统方案局限性：
  • 使用MySQL存储bitmap索引，但由于MySQL不支持bitmap类型，需使用blob类型存储，频繁更新导致binlog数据量激增。
  • 替换为Druid、RockDB等大数据组件或纯Redis缓存方案，存在运维复杂、资源消耗大、稳定性差等问题。
• 解决方案：基于Ehcache、Redis和Zookeeper构建分布式缓存计算框架Blade，专门优化bitmap索引的更新与同步流程。

关键信息

问题分析

• 日活量：企业客户APP日活从500万增长到2000万，导致MySQL存储压力剧增。
• bitmap索引特点：
  • 每个bitmap对象的大小从数百KB到数MB不等。
  • 高频更新操作导致binlog存储爆炸。
• 性能瓶颈：
  • 高并发下Redis无法高效处理大体量bitmap索引。
  • Apache Ignite方案因数据复制导致OOM问题。

Blade框架优势

• 性能提升：在相同资源下，Blade能够支撑2000万日活，而原有架构无法做到。
• 资源节省：在支撑2000万日活的情况下，为客户节省了近1/3的计算资源。
• 稳定性增强：基于成熟组件实现，具备缓存复制、过期、驱逐等机制，避免数据丢失和系统不稳定。
• 运维友好：相比Druid、RockDB等方案，Blade无需复杂运维，降低了客户运维成本。

Blade框架结构

• 主要模块：
  • Blade Client：客户端Jar，提供API接口，与Blade Cluster通信。
  • Blade Cluster：集群架构，包含多个Blade Server，支持Replica Group复制。
  • Blade Data Sync：数据同步模块，定时将缓存数据同步到MySQL，采用主备架构。
  • Blade Admin：监控和管理模块，提供集群状态监控和同步管理功能。
• 技术实现：
  • 使用一致性Hash算法将Key均匀分布到集群中。
  • Redis仅作为大缓存使用，不启用其分片、集群等特性。
  • Data Sync模块采用Dispatcher Thread和Sync Thread Group异步处理同步任务。

压力测试结果

• 数据量：模拟2000万日活用户，生成4.8TB数据。
• MySQL性能对比：
  • 实时写入MySQL binlog：需要约70小时，无法支撑2000万日活。
  • Blade同步MySQL：仅需约20小时，能够支撑2000万日活。
• binlog对比：
  • Blade方案下，binlog数据量仅为实时写入方式的近40倍。
• 资源节省：
  • 在相同条件下，Blade方案为客户节省了近1/3的计算资源。

总结

Blade是一个基于Ehcache、Redis和Zookeeper的分布式缓存计算框架，专门用于优化bitmap索引的更新与同步。它通过内存缓存减少对MySQL的频繁写入，显著降低binlog存储压力，提高系统性能与稳定性。相比其他候选方案，Blade在运维复杂度、资源消耗和系统稳定性方面更具优势，是解决高日活APP数据处理瓶颈的理想选择。