基于Redis的消息中心缓存搭建

背景

问题分析

在以往的经历中出现了在大批用户涌入消息中心时，造成数据库负载急剧升高的问题，经过排查，发现原因主要有以下几点：

1. 消息中心相关表中，部分体量较大的数据表没有创建索引，查询操作中数据库连接不能及时释放，导致API服务器不能及时响应，拖垮API服务器；
2. 目前的访问量级对消息中心没有做数据库的读写分离，导致在缺失索引的情况下，影响主库性能，拖累其他业务；

目前解决方案

1. 结合数据库日志，补全消息中心索引；
2. 对消息中心数据库进行读写分离操作，降低主库压力；

仍然存在的问题

在完成上述改造后，仍然有部分较为严重的问题，比如：

1. 在发送真对全量用户的布告板消息时，在仅依靠数据库的前提下，采用为每个用户插入相同的消息来处理，从而导致数据库中无效数据的增多。(需求方不允许单独拆分出公告消息，需将公告消息合并至系统消息中)
2. 对于一些活动推广消息，增加用户组概念，即：对于推广消息，不用的用户查询到的推广消息的内容不同，依赖数据库进行用户分组的查询，即使在创建索引的情况下，仍会导致查询开销的急剧增长；
3. 对于推广消息，支持多图文等富文本格式，依赖数据库查询，在做推广活动时，可能会导致数据库负载明显升高；

需求

类似于淘宝的消息中心，主要体现在如下几点：

1. 系统中心首页包涵多个选项卡：喜欢消息，关注消息，评论消息，系统消息（包含公告板消息），推广消息，物流消息等；
2. 推广消息分用户组进行查看；
3. 推广消息详情支持多图文；

解决方案

基于上述需求单独依赖数据库的话，查询或者更新的开销均较大，因此对消息中心进行缓存改造，由于目前公司的业务需求，缓存系统基于redis，为了增强缓存中内容的可读性，缓存中存放类的信