gg修改器显示未优化,gg修改器怎么开始不了

    《计算机站场地技术条件（GB 2887-89）》

    《计算机站场地安全要求（GB 9361）》

    《电子计算机机房设计规范（GB 50174－93）》

    《电总通信机房动力及环境监控规范书》

    《低压配电设计规范》(GB 50054－95)

    《保安电视监控工程技术规范》GA/T76–96

    《安全防范系统验收规则》(GA 308－2001)

    《安全防范工程程序与要求》(GA/T75-94)

    《建筑安装工程质量检验评定标准（GBJ 300－88）》

    《建筑与建筑群综合布线系统工程设计规范（CECS89:97）》

    《建筑与建筑群综合布线系统工程施工及验收规范》

本次机房监控系统的设计及建设是结合机房结构、设备内容、使用功能、操作对象和管理要求等综合因素进行考虑的，并做出合理的、适应特定工程使用和管理需要的设计。

机房监控的点表如下：

机房名称

UPS

空调

配电开关

配电质量

漏水

温湿度

视频

门禁

消防

防盗

新风

单位

台

台

路

路

米

台

台

道

个

个

套

主机房

2

24

15

5

4

2

1

2

1

动力机房

1

1

8

3

15

2

1

1

1

1

操作机房

1

1

钢瓶间

1

1

合计

1

3

32

3

30

7

5

5

3

4

1

表1：KingWeb机房监控系统点表

在机房配电柜总线、空调输入线路及UPS输入端分别加装1台智能电量检测仪，共3台。通过电量仪的智能接口，系统可全面检测市电进线配电柜的电源参数，例如三相电压、电流、频率、功率因数、有功功率、无功功率。管理人员通过系统远程查看各项参数，达到无人职守。

对于机房的重要配电开关，监视开关是否跳闸或断电等状态非常必要，一旦开关跳闸断电，计算机系统立即停止工作，将造成整个系统崩溃，如不尽快处理造成的损失将无法估计。本次监测配电柜输出端及重要机柜的共32路空气开关的闭合状态，有跳变则报警。

精密空调为机房创造符合要求的温湿度环境。通过空调通讯接口采集回/送风温度、回/送风湿度等模拟参数；包括回风温湿度上下限，压缩机、风机、加热器、加湿器、去湿器、滤网等报警信息；空调开/关机。

共监测2台精密空调。可通过监控系统对空调进行统一控制和管理

机房内有可能会产生漏水处（包括：空调下、给排水管及窗户附近等处），均采用漏水检测系统可将渗漏情况感应出来，将信号通过机房环境监控系统通知工作人员立即采取措施。

本次设计中将围绕3台空调安装一套定位式的漏水系统，敷设30米漏水感应绳，一旦有水泄漏碰到漏水绳，漏水绳上的监测点通过控制器将信号输到监控主机，系统在第一时间报警，监控界面自动切换到漏水监测画面上，漏水点精确到1米，相应的漏水点变红色闪烁并发出语音报警，可大大减少寻找水源的时间。

由于机房内系统繁多，人员出入控制的要求也较高，因此图像监控系统对整个机房突发事件及事后取证将提供不可估量的作用。采用数字监控系统对整个视频进行管理、图像侦测、识别、控制、存储以及检索。

主要针对机房所有出入口，共安装5台彩色半球摄像机，其中4台布置在主机房进门，动力机房1台，观察人员进入状况，并可以和其它系统设置联动。

1、图像监控系统功能

2、系统的联动

通过机房监控系统主平台“KingWeb平台”的内部信息共享，视频将与门禁、防盗报警或消防等系统集成后进行联动，系统能自动识别并响应其它设备的报警信号，协调运行。如门禁系统遭非法操作或消防报警，图像监控系统能自动命令就近的摄像机监视该部位的情况，同时发出报警信号并录像。

本次机房监控系统通过集成门禁管理主机达到对门禁系统的无缝集成。用户通过操作“KingWeb平台”达成对门禁系统管理的所有功能，很好地实现了资源共享的目的，也大大提高了管理效率。

在机房各道出入口各安装1台读卡器，其中主机房2道门，操作间、钢瓶间、动力机房各1道门，通过授权管理，只有持有效卡的的合法用户才能进出门禁控制区域，出入记录全部存贮在电脑中，出入口控制完全采用电子控制，保安人员只需在控制室中，就可对所有门禁区域进行监测和控制。

1、门禁管理系统功能

2、系统的联动

门禁控制主机通过与机房监控系统主平台“KingWeb平台”的接口通讯，与视频系统、消防报警等系统集成后，能自动识别并响应其它系统的报警信号，协调运行。如消防报警，门禁系统将自动打开所有门，视频监控系统能自动命令就近的摄像机监视该部位的情况，同时发出报警信号并录像。

根据要求，系统需要对新风机的运行状态进行实时监测。由新风机厂家提供新风机运行状态的干接点信号，通过采集该接点信号，对新风机的开关状态及报警状态进行监控，同时通过改造新风供电系统实现控制新风机的开启和关闭。

通过采集机房消防系统烟感探测器的报警信号实时监测机房区域的火灾情况。消防系统利用机房监控系统的多样稳定地报警方式，及时通知相关管理人员迅速采取行动，以尽可能减少损失。可联动门禁系统打开所有的门锁，并联动图像系统进行录像。

本工程所有的子系统在设计上不是仅仅将其作为一个独立的子系统，而是将其有机的融入机房环境集中管理系统之中，这样单系统的作用就不仅仅是实现各自监控功能，而是为整个数据中心在提高管理效率或提升功能方面需要的应用。

针对项目的实际需求，所有动力环境及安全防范设备将通过统一的监控系统平台软件进行集成管理，因此，该平台软件就成了本项目的核心。平台软件我们将选用专业机房监控平台《KingWeb信息集成平台软件》。它与后台服务器、前端采集设备、中间通讯设备一起组成了完整的“KingWeb机房监控系统”。

可通过监控终端、短信等方式对报警信息进行确认，在未收到确认前监控终端一直进行报警且间隔一定时间后再次发送报警短信。

（2）报警级别：系统具有强大的报警处理功能。可区分10级报警级别，报警事件发生时，系统按事件级别排队报警，显示处理，并将系统界面自动切换到相应的报警画面。系统管理员拥有更改任何报警级别的权利。

（3）报警参数设置：只有拥有系统管理员账号和密码，才可以对所有的报警参数、报警级别、报警界限进行修改。

（4）报警分析：系统管理员可以对所有报警事件的报警级别进行修改，如果不需要报警的事件可以屏蔽。

（5）系统默认保存一年的历史报警记录，所有人员都无法修改或者删除。

