怀揣梦想，一颗执着于技术的心从未磨灭，内心住着一颗顽强的小强时刻提醒自己层层突破自我，同时也成就他人

Redis自带的缓存淘汰策略包括noeviction、volatile-random、volatile-ttl、volatile-lru、volatile-lfu、allkeys-lru、allkeys-random和allkeys-lfu等。虽然Redis不支持直接自定义淘汰策略，但用户可以通过以下几种方式间接地实现类似的功能, 在应用层面，可以通过编程逻辑来控制哪些键应该被删除，从而间接地实现自定义淘汰策略。Redis的淘汰策略是由其内部实现和配置参数控制的，用户无法直接编写或插入自定义的淘汰策略。

Redis是一个键值存储系统，它支持多种数据结构，如字符串（strings）、哈希（hashes）、列表（lists）、集合（sets）、有序集合（sorted sets）等。MySQL是一个关系型数据库，它使用表（tables）来存储数据，表中的数据通过行（rows）和列（columns）进行组织，并支持复杂的SQL查询。然而，将Redis直接类比为MySQL这样的关系型数据库（RDBMS）并不完全准确，因为它们在数据模型、用途、性能和适用场景上存在一些重要的区别。

在连接Redis的客户端中，也需要提供正确的密码才能成功连接并进行操作。通过设置requirepass，可以有效地阻止这类攻击，因为攻击者需要知道正确的密码才能连接并进行操作。通过设置requirepass，可以确保只有授权的用户才能访问这些数据，从而有效地保护数据的安全性。requirepass增加了系统的安全性，通过要求客户端在连接时提供密码，可以有效地防止未经授权的访问和数据泄露。在Redis的配置中，requirepass是一个非常重要的配置项，它的主要作用是为了增强Redis服务器的安全性。

Redis 和 MongoDB 是两种不同类型的数据库系统，尽管 Redis 现在支持 JSON 数据类型（通过 RedisJSON 模块），但这并不意味着 MongoDB 没有存在的必要。尽管 Redis 现在支持 JSON 并提供了高性能的内存存储解决方案，但 MongoDB 因其持久化存储、复杂查询支持和大数据处理能力等特性，仍然在许多场景中发挥着不可替代的作用。Redis 支持多种数据结构，如字符串、列表、集合、哈希表等，以及现在通过 RedisJSON 支持的 JSON 数据类型。

对Redis和数据库进行详细的故障排查，找出导致故障的根本原因，并采取措施防止类似问题再次发生。立即启动数据库的备份恢复计划，如果可能，将数据库恢复到Redis故障之前的状态。实施限流策略，限制对数据库的并发请求数量，以防止过多的请求同时打到数据库上。如果数据库支持，可以启用数据库的读写分离，将读请求和写请求分散到不同的服务器上处理，以减轻单个服务器的压力。如果Redis短时间内无法恢复，可以考虑使用其他缓存解决方案，如Memcached，来临时替代Redis，以缓解数据库的压力。

Redis在读取和写入数据方面具有显著的速度优势，尤其适用于需要频繁访问数据的场景。而MySQL在面临大量并发读写请求时，可能需要通过更复杂的锁机制和并发控制来确保数据的一致性，这可能会降低其性能。通过将热点数据存储在Redis中，可以避免频繁访问MySQL数据库，从而降低数据库的负载和响应延迟。这种缓存机制在处理大量数据时尤为有效，可以显著提高系统的性能和稳定性。在数据量大的情况下，使用Redis而不是MySQL的原因主要涉及到Redis的内存存储、高并发读写能力、丰富的数据结构以及缓存机制等多个方面。

Session 是运行在一台服务器上的，所有的访问都会到达我们的唯一服务器上，这样我们可以根据客户端传来的 sessionID，来获取 session，或在对应 Session 不存在的情况下（session 生命周期到了/用户第一次登录），创建一个新的 Session；通过引入Redis依赖和Redis-session依赖，可以实现Spring Session与Redis的整合，从而在集群环境中共享session。即每次 session 发生变化时，创建或者修改，就广播给所有集群中的服务器，使。

