高并发场景案例分享（一）分库分表

今年在公司重构（写）了一个老项目，踩了无数的坑。

中间好几次遇到问题，甚至感觉项目可能要失败了，好在最后终于成功上线了。

虽然被坑的不要不要的，但也从中领悟到了不少东西，在这里记录一下，顺便分享给大家乐呵乐呵。

先简单介绍下项目，一个面向C端用户的服务，主要提供包括动态、评论、圈子、好友、关注、Feed等常见的社区功能，另外还有其他一些个性化的功能。

日活比较高，整个服务QPS上万。高频业务，单个接口QPS上千。单项业务数据量过亿，比如评论。

图1.qps监控图

在上述高并发、海量数据的情况下，整个系统设计时需要注意的坑，和我总结的一些经验：

数据库层面

MySQL分库分表

因为是重写整个项目，包括重新设计底层数据库，必然要考虑到分库分表。

最初在网上参考了一些分库分表的原则，实际操作中，发现大部分资料都有些缥缈。

如果是简单的应用怎么分表，甚至不分都可以。所以这些原则你也不能说它是错的，但在你最需要参考的时候，这些原则往往不够深入。

分享下我个人总结的一些经验：

先说分库

分库的主要目标，应该是缓解主库（Master）的压力。

绝大部分服务都是读多写少，在读写分离，1主1备N从的情况下，即便为了