DB，Cache和Redis应用场景分析

最新推荐文章于 2025-07-25 15:57:11 发布

转载最新推荐文章于 2025-07-25 15:57:11 发布 · 70 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：http://www.cnblogs.com/kenshinobiy/p/4316297.html

文章标签：

#数据库 #移动开发

本文介绍了作者在开发一款微博产品的过程中使用MySQL、Memcached及Redis进行数据存储的经验。重点讲解了不同存储技术在微博场景中的应用，包括持久化存储、缓存及计数器等。

最近做一产品，微博方面的。数据存储同时用到了DB(mysql),Cache(memcache),Redis。其实最开始架构设计的时候是准备用MongoDB的，由于学习成本太高，
最终选择放弃了，采用了比较保守的方案。这款微博产品做了将近一年，涵盖了手机客户端(ios,android),web（刚上线不久），现在差不多有10多W用户，光
DB的写操作也到了几十W每日，前段时间刚刚做了一个读写分离。目前感觉这套系统还比较稳定。下文主要就微博产品的一些数据存储的应用场景做个简要介绍。
DB
DB主要用来存储一些不经常修改的数据，比如微博，评论，好友关系，用户信息，和一些微博分类。这里边联表查询比较多，虽然有些地方做了一些视
图。由于业务比较复杂，还是有不少地方超过了3个表的联表查询。随着数据量的逐步增加，下一步要考虑分库分表了。
Cache
主要对经常使用的数据做了缓存，比如新发的微博，第一页评论，登录的用户信息，微博分类。目前主要做了细粒度的缓存，下一步针对业务级做一些缓
存。
Redis
主要用来做计数器，比如发帖数，评论数，阅读数之类的，比较合适存储经常改变而又需要永久存储的数据，这也是和cache的区别。另外对登录后的好
友关系做了一个redis备份。Redis还做了一些临时存储的数据，比如今日最热微博，本周最热微博ID列表。
这三个组件相辅相成。其实DB放了一些需要永久存储，而不经常修改的数据。Cache针对单表和业务层分别做了一些细粗粒度的缓存。Redis主要放了一些
不太紧要的而又经常改变的数据。

转载于:https://www.cnblogs.com/kenshinobiy/p/4316297.html