redis的知识点

 Redis内存数据库的内存指的是共享内存么？

Redis的持久化方式？

redis的知识点

Redis入门教程 参考 https://mp.weixin.qq.com/s/cBs5ZMLZmUxUqkyNmF8gaw

redis的面试问题 参考 https://mp.weixin.qq.com/s/qHzrFi1rxIXK5eukxZakuw

redis全称是什么?

Redis是由意大利人Salvatore Sanfilippo（网名：antirez）开发的一款内存高速缓存数据库。Redis全称为：Remote Dictionary Server（远程数据服务），该软件使用C语言编写，Redis是一个key-value存储系统，它支持丰富的数据类型，如：string、list、set、zset(sorted set)、hash。Redis是个中间件，用C语言写的，和Java没有关系的。

除了Java外还有很多语言可以操作它，比如Python。当然也可以把一个Python里的String存储到Redis里。

数据结构

redis里存的都是二进制数据，其实就是字节数组（byte[]），这些字节数据是没有数据类型的，只有把它们按照合理的格式解码后，可以变成一个字符串，整数或对象，此时才具有数据类型。

这一点必须要记住。所以任何东西只要能转化成字节数组（byte[]）的，都可以存到redis里。管你是字符串、数字、对象、图片、声音、视频、还是文件，只要变成byte数组。

• 关键字（Keys）是用于标识一段数据的一个字符串
• 值（Values）是一段任意的字节序列，Redis不会关注它们实质上是什么

关于key

• key不要太长，尽量不要超过1024字节，这不仅消耗内存，而且会降低查找的效率

• key也不要太短，太短的话，key的可读性会降低

• 在一个项目中，key最好使用统一的命名模式，例如user:10000:passwd

因此redis里的String指的并不是字符串，它其实表示的是一种最简单的数据结构，即一个key只能对应一个value。这里的key和value都是byte数组，只不过key一般是由一个字符串转换成的byte数组，value则根据实际需要而定。

在特定情况下，对value也会有一些要求，比如要进行自增或自减操作，那value对应的byte数组必须要能被解码成一个数字才行，否则会报错。

那么List这种数据结构，其实表示一个key可以对应多个value，且value之间是有先后顺序的，value值可以重复。

lists的常用操作包括LPUSH、RPUSH、LRANGE等。我们可以用LPUSH在lists的左侧插入一个新元素，用RPUSH在lists的右侧插入一个新元素，用LRANGE命令从lists中指定一个范围来提取元素。

lists的应用相当广泛，随便举几个例子：

• 我们可以利用lists来实现一个消息队列，而且可以确保先后顺序，不必像MySQL那样还需要通过ORDER BY来进行排序。

• 利用LRANGE还可以很方便的实现分页的功能。

• 在博客系统中，每片博文的评论也可以存入一个单独的list中。

Set这种数据结构，表示一个key可以对应多个value，且value之间是没有先后顺序的，value值也不可以重复。集合相关的操作也很丰富，如添加新元素、删除已有元素、取交集、取并集、取差集等.

Hash这种数据结构，表示一个key可以对应多个key-value对，此时这些key-value对之间的先后顺序一般意义不大，这是一个按照名称语义来访问的数据结构，而非位置语义。hashes存的是字符串和字符串值之间的映射，比如一个用户要存储其全名、姓氏、年龄等等，就很适合使用哈希
Sorted Set这种数据结构，表示一个key可以对应多个value，value之间是有大小排序的，value值不可以重复。每个value都和一个浮点数相关联，该浮点数叫score。元素排序规则是：先按score排序，再按value排序。很多时候，我们都将redis中的有序集合叫做zsets，这是因为在redis中，有序集合相关的操作指令都是以z开头的，比如zrange、zadd、zrevrange、zrangebyscore等等

Redis特点 : 

Redis以内存作为数据存储介质，所以读写数据的效率极高，远远超过数据库。以设置和获取一个256字节字符串为例，它的读取速度可高达110000次/s，写速度高达81000次/s。

Redis跟memcache不同的是，储存在Redis中的数据是持久化的，断电或重启后，数据也不会丢失。因为Redis的存储分为内存存储、磁盘存储和log文件三部分，重启后，Redis可以从磁盘重新将数据加载到内存中，这些可以通过配置文件对其进行配置，正因为这样，Redis才能实现持久化。

Redis支持主从模式，可以配置集群，这样更利于支撑起大型的项目，这也是Redis的一大亮点。

由于INCR等指令本身就具有原子操作的特性，所以我们完全可以利用redis的INCR、INCRBY、DECR、DECRBY等指令来实现原子计数的效果，假如，在某种场景下有3个客户端同时读取了mynum的值（值为2），然后对其同时进行了加1的操作，那么，最后mynum的值一定是5。不少网站都利用redis的这个特性来实现业务上的统计计数需求。

Redis支持事务吗？

支持 , 表现为多条命令，要么都执行，要么都不执行。

redis的事务可以分为两步，定义事务和执行事务。使用multi命令开启一个事务，然后把要执行的所有命令都依次排上去。这就定义好了一个事务。此时使用exec命令来执行这个事务，或使用discard命令来放弃这个事务。
你可能希望在你的事务开始前，你关心的key不想被别人操作，那么可以使用watch命令来监视这些key，如果开始执行前这些key被其它命令操作了则会取消事务的。也可以使用unwatch命令来取消对这些key的监视。

redis事务具有以下特点：
1、如果开始执行事务前出错，则所有命令都不执行
2、一旦开始，则保证所有命令一次性按顺序执行完而不被打断
3、如果执行过程中遇到错误，会继续执行下去，不会停止的
4、对于执行过程中遇到错误，是不会进行回滚的
很显然，这并不是我们通常认为的事务，因为它连原子性都保证不了。保证不了原子性是因为redis不支持回滚，不过它也给出了不支持的理由。
不支持回滚的理由：
1、redis认为，失败都是由命令使用不当造成
2、redis这样做，是为了保持内部实现简单快速
3、redis还认为，回滚并不能解决所有问题
因此 , 使用redis事务的不太多

