数据库和redis缓存双写不一致的问题
最初级的缓存不一致问题以及解决方案
Q：如果先修改数据库再删除缓存，那么当缓存删除失败来，那么会导致数据库中是最新数据，缓存中依旧是旧数据，造成数据不一致。
A：可以先删除缓存，再修改数据库，如果删除缓存成功但是数据库修改失败，那么数据库中是旧数据，缓存是空不会出现不一致
比较复杂的数据不一致问题分析
问题：对于数据发生来变更，先删除缓存，然后去修改数据库，此时数据库中的数据还没有修改成功，并发的读请求到来去读缓存发现是空，进而去数据库查询到此时的旧数据放到缓存中，然后之前对数据库数据的修改成功来，就会造成数据不一致
解决方案：将数据库与缓存更新与读取操作进行异步串行化。当更新数据的时候，根据数据的唯一标识，将更新数据操作路由到一个jvm内部的队列中，一个队列对应一个工作线程，线程串行拿到队列中的操作一条一条地执行。当执行队列中的更新数据操作，删除缓存，然后去更新数据库，此时还没有完成更新的时候过来一个读请求，读到了空的缓存那么可以先将缓存更新的请求发送至路由之后的队列中，此时会在队列积压，然后同步等待缓存更新完成，一个队列中多个相同数据缓存更新请求串在一起是没有意义的，因此可以做过滤处理。等待前面的更新数据操作完成数据库操作之后，才会去执行下一个缓存更新的操作，此时会从数据库中读取最新的数据，然后写入缓存中，如果请求还在等待时间范围内，不断轮询发现可以取到缓存中值就可以直接返回（此时可能会有对这个缓存数据的多个请求正在这样处理）；如果请求等待事件超过一定时长，那么这一次的请求直接读取数据库中的旧值
对于这种处理方式需要注意一些问题：
读请求长时阻塞：由于读请求进行来非常轻度的异步化，所以对超时的问题需要格外注意，超过超时时间会直接查询DB，处理不好会对DB造成压力，因此需要测试系统高峰期QPS来调整机器数以及对应机器上的队列数最终决定合理的请求等待超时时间
多实例部署的请求路由：可能这个服务会部署多个实例，那么必须保证对应的请求都通过nginx服务器路由到相同的服务实例上
热点数据的路由导师请求的倾斜：因为只有在商品数据更新的时候才会清空缓存，然后才会导致读写并发，所以更新频率不是太高的话，这个问题的影响并不是特别大，但是的确可能某些机器的负载会高一些 。