高并发场景中DB和Cache的一致性新的方案感想

拜读了: 美团2面：如何保障 MySQL 和 Redis 数据一致性？这样答，虐爆面试官这篇文章后的感想

上述文章中认为：删除缓存比更新缓存拥有更好的性能，这个观点我是赞成的，毕竟从复杂度的角度来考虑，如果考虑更新操作，就需要考虑高并发环境下的更新顺序（谁的值是新的，谁的值是旧的），相比而言，不管是谁来都删除cache中的数据是更为高效和经济的。

在看完之后，我突发奇想地提出以下的一种双写的方案，欢迎大家讨论点评：

1，先更新缓存，再更新数据库

1.1，前提

文中末尾也提到CAP原理，AP和CP就是水火不容，高并发的场景中是不可能放弃AP的，所以需要我们从CP的角度去考虑能否降低数据一致性带来的影响。文中的延迟双删策略是个不错的手段，但是第二次删除的可靠性并不能完全得到保证，所以引入了消息队列（MQ）机制，通过使用消息队列的可重试，可确认已经高可用的特点，完成写入DB后对Cache的完整删除，以降低脏数据的风险。

1.2，理由

1.2.1，写多读少

在这种场景下，频繁的更新缓存虽然会对缓存造成一定的压力，但是考虑到数据库的IO瓶颈，从效率上来讲更新Cache也会比更新DB的效率高很多；

1.2.2，写少读多

在这种场景下，就更可以稍微忽略对Cache的写压力了；

1.2.3，写多读多【重点】

在这种场景下：

1. 首先可以将双写分开，保证了单一职责原则；
2. 其次，因为这种方案是先写Cache，所以读多的场合，读到的永远是最新的数据，后期使用MQ消息队列机制也能高性能的保证写入DB的及时和准确性；
3. 再者，写多的场合下，优先写Cache会比写DB有更好的性能，缓存中写入新数据的及时也能降低读到脏数据的风险。

考虑不周，只是片面之词，欢迎各方大佬给予点评和指导。