用mysql+redis实现微博feed架构上需要注意哪些问题

微博中的feed(新鲜事)通常采用mysql+redis架构，当用户发一条微博时，系统会将该条微博写到其粉丝的feed列表中。目前有个疑问如果把mysql以写为主，redis只做缓存用来读，这在技术实现上需要注意哪些问题?
可以从架构思路上来说说，如以redis做缓存、以mysql为主、以redis为辅。

1、MySQL使用需要注意的地方

1) 存储引擎选择InnoDB，在高并发下读写有很好的表现

2) 数据合理分表分区，均衡各数据库服务器的负载

3) 适当作数据的冗余，便于在cache失效时的快速恢复

2、Redis使用需要注意的地方

1) 合理规划cache

将访问量高的热点数据统计出来、分类缓存。

对微博来说，主要有三种形式的缓存：IDs，content，page。

IDs包括各种关系的ID列表，如用户的粉丝、关注的对象、发表的新鲜事等，这些可以缓存在Redis的set或list结构中；

content包括各ID的具体信息及内容，如新鲜事的正文、用户的详细信息等，这些可以缓存在Redis的string或hash结构中；

page包括一些热点页面的部分内容或全部内容缓存，如名人主页等，这些可以缓存在Redis的string结构中。

根据以上缓存类型以及缓存的大小和过期时间，就可以规划出不同缓存如何存放、如何使用才能更高效地利用缓存的方式。
2) 缓存的压缩

在高访问量和高并发下，每一个字节的减少都是巨大的节省。

根据以上缓存类型的分析，我们可以对string结构的内容做压缩存储，如新鲜事的正文以及page cache等。

3、数据实时性与一致性

1) 实时性

在发表微博时，如果采用的是推送给粉丝的方式，为了保证快速响应，可以使用消息队列，先发表，再在后台推送。如果粉丝比较多，还可以将粉丝按照是否在线分组，通过不同队列发送。
2) 一致性

一致性主要是针对缓存与数据库中的数据不一致而言。

对于重要的数据，我们可以采取先写数据库再写缓存的方式来保证，而对于不太重要但对响应速度要求很高的数据可以采取先写缓存然后通过消息队列再写入数据库的方式。当然，需要做好错误日志记录以及能根据日志恢复数据。

本文转自互联网，在此感谢！