热门缓存数据架构设计

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