管道  : 客户端和集群的交互过程是串行化阻塞式的，即客户端发送了一个命令后必须等到响应回来后才能发第二个命令，这一来一回就是一个往返时间。如果你有很多的命令，都这样一个一个的来进行，会变得很慢。
redis提供了一种管道技术，可以让客户端一次发送多个命令，期间不需要等待服务器端的响应，等所有的命令都发完了，再依次接收这些命令的全部响应。这就极大地节省了许多时间，提升了效率。
聪明的你是不是意识到了另外一个问题，多个命令就是多个key啊，这不就是上面提到的多key操作嘛，那么问题来了，你如何保证这多个key都是同一个节点上的啊，redis集群又放弃了对管道的支持。
不过可以在客户端模拟实现，就是使用多个连接往多个节点同时发送命令，然后等待所有的节点都返回了响应，再把它们按照发送命令的顺序整理好，返回给用户代码。

协议  :简单了解下redis的协议，知道redis的数据传输格式。
发送请求的协议：
*参数个数CRLF$参数1的字节数CRLF参数1的数据CRLF...$参数N的字节数CRLF参数N的数据CRLF
例如，SET name lixinjie，实际发送的数据是：

*3\r\n$3\r\nSET\r\n$4\r\nname\r\n$8\r\nlixinjie\r\n
接受响应的协议：
单行回复，第一个字节是+

错误消息，第一个字节是-

整型数字，第一个字节是:

批量回复，第一个字节是$

多个批量回复，第一个字节是*
例如，

+OK\r\n

-ERR Operation against\r\n

:1000\r\n

$6\r\nfoobar\r\n

*2\r\n$3\r\nfoo\r\n$3\r\nbar\r\n
可见redis的协议设计的非常简单。

如果Redis是单节点，向它发送命令总能获取到数据。如果Redis是集群，会有很多节点，如果向A节点发送命令，发现数据不在A上而在B节点上，此时会怎么样？（Redis是如何处理数据不在本节点这样情况的呢？）

redis集群的相关问题

集群带来的问题与解决思路  参考 https://mp.weixin.qq.com/s/BZd41DY8WdSNDnnvyJJf2g
集群带来的好处是显而易见的，比如容量增加、处理能力增强，还可以按需要进行动态的扩容、缩容。但同时也会引入一些新的问题，至少会有下面这两个。
一是数据分配：存数据时应该放到哪个节点上，取数据时应该去哪个节点上找。二是数据移动：集群扩容，新增加节点时，该节点上的数据从何处来；集群缩容，要剔除节点时，该节点上的数据往何处去。
上面这两个问题有一个共同点就是，如何去描述和存储数据与节点的映射关系。又因为数据的位置是由key决定的，所以问题就演变为如何建立起各个key和集群所有节点的关联关系?
集群的节点是相对固定和少数的，虽然有增加节点和剔除节点。但集群里存储的key，则是完全随机、没有规律、不可预测、数量庞多，还非常琐碎。这就好比一所大学和它的所有学生之间的关系。如果大学和学生直接挂钩的话，一定会比较混乱。现实是它们之间又加入了好几层，首先有院系，其次有专业，再者有年级，最后还有班级。经过这四层映射之后，关系就清爽很多了。这其实是一个非常重要的结论，这个世界上没有什么问题是不能通过加入一层来解决的。如果有，那就再加入一层。计算机里也是这样的。
redis在数据和节点之间又加入了一层，把这层称为槽（slot），因该槽主要和哈希有关，又叫哈希槽。最后变成了，节点上放的是槽，槽里放的是数据。槽解决的是粒度问题，相当于把粒度变大了，这样便于数据移动。哈希解决的是映射问题，使用key的哈希值来计算所在的槽，便于数据分配。可以这样来理解，你的学习桌子上堆满了书，乱的很，想找到某本书非常困难。于是你买了几个大的收纳箱，把这些书按照书名的长度放入不同的收纳箱，然后把这些收纳箱放到桌子上。这样就变成了，桌子上是收纳箱，收纳箱里是书籍。这样书籍移动很方便，搬起一个箱子就走了。寻找书籍也很方便，只要数一数书名的长度，去对应的箱子里找就行了。其实我们也没做什么，只是买了几个箱子，按照某种规则把书装入箱子。就这么简单的举动，就彻底改变了原来一盘散沙的状况。是不是有点小小的神奇呢。
一个集群只能有16384个槽，编号0-16383。这些槽会分配给集群中的所有主节点，分配策略没有要求。可以指定哪些编号的槽分配给哪个主节点。集群会记录节点和槽的对应关系。接下来就需要对key求哈希值，然后对16384取余，余数是几key就落入对应的槽里。slot = CRC16(key) % 16384。以槽为单位移动数据，因为槽的数目是固定的，处理起来比较容易，这样数据移动问题就解决了。使用哈希函数计算出key的哈希值，这样就可以算出它对应的槽，然后利用集群存储的槽和节点的映射关系查询出槽所在的节点，于是数据和节点就映射起来了，这样数据分配问题就解决了。我想说的是，一般的人只会去学习各种技术，高手更在乎如何跳出技术，寻求一种解决方案或思路方向，顺着这个方向走下去，八九不离十能找到你想要的答案。

集群对命令操作的取舍

