一.问题引入
目前在写项目的时候，在B端查看文章，A端修改文章。为了增加效率，以及防止堆内存溢出，在B端选择本地缓存文章的方案。但是目前出现了A端对文章修改之后，B端读的还是旧数据，出现了缓存不一致的问题
二.解决方案
1. 本地缓存失效策略
A端只要有文章修改，就将对应的caffineKey缓存删除，B端就会重新去读新的数据.
问题:
由于在线上环境下，服务是集群的形式部署的，因此在使缓存失效的时候是随机使一个节点的缓存失效，不能所有的节点都失效，所以会存在某些节点仍然会读到旧缓存的问题。
2. 加入redis,使redis失效策略
由于redis是分布式缓存，在集群下，所有节点都能读到
2.1 redisKey与caffineKey一一对应
A端只要有文章修改，就将对应的redisKey缓存删除，B端先判断某篇文章的redisKey是否存在，存在则说明该文章没有发生变更，去caffine拿相应缓存，否则去查数据库。
问题:
理想条件下这种方案是比较好的，但是目前A段在修改文章的时候，粒度不能进行控制，对于不同的操作，修改文章的篇数不同，有是可能会改动到所有的文章，这是需要删除所有的redis缓存，但是在遍历某文件夹下所有的key是一个十分消耗性能的操作，容易造成redis崩溃,所以不推荐。
2.2 redisKey只存一个控制所有caffineKey
目前的想法是，redisKey只存一个，只要有文章的变更就让redisKey失效，那么当访问文章时，先查看是否有redisKey缓存，如果没有直接去查数据库，不去查缓存，查了数据库之后，更新缓存。
问题:
如果有A,B两篇文章都进行了缓存，但是此时A文章进行了修改，因此redisKey失效，当B再次读取的时候，redisKey重新失效，再去读A，由于A中的缓存未发生变更，因此读到的还是旧数据
2.2 redisKey只存一个控制所有caffineKey同时redisKey和caffineKey的值中时间戳
redis和caffine缓存中存储时间戳，如果redis和caffine缓存时间戳相等，说明caffine缓存中的数据没有落后
问题:
因为每次当caffine缓存中的时间戳和redis中的时间戳不一致就会去重新插入redis，这样就会造成，只要有一片文章重新去数据库查了，就会导致之前的caffine缓存都失效，失去了缓存的意义。
3.redis缓存作为文章发生变更的标识
只有在文章发生变更的时候才会进行redis缓存的插入/更新操作
这个时候只是把redis缓存作为文章发生变更的标识，在查文章的时候也不会先去看redis是否存在，而是先看本地缓存是否存在，然后再看redis是否存在（是否发生变更）,以及如果redis缓存存在，时间戳的比较(判断该本地缓存是在变更前写入的还是变更后写入的)
三.总结
通过这个实践，还是得从一开始弄明白整个方案设计的可能存在的问题，以及对于redis缓存的键和值进行灵活的使用。
