基于内存的分布式计算实践.pptx

背景简介 我们团队专注于移动运营 平台企业版，客户的APP日活 小的有不到10万，大的可以达 到数千万。 我们致力于让移动运营平 台企业版能够弹性地支持小、 中、大型企业客户，系统稳定 且易于维护。 V2.0 V1.0 V3.0 V3.1 V4.0 2013 2014 2015 2016 2017 移动运营平台企业版 产品进化图 问题 我们团队负责 移动运营平台企业 版V3.0 及后续版本 迭代， 当时的设计 目标支撑500w日活 ， 数据库使用MySQL 。 有一天，我们的一个客 户，他们上线了几个日活量 较大的APP，系统的整体日活 达到了2000万，运维人员反 映MySQL的binlog增长很快， 快把剩余磁盘空间占满了。 事实证明移动运 营平台企业版V3.0 能 够满足绝大多数企业 客户的需求， 能够稳 定地支撑他们的业务。 500 W 500 W 2000 W 企业客户APP日活设计目标 问题分析 1 我们使用了bitmap索引 技术保证移动运营各项指标 （如日活、留存、转化漏斗 等） 的 实时 计算， 因为 bitmap索引高效且能节省存 储空间，它能很方便地做指 标的实时排重。 第1位 设备1 第2位 设备2 第3位 设备3 … 第N-1位 设备N-1 第N位 设备N 0 0 0 0 0 0 1 设备1 2 设备2 3 设备3 … N-1 设备N-1 N 设备N 0 0 1 0 1 0 bitmap bitmap 当天8：10，设备3和设备N-1访问了APP 1 设备1 2 设备2 3 设备3 … N-1 设备N-1 N 设备N 0 1 1 0 1 0 bitmap 当天9：20，设备2和设备N-1访问了APP 某APP某天0：0的初始活跃状态 问题分析 2 我们使用MySQL 存储bitmap 索引， 因 为MySQL稳定且易于 运维。 我们将bitmap 对象作 为blob类型存入MySQL，对 bitmap 索引的某一位更新 时需要先从DB查询出来， 更新之后再update 到DB 中。 更新后 Bitmap 1~3MB MySQL APP数据处理 程序 但是， MySQL本身 在 业 务 上 是 不 支 持 bitmap类型的数据，不 能够发送指令给MySQL 让它把bitmap的某一位 设置为1或0。 更新前 Bitmap 1~3MB 1.查询某个维度的bitmap， 比如说今天的活跃用户。 2.设置某一位为 1 3.更新到DB（网络IO） 网络IO 磁盘 4.写binlog（磁盘IO） 问题分析 3 每个bitmap对 象的大小从数百 KB到数MB不等。 数据分析： 100w存量用户，随机60w日活，每个bitmap原始大小 130KB，压缩后126KB 2000w存量用户，随机200w日活，每个bitmap原始大小 2.6MB，压缩后1.5MB 1亿存量用户，随机500w日活，每个bitmap原始大小 11.5MB，压缩后5.2MB 频繁地更新blob二进制数据，导致binlog数据量极大，从而导致存储空间不够用。 这就是前面某客户出现瓶颈的原因所在。 问题域 大块（1M~10M）的二进制 对象（约30w个bitmap对象）频 繁读写，导致网络IO、磁盘IO等 资源耗费巨大，MySQL binlog增 长过快导致存储空间不够与浪费。 我们需要考虑如何在分布 式内存中计算以解决此类问题， 解决方案需要满足： 第一个，缓存备份 第二个，性能高 第三个，易于维护 候选解决方案 方案一： 替换MySQL ， 使用 druid/rockdb等大数据组件 方案二：在MySQL前面引入redis缓 存层，定时同步到MySQL 方案三：调研使用Apache Ignite组件 为什么不选用Druid/RockDB方案 我们在互联网研发线使用了此种方案，但调研下来不适合企业侧产品研发： 原来我们的系统运维工作很少，整个2000万日活体量的系统，也只需要1个运维人 员；而换了Druid/rockdb，需要有较多的运维工作，等于放弃了我们原有的优势， 增加了对客户运维人员的要求。 Druid/RockDB 需要大量的服务器资源。 为什么不选用纯Redis缓存方案 Redis在高并发下不能支撑对较大bitmap索引的频繁更新，单个bitmap索引平均能 够达到2、3MB，而Redis的value达到1MB时吞吐量不到1000每秒，远远达不到要 求的吞吐量。 另外一个重要的原因是Redis的事件机制有问题，expired和eviction事件拿不到缓 存对象的值，这样会导致一旦缓存对象过期或被驱逐，我们无法把缓存对象更新 到数据库。 对大块bitmap索引的频繁更新，导致存储空间耗用巨大，而且大块数据的复制