客户端只要和集群中的一个节点建立链接后，就可以获取到整个集群的所有节点信息。此外还会获取所有哈希槽和节点的对应关系信息，这些信息数据都会在客户端缓存起来，因为这些信息相当有用。客户端可以向任何节点发送请求，那么拿到一个key后到底该向哪个节点发请求呢？其实就是把集群里的那套key和节点的映射关系理论搬到客户端来就行了。
所以客户端需要实现一个和集群端一样的哈希函数，先计算出key的哈希值，然后再对16384取余，这样就找到了该key对应的哈希槽，利用客户端缓存的槽和节点的对应关系信息，就可以找到该key对应的节点了。接下来发送请求就可以了。还可以把key和节点的映射关系缓存起来，下次再请求该key时，直接就拿到了它对应的节点，不用再计算一遍了。理论和现实总是有差距的，集群已经发生了变化，客户端的缓存还没来得及更新。肯定会出现拿到一个key向对应的节点发请求，其实这个key已经不在那个节点上了。此时这个节点应该怎么办？
这个节点可以去key实际所在的节点上拿到数据再返回给客户端，也可以直接告诉客户端key已经不在我这里了，同时附上key现在所在的节点信息，让客户端再去请求一次，类似于HTTP的302重定向。这其实是个选择问题，也是个哲学问题。结果就是redis集群选择了后者。因此，节点只处理自己拥有的key，对于不拥有的key将返回重定向错误，即-MOVED key 127.0.0.1:6381，客户端重新向这个新节点发送请求。所以说选择是一种哲学，也是个智慧。稍后再谈这个问题。先来看看另一个情况，和这个问题有些相同点。redis有一种命令可以一次带多个key，如MGET，我把这些称为多key命令。这个多key命令的请求被发送到一个节点上，这里有一个潜在的问题，不知道大家有没有想到，就是这个命令里的多个key一定都位于那同一个节点上吗？
就分为两种情况了，如果多个key不在同一个节点上，此时节点只能返回重定向错误了，但是多个key完全可能位于多个不同的节点上，此时返回的重定向错误就会非常乱，所以redis集群选择不支持此种情况。如果多个key位于同一个节点上呢，理论上是没有问题的，redis集群是否支持就和redis的版本有关系了，具体使用时自己测试一下就行了。
在这个过程中我们发现了一件颇有意义的事情，就是让一组相关的key映射到同一个节点上是非常有必要的，这样可以提高效率，通过多key命令一次获取多个值。
那么问题来了，如何给这些key起名字才能让他们落到同一个节点上，难不成都要先计算个哈希值，再取个余数，太麻烦了吧。当然不是这样了，redis已经帮我们想好了。可以来简单推理下，要想让两个key位于同一个节点上，它们的哈希值必须要一样。要想哈希值一样，传入哈希函数的字符串必须一样。那我们只能传进去两个一模一样的字符串了，那不就变成同一个key了，后面的会覆盖前面的数据。这里的问题是我们都是拿整个key去计算哈希值，这就导致key和参与计算哈希值的字符串耦合了，需要将它们解耦才行，就是key和参与计算哈希值的字符串有关但是又不一样。
redis基于这个原理为我们提供了方案，叫做key哈希标签。先看例子，{user1000}.following，{user1000}.followers，相信你已经看出了门道，就是仅使用Key中的位于{和}间的字符串参与计算哈希值。这样可以保证哈希值相同，落到相同的节点上。但是key又是不同的，不会互相覆盖。使用哈希标签把一组相关的key关联了起来，问题就这样被轻松愉快地解决了。
相信你已经发现了，要解决问题靠的是巧妙的奇思妙想，而不是非要用牛逼的技术牛逼的算法。这就是小强，小而强大。
最后再来谈选择的哲学。redis的核心就是以最快的速度进行常用数据结构的key/value存取，以及围绕这些数据结构的运算。对于与核心无关的或会拖累核心的都选择弱化处理或不处理，这样做是为了保证核心的简单、快速和稳定。
其实就是在广度和深度面前，redis选择了深度。所以节点不去处理自己不拥有的key，集群不去支持多key命令。这样一方面可以快速地响应客户端，另一方面可以避免在集群内部有大量的数据传输与合并。

 

redis的过期策略如何实现？

参考 https://mp.weixin.qq.com/s/E60I9RLLT1lw3ZxCH0IPVA （LRU源码）

使用redis的原因 : 

Redis是一个分布式NoSQL数据库，因其数据都存储在内存中，所以访问速度极快，因此几乎所有公司都拿它做缓存使用，所以Redis常被称为分布式缓存。使用了多路复用，一个线程可以处理多个请求。redis是单线程的，mysql是多线程的 ，redis无锁机制，不会争抢资源；

为什么要使用过期策略 : 

因为redis是基于内存来进行高性能、高并发的读写操作的，既然是内存，那肯定有空间的限制，如果只有10g内存，一直往里面写数据，那肯定不行，所以采用一些过期策略把不需要的数据删除、或者是淘汰掉。

有哪些过期策略？

我了解的有 定期删除、惰性删除两种

• 惰性删除：每次从键空间中获取键时，都检查取得的键是否过期，如果过期的话，就删除该键；如果没有过期，就返回该键。

• 定期删除：每隔一段时间，程序就对数据库进行一次检查，删除里面的过期键。

定期删除怎么实现？

所谓定期删除，指的是 redis 默认是每隔 100ms 就随机抽取一些设置了过期时间的 key，检查其是否过期，如果过期就删除。

为什么是随机抽取？

假如在redis 里插入10w个key，并且都设置了过期时间，如果每次都检查所有key，那cpu基本上都消耗在过期key的检查上了，redis对外的性能也会大大降低，简直就是一场灾难。

随机检查会存在什么问题？

可能导致本已经过期的key没有被扫描到，而继续留在内存中，并占用空间，等待被删除。

这种情况怎么解决？

这时候就需要第二种过期策略了，惰性删除，就是在获取某个 key 的时候，redis 会检查一下 ，如果这个 key 设置了过期时间，并且已经过期了，那么就直接删除，返回空。

那再考虑一种情况，如果大量的key没有被扫描到，且已过期，也没有被再次访问，即没有走惰性删除，这些大量过期 key 堆积在内存里，导致 redis 内存块耗尽了，这种情况下，怎么办？