（6）系统自检报警：监控系统具有专家诊断功能，对通信中断、软件故障能够诊出故障并及时告警。监视各智能设备各部件的运行状态和工作参数。当监控系统非法退出时，监控系统可以自动重启。

（2）设备操作历史记录：系统将自动记录所有操作记录，包括操作人、操作对象、操作内容、登录及退出时间等。

系统用户可以在线进行监控对象的增加、修改和删除等管理功能，所有更改马上就能生效，无需重新启动监控系统。

（1）报表处理：系统对采集的数据进行处理，可生成报警统计报表、操作统计报表、历史统计报表等多种报表并打印出来；用户可以查看一年内所有报警的事件和操作记录，并且可以通过报表形式打印出来。

（2）系统根据采集的数据生成实时动态曲线图、历史数据曲线图等直观的曲线图标；系统可以对所有遥测数据都可以生成实时动态曲线图和历史曲线图。

（1）通过远程监控程序，可实现系统的远程监控；系统提供B/S（远程管理站/本地服务器）监控模式。

（2）系统可自动侦测通信故障，发生故障时提示；系统会自动侦测远程监控主机与监控中心管理主机之间的通讯，当通讯发生故障时，系统将以最高级别方式报警，并通知系统管理员。

（3）可扩展性：系统应留有与以后其它应用系统互联的接口；本系统的可扩展性非常高，所有功能都是通过模块化结构实现，对于日后系统的扩展与升级来说，十分方便。

（4）系统可通过手机短信接收订制的信息，并可向系统发送控制命令，控制设备启停或设置报警级别、报警上下限等任意属性。

根据通盘考虑，所有数据中心机房的众多设备需在一个整合了多种机房系统资源的集成大平台上得到统一管理，以解决因大量设备分散分布所带来的管理上的不便性，免除了众多不必要的外围设备而节省大量空间，使得各管理员可在监控室内从键盘、鼠标、显示器组成的控制台便可登陆所有的设备，方便快捷地排除机器故障，从而更有效地保障整体机房的正常运营。具体需求如下：

在综合考虑了以上各因素及反复探讨后，我方经过反复研究，推出以下合理化方案供各位领导参考。

根据机房整体设计考虑，建议数据中心不同部门分机房所有数据中心机房的众多设备，包括不同品牌服务器和不同操作系统服务器控制，需在一个整合了多种机房系统资源的集成大平台上得到统一管理，以解决信息孤岛和各厂商管理方式各自为政的问题，方便快捷地排除机器故障，从而更有效地保障整体机房的高效运营。

主要体现在以下几个方面：

系统安全性

系统安全方面，我方提供了Hub-Spoke结构的集中控管系统，将来扩展时，认证服务器之间数据自动同步，并且可以实现负载均衡，可以避免被控服务器数量将来过多及用户访问次数增加造成用户访问系统过渡拥挤而瘫痪，保证访问过程无阻塞性。

面对将来各种各样的服务器、路由器、交换机、电源等，其管理软件各自为政，各种软件只能承诺对单一或少量设备的管理，而无法实现一个界面上对所有设备的统一管理，我方采用的DSView 3软件使得管理人员在统一的平台及界面上集中控制管理服务器设备、串口设备、电源设备等，管理员对设备情况一目了然。集中控制系统还为以后加入各种新功能提供了保障，提供更进一步的硬件远端操控能力，包括服务器的物理健康特征，如温度、电压、电扇工作状态、电源供应以及机箱入侵等为系统管理、恢复以及资产管理提供信息，这样机房管理人员便可以随时随地在第一时间了解整个网络服务器系统的物理健康状况，以采取积极的应对措施，节省了客户将来的投资，降低数据中心的管理与维护成本，使机房的管理达到国际上新的成熟度标准。

根据总体机房建设要求以及以上需求说明，综合考虑系统的稳定性、服务器和网络的安全性、用户控制服务器和网络设备的合理性、应用需求的高效率性、体系架构冗余拓展性、统一管理性、降低维护成本性等多方面的因素。具体方案如下：

方案实现：

解决方案采用分布式Hub-Spoke架构，使得认证服务器的放置实现了异地化和多机并发处理。对于数据中心机房而言，可设置一台HUB（中心）和Spoke（分支）认证服务器，中心和分支后台数据同步；如需访问主机房中的终端设备，用户可直接通过HUB或Spoke认证服务器的用户和权限验证，建立与主机房内的相应终端设备之间的连接。如建立统一控制管理，访问A机房的终端设备可直接通过A机房认证服务器，节省了数据传输返回时间，实现了认证系统的负载均衡处理。当A机房本地认证服务器出现问题时，也可通过B认证服务器进行通信验证，同样可对机房内的终端设备实现远程操作。无论管理员是在不同楼层、不同楼宇还是出差在外地，同样操作也可实现同时控制操作数据中心机房。Avocent独有的分布式认证服务器架构特别适用于多地点机房的集中管理，已经在各大通信、金融行业数据中心中成功应用，该架构可以提高系统的可靠性（可实现16台认证服务器冗余），以及减少认证系统负载，从而保障多地点数据中心IT基础设施系统的完全可用性。

服务器设备逻辑分组说明

数据中心内服务器设备众多，可以对机房内服务器设备的逻辑划分说明如下：

首先，按照各服务器设备所属单位部门进行划分，如下图所示：

当用户需要时，还可对以上信息进行导出，保存为.CSV 文件，更方便用户直观地对具体服务器进行各项操作：

如此划分，无论是对于操作员还是管理员来说，都可方便地找出所需访问的服务器设备，尤其对于系统管理员来说，既可利用不同组别来查找不同服务器设备，亦可通过DSView系统独有的Filter功能，方便快捷地找出相应字段匹配的服务器设备。例如：需查找操作员“张杰”所负责的服务器，可在系统Filter栏处输入“张杰”字段，即可显示出操作员“张杰”所负责的所有服务器设备列表。
同时，也可根据不同的定义字段（如IP地址、部门、应用等）来搜检相应的服务器设备：如输入“51”字段，系统会自动将所有包含“51”字段的服务器列表检索出来：

DSView 3 集中控制管理平台有DSView 内部认证服务，它可以根据 DSView 3 软件服务器数据库中保存的用户帐户信息，来验证登录和密码。

DSView 3 软件还支持以下几种外部认证服务：

对于用户分组而言，可设三个不同优先级别的账号，分别具有不同的访问权限，管理便捷：

例如：设置用户“周彦倜”为系统超级用户，具有DSView Administrator权限，优先级最高，可对所有服务器设备进行访问并可随时断开任意用户的访问进程，还可进行系统设置操作；

设置用用户“蒋放”为组长，其具有对“科技部”组中的所有服务器设备的访问权限，可随时断开对该组设备有部分访问权限的组员的访问进程；

