在这篇文章中，边肖整理了如何做redis分布式的具体内容和知识点，有兴趣的朋友可以参考一下。
一 为什么使用 Redis
在项目中使用Redis时，有两个主要考虑因素：性能和并发性。如果只是为了分布式锁等其他功能，有Zookpeer等其他中间件代替，就没必要用Redis了。
性能：
如下图所示，当我们遇到执行时间长，结果变化不频繁的SQL时，特别适合缓存运行结果。通过这种方式，在缓存中读取下面的请求，以便请求可以快速响应。
尤其是秒杀系统，几乎同时所有人都在下单和下单。正在执行相同的操作mdashmdashmdash检查数据库中的数据。
根据不同的交互效果，响应时间没有固定的标准。理想状态下，我们的页面跳转需要瞬间解决，对于页内操作，需要瞬间解决。
并发性：
如下图所示，在大并发的情况下，所有请求都直接访问数据库，数据库会异常连接。这时候就需要用Redis做一个缓冲操作，让请求先访问Redis，而不是直接访问数据库。
关于使用Redis缓存和数据库双写一致性问题缓存雪崩问题缓存崩溃问题缓存并发竞争问题2为什么单线程的Redis那么快？
这个问题是对Redis内部机制的考察。很多人不知道Redis是单线程的工作模式。
主要原因有：纯内存操作，单线程操作，避免频繁的上下文切换，采用非阻塞I/O复用机制。
再来仔细说说I/O复用机制，比如：小明在A城开了一家快餐店，负责同城的快餐服务。小明因为资金有限，雇了一批送货员，然后小曲发现资金不够，只够买一辆车送快递。
经营方式一
每次有客户下单，小明就让一个送货员盯着，然后让人开车去送。慢慢的小曲在这种操作模式下发现了以下问题：
所有的时间都花在抢车上，大部分配送员都很闲，只有抢车的时候才能配送。
随着订单的增加，送货员越来越多。小明发现快递店越来越拥挤，没办法再雇新的配送员。送货人员之间的协调需要时间。基于以上不足，小明痛定思痛，提出了第二种经营模式。操作模式2
小明只雇了一个送货员。客户下单时，小明按照送货地点标注，依次放在一个地方。最后让配送员开车依次送过去，送完再回来取下一个。比较以上两种操作模式，很明显第二种模式效率更高。
在上面的比喻中：每个调度员rarr每个线程每个订单的Rarr每个Socket(I/O流)订单的交付地点是rarr客户送餐请求rarr在不同状态下的套接字；客户对名曲rarr管理模式的要求；服务器端运行的代码是car rarrCPU的核心数然后得出以下结论：第一种运行模式是传统的并发模式，每个I/O流(订单)由一个新线程(dispatcher)管理。第二种工作模式是I/O多路复用。只有一个线程(一个调度程序)通过跟踪每个I/O流的状态(每个调度程序的交付位置)来管理多个I/O流。
下面类比真实的Redis线程模型，如图所示：
Redis-client在运行时会生成不同事件类型的Socket。在服务器端，有一个I/O复用程序，它被放入队列中。然后，文件事件调度器依次从队列中取出，转发给不同的事件处理器。
三 Redis 的数据类型及使用场景
一个合格的程序员可以使用所有五种类型。
String
最常见的set/get操作，值可以是字符串或数字。一般缓存一些复杂的计数函数。
Hash
Value在这里存储结构化对象，操作其中一个字段比较方便。我做单点登录的时候用这个数据结构来存储用户信息，用CookieId作为Key，设置30分钟作为缓存过期时间，可以很好的模拟类似Session的效果。
List
利用List的数据结构，可以做一个简单的消息队列功能。另外可以使用lrange命令做基于Redis的分页功能，性能非常出色，用户体验也很好。
Set
因为集合被堆叠为不重复值的集合。因此，您可以执行全局重复数据消除功能。我们的系统一般部署在集群中，所以使用JVM自带的那一套很麻烦。此外，您可以通过使用交集、并集和差运算来计算公共首选项、所有首选项、您自己的独特首选项和其他函数。
Sorted Set
有序集合有一个权重参数得分，集合中的元素可以根据得分进行排列。可以做排行榜应用，拿TOP N操作。有序集合可以用来做延迟的任务。
四 Redis 的过期策略和内存淘汰机制
家里用不用Redis，由此可见一斑。比如你的Redis只能存储5G数据，但是你写10G，它就会删除5G数据。怎么会？你想过这个问题吗？
正解：Redis采用周期删除的懒删除策略。
为什么不定期删除保单？
定期删除，用定时器监控密钥，过期自动删除。虽然及时释放了内存，但是消耗了CPU资源。在大并发请求的情况下，CPU应该把时间用在处理请求上，而不是删除键，所以不采用这种策略。
周期性懒惰删除是如何工作的？
定期删除，Redis默认每100ms检查一次，删除过期密钥。需要注意的是，Redis并不是每100ms检查一次所有的键，而是随机选取进行检查。如果只采用周期删除策略，很多键是不会被时间删除的。所以，懒删就派上用场了。
定期删和懒删就没有其他问题吗？
不会，如果不定期删键的话。而且你没有及时索要Key，说明偷懒删除没有生效。这样Redis的内存就会越来越高。那么应该采用记忆消除机制。
redis.conf中有一行配置：
# maxmemory-策略可变-lru
这种配置与内存消除策略相匹配：noeviction:当内存不足以容纳新写入的数据时，新写入的操作会报错。AllKeys-lru:当内存不足以容纳新写入的数据时，在密钥空间中，删除最近最少使用的密钥。(推荐，这是目前在项目中使用的)(最近使用时间最长的算法)allKeys-random:当内存不足以容纳新写入的数据时，在密钥空间中，随机删除某个密钥。(应该也没人用。如果不删除最少使用的键，就随机删除。)volatile-lru:当内存不足以容纳新写入的数据时，从设置了到期时间的密钥空间中删除最近最少使用的密钥。在这种情况下，Redis通常同时用作缓存和持久存储。(不推荐)volatile-random:当内存不足以容纳新写入的数据时，从设置了到期时间的密钥空间中随机删除一个密钥。(仍然不推荐)volatile-ttl:当内存不足以容纳新写入的数据时，在设置了失效时间的密钥空间中，失效时间较早的密钥将首先被删除。(不推荐)五个Redis和数据库双写的一致性
一致性可以进一步分为最终一致性和强一致性。而且数据库和缓存写的一样，难免会有不一致的问题。前提是，如果对数据有很强的一致性要求，就不能缓存。我们所做的只能保证最终的一致性。
另外，从根本上说，我们所做的方案只能降低不一致的概率。所以一致性要求强的数据是无法缓存的。第一，采用正确的更新策略，先更新数据库，再删除缓存。其次，因为可能存在缓存删除失败的问题，所以提供一个补偿措施就足够了，比如使用消息队列。
六 如何应对缓存穿透和缓存雪崩问题
这两个问题是中小型传统软件企业的难题。如果有几百万左右流量的大并发项目，这两个问题一定要深入考虑。缓存穿透，即黑客故意请求缓存中不存在的数据，导致所有请求都指向数据库，数据库连接异常。
缓存穿透解决方案：当缓存失效时，先使用互斥锁获取锁，然后请求数据库。如果没被锁定，就睡一会儿再试。采用异步更新策略，不管键是否得到值，都会直接返回。值维护缓存过期时间。如果缓存过期，异步启动一个线程来读取数据库并更新缓存。您需要预热缓存(在项目开始之前加载缓存)。提供一种拦截机制，可以快速判断一个请求是否有效，例如使用Bloom filter在内部维护一系列有效的密钥。快速判断请求携带的密钥是否合法有效。如果不合法，直接退回。
缓存雪崩，即缓存同时大面积失效。这时又来了一波请求，结果所有的请求都到达了数据库，导致数据库连接异常。
缓存雪崩解决方案：给缓存过期时间添加一个随机值，以避免集体失效。使用了互斥锁，但是这种方案的吞吐量明显降低。双缓存。我们有两个缓存，缓存A和缓存B，缓存A的过期时间是20分钟，缓存B没有过期时间。自己做缓存预热操作。然后细分以下几点：从缓存A读取数据库，或者直接返回；A没有数据，直接从B读取数据，直接返回，异步启动一个更新线程，同时更新缓存A和缓存B。如何解决Redis的并发竞争关键问题
问题大致是有多个子系统同时设置一个密钥。这个时候要注意什么？大家基本都推荐使用Redis交易机制。
但不推荐Redis的交易机制。因为我们的生产环境基本是Redis集群环境，所以做了数据分片操作。当一个事务中涉及多个密钥操作时，这些密钥不一定都存储在同一个redis服务器上。所以Redis的交易机制很尴尬。
如果操作该键，不需要任何顺序。
这种情况下，准备一个分布式锁，抢锁，然后做集合操作，相对简单。
如果操作此键，则需要订单。
假设有key1，系统A需要将key1设置为valueA，系统B需要将key1设置为valueB，系统C需要将key1设置为valueC。
key1的值预计将按值a值b值c的顺序更改。这时，我们需要在数据写入数据库时保存一个时间戳。
假设时间戳如下：
一把钥匙1 {valueA 3:00}
b键1 {值B 3:05}
c键1 {valueC 3:10}
然后，假设系统B先抢锁，将key1设置为{valueB 3:05}。接下来，系统A抓取锁，发现其valueA的时间戳早于缓存中的时间戳，所以不做set操作，以此类推。其他方法，如使用队列，也可以将set方法更改为串行访问。
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。