内存被分成大小不等的 slabs chunks（先分成大小相等的 slabs，然后每个 slab 被分成大小相等 chunks，不同 slab 的 chunk 大小是不相等的）。然而，需要注意的是，虽然内存提供了快速的数据访问速度，但它也是易失的，即当服务器重启或内存被清空时，存储在Memcached中的数据将会丢失。需要注意的是，在处理大量数据时，批量导入导出可能会对系统性能产生一定的影响。因此，在执行这些操作时，建议根据系统的实际情况进行性能优化和监控，以确保操作的顺利进行并避免对系统造成过大的负担。

8、redis 内存管理： Redis 通过定义一个数组来记录所有的内存分配情况， Redis采用的是包装的 malloc/free，相较于 Memcached 的内存 管理方法来说，要简单很多。1、Redis 不仅仅支持简单的 k/v 类型的数据，同时还提供 list，set，zset，hash等数据结构的存储。Memcached 就像一个巨大的、存储了很多对的哈希表。2、Redis 支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用（PS：持久化在 rdb、aof）。

它的设计本身就不带有任何冗余机制。如果您通过 get 命令获取了一个 item，修改了它，然后想把它 set 回 memcached，我们不保证这个 item 没有被其他进程（process，未必是操作系统中的进程）操作过。所有的被发送到 memcached 的单个命令是完全原子的。如果另一个进程在这期间也修改了这个 item，那么该 item 存放在 memcached 中的唯一标识将会改变，您的写操作就会失败。如果该 item存放在 memcached 中的唯一标识与您提供的一致，您的写操作将会成功。

当客户端存取数据时，如果发现一个节点 down了，就再做一次哈希（哈希算法与前一次不同），重新选择另一个节点（需要注意的时，客户端并没有把 down 的节点从节点列表中移除，下次还是有可能先哈希到它）。如果某个节点时好时坏，两次哈希的方法就有风险了，好的节点和坏的节点上都可能存在脏数据（stale data）。不过，local cache 有一点比 memcached 和 query cache 都要好，那就是它不但可以存储任意的数据，而且没有网络存取的延迟。把失效的节点从节点列表中移除。

8、redis 内存管理： Redis 通过定义一个数组来记录所有的内存分配情况， Redis采用的是包装的 malloc/free，相较于 Memcached 的内存 管理方法来说，要简单很多。给数据库服务器增加更多的内存来缓存数据，固然是很好的。但是，有了 memcached，只要您有空闲的内存，都可以用来增加 memcached 集群的规 模，然后您就可以缓存更多的数据。1、Redis 不仅仅支持简单的 k/v 类型的数据，同时还提供 list，set，zset，hash等数据结构的存储。

您确实确实应该使用内建的 slab 分配器。反复地 malloc/free造成了内存碎片，OS 最终花费大量的时间去查找连续的内存块来满足 malloc 的请求，而不是运行 memcached 进程。memcached 内部对数据的操作是基于很多全局锁的（因此这部分工作不是多线程的）。未来对多线程模式的改进，将移除大量的全局锁，提高memcached 在负载极高的场景下的性能。因为内存被划分成大小不等的 slabs，如果 item 的大小与被选择存放它的 slab 不是很合适的话，就会浪费一些内存。

Slab Allocation 机制原理是按照预先规定的大小，将分配给 memcached 的内存分割成特定长度的内存块（chunk)，再把尺寸相同的内存块，分成组（chunks slab class),这些内存块不会释放，可以重复利用。早期的 Memcached 内存管理方式是通过 malloc 的分配的内存，使用完后通过free 来回收内存，这种方式容易产生内存碎片，并降低操作系统对内存的管理效率。数据访问，这种先放到内存，我们称之为预热，（先把数据存缓存中），用户访。a、完整缓存（易），静态缓存。

