最近这几天,一直在思考写服务器的时候怎么做数据库的读写服务,用什么架构来做这个事情,现在终于有了一个大概的想法,用redis+mysql的方法。
目前业内有两种思路,一种是full-mem模式,即全用redis存储这种方式。另外一种是redis只存热数据,大部分数据放到mysql里。具体选哪种还是要看具体的需求。
一般而言,纯redis用于数据量比较小,读写极为频繁的状况,而redis+mysql结合是用于解决数据量比较大,而且冷数据比较多的情况。必定redis的价格还是蛮高的,一台2G的redis节点阿里云只需要270一个月,而一台256G的redis节点就要5W一个月,一年就是60W,用来发点奖金啥的都挺好的。
我决定暂时用redis+mysql结合的方式,redis中只存3天或7天以后用户访问过的数据,mysql中存储其他的数据。大概思路如下:
启动阶段:
从mysql中读取一部分常用的不会在服务器运行过程中修改的配置表,根据实际需求初始化成各种redis的表,方便查询。比如一个道具配置表的结构是:
CREATE TABLE `standard_item` ( `sn` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT ‘sn‘, `id` int(10) unsigned NOT NULL DEFAULT ‘0‘ COMMENT ‘物品id‘, `name` varchar(50) NOT NULL DEFAULT ‘11‘ COMMENT ‘道具名‘, `type` tinyint(4) NOT NULL DEFAULT ‘0‘ COMMENT ‘类型‘, `sub_type` smallint(5) unsigned NOT NULL DEFAULT ‘0‘, `quality` tinyint(4) NOT NULL DEFAULT ‘0‘ COMMENT ‘品质‘, `stacked_num` smallint(6) NOT NULL DEFAULT ‘0‘ COMMENT ‘堆叠数量‘, `use_num` smallint(6) NOT NULL DEFAULT ‘0‘ COMMENT ‘使用数量‘, `is_use` tinyint(4) NOT NULL DEFAULT ‘0‘, `price` smallint(6) NOT NULL DEFAULT ‘0‘, `effect` varchar(50) DEFAULT NULL, `version` int(10) NOT NULL DEFAULT ‘0‘ COMMENT ‘球员碎片对应的版本‘, PRIMARY KEY (`sn`), KEY `IX_Type` (`type`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=2478 DEFAULT CHARSET=utf8 COMMENT=‘标准物品表‘;
这个表在redis中存储一般会是以standard_item:id为key的哈希表,但是策划如果有需求根据type和quality查询所有道具的话,我就应该在初始化的阶段将standard_item多转存出几个standard_item:type:quality为主键的set来,以启动时候预处理的时间来换取运行阶段大量查询的时间,或者避免用户查询的时候击穿redis到mysql数据库。
启动完成以后,读运算:
用户请求服务器===》 服务器查询redis是否有用户缓存
===》如果有返回数据并进行对应运算
===》如果没有,击穿缓存层,访问mysql数据库读取数据===》返回数据并保存至redis,标记3天后过期
启动完成后,写运算:
服务器有写请求===》将写请求置入写的队列,解除数据的过期时间
写数据的线程===》如果队列中有需要写的数据,就取出一条进行mysql写操作===》写入成功,标记redis数据3天后过期
===》写入失败,重写至次数尝试超过限定次数,写日志
===》如果队列中没有需要写的数据,休眠一小会
明天按照这个思路试着做套数据库读写机制试下。