作者先写了架构方面的关注点。极简缓存架构将框架定义为客户端层、缓存提供层、缓存管理层、缓存存储层。其中缓存存储层又分为基本存储层、LRU存储层和Weak存储层。缓存系统主要消耗的是服务器的内存，因此，在使用缓存时必须先对应用需要缓存的数据大小进行评估，包括缓存的数据结构、缓存大小、缓存数量、缓存的失效时间。在业务方面，作者建议将使用缓存的业务进行分离，核心业务和非核心业务使用不同的缓存实例，从物理上进隔离，如果有条件，则请对每个业务使用单独的实例或者集群，以减小应用之间互相影响的可能性。
然后作者又从缓存的细节方面描述他的关注点：所有的缓存实例都需要添加监控，这是非常重要的，我们需要对慢查询、大对象、内存使用情况做可靠的监控。任何缓存的key都必须设定缓存失效时间，且失效时间不能集中在某一点，否则会导致缓存占满内存或者缓存雪崩。在使用缓存时需要进行缓存设计，要充分考虑如何避免常见的缓存穿透、缓存雪崩、缓存并发等问题，尤其是对于高并发的缓存使用，需要对key的过期时间进行随机设置。
然后作者讲述了缓存一致性方面的关注问题：如果两个线程同时执行更新操作，线程1更新数据库后，线程2也更新了数据库，然后开始写缓存，但线程2先执行了更新缓存的操作，而线程1在执行更新缓存的时候就把线程2更新的数据给覆盖掉了，这样就会出现数据不一致。先删缓存，这种操作对于如商品这种查询非常频繁的业务不适用，因为在你删缓存的同时，已经有另一个系统来读缓存了，此时事务还没有提交。对于数据库和缓存数据一致性。京东采用了通过canal更新缓存原子性的方法。先更新数据库，再删除缓存。
最后作者描述了缓存在其他方面的问题。对于本地缓存，如果对性能的要求不是非常高，则尽量使用分布式缓存，而不要使用本地缓存，因为本地缓存在服务的各个节点之间复制，在某一时刻副本之间是不一致的，于分布式缓存，我们需要在Nginx+Lua应用中进行应用缓存来减少Redis集群的访问冲击；即首先查询应用本地缓存，如果命中则直接缓存，如果没有命中则接着查询Redis集群、回源到Tomcat；然后将数据缓存到应用本地。预防缓存失效的连接风暴的方案是将缓存失效时间分散开。数据预热处理，提前把数据读入到缓存。使用远程缓存（如Redis、Memcached）时，一定要对操作超时时间进行设置。对于缓存崩溃的两种解决犯法：取模，一致性哈希。对于缓存崩溃后的快速恢复，要用主从机制，做好冗余，即其中一部分不可用，将对等的部分补上去；如果因为缓存导致应用可用性已经下降可以考虑：部分用户降级，然后慢慢减少降级量；后台通过Worker预热缓存数据。如果开启Nginx Proxy Cache性能不升反降，内核使用LRU机制。
作者的这篇文章干货很多，作者依次从缓存架构，缓存的一致性，缓存的细节，常见缓存问题的解决方案等方面讲述了后端缓存的关键关注点。在这篇文章中作者给出了当我们设计后端缓存时需要做出选择的最佳选择方案以及对于一些常见后端缓存问题的解决方法。作者的有些解决方法不仅在后端缓存上很实用，在设计其他方面时也可以借鉴。