【6. Redis缓存使用问题】
Redis缓存使用问题
数据一致性
工程实践
只要使用到缓存，无论是本地内存做缓存还是使用 redis 做缓存，那么就会存在数据同步的问题。
先读缓存数据，缓存数据有，则立即返回结果；如果没有数据，则从数据库读数据，并且把读到的数据同步到缓存里，提供下次读请求返回数据。
这样能有效减轻数据库压力，但是如果修改删除数据，因为配置信息缓存在内存中，而内存时无法感知到数据在数据库的修改。这样就会造成数据库中的数据与缓存中数据不一致的问题，那该如何解决呢？
有好几种解决方案，
-
先更新缓存，再更新数据库
-
先更新数据库，再更新缓存
-
先删除缓存，后更新数据库
-
先更新数据库，后删除缓存
更新缓存类
先更新缓存，再更新DB
这个方案我们一般不考虑。原因是更新缓存成功，更新数据库出现异常了，导致缓存数据与数据库数据完全不一致，而且很难察觉，因为缓存中的数据一直都存在。(数据库是旧值)
先更新DB，再更新缓存
这个方案也我们一般不考虑，原因跟第一个一样，数据库更新成功了，缓存更新失败，同样会出现数据不一致问题。(这个数据库是新值)
为什么实践中不是更新缓存而是后面要讲的删除缓存？
除了上面所说的，异常导致数据一致性很难察觉外，还有什么原因呢？
1）并发问题：(aba问题)
同时有请求A和请求B进行更新操作，那么会出现(aba问题)
（1*）线程A**更新了数据库*
（2*）线程B**更新了数据库*
（3*）线程B**更新了缓存*
（4*）线程A**更新了缓存*
先更新redis是同样的道理, 只不过是数据库是的是旧值
这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。这就导致了脏数据，因此不考虑。
2）业务场景问题(频繁写更新问题)
如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能。
其次很多时候，在复杂点的缓存场景，缓存不单单是数据库中直接取出来的值。
比如可能更新了某个表的一个字段，然后其对应的缓存，是需要查询另外两个表的数据并进行运算，才能计算出缓存最新的值的。
而且是不是说，每次修改数据库的时候，都一定要将其对应的缓存更新一份？也许有的场景是这样，但是对于比较复杂的缓存数据计算的场景，就不是这样了。如果你频繁修改一个缓存涉及的多个表，缓存也频繁更新。但是问题在于，这个缓存到底会不会被频繁访问到？
举个例子：一个缓存涉及的表的字段，在 1 分钟内就修改了 20 次，或者是 100 次，那么缓存更新 20 次、100 次；但是这个缓存在 1 分钟内只被读取了 1 次，有大量的冷数据。
实际上，如果你只是删除缓存的话，那么在 1 分钟内，这个缓存不过就重新计算一次而已，开销大幅度降低。用到缓存才去算缓存。
其实删除缓存，而不是更新缓存，就是一个 Lazy 计算的思想，不要每次都重新做复杂的计算，不管它会不会用到，而是让它到需要被使用的时候再重新计算。
说到底是选择更新缓存还是淘汰缓存呢，主要取决于“更新缓存的复杂度”，更新缓存的代价很小，此时我们应该更倾向于更新缓存，以保证更高的缓存命中率，更新缓存的代价很大，此时我们应该更倾向于淘汰缓存。但是淘汰缓存操作简单，并且带来的副作用只是增加了一次cache miss*，所以一般作为通用的处理方式。*
删除缓存类
先删除缓存，后更新DB
该方案也会出问题，具体出现的原因如下。
此时来了两个请求，请求 A（更新操作） 和请求 B（查询操作）
请求 A 会先删除 Redis 中的数据，然后准备去数据库进行更新操作；
此时请求 B 看到 Redis 中的数据时是空的，会去数据库中查询该值，把数据缓存到 Redis 中；
接着请求A更新事务提交
问题: 请求B去数据库查询得到的是旧值
那么这时候就会产生数据库和 Redis 数据不一致的问题。如何解决呢？其实最简单的解决办法就是延时双删的策略。就是
（1）先淘汰缓存
（2）再写数据库
（3）休眠1秒，再次淘汰缓存
这么做，可以将1秒内所造成的缓存脏数据，再次删除。
那么，这个1秒怎么确定的，具体该休眠多久呢？
针对上面的情形，自行评估自己的项目的读数据业务逻辑的耗时。然后写数据的休眠时间则在读数据业务逻辑的耗时基础上，加几百ms即可。这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。
但是上述的保证事务提交完以后再进行删除缓存还有一个问题，就是如果你使用的是 Mysql 的读写分离的架构的话，那么其实主从同步之间也会有时间差。
此时来了两个请求，请求 A（更新操作） 和请求 B（查询操作）
请求 A 更新操作，删除了 Redis，
请求主库进行更新操作，主库与从库进行同步数据的操作，
请 B 查询操作，发现 Redis 中没有数据，
去从库中拿去数据，此时同步数据还未完成，拿到的数据是旧数据。
此时的解决办法有两个：
1、还是使用双删延时策略。只是，睡眠时间修改为在主从同步的延时时间基础上，加几百ms。
2、就是如果是对 Redis 进行填充数据的查询数据库操作，那么就强制将其指向主库进行查询。
继续深入，采用这种同步淘汰策略，吞吐量降低怎么办？
那就将第二次删除作为异步的。自己起一个线程，异步删除。这样，写的请求就不用沉睡一段时间后了，再返回。这么做，加大吞吐量。
先更新DB，后删除缓存
这种方式，被称为Cache Aside Pattern，读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。更新的时候，先更新数据库，然后再删除缓存。
这种情况不存在并发问题么？
依然存在。假设这会有两个请求，一个请求A做查询操作，一个请求B做更新操作，那么会有如下情形产生
（1）缓存刚好失效(这时候没有数据删除,所以只有失效时候会出现这个问题)
（2）请求A查询数据库，得一个旧值
（3）请求B将新值写入数据库
（4）请求B删除缓存
（5）请求A将查到的旧值写入缓存
如果发生上述情况，确实是会发生脏数据。然而，发生这种情况的概率又有多少呢？
发生上述情况有一个先天性条件，就是步骤（3）的写数据库操作比步骤（2）的读数据库操作耗时更短，才有可能使得步骤（4）先于步骤（5）。可是，大家想想，数据库的读操作的速度远快于写操作的（不然做读写分离干嘛，做读写分离的意义就是因为读操作比较快，耗资源少），因此步骤（3）耗时比步骤（2）更短，这一情形很难出现。一定要解决怎么办？如何解决上述并发问题？
首先，给缓存设有效时间是一种方案。
其次，采用异步延时删除策略。
但是，更新数据库成功了，但是在删除缓存的阶段出错了没有删除成功怎么办？这个问题，在删除缓存类的方案都是存在的，那么此时再读取缓存的时候每次都是错误的数据了。
此时解决方案有两个，一是就是利用消息队列进行删除的补偿。具体的业务逻辑用语言描述如下：
1、请求 A 先对数据库进行更新操作
2、在对 Redis 进行删除操作的时候发现报错，删除失败
3、此时将Redis 的 key 作为消息体发送到消息队列中
4、系统接收到消息队列发送的消息后
5、再次对 Redis 进行删除操作
但是这个方案会有一个缺点就是会对业务代码造成大量的侵入，深深的耦合在一起，所以这时会有一个优化的方案，我们知道对 Mysql 数据库更新操作后再 binlog 日志中我们都能够找到相应的操作，那么我们可以订阅 Mysql 数据库的 binlog 日志对缓存进行操作。
订阅binlog程序在mysql中有现成的中间件叫canal，阿里开源的，用以完成订阅binlog日志的功能。
缓存出现不一致的情况总结:
总体上说都是aba导致问题, 更新时候的aba可以都是更新请求导致(abba), 但是删除缓存策略有点不同的是如果都是更新情况都会删除不会出现一致问题, 所以出现缓存不一致都是因为被缓存了, 而只有在缓存失效时候的查询会更新缓存,所以典型场景是
A先删除缓存
B查询缓存没有, 继续查询数据库
B更新缓存(缓存了旧值)
A更新数据库(数据库是新的值)
缓存失效, A请求查询数据库
B请求更新数据库(新值)
B请求删除缓存
A请求更新旧值到缓存(旧值)
缓存更新的设计模式
更新缓存的的设计模式主要有四种：Cache aside, Read through, Write through, Write behind caching
Cache Aside
这是最常用最常用的pattern了。上面已经讲过了，其具体逻辑如下：
失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
命中：应用程序从cache中取数据，取到后返回。
更新：先把数据存到数据库中，成功后，再让缓存失效。
这种模式下，没有先删除cache数据的操作了，而是先更新了数据库中的数据，此时，缓存依然有效，所以，并发的查询操作拿的是没有更新的数据，但是，更新操作马上让缓存的失效了，后续的查询操作再把数据从数据库中拉出来不会存在后续的查询操作一直都在取老的数据。
这是标准模式，包括Facebook的论文《Scaling Memcache at Facebook》也使用了这个策略。
**是不是Cache Aside这个就不会有并发问题了？**不是的，比如，一个是读操作，但是没有命中缓存，然后就到数据库中取数据，此时来了一个写操作，写完数据库后，让缓存失效，然后，之前的那个读操作再把老的数据放进去，所以，会造成脏数据。
但，这个case理论上会出现，不过，实际上出现的概率并不高，前面已经讲述过原因了。
缓存一致性，要么通过2PC或是Paxos协议保证一致性，要么就是拼命的降低并发时脏数据的概率，而Facebook使用了这个降低概率的玩法，因为2PC太慢，而Paxos太复杂。当然，最好还是为缓存设置上过期时间。
Read/Write Through
我们可以看到，在上面的Cache Aside套路中，我们的应用代码需要维护两个数据存储，一个是缓存（Cache），一个是数据库（Repository）。所以，应用程序比较啰嗦。而Read/Write Through套路是把更新数据库（Repository）的操作由缓存自己代理了，所以，对于应用层来说，就简单很多了。可以理解为，应用认为后端就是一个单一的存储，而存储自己维护自己的Cache。
Read Through
Read Through 套路就是在查询操作中更新缓存，也就是说，当缓存失效的时候（过期或LRU换出），Cache Aside是由调用方负责把数据加载入缓存，而Read Through则用缓存服务自己来加载，从而对应用方是透明的。
Write Through
Write Through 套路和Read Through相仿，不过是在更新数据时发生。当有数据更新的时候，如果没有命中缓存，直接更新数据库，然后返回。如果命中了缓存，则更新缓存，然后再由Cache自己更新数据库。
Write Behind Caching
Write Behind 又叫 Write Back。Linux文件系统的Page Cache也是同样算法。
Write Back套路，一句说就是，在更新数据的时候，只更新缓存，不更新数据库，而我们的缓存会异步地批量更新数据库。这个设计的好处就是让数据的I/O操作飞快无比，因为异步，write back还可以合并对同一个数据的多次操作，所以性能的提高是相当可观的。
但是，其带来的问题是，数据不是强一致性的，而且可能会丢失（我们知道Unix/Linux非正常关机会导致数据丢失，就是因为这个事）。
另外，Write Back实现逻辑比较复杂，因为他需要track有哪数据是被更新了的，需要刷到持久层上。
缓存穿透、击穿、雪崩
缓存穿透
是指查询一个根本不存在的数据，缓存层和存储层都不会命中，如果从存储层查不到数据则不写入缓存层。
缓存穿透将导致不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端存储的意义。
缓存穿透问题可能会使后端存储负载加大，由于很多后端存储不具备高并发性，甚至可能造成后端存储宕掉。通常可以在程序中分别统计总调用数、缓存层命中数、存储层命中数，如果发现大量存储层空命中，可能就是出现了缓存穿透问题。
造成缓存穿透的基本原因有两个。
第一，自身业务代码或者数据出现问题，比如，我们数据库的 id 都是1开始自增上去的，如发起为id值为 -1 的数据或 id 为特别大不存在的数据。如果不对参数做校验，数据库id都是大于0的，我一直用小于0的参数去请求你，每次都能绕开Redis直接打到数据库，数据库也查不到，每次都这样，并发高点就容易崩掉了。
第二，一些恶意攻击、爬虫等造成大量空命中。下面我们来看一下如何解决缓存穿透问题。
- 缓存空对象
当第2步存储层不命中后，仍然将空对象保留到缓存层中，之后再访问这个数据将会从缓存中获取,这样就保护了后端数据源。
缓存空对象会有两个问题:第一，空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间(如果是攻击，问题更严重),比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。第二，缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为5分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用前面所说的数据一致性方案处理。
- 布隆过滤器拦截
在访问缓存层和存储层之前,将存在的key用布隆过滤器提前保存起来,做第一层拦截。例如:一个推荐系统有4亿个用户id，每个小时算法工程师会根据每个用户之前历史行为计算出推荐数据放到存储层中,但是最新的用户由于没有历史行为,就会发生缓存穿透的行为,为此可以将所有推荐数据的用户做成布隆过滤器。如果布隆过滤器认为该用户id不存在,那么就不会访问存储层,在一定程度保护了存储层。
这种方法适用于数据命中不高、数据相对固定、实时性低(通常是数据集较大)的应用场景,代码维护较为复杂,但是缓存空间占用少。
缓存击穿
缓存击穿是指一个热点Key，大并发集中对这一个点进行访问，当这个Key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库。
缓存击穿的话，设置热点数据永远不过期。或者加上互斥锁就能搞定了。
使用互斥锁(mutex key)
业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。
伪代码：
public String get(key) {
String value = redis.get(key);
if (value == null) { //代表缓存值过期
//设置3min的超时，防止del操作失败的时候，下次缓存过期一直不能load db
if (redis.setnx(key_mutex, 1, 3 * 60) == 1) { //代表设置成功
value = db.get(key);
redis.set(key, value, expire_secs);
redis.del(key_mutex);
} else { //这个时候代表同时候的其他线程已经load db并回设到缓存了，这时候重试获取缓存值即可
sleep(50);
get(key); //重试: 递归
}
} else {
return value;
}
}
永远不过期
这里的“永远不过期”包含两层意思：
(1) 从redis上看，确实没有设置过期时间，这就保证了，不会出现热点key过期问题，也就是“物理”不过期。
(2) 从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期
从实战看，这种方法对于性能非常友好，唯一不足的就是构建缓存时候，其余线程(非构建缓存的线程)可能访问的是老数据，但是对于一般的互联网功能来说这个还是可以忍受。
缓存雪崩
缓存雪崩:由于缓存层承载着大量请求,有效地保护了存储层,但是如果缓存层由于某些原因不能提供服务，比如同一时间缓存数据大面积失效，那一瞬间Redis跟没有一样，于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会级联宕机的情况。缓存雪崩的英文原意是stampeding herd(奔逃的野牛)，指的是缓存层宕掉后，流量会像奔逃的野牛一样,打向后端存储。
预防和解决缓存雪崩问题,可以从以下三个方面进行着手。
1）保证缓存层服务高可用性。和飞机都有多个引擎一样，如果缓存层设计成高可用的,即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，例如前面介绍过的Redis
Sentinel和 Redis Cluster都实现了高可用。
2）依赖隔离组件为后端限流并降级。无论是缓存层还是存储层都会有出错的概率，可以将它们视同为资源。作为并发量较大的系统，假如有一个资源不可用，可能会造成线程全部阻塞(hang)在这个资源上，造成整个系统不可用。降级机制在高并发系统中是非常普遍的。
3）提前演练。在项目上线前，演练缓存层宕掉后，应用以及后端的负载情况以及可能出现的问题,在此基础上做一些预案设定。
4）将缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
缓存雪崩和缓存击穿的区别在于缓存击穿针对某一key缓存，缓存雪崩则是很多key。
热点Key
在Redis中，访问频率高的key称为热点key。
产生原因和危害
原因
热点问题产生的原因大致有以下两种：
用户消费的数据量远超预期（热卖商品、热点新闻、热点评论、明星直播）。
在日常工作生活中一些突发的事件，例如：双十一期间某些热门商品的降价促销，当这其中的某一件商品被数万次点击浏览或者购买时，会形成一个较大的需求量，这种情况下就会造成热点问题。同理，被大量刊发、浏览的热点新闻、热点评论、明星直播等，这些典型的读多写少的场景也会产生热点问题。
请求分片集中，超过单Server的性能极限。
在服务端读数据进行访问时，往往会对数据进行分片切分，此过程中会在某一主机Server上对相应的Key进行访问，当访问超过Server极限时，就会导致热点Key问题的产生。
危害
流量集中，达到物理网卡上限。
请求过多，缓存分片服务被打垮。
DB击穿，引起业务雪崩。
如前文讲到的，当某一热点Key的请求在某一主机上超过该主机网卡上限时，由于流量的过度集中，会导致服务器中其它服务无法进行。如果热点过于集中，热点Key的缓存过多，超过目前的缓存容量时，就会导致缓存分片服务被打垮现象的产生。当缓存服务崩溃后，此时再有请求产生，会缓存到后台DB上，由于DB本身性能较弱，在面临大请求时很容易发生请求穿透现象，会进一步导致雪崩现象，严重影响设备的性能。
发现热点key
预估发现
针对业务提前预估出访问频繁的热点key，例如秒杀商品业务中，秒杀的商品都是热点key。
当然并非所有的业务都容易预估出热点key，可能出现漏掉或者预估错误的情况。
客户端发现
客户端其实是距离key"最近"的地方，因为Redis命令就是从客户端发出的，以Jedis为例，可以在核心命令入口，使用这个Google Guava中的AtomicLongMap进行记录。
使用客户端进行热点key的统计非常容易实现，但是同时问题也非常多：
(1) 无法预知key的个数，存在内存泄露的危险。
(2) 对于客户端代码有侵入，各个语言的客户端都需要维护此逻辑，维护成本较高。
(3) 规模化汇总实现比较复杂。
代理端发现
客户端对于proxy的访问通常是均匀的，所以理论上只要在一个代理完成热点key的统计即可。但是这样做的不多。一方面并不是所有Redis架构都是proxy模式，另一方面在proxy层做二次开发也需要投入相应的人力和时间。
Redis发现
monitor命令
monitor命令可以监控到Redis执行的所有命令，利用monitor的结果就可以统计出一段时间内的热点key排行榜，命令排行榜，客户端分布等数据。Facebook开源的redis-faina正是利用上述原理使用Python语言实现的，例如下面获取最近10万条命令的热点key、热点命令、耗时分布等数据。为了减少网络开销以及加快输出缓冲区的消费速度，monitor尽可能在本机执行。
此种方法会有两个问题：
monitor命令在高并发条件下，会存在内存暴增和影响Redis性能的隐患，所以此种方法适合在短时间内使用。
只能统计一个Redis节点的热点key，对于Redis集群需要进行汇总统计。
–hotkeys
Redis在4.0.3中为redis-cli提供了–hotkeys，用于找到热点key。Redis 4.0提供了maxmemory policy LFU功能，可以为键值对象提供了LFU（Least Frequently Used）的属性，–hotkeys正是利用该属性完成对热点key的统计的，需要注意的是该选项必须配合maxmemory-policy的属性为LFU相关。
也可以自己扫描所有的key，使用object freq xx功能进行查看，–hotkeys在使用上有一些问题：
如果键值较多，执行较慢，和热点的概念的有点背道而驰
热度定义的不够准确。
抓取TCP包发现
Redis客户端使用TCP协议与服务端进行交互，通信协议采用的是RESP。如果站在机器的角度，可以通过对机器上所有Redis端口的TCP数据包进行抓取完成热点key的统计
此种方法对于Redis客户端和服务端来说毫无侵入，是比较完美的方案，但是依然存在3个问题：
(1) 需要一定的开发成本，但是一些开源方案实现了该功能，例如ELK(ElasticSearch Logstash Kibana)体系下的packetbeat插件，可以实现对Redis、MySQL等众多主流服务的数据包抓取、分析、报表展示
(2) 对于高流量的机器抓包，对机器网络可能会有干扰，同时抓包时候会有丢包的可能性。
(3) 维护成本过高。
解决热点key
发现热点key之后，需要对热点key进行处理。
使用二级缓存
可以使用 guava-cache或hcache，发现热点key之后，将这些热点key加载到JVM中作为本地缓存。访问这些key时直接从本地缓存获取即可，不会直接访问到redis层了，有效的保护了缓存服务器。
key分散
将热点key分散为多个子key，然后存储到缓存集群的不同机器上，这些子key对应的value都和热点key是一样的。当通过热点key去查询数据时，通过某种hash算法随机选择一个子key，然后再去访问缓存机器，将热点分散到了多个子key上。
BigKey
什么是bigkey
bigkey是指key对应的value所占的内存空间比较大，例如一个字符串类型的value可以最大存到512MB，一个列表类型的value最多可以存储23-1个元素。如果按照数据结构来细分的话，一般分为字符串类型bigkey和非字符串类型bigkey。
字符串类型:体现在单个value值很大，一般认为超过10KB就是bigkey，但这个值和具体的OPS相关。
非字符串类型:哈希、列表、集合、有序集合,体现在元素个数过多。
bigkey无论是空间复杂度和时间复杂度都不太友好，下面我们将介绍它的危害。
bigkey的危害
bigkey的危害体现在三个方面:
**内存空间不均匀(平衡)*例如在Redis Cluster中，bigkey 会造成节点的内存空间使用不均匀。
超时阻塞:由于Redis单线程的特性，操作bigkey比较耗时，也就意味着阻塞Redis可能性增大。
网络拥塞:每次获取bigkey产生的网络流量较大，假设一个bigkey为1MB，每秒访问量为1000，那么每秒产生1000MB 的流量,对于普通的千兆网卡(按照字节算是128MB/s)的服务器来说简直是灭顶之灾，而且一般服务器会采用单机多实例的方式来部署,也就是说一个bigkey可能会对其他实例造成影响,其后果不堪设想。
bigkey的存在并不是完全致命的,如果这个bigkey存在但是几乎不被访问,那么只有内存空间不均匀的问题存在,相对于另外两个问题没有那么重要紧急,但是如果bigkey是一个热点key(频繁访问)，那么其带来的危害不可想象,所以在实际开发和运维时一定要密切关注bigkey的存在。
发现bigkey
redis-cli --bigkeys可以命令统计bigkey的分布，但是在生产环境中，开发和运维人员更希望自己可以定义bigkey的大小，而且更希望找到真正的bigkey都有哪些,这样才可以去定位、解决、优化问题。判断一个key是否为bigkey，只需要执行debug object key查看serializedlength属性即可，它表示 key对应的value序列化之后的字节数。
如果键值个数比较多，scan + debug object会比较慢，可以利用Pipeline机制完成。对于元素个数较多的数据结构，debug object执行速度比较慢，存在阻塞Redis的可能，所以如果有从节点,可以考虑在从节点上执行。
解决bigkey
主要思路为拆分，对 big key 存储的数据 （big value）进行拆分，变成value1，value2… valueN等等。
例如big value 是个大json 通过 mset 的方式，将这个 key 的内容打散到各个实例中，或者一个hash，每个field代表一个具体属性，通过hget、hmget获取部分value，hset、hmset来更新部分属性。
例如big value 是个大list，可以拆成将list拆成。= list_1， list_2, list3, listN
其他数据类型同理。
数据倾斜
数据倾斜其实分为访问量倾斜或者数据量倾斜，hot key出现造成集群访问量倾斜，big key 造成集群数据量倾斜，所以解决方案前面已经说过了，这里不再赘述。
Redis脑裂
所谓的脑裂，就是指在保障可用性的主从集群中，同时产生了两个主节点，它们都能接收写请求。
而脑裂最直接的影响，就是客户端不知道应该往哪个主节点写入数据，结果就是不同的客户端会往不同的主节点上写入数据。而且，严重的话，脑裂会进一步导致数据丢失。
哨兵主从集群脑裂
现在假设：有三台服务器,一台主服务器，两台从服务器，还有哨兵机制。
基于上边的环境，这时候网络环境发生了波动导致了某个master所在机器突然脱离了正常的网络，但是实际上master还运行着，sentinel会以通过选举的方式提升了一个slave为新master。
如果恰好此时App Server1仍然连接的是旧的master，而App Server2连接到了新的master上。数据就不一致了，哨兵恢复对老master节点的感知后，会将其降级为slave节点，然后从新maste同步数据（full resynchronization），导致脑裂期间老master写入的数据丢失。(短暂的脑裂,但是还是可能出现问题)
通过配置如下参数来解决脑裂
min-replicas-to-write 1
min-replicas-max-lag 5
上面的参数表示要求至少有1个slave，数据复制和同步的延迟不能超过5秒。第一个参数表示最少的slave节点为1个，数据只有写入一个master结点并且也被同步到了至少1个从节点中，才说明这个数据添加成功。第二个参数表示数据复制和同步的延迟不能超过5秒。
配置了这两个参数，如果发生脑裂：原master会在客户端写入操作的时候拒绝请求。这样可以避免大量数据丢失。
集群脑裂
默认情况下，Redis集群的脑裂一般是不存在的，因为Redis集群中存在着过半选举机制，而且当集群16384个槽任何一个没有指派到节点时整个集群不可用。
所以我们在构建Redis集群时，应该让集群 Master 节点个数最少为 3 个，且集群可用节点个数为奇数。
非默认情况下，比如集群的个数为偶数个或者参数cluster-require-full-coverage设置为关闭（开启时只要有节点宕机导致 16384 个分片没被全覆盖，整个集群就拒绝服务），这种情况下依然有可能导致脑裂。那么解决的办法同样可以使用参数min-replicas-to-write和min-replicas-max-lag 。