MySQL缓存策略
前言
MySQL是大部分业务的铁打需求。而事实上，几乎所有业务的查询操作占比远远高于增删改操作，在这种读远大于写的情况下，MySQL的一些机制反而成了累赘。比如redolog落盘机制，我们每次读都要访问磁盘，访问量一大就会使系统整体性能下降。你可能会疑惑，MySQL不是有个Buffer Pool和Change Buffer吗。没错，内存的访问速度是磁盘访问速度的10万倍，速度上它以绝对的优势战胜了磁盘，并且LRU机制让它能够更新数据。但是！如果用户将在一个固定时间大量访问，LRU机制就是鸡肋，因为热点数据不会改变，而是要提前备好供访问。
所以我们要使用缓存策略，将热点数据提前备好到内存，供某一时刻用户的大量访问。将MySQL用做统计与数据分析的主数据库，缓存数据库（如Redis）就用来助力，但是不会影响整体的可用性，也就是说缓存数据库可有可无。
当然，提高MySQL访问性能的方法有很多，比如读写分离（类似MongoDB）、连接池等等。MySQL有binlog供主从复制，以备不时之需，读操作直接访问多个从数据库，写操作则访问主数据库，这样就达到读写分离的目的。由于异步复制的机制，主从数据库数据就有时差，从数据库的数据就不会是最新的，这时候就要考虑读一致性要求，有要求就没办法，必须读主数据库，这种方法实在性价比低。我们知道SQL语句只能一条条执行，所以我们可以使用多条连接并发执行。连接池就可以提供并发功能。但是要注意一个事务只能在一条连接执行，多条连接在MySQL中就有多个线程，会执行紊乱。
缓存方案
我们以热点数据作为参照物，如果用户读的是热点数据，就读从数据库，如果是非热点数据，就读MySQL，可以设计一个热点数据表来供判断。考虑到将MySQL与Redis这两个进程组合成一个数据库，就要分析数据的一致性问题，值得注意的是：单看热点数据，MySQL没有Redis却有，这不符合MySQL作为主数据库的原则；热点数据一致数据不一致，那我要这个从数据库干鸡毛。
对于读，我们可以先读Redis，如果没有就去读MySQL，有就直接返回。MySQL也没有就返回读失败，有就将数据同步到Redis。
对于写，我们一般在安全与效率之间做权衡。如果以安全优先，MySQL会断开长时间没有操作的连接，如果两条连接断开一条，断开了MySQL那条，为了确保数据一致，可以选择之间删除Redis的缓存，写MySQL，再同步回Redis，但是这种操作很无脑而且违背了使用Redis读的初衷；所以一般选择效率优先，Redis（key-value数据库）可以设置key的值的有效期，我们可以先写Redis，设置key的过期时间（一般为200ms），再马上去写MySQL，最后MySQL同步回Redis，如果MySQL写成功了，就可以同步到Redis，这一整个写操作就完成了，如果写MySQL失败了，数据就没有，就不需要同步，Redis的数据也过期自动删除，这样就当没写过。这种策略就实实在在的保证了数据一致性。如果在过期时间之内访问这个写的数据，是有效的，在过期时间之后就由MySQL是否写成功来决定。
关于同步策略，可以选择开源方案go_mysql_transfer伪装从数据库，它是通过拉取MySQL的binlog获得行数据再同步到Redis。也可以选择触发器+udf，热点数据表设置触发器，与redis连接同步数据。这里不再赘述。
缓存问题
缓存穿透
MySQL与Redis都没有热点数据，却一直读取这个不存在的数据，MySQL崩溃。我们可以在Redis中设置键值对<key,null>，这样就相当于有效访问，但是没有数据。此外，还可以使用布隆过滤器，可确定访问的热点数据一定不存在，提前判断热点数据有没有，没有就不访问。
缓存击穿
Redis没有的数据，MySQL却有，大量的MySQL并发连接请求造成MySQL崩溃。可以设置Redis过热数据不过期。或者可用分布式锁将Redis与MySQL的访问加锁，做同步。
缓存雪崩
大量缓存数据集中失效，但是MySQL却有，造成MySQL崩溃，多出些重启情况。可以间隔设置过期时间。或者在重启时预热向Redis导入热数据。
其他
MySQL与Redis是有区别的，Redis不支持回滚，如果两个都使用事务就无法满足一致性，所以使用这种缓存方案只支持一条一条的SQL语句。