1.缓存时间设置的合理性：
是否针对业务场景的合理性以及缓存的更新机制设置合适的缓存时间。如果缓存时间设置过短，会对数据库访问频繁；如果缓存时间设置太长，会占用过多内存，造成内存浪费，并且如果缓存是被动更新（缓存失效才会查数据库），缓存设置时间太长会造成用户访问的数据一直是老得。
2.缓存更新机制：
缓存什么时候更新；是否符合业务场景需求。
缓存更新分为主动更新和被动更新。主动更新即数据入库时，同时写入缓存；被动更新即访问时先访问缓存，缓存没有，访问数据库并把数据存入缓存；主动更新和被动更新适用场景略有不同，需要根据业务场景选择合适的缓存更新机制。（主被动更新可同时拥有）
3.缓存内容是否正确：
根据业务逻辑，查看缓存具体内容是否正确，是否和数据库中数据保持一致；数据类型（string、list等）设置是否合理；缓存的增删改查是否正确。
4.缓存读取逻辑是否合理：
有缓存读缓存，没有缓存请求接口或数据库，并更新缓存。
5.数据不存在情况：
数据在redis和数据库中都不存在，业务逻辑是否正常（如是否需要设置默认值；该数据是否是强依赖数据等）
6.缓存穿透：
是否会产生缓存穿透现象，如何避免。
现象：同一时间大量去请求缓存中没有数据库中也没有的数据。
问题：会导致数据库压力过大。
解决方案：
1.从DB中查询出来数据为空，也进行空数据的缓存，避免DB数据为空也每次都进行数据库查询，但是此种情况需要设置redis过期时间较短并最好配合主动更新机制。
2.接口层增加校验，如用户鉴权校验，异常参数（id<=0）校验；
7.缓存击穿：
是否会产生缓存击穿现象，如何避免。
现象：key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据，在redis中过期，同一时间大量去请求”缓存中没有“且”数据库中有”的数据。
问题：数据库瞬间压力过大。
解决方案：
使用互斥锁
热点数据不过期。
8.缓存雪崩
是否会产生缓存雪崩现象，如何避免。
现象：缓存中数据大批量到过期时间，而查询数据量巨大。（与缓存击穿的区别在于这里针对很多key缓存，前者则是某一个key。）
问题：数据库压力过大。
解决方案：
1.缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
2.如果缓存数据库是分布式部署，将热点数据均匀分布在不同的缓存数据库中。
3.使用锁或队列
4.缓存标记：记录缓存数据是否过期，如果过期会触发通知另外的线程在后台去更新实际key的缓存；