redis内部提供了内存淘汰机制，应该有好几种策略，但我只知道LRU算法。Redis可以开启LRU功能来自动淘汰一些键值对。

参考 https://mp.weixin.qq.com/s/g4KguF7BYv72xW8w-pijXg

那你手写一个LRU算法？ 

class 
LRUCache<K, V> extends LinkedHashMap<K, V> {    
private final int CACHE_SIZE;     
/* 
@param cacheSize 缓存大小     
*/
    // true 表示让 linkedHashMap 按照访问顺序来进行排序，最近访问的放在头部，最老访问的放在尾部。    
public LRUCache(int cacheSize) {        
super((int) Math.ceil(cacheSize / 0.75) + 1, 0.75f, true);
        CACHE_SIZE = cacheSize;    
}
    
@Override     
// 当 map中的数据量大于指定的缓存个数的时候，就自动删除最老的数据。    
protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {        
return size() 
> CACHE_SIZE;    
}
}

LRU配置参数

Redis配置中和LRU有关的有三个：

• maxmemory: 配置Redis存储数据时指定限制的内存大小，比如100m。当缓存消耗的内存超过这个数值时, 将触发数据淘汰。该数据配置为0时，表示缓存的数据量没有限制, 即LRU功能不生效。64位的系统默认值为0，32位的系统默认内存限制为3GB

• maxmemory_policy: 触发数据淘汰后的淘汰策略

• maxmemory_samples: 随机采样的精度，也就是随即取出key的数目。该数值配置越大, 越接近于真实的LRU算法，但是数值越大，相应消耗也变高，对性能有一定影响，样本值默认为5。

淘汰策略

淘汰策略即maxmemory_policy的赋值有以下几种：

• noeviction:如果缓存数据超过了maxmemory限定值，并且客户端正在执行的命令(大部分的写入指令，但DEL和几个指令例外)会导致内存分配，则向客户端返回错误响应

• allkeys-lru: 对所有的键都采取LRU淘汰

• volatile-lru: 仅对设置了过期时间的键采取LRU淘汰

• allkeys-random: 随机回收所有的键

• volatile-random: 随机回收设置过期时间的键

• volatile-ttl: 仅淘汰设置了过期时间的键---淘汰生存时间TTL(Time To Live)更小的键

volatile-lru, volatile-random和volatile-ttl这三个淘汰策略使用的不是全量数据，有可能无法淘汰出足够的内存空间。在没有过期键或者没有设置超时属性的键的情况下，这三种策略和noeviction差不多。

一般的经验规则:

• 使用allkeys-lru策略：当预期请求符合一个幂次分布(二八法则等)，比如一部分的子集元素比其它其它元素被访问的更多时，可以选择这个策略。

• 使用allkeys-random：循环连续的访问所有的键时，或者预期请求分布平均（所有元素被访问的概率都差不多）

• 使用volatile-ttl：要采取这个策略，缓存对象的TTL值最好有差异

volatile-lru 和 volatile-random策略，当你想要使用单一的Redis实例来同时实现缓存淘汰和持久化一些经常使用的键集合时很有用。未设置过期时间的键进行持久化保存，设置了过期时间的键参与缓存淘汰。不过一般运行两个实例是解决这个问题的更好方法。

为键设置过期时间也是需要消耗内存的，所以使用allkeys-lru这种策略更加节省空间，因为这种策略下可以不为键设置过期时间。

近似LRU算法

我们知道，LRU算法需要一个双向链表来记录数据的最近被访问顺序，但是出于节省内存的考虑，Redis的LRU算法并非完整的实现。Redis并不会选择最久未被访问的键进行回收，相反它会尝试运行一个近似LRU的算法，通过对少量键进行取样，然后回收其中的最久未被访问的键。通过调整每次回收时的采样数量maxmemory-samples，可以实现调整算法的精度。

根据Redis作者的说法，每个Redis Object可以挤出24 bits的空间，但24 bits是不够存储两个指针的，而存储一个低位时间戳是足够的，Redis Object以秒为单位存储了对象新建或者更新时的unix time，也就是LRU clock，24 bits数据要溢出的话需要194天，而缓存的数据更新非常频繁，已经足够了。

Redis的键空间是放在一个哈希表中的，要从所有的键中选出一个最久未被访问的键，需要另外一个数据结构存储这些源信息，这显然不划算。最初，Redis只是随机的选3个key，然后从中淘汰，后来算法改进到了N个key的策略，默认是5个。

Redis3.0之后又改善了算法的性能，会提供一个待淘汰候选key的pool，里面默认有16个key，按照空闲时间排好序。更新时从Redis键空间随机选择N个key，分别计算它们的空闲时间idle，key只会在pool不满或者空闲时间大于pool里最小的时，才会进入pool，然后从pool中选择空闲时间最大的key淘汰掉。

在模拟实验的过程中，我们发现如果使用幂次分布的访问模式，真实LRU算法和近似LRU算法几乎没有差别。

【复杂，参考文章中有源码分析】

 

Redis 如何保持和MySQL数据一致

1.MySQL持久化数据，Redis只读数据

redis在启动之后，从数据库加载数据。

读请求：

不要求强一致性的读请求，走redis，要求强一致性的直接从mysql读取

写请求：

数据首先都写到数据库，之后更新redis（先写redis再写mysql，如果写入失败事务回滚会造成redis中存在脏数据）

2.MySQL和Redis处理不同的数据类型

• MySQL处理实时性数据，例如金融数据、交易数据

• Redis处理实时性要求不高的数据，例如网站最热贴排行榜，好友列表等

 

在并发不高的情况下，读操作优先读取redis，不存在的话就去访问MySQL，并把读到的数据写回Redis中；写操作的话，直接写MySQL，成功后再写入Redis(可以在MySQL端定义CRUD触发器，在触发CRUD操作后写数据到Redis，也可以在Redis端解析binlog，再做相应的操作)

 CRUD是指在做计算处理时的增加(Create)、读取查询(Retrieve)、更新(Update)和删除(Delete)几个单词的首字母简写。主要被用在描述软件系统中DataBase或者持久层的基本操作功能。

