java多线程 注意事项_java多线程死锁 后端(Java)开发人员使用Redis时的注意事项...

后端开发人员在使用Redis时的注意事项，我们分为设计阶段和使用阶段来讲，先讲设计阶段。

设计阶段

1.缓存数据筛选

我们知道Redis是一个缓存，他的数据都是存放在内存中的，所以能够实现高效的存取和写入，但内存单位的高昂代价注定了其难以取代磁盘，作为数据的最终存储介质。使用缓存最重要的作用就是降低存储层的承受压力，提高请求的响应速度，所以如何选择数据很关键。注定了不能缓存所有数据，那么站在存储层的角度，自然优先缓存那些访问最频繁的数据，也就是所谓的热点数据，如何判断是否为热点数据需要根据实际的业务场景作相应的择取。站在应用的角度，自然是将那些响应时间长的数据做缓存，能够有效的提高用户的使用体验。站在缓存的角度上，自然是希望缓存那些更新不是很频繁的数据，否则频繁的缓存重建就失去了缓存的意义了。站在Redis的角度，自然是希望能够将自身优势发挥出来的，缓存那些数据量不是很大，但是很关键的数据，比如用户登录信息等，同时能够发挥自身特点，比如高速存储和写入，可以执行简单的算术操作，可以设置被动过期时间等。从多个方面考虑缓存数据的筛选问题，是设计阶段应该优先考虑的事情。

2.缓存粒度控制

粒度，就是缓存是数据的相对多少问题。粒度越大，操作时越简单，但占用空间越多，且缓存重建时需要的资源就越多；粒度越小，控制越复杂，但占用空间想小，且缓存重建时需要的资源就越少，这就是一个缓存性能，空间和操作的平衡问题。假设用户的信息由A,B,C三部分组成，每次获取的时候A和B用的较多，C用的不多，此时缓存的策略有4中情况：

1. A，B，C合并后缓存

2. A，B合并缓冲，C不作缓存

3. A，B，C各自分开缓存

4. A，B缓存，C不作缓存

每种缓存策略均有各自的优势及局限性，第一种情况下，从缓存提取简单，但占据空间大，且若A,B,C中的一个数据发生改变均需要重建整个缓存；第二种情况能降低占据空间，但是提高提取缓存的操作复杂性；第三种策略提取操作最复杂，占据空间大，但是重建缓存的性能最好；第四种能降低占据空间，但是提高了缓存重建的复杂性。

如何权衡缓存的粒度控制，需要根据实际业务提前设计好。

3.缓存更新策略

根据不同的业务场景指定不同的缓存更新策略。

一致性：缓存数据和真实数据源的数据一致。

对于低一致性要求的业务场景，可以配置Redis的最大内存配合淘汰策略作用。缓存淘汰策略可以使用LRU(Least Recently Used),LFU(Least Frequently Used)和FIFO(First In First Out)等。

对于高一致性要求的业务场景，可以使用Redis的超时剔除和主动更新策略。

4.缓存穿透优化

缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不会命中。通常处于容错的考虑，如果从存储层查询不到数据则不会写入缓存层。缓存穿透将导致请求不存在的数据每次都要到存储层去在找，就失去了缓存保护后端存储的意义。

造成缓存穿透的原因主要有两个：

1. 自身业务代码或者数据出现问题

2. 一些恶意攻击或爬虫造成大量空命中

对于缓存穿透，可以给不存在的数据缓存一个空对象，同时设置超时时间。如果在此期间缓存层和存储层的数据不一致，可使用消息系统或者其他操作剔除缓存中的空对象。

5.热点key重建

对于并发量较大的应用，当一个热点key重建时，可能会触发多个线程同时执行重建工作。多个线程同时重建，耗费额外性能生成资源，同时可能会有多次的缓存替换操作，对整体性能可能有一定影响。此时可以使用互斥锁机制，保证同一时间对于同一key只有一个线程能够执行重建工作。但是要注意，如果重建工作耗时较长，可能存在死锁和线程阻塞的风险。

本文来自电脑杂谈，转载请注明本文网址：

http://www.pc-fly.com/a/jisuanjixue/article-63783-1.html