1、列表问题

  举例：展示商品列表，但是要先展示运营置顶的数据，如果排序的序号一样，则按照id降序排序，就是需要按照sort asc, id desc 来排序；用redis怎么处理？

  【分析】

  首先这个问题可能本身有点问题，因为如果限定了redis，那么处理的方法就给限定死了，当时由于一股劲想着用redis处理，而忘了去想下redis是否适合处理这种问题；

  第二，讲下一开始是怎么用redis处理的：

  1）商品列表存储起来在有序集合，按照sort字段排序比如有序集合goods-by-sort中数据：

  商品id （member） ， value（score）

  1          1

  2          1  

  3          3

  4          2

  2）每当创建新商品，加入此队列，sort值是默认值；

  3）每当运营在管理后台修改sort值，则修改此有序集合中对应商品的score值；

  4）删除商品，或者设置不可见，则从这个有序集合中删掉该商品id的数据；

  5）用户获取商品列表时，因为需要按照sort和id排序，所以我当时再新增一个有序集合： goods_list_data，首先从goods_by_sort取出数据，在程序里面重新排序，然后写到goods_temp有序集合，然后rename为goods_list_data有序集合，然后给这个集合设置一个过期时间，比如2分钟。

  6）针对上面第2）到第4）步可能会对goods_by_sort有序集合的数据进行调整，比如修改、新增和删除，那么goods_list_data数据也需要更新，否则用户会一直看到被删除的商品。所以上面这三种情况，我会去更新一个string类型的refresh_goods_data 的key，每次去incr。用一个定时任务，每分钟一次去检查这个值，如果不为0，那么就去更新goods_list_data，然后设置refresh_goods_data的值为0,。否则则不处理，因为goods_list_data有序集合没改动。

  【上面这么做的问题】

  1）耦合很深，不好维护；搞了2个有序集合，还有定时任务；

  2）会有无底洞问题：有序集合存储的数据会越来越多，当然这个可以根据业务处理，比如裁剪，但是维护这个有序集合也是个问题，增删改都要做相应维护。

  【比较好的处理方法】

  1）还是回归到查询数据库，根据sort asc,id desc 排序来分页获取，但是基础数据就从redis中获取；这个要根据数据量，还有sql语句复杂度来评估，如果联表，或者是已经被告知数据库出现这个慢查询sql，那就肯定不能用这个方法。

  2）同事建议这种用sphinx来处理，有道理，不过还没尝试。

  2、redis防雪崩、防穿透、无底洞问题

  【分析和解决方法】

  防止雪崩问题的有效方法：

  1）不设置过期时间，只要数据实时更新到redis，那么给用户的数据就是实时的，不影响后端数据库；

  2）热数据和冷数据的区分，每天定时刷新热数据；

  防穿透问题：

  1）由于在redis中找不到数据，所以会去数据库读取，但是数据库也没有，所以不会写回缓存，导致并发访问时每次兜圈数据库读取；

  2）可以给这类数据写一个null或false到redis，设置一个过期时间，比如2分钟；

  3）要注意的是，这种key不能存储太长时间，key的量多起来，内存占用也会多的。

  无底洞问题：

  1）key如果不过期，那么会一直保存在内存，内存会越来越不够用；

  2）key如果过期，那么过期后，怎么处理，高并发访问数据，数据库会不会挂掉？网上有不少代码用setnx加锁方式，获取到锁的就去db查询然后写回redis，而其他的请求没有获取到锁，则等待一段时间（比如10毫秒）然后再去redis读取，取到就返回，取不到数据的话可以根据业务看要不要直接返回空结果，还是再去获取锁，直到读取到数据或者尝试的次数到达指定次数。

  3、刷缓存问题

  举例：由于是在一个老项目上做优化，之前是没有做redis缓存（严格来说还是有缓存，但是仅仅是把api接口的结果缓存起来设置个过期时间），所以新的优化上线后，如果访问旧的数据，缓存中没有，那么如果不刷数据，就会所有请求到缓存都是空命中，此时要么直接返回说没数据（用户体验非常差），或者去数据库查询，此时是类似雪崩的情况，并发访问数据库，数据库可能会挂掉，那么比较好的处理方式就是先把数据刷到缓存。这里该如何处理？

  【分析】

  1）根据业务，分析哪些数据需要提前刷新到缓存；

  2）增加锁机制，如果获取不到数据，则先去获取锁，获取到锁的则去db查询然后写回redis，db无数据则写null或false到redis并设置过期时间；

  3）根据数据库表中数据量和业务，分析是否可以先刷一部分数据。比如商品有1000万条数据，用户在网站首页可以分页慢慢地看1000万条数据，但是大部分用户可能只会看前面的几十页数据，比如一页20条数据，那么准备2000条最新数据或者热门数据即可。其他的商品，等待用户访问的时候，从redis获取，读取不到从db获取写回redis即可。

  4、商品之间根据标签进行关联，比如

  商品A： tag1， tag2 ，tag3

  商品B： tag2， tag4

  商品C： tag1， tag5

  商品D： tag4

  所以，商品A和商品B、商品C关联；商品B和商品D关联；商品C和商品A关联；商品D和商品B关联。

  每当要获取商品A关联的商品时，当然可以从db去获取A的标签，然后计算出管理的商品，那么如何用redis处理？

  【分析】

  如果非要用redis处理，那么就是需要提前把关系计算好，存放到集合/有序集合，那么一旦需要获取数据的时候，不需要再去计算，而是直接从缓存读出这些关联的id。

  1）新增商品时，会附带标签。计算关联的商品，是比较耗时的操作，可以放在队列，由后台脚本定时处理；

  2）删除商品时，也是需要放入队列，由后台脚本去处理；

  3）修改标签（给商品新增一个或多个标签、删除一个或多个标签和修改某些标签），也是需要放入队列，由后台脚本去处理；

  【上面这么做的问题】

  1）不好维护；增删改，都需要去维护这个有序集合。好处就是需要获取关联数据时直接从集合/有序集合获取id，基础信息也从redis获取；

  2）请教了同事，说用sphinx也可以处理，还没尝试。

  5、用redis能否解决mysql like 的问题

  答案自然是解决不了，只能用sphinx或es这些全文搜索系统。

  6、商品列表有个逻辑是，允许展示用户自己发布的商品（不论审核状态）+其他用户发布的商品（只能审核通过状态）的这些数据。当时用redis处理，搞了两个有序集合，一个是存储网站上所有审核通过的商品；第二个有序集合是存储用户自己发布的商品（不论审核状态）。当需要获取商品列表时，合并两个集合，然后分页取数据。

  【问题】

  并发情况下，合并有序集合的代价是很高的，可能造成阻塞；

  【解决方法】

  1）可以的话直接mysql查询。

  2）使用sphinx：又是同事的建议。

  总结：

  1、redis不是万能的，也有自己的优势和劣势；redis不适合处理sql这种关系型的业务；

  2、redis的性能是很好的，但是人为的操作，使用不当，可能造成阻塞；

  3、除了redis，还有其他的方法可以处理，不能限定死了。处理问题的时候，不仅要考虑能不能处理，还要考虑是否合理。