如果你的系统不是严格要求 “缓存+数据库” 必须保持一致性的话，最好不要做这个方案 : 读请求和写请求串行化，串到一个内存队列里去。串行化可以保证一定不会出现不一致的情况，但是它也会导致系统的吞吐量大幅度降低，用比正常情况下多几倍的机器去支撑线上请求。

Cache Aside Pattern  --最经典的缓存+数据库读写的模式，就是 Cache Aside Pattern。

读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。更新的时候，先更新数据库，然后再删除缓存。

在并发高的情况下，读操作和上面一样，写操作是异步写，写入Redis后直接返回，然后定期写入MySQL

几个例子：

最初级的缓存不一致问题及解决方案

1.当更新数据时，如更新某商品的库存，当前商品的库存是100，现在要更新为99，先更新数据库更改成99，然后删除缓存，发现删除缓存失败了，这意味着数据库存的是99，而缓存是100，这导致数据库和缓存不一致。

解决方法：

这种情况应该是先删除缓存，然后再更新数据库，如果删除缓存失败，那就不要更新数据库，如果说删除缓存成功，而更新数据库失败，那查询的时候只是从数据库里查了旧的数据而已，这样就能保持数据库与缓存的一致性。

比较复杂的数据不一致问题分析

2.在高并发的情况下，如果当删除完缓存的时候，这时去更新数据库，但还没有更新完，另外一个请求来查询数据，发现缓存里没有，就去数据库里查，还是以上面商品库存为例，如果数据库中产品的库存是100，那么查询到的库存是100，然后插入缓存，插入完缓存后，原来那个更新数据库的线程把数据库更新为了99，导致数据库与缓存不一致的情况

解决方法：

遇到这种情况，可以用队列的去解决这个问题，创建几个队列，如20个，根据商品的ID去做hash值，然后对队列个数取摸(获得数据的唯一标识)，当有数据更新请求时，先把它丢到队列里去(将操作路由之后，发送到一个 jvm 内部队列中)，当更新完后在从队列里去除，读取数据的时候，如果发现数据不在缓存中，那么将重新读取数据+更新缓存的操作，根据唯一标识路由之后，也发送同一个 jvm 内部队列中 , 然后同步等待缓存更新完成。

一个队列对应一个工作线程，每个工作线程串行拿到对应的操作，然后一条一条的执行。这样的话，一个数据变更的操作，先删除缓存，然后再去更新数据库，但是还没完成更新。此时如果一个读请求过来，读到了空的缓存，那么可以先将缓存更新的请求发送到队列中，此时会在队列中积压，然后同步等待缓存更新完成。

 

这里有一个优化点，如果发现队列里有一个查询请求了，那么就不要放新的查询操作进去了，用一个while（true）循环去查询缓存，循环个200MS左右，如果缓存里还没有则直接取数据库的旧数据，一般情况下是可以取到的。

这里有一个优化点，一个队列中，其实多个更新缓存请求串在一起是没意义的，因此可以做过滤，如果发现队列中已经有一个更新缓存的请求了，那么就不用再放个更新请求操作进去了，直接等待前面的更新操作请求完成即可。

待那个队列对应的工作线程完成了上一个操作的数据库的修改之后，才会去执行下一个操作，也就是缓存更新的操作，此时会从数据库中读取最新的值，然后写入缓存中。

如果请求还在等待时间范围内，不断轮询发现可以取到值了，那么就直接返回；如果请求等待的时间超过一定时长，那么这一次直接从数据库中读取当前的旧值。

在高并发下解决场景二要注意的问题：

1、读请求时长阻塞

由于读请求进行了非常轻度的异步化，所以一定要注意读超时的问题，每个读请求必须在超时间内返回，该解决方案最大的风险在于可能数据更新很频繁，导致队列中挤压了大量的更新操作在里面，然后读请求会发生大量的超时，最后导致大量的请求直接走数据库，像遇到这种情况，一般要做好足够的压力测试，如果压力过大，需要根据实际情况添加机器。

2、请求并发量过高

这里还是要做好压力测试，多模拟真实场景，并发量在最高的时候QPS(每秒查询率)多少，扛不住就要多加机器，还有就是做好读写比例是多少

3、多服务实例部署的请求路由

可能这个服务部署了多个实例，那么必须保证说，执行数据更新操作，以及执行缓存更新操作的请求，都通过nginx服务器路由到相同的服务实例上

4、热点商品的路由问题，导致请求的倾斜

万一某个商品的读写请求特别高，全部打到相同的机器的相同的队列里面去了，可能会造成某台机器的压力过大。就是说，因为只有在商品数据更新的时候才会清空缓存，然后才会导致读写并发，所以其实要根据业务系统去看，如果更新频率不是太高的话，这个问题的影响并不是特别大，但是的确可能某些机器的负载会高一些。

 

参考 https://mp.weixin.qq.com/s/9fbXiQe1sc2xpMKfBXNF3w

只要用缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么你如何解决一致性问题？

为什么是删除缓存，而不是更新缓存？

原因很简单，很多时候，在复杂点的缓存场景，缓存不单单是数据库中直接取出来的值。比如可能更新了某个表的一个字段，然后其对应的缓存，是需要查询另外两个表的数据并进行运算，才能计算出缓存最新的值的。

另外更新缓存的代价有时候是很高的。是不是说，每次修改数据库的时候，都一定要将其对应的缓存更新一份？也许有的场景是这样，但是对于比较复杂的缓存数据计算的场景，就不是这样了。如果你频繁修改一个缓存涉及的多个表，缓存也频繁更新。但是问题在于，这个缓存到底会不会被频繁访问到？

