拜读了: 美团2面：如何保障 MySQL 和 Redis 数据一致性？这样答，虐爆面试官这篇文章后的感想
高并发场景中数据库和缓存的一致性和可用性的感想
- 1，先更新缓存，再更新数据库
- 1.1，前提
- 1.2，理由
- 1.2.1，写多读少
- 1.2.2，写少读多
- 1.2.3，写多读多【重点】
上述文章中认为：删除缓存比更新缓存拥有更好的性能，这个观点我是赞成的，毕竟从复杂度的角度来考虑，如果考虑更新操作，就需要考虑高并发环境下的更新顺序（谁的值是新的，谁的值是旧的），相比而言，不管是谁来都删除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，写多读多【重点】
在这种场景下：
- 首先可以将双写分开，保证了单一职责原则；
- 其次，因为这种方案是先写Cache，所以读多的场合，读到的永远是最新的数据，后期使用MQ消息队列机制也能高性能的保证写入DB的及时和准确性；
- 再者，写多的场合下，优先写Cache会比写DB有更好的性能，缓存中写入新数据的及时也能降低读到脏数据的风险。
考虑不周，只是片面之词，欢迎各方大佬给予点评和指导。
