热门数据通用数据在个性化推荐系统中有这广泛的应用, 为什么这么说呢? 因为在大部分频道下, 当天来的除了 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 服务, 也能很快实现一个热门通用数据存储架构
随着个性化推荐系统机器学习化深度学习化, 线上服务还会遇到这样那样的问题, 需要我们不断去解决各种各样问题, 来配合业务发展同时在解决问题过程中也不断提升我们的技术水平, 以及架构能力
来源: http://www.tuicool.com/articles/ii2aeua