举个栗子，一个缓存涉及的表的字段，在 1 分钟内就修改了 20 次，或者是 100 次，那么缓存更新 20 次、100 次；但是这个缓存在 1 分钟内只被读取了 1 次，有大量的冷数据。实际上，如果你只是删除缓存的话，那么在 1 分钟内，这个缓存不过就重新计算一次而已，开销大幅度降低，用到缓存才去算缓存。

其实删除缓存，而不是更新缓存，就是一个 lazy 计算的思想，不要每次都重新做复杂的计算，不管它会不会用到，而是让它到需要被使用的时候再重新计算。像 mybatis，hibernate，都有懒加载思想。查询一个部门，部门带了一个员工的 list，没有必要说每次查询部门，都里面的 1000 个员工的数据也同时查出来啊。80% 的情况，查这个部门，就只是要访问这个部门的信息就可以了。先查部门，同时要访问里面的员工，那么这个时候只有在你要访问里面的员工的时候，才会去数据库里面查询 1000 个员工。

 

Redis 热点 Key 如何发现？又该如何解决？

参考 https://mp.weixin.qq.com/s/3pe_dTAC8GdAs-bgzvcIpg

热点Key问题产生的原因大致有以下两种：

1、用户消费的数据远大于生产的数据（热卖商品、热点新闻、热点评论、明星直播）。--库存问题

在日常工作生活中一些突发的的事件，例如：双十一期间某些热门商品的降价促销，当这其中的某一件商品被数万次点击浏览或者购买时，会形成一个较大的需求量，这种情况下就会造成热点问题。

同理，被大量刊发、浏览的热点新闻、热点评论、明星直播等，这些典型的读多写少的场景也会产生热点问题。

2、请求分片集中，超过单 Server 的性能极限。--一行数据竞争

在服务端读数据进行访问时，往往会对数据进行分片切分，此过程中会在某一主机 Server 上对相应的 Key 进行访问，当访问超过 Server 极限时，就会导致热点 Key 问题的产生。

热点Key问题的危害

1、流量集中，达到物理网卡上限。

2、请求过多，缓存分片服务被打垮。

3、DB 击穿，引起业务雪崩。

如前文讲到的，当某一热点 Key 的请求在某一主机上超过该主机网卡上限时，由于流量的过度集中，会导致服务器中其它服务无法进行。

如果热点过于集中，热点 Key 的缓存过多，超过目前的缓存容量时，就会导致缓存分片服务被打垮现象的产生。

当缓存服务崩溃后，此时再有请求产生，会缓存到后台 DB 上，由于DB 本身性能较弱，在面临大请求时很容易发生请求穿透现象，会进一步导致雪崩现象，严重影响设备的性能。

解决方案

通常的解决方案主要集中在对客户端和 Server 端进行相应的改造。

1、服务端缓存方案

首先 Client 会将请求发送至 Server 上，而 Server 又是一个多线程的服务，本地就具有一个基于 Cache LRU 策略的缓存空间。

当 Server 本身就拥堵时，Server 不会将请求进一步发送给 DB 而是直接返回，只有当 Server 本身畅通时才会将 Client 请求发送至 DB，并且将该数据重新写入到缓存中。此时就完成了缓存的访问跟重建。

但该方案也存在以下问题：

1、缓存失效，多线程构建缓存问题

2、缓存丢失，缓存构建问题

3、脏读问题

2、使用 Memcache、Redis 方案

该方案通过在客户端单独部署缓存的方式来解决热点 Key 问题。使用过程中 Client 首先访问服务层，再对同一主机上的缓存层进行访问。该种解决方案具有就近访问、速度快、没有带宽限制的优点，但是同时也存在以下问题。

1、内存资源浪费

2、脏读问题

3、使用本地缓存方案

使用本地缓存则存在以下问题：

1、需要提前获知热点

2、缓存容量有限

3、不一致性时间增长

4、热点 Key 遗漏

传统的热点解决方案都存在各种各样的问题，那么究竟该如何解决热点问题呢？

4、读写分离方案解决热读

架构中各节点的作用如下：

1、SLB 层做负载均衡

2、Proxy 层做读写分离自动路由

3、Master 负责写请求

4、ReadOnly 节点负责读请求

5、Slave 节点和 Master 节点做高可用

实际过程中 Client 将请求传到 SLB，SLB 又将其分发至多个 Proxy 内，通过 Proxy 对请求的识别，将其进行分类发送。

例如，将同为 Write 的请求发送到 Master 模块内，而将 Read 的请求发送至 ReadOnly 模块。

而模块中的只读节点可以进一步扩充，从而有效解决热点读的问题。

读写分离同时具有可以灵活扩容读热点能力、可以存储大量热点Key、对客户端友好等优点。

5、热点数据解决方案

该方案通过主动发现热点并对其进行存储来解决热点 Key 的问题。首先 Client 也会访问 SLB，并且通过 SLB 将各种请求分发至 Proxy 中，Proxy 会按照基于路由的方式将请求转发至后端的 Redis 中。在热点 key 的解决上是采用在服务端增加缓存的方式进行。具体来说就是在 Proxy 上增加本地缓存，本地缓存采用 LRU 算法来缓存热点数据，后端 db 节点增加热点数据计算模块来返回热点数据。

Proxy 架构的主要有以下优点：

1、Proxy 本地缓存热点，读能力可水平扩展

2、DB 节点定时计算热点数据集合

3、DB 反馈 Proxy 热点数据

4、对客户端完全透明，不需做任何兼容

热点 key 处理

热点数据的读取

在热点 Key 的处理上主要分为写入跟读取两种形式，在数据写入过程当 SLB 收到数据 K1 并将其通过某一个 Proxy 写入一个 Redis，完成数据的写入。

假若经过后端热点模块计算发现 K1 成为热点 key 后， Proxy 会将该热点进行缓存，当下次客户端再进行访问 K1 时，可以不经 Redis。

最后由于 proxy 是可以水平扩充的，因此可以任意增强热点数据的访问能力。

