你好,游客 登录
背景:
阅读新闻

热门缓存数据架构设计

[日期:2018-03-05] 来源:公众账号  作者: [字体: ]

  热门数据、通用数据在个性化推荐系统中有这广泛的应用,为什么这么说呢?因为在大部分频道下,当天来的除了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!





收藏 推荐 打印 | 录入:Cstor | 阅读:
相关新闻       数据​  大数据​ 
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款