设置用户“张杰”为组员，其仅具有对“科技部”中几台服务器设备的基本管理权限。访问安全的顾虑

Avocent数字解决方案针对的应用，设置了6方面用户安全级别控制和保护方式：

可通过DSView系统针对不同用户设置不同等级的用户权限，管理相应的服务器；任一用户在访问终端设备前，必须先通过多冗余设计的认证服务器（Hub或Spoke）的严格权限验证（SSPI、AASP专用安全协议），成功后才能访问到具有相应的终端设备并进行相应权限的操作，此其间所有的鼠标、键盘及视频信号的传输皆采用可选方式的DES，3DES，128位SSL，AES加密算法，并可结合利用防火墙的端口设置等功能，最大程度地保障了系统的安全性能。

结合XXXXX外部认证系统，可指定用户在指定时间访问相应服务器设备，增强了系统的安全完备性。

可由DSView系统分配给各不同用户不同的用户权限。

DSView具有的强大功能使得系统可指定访问用户的IP地址列表，使得仅在此列表中存在的IP网段内的访问用户可以访问到DSView系统，防止了各种外部无效访问，大大增强了系统的严密性。

在DSView实现系统统一日志管理，功能包括：保存、查询、索引、归档，日志内容主要包括以下几个方面

事件日志主要用于记录设备在Console端口输出的包含有用户所定义关键字的系统信息，包含了发生事件、发生端口、信息内容，事件日志以表格方式记录在DSView的数据库中。

将ACS上的串口数据统一保存到DSView3中。串口数据中包含了重要的目标设备的系统信息，以及通过serial console对目标设备的配置或操作过程。数据日志主要用于记录设备在Console端口输入输出的信息，即网管人员在Console进行的操作信息，数据日志以文件的形式保存在DSView的文件系统中。ACS还支持NFS和Syslog协议，可以根据客户具体需求，将Console端口输入的信息，记录在相应的协议服务器上。

软件系统发生已定义且启用的事件，则将该事件保存在事件日志中。您可以显示事件日志内容、查看单个事件日志条目的详细信息，或删除事件日志条目。您可以设置在事件发生时将通知邮件发送至一个或多个地址。您可以更改事件日志的保留时间以及导出事件日志内容。

定义的事件可归类于以下类别：事件类别

然而，虚拟技术的引入也给IT机构的管理工作带来了许许多多的挑战。这些新的挑战主要应归咎于两个基本原因：

虚拟和物理服务器的混合为管理运营带来了新一层的复杂性。因此，IT机构必须重新思考新的方法，对这些动态混合程度越来越高的虚拟和物理服务器实施有效的管理。

Avocent集中控制管理平台DSView3.5可使管理者对物理IT资产与虚拟化设备进行统一的访问与控制管理，是业界第一种可以在统一平台上实现对虚拟和物理服务器的组合访问和控制，从而减少管理数据中心的费用和使复杂性的管理平台简单化。

AAA数据中心机房的机房区采用气体消防；气体灭火系统采用七氟丙烷自动灭火系统；系统具有自动、手动及机械应急启动三种控制方式。并与配电柜、新风和排风系统联动。

为保护一些不能用水扑救部位的避免火灾损失，广泛使用了气体消防。如证券、基金公司机房、电信机房、广播电视设备、发电机房等场所。气体灭火系统包括卤代烷（如七氟丙烷）、二氧化碳、惰性气体及烟雾灭火系统。

其中七氟丙烷气体灭火系统以其环保性、低毒性在计算机机房灭火系统中广泛采用。

七氟丙烷气体灭火系统在应用方式上可分为管网式和无管网式，下面我们就这二种应用形式进行分析。

当一个防护区的面积不大于500m2；容积不大于2000m3时采用管网式灭火系统；

管网式灭火系统图如下：

（单元独立系统原理图）

1.紧急启停按钮

2.放气指示灯

3.声报警器

4.光报警器

5.喷嘴

6.火灾探测器

7.电气控制线路

8.灭火剂输送管道

9.信号反馈装置

10.启动管路

11.集流管

12.灭火剂管路单向阀

13.安全泄压阀

14.压力软管

15.灭火剂容器阀

16.机械应急启动把手

17.瓶组架

18.灭火剂容器

19.启动装置

20.报警控制器

21.灭火控制器

当一个防护区的面积不大于100m2；容积不大于300m3时采用管网式灭火系统；

无管网式灭火系统图如下：

1.紧急启停按钮

2.放气指示灯

3.光报警器

4.声报警器

6.火灾探测器

7.喷嘴

8.信号反馈装置

9.集流管

10.灭火剂管路单向阀

11.压力软管

12.灭火剂容器阀

13.机械应急启动把手

14.柜体

15.灭火剂储存容器

16.启动管路

17.启动装置

18.报警灭火控制器

由于AAA数据中心机房需要气体消防的机房面积不超过200m2，容积不超过600m3，故建议选择无管网式灭火系统。

防护区为数据中心机房，共设  3   个防护区。

本系统具有自动、手动及机械应急启动三种控制方式。

●电气自动启动：

在防护区无人时，将灭火系统设置在自动控制状态。当防护区发生火情，报警及灭火控制器接收到感温和感烟探测器同时报警，发出火警声、光报警信号，同时，安装于防护区内的警铃、防护区门口的声光音响器发出声光报警信号，以提醒人员迅速撤离现场，继而联动相关设备（如防排烟阀，防火门、窗，风机，防火阀等），同时联动控制切断非消防电源，关闭空调。延时30s以后，灭火控制器发出灭火指令，触发与防护区相应的电磁先导阀使启动气瓶气瓶阀开启，释放启动气体，通过气控管路打开相应的选择阀和灭火剂储瓶瓶头阀，释放HFC-227ea灭火剂，实施灭火。在灭火剂开始喷放时，点亮防护区门口的气体释放门灯，直到手动消除。

●电气手动启动：

在防护区有人工作或值班时，灭火系统应设置在手动控制状态。当防护区发生火情，可按下灭火控制器上的直接输出按钮，或对设在防护区外的手动控制盒击碎玻璃，按下“紧急启动”按钮，即可按上述程序启动灭火系统，实施灭火。在自动控制状态，仍可实现电气手动控制。电气手动控制实施前，防护区内人员必须全部撤离。当发生火灾警报，在系统释放前的延时阶段，如发现有异常情况或判断火情不大，无需启动灭火系统时，可按下气体手动控制盒上的“急停”按钮，将终止灭火指令的发出，阻止选择阀和瓶头阀的打开，禁止灭火剂的喷放。

注意！不论何时，按下“急停”按钮后，系统将不能再次启动，需要到现场将该按钮恢复。

