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

文档总结：基于内存的分布式计算框架 Blade

核心内容

本文档介绍了 TalkingData 企业产品研发团队在面对移动运营平台企业版日活量增长时，所遇到的数据库性能瓶颈问题及其解决方案。团队在原有 MySQL 架构下，由于 bitmap 索引频繁更新导致 MySQL binlog 增长过快，最终影响了存储空间和系统稳定性。为解决这一问题，团队调研并否定了几种候选方案，最终决定基于 Ehcache、Redis 和 Zookeeper 构建一套名为 Blade 的分布式缓存计算框架。

主要观点

• 问题背景：随着企业客户日活量的增长，MySQL 的 binlog 存储空间迅速耗尽，影响系统稳定性。
• 解决方案：Blade 是一个专注于 bitmap 索引计算的分布式缓存加速框架，旨在减少对 MySQL 的频繁更新操作。
• 优势：Blade 采用成熟的组件（Ehcache、Redis、Zookeeper），系统稳定、易于维护，并能有效处理高并发场景。
• 架构设计：Blade 通过分布式缓存、复制组机制和异步数据同步，实现高效、可靠的数据管理。

关键信息

问题分析

1. bitmap 索引使用：用于实时计算日活、留存、转化漏斗等指标，但其更新操作频繁。
2. MySQL 存储限制：虽然 MySQL 稳定且易于运维，但不支持 bitmap 类型，导致频繁更新 blob 数据，binlog 增长迅速。
3. 存储与性能瓶颈：对于大体量用户，bitmap 索引的存储和更新操作导致资源消耗巨大，影响系统稳定性。

候选方案分析

• Druid/RockDB：需要大量服务器资源，运维复杂，不符合企业产品简化运维的需求。
• 纯 Redis 缓存：无法处理大块 bitmap 索引，存在高并发下吞吐量不足、缓存失效后无法同步等问题。
• Apache Ignite：虽然具备数据备份功能，但频繁更新大 bitmap 导致 OOM 问题，系统不稳定。

Blade 框架设计

• 架构模块：

  • Blade Client：客户端 Jar，使用 API 调用 Blade Cluster，通过 Zookeeper 获取集群状态。
  • Blade Cluster：包含多个 Blade Server，采用一致性 Hash 算法进行负载均衡。
  • Replica Group：用于复制组内的数据一致性，防止单点故障。
  • Blade Data Sync：负责定时将缓存数据同步到 MySQL，采用主备架构提高可靠性。
  • Blade Admin：用于监控和管理整个集群，提供同步启动和状态监控功能。

• 主要功能：

  • 提供分布式内存缓存，支持 Replication、Expired、Eviction 等功能。
  • 提供 UI 监控和管理，便于运维。
  • 支持异步处理和高并发场景，提升系统性能。

压力测试结果

• 测试场景：模拟 2000w 日活用户，每用户产生 20 条日志，总计 4.8TB 数据。
• 资源配置：
  • Collector/report/queryengine/um/makedata：物理机 40c/128g/4.4T。
  • Kafka1~4/Zookeeper1~3：物理机 40c/128g/4.4T。
  • Storm1~10：物理机 40c/128g/4.4T。
  • BladeServer1~6：物理机 40c/128g/4.4T。
  • MySQL：物理机 40c/128g/4.4T。
• 测试结果：
  • Blade 能够在相同资源下支撑 2000w 日活，而原架构无法实现。
  • Blade 的同步方式比实时写入 MySQL 的 binlog 高效近 40 倍。
  • 为客户节省了近 1/3 的计算资源。

结论

Blade 框架通过引入分布式内存缓存机制，有效解决了 bitmap 索引频繁更新导致的 MySQL 性能瓶颈问题，具备高并发、稳定、易于维护等优势，是企业级产品在面对大数据量时的理想解决方案。