1. 什么是CDN
内容分发网络（Content Delivery Network，CDN）是建立并覆盖在承载网上，由不同区域的服务器组
成的分布式网络。将源站资源缓存到全国各地的边缘服务器，利用全球调度系统使用户能够就近获取，
有效降低访问延迟，降低源站压力,提升服务可用性。
- 常见的CDN服务商
- 百度CDN：https://cloud.baidu.com/product/cdn.html
- 阿里CDN：https://www.aliyun.com/product/cdn?spm=5176.8269123.416540.50.728y8n
- 腾讯CDN：https://www.qcloud.com/product/cdn
- 腾讯云CDN收费介绍：https://cloud.tencent.com/document/product/228/2949
2. CDN的原理
用户请求CDN流程
假设您的业务源站域名为www.test.com，域名接入 CDN 开始使用加速服务后，当您的用户发起HTTP
请求时，实际的处理流程如下图所示：
- 详细说明如下：
- 1. 用户向www.test.com下的某图片资源（如：1.jpg）发起请求，会先向 Local DNS 发起域名解析请求。
- 2. 当 Local DNS 解析www.test.com时，会发现已经配置了CNAMEwww.test.com.cdn.dnsv1.com，解析请求会发送至 Tencent DNS（GSLB），GSLB 为腾讯云自主研发的调度体系，会为请求分配最佳节点 IP。
- 3. Local DNS 获取 Tencent DNS 返回的解析 IP。
- 4. 用户获取解析 IP。
- 5. 用户向获取的 IP 发起对资源 1.jpg 的访问请求。
- 6. 若该 IP 对应的节点缓存有 1.jpg，则会将数据直接返回给用户（10），此时请求结束。若该节点未缓存 1.jpg，则节点会向业务源站发起对 1.jpg 的请求（6、7、8），获取资源后，结合用户自定义配置的缓存策略，将资源缓存至节点（9），并返回给用户（10），此时请求结束。
3. CDN如何选择离用户最近的服务器提供服务
- BGP Anycast：CDN提供商将边缘节点的IP地址配置为BGP Anycast，通过BGP协议将同一个IP地址广播到多个数据中心。当用户请求到达时，网络路由器会根据最短路径原则将请求导向离用户最近的可用边缘节点。
- DNS负载均衡：CDN提供商使用DNS解析来将用户请求导向最接近用户的边缘节点。根据用户的IP地址，DNS服务器返回与其距离最近的可用节点的IP地址。这种方式通常基于地理位置和网络测量来选择最佳节点。
- 基于客户端IP地址：CDN服务可以根据用户请求中包含的客户端IP地址进行路由决策。通过查询客户端IP所属的地理位置或者网络信息，CDN可以选择就近的边缘节点来提供内容。
- 流量监测和分析：CDN提供商会实时监测网络流量情况，并收集相关数据。利用这些数据，他们可以确定哪些边缘节点能够更好地满足特定区域或特定时间段内用户对内容的需求，并相应地调整路由策略。
- 利用 302 实现转发请求重定向至最优服务器集群
- 因为中国网络较为复杂，依赖DNS就近解析的调度，仍然会存在部分请求调度失效、调度生效慢等问题。
- 比如:腾讯云利用在全国部署的302重定向服务器集群，能够为每一个请求实时决策最优的服务器资源，精准解决小运营商的调度问题，提升用户访问质量, 能最快地把用户引导到最优的服务器节点上，避开性能差或者异常的节点。
- 利用 302 实现转发请求重定向至最优服务器集群
总之，CDN通过使用路由技术结合地理位置和网络测量等信息，以及实时流量监测和分析来找到就近的边缘节点，从而提供更快速、高效的内容分发服务。
4. Redis内存淘汰机制
Redis内存淘汰机制主要包括以下几种类型：
- 全局淘汰：
- allkeys-lru：淘汰范围包括所有keys，按最久未使用（LRU）原则进行淘汰。
- allkeys-lfu：淘汰范围包括所有keys，按使用频次最少（LFU）原则进行淘汰。
- allkeys-random：淘汰范围包括所有keys，通过随机的方式进行淘汰。
- 淘汰expire时间：
- volatile-lru：淘汰范围包括所有设置了expire时间的keys，按最久未使用（LRU）原则进行淘汰。
- volatile-lfu：淘汰范围包括所有设置了expire时间的keys，按使用频次最少（LFU）原则进行淘汰。
- volatile-random：淘汰范围包括所有设置了expire时间的keys，通过随机的方式进行淘汰。
- volatile-ttl：淘汰范围包括所有设置了expire时间的keys，按剩余时间最少（TTL）原则进行淘汰。
- 不淘汰：
- noeviction：不进行淘汰，意味着当内存达到限制时，将无法存储新数据。
此外，Redis提供了多种配置选项来定制内存淘汰策略，这些策略可以结合使用以优化内存管理。例如，可以通过设置`maxmemory参数来限制Redis的最大内存使用量。
具体来说，Redis的内存淘汰机制旨在平衡内存使用效率和可用性，确保Redis能够处理不断增加的数据量和查询请求。当内存不足以容纳新的数据或旧的数据不再频繁使用时，Redis会根据配置的淘汰策略自动移除不需要的数据。
5. Redis数据持久化RDB与AOF
Redis 虽然是一个内存级别的缓存程序，也就是redis 是使用内存进行数据的缓存的，但是其可以将内存的数据按照一定的策略保存到硬盘上，从而实现数据持久保存的目的
目前redis支持两种不同方式的数据持久化保存机制，分别是RDB和AOF
RDB 模式
RDB 模式工作原理
RDB(Redis DataBase)：基于时间的快照，其默认只保留当前最新的一次快照，特点是执行速度比较快，缺点是可能会丢失从上次快照到当前时间点之间未做快照的数据
RDB bgsave 实现快照的具体过程
- Redis从master主进程先fork出一个子进程，使用写时复制机制，子进程将内存的数据保存为一个临时文件
- 当数据保存完成之后再将上一次保存的RDB文件替换掉，然后关闭子进程，这样可以保证每一次做RDB快照保存的数据都是完整的
- 因为直接替换RDB文件的时候,可能会出现突然断电等问题,而导致RDB文件还没有保存完整就因为突然关机停止保存,而导致数据丢失的情况.后续可以手动将每次生成的RDB文件进行备份，这样可以最大化保存历史数据
RDB 相关配置
save 900 1 #在900秒内有1个key内容发生更改,就执行快照机制
save 300 10 #在300秒内有10个key内容发生更改,就执行快照机制
save 60 10000 #60秒内如果有10000个key以上的变化，就自动快照备份
stop-writes-on-bgsave-error yes #默认为yes时,可能会因空间满等原因快照无法保存出错时，会禁止redis写入操作，生产建议为no #此项只针对配置文件中的自动save有效
rdbcompression yes #持久化到RDB文件时，是否压缩，"yes"为压缩，"no"则反之
rdbchecksum yes #是否对备份文件开启RC64校验，默认是开启
dbfilename dump.rdb #快照文件名
dir /var/lib/redis #快照文件保存路径，示例：dir "/apps/redis/data" #编译安装，默认RDB文件存放在启动redis的工作目录，建议明确指定存入目录 实现RDB方式
- save：同步，会阻塞其它命令，不推荐使用
- bgsave：异步后台执行,不影响其它命令的执行
- 自动: 制定规则,自动执行
- 1. 执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进 程，如RDB/AOF子进程，如果存在bgsave命令直接返回。
- 2. 父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通 过info stats命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒。
- 3. 父进程fork完成后，bgsave命令返回“Background saving started”信息 并不再阻塞父进程，可以继续响应其他命令。
- 4. 子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的 时间，对应info统计的rdb_last_save_time选项。
- 5. 进程发送信号给父进程表示完成，父进程更新统计信息，
RDB 模式优缺点
- RDB 模式优点
- RDB快照保存了某个时间点的数据，可以通过脚本执行redis指令bgsave(非阻塞，后台执行)或者save(会阻塞写操作,不推荐)命令自定义时间点备份，可以保留多个备份，当出现问题可以恢复到不同时间点的版本,很适合备份,并且此文件格式也支持有不少第三方工具可以进行后续的数据分析
- 比如: 可以在最近的24小时内，每小时备份一次RDB文件，并且在每个月的每一天，也备份一个ROB文件。这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。
- RDB可以最大化Redis的性能，父进程在保存 RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘工/0操作。
- RDB在大量数据,比如几个G的数据，恢复的速度比AOF的快
- RDB 模式缺点
- 不能实时保存数据，可能会丢失自上一次执行RDB备份到当前的内存数据
- 如果你需要尽量避免在服务器故障时丢失数据，那么RDB不适合你。虽然Redis允许你设置不同的保存点（save point）来控制保存RDB文件的频率，但是，因为RDB文件需要保存整个数据集的状态，所以它并不是一个轻松的操作。因此你可能会至少5分钟才保存一次RDB文件。在这种情况下，一旦发生故障停机，你就可能会丢失好几分钟的数据。
- 当数据量非常大的时候，从父进程fork子进程进行保存至RDB文件时需要一点时间，可能是毫秒或者秒，取决于磁盘IO性能
- 在数据集比较庞大时，fork()可能会非常耗时，造成服务器在一定时间内停止处理客户端﹔如果数据集非常巨大，并且CPU时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒或更久。虽然 AOF重写也需要进行fork()，但无论AOF重写的执行间隔有多长，数据的持久性都不会有任何损失。
AOF 模式
AOF 模式工作原理
- AOF：AppendOnylFile，按照操作顺序依次将操作追加到指定的日志文件末尾
- AOF 和 RDB 一样使用了写时复制机制，AOF默认为每秒钟 fsync一次，即将执行的命令保存到AOF文件当中，这样即使redis服务器发生故障的话最多只丢失1秒钟之内的数据，也可以设置不同的fsync策略always，即设置每次执行命令的时候执行fsync，fsync会在后台执行线程，所以主线程可以继续处理用户的正常请求而不受到写入AOF文件的I/O影响
- 同时启用RDB和AOF,进行恢复时,默认AOF文件优先级高于RDB文件,即会使用AOF文件进行恢复
- 注意: AOF 模式默认是关闭的,第一次开启AOF后,并重启服务生效后,会因为AOF的优先级高于RDB,而AOF第一次默认没有文件内容存在,从而导致所有数据丢失，因为启动时会去读数据文件，读AOF文件
AOF rewrite 重写
将一些重复的,可以合并的,过期的数据重新写入一个新的AOF文件,从而节约AOF备份占用的硬盘空间,也能加速恢复过程
可以手动执行bgrewriteaof 触发AOF,或定义自动rewrite 策略
AOF rewrite 过程
- 1.执行AOF重写请求。
- 2.父进程执行fork创建子进程，开销等同于bgsave过程。
- 3.1主进程fork操作完成后，继续响应其他命令。所有修改命令依然写 入AOF缓冲区并根据appendfsync策略同步到硬盘，保证原有AOF机制正确性。
- 3.2由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，Redis使用“AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。
- 4.子进程根据内存快照，按照命令合并规则写入到新的AOF文件。每次批量写入硬盘数据量由配置aofrewrite-incremental-fsync控制，默认为32MB，防止单次刷盘数据过多造成硬盘阻塞。
- 5.1新AOF文件写入完成后，子进程发送信号给父进程，父进程更新 统计信息，具体见info persistence下的aof_*相关统计。
- 5.2父进程把AOF重写缓冲区的数据写入到新的AOF文件。
- 5.3使用新AOF文件替换老文件，完成AOF重写。
AOF相关配置
appendonly yes #是否开启AOF日志记录，默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了，但是redis如果中途宕机，会导致可能有几分钟的数据丢失(取决于dump数据的间隔时间)，根据save来策略进行持久化，Append Only File是另一种持久化方式，可以提供更好的持久化特性，Redis会把每次写入的数据在接收后都写入appendonly.aof 文件，每次启动时Redis都会先这个文件的数据读入内存里，先忽略RDB文件。默认不启用此功能
appendfilename "appendonly-${port}.aof" #文本文件AOF的文件名，存放在dir指令指定的目录中
appendfsync everysec #aof持久化策略的配置
#no表示由操作系统保证数据同步到磁盘,Linux的默认fsync策略是30秒，最多会丢失30s的数据
#always表示每次写入都执行fsync，以保证数据同步到磁盘,安全性高,性能较差
#everysec表示每秒执行一次fsync，可能会导致丢失这1s数据,此为默认值,也生产建议值
#同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往
往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形,以下参数实现控制
dir /path #快照文件保存路径
no-appendfsync-on-rewrite yes #在aof rewrite期间,是否对aof新记录的append暂缓使用文件同步策略,主要考虑磁盘IO开支和请求阻塞时间。
#默认为no,表示"不暂缓",新的aof记录仍然会被立即同步到磁盘，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题
#为yes,相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样
并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。丢失多少数据
呢？Linux的默认fsync策略是30秒，最多会丢失30s的数据,但由于yes性能较好而且会避免出现阻塞
因此比较推荐
#rewrite 即对aof文件进行整理,将空闲空间回收,从而可以减少恢复数据时间
auto-aof-rewrite-percentage 100 #当Aof log增长超过指定百分比例时，重写AOF文件，设置
为0表示不自动重写Aof日志，重写是为了使aof体积保持最小，但是还可以确保保存最完整的数据
auto-aof-rewrite-min-size 64mb #触发aof rewrite的最小文件大小
aof-load-truncated yes #是否加载由于某些原因导致的末尾异常的AOF文件(主进程被kill/断电
等)，建议yesAOF 模式优缺点
- AOF 模式优点
- 数据安全性相对较高，根据所使用的fsync策略(fsync是同步内存中redis所有已经修改的文件到存储设备)，默认是appendfsync everysec，即每秒执行一次 fsync,在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据( fsync会在后台线程执行，所以主线程可以继续努力地处理命令请求)
- 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中不需要seek, 即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，可以通过 redis-check-aof 工具来解决数据一致性的问题
- Redis可以在 AOF文件体积变得过大时，自动地在后台对AOF进行重写,重写后的新AOF文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为Redis在创建新 AOF文件的过程中，append模式不断的将修改数据追加到现有的 AOF文件里面，即使重写过程中发生停机，现有的 AOF文件也不会丢失。而一旦新AOF文件创建完毕，Redis就会从旧AOF文件切换到新AOF文件，并开始对新AOF文件进行追加操作。
- AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，也可以通过该文件完成数据的重建。
- AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此 AOF文件的内容非常容易被人读懂，对文件进行分析(parse)也很轻松。导出（export)AOF文件也非常简单:举个例子，如果你不小心执行了FLUSHALL.命令，但只要AOF文件未被重写，那么只要停止服务器，移除 AOF文件末尾的FLUSHAL命令，并重启Redis ,就可以将数据集恢复到FLUSHALL执行之前的状态。
- AOF 模式缺点
- 即使有些操作是重复的也会全部记录，AOF 的文件大小要大于 RDB 格式的文件
- AOF 在恢复大数据集时的速度比 RDB 的恢复速度要慢
- 根据fsync策略不同,AOF速度可能会慢于RDB
- bug 出现的可能性更多
RDB和AOF 的选择
- 如果主要充当缓存功能,或者可以承受数分钟数据的丢失, 通常生产环境一般只需启用RDB即可,此也是默认值
- 如果数据需要持久保存,一点不能丢失,可以选择同时开启RDB和AOF,一般不建议只开启AOF
6. redis和MySQL的区别
一、.redis和mysql的区别总结
- （1）类型上
- 从类型上来说，mysql是关系型数据库，redis是缓存数据库
- （2）作用上
- mysql用于持久化的存储数据到硬盘，功能强大，但是速度较慢
- redis用于存储使用较为频繁的数据到缓存中，读取速度快
- （3）需求上
- mysql和redis因为需求的不同，一般都是配合使用。
二、详细说明
- 1.mysql和redis的数据库类型
- mysql是关系型数据库，主要用于存放持久化数据，将数据存储在硬盘中，读取速度较慢。
- redis是NOSQL，即非关系型数据库，也是缓存数据库，即将数据存储在缓存中，缓存的读取速度快，能够大大的提高运行效率，但是保存时间有限
- 2.mysql的运行机制
- mysql作为持久化存储的关系型数据库，相对薄弱的地方在于每次请求访问数据库时，都存在着I/O操作，如果反复频繁的访问数据库。第一：会在反复链接数据库上花费大量时间，从而导致运行效率过慢；第二：反复的访问数据库也会导致数据库的负载过高，那么此时缓存的概念就衍生了出来。
- 3.缓存
- 缓存就是数据交换的缓冲区（cache），当浏览器执行请求时，首先会对在缓存中进行查找，如果存在，就获取；否则就访问数据库。
- 缓存的好处就是读取速度快
- 4.redis数据库
- redis数据库就是一款缓存数据库，用于存储使用频繁的数据，这样减少访问数据库的次数，提高运行效率。