●紧急气动启动及机械应急手动启动：

当某一防护区发生火情，但由于电源发生故障或自动探测系统、控制系统失灵不能执行灭火指令时，应立即通知所有人员撤离现场，关闭联动设备。

●紧急气动启动：

电磁先导阀包含手动启动头，可用于手动启动。在保险销已拔掉的情况下，手动操作时，拉掉相应防护区启动气瓶电磁先导阀上部保险夹，用力拍击顶部顶块，即可打开电磁先导阀相连的气瓶阀从而启动系统。

●机械应急手动启动：

进入储瓶间打开与防护区域相对应的选择阀（即向后拉动选择阀上的转臂杆，翻转打开压臂使其敞开，靠灭火剂自身压力可打开。对于90L，DN32型瓶头阀，向后拉动各对应主储存瓶瓶头阀上的转臂，翻转打开压臂，打开主储存瓶瓶头阀，释放灭火气体，实施灭火。

防护区

面积（m2）

高度（m）

设计浓度（%）

设计喷射时间（s）

设计抑制时间（min）

56.84

3.5

27.71

3.5

9.43

3.54

防护区

七氟丙烷设

计用量（Kg）

七氟丙烷实

际用量（Kg）

使用储瓶数（个）

每瓶充装量（Kg）

储瓶容积（L）

主管径

66.5

61.5

66.5

66.5

66.5

66.5

参数

防护区

灭火设计浓度

灭火剂储瓶数（只）

喷头数量（只）

喷头规格

地板

房间

吊顶

地板

房间

吊顶

8%

8%

8%

管道公称直径（mm）

最大间距（m）

1.5

1.8

2.1

2.4

2.7

3.0

3.4

3.7

4.3

5.2

防护区门外应设警告牌和声光报警及释放信号标志。

只探测报警，发出火警信号。但当电气控制部分出现故障，或由于电源发生故障或自动探测报警系统失灵，不能执行灭火指令的情况下，采用应急手动启动。

应急手动启动必须在储瓶间进行。首先关闭影响灭火效果的设备，通知并确认人员已经撤离后，拉掉相应防护区启动气瓶上电磁先导阀上部保险夹，用力拍击顶部顶块，即可打开电磁先导阀相连的气瓶阀从而启动系统。灭火系统必须有专人负责，经常进行检查和维修、保养，保持良好的工作状况，检查方法与要求应根据设备厂家提供的说明书进行。

针对AAA数据中心机房的网络需求，以计算机网络运算准确无误及数据传输安全可靠、速度快的高标准，此次选用泛达超5类综合布线系统（结合语音系统）布线解决方案。

AAA数据中心机房的主要需求有：数据通讯/语音系统。结合AAA综合布线需求和我公司多年综合布线建设经验，我们提出以下综合布线工程解决方案。

综合布线系统工程设计应采用当今先进的网络技术，实现网络数据高速有序流通，最大限度保护网络的安全、稳定、高速性。

我们将严格按照ISO11801等国际布线标准设计及施工，将AAA数据中心机房建设成为一个技术先进、性能可靠、功能齐全的系统。系统应符合ISO/IEC11801:1995(E)等综合布线工程国际标准中的各项规定，还应满足以下要求：

AAA数据中心机房的局域网络系统是按照以太网（Ethernet）设计和规划的，为满足网络技术发展的需要，降低信息系统总投入成本，AAA的局域网系统建议按照千兆以太网规范设计。这不但能提升网络系统速度，对今后网络的扩展也留有余地。

信息点（含语音信息点）采用六类UTP布线系统。

由于语音信息点和数据信息点统一设计及施工，通过更改跳线，语音信息点和数据信息点可方便的互换使用，增强了布线系统的灵活性和可扩展性。

       根据计算机网络的发展要求，以及今后的发展趋势。综合布线我们建议选用Panduit系列布线产品。

       我们将结合多年的设计与施工经验，有效地配合贵方，为圆满完成贵方工程尽我们最大的智慧和力量。诚恳地希望贵方对我公司投标建议书的不妥之处，多提宝贵意见！

       机柜推荐采用APC机柜，选用规格为600*960*2000标准服务器机柜和800*800*2000网络机柜，42U。机房暂时设置8个服务器机柜，2个布线柜

       线槽选用国产镀锌1.0 厚铁线槽，一次冲压成型。线管选用国产1.7寸厚镀锌铁管，通过铜杯梳、铁直通等材料实现路由端接。

       在系统设计中首先要考虑的是选用的传输介质。综合布线系统有两类传输介质可选：六类；光纤；

       根据本项目实际需要，在设计中用六类传输介质构成整个系统。用最小的开销，最少的干扰更改路由。结构可以简单的通过空管、槽安装好，并可以方便的重新改变、增加路由。

施工过程由三个方面完成：管道安装，拉线安装和配件端接。

       在施工中经常可以看到下列情况：

       为了避免施工中出现上述问题，在ISO/IEC11801标准EIA/TIA569标准中规定：

       ◆双绞线拉线时的拉力不能超过13磅

       ◆光纤的拉力不能超过15磅

       我公司为了保证施工的质量，规定：拉线时每段线的长度不超过20米，超过部分必须有人接送；在线路转弯处必须有人接送；

       所有信息点电缆均引至配线系统内。经配线后连接到水平配线系统。再以水平配线系统主干线为中心连到各个RJ45接线盒。最后经各信息线缆连接到各种终端。

       所有线缆在地板下安装在铁皮线槽内（主干槽），从主干槽引至各工作区采用镀锌铁管安装，交换点使用转接头，保证线缆从主配线到工作区之间安装是封闭的，以防损坏。同时，铁槽要做好接地处理。

       所用交换机、配线架在机柜中。

       布线一般由远到近的区域进行拉线，以保证网线的最高利用率。

（最后一章了，加油！）

内积矩阵（这个树是前缀树Trie吗，待深入了解）（统计学习方法7.3.3节给出了一个更复杂的字符串核函数，能考虑到不连续的子串，以及子串长度衰减）

P678 认为存在隐变量的相关性）
监督主成分算法可以看成是拟合这个模型的方法：

算法18.1中系数不为0，（当且）仅当个主成分）（因子分析和PCA有必然联系吗？总感觉这里是概率PCA才对）
步骤2b中的回归是显然的

P679 假设一共增长相对较小，可以证明，在合理条件下，第一主成分与隐因子是一致的. 通常情形下的主成分可能不是一致的，因为它可能被大量的噪声特征所污染．（这里的一致感觉不够具体，另外渐近一致如何考虑？）

P679 假设在第1步使用的阈值产生大量的特征用于计算主成分．则为了解释性和实际应用，会寻找降维后的子集特征来近似模型．18.6.3节的预处理Pre-conditioning是其中

