棋牌架构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里做常驻内存的数据。

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

你可能感兴趣的:(棋牌架构DB服务(Mysql+Redis)数据存储演进笔记)