这是TalkingData团队在今年2017上海qcon上的一个具体问题的解决方案分享。截图来自ppt。
问题背景
Talking data的主要业务角色是第三方移动数据服务平台。一个基础的业务场景就是统计客户app的dau，他们使用bitmap索引技术来保证客户app移动运行各项指标的实时计算。
对于使用bitmap统计dau的解释如下：
屏幕快照 2017-11-12 下午10.36.15.png
对于bitmap的存储使用Mysql,每个bitmap对象大小从数百KB到数百MB不等。但当有大块数据对象出现时，约30w个bitmap对象频繁读写，会导致网络IO，磁盘IO等资源耗费巨大，Mysql的binlog增长过快，导致存储空间不足。
Blade方案
屏幕快照 2017-11-12 下午10.42.06.png
介绍:
Client 是一个Jar，应用程序通过jar的api发起对Blade的调用。并通过Hash算法，将可以尽可能分布在Blade的所有ReplicaGroup上。
一个Blade Server 包含一个Jetty和一个Redis，对bitmap做处理。ReplicaGroup的作用主要是防止单节点Blade Server宕机后，丢失缓存对象，同一个group的Balde server的缓存对象会保持一致。
最后，Data Sync复制将Blade server中缓存的bitmap索引对象定时同步到mysql中，做持久化。
主要思想就是数据更新操作都在Blade内存中进行，定时同步，解决频繁更新bitmap导致大量mysql的binlog问题。
一些细节
Balde Admin，主要用来监控每个Blade Server，Replica Group和 Data Sync的同步情况，也能监控每个Replca Group主从节点间的同步。
一些思考
Blade 主要是基于缓存的，没有持久化，如果主从节点的Blade Server都挂了，是不是就会丢失还未同步的数据了？如果不使用缓存的方式，而是使用一些现有的开源消息中间件，接收客户端的更新消息，再定时从消息队列中读取更新消息完成DB更新，是不是也可以解决频繁访问mysql的问题？
网友评论