BH过程为什么对应的 FDR 至多为的证明相当复杂

至此，ESLII读完了。

参考文献：
[1]
[2]

一，当前KV数据库从存储介质可以分为两种模式：

1，一种是以内存为主持久化为辅，如memcache(无持久化)，redis等———-侧重高性能

2，一种是以持久化为主内存为辅，如ssdb(基于leveldb/rocksdb存储引擎)——-侧重大容量

方案一 改造redis，是它支持冷热分离

client—————–>proxy——-读写主redis——->redis(m)—-同步—->redis(s)

client——————>proxy—–读写ssdb———->ssdb(m)<—-同步——>ssdb(s)

实现描述：

写操作全部记录在内存，不同步写磁盘

内存中标记不存在的key,如果一个key在磁盘上不存在，则在标记之后不用再去磁盘查看这个值是否存在

缺点：基于redis做二次开发，后续不方便升级redis

分析：

redis定位是内存KV数据库，只支持所有数据存放在内存，持久化只是数据安全性的一种保障方式。

Jimdb S是京东基于redis2.8实现的KV数据库，用SSD(固态硬盘)持久化数据。

方案二 改造备redis和proxy,备redis落地数据

client——>proxy—–1,读写主redis——>redis(m)—-sync—->redis(s)

(sync)改造redis(s)—-r/w—>rocksdb/imdb

(sync)改造redis(s)—-r/w—>rocksdb/imdb

2,读主redis无数据，则读备redis   3，读备redis成功，写主redis

写操作时proxy正常写主redis，由改造备redis写rocksdb

读操作时proxy先正常读主redis，如无数据，则读改造备redis；改造备redis在内存中读不到数据则读rocksdb,

优点：写操作和当前流程完全一样；读操作和当前迁移流程中rrw流程基本一致，可以复用。不影响纯内存的原生redis使用，风险可控

缺点：proxy和redis均需修改。在原有一主一备redis基础上需要增加改造备redis部署。

分析：

最大特点是不影响纯内存的原生redis使用，且proxy改动较小

可以视情况选择部署一个或两个改造备redis。只部署一个改造备redis时落地数据是单点，可用于数据丢失不重要或后端另存有全量数据的场景。部署两个改造备redis可以避免单点，因为是链式同步，对主redis几乎无影响。

方案三 ：改造proxy，使用ssdb落地数据

实现描述：

写操作时proxy先正常写主redis，再同步或异步写ssdb

读操作时proxy先正常读redis，如redis无数据，则读ssdb;读ssdb成功，再写主redis

优点：只改proxy,redis无须改动

缺点：proxy实现较复杂，redis和ssdb的数据一致性不好保证。因为ssdb基于leveldb/rocksdb实现，在读操作且redis中无数据且ssdb内存中无数据时，可能极大影响性能。

方案四 提供ssdb,业务选择接入redis或ssdb

当前KV数据库从存储介质可以分为两种模式，一种是以内存为主持久化为辅，如memcache（无持久化）、redis等；一种是以持久化为主内存为辅，如ssdb（基于leveldb/rocksdb存储引擎）。这两种模式代表了两种不同的选择策略和哲学，适应不同的业务场景。简单地说，以内存为主的模式侧重高性能，信奉“内存是新的硬盘”的哲学；以持久化为主的模式则侧重大容量，兼顾性能。

这里冷热分离方案主要基于redis或者基于redis协议及命令实现。

2.1 方案一  改造redis，使之支持冷热分离

l  实现描述：

ü  可以使用开源的rocksdb或lmdb引擎读写落地数据；

ü  写操作全部记录在内存，不同步写磁盘；

ü  常驻写子进程定时将内存中的数据写到磁盘；

ü  内存中标记不存在的key，如果一个key在磁盘上不存在，则在标记之后不用再去磁盘查看这个值是否存在；

ü  读操作先读内存，如内存中不存在且key未被标识磁盘不存在，则由读子进程从磁盘读并写回到redis（key不存在才写回）。之后子进程通知主进程再次读取，此过程会阻塞主进程上单个连接的处理。

l  分析：

redis定位是内存KV数据库，只支持所有数据存放在内存，持久化只是数据安全性的一种保障方式。基于redis做冷热分离的例子有两个，一个是v2.0-2.4版的原生redis，一个是jimdb S，这两个做得都不成功。

Jimdb S是京东云平台基于redis2.8实现的KV数据库，用SSD持久化数据。使用Jimdb S可以保存全量数据，把缓存+数据库的两层架构用一层架构取代。写操作时先写内存，再异步写cycledb。读操作如数据不在内存，则创建后台任务读cycledb。这个后台任务的作用是预热，读到数据后并不把结果载入内存，执行完成后由前台主线程再次读取，这次在内存中读不到则直接读取cycledb并载入内存。目前了解到的情况是使用不广泛，而且即将下线。主要原因是性能不如纯内存的redis，但不知道是否还有其它缺陷。

方案二  改造备redis和proxy，备redis落地数据

l  实现描述：

ü  写操作时proxy正常写主redis，由改造备redis写rocksdb；

ü  读操作时proxy先正常读主redis，如无数据，则读改造备redis；改造备redis在内存中读不到数据则读rocksdb，proxy从改造备redis读到数据再写主redis。

l  优点：写操作和当前流程完全一样；读操作和当前迁移流程中rrw流程基本一致，可以复用。不影响纯内存的原生redis使用，风险可控。

l  缺点：proxy和redis均需修改。在原有一主一备redis基础上需要增加改造备redis部署。

l  分析：

最大特点是不影响纯内存的原生redis使用，且proxy改动较小。

可以视情况选择部署一个或两个改造备redis。只部署一个改造备redis时落地数据是单点，可用于数据丢失不重要或后端另存有全量数据的场景。部署两个改造备redis可以避免单点，因为是链式同步，对主redis几乎无影响。

方案三  改造proxy，使用ssdb落地数据

l  实现描述：

ü  写操作时proxy先正常写主redis，再同步或异步写ssdb；

ü  读操作时proxy先正常读redis，如redis无数据，则读ssdb；读ssdb成功，再写主redis。

l  优点：只改proxy，redis无须改动。

l  缺点：proxy实现较复杂，redis和ssdb的数据一致性不好保证。因为ssdb基于leveldb/rocksdb实现，在读操作且redis中无数据且ssdb内存中无数据时，可能极大影响性能。

方案四 提供ssdb，业务选择接入redis或ssdb

优点：无须开发，只需引入ssdb系统即可

缺点：业务开发可能没办法一开始确定使用哪一套系统。需要维护和运维两套系统

方案五 提供ssdb,业务初始化接入redis，可选择平滑迁入ssdb

