如何保证数据库和缓存一致性问题
我刚开始以为数据一致性指的是不同请求拿到的数据是一样的，但是这个对于一致性的定义其实是强一致性。
为了保证系统的可用性和性能，我们选择的是牺牲强一致性来获取最终一致性，那么接下来我们只需要保证最终一致性而无需考虑整个过程中的数据强一致性。我们使用的是旁路缓存的方式。
对于读策略，如果缓存没有过期，直接读取即可。如果缓存过期，可以选择客户端线程或者是redis的后台线程去读数据库的数据，然后更新到缓存中，最后再返回给客户端。
对于写策略，有两种方式，先更新数据库，后删缓存。先删缓存，后更新数据库。
对于先删缓存，后更新数据库来说，假设线程A删缓存，此时线程B访问数据，发现数据不在缓存中。那么线程B需要去数据库中获取数据再将数据放到缓存中，等到线程A更新完数据库后，此时数据库和缓存中的数据不一样，无法保证最终一致性。对于先更新数据库，后删缓存来说，线程A先进行数据库的更新，此时线程B访问缓存有数据直接返回，接着线程A再进行缓存的删除，此时可以保证缓存和数据库的一致性。后续请求访问缓存时，没有命中会到数据库中进行获取对应数据。有一种特殊情况，线程B在缓存中没有找到数据，去数据库中进行数据的查找，线程A更新数据库，等到线程A删除缓存中的数据后，线程B再将之前获取的数据放到缓存中。由于线程B拿到的数据是在线程A更新数据库之前的，那么此时会存在数据库和缓存数据不一致的问题，但是这样的概率会很低，因为将数据写到缓存中的速度大于线程A更新数据库的速度
删除缓存一般存在两种方式：通过设置数据的过期时间和直接删除的方式。
通过设置数据的过期时间比较麻烦，设置过小，缓存没有起到缓存效果，请求会发到数据库中，造成数据库的压力。设置过大，缓存和数据库之间数据延迟较大，且浪费内存。
因此我们选择直接删除的方式来进行优化。此时我们需要保证直接删除能够成功，否则旧有数据一直存放到缓存中，会造成数据一致性问题。
对于直接删除数据会有两种方式。
一种是删除数据重试策略，我们会将需要删除的数据放在消息队列中，由客户端去获取需要删除的数据，尝试删除，如果删除成功那么将消息从消息队列中进行移除，如果没有成功那么重新尝试几次。尝试几次依然没有成功，需要向业务层反馈这个问题。
这种方式缺点是我们需要通过在代码中写死向mq队列发送特定要删除的数据。
另外一种是通过订阅binlog + canal + 消息队列方式。我们通过订阅binlog，将数据解析为结构化数据存放到消息队列中，接着编写一个简单的消费数据的消费者订阅mq，接着通过获取数据的key来完成删除操作。通过ack机制来保证数据一致性问题。
这种方式我们通过订阅binlog。数据发生更新，此时binlog会发生改动，那么canal能够察觉binlog的变化并将改动后的信息发送给mq。这样子并不需要我们硬编码，来完成数据的删除操作。缺点是实现起来比较麻烦。