g、当内存中缓存的数据容量达到启动时设定的内存值时，就自动使用 LRU 算法。j、memcache 会对设定的内存进行分块，再把块分组，然后再提供服务。f、全部数据存放于内存中，无持久性存储的设计，重启服务器，内存里的数据会。h、可以对存储的数据设置过期时间，这样过期后的数据自动被清除，服务本身不。会监控过期，而是在访问的时候查看 key 的时间戳,判断是否过期。c、C/S 模式架构，C 语言编写，总共 2000 行代码。e、被缓存的数据以 key/value 键值对形式存在的。a、完全基于内存缓存的。

特殊说明：Memcached 集群和 web 服务集群是不一样的，所有 Memcached 的数据总和才是数据库的数据。每台 Memcached 都是部分数据。（一台 memcached 的数据，就是一部分 mysql 数据库的数据）程序加载所有 mc 的 ip 列表，通过对 key 做 hash (一致性哈希算法)一致哈希算法的目的是不但保证每个对象只请求一个对应的服务器，而且当节点。通过对 key 做 hash (一致性哈希算法)宕机，缓存服务器的更新重新分配比例降到最低。

幸运的是，随着Redis这些年的改进，很容易找到怎么恰当的使用Redis来缓存会话文档。这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的视角会比直接使用keys指令长。紧接着你需要抓一抓自己的脑袋，故作思考片段，好像接下来的结果是你主动思考出来的，然后回答：我记得set指令有非常复杂的参数，这个应该是可以同事把setnx和expire合成一个指令来用的，对方这时会显露笑容，心里开始默念：嗯，这小子还不错。

如果一个命令的结果导致大量内存被使用（例如很大的集合的交集保存到一个新的键），不用多久内存限制就会被这个内存使用量超越。Redis检查内存使用情况，如果大于maxMemory的限制，则根据设定好的策略进行回收。尽可能使用散列表（hashes），散列表（是说散列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。比如你的web系统中有个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key，而是应该把这个用户的所有信息存在到一张散列表里面。

Redis集群没有使用一致性hash，而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16验证后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。第一次同步时，主节点做一次bgsave，并同时将后续操作记录到内存buffer，待完成后将rdb文件全量同步到复制节点，复制节点接受完成后将rdb镜像加载到内存。有A,B,C三个节点的集群，在没有复制模型的情况下，如果节点B失败了，那么整个集群就会因为缺少了5501-11000这个范围的槽而不可用。

注意这里的6钟机制，volatile和allkeys规定了是对已设置过期时间的数据集淘汰数据还是从全部数据集淘汰数据，后面的lru,ttl以及random是三种不同的淘汰策略，再加上一种no-envication永不回收的策略。1.RDB（Redis DataBase）持久化方式：是指用数据集快照的方式半持久化，记录Redis数据库的所有键值对，在某个时间点将数据导入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。至于要删除多少过期键，以及要检查多少个数据库，则有算法决定。

6、broker要等待消费者真正确认消费到了消息时才删除掉消息，这里通常就是消费端ack机制，消费者接收到一条消息后，如果确认没有问题了，就可以发送一个ack，broker接收到ack后才会删除消息。2、首先要确保消息不多发，这个不常出现，也比较难控制，因为如果出现了多发，很大的原因是生产者自己的原因，如果要避免出现问题，就需要在消费端做控制。3、要避免不重复消费，最保险的机制就是消费者实现幂等性，保证就算重复消费，也不会有问题，通过幂等性，也能解决生产者重复发送消息的问题。

Kafka的生产者采用的是异步消息发送机制，当发送一条消息时，消息并没有发送到Broker而是缓存起来，然后直接想业务返回成功，当缓存的消息达到一定数量时再批量发送给Broker。1、pull表示消费者主动拉取，可以批量拉取，也可以单条拉取，所以pull可以由消费者自己控制，根据自己的消息处理能力来进行控制，但是消费者不能及时知道是否有消息，可能会拉到的消息是空的。2、Producer在发送消息的时候从NameServer获取Broker服务器地址，根据负载均衡算法选择一台服务器来发送消息。

