棋牌架构DB服务（Mysql+Redis）数据存储演进笔记

自新项目开展以来，需要接触与数据存储打交道那一块业务，以前的项目开发过程中因为写的都是棋牌玩法相关的业务逻辑，虽然也私下看过DB服务代码，但是当时对数据库与缓存的理解还是停留在语法使用层面，所以对DB服务设计的利弊完全没有概念。

现在写的一些业务，比如排行榜、邮件、签到和商城等等与DB服务接口的交互频繁，加之微信小游戏的流量增长速度相比棋牌app要大得多，面对冷热数据的处理，就不得不多做性能方面的优化考虑。

之前的DB服务设计是所有数据都做平台缓存、redis缓存以及mysql存储。当然，因为之前项目的用户规模小，业务简单，以及一些个人的惰性思维，所以也就没太多去考虑DB架构是否需要优化。

当业务规模达到一定量级，原有的架构愈加不能满足业务需求的时候，是该考虑架构演进了。

遵循架构设计的三原则：合适、简单、演化。

首先给自己提几个问题：

1. 有必要所有数据都做平台缓存、redis缓存以及mysql存储吗？

2. 做了redis缓存还有必要做平台缓存吗？

3. 什么数据做了mysql数据持久化存储还应该做Redis缓存？

4. 什么数据做了mysql数据持久化存储可以不用做Redis缓存？

5. 什么数据可以只做Redis缓存不做mysql数据持久化存储？

首先回答第2个问题，遵循架构设计的简单合适原则，当前业务没有必要做双缓存，当前业务数据不存在对读热点，即使存在，也可以通过其他途径缓解压力，比如读写分离、分库分表。双缓存的设计反而使程序设计起来更复杂，因为面对缓存引发的故障（比如缓存穿透、雪崩、未命中等）处理都是单缓存的2倍处理量。

第1个问题的答案是否，有些冷数据没必要做缓存，毕竟内存的代价比硬盘大的不是一个量级的。当然，钱多任性除外。

回答问题3，自然是读多写少的热点数据，比如用户基本信息。

问题4答：读写均衡、或者写多读少的数据，比如邮件数据。

问题5答：单体量小的热点数据，单体量小指的是每一个用户行数据占用内存容量较小的数据，比如排行榜数据，因为排行数据我们只需要记录玩家的uid以及score值即可，然后这类数据又是热点数据，适合在Redis里做常驻内存的数据。

通过这几个问题的分析，遵循架构设计的简单合适原则，演化的路线算是明了了。