实现描述：类似方案四，但可选择从redis平滑迁入ssdb

优点：只需开发proxy支持迁入ssdb系统即可

缺点：需要维护和运维两套系统

三：通用问题

1，读操作且redis中无数据的性能问题

不管是直接基于leveldb/rocksdb做数据落地，还是使用ssdb,都会碰到读操作且redis中无数据的性能问题，因此此时需要先读取redis，redis中读不到再一个level一个level去读磁盘文件，这种情况的性能可想而知不会太好

2，redis的淘汰

redis区分冷热数据都是设定redis的maxmemory,然后进行使内存中只保留热数据，而redis的lru淘汰只是从随机选的一些key选出最符合lru规则的一个key进行淘汰，即只是一种近似淘汰，所以不能很好地区分冷热数据。因此有可能出现被lru淘汰的key实际并不是冷数据，这样下次读取时会因为redis中已无数据而去磁盘读，出现一些性能问题。

3，写操作先写内存还是先写磁盘

先写内存，此时如果系统奔溃，内存中的数据还没来得及dump到磁盘，会丢失数据。先写磁盘，再写内存，则即使系统崩溃，不会造成数据的丢失，但可能导致磁盘和内存数据的不一致，为了避免这种不一致，又得先删除内存中的key，再写磁盘，再写内存，影响性能。总的来说，对于以内存为主的KV数据库，优先选择先写内存。

为了提高读写磁盘的性能，需要使用SSD。而SSD本身存在一些问题：

毛刺问题：同时读写SSD盘时，读SSD盘有可能会耗时数秒。被挂住的几率为万分之一；

坏盘问题：SSD坏盘几率比普通sas硬盘要高

坏块问题：SSD盘中可能存在某个块可以写入，但是读不出来，此时这个块的数据将会丢失

（

毛刺问题：

最近收到一封邮件，对于线上磁盘使用出现毛刺的分析。

）

五、附录

附各C/C++持久化KV数据库简介和分析：

l  Leveldb

LevelDb是google开源的能够处理十亿级别规模KV型数据持久性存储的C++程序库。LevleDb在存储数据时，是根据记录的key值有序存储。LevelDb的写操作要大大快于读操作，而顺序读写操作则大大快于随机读写操作。

level一个写操作仅涉及一次磁盘文件追加写和内存SkipList插入操作，因此leveldb的写操作非常高效。

由于 LevelDB 在某一层查找不存在的数据时, 会继续在下一层进行查找, 所以对于不存在的数据的查找会速度非常慢. 所以, 需要结合 Bloom Filter, 利用 Bloom Filter 能快速地判定”不存在”的特点。

l  Rocksdb

l  Lmdb

l  Ssdb

基于leveldb/rocksdb存储引擎实现，加入网络支持，兼容redis协议和redis数据类型（不支持set集合），支持主从复制和负载均衡。SSDB/LevelDB 在进行数据库整理(Compaction)操作时, 磁盘io高，持续的时间一般随着数据变大而变长, 一般只持续数秒。不能指定执行compaction的时间。有些redis命令不支持，有些支持的redis命令可能不完全和redis一致。

l  Fatcache

SSD上实现的memcached，内存中保存索引数据，机器重启索引数据会丢失。假如只需要支持string类型数据落地，可使用代替ssdb。

l  Tair

l  TTC

非严格意义上的KV数据库。支持无数据源和持久数据源两种工作模式。无数据源模式就是一个简单的基于共享内存的cache服务。持久数据源后接mysql，写操作先写db，再写内存；读操作先读内存，内存中不存在再去读db，读db成功再添加到内存。所以TTC本质上是一个带缓存功能的mysql数据库，可以想见其读写性能肯定不如纯内存数据库，也没有leveldb高效写的特点，注定是一个平庸的产品，再加上使用繁琐，早已被淘汰。

分布式KV内存数据库，支持主从同步和平滑迁移，数据可落地，高性能。仅做KV缓存还不错，但支持数据类型和命令不如redis丰富。
 

=======================================

============================================================

=============================================================================

Redis是单线程，但redis为什么这么快

