超大规模系统下，MySQL到Redis的数据同步也不难吧？

导读：本文将重点讨论在超大规模系统中缓存会面临什么样的问题，以及应该使用什么样的策略来更新缓存。

一、缓存穿透

超大规模系统的不能承受之痛

如何构建Redis集群？由于集群可以水平扩容，因此只要集群足够大，理论上支持海量并发就不是问题。但是，如果并发请求数量的基数过大，那么即使只有很小比率的请求穿透缓存，直接访问数据库的请求其绝对数量也仍然不小。再加上大促期间的流量峰值，还是会存在因为缓存穿透而引发系统雪崩的风险。

那么，这个问题该如何解决呢？其实方法并不难想到，不让请求穿透缓存就行了。如今内存存储的价格一路走低，只要能买得起足够多的服务器，Redis集群的容量就是无限的。 我们可以把全量数据都放在Redis集群中，处理读请求的时候，只需要读取Redis，而不用访问数据库，这样就完全没有“缓存穿透”的风险了。 实际上，很多大型互联网公司都在使用这种方法。

不过，在Redis中缓存全量数据，又会引发一个新的问题。那就是，缓存中的数据应该如何更新呢？因为我们取消了缓存穿透的机制，在这种情况下，如果能从缓存中直接读到数据，则可以直接返回，如果没能读到数据，那就只能返回错误了！ 所以，当系统更新数据库的数据之后，必须及时更新缓存。

至此，我们又要面对一个老问题：如何保证Redis中的数据与数据库中的数据同步更新？可以用分布式事务来解决数据一致性的问题，但是这些方法都不太适合用来更新缓存。原因是，分布式事务对数据更新服务有很强的侵入性。这里仍以下单服务为例来说明，如果为了更新缓存，增加一个分布式事务，那么无论我们使用哪种分布式事务，下单服务的性能或多或少都会受到影响。还有一个问题是，如果Redis本身出现了故障，写入数据失败，则还会导致下单失败的问题，相当于是降低了下单服务的性能和可用性，这样肯定是不行的。

对于像订单服务之类的核心业务，一个可行的方法是，启动一个更新订单缓存的服务，接收订单变更的消息队列（Message Queue，MQ）中的消息，然后更新Redis中缓存的订单数据。使用订单变更消息更新缓存的结构如图1所示。因为对于这类核心的业务数据，使用方通常会非常多，服务本来就需要向外发送消息，增加一个消费订阅，基本上不会增加额外的开发成本，也不需要对订单服务本身做出任何更改。

图1使用订单变更消息更新缓存

对于上述方法，我们唯一需要担心的问题是，如