系统简介
- 投放系统是为点评app，点评m站，微信m站，点评pc，美团app，美团i站 等 提供的一个活动入口管理的平台
- 内容支持多时段，分城市，新老用户，分类目，版本，渠道等多种分发条件
- 本系统已累计接入包含点评app首页rb，新用户专区，为你优选等400+个入口区域
- 目前系统高峰qps超过1w，日调用超过3亿+ 次
问题背景
- 投放系统的service端数据设置了5分钟的缓存，因此在新数据投放/内容暂停/内容过期 等都存在一定的延时
- 数据按城市展开存入redis中，形成大量冗余数据占用缓存资源
- 缓存集群在高并发时产生一定的延时，降低系统性能
系统数据流图
data-flow.png
优化前系统指标截图
优化前性能截图.png
数据流程简介
- 在新增投放，内容暂停 操作时，数据首先写入mysql, 之后触发对redisA中数据的增量更新
- 为防止redisA中数据增量同步失败，增加一个task定时对redisA中的数据做全量更新，redisA中的数据永不过期
- redisB通过运营位名称及城市id做了缓存索引，每5分钟过期，过期后从redisA重新加载
优化过程
- 经过统计每天存储在redisA中的数据约50MB, 因此决定将redisB替换为内存缓存
- 替换为内存缓存后面对数据同步与热启动的问题
- 针对内存缓存的热启动，提前将使用到的运营位存储到redis中，服务启动时依照redis中存储的运营位将数据缓存到内存中
- 针对数据同步，采用定时任务，每5s进行一次redis与内存缓存数据的同步，为避免相同数据的重复更新，采用对数据设置版本号的方式，当版本号相同时则不更新。
数据结构选取
- 内存缓存使用ConcurrentHashMap ，初始大小设置为 512
- 针对分城市投放的问题，对城市列表的数据结构做了重新设计(平衡查找的时间与空间复杂度)，采用将一组整数转化成 一组区间，然后在区间中二分查找，详细设计见 LocalRange.java
新版数据流图
inner-memory.png
优化后系统指标截图
优化后性能截图.png
性能对比
优化前性能截图.png
优化后性能截图.png
系统依然存在的问题与可选解决方案
- 系统依然存在最多5s的延时，可引入MQ来做数据更新的实时通知
- 数据中心化存储与分发，当中心服务出现问题后，所有的下游都会受到影响，可采用发布sdk的方式，将数据缓存到调用方的机器上，采取数据版本的方式做数据更新。
总结
- 针对此类配置管理系统，数据更新并不是特别频繁，且数据量不大的情况下适当做内存缓存，来提升系统性能
网友评论