背景简介
我们团队专注于移动运营
平台企业版，客户的APP日活
小的有不到10万，大的可以达
到数千万
我们致力于让移动运营平
台企业版能够弹性地支持小、
中、大型企业客户，系统稳定
且易于维护
V1.0
V2.0
V3.0V3.1
V4.0
20132014201520162017
移动运营平台企业版
产品进化图
问题
我们团队负责
移动运营平台企业
版V3.0及后续版本
迭代，当时的设计
目标支撑500w日活，
数据库使用MySQL
有一天，我们的一个客
户，他们上线了几个日活量
较大的APP，系统的整体日活
达到了2000万，运维人员反
映MySQL的binlog增长很快，
快把剩余磁盘空间占满了
事实证明移动运
营平台企业版V3.0能
够满足绝大多数企业
客户的需求，能够稳
定地支撑他们的业务
500 W500 W
2000 W
企业客户APP日活设计目标
问题分析1
我们使用了bitmap索引
技术保证移动运营各项指标
（如日活、留存、转化漏斗
等）的实时计算，因为
bitmap索引高效且能节省存
储空间，它能很方便地做指
标的实时排重
第1位
设备1
第2位
设备2
第3位
设备3
…第N-1位
设备N-1
第N位
设备N
000000设备1设备2设备3
…N-1
设备N-1
N
设备N
001010
bitmap
bitmap
当天8：10，设备3和设备N-1访问了APP设备1设备2设备3
…N-1
设备N-1
N
设备N
011010
bitmap
当天9：20，设备2和设备N-1访问了APP
某APP某天0：0的初始活跃状态
问题分析2
我们使用MySQL
存储bitmap索引，因
为MySQL稳定且易于
运维
但是，MySQL本身
在业务上是不支持
bitmap类型的数据，不
能够发送指令给MySQL
让它把bitmap的某一位
设置为1或0
我们将bitmap对象作
为blob类型存入MySQL，对
bitmap索引的某一位更新
时需要先从DB查询出来，
更新之后再update到DB中
更新后
Bitmap
1~3MB
MySQL
APP数据处理
程序
更新前
Bitmap
1~3MB
1.查询某个维度的bitmap，
比如说今天的活跃用户
2.设置某一位为13.更新到DB（网络IO）
网络IO
磁盘
4.写binlog（磁盘IO）。