((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((

一：缓存雪崩：如果缓存集中在一段时间内失效，发生大量的缓存穿透，所有的查询都落在数据库上，造成缓存雪崩

（大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。）

解决方法：

A，加锁排队。限流—-限流算法 1.计数 2.滑动窗口 3令牌桶Token Bucket 4漏桶leaky bucket

在缓存失效后，通过加锁 或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写数据，其他线程等待。

业界比较常用的做法，是使用mutex。简单来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db,而是先使用缓存工具的某些带成功操作返回值的操作当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。

C：做二级缓存，或者双缓存策略

A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期。

D：缓存永远不过期：

这里的“”永远不过期“”包含两层意思：

1）从缓存上看，确实没有设置过期时间，这就保证了，不会出现热点key过期问题，也就是“”物理“”不过期

2）从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期.

从实战看，这种方法对于性能非常友好，唯一不足的就是构建缓存时候，其余线程（非构建缓存的线程）可能访问的是老数据，但是对于一般的互联网功能来说这个还是可以忍受的。

二，缓存穿透：是指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。

)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))00

redis是一个开源的内存中的数据结构存储系统，它可以用作：数据库、缓存和消息中间件

它支持多种类型的数据结构，如字符串（String），散列（Hash），列表（List），集合（Set），有序集合（Sorted Set或者是ZSet）与范围查询，Bitmaps，Hyperloglogs 和地理空间（Geospatial）索引半径查询。其中常见的数据结构类型有：String、List、Set、Hash、ZSet这5种。

((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((

原文链接：http://rainybowe.com/blog/2017/07/13/%E7%A5%9E%E5%A5%87%E7%9A%84HyperLogLog%E7%AE%97%E6%B3%95/index.html?utm_source=tuicool&utm_medium=referral

基数计数(cardinality counting)通常用来统计一个集合中不重复的元素个数，例如统计某个网站的UV( unique visitor 网站独立访客——-独立IP：是指独立用户/。————–PV(访问量)：即, 即页面浏览量或 )，或者用户搜索网站的关键词数量。数据分析、网络监控及数据库优化等领域都会涉及到基数计数的需求。 要实现基数计数，最简单的做法是记录集合中所有不重复的元素集合S_uS​u​​，当新来一个元素x_ix​i​​，若S_uS​u​​中不包含元素x_ix​i​​，则将x_ix​i​​加入S_uS​u​​，否则不加入，计数值就是S_uS​u​​的元素数量。这种做法存在两个问题：

大数据量背景下，要实现基数计数，首先需要确定存储统计数据的方案，以及如何根据存储的数据计算基数值；另外还有一些场景下需要融合多个独立统计的基数值，例如对一个网站分别统计了三天的UV，现在需要知道这三天的UV总量是多少，怎么融合多个统计值。

B树最大的优势是插入和查找效率很高，如果用B树存储要统计的数据，可以快速判断新来的数据是否已经存在，并快速将元素插入B树。要计算基数值，只需要计算B树的节点个数。 将B树结构维护到内存中，可以快速统计和计算，但依然存在问题，B树结构只是加快了查找和插入效率，并没有节省存储内存。例如要同时统计几万个链接的UV，每个链接的访问量都很大，如果把这些数据都维护到内存中，实在是够呛。

bitmap可以理解为通过一个bit数组来存储特定数据的一种数据结构，每一个bit位都能独立包含信息，bit是数据的最小存储单位，因此能大量节省空间，也可以将整个bit数据一次性load到内存计算。 如果定义一个很大的bit数组，基数统计中每一个元素对应到bit数组的其中一位，例如bit数组 001101001001101001代表实际数组[2,3,5,8][2,3,5,8]。新加入一个元素，只需要将已有的bit数组和新加入的数字做按位或 (or)(or)计算。bitmap中1的数量就是集合的基数值。

实际上目前还没有发现更好的在大数据场景中准确计算基数的高效算法，因此在不追求绝对准确的情况下，使用概率算法算是一个不错的解决方案。概率算法不直接存储数据集合本身，通过一定的概率统计方法预估基数值，这种方法可以大大节省内存，同时保证误差控制在一定范围内。目前用于基数计数的概率算法包括:

下面将着重讲HLL的原理和计算过程。

上面我们计算过首先容我感叹一下数学的强大和魅力，那么概率算法是怎样做到如此节省内存的，又是怎样控制误差的呢？

这里有个可以看一下HLL到底是怎么做到这种超乎想象的事情的。

看到这里心里应该有无数个问号，这样真的就能统计到上亿条数据的基数了吗？我总结一下，先抛出三个疑问：

举一个我们最熟悉的抛硬币例子，出现正反面的概率都是1/2，一直抛硬币直到出现正面，记录下投掷次数kk，将这种抛硬币多次直到出现正面的过程记为一次伯努利过程，对于nn次伯努利过程，我们会得到nn个出现正面的投掷次数值k_1k​1​​,k_2k​2​​……k_nk​n​​，其中最大值记为k_{max}k​max​​，那么可以得到下面结论：

对于第一个结论，nn次伯努利过程的抛掷次数都不大于k_{max}k​max​​的概率用数学公式表示为： 
P_n(X le k_{max})=(1-1/2^{k_{max}})^nP​n​​(X≤k​max​​)=(1−1/2​k​max​​​​)​n​​

第二个结论至少有一次等于k_{max}k​max​​的概率用数学公式表示为： 
P_n(X ge k_{max})=1-(1-1/2^{k_{max}-1})^nP​n​​(X≥k​max​​)=1−(1−1/2​k​max​​−1​​)​n​​

以上结论可以总结为：进行了nn次进行抛硬币实验，每次分别记录下第一次抛到正面的抛掷次数kk，那么可以用n次实验中最大的抛掷次数k_{max}k​max​​来预估实验组数量nn： hat{n} = 2^{k_{max}}​n​^​​=2​k​max​​​​

可以通过一组小实验验证一下这种估计方法是否基本合理。

分桶平均的基本原理是将统计数据划分为mm个桶，每个桶分别统计各自的{k_{max}}k​max​​并能得到各自的基数预估值 hat{n}​n​^​​ ，最终对这些 hat{n}​n​^​​ 求平均得到整体的基数估计值。LLC中使用几何平均数预估整体的基数值，但是当统计数据量较小时误差较大；HLL在LLC基础上做了改进，采用调和平均数，调和平均数的优点是可以过滤掉不健康的统计值，具体的计算公式为：

上述经过分桶平均后的估计量看似已经很不错了，不过通过数学分析可以知道这并不是基数n的无偏估计。因此需要修正成无偏估计。这部分的具体数学分析在“”中。

根据论文中分析结论，HLL与LLC一样是渐进无偏估计，渐进标准误差表示为：

m = 2^b # with b in [4...16]

if m == 16:

alpha = 0.673

elif m == 32:

alpha = 0.697

elif m == 64:

alpha = 0.709

else:

alpha = 0.7213/(1 + 1.079/m)

registers = [0]*m # initialize m registers to 0

###########################################################################

# Construct the HLL structure

for h in hashed(data):

register_index = 1 + get_register_index( h,b ) # binary address of the rightmost b bits

run_length = run_of_zeros( h,b ) # length of the run of zeroes starting at bit b+1

registers[ register_index ] = max( registers[ register_index ], run_length )

##########################################################################

# Determine the cardinality

DV_est = alpha * m^2 * 1/sum( 2^ -register ) # the DV estimate

if DV_est < 5/2 * m: # small range correction

V = count_of_zero_registers( registers ) # the number of registers equal to zero

if V == 0: # if none of the registers are empty, use the HLL estimate

DV = DV_est

else:

DV = m * log(m/V) # i.e. balls and bins correction

if DV_est <= ( 1/30 * 2^32 ): # intermediate range, no correction

DV = DV_est

if DV_est > ( 1/30 * 2^32 ): # large range correction

DV = -2^32 * log( 1 - DV_est/2^32)

参考阅读

)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))

redis内置了复制，LUA脚本，LRU驱动事件(LRU eviction)，事务(Transaction)和不同级别的磁盘持久化，并通过redis哨兵（sentinel）和自动分区（cluster）提供高可用性（high availablity）

redis也提供了持久化的选项，这些选项可以让用户将自己的数据保存到磁盘上面进行存储。根据实际情况，可以每隔一定时间将数据集导出到磁盘（快照），或者追加到命令日志中（AOF只追加文件），

[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[

Redis提供的持久化机制

文章主要包含三个方面：Redis持久化是如何工作的、这一性能是否可靠以及和其它类型的数据库比较。以下为文章内容： 

一、Redis持久化是如何工作的？ 

　　什么是持久化？简单来讲就是将数据放到断电后数据不会丢失的设备中，也就是我们通常理解的硬盘上。

首先我们来看一下数据库在进行写操作时到底做了哪些事，主要有下面五个过程： 

故障分析 

写操作大致有上面5个流程，下面我们结合上面的5个流程看一下各种级别的故障： 

通过上面5步的了解，可能我们会希望搞清下面一些问题： 

　　对于第一个问题，通常数据库层面会进行全面控制。

　　而对第二个问题，操作系统有其默认的策略，但是我们也可以通过POSIX API提供的fsync系列命令强制操作系统将数据从内核区写到磁盘控制器上。

　　对于第三个问题，好像数据库已经无法触及，但实际上，大多数情况下磁盘缓存是被设置关闭的，或者是只开启为读缓存，也就是说写操作不会进行缓存，直接写到磁盘。

　　建议的做法是仅仅当你的磁盘设备有备用电池时才开启写缓存。 

数据损坏 

　　所谓数据损坏，就是数据无法恢复，上面我们讲的都是如何保证数据是确实写到磁盘上去，但是写到磁盘上可能并不意味着数据不会损坏。比如我们可能一次写请求会进行两次不同的写操作，当意外发生时，可能会导致一次写操作安全完成，但是另一次还没有进行。如果数据库的数据文件结构组织不合理，可能就会导致数据完全不能恢复的状况出现。 

这里通常也有三种策略来组织数据，以防止数据文件损坏到无法恢复的情况： 
 

　　RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。

　　也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。

可以通过配置设置自动做快照持久化的方式。我们可以配置redis在n秒内如果超过m个key被修改就自动做快照，下面是默认的快照保存配置

client 也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有 client的请求，这种方式会阻塞所有client请求。所以不推荐使用。

另一点需要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不 是增量的只同步脏数据。如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘io操作，可能会严重影响性能。

redis会将每一个收到的写命令都通过write函数追加到文件中(默认是 appendonly.aof)。

当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于os会在内核中缓存 write做的修改，所以可能不是立即写到磁盘上。这样aof方式的持久化也还是有可能会丢失部分修改。不过我们可以通过配置文件告诉redis我们想要 通过fsync函数强制os写入到磁盘的时机。有三种方式如下（默认是：每秒fsync一次）

aof 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用incr test命令100次，文件中必须保存全部的100条命令，其实有99条都是多余的。因为要恢复数据库的状态其实文件中保存一条set test 100就够了。

为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。收到此命令redis将使用与快照类似的方式将内存中的数据 以命令的方式保存到临时文件中，最后替换原来的文件。具体过程如下

需要注意到是重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。

使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。

AOF 文件是一个只进行追加操作的日志文件（append only log）， 因此对 AOF 文件的写入不需要进行 seek ， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等）， redis-check-aof 工具也可以轻易地修复这种问题。
Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。

根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。） 测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的。

一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。

如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。

1. Snapshotting:
缺省情况下，Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：
save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

2. Dump快照的机制：
1). Redis先fork子进程。
2). 子进程将快照数据写入到临时RDB文件中。
3). 当子进程完成数据写入操作后，再用临时文件替换老的文件。

5.4.3. AOF文件：
上面已经多次讲过，RDB的快照定时dump机制无法保证很好的数据持久性。如果我们的应用确实非常关注此点，我们可以考虑使用Redis中的AOF机制。对于Redis服务器而言，其缺省的机制是RDB，如果需要使用AOF，则需要修改配置文件中的以下条目：
将appendonly no改为appendonly yes
从现在起，Redis在每一次接收到数据修改的命令之后，都会将其追加到AOF文件中。在Redis下一次重新启动时，需要加载AOF文件中的信息来构建最新的数据到内存中。

5.4.5. AOF的配置：
在Redis的配置文件中存在三种同步方式，它们分别是：
appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no #从不同步。高效但是数据不会被持久化。

5.4.6. 如何修复坏损的AOF文件：
1). 将现有已经坏损的AOF文件额外拷贝出来一份。
2). 执行”redis-check-aof –fix <filename>”命令来修复坏损的AOF文件。
3). 用修复后的AOF文件重新启动Redis服务器。

