13518219792
腾讯云包括云服务器、云数据库、CDN、云安全、万象图片和云点播等产品。
创新互联建站于2013年开始，先为巴州等服务建站，巴州等地企业，进行企业商务咨询服务。为巴州企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
开发者通过接入腾讯云平台，可降低初期创业的成本，能更轻松地应对来自服务器、存储以及带宽的压力。 云服务器
高性能高稳定的云虚拟机，可在云中提供弹性可调节的计算容量，不让计算能束缚您的想象；您可以轻松购买自定义配置的机型，在几分钟内获取到新服务器，并根据您的需要使用镜像进行快速的扩容。
弹性web 服务
弹性Web 引擎（Cloud Elastic Engine）是一种Web 引擎服务，是一体化web 应用运行环境，弹性伸缩，中小开发者的利器。通过提供已部署好php、nginx 等基础web 环境，让您仅需上传自己的代码，即可轻松地完成web 服务的搭建。
负载均衡
腾讯云负载均衡服务，用于将业务流量自动分配到多个云服务器、弹性web 引擎等计算单元的服务，帮您构建海量访问的业务能力，以及实现高水平的业务容错能力。腾讯云提供公网及内外负载均衡，分别处理来自公网和云内的业务流量分发。 云数据库
云数据库（CDB:Cloud Data Base）是腾讯云平台提供的面向互联网应用的数据存储服务。
NoSQL 高速存储
腾讯NoSQL 高速存储，是腾讯自主研发的极高性能、内存级、持久化、分布式的Key-Value存储服务。NoSQL 高速存储以最终落地存储来设计，拥有数据库级别的访问保障和持续服务能力。支持Memcached 协议，能力比Memcached 强（能落地），适用Memcached、TTServer 的地方都适用NoSQL 高速存储。NoSQL 高速存储解决了内存数据可靠性、分布式及一致性上的问题，让海量访问业务的开发变得简单快捷。
对象存储服务(beta)
对象存储服务（COS:Cloud Object Service），是腾讯云平台提供的对象存储服务。COS 为开发者提供安全、稳定、高效、实惠的对象存储服务，开发者可以将任意动态、静态生成的数据，存放到COS 上，再通过HTTP 的方式进行访问。COS 的文件访问接口提供全国范围内的动态加速，使开发者无需关注网络不同所带来的体验问题。
CDN
CDN（Content Delivery Network）即内容分发网络。腾讯CDN 服务的目标与一般意义上的CDN 服务是一样的，旨在将开发者网站中提供给终端用户的内容（包括网页对象—文本、图片、脚本，可下载的对象—多媒体文件、软件、文档，等等），发布到多个数据中心的多台服务器上，使用户可以就近取得所需的内容，提高用户访问网站的响应速度。 云监控
腾讯云监控是面向腾讯云客户的一款监控服务，能够对客户购买的云资源以及基于腾讯云构建的应用系统进行实时监测。开发人员或者系统管理员可以通过腾讯云监控收集各种性能指标，了解其系统运行的相关信息，并做出实时响应，保证自己的服务正常运行。
腾讯云监控提供了可靠，灵活的监控解决方案，当您首次购买云服务后，不需要任何设置，就可以获得基础监控指标，同时，也可以通过简单的步骤后，获取到更多的个性化指标。除了丰富的监控指标视图以外，腾讯云监控还提供个性化的告警服务，客户可以对任意监控指标自定义告警策略。通过短信，邮件，微信等方式，实时推送故障告警。
腾讯云监控也是一个开放式的监控平台，支持用户上报个性化的指标，提供多个维度，多种粒度的实时数据统计以及告警分析。并提供开放式的API，让客户通过接口也能够获取到监控数据。
云安全
腾讯公司安全团队在处理各种安全问题的过程中积累了丰富的技术和经验，腾讯云安全将这些宝贵的安全技术和经验打造成优秀的安全服务产品，为开发商提供业界领先的安全服务。腾讯云安全能够帮助开发商免受各种攻击行为的干扰和影响，让客户专注于自己创新业务的发展，极大的降低了客户在基础环境安全和业务安全上的投入和成本。
云拨测
云拨测依托腾讯专有的服务质量监测网络，利用分布于全球的服务质量监测点，对用户的网站，域名，后台接口等进行周期性监控， 并提供实时告警, 性能和可用性视图展示，智能分析等服务。 TOD 大数据处理
TOD 是腾讯云为用户提供的一套完整的、开箱即用的云端大数据处理解决方案。开发者可以在线创建数据仓库，编写、调试和运行SQL 脚本，调用MR程序，完成对海量数据的各种处理。另外开发者还可以将编写的数据处理脚本定义成周期性执行的任务，通过可视化界面拖拽定义任务间依赖关系，实现复杂的数据处理工作流。主要应用于海量数据统计、数据挖掘等领域。已经为微信、QQ 空间、广点通、腾讯游戏、财付通、QQ 网购等关键业务的提供了数据分析服务。
腾讯云分析
腾讯云分析是一款专业的移动应用统计分析工具，支持主流智能手机平台。开发者可以方便地通过嵌入统计SDK，实现对移动应用的全面监测，实时掌握产品表现，准确洞察用户行为。不仅仅是记录，移动APP 统计还分析每个环节，利用数据透过现象看本质。腾讯云分析还同时提供业内市场排名趋势、竞品排名监控等情报信息，让您在应用开发运营过程中，知己知彼，百战百胜。
腾讯云搜
腾讯云搜（Tencent Cloud Search）是腾讯公司基于在搜索领域多年的技术积累，对公司内部各大垂直搜索业务搜索需求进行高度抽象， 把搜索引擎组件化、平台化、服务化，最终形成成熟的搜索对外开放能力，为广大移动应用开发者和网站站长推出的一站式结构化数据搜索托管服务。 移动加速
移动加速服务是腾讯云针对终端应用提供的访问加速服务，通过加速机房、优化路由算法、动态数据压缩等多重措施提升移动应用的访问速度和用户体验，并为客户提供了加速效果展示、趋势对比、异常告警等运营工具随时了解加速效果。
应用加固
应用加固服务是腾讯云依托多年终端安全经验，提供的一项终端应用安全加固服务。具有操作简单、多渠道监控、防反编译防篡改防植入、零影响的特点，帮助用户保护应用版权和收入。
腾讯云安全认证
腾讯云安全认证是腾讯云提供的免费安全认证服务，通过申请审核的用户将获得权威的腾讯云认证展示，让您的业务获得腾讯亿万用户的认可。免费安全服务，权威认证展示，腾讯云已为2.6万网站、应用保驾护航。
信鸽推送
信鸽（XG Push）是一款专业的免费移动App 推送平台，支持百亿级的通知/ 消息推送，秒级触达移动用户，现已全面支持Android 和iOS 两大主流平台。开发者可以方便地通过嵌入SDK，通过API 调用或者Web 端可视化操作，实现对特定用户推送，大幅提升用户活跃度，有效唤醒沉睡用户，并实时查看推送效果。
域名备案
腾讯云备案服务，帮助您将网站在工信部系统中进行登记，获得备案证书悬挂在网站底部。目前支持企业、个人、政府机关、事业单位、社会团体备案。
云API
云API 是构建云开放生态重要的一环。腾讯云提供的计算、数据、运营运维等基础能力，包括云服务器、云数据库、CDN 和对象存储服务等，以及腾讯云分析（MTA）、腾讯云推送（信鸽）等大数据运营服务等，都将以标准的开放API 的形式提供给广大企业和开发者使用，方便开发者集成和二次开发。
万象图片
万象图片是将QQ空间相册积累的十年图片经验开放给开发者，提供专业一体化的图片解决方案，涵盖图片上传、下载、存储、图像处理。
维纳斯
维纳斯(Wireless Network Service)专业的移动网络接入服务，使用腾讯骨干网络，全国400个节点，连通成功率99.9%。
云点播
腾讯云一站式视频点播服务，汇聚腾讯强大视频处理能力。从灵活上传到快速转码，从便捷发布到自定义播放器开发，为客户提供专业可靠的完整视频服务。
当前主流的关系型数据库有Oracle、DB2、Microsoft SQL Server、Microsoft Access、MySQL等。
非关系型数据库有 NoSql、Cloudant。
nosql和关系型数据库比较？
优点：
1）成本：nosql数据库简单易部署，基本都是开源软件，不需要像使用oracle那样花费大量成本购买使用，相比关系型数据库价格便宜。
2）查询速度：nosql数据库将数据存储于缓存之中，关系型数据库将数据存储在硬盘中，自然查询速度远不及nosql数据库。
3）存储数据的格式：nosql的存储格式是key,value形式、文档形式、图片形式等等，所以可以存储基础类型以及对象或者是集合等各种格式，而数据库则只支持基础类型。
4）扩展性：关系型数据库有类似join这样的多表查询机制的限制导致扩展很艰难。
缺点：
1）维护的工具和资料有限，因为nosql是属于新的技术，不能和关系型数据库10几年的技术同日而语。
2）不提供对sql的支持，如果不支持sql这样的工业标准，将产生一定用户的学习和使用成本。
3）不提供关系型数据库对事物的处理。
因人而异
自学肯定也是可以的，最主要还是要看个人的学习能力，意志力，和自己的决心，
下面我就说一下，在自学时需要注意的一些误区和如何自学前端知识。
前端自学者存在的学习误区：
1、所学东西可能已过时
奉为经典的东西可能已经过时，或者已经有了更好的替代者，而你获取信息的渠道有限，消息滞后，导致学习的内容也相对滞后。
2、学习方法盲目。
看书看不懂就找视频类教程学习，觉得教程跟自己的口味不符就另寻他法，因为自己缺少对资源的辨识能力，总是在没有清晰规划学习线路的情况就盲目学习，导致无效学习时间过长而收获寥寥。
3、只有理论，缺乏真实项目锻炼。
对技术的理解停留在理论层次，而缺乏真实企业项目的历练，如果没有相关实习或工作经历，对前端岗位具体的责任划分和工作流程了解不充分。
如何自学前端知识：
自学方法：
1、作为一个初学者，你必须明确系统的学习方案，我建议一定有一个指导的人，全靠自己学，放弃的几率非常大，在你对于web前端还没有任何概念的时候，需要一个人领进门，之后就都靠自己钻研，第一步就是确定web前端都需要哪些内容，并且在多少时间内学完，建议时间6个月保底。
2、视频为主，书为辅。很多初学者在学习前端的时候非常喜欢去买书，但是最后的结果是什么？看来看去什么都不会写，所以在这里给大家提醒，书可以看，但是是在建立于你已经对于某个知识点有了具体操作的执行后，在用书去巩固概念，这样更加利于你对于知识的理解。
3、对于学习技术来讲，掌握一个学习方法是非常重要的，其实对于学习web前端来讲，学习方法确实很多都是相通的，一旦学习方法不对，可能就会造成“方法不对，努力白费”。其实关于这方面还是很多的，我就简单说个例子，有的人边听课边跟着敲代码，这样就不对，听课的时候就专心听，做题的时候就专心做题，这都是过来人的经验，一定要听。根据每个人的不同，可能学习方法也会有所出路，找到适合你自己的学习法方法是学习的前提。
4、不建议自己一个人瞎学，在我了解学习编程的这些人来看，从零基础开始学并且最后成功做这份工作的其实并没有几个，我觉得大部分原因就是因为他们都不了解web前端是干什么的，学什么的，就盲目的买书看，到处找视频看，最后看着看着就放弃了，所以我建议初学者在没有具体概念之前，还是找有经验的人请教一下，聊过之后你就会知道web前端具体是干什么的，该怎么学，这是我个人的小建议，可以不采纳。
学前端的话，书籍是必不可少的：
1、《JavaScript高级程序设计(第3版) 红皮书 》，适合有一定编程经验的Web应用开发人员阅读，也可作为高校及社会实用技术培训相关专业课程的教材。
2、《JavaScript权威指南(第6版)》 犀牛书，本书不仅适合初学者系统学习，也适合有经验的 JavaScript 开发者随手翻阅。
3、《JavaScript DOM编程艺术 (第2版)》，本书在简洁明快地讲述JavaScript和DOM的基本知识之后，通过几个实例演示了专业水准的网页开发技术，透彻阐述了平稳退化等一批至关重要的 JavaScript编程原则和最佳实践，并全面探讨了HTML5以及jQuery等JavaScript库。
4、《CSS权威指南(第三版)》，不管你是一个有经验的Web开发人员还是一个彻底的初学者，《CSS权威指南(第3版)》都是你的CSS学习源泉。
5、《JavaScript设计模式》，适合JavaScript初学者、前端设计者、JavaScript程序员学习，也可以作为大专院校相关专业师生的学习用书，以及培训学校的教材。
6、《你不知道的JavaScript(上中下卷) 》，本书既适合JavaScript语言初学者了解其精髓，又适合经验丰富的JavaScript开发人员深入学习。
7、《Vue.js权威指南》，该书内容全面，讲解细致，实例丰富，适用于各层次的开发者。
学习路线：
第1阶段：前端页面重构(4周)
内容包含了：(PC端网站布局项目、HTML5+CSS3基础项目、WebApp页面布局项目)
第2阶段：JavaScript高级程序设计(5周)
内容包含：(原生JavaScript交互功能开发项目、面向对象进阶与ES5/ES6应用项目、JavaScript工具库自主研发项目)
第3阶段：PC端全栈项目开发(3周)
内容包含：(jQuery经典交互特效开发、HTTP协议、Ajax进阶与PHP/JAVA开发项目、前端工程化与模块化应用项目、PC端网站开发项目、PC端管理信息系统前端开发项目)
第4阶段：移动端项目开发(6周)
内容包含：(Touch端项目、微信场景项目、应用Angular+Ionic开发WebApp项目、应用Vue.js开发WebApp项目、应用React.js开发WebApp项目)
第5阶段：混合(Hybrid,ReactNative)开发(1周)
内容包含：(微信小程序开发、ReactNative、各类混合应用开发)
第6阶段：NodeJS全栈开发(1周)
内容包括：(WebApp后端系统开发、一、NodeJS基础与NodeJS核心模块二、Express三、noSQL数据库)
视频教程：
网页链接
Redis的作者Salvatore Sanfilippo曾经对这两种基于内存的数据存储系统进行过比较：
1、Redis支持服务器端的数据操作：Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作，通常在Memcached里，你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的GET/SET一样高效。所以，如果需要缓存能够支持更复杂的结构和操作，那么Redis会是不错的选择。
2、内存使用效率对比：使用简单的key-value存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。
3、性能对比：由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis最近也在存储大数据的性能上进行优化，但是比起Memcached，还是稍有逊色。
具体为什么会出现上面的结论，以下为收集到的资料：
1、数据类型支持不同
与Memcached仅支持简单的key-value结构的数据记录不同，Redis支持的数据类型要丰富得多。最为常用的数据类型主要由五种：String、Hash、List、Set和Sorted Set。Redis内部使用一个redisObject对象来表示所有的key和value。redisObject最主要的信息如图所示：
type代表一个value对象具体是何种数据类型，encoding是不同数据类型在redis内部的存储方式，比如：type=string代表value存储的是一个普通字符串，那么对应的encoding可以是raw或者是int，如果是int则代表实际redis内部是按数值型类存储和表示这个字符串的，当然前提是这个字符串本身可以用数值表示，比如:”123″ “456”这样的字符串。只有打开了Redis的虚拟内存功能，vm字段字段才会真正的分配内存，该功能默认是关闭状态的。
1）String
常用命令：set/get/decr/incr/mget等；
应用场景：String是最常用的一种数据类型，普通的key/value存储都可以归为此类；
实现方式：String在redis内部存储默认就是一个字符串，被redisObject所引用，当遇到incr、decr等操作时会转成数值型进行计算，此时redisObject的encoding字段为int。
2）Hash
常用命令：hget/hset/hgetall等
应用场景：我们要存储一个用户信息对象数据，其中包括用户ID、用户姓名、年龄和生日，通过用户ID我们希望获取该用户的姓名或者年龄或者生日；
实现方式：Redis的Hash实际是内部存储的Value为一个HashMap，并提供了直接存取这个Map成员的接口。如图所示，Key是用户ID, value是一个Map。这个Map的key是成员的属性名，value是属性值。这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据。当前HashMap的实现有两种方式：当HashMap的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，这时对应的value的redisObject的encoding为zipmap，当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。
请点击输入图片描述
3）List
常用命令：lpush/rpush/lpop/rpop/lrange等；
应用场景：Redis list的应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现；
实现方式：Redis list的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。
4）Set
常用命令：sadd/spop/smembers/sunion等；
应用场景：Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的；
实现方式：set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。
5）Sorted Set
常用命令：zadd/zrange/zrem/zcard等；
应用场景：Redis sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序。当你需要一个有序的并且不重复的集合列表，那么可以选择sorted set数据结构，比如twitter 的public timeline可以以发表时间作为score来存储，这样获取时就是自动按时间排好序的。
实现方式：Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。
2、内存管理机制不同
在Redis中，并不是所有的数据都一直存储在内存中的。这是和Memcached相比一个最大的区别。当物理内存用完时，Redis可以将一些很久没用到的value交换到磁盘。Redis只会缓存所有的key的信息，如果Redis发现内存的使用量超过了某一个阀值，将触发swap的操作，Redis根据“swappability = age*log(size_in_memory)”计算出哪些key对应的value需要swap到磁盘。然后再将这些key对应的value持久化到磁盘中，同时在内存中清除。这种特性使得Redis可以保持超过其机器本身内存大小的数据。当然，机器本身的内存必须要能够保持所有的key，毕竟这些数据是不会进行swap操作的。同时由于Redis将内存中的数据swap到磁盘中的时候，提供服务的主线程和进行swap操作的子线程会共享这部分内存，所以如果更新需要swap的数据，Redis将阻塞这个操作，直到子线程完成swap操作后才可以进行修改。当从Redis中读取数据的时候，如果读取的key对应的value不在内存中，那么Redis就需要从swap文件中加载相应数据，然后再返回给请求方。 这里就存在一个I/O线程池的问题。在默认的情况下，Redis会出现阻塞，即完成所有的swap文件加载后才会相应。这种策略在客户端的数量较小，进行批量操作的时候比较合适。但是如果将Redis应用在一个大型的网站应用程序中，这显然是无法满足大并发的情况的。所以Redis运行我们设置I/O线程池的大小，对需要从swap文件中加载相应数据的读取请求进行并发操作，减少阻塞的时间。
对于像Redis和Memcached这种基于内存的数据库系统来说，内存管理的效率高低是影响系统性能的关键因素。传统C语言中的malloc/free函数是最常用的分配和释放内存的方法，但是这种方法存在着很大的缺陷：首先，对于开发人员来说不匹配的malloc和free容易造成内存泄露；其次频繁调用会造成大量内存碎片无法回收重新利用，降低内存利用率；最后作为系统调用，其系统开销远远大于一般函数调用。所以，为了提高内存的管理效率，高效的内存管理方案都不会直接使用malloc/free调用。Redis和Memcached均使用了自身设计的内存管理机制，但是实现方法存在很大的差异，下面将会对两者的内存管理机制分别进行介绍。
Memcached默认使用Slab Allocation机制管理内存，其主要思想是按照预先规定的大小，将分配的内存分割成特定长度的块以存储相应长度的key-value数据记录，以完全解决内存碎片问题。Slab Allocation机制只为存储外部数据而设计，也就是说所有的key-value数据都存储在Slab Allocation系统里，而Memcached的其它内存请求则通过普通的malloc/free来申请，因为这些请求的数量和频率决定了它们不会对整个系统的性能造成影响Slab Allocation的原理相当简单。 如图所示，它首先从操作系统申请一大块内存，并将其分割成各种尺寸的块Chunk，并把尺寸相同的块分成组Slab Class。其中，Chunk就是用来存储key-value数据的最小单位。每个Slab Class的大小，可以在Memcached启动的时候通过制定Growth Factor来控制。假定图中Growth Factor的取值为1.25，如果第一组Chunk的大小为88个字节，第二组Chunk的大小就为112个字节，依此类推。
请点击输入图片描述
当Memcached接收到客户端发送过来的数据时首先会根据收到数据的大小选择一个最合适的Slab Class，然后通过查询Memcached保存着的该Slab Class内空闲Chunk的列表就可以找到一个可用于存储数据的Chunk。当一条数据库过期或者丢弃时，该记录所占用的Chunk就可以回收，重新添加到空闲列表中。从以上过程我们可以看出Memcached的内存管理制效率高，而且不会造成内存碎片，但是它最大的缺点就是会导致空间浪费。因为每个Chunk都分配了特定长度的内存空间，所以变长数据无法充分利用这些空间。如图 所示，将100个字节的数据缓存到128个字节的Chunk中，剩余的28个字节就浪费掉了。
请点击输入图片描述
Redis的内存管理主要通过源码中zmalloc.h和zmalloc.c两个文件来实现的。Redis为了方便内存的管理，在分配一块内存之后，会将这块内存的大小存入内存块的头部。如图所示，real_ptr是redis调用malloc后返回的指针。redis将内存块的大小size存入头部，size所占据的内存大小是已知的，为size_t类型的长度，然后返回ret_ptr。当需要释放内存的时候，ret_ptr被传给内存管理程序。通过ret_ptr，程序可以很容易的算出real_ptr的值，然后将real_ptr传给free释放内存。
请点击输入图片描述
Redis通过定义一个数组来记录所有的内存分配情况，这个数组的长度为ZMALLOC_MAX_ALLOC_STAT。数组的每一个元素代表当前程序所分配的内存块的个数，且内存块的大小为该元素的下标。在源码中，这个数组为zmalloc_allocations。zmalloc_allocations[16]代表已经分配的长度为16bytes的内存块的个数。zmalloc.c中有一个静态变量used_memory用来记录当前分配的内存总大小。所以，总的来看，Redis采用的是包装的mallc/free，相较于Memcached的内存管理方法来说，要简单很多。
3、数据持久化支持
Redis虽然是基于内存的存储系统，但是它本身是支持内存数据的持久化的，而且提供两种主要的持久化策略：RDB快照和AOF日志。而memcached是不支持数据持久化操作的。
1）RDB快照
Redis支持将当前数据的快照存成一个数据文件的持久化机制，即RDB快照。但是一个持续写入的数据库如何生成快照呢？Redis借助了fork命令的copy on write机制。在生成快照时，将当前进程fork出一个子进程，然后在子进程中循环所有的数据，将数据写成为RDB文件。我们可以通过Redis的save指令来配置RDB快照生成的时机，比如配置10分钟就生成快照，也可以配置有1000次写入就生成快照，也可以多个规则一起实施。这些规则的定义就在Redis的配置文件中，你也可以通过Redis的CONFIG SET命令在Redis运行时设置规则，不需要重启Redis。
Redis的RDB文件不会坏掉，因为其写操作是在一个新进程中进行的，当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性rename系统调用将临时文件重命名为RDB文件，这样在任何时候出现故障，Redis的RDB文件都总是可用的。同时，Redis的RDB文件也是Redis主从同步内部实现中的一环。RDB有他的不足，就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。在某些业务下，这是可以忍受的。
2）AOF日志
AOF日志的全称是append only file，它是一个追加写入的日志文件。与一般数据库的binlog不同的是，AOF文件是可识别的纯文本，它的内容就是一个个的Redis标准命令。只有那些会导致数据发生修改的命令才会追加到AOF文件。每一条修改数据的命令都生成一条日志，AOF文件会越来越大，所以Redis又提供了一个功能，叫做AOF rewrite。其功能就是重新生成一份AOF文件，新的AOF文件中一条记录的操作只会有一次，而不像一份老文件那样，可能记录了对同一个值的多次操作。其生成过程和RDB类似，也是fork一个进程，直接遍历数据，写入新的AOF临时文件。在写入新文件的过程中，所有的写操作日志还是会写到原来老的AOF文件中，同时还会记录在内存缓冲区中。当重完操作完成后，会将所有缓冲区中的日志一次性写入到临时文件中。然后调用原子性的rename命令用新的AOF文件取代老的AOF文件。
AOF是一个写文件操作，其目的是将操作日志写到磁盘上，所以它也同样会遇到我们上面说的写操作的流程。在Redis中对AOF调用write写入后，通过appendfsync选项来控制调用fsync将其写到磁盘上的时间，下面appendfsync的三个设置项，安全强度逐渐变强。
appendfsync no 当设置appendfsync为no的时候，Redis不会主动调用fsync去将AOF日志内容同步到磁盘，所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上。
appendfsync everysec 当设置appendfsync为everysec的时候，Redis会默认每隔一秒进行一次fsync调用，将缓冲区中的数据写到磁盘。但是当这一次的fsync调用时长超过1秒时。Redis会采取延迟fsync的策略，再等一秒钟。也就是在两秒后再进行fsync，这一次的fsync就不管会执行多长时间都会进行。这时候由于在fsync时文件描述符会被阻塞，所以当前的写操作就会阻塞。所以结论就是，在绝大多数情况下，Redis会每隔一秒进行一次fsync。在最坏的情况下，两秒钟会进行一次fsync操作。这一操作在大多数数据库系统中被称为group commit，就是组合多次写操作的数据，一次性将日志写到磁盘。
appednfsync always 当设置appendfsync为always时，每一次写操作都会调用一次fsync，这时数据是最安全的，当然，由于每次都会执行fsync，所以其性能也会受到影响。
对于一般性的业务需求，建议使用RDB的方式进行持久化，原因是RDB的开销并相比AOF日志要低很多，对于那些无法忍数据丢失的应用，建议使用AOF日志。
4、集群管理的不同
Memcached是全内存的数据缓冲系统，Redis虽然支持数据的持久化，但是全内存毕竟才是其高性能的本质。作为基于内存的存储系统来说，机器物理内存的大小就是系统能够容纳的最大数据量。如果需要处理的数据量超过了单台机器的物理内存大小，就需要构建分布式集群来扩展存储能力。
Memcached本身并不支持分布式，因此只能在客户端通过像一致性哈希这样的分布式算法来实现Memcached的分布式存储。下图给出了Memcached的分布式存储实现架构。当客户端向Memcached集群发送数据之前，首先会通过内置的分布式算法计算出该条数据的目标节点，然后数据会直接发送到该节点上存储。但客户端查询数据时，同样要计算出查询数据所在的节点，然后直接向该节点发送查询请求以获取数据。
请点击输入图片描述
相较于Memcached只能采用客户端实现分布式存储，Redis更偏向于在服务器端构建分布式存储。最新版本的Redis已经支持了分布式存储功能。Redis Cluster是一个实现了分布式且允许单点故障的Redis高级版本，它没有中心节点，具有线性可伸缩的功能。下图给出Redis Cluster的分布式存储架构，其中节点与节点之间通过二进制协议进行通信，节点与客户端之间通过ascii协议进行通信。在数据的放置策略上，Redis Cluster将整个key的数值域分成4096个哈希槽，每个节点上可以存储一个或多个哈希槽，也就是说当前Redis Cluster支持的最大节点数就是4096。Redis Cluster使用的分布式算法也很简单：crc16( key ) % HASH_SLOTS_NUMBER。
请点击输入图片描述
为了保证单点故障下的数据可用性，Redis Cluster引入了Master节点和Slave节点。在Redis Cluster中，每个Master节点都会有对应的两个用于冗余的Slave节点。这样在整个集群中，任意两个节点的宕机都不会导致数据的不可用。当Master节点退出后，集群会自动选择一个Slave节点成为新的Master节点。
请点击输入图片描述
