SNS站点的数据存储方案

今天看了篇文章，谈到SNS站点应用中的分库分表问题，这里我也谈谈我对SNS站点和应用数据存储的看法。

一、数据存储

SNS站点中数据层根据业务和访问特性可分为几类：

1. 读写都很频繁，非重要数据。

如应用feeds等。 这部分数据通常读写都很频繁，但丢失的话用户也不是特别关注，因些通常保存在内存cache中，而不落DB，旨保证用户请求的快速响应。

2. 读频繁写不频繁，重要数据。

比如用户等级数据、评论、留言等。 这类数据一定要落到DB里，保证数据的终极存储，前端用内存cache保证快速响应，因为写并不是很频繁，因些DB足以支持，通常mysql可以支持每秒200-400次写请求。

3. 读写都频繁，次重要数据。

这类数据是最让人头疼的数据，通常的处理方式是前端用内存cache，后挂DB，但因为写操作很频繁，如果每次操作都直接更新到DB的话，DB根本无法支持，因此，我们可以考虑合并请求。可以单独搭一个内存cache用来记录用户数据是否被更新过，每隔一定的时间，比如10分钟，批理处理一下，把内存cache中的数据同步到DB中来。这样，可以大量的用户请求被合并，以现在非常火的开心农场为例，用户每天登录后会把所有的好友的菜偷一遍，假设平均一个用户有20个好友，每个好友有两块地可以偷，这样，共有有40次写请求，如果每次请求都把偷到的果实写到仓库DB的话，就需要40次写操作，但如果合并的话，一次就可以搞定了。

这样处理方式也有风险，那就是如果内存cache机器掉电的话，数据全部会丢失，如果从DB恢复的话，只能回到10分钟之前的档，但通常通过补偿的方法也可以平息用户的投诉。因此，这一点也是可以接受的，因为架构如果要做到完美的话，成本就会很高了。

4. 好友信息汇总数据

这是一类比较特殊的数据，比如应用中的好友近况等。这类数据通常用来拉动活跃，一般会放到首页，因此读请求也会比较高。如果实时去拉取数据并进行汇总的话，开销是非常大的，因为首先需要先访问好友关系链，把好友列表拉出来，再依次去取数据，最后进行数据合并、排序等，这种处理方式网络开销很严重，假设平均一个用户有20个好友，那么好友关系链请求10ms，每个用户数据请求到返回50ms，这样单网络开销就有1.01s，这样的开销是用户是无法接受的。那应该怎么处理呢？

首先，我们需要对汇总后展示的数据进行内存cache，这样可以保证首页请求的数据是key-value形式的，一次请求可以搞定。但是这里的数据也需要更新，所以我们需要另一个内存cache，来保存最近有数据更新的好友列表，这样，每次首页读数据时，先查一下是否有好友更新，如果有更新的话，只要查询一下有更新的好友数据即可。

但如果好友应用更新很频繁的话，可能每次首页读数据时发现所有好友数据都有更新，这样，又退化到最初的方式了，对于这种非常活跃的应用，可以强行在用户侧进地文件或IE缓存，保证用户若干时间间隔的请求读的都是本地cache的数据，这种方式虽然更新不是很及时，但可以保证首页的稳定，同时也起到了拉动活跃的效果，还是很不错的。

二、数据库分库分表

数据无论是保证在内存cache还是db中，都存在一个分库分表的问题，通常的做法是分成十库十表、百库百表或千库百表，这里推荐使用千库百表的方式，这样最大可以拆分到100000台机器上，一般的应用，能到这个规模就已经很惊人了。举个例子，比如一个用户的id是1234567，那么他的数据会落在库567表34上，这种方式也便于路由。在业务刚上线时，一到两台db就可以搞定，随着业务的活跃人数和同时在线的增长，可以方便的把数据迁出来，因此这种分库分表方式十分灵活，也便于扩展。

三、冗灾

上面的4类数据，如果出现掉电、DB异常应该如何处理呢？

对于1、4这类非关键数据来说，丢失也无所谓，用户不是很关心。

对于2这类重据来说，DB一定要做热备，因此关键数据的数据量也比较小，所以热备的成本也不是很高。

对于3这类次重要数据，一般数据量比较大，DB一般做增量备份就可以了，一般内存cache和DB不可能同时出问题，因此数据恢复还是可以实现的。如果DB异常的话，可以恢复到冷备数据或通过内存cache的数据，重写一份。如果cache机掉电的话，可以采用上面提到的方案，从DB中恢复数据，用户资料回档到10分钟之前，同时对用户进行补偿与告知，平息用户投诉。

三、总结

本文主要讨论了SNS站点和应用数据存储的问题，上面给出的方案基于业务可用性、稳定性、冗灾以及成本的综合考虑，用一位前辈的话就是“一切都是均衡”，业务的稳定性不能单独靠高成本去保证。 SNS应用业务的特点很大，这里可能并不能全面的覆盖，后续我会根据新业务的特性继续补充，欢迎大家关注讨论！