5.4.7. Redis的数据备份：
在Redis中我们可以通过copy的方式在线备份正在运行的Redis数据文件。这是因为RDB文件一旦被生成之后就不会再被修改。Redis每次都是将最新的数据dump到一个临时文件中，之后在利用rename函数原子性的将临时文件改名为原有的数据文件名。因此我们可以说，在任意时刻copy数据文件都是安全的和一致的。鉴于此，我们就可以通过创建cron job的方式定时备份Redis的数据文件，并将备份文件copy到安全的磁盘介质中。

5.5、立即写入

运行结果：

这里的save方法是同步的，没有写入完成前不执行后面的代码。

5.6、异步写入

如果数据量非常大，要保存的内容很多，建议使用bgsave，如果内容少则可以使用save方法。关于各方式的比较源自网友的博客。

1、Redis的第一个持久化策略：RDB快照 

Redis支持将当前数据的快照存成一个数据文件的持久化机制。而一个持续写入的数据库如何生成快照呢。Redis借助了fork命令的copy on write机制。在生成快照时，将当前进程fork出一个子进程，然后在子进程中循环所有的数据，将数据写成为RDB文件。 

我们可以通过Redis的save指令来配置RDB快照生成的时机，比如你可以配置当10分钟以内有100次写入就生成快照，也可以配置当1小时内有1000次写入就生成快照，也可以多个规则一起实施。这些规则的定义就在Redis的配置文件中，你也可以通过Redis的CONFIG SET命令在Redis运行时设置规则，不需要重启Redis。 

Redis的RDB文件不会坏掉，因为其写操作是在一个新进程中进行的，当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性rename系统调用将临时文件重命名为RDB文件，这样在任何时候出现故障，Redis的RDB文件都总是可用的。 

同时，Redis的RDB文件也是Redis主从同步内部实现中的一环。 

但是，我们可以很明显的看到，RDB有它的不足，就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，从上次RDB文件生成到 Redis停机这段时间的数据全部丢掉了。在某些业务下，这是可以忍受的，我们也推荐这些业务使用RDB的方式进行持久化，因为开启RDB的代价并不高。 但是对于另外一些对数据安全性要求极高的应用，无法容忍数据丢失的应用，RDB就无能为力了，所以Redis引入了另一个重要的持久化机制：AOF日志。 

2、Redis的第二个持久化策略：AOF日志 

AOF日志的全称是Append Only File，从名字上我们就能看出来，它是一个追加写入的日志文件。与一般数据库不同的是，AOF文件是可识别的纯文本，它的内容就是一个个的Redis标准命令。比如我们进行如下实验，使用Redis2.6 版本，在启动命令参数中设置开启AOF功能：

./redis-server --appendonly yes

　　然后我们执行如下的命令：

redis 127.0.0.1:6379> set key1 Hello

OK

redis 127.0.0.1:6379> append key1 " World"

(integer) 12

redis 127.0.0.1:6379> del key1

(integer) 1

redis 127.0.0.1:6379> del non_existing_key

(integer) 0

　　这时我们查看AOF日志文件，就会得到如下内容：

$ cat appendonly.aof

*2

$6

SELECT

$1

0

*3

$3

set

$4

key1

$5

Hello

*3

$6

append

$4

key1

$7

 World

*2

$3

del

$4

key1

]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]