热点数据的发现

对于 db 上热点数据的发现，首先会在一个周期内对 Key 进行请求统计，在达到请求量级后会对热点 Key 进行热点定位，并将所有的热点 Key 放入一个小的 LRU 链表内，在通过 Proxy 请求进行访问时，若 Redis 发现待访点是一个热点，就会进入一个反馈阶段，同时对该数据进行标记。

DB 计算热点时，主要运用的方法和优势有：

1、基于统计阀值的热点统计

2、基于统计周期的热点统计

3、基于版本号实现的无需重置初值统计方法

4、DB 计算同时具有对性能影响极其微小、内存占用极其微小等优点

方案对比

通过上述对比分析可以看出，在解决热点 Key 上较传统方法相比都有较大的提高，无论是基于读写分离方案还是热点数据解决方案，在实际处理环境中都可以做灵活的水平能力扩充、都对客户端透明、都有一定的数据不一致性。

此外读写分离模式可以存储更大量的热点数据，而基于 Proxy 的模式有成本上的优势。

 

redis单线程不阻塞

1.redis的单线程指的是什么单线程？
同一个时间点只处理一个客户端的连接，也就是redis网络模块的单线程。redis集群的每个节点里只有一个线程负责接受和执行所有客户端发送的请求。技术上使用多路复用I/O，使用Linux的epoll函数，这样一个线程就可以管理很多socket连接。

除此之外，选择单线程还有以下这些原因：

1、redis都是对内存的操作，速度极快（10W+QPS）

2、整体的时间主要都是消耗在了网络的传输上

3、如果使用了多线程，则需要多线程同步，这样实现起来会变的复杂(所以选择单线程)

4、线程的加锁时间甚至都超过了对内存操作的时间(所以选择单线程)

5、多线程上下文频繁的切换需要消耗更多的CPU时间(所以选择单线程)

6、还有就是单线程天然支持原子操作，而且单线程的代码写起来更简单

因为CPU不是Redis的瓶颈。Redis的瓶颈最有可能是机器内存或者网络带宽，既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。关于redis的性能，官方网站也有，普通笔记本轻松处理每秒几十万的请求

redis 核心就是 如果我的数据全都在内存里，我单线程的去操作 就是效率最高的，为什么呢，因为多线程的本质就是 CPU 模拟出来多个线程的情况，这种模拟出来的情况就有一个代价，就是上下文的切换，对于一个内存的系统来说，它没有上下文的切换就是效率最高的。redis 用 单个CPU 绑定一块内存的数据，然后针对这块内存的数据进行多次读写的时候，都是在一个CPU上完成的，所以它是单线程处理这个事。在内存的情况下，这个方案就是最佳方案  —— 阿里 沈询

因为一次CPU上下文的切换大概在 1500ns 左右。从内存中读取 1MB 的连续数据，耗时大约为 250us，假设1MB的数据由多个线程读取了1000次，那么就有1000次时间上下文的切换，那么就有1500ns * 1000 = 1500us ，我单线程的读完1MB数据才250us ,你光时间上下文的切换就用了1500us了，我还不算你每次读一点数据 的时间，那什么时候用多线程的方案呢？

答案是：下层的存储等慢速的情况。比如磁盘

内存是一个 IOPS 非常高的系统，因为我想申请一块内存就申请一块内存，销毁一块内存我就销毁一块内存，内存的申请和销毁是很容易的。而且内存是可以动态的申请大小的。磁盘的特性是：IPOS很低很低，但吞吐量很高。这就意味着，大量的读写操作都必须攒到一起，再提交到磁盘的时候，性能最高。为什么呢？

如果我有一个事务组的操作（就是几个已经分开了的事务请求，比如写读写读写，这么五个操作在一起），在内存中，因为IOPS非常高，我可以一个一个的完成，但是如果在磁盘中也有这种请求方式的话，我第一个写操作是这样完成的：我先在硬盘中寻址，大概花费10ms，然后我读一个数据可能花费1ms然后我再运算（忽略不计），再写回硬盘又是10ms ，总共21ms   ; 第二个操作去读花了10ms, 第三个又是写花费了21ms ,然后我再读10ms, 写21ms ，五个请求总共花费83ms，这还是最理想的情况下，这如果在内存中，大概1ms不到。所以对于磁盘来说，它吞吐量这么大，那最好的方案肯定是我将N个请求一起放在一个buff里，然后一起去提交。

方法就是用异步：将请求和处理的线程不绑定，请求的线程将请求放在一个buff里，然后等buff快满了，处理的线程再去处理这个buff。然后由这个buff 统一的去写入磁盘，或者读磁盘，这样效率就是最高。java里的 IO不就是这么干的么~对于慢速设备，这种处理方式就是最佳的，慢速设备有磁盘，网络 ，SSD 等等，多线程 ，异步的方式处理这些问题非常常见，大名鼎鼎的netty 就是这么干的。

补一发大师语录：来说说，为何单核cpu绑定一块内存效率最高“我们不能任由操作系统负载均衡，因为我们自己更了解自己的程序，所以我们可以手动地为其分配CPU核，而不会过多地占用CPU”，默认情况下单线程在进行系统调用的时候会随机使用CPU内核，为了优化Redis，我们可以使用工具为单线程绑定固定的CPU内核，减少不必要的性能损耗！redis作为单进程模型的程序，为了充分利用多核CPU，常常在一台server上会启动多个实例。而为了减少切换的开销，有必要为每个实例指定其所运行的CPU。Linux 上  taskset 可以将某个进程绑定到一个特定的CPU。你比操作系统更了解自己的程序，为了避免调度器愚蠢的调度你的程序，或是为了在多线程程序中避免缓存失效造成的开销。

顺便再提一句：redis 的瓶颈在网络上 

