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

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

核心内容

本文档介绍了TalkingData企业产品研发团队在面对高日活量APP带来的MySQL性能瓶颈时，所设计并实现的分布式缓存计算框架Blade。该框架旨在通过内存缓存技术，优化对bitmap索引的频繁更新操作，从而降低MySQL的binlog增长速度，提升系统性能与稳定性。

主要观点

• 背景：移动运营平台企业版支持从小规模到大规模企业客户，日活量可达数千万。
• 问题：随着日活量增加，MySQL的binlog增长过快，导致存储空间不足。
• 原因：使用MySQL存储bitmap索引，每次更新都需要从数据库中查询、修改、再写回，操作频繁且效率低下。
• 需求：解决方案需满足缓存备份、高性能、易于维护。
• 候选方案：包括替换MySQL为druid/rockdb、引入Redis缓存层、使用Apache Ignite。
• 选择原因：上述方案均存在运维复杂、资源消耗大或稳定性不足的问题，最终选择基于Ehcache、Redis和Zookeeper构建Blade框架。

关键信息

问题分析

1. bitmap索引技术：用于实时计算日活、留存等指标，具有高效和节省存储空间的优势。
2. MySQL存储限制：不支持bitmap类型，需以blob形式存储，频繁更新导致binlog增长。
3. 存储与性能瓶颈：大块bitmap对象频繁读写，消耗大量网络与磁盘IO，导致系统不稳定。

Blade框架优势

• 基于成熟组件：使用Ehcache、Redis和Zookeeper，易于维护。
• 减少DB更新频率：通过内存缓存，仅需告知Blade修改哪个bit，无需拉取整条数据。
• 实现缓存功能：支持Replication、Expired、Eviction等，保证系统稳定性。
• 高并发支持：避免Redis在处理大bitmap对象时的吞吐量瓶颈。
• 同步机制：定时同步缓存数据到MySQL，减少binlog压力。

Blade架构模块

• Blade Client：客户端，通过API调用Blade Cluster，使用一致性Hash算法均匀分布数据。
• Blade Cluster：集群，包含多个Blade Server，支持Replica Group机制。
• Blade Data Sync：数据同步模块，采用主备架构，异步处理同步请求。
• Blade Admin：管理与监控模块，提供对Blade Server、Replica Group和同步状态的监控与管理。

压力测试结果

• 资源配置：系统采用多物理机部署，资源分配合理。
• 性能对比：
  • MySQL binlog：实时写入方式导致binlog增长快，处理4.8TB数据需70小时。
  • Blade同步方式：每2小时同步一次，处理4.8TB数据仅需20小时。
  • 资源节省：在支撑2000万日活的情况下，为客户节省了近1/3的计算资源。

总结

Blade框架通过内存缓存与异步同步机制，有效解决了高日活量APP对MySQL性能的影响，实现了对bitmap索引的高效管理与实时计算。相比其他候选方案，Blade在维护成本、资源消耗与系统稳定性方面更具优势，能够满足企业客户对高并发、高性能和易维护的需求。