Redis使用注意事项
-
Redis作为单线程应用，如何保证高可用？
基本上，通过lua和Pipeline机制保证redis的高可用，其原理都是减少应用和redis的交互次数，但是这两种略有不同，lua可以执行逻辑，而pipeline只适用于redis查询之间彼此无关的组合，如果满足pipeline的适用条件，使用Pipeline的效率会比使用lua的效率更高，同时，lua也不适合执行过于复杂的逻辑，如果单条lua脚本耗时过长，会导致后续的redis请求在队列中阻塞不能执行。有时，在业务逻辑场景过于复杂的情况下，会将冗余的缓存数据查询到进程中，在业务逻辑代码中再找到需要用到的缓存数据，以此来减轻redis执行Lua的负担。
注意：
- 使用Lua时可以写一个公共方法将lua脚本压缩，以减少网络传输的时间
- 理论上redis的multi watch机制也可以提高redis的可用性，但是从事务的角度来讲，redis的事务不具有原子性，与传统数据库的事务有差别，而使用Lua的话，由于redis单线程，在执行lua时不能同时处理其他请求，可以保证原子性，所以不建议使用Multi。
- 注意Lua中的循环，一旦死循环，redis就挂了。
-
Redis作为缓存时，如何保证和数据库数据的一致性？
永远都不要执行redis中数据的修改操作，由于Java GC机制的存在，请求A先处理修改缓存数据，请求B在之后产生删除缓存数据，如果此时请求A的JVM正在GC，导致B请求先于A，这种情况就会导致redis和mysql数据的不一致，推荐做法是使用懒加载的方式初始化缓存，当某一条数据发生修改时，直接删除redis中的数据，待下次懒加载时将最新数据加载到redis中，同时建议使用redis的TTL机制，保证数据的最终一致性。
-
如何避免缓存穿透？
缓存穿透是由于后端存储中没有这条数据，然后又频繁从缓存中去查询该数据，但是由于缓存没有命中，请求就会穿透到数据库上，导致性能问题，解决方法是，在第一次发生缓存穿透时，在redis中存入一个特定的值，让redis感知到该条数据在后端存储中不存在，当后端存储新增该数据时，删除redis中的该特定值数据。
-
如何避免缓存雪崩？
缓存雪崩一般发生于redis实例掉电以后，由于业务并未中断，可能有大量的请求发生，这些大量的请求会同时去初始化缓存，导致JVM中对象的数量激增，从而导致OutofMemoryException，服务中断。避免的方式就是在所有初始化缓存的时候加一个redis锁，做double check。
注意：
- redis锁不是严格意义上的分布式锁，但是对于初始化缓存这种具有幂等性的任务来说，使用redis锁完全可以
- 注意double check模式的使用条件是JDK > 1.5
-
避免redis连接泄露的优秀实践
获取Jedis连接时，复写AutoClose接口，但是close方法不关闭连接，而是把连接返回连接池，同时在所有取连接的地方使用try-with-resources，以便从代码Review的层面避免连接泄露。
