长期把Redis做缓存用，总有一天Redis内存会满的，怎么处理呢？
在Redis的配置文件 redisconf 文件中，配置 maxmemory 的大小参数如下所示：
倘若实际的存储中超出了Redis的配置参数的大小时，Redis中有 淘汰策略 ，把 需要淘汰的key给淘汰掉，整理出干净的一块内存给新的key值使用 。
Redis提供了 6种的淘汰策略 ，其中默认的是 noeviction ，这6中淘汰策略如下：
LRU(Least Recently Used) 即表示最近最少使用，也就是在最近的时间内最少被访问的key，算法根据数据的历史访问记录来进行淘汰数据。
它的核心的思想就是： 假如一个key值在最近很少被使用到，那么在将来也很少会被访问 。
实际上Redis实现的LRU并不是真正的LRU算法，也就是名义上我们使用LRU算法淘汰键，但是实际上被淘汰的键并不一定是真正的最久没用的。
Redis使用的是近似的LRU算法， 通过随机采集法淘汰key，每次都会随机选出5个key，然后淘汰里面最近最少使用的key 。
这里的5个key只是默认的个数，具体的个数也可以在配置文件中进行配置，在配置文件中的配置如下图所示：
当近似LRU算法取值越大的时候就会越接近真实的LRU算法，可以这样理解，因为 取值越大那么获取的数据就越全，淘汰中的数据的就越接近最近最少使用的数据 。
那么为了实现根据时间实现LRU算法，Redis必须为每个key中额外的增加一个内存空间用于存储每个key的时间，大小是3字节。
在Redis 30中对近似的LRU算法做了一些优化，Redis中会维护大小是 16 的一个候选池的内存。
当第一次随机选取的采样数据，数据都会被放进候选池中，并且候选池中的数据会根据时间进行排序。
当第二次以后选取的数据，只有 小于候选池内的最小时间 的才会被放进候选池中。
当某一时刻候选池的数据满了，那么时间最大的key就会被挤出候选池。当执行淘汰时，直接从候选池中选取最近访问时间最小的key进行淘汰。
这样做的目的就是选取出最近似符合最近最少被访问的key值，能够正确的淘汰key值，因为随机选取的样本中的最小时间可能不是真正意义上的最小时间。
但是LRU算法有一个弊端：就是假如一个key值在以前都没有被访问到，然而最近一次被访问到了，那么就会认为它是热点数据，不会被淘汰。
然而有些数据以前经常被访问到，只是最近的时间内没有被访问到，这样就导致这些数据很可能被淘汰掉，这样一来就会出现误判而淘汰热点数据。
于是在Redis 40的时候除了LRU算法，新加了一种LFU算法， 那么什么是LFU算法算法呢？
LFU(Least Frequently Used) 即表示最近频繁被使用，也就是最近的时间段内，频繁被访问的key，它以最近的时间段的被访问次数的频率作为一种判断标准。
它的核心思想就是：根据key最近被访问的频率进行淘汰，比较少被访问的key优先淘汰，反之则优先保留。
LFU算法反映了一个key的热度情况，不会因为LRU算法的偶尔一次被访问被认为是热点数据。
在LFU算法中支持 volatile-lfu 策略和 allkeys-lfu 策略。
在Redis种有三种删除的 *** 作此策略，分别是：
在Redis中持久化的方式有两种 RDB 和 AOF
在RDB中是以快照的形式获取内存中某一时间点的数据副本，在创建RDB文件的时候可以通过 save 和 bgsave 命令执行创建RDB文件。
这两个命令都不会把过期的key保存到RDB文件中 ，这样也能达到删除过期key的效果。
当在启动Redis载入RDB文件的时候， Master 不会把过期的key载入，而 Slave 会把过期的key载入。
在AOF模式下，Redis提供了Rewite的优化措施，执行的命令分别是 REWRITEAOF 和 BGREWRITEAOF ， 这两个命令都不会把过期的key写入到AOF文件中，也能删除过期key 。
RDB 是一种快照存储持久化方式，具体就是将 Redis 某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为 dumprdb ，而在 Redis 服务器启动时，会重新加载 dumprdb 文件的数据到内存当中恢复数据。
开启RBD持久化方式
开启 RDB 持久化方式很简单，客户端可以通过向 Redis 服务器发送 save 或 bgsave 命令让服务器生成 rdb 文件，或者通过服务器配置文件指定触发 RDB 条件。
save 命令是一个同步 *** 作。
当客户端向服务器发送 save 命令请求进行持久化时，服务器会阻塞 save 命令之后的其他客户端的请求，直到数据同步完成。
与 save 命令不同， bgsave 命令是一个异步 *** 作。
当客户端发服务发出 bgsave 命令时， Redis 服务器主进程会 forks 一个子进程来数据同步问题，在将数据保存到rdb文件之后，子进程会退出。
所以，与 save 命令相比， Redis 服务器在处理 bgsave 采用子线程进行IO写入，而主进程仍然可以接收其他请求，但 forks 子进程是同步的，所以 forks 子进程时，一样不能接收其他请求，这意味着，如果forks一个子进程花费的时间太久(一般是很快的)，bgsave命令仍然有阻塞其他客户的请求的情况发生。
除了通过客户端发送命令外，还有一种方式，就是在 Redis 配置文件中的 save 指定到达触发RDB持久化的条件，比如多少秒内至少达到多少写 *** 作就开启 RDB 数据同步。
例如我们可以在配置文件redisconf指定如下的选项：
之后在启动服务器时加载配置文件。
这种通过服务器配置文件触发RDB的方式，与bgsave命令类似，达到触发条件时，会forks一个子进程进行数据同步，不过最好不要通过这方式来触发RDB持久化，因为设置触发的时间太短，则容易频繁写入rdb文件，影响服务器性能，时间设置太长则会造成数据丢失。
介绍了三种让服务器生成rdb文件的方式，无论是由主进程生成还是子进程来生成，其过程如下：
Redis 的另外一个持久化方式： AOF(Append-only file) 。
与 RDB 存储某个时刻的快照不同， AOF 持久化方式会记录客户端对服务器的每一次写 *** 作命令，并将这些写 *** 作以 Redis 协议追加保存到以后缀为 aof 文件末尾，在Redis服务器重启时，会加载并运行 aof 文件的命令，以达到恢复数据的目的。
Redis默认不开启AOF持久化方式，我们可以在配置文件中开启并进行更加详细的配置，如下面的redisconf文件：
在上面的配置文件中，我们可以通过 appendfsync 选项指定写入策略,有三个选项
客户端的每一个写 *** 作都保存到 aof 文件当，这种策略很安全，但是每个写请注都有IO *** 作，所以也很慢。
appendfsync 的默认写入策略，每秒写入一次 aof 文件，因此，最多可能会丢失1s的数据。
Redis 服务器不负责写入 aof ，而是交由 *** 作系统来处理什么时候写入 aof 文件。更快，但也是最不安全的选择，不推荐使用。
AOF将客户端的每一个写 *** 作都追加到 aof 文件末尾，比如对一个key多次执行incr命令，这时候， aof 保存每一次命令到aof文件中，aof文件会变得非常大。
aof文件太大，加载aof文件恢复数据时，就会非常慢，为了解决这个问题，Redis支持aof文件重写，通过重写aof，可以生成一个恢复当前数据的最少命令集，比如上面的例子中那么多条命令，可以重写为：
通过在redisconf配置文件中的选项no-appendfsync-on-rewrite可以设置是否开启重写，这种方式会在每次fsync时都重写，影响服务器性能，因此默认值为no，不推荐使用。
客户端向服务器发送bgrewriteaof命令，也可以让服务器进行AOF重写。
AOF重写方式也是异步 *** 作，即如果要写入aof文件，则Redis主进程会forks一个子进程来处理，如下所示：
在写入aof日志文件时，如果Redis服务器宕机，则aof日志文件文件会出格式错误，在重启Redis服务器时，Redis服务器会拒绝载入这个aof文件，可以通过以下步骤修复aof并恢复数据。
AOF只是追加日志文件，因此对服务器性能影响较小，速度比RDB要快，消耗的内存较少。
我们可以从几个方面对比一下RDB与AOF,在应用时，要根本自己的实际需求，选择RDB或者AOF，其实，如果想要数据足够安全，可以两种方式都开启，但两种持久化方式同时进行IO *** 作，会严重影响服务器性能，因此有时候不得不做出选择。
当RDB与AOF两种方式都开启时，Redis会优先使用AOF日志来恢复数据，因为AOF保存的文件比RDB文件更完整。
尽管Twitter的运营团队通过后台的流量图看到了即将到来的奥运会热潮对各项指标的拉升—这种可预期的、能带来大流量的事件，Twitter一般都会提前做准备，然而意外还是发生了。
在Twitter的预案里，如果这里发生了洪水、地震或者其他任何有可能导致服务器停止工作的问题，距离萨克拉门托965公里的另一个数据中心就会开始工作，它位于托管服务商Raging Wire旗下的一处建筑内，当然，情况也可能相反：Raging Wire这边出了问题，萨克拉门托开始工作。
无论哪一种情况，Twitter希望保证的是用户的不间断使用体验，即便是远在大洋彼岸的用户，也可以正常地把自己的消息Tweet出去，而不会感受到服务中断。
对于互联网公司而言，在线就是生命。Facebook早期迅速积累用户并不是由于它来自哈佛大学的好名声，而是它几乎从不宕机。这与当时强劲的竞争对手MySpace形成了鲜明对 照。
但在7月26日这一天，Twitter两个数据中心同时发生故障，全球用户的Twitter服务中止。Twitter提供的解释是由于“基础设施元件中的级联式漏洞”，但没有公布更详细的信息。在Twitter的成长史上几乎每年都会有多次重大宕机事故，宕机时网站就会显示出一幅有趣的：几只小鸟用线艰难地拉起一头搁浅的鲸鱼。
这是Twitter在两个月之内的第二次重大宕机故障。此前一次是6月21日，Twitter停止服务将近两个多小时。
Twitter负责工程技术的副总裁拉瓦德（Mazen Rawashdeh）事后解释说，Twitter在数据中心有两套能互相备份的数据系统同时出现了故障，这是基础设施上的“巧合事件”。通常情况下，如果一个系统出现故障，那么另一个将被紧急启用。而两套系统同时出现问题则比较少见，为避免类似故障重演，Twitter称计划对基础设施大幅投资。
数据中心问题一直困扰着Twitter。截至3月，Twitter已有14亿活跃用户，每天会发出34亿条Tweet。随着用户量和信息读写量的增长，Twitter迫切需要一个能自我完全掌控的数据中心。
Twitter早期租用第三方的数据服务，之后计划转向租用位于犹他州盐湖城的定制化数据中心，然而在去年该数据中心却出现了漏雨、电力不足等问题，于是Twitter不得不改变其计划，另谋他处。
在同一天，悲催的不仅仅是Twitter。谷歌的即时通讯服务Gtalk也在早上6点40分发生故障，并迟迟没有被修复。有用户报告，微软旗下面对企业客户的云服务工具Windows Azure在西欧地区也发生了宕机问题。
在宕机这段时间内，Gtalk用户发现虽然能够登录，但无法像以往一样正常发送信息以及进行语音、视频聊天。他们持续接到谷歌通过网页更新的问题修复状态通知，时间单位大约为半小时，而这一状态持续了近5个小时，算是谷歌史上罕见的长时间故障。习惯线上沟通的用户们不得不转向其他工具，有人说，接连两起宕机事件让他们有一种“全球停电”的感觉。
谷歌的数据中心分布全球且多达20多个，目前无法得知是哪一块数据中心发生了故障以致Gtalk瘫痪，谷歌至今也未解释具体原 因。
世界正在变成一个由数据洪流组成的存在，而整个世界也因几个重要信息节点而相互连接在一起。但即使是像谷歌这样著名的互联网公司也无法保证自己所有的服务全年都不出问题。
据谷歌称，其最受欢迎的服务Gmail电子邮件服务2010年全年宕机时间为7分钟，这已经是业内最短时间。根据Radicati Group的数据，电子邮件系统平均宕机时间为每月38小时。对比起来，Gmail可谓优秀。
一般造成系统不稳定甚至宕机的原因是多样的，开发安卓手机管理工具豌豆荚的豌豆实验室技术总监高磊对《第一财经周刊》介绍，在用户使用网站服务时，从用户输入信息，网络传送信息给网站服务器，网站服务器按照程序对用户要求进行处理，将结果返还用户，整个过程中其中一个环节出现问题就会导致网站的服务受到影响，甚至发生宕机而不可用。
引发问题的潜在因素多种多样，包括网站自身程序、服务器的 *** 作系统、硬件设备、机房与网络运营商等基础设施。
如果网站自身程序有Bug，可能会导致使用变慢，或部分功能失效；服务器的 *** 作系统也会出现漏洞，比如装有Linux部分版本的服务器就在本月因为闰秒问题而宕机；服务器硬件本身损坏，比如硬盘或内存都存在一定物理故障的机率。
而在基础设施上，机房停电或进水、遭到雷击等也会造成设备停止运行。最基础的问题是过热，因此大型数据中心旁边一般都有冷却装置。
6月底，美国一场风暴袭击了弗吉尼亚北部，大面积电力供应中断。而恰巧亚马逊在这里安置了US-East-1数据中心，因为停电，整个数据中心瘫痪。
亚马逊是业界领先的云服务提供商，其提供给网站以数据服务的云服务Amazon Web Services也因此一度中断服务。之后连锁反应便产生，使用其服务的Instagram、Pinterest、Quora、Netflix等知名网站也停止了服务，进而影响到各自的生态系统。
为避免风险，一些网络公司选择不把鸡蛋放在一个篮子里，设置多个数据中心，或者在使用云服务时同时选择多家供应商，当然，这也会增加成本。
据新浪微博技术总监杨卫华对《第一财经周刊》介绍，是否能稳定登录，响应的速度怎样，都会对用户的体验造成直接影响。新浪微博采用了分布式的架构，这意味着它没有把所有的服务器都放在新浪所在的北京，而是在国内多个主要城市都设置了数据中心，在突发事件发生后的流量处理和响应速度等各方面来保证用户体验。
你在宕机时体验到多少焦虑，稳定对于互联网公司就有多重要。
当越来越多的人被接入同一个网络─比如被称为“世界的脉搏”的Twitter，数据中心瘫痪的风险等级也相应增加。这些数据就存储在像加州萨克拉门托的大房子里，一旦宕机，空白也从这里开始。会。当电脑主机服务器内存满了电脑会自动覆盖超过时间的数据。计算机（computer）俗称电脑，是现代一种用于高速计算的电子计算机器，可以进行数值计算，又可以进行逻辑计算，还具有存储记忆功能。—、服务器出现宕机的原因
1运行环境出现问题，机房断电导致的服务器断电(欠压，过载，波动)、机房温度过高，散热不良、资源冲突、DirectX文件的损坏、系统不完善等等原因而造成服务器宕机。
⒉服务器不堪负重，最常见的如磁盘空间耗尽、访问值过大、程序中毒、遭受攻击等大规模高消耗服务器资源情况。
3由于主备数据不—致导致的复制问题。
4性能问题，运维运行糟糕的SQL或Schema和索引设计等。
二、服务器宕机应该从哪些方面检查呢
①硬件
(1)检查硬件是否有冲突;
(2)对比服务器电源所负载的功率判断电源是否出现故障;
(3)扫描硬盘表面检查是否有坏道;
(4)通过错误报告和 *** 作系统的报错信息来判断;
(5)使用替换法判断主板、CPU、SCSI/RAID卡或其他PCI设备是否出现故障。
②软件
(1)检查 *** 作系统的系统日志，可以通过系统日志来判断部分造成死机的原因;
(2)在判断硬件没有故障后，考虑系统软件的BUG和漏洞原因;
(3)如果是因为软件使用不当或系统工作压力过大，可以适当降低服务器的工作压力;
(4)电脑病毒。
以上就是有关服务器宕机的原因有哪些，应该从哪些方面检查的知识介绍。
在想解决处理办法之前要知道服务器宕机的两种形态：假死机和死机
假死机(非蓝屏死机)是由于硬件资源暂时性地被消耗殆尽，因而无法对外部指令进行响应的现象， 通常是网站处于访问高峰期，带宽等资源跑满，这时只需要等待一定的时间，待服务器腾出更多的硬件资源即可恢复正常。
而死机，如果通过ping测试服务器，键盘切换数字锁定键(NumLock)或大写锁定键(Caps Lock)功能， 显示器无画面输出，或者鼠标光标没有任何反应则表明服务器硬件故障。
再了解服务器出现宕机的常见原因 ：
1在运行环境的问题中，最普遍的问题时磁盘空间耗尽。
2在性能问题中，最普通的服务器宕机原因确实是运行很糟糕的SQL， 但也不一定都是这个原因，比如也有很多问题是由于服务器Bug或错误的行为导致的。
3糟糕的Schema和索引设计是第二大影响性能的问题。
4复制问题通常由于主备数据不一致导致。
5数据丢失问题通常由于drop table的错误 *** 作导致，并总是便随着缺少可用备份的问题。
如何查看服务器宕机的原因：
a、是否是应用程序导致内存溢出或者泄露，out of memory导致
b、是否是进程过多或者不断创建，耗尽资源导致
c、是否是数据库程序死锁，连接数过多导致
d、是否是应用程序异常导致
e、是否是流量负载过大导致
f、 是否是遭受黑客入侵攻击导致
g、是否是误 *** 作导致
服务器宕机自行解决办法：
1要即时发现服务器宕机的问题。时间就是金钱，这是不变的真理。我们要第一时间， 发现宕机的问题，服务器宕机时，为了避免造成不必要的损失，要尽早通知IDC服务商解决相关问题。
2最好准备2个服务器空间，他们存放的内容相同，而ip不同，并且机房的地理位置不同。这样2个区域的服务器， 能够做到有效异地容灾备份。发现宕机问题后，可以迅速的通过修改>对于广大站长来说，服务器宕机对网站的收录跟排名都是有非常大的影响的，最重要的是宕机会影响网站业务的进行，所以无论不管说是用户还是服务商都不希望服务器出现宕机问题，那假如出现了，我们该如何解决它呢？
服务器宕机是每个服务商都会遇到的问题，一般有以下几种原因：
1服务器性能
服务器的性能问题有很多，但最多见的应该就是SQL，但我们也不能一概而论，还有别的可能性，例如有些问题就是服务器Bug或错误行为导致的。另外，较差的Schema和索引设计也是较多的出错原因之一。
2运行环境
如果是这个问题，那么最常见的就是磁盘空间消耗完了。
3数据丢了或损坏
数据丢失也有很多原因，可能不是用户错误 *** 作，也可能是人为攻击造成的，但一般来说是由drop table错误 *** 作导致，通常出现这个问题都会伴随着缺少可用备份的问题。
4复制
复制问题一般是由主备数据不一致导致的。
我们了解了这几项宕机原因，那么如何判断或查看服务器宕机原因呢？
（1）查看是否是误 *** 作导致的
（2）查看是否是应用程序导致的
（3）查看是否是应用程序导致内存溢出或者泄露，out of memory导致
（4）查看是否是流量负载过大导致的
（5）查看是否是遭受黑客入侵攻击导致的
那我们查明是如原因后，我们又该如何去解决问题呢？
1发现服务器宕机后，及时联系服务商解决相关问题，就算短暂的宕机也可能会造成较大的损失，请大家及时联系自己的服务商。
2做好提前防范的准备。可以同时运行两个网站空间，备份内容，当一个出现问题，立刻启动另一个。
3使用一款功能好的宕机监控第一时间智能处理，故障发生时可设置自动切换至备用IP，恢复后将切换回原IP，能够有效提高网站可用性和页面性能。有效规避风险降低成本。
服务器崩溃的几种原因第一：高并发流量或请求超过服务器承受力
无论是企业和个人在租用服务器的时候都会受到峰值承受限制的，一旦超过服务器的承受能力，就会导致服务器瘫痪，应用程序暂停，网站无法访问。服务器都是有峰值限制的，不可能承受无上限的并发能力。而造成服务器瘫痪的原因就是在同一段时间内，访问人数多，造成高流量的突进。超出了服务器的承受范围。这种例子我们经常可以看到，比如双11期间，很多公司为了应对双11的高流量，开启的紧急避险措施和大规模的服务器负载能力。还有春运期间，12306网站由于受到高并发的问题，也会频繁的出现崩溃。
第二：磁盘空间不足
导致服务器无法正常运行的原因也有可能是磁盘空间溢出导致的。企业的网络管理员应该实时关注磁盘的使用情况，并且要在规定的时间把磁盘储存的数据备份到另外的存储设备里面，确保数据无遗失，推荐相关阅读：哪些网站应该使用服务器呢？
服务器的磁盘大部分的资源都是被日志文件占用了，包括web服务器，数据库等日志信息都包括其中，以及应用程序服务器日志文件均与内存泄漏是同等的危害。我们可以采取措施保护我们的数据和日志文件，日志文件对应用程序进行异地存储。日志文件系统空间如果满了，则web服务器将自动被挂起，但是机器本身瘫痪和宕机的几率就会大大降低。
第三：服务器超载
连接web服务器都是用一个线程链接的，web服务器会在线程用过之后自动挂起，不会再未已链接的线程提供任何服务。如果我们用了负载机制，那么如果该服务器没有响应，则该服务器的负载则会自动的转移到其他web服务器上，这个 *** 作会使服务器一个接一个的用光线程。这中 *** 作可能会导致整个服务器机组被挂起， *** 作系统同时还有可能在不断接收新的链接，而我们的web服务器无法未其提供服务，致使服务器崩溃。
第四：服务器遭到恶意攻击
网络科技的不断发展同时，黑客的技术和渗透也是很强的，服务器和系统遭受到攻击已经是普遍存在的了。所有服务器都会面临这个问题，这个是无法预测的危险，我们只能实时做好安全防护，将被攻击的风险降至最低。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）