读数据的标准姿势:先查缓存，如果缓存中数据不存在时读数据库，然后再将数据写回缓存。
相信这种读缓存方案争议较小，但是对于数据修改时缓存的处理，方案却有多种，需要依据具体的业务需求进行选择。
方案一: 先删缓存再修改数据。
这种方案是最不推荐的，主要是并发的时候缓存中更容易出现脏数据，让我们来分析一下，A修改数据时先删缓存，此时B需要读数据，会读数据库中的修改前的数据，会将数据写到缓存中，然后A修改数据库为新数据。这种场景更容易出现。
方案二: 先修改数据再删缓存。
这种方案再结合缓存设置一个较短的有效期，还是非常推荐的。这种方案发生问题的几率小，而且开发难度小、方案简单，所以最推荐。
那么这个方案就不会出问题吗？让我们来分析一下: 假设缓存中没有数据，A读数据库中数据，B修改数据库中数据然后删除缓存，A因为各种原因处理慢，此时才开始将之前读的库中的数据写缓存，那么缓存中就是脏数据。通常情况下数据库读的速度要远大于写库的速度，所以发生的概率极低，再结合缓存有效期，即使发生了，一定时间后数据也会变成最终一致性。
方案三: 读写缓存时加锁
如果有业务方要求修改数据后需要实时生效，可以考虑此方案。读数据时当缓存中没有时，先加锁，读数据，写回缓存，解锁。修改数据时先加锁，修改数据，删除缓存，解锁。加锁的方式可以考虑redis、zk等。此方案严格保证数据一致性，但是引入了系统复杂度。
