未加星标

热门缓存数据架构设计

字体大小 | |
[大数据技术 所属分类 大数据技术 | 发布者 店小二05 | 时间 2018 | 作者 红领巾 ] 0人收藏点击收藏

  热门数据、通用数据在个性化推荐系统中有这广泛的应用,为什么这么说呢?因为在大部分频道下,当天来的除了20%用户是老用户,还有80%用户是新用户,是在频道内没有历史行为的,这就需要通过热门数据、地域数据、通用数据来补充用户feed信息,好的热门数据能够带来更多的用户转化,好的热门数据架构决定这热门数据带来的价值。

  当下大型互联网公司数据是存在哪的呢?为了好的性能现在大部分公司均将数据存储在redis中,redis有极大吞吐量有着极高的性能,但是在热门数据以及通用数据这个场景下,线上服务直接拉取热门数据不是一个好的方式。特别是当线上服务在618、双11大促进行扩容的场景下。

  redis存储热门数据,线上服务一般采取定时拉取方式获得数据,避免造成线上服务读取redis造成单点。其次因为线上服务节点极多,像首页入口图这种服务平时就有100多个4核16G内存容器在支撑线上服务,为什么有这么多机器,因为采用了极其复杂的推荐算法,并且用着机器学习技术在线上进行推荐,很是消耗内存以及cpu计算资源,这么多的节点给redis服务带来的一个问题是连接数超过redis能够支持的上线,发生后果就是线上mGet拉取定时数据时经常抱错,需要进行重试才能正确拉取数据。

  并且618、双11后进行扩容后,线上服务节点增多,给redis本身带来更大压力,拉取定时数据过多导致阻塞redis服务导致redis吞吐量下降,tp99由1-2ms升到几百ms。

  为什么会有这样情况发生?要从redis架构说起。我们线上服务redis集群规模是几百G到2T多个集群,集群规模大,为了节省空间增加资源使用率,一般是采用一主一从架构,异地双机房进行容灾处理,这样架构本身没有任何问题,但通用数据本身存储在一个或几个分片上,当线上几个入口图服务同时拉取这几个分片上数据时,会产生几千个连接,而一个集群建议连接是500,连接数远超上限就导致了,获取不到可用连接导致此次拉取热门数据失败,拉取失败节点数过多会导致线上效果变差,热门数据架构问题就是一个急需解决的问题。

  问题很明确就是连接数过多导致取不到可用连接,再有就是过多拉取redis数据导致redis阻塞影响redis集群吞吐以及tp99,明确了问题,那么就需要一个问题一个问题去解决。

  过多拉取导致redis阻塞影响redis集群吞吐,那么一种解决办法就是将redis存储热门数据摘出来,存储到单独地方,避免对redis造成过大压力,通过拆分解决redis压力过大问题。

  过多连接导致连接不可用,netty长连接,对linux进行相应设置单个机器可以支持10k甚至100k连接没有问题,通过成熟dubbo等微服务来提供连接调用,能解决连接数过多问题。

  结合上边这两点在java技术栈下可以采用ehcache+dubbo方式提供热门数据存储,因为热门、通用数据一般在100万数量以下,上边架构能很好解决热门数据问题,并且不用造新的轮子。

热门缓存数据架构设计

  如果ehcache或者dubbo或者java语言在实际线上作为热门存储存在瓶颈,可以采用c或c++语言进行重写上述架构,自己实现hash内存存储,通过google grpc实现跨语言的高性能rpc服务,也能很快实现一个热门、通用数据存储架构。

  随着个性化推荐系统机器学习化、深度学习化,线上服务还会遇到这样那样的问题,需要我们不断去解决各种各样问题,来配合业务发展。同时在解决问题过程中也不断提升我们的技术水平,以及架构能力。

  一年之计在于春,coding now!


热门缓存数据架构设计
tags: redis,热门,数据,拉取,线上,连接,架构,服务,存储,集群,导致,用户,通用,数过
分页:12
转载请注明
本文标题:热门缓存数据架构设计
本站链接:http://www.codesec.net/view/573037.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 大数据技术 | 评论(0) | 阅读(54)