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

文档总结

核心内容

本文档介绍了TalkingData团队为解决移动运营平台企业版中bitmap索引频繁更新导致MySQL binlog存储空间不足的问题，所设计并实现的分布式缓存计算框架Blade。该框架旨在通过内存缓存和分布式同步机制，提升系统性能并降低运维成本。

主要观点

• 问题背景：随着企业客户APP日活量的增加，MySQL binlog增长迅速，导致存储空间不足。同时，大块数据的频繁读写也增加了网络IO和磁盘IO的负担。
• 解决方案需求：需要一个能够支持缓存备份、高性能和易于维护的框架，以应对大活跃客户的需求。
• 候选方案分析：
  • Druid/RockDB：虽然性能优越，但运维复杂度高，且需要大量服务器资源，不适合企业产品研发。
  • 纯Redis缓存：在高并发下吞吐量不足，且无法处理缓存过期或驱逐时的数据同步问题。
  • Apache Ignite：虽然具备缓存功能，但频繁更新大块数据容易导致OOM问题，系统不稳定。
• 最终方案：基于Ehcache、Redis和Zookeeper构建Blade框架，有效解决上述问题。

关键信息

Blade框架简介

• 功能：Blade是一个用于bitmap索引计算的加速框架，旨在减少频繁更新MySQL中bitmap索引的频率。
• 架构：
  • Blade Client：客户端，应用程序通过API调用Blade Cluster，支持一致性Hash算法，实现Key的均匀分布。
  • Blade Cluster：集群，包含多个Blade Server，每个Server运行Jetty和Redis。
  • Replica Group：复制组，用于防止单节点宕机导致的数据丢失，确保缓存一致性。
  • Blade Data Sync：数据同步模块，采用主备架构，定时将缓存中的bitmap索引同步到MySQL。
  • Blade Admin：管理监控模块，用于监控和管理整个Blade Cluster的运行状态。

数据同步机制

• 同步策略：Data Sync模块通过Dispatcher Thread遍历所有Key，并根据Key做Hash分配同步任务给Sync Thread Group。
• 性能优化：每个Sync Thread都有一个Queue，异步处理请求，提升同步效率。

压力测试结果

• 测试场景：模拟2000万日活用户，每个用户产生20条日志，总计约4.8TB数据。
• 资源配置：
  • Collector/report/queryengine/um/makedata：40c/128g/4.4T
  • Kafka/Zookeeper：40c/128g/4.4T
  • Storm节点：40c/128g/4.4T
  • Blade Server：40c/128g/4.4T
  • MySQL：40c/128g/4.4T
• 测试结果：
  • MySQL binlog：使用传统架构处理4.8TB数据需要70小时，而Blade框架处理同样数据仅需20小时。
  • 资源节省：在支撑2000万日活的情形下，Blade为客户节省了近1/3的计算资源。
  • 性能对比：Blade在同样机器资源下，完全能够支撑2000万日活，而之前的架构无法做到。

总结

Blade框架通过将bitmap索引缓存在内存中，并结合Redis和Zookeeper实现高效的数据同步和缓存管理，有效解决了传统MySQL架构下因频繁更新导致的存储瓶颈和性能问题。其设计兼顾了稳定性、可维护性和高并发处理能力，成为TalkingData团队在企业产品研发中的优选方案。