具体作者怎么想的，我不知道，我说一下我的理解
（1）redis用的是非阻塞IO，非阻塞I/O本身就可以是单线程处理多个请求
（2）如果用多线程，就要考虑线程的上下文切换，和锁的请求和释放，这些操作也比较耗时，锁等待更容易把业务线程池占满
（3）在我看来，Redis的设计理念就是短平快，在保证完全内存计算的情况下，能串行的地方就串行，在处理socket请求这块采用了非阻塞IO，并且是纯内存操作，一个event loop（请求事件）下来，几乎没有等待点

3.redis是单线程为什么这么快
（1） 纯内存操作
（2） 异步非阻塞 I/O
（3） 单线程，避免了上下文切换和线程锁

1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；

2、数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；

3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；

4、使用多路I/O复用模型，非阻塞IO；

5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；

参考 https://blog.csdn.net/u013328047/article/details/82229710

参考 https://mp.weixin.qq.com/s/ApDUI3uWJIUtHcpjJzI_6w

参考 https://mp.weixin.qq.com/s/Spiq8eFzVNS92LVX-TN3IA

4.服务性能三大杀手
（1） 大量线程导致的线程切换开销
（2） 请求和释放锁
（3） 非必要的内存拷贝

 

为什么Redis 单线程却能支撑高并发？

参考 https://mp.weixin.qq.com/s/ApDUI3uWJIUtHcpjJzI_6w (涉及redis源码)

为什么 Redis 中要使用 I/O 多路复用这种技术呢？

首先，Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务，而 I/O 多路复用就是为了解决这个问题而出现的。

I/O 多路复用

虽然还有很多其它的 I/O 模型，但是在这里都不会具体介绍。

阻塞式的 I/O 模型并不能满足这里的需求，我们需要一种效率更高的 I/O 模型来支撑 Redis 的多个客户（redis-cli），这里涉及的就是 I/O 多路复用模型了：

在 I/O 多路复用模型中，最重要的函数调用就是 select，该方法的能够同时监控多个文件描述符的可读可写情况，当其中的某些文件描述符可读或者可写时，select 方法就会返回可读以及可写的文件描述符个数。

关于 select 的具体使用方法，在网络上资料很多，这里就不过多展开介绍了；

与此同时也有其它的 I/O 多路复用函数 epoll/kqueue/evport，它们相比 select 性能更优秀，同时也能支撑更多的服务。

(后略 源码及详细)

 

Redis持久化-RDB和AOF

持久化不属于入门范围，找了几篇比较好的文章，有兴趣欢迎阅读

• redis持久化RDB和AOF

  https://my.oschina.net/davehe/blog/174662

• [Redis持久化RDB和AOF相比较]

  http://www.ywnds.com/?p=4876

• [redis系列：RDB持久化与AOF持久化]

  https://www.cnblogs.com/fixzd/p/9393990.html

redis.conf文件配置项

redis.conf 配置项说明如下：

1. Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程
   daemonize no

2. 当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定
   pidfile /var/run/redis.pid

3. 指定Redis监听端口，默认端口为6379，这里有个故事，因为6379在手机按键上MERZ对应的号码，而MERZ取自意大利歌女Alessia Merz的名字
   port 6379

4. 绑定的主机地址
   bind 127.0.0.1

5. 当客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能
   timeout 30

6. 指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose
   loglevel verbose

7. 日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null
logfile stdout

8. 设置数据库的数量，默认数据库为0，可以使用SELECT <dbid>命令在连接上指定数据库id
   databases 16

9. 指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
   save <seconds> <changes>
   Redis默认配置文件中提供了三个条件：
   `save 900 1
   save 300 10
   save 60 10000`
   分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。

10. 指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大
    rdbcompression yes

11. 指定本地数据库文件名，默认值为dump.rdb
    dbfilename dump.rdb

12. 指定本地数据库存放目录 `dir ./`

13. 设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步               `slaveof <masterip> <masterport>`

14. 当master服务设置了密码保护时，slav服务连接master的密码

    `masterauth <master-password>`

15. 设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH <password>命令提供密码，默认关闭

    `requirepass foobared`

16. 设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息
    maxclients 128

17. 指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区

    `maxmemory <bytes>`

18. 指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no
    appendonly no

19. 指定更新日志文件名，默认为appendonly.aof
    appendfilename appendonly.aof

20. 指定更新日志条件，共有3个可选值：                                                                                                                                              no：表示等操作系统进行数据缓存同步到磁盘（快） 
    always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全） 
    everysec：表示每秒同步一次（折衷，默认值）
    appendfsync everysec

21. 指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中
    vm-enabled no

22. 虚拟内存文件路径，默认值为/tmp/redis.swap，不可多个Redis实例共享
    vm-swap-file /tmp/redis.swap

23. 将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据 就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0
    vm-max-memory 0

24. Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的 数据大小来设定的，作者建议如果存储很多小对象，page大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不 确定，就使用默认值
    vm-page-size 32

25. 设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存。
    vm-pages 134217728

26. 设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4
    vm-max-threads 4

27. 设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启
    glueoutputbuf yes

28. 指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法
    `hash-max-zipmap-entries 64
    hash-max-zipmap-value 512`

29. 指定是否激活重置哈希，默认为开启
    activerehashing yes

30. 指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件

    include /path/to/local.conf

• 什么是守护进程？
  守护进程（Daemon Process），也就是通常说的 Daemon 进程（精灵进程），是 Linux 中的后台服务进程。它是一个生存期较长的进程，通常独立于控制终端并且周期性地执行某种任务或等待处理某些发生的事件。守护进程是个特殊的孤儿进程，这种进程脱离终端，为什么要脱离终端呢？之所以脱离于终端是为了避免进程被任何终端所产生的信息所打断，其在执行过程中的信息也不在任何终端上显示。由于在 linux 中，每一个系统与用户进行交流的界面称为终端，每一个从此终端开始运行的进程都会依附于这个终端，这个终端就称为这些进程的控制终端，当控制终端被关闭时，相应的进程都会自动关闭。