百分点内存数据库架构演变-武毅

火龙果整理uml.org.cn百分点内存数据库架构演变武毅火龙果整理uml.org.cn火龙果整理uml.org.cn摘要•内存计算的趋势•百分点推荐引擎BRE的内存计算•百分点内存数据库演变火龙果整理uml.org.cn火龙果整理uml.org.cn内存计算的趋势•数据展现上，时间就是金钱•面临着处理海量的数据•磁盘IO成为并行计算的瓶颈•针对不同行业，应对各种业务需求，需要从不同的维度去处理，分析数据•对内存数据库的需求火龙果整理uml.org.cn火龙果整理uml.org.cn互联网公司数据金字塔CacheAppDataFullColdData火龙果整理uml.org.cn火龙果整理uml.org.cn摘要•内存计算的趋势•百分点推荐引擎BRE与内存计算•百分点内存数据库演变火龙果整理uml.org.cn火龙果整理uml.org.cnRecommendationAnalytics场景引擎流处理平台规则引擎批处理平台InfrastructureBRE原理展示引擎算法引擎火龙果整理uml.org.cn火龙果整理uml.org.cnBRE实时计算：lambda架构示意内存数据库规则引擎数据探头实时用户行为实时用户偏好实时推荐算法在线分类器实时搜索引擎消息队列hadoop火龙果整理uml.org.cn火龙果整理uml.org.cnBRE基于内存数据库的实时计算实时用户偏好用户购物状态用户购物目标用户购物周期实时推荐算法大规模矩阵计算大规模图计算统计类算法在线分类器商品自动分类舆情评估实时规则引擎最优化算法推荐结果混合推荐结果排序A/BTest实时搜索引擎商品索引资讯索引流计算带有时间窗口的存储和计算推荐效果统计分析监控信息分析火龙果整理uml.org.cn火龙果整理uml.org.cn内存数据库是BRE的主存•数据实时更新–用户行为、用户偏好、商品资讯信息、推荐算法结果、集群监控数据…•海量数据–十几种类别、十亿量级条目数、TB量级存储量•高并发、高吞吐量–每秒十万量级读写次数、GB量级数据量•高可靠和高可用–数据固化、容灾、备份火龙果整理uml.org.cn火龙果整理uml.org.cn摘要•内存计算的趋势•百分点推荐引擎BRE与内存计算•百分点内存数据库演变火龙果整理uml.org.cn火龙果整理uml.org.cn百分点内存数据库演变Redis+Route-TableRedis+MongoDB+ZookeeperBRE0.xMemcached+Mysql+ZookeeperBRE1.xMemcached+Redis+ZookeeperBDM、BRE2.x火龙果整理uml.org.cn火龙果整理uml.org.cnBRE0.x的内存数据库：需求•2010.1-2012.3•数据量–100G•并发和吞吐量–1万RW/秒，2M/秒•承载的应用数目不多火龙果整理uml.org.cn火龙果整理uml.org.cnMonitorBRE0.x的内存数据库：架构ClientRoutingTableRedisMasterKeepalivedRedisSlaveRedisMasterKeepalivedRedisSlaveRedisMasterKeepalivedRedisSlave火龙果整理uml.org.cn火龙果整理uml.org.cnBRE0.x的内存数据库：说明•分布式–数据按客户分组–每个数据分组由唯一的Redis实例存储–用路由表记录分组和Redis实例的对应关系•高可用–Redis主从+Keepalived–通过info和dbsize命令监控Redis状态•数据固化•主无持丽化，从定期持丽化火龙果整理uml.org.cn火龙果整理uml.org.cnBRE0.x的内存数据库：局限•需要手工维护路由表–容易导致负载不均衡–人工成本高–扩展性较差火龙果整理uml.org.cn火龙果整理uml.org.cnBRE1.x的内存数据库：需求•2011.7–今•数据量–～700G•并发和吞吐量–～200万RW/秒，～400M/秒•承载很多应用–应用间数据需要隔离•良好的负载均衡和水平扩展性火龙果整理uml.org.cn火龙果整理uml.org.cnZookeeperMonitorBRE1.x的内存数据库：架构IClientReaderNamespace1MemcachedMySQLMemcachedBackupMemcachedMySQLNamespace1MemcachedMySQLMemcachedBackupMemcachedMySQLClientWriter火龙果整理uml.org.cn火龙果整理uml.org.cnZookeeperMonitorBRE1.x的内存数据库：架构IIClientReaderNamespace1Namespace1MemcachedRedisMemcachedRedisMemcachedRedisMemcachedRedisClientWriter火龙果整理uml.org.cn火龙果整理uml.org.cnBRE1.x的内存数据库：说明•••分布式–集群分为多个Namespace，物理上隔离–同一Namespace内使用一致性Hash（Ketama）及虚结点机制均匀分布数据–写入的数据通过key值做逻辑隔离高可用–利用组件内建工具（Memcachedstats、Redisinfo）实时监控集群信息–利用Zookeeper实时更新集群状态，并通知客户端–自动故障迁移，一开始采用备份机，后期采用Redis数据固化–写入数据时异步固化–MySQL固化速度慢，最终采用Redis火龙果整理uml.org.cn火龙果整理uml.org.cnBRE1.x的内存数据库：数据重分布•虚拟结点导致物理机器数目改变时数据必须重新分布每台物理机器上有多个虚结点虚结点无法有效区分火龙果整理uml.org.cn火龙果整理uml.org.cnBRE1.x的内存数据库：局限•Memcached不能作为数据库–无法固化数据–无法枚丼数据–无法很好的控制数据过期•读写分离导致系统复杂•简单的KV不能满足需求–大Value导致网卡瓶颈–数据序列化/反序列化消耗系统资源•扩容不易–虚结点的使用导致需要重新计算所有数据分布火龙果整理uml.org.cn火龙果整理uml.org.cnBDM的内存数据库：需求•2013.7–今•更多的应用–BRE的底层架构演变为百分点大数据平台（BDM）–BRE（2.x）成为BDM上的一个应用•数据量–～1.5T•并发和吞吐量–～500万RW/秒，～1G/秒•更多的数据结构支持•更简便的的扩容火龙果整理uml.org.cn火龙果整理uml.org.cnZookeeperMonitorBDM的内存数据库：架构ClientNamespace1Redis/MongoDBMasterRedis/MongoDBSlaveRedis/MongoDBMasterRedis/MongoDBSlaveNamespace2Redis/MongoDBMasterRedis/MongoDBSlaveRedis/MongoDBMasterRedis/MongoDBSlave火龙果整理uml.org.cn火龙果整理uml.org.cnBDM的内存数据库：说明•多种数据结构–Redis：KV、List、HashMap、Set…–MongoDB：JSON文档•分布式–集群分为多个Namespace–同一Namespace内使用一致性Hash及虚结点机制均匀分布数据–利用Redis和MongoDB中的数据库作为（半）虚结点，扩容时只需重分布某些数据库中的数据–Smallinstance,moreinstance火龙果整理uml.org.cn火龙果整理uml.org.cnBDM的内存数据库：说明•高可用–利用RedisSentinal、MongoDBmongostat实时监控集群状态–RedisSentinal••记录集群状态、状态变化通知、控制Redis故障时切换主从多个Sentinal冗余、高可用，可用性投票•数据固化–数据分层•••不可舍弃无法再生的数据可再生数据缓存数据–Redis主不持丽化，从定期持丽化火龙果整理uml.org.cn火龙果整理uml.org.cnBDM的内存数据库：现状•集群–Redis•••24台服务器，单机144G内存每台服务器4个Redis实例3个Sentinal实例–MongoDB••4台服务器，单机144G内存每台服务器4个MongoDB实例•数据–––42亿，1.5T单机读峰值50K/s，写2K/s单机出口流量70MB/s,入口流量峰值：20M/s火龙果整理uml.org.cn火龙果整理uml.org.cnBDM的内存数据库：最终一致性•读写异步模型（lambda架构）•Master挂掉，此时还未同步到Slave的数据–从消息队列中回放数据恢复–算法数据再生，持续输出–Slave升级为Master，原Master恢复后作为Slave•Slave挂掉，恢复后数据重新同步火龙果整理uml.org.cn火龙果整理uml.org.cn百分点内存数据库：其他•In-Memory-Index内存索引–轻量级索引–异步准实时建立•Half-Memory-Sparse-Matrix(TC、KC)–使用嵌入式kc作为算法引擎内存数据库火龙果整理uml.org.cn火龙果整理uml.org.cnQ&A火龙果整理uml.org.cn