mysql高可用与redis缓存简记

看到有人讨论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中数据是正常的，不会有并发性问题

1. 未缓存
   需要从mysql中查询数据，存入redis

2. 缓存需要更新
   数据业务逻辑上已过期，但redis中还存在，需要从redis中删除，再从mysql中同步数据

2.1.2 mysql数据已过期

    逻辑稍微复杂一点，如果先更新mysql，redis有可能被其他线程取走旧数据，所以需要先更新redis再更新mysql，但要考虑mysql更新失败的情况处理。