2、先删除Redis缓存数据，再更新MySQL，再次查询的时候再将数据添加到缓存中，这种方案能解决1方案的问题，但是在高并发下性能较低，而且仍然会出现数据不一致的问题，比如线程1删除了Redis缓存数据，正在更新MySQL，此时另外一个线程查询再查询，那么就会把MySQL中老数据有查到Redis中。1、先更新MySQL，再更新Redis，如果更新Redis失败，可能数据不一致。

它的底层主要是先去初始化一个比较大的数组，里面存放的二进制0和1，在开始都是0，当一个key来了之后经过3次hash计算，模于数组长度找到数据的下标然后把数组中原来的0改为1，这样的话，三个数组的位置就能标明一个key的存在，查找的过程也是一样的。缺点是，布隆过滤器有可能产生一定的误判，我们一般设置一个误判率，大概不会超过5%，其实这个误判是必然存在的，要不就得增加数组的长度，5%以内的误判率一般的项目也能接受，不至于高并发下压倒数据库。1、Redis通常是做缓存或分布式锁的。

相对来说，考虑的比较完善的一套方案，分为事前，事中，事后三个层次去思考怎么来应对缓存雪崩的场景。

面临难题：对于每天上亿流量，拥有上亿页面的大型电商网站来说，能够支撑高并发访问，同时能够秒级让最新模板生效的商品详情页系统的架构是如何设计的？面临难题：如何解决高并发场景下，缓存冷启动导致MySQL负载过高，甚至瞬间被打死的问题？解决方案：基于hystrix的高可用缓存服务，资源隔离+限流+降级+熔断+超时控制。面临难题：如何解决高并发场景下的缓存穿透问题？面临难题：高并发场景下，如何解决数据库与缓存双写的时候数据不一致的情况？面临难题：如何解决高并发场景下，缓存重建时的分布式并发重建的冲突问题？

高可用(HA)是分布式系统架构设计中必须考虑的因素之一，它是通过架构设计减少系统不能提供服务的时间。单点是系统高可用的大敌，应该尽量在系统设计的过程中避免单点。通过架构设计而保证系统高可用的，其核心准则是：冗余。实现自动故障转移。sentinel(哨兵)是用于监控redis集群中Master状态的工具，其本身也是一个独立运行的进程，是Redis 的高可用解决方案，sentinel哨兵模式已经被集成在redis2.4之后的版本中。

假设先写数据库，再淘汰缓存：第一步写数据库操作成功，第二步淘汰缓存失败，则会出现DB 中是新数据，Cache 中是旧数据，数据不一致【如下图：db 中是新数据，cache 中是旧数据】假设先淘汰缓存，再写数据库：第一步淘汰缓存成功，第二步写数据库失败【如下图： cache中无数据，db 中是旧数据】。

mongodb 有几种部署方式，这里采用的是副本集架构（Replica Set）。为了防止单点故障就需要引副本（Replication），当发生硬件故障或者其它原因造成的宕机时，可以使用副本进行恢复，最好能够自动的故障转移（failover）。有时引入副本是为了读写分离，将读的请求分流到副本上，减轻主（Primary）的读压力。而 Mongodb 的 Replica Set 都能满足这些要求。Replica Set 的一堆 mongod 的实例集合，它们有着同样的数据内容。

什么是 kafka 呢，他是 LinkedIn 开发的一个分布式消息系统，用 scala 编写的，可以水平扩展和高吞吐率。原本开发自 LinkedIn，用作他们的活动流和运营数据处理管道的基础，之后被多家公司使用，慢慢发展壮大起来。kafka 是分布式的，基于发布/订阅的消息系统。1、 即使对 TB 级以上数据也能保证常数时间复杂度的访问性能。2、 高吞吐率：即使在非常廉价的商用机器上也能做到单机支持每秒 100k 条以上消息的传输。