看到有人讨论redis与mysql一致性的问题,思考一下。
1.mysql
1.1 单节点mysql
毫无疑问,这种模式只能用来做测试,生产环境再小的公司都不推荐,除非数据没什么重要,没有mysql也能正常提供服务。
提醒一下一定要做好数据备份。
1.2 主从mysql
单主一从或多从,相对单节点来说,优点:
- 高可用提高一个档次,挂掉一个节点也能较快恢复服务(主挂掉需要人工介入);
- 数据不容易丢失;
- 做好读写分离,数据统计等高负载请求放在从节点,提高并发
- 架构简单易懂,好维护;
缺点也很明显:
- 写依然是单节点,存在性能问题;
- 恢复时需要人工介入(工具可实现自动化,如MHA),切换时间长;
- 从节点较多时,或写操作比读操作多很多时,从节点备份数据就会占用大量网络与IO,造成主节点性能降低,当然这可以使用树状结构来缓解主节点压力,即主节点只给少量从节点备份数据,其他从节点再从这几个节点来备份;
1.3 双主mysql
要做到秒级容灾切换,双主是个很好的选择,也可以附加多从,做到读写分离。但双主无法回避的一个问题是数据的一致性,也就引出了双主的不同用法。
1.3.1 双主单写
其中一个主节点只做高可用容灾备份,不进行写操作,在另一个主节点挂掉后,可以快速提供服务,确保系统可用。
1.3.2 双主双写
可解决单主节点的写瓶颈问题,但易发生数据冲突,可由一些配置来解决部分问题,如配置一个节点自增单数,一个节点自增双数,解决插入数据冲突问题;还可以业务层添加逻辑,做数据路由,单数数据与双数数据去不同节点去写等等。需要在性能与复杂性之间做一个取舍。
2.redis
KV存储——数据复杂度不高,内存数据库——读写效率高但数据稳定性不高(相对),当然现在redis也支持集群,类似mysql主从,数据稳定性上相对高了不少。适合当缓存与mysql配合使用。
2.1 数据同步
包括几种场景
2.1.1 mysql数据可用
这种情况处理起来简单,因为mysql中数据是正常的,不会有并发性问题
-
未缓存
需要从mysql中查询数据,存入redis -
缓存需要更新
数据业务逻辑上已过期,但redis中还存在,需要从redis中删除,再从mysql中同步数据
2.1.2 mysql数据已过期
逻辑稍微复杂一点,如果先更新mysql,redis有可能被其他线程取走旧数据,所以需要先更新redis再更新mysql,但要考虑mysql更新失败的情况处理。