互联网时代背景下大机遇，为什么用nosql

• 在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付,在那个时候，更多的都是静态网页，动态交互类型的网站不多
• 上述架构下，我们来看看数据存储的瓶颈是什么？
  1. 数据量的总大小 一个机器放不下时
  2. 数据的索引（B+ Tree）一个机器的内存放不下时
  3. 访问量(读写混合)一个实例不能承受

• 后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品
• Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展，然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端

• 由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了

4.分表分库＋水平拆分＋mysql集群

• 在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM

• 同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群，但性能也不能很好满足互联网的要求，只是在高可靠性上提供了非常大的保证

• MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小。关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题

6.今天系统是什么样子

• 今天我们可以通过第三方平台（如：Google,Facebook等）可以很容易的访问和抓取数据。用户的个人信息，社交网络，地理位置，用户生成的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘，那SQL数据库已经不适合这些应用了, NoSQL数据库的发展也却能很好的处理这些大的数据

• 泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储

• （例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展

• NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特征。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力

• NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀，这得益于它的无关系性，数据库的结构简单
在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，
是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多

• NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，
  增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦

• 结构化查询语言（SQL）
  数据和关系都存储在单独的表中
  数据操纵语言，数据定义语言	键 - 值对存储，列存储，文档存储，图形数据库
  最终一致性，而非ACID属性
  非结构化和不可预知的数据
  高性能，高可用性和可伸缩性

当下的NoSQL经典应用

当下的应用是sql和nosql一起使用

阿里巴巴中文站商品信息如何存放

• 和我们相关的，多数据源多数据类型的存储问题

• 名称、价格，出厂日期，生产厂商等
• 关系型数据库：mysql/oracle目前淘宝在去O化(也即拿掉Oracle)，注意，淘宝内部用的Mysql是里面的大牛自己改造过的
  • 为什么去IOE：2008年，王坚加盟阿里巴巴成为集团首席架构师，即现在的首席技术官。这位前微软亚洲研究院常务副院长被马云定位为：将帮助阿里巴巴集团建立世界级的技术团队，并负责集团技术架构以及基础技术平台搭建。
    在加入阿里后，带着技术基因和学者风范的王坚就在阿里巴巴集团提出了被称为“去IOE”（在IT建设过程中，去除IBM小型机、Oracle数据库及EMC存储设备）的想法，并开始把云计算的本质，植入阿里IT基因。
    王坚这样概括“去IOE”运动和阿里云之间的关系：“去IOE”彻底改变了阿里集团IT架构的基础，是阿里拥抱云计算，产出计算服务的基础。“去IOE”的本质是分布化，让随处可以买到的Commodity PC架构成为可能，使云计算能够落地的首要条件。

2.商品描述、详情、评价信息（多文字类）

• 多文字信息描述类，IO读写性能变差

5.商品的波段性的热点高频信息

6.商品的交易、价格计算、积分累计

• 外部系统，外部第3方支付接口

7.总结大型互联网应用(大数据、高并发、多样数据类型)的难点和解决方案

• 数据源多样性和变化重构
• 数据源改造而数据服务平台不需要大面积重构
• EAI和统一数据平台服务

NoSQL数据模型简介

以一个电商客户、订单、订购、地址模型来对比下关系型数据库和非关系型数据库

传统的关系型数据库你如何设计？

• 什么是BSON：BSON（）是一种类json的一种二进制形式的存储格式，简称Binary JSON，它和JSON一样，支持内嵌的文档对象和数组对象

• 为什么上述的情况可以用聚合模型来处理
  • 高并发的操作是不太建议有关联查询的，互联网公司用冗余数据来避免关联查询
  • 分布式事务是支持不了太多的并发的
• 启发学生，想想关系模型数据库你如何查？如果按照我们新设计的BSon，是不是查询起来很可爱

NoSQL数据库的四大分类

文档型数据库（bson格式比较多）：典型介绍

• MongoDB 是一个基于分布式文件存储的数据库。由 C++ 语言编写。旨在为 WEB 应用提供可扩展的高性能数据存储解决方案
• MongoDB 是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的

• 它不是放图形的，放的是关系比如:朋友圈社交网络、广告推荐系统，社交网络，推荐系统等。专注于构建关系图谱

在分布式数据库中CAP原理CAP＋BASE

传统的ACID分别是什么

原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。比如银行转账，从A账户转100元至B账户，分为两个步骤：1）从A账户取100元；2）存入100元至B账户。这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了100元。 一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。 所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的 持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。

• CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点

• C:强一致性 、A：高可用性 、P：分布式容忍性

  • AP 大多数网站架构的选择

  • 注意：分布式架构的时候必须做出取舍。一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。因此牺牲C换取P，这是目前分布式数据库产品的方向

• CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，
  最多只能同时较好的满足两个。因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：
• CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大
• CP - 满足一致性，分区容忍必的系统，通常性能不是特别高
• AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些

• BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。

• BASE其实是下面三个术语的缩写：

• 它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么这么说呢，缘由就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些指标，要想获得这些指标，我们必须采用另外一种方式来完成，这里BASE就是解决这个问题的办法

• • 由多台计算机和通信的软件组件通过计算机网络连接（本地网络或广域网）组成。分布式系统是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。分布式系统可以应用在在不同的平台上如：Pc、工作站、局域网和广域网上等。

• 1. 分布式：不同的多台服务器上面部署不同的服务模块（工程），他们之间通过Rpc/Rmi之间通信和调用，对外提供服务和组内协作

  2. 集群：不同的多台服务器上面部署相同的服务模块，通过分布式调度软件进行统一的调度，对外提供服务和访问

• 是完全开源免费的，用C语言编写的，遵守BSD协议，是一个高性能的(key/value)分布式内存数据库，基于内存运行，并支持持久化的NoSQL数据库，是当前最热门的NoSql数据库之一,也被人们称为数据结构服务器

• 1. Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用
  2. Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储

• 内存存储和持久化：redis支持异步将内存中的数据写到硬盘上，同时不影响继续服务
• 取最新N个数据的操作，如：可以将最新的10条评论的ID放在Redis的List集合里面
• 模拟类似于HttpSession这种需要设定过期时间的功能

• 数据类型、基本操作和配置

• 第三方软件习惯放置于/opt目录下

Redis启动后杂项基础知识讲解

• 单进程模型来处理客户端的请求。对读写等事件的响应是通过对epoll函数的包装来做到的。Redis的实际处理速度完全依靠主进程的执行效率
• Epoll是Linux内核为处理大批量文件描述符而作了改进的epoll，是Linux下多路复用IO接口select/poll的增强版本，它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率

默认16个数据库，类似数组下表从零开始，初始默认使用零号库

• 设置数据库的数量，默认数据库为0，可以使用SELECT 命令在连接上指定数据库id
  

Select命令切换数据库

Dbsize查看当前数据库的key的数量

统一密码管理，16个库都是同样密码，要么都OK要么一个也连接不上

Redis索引都是从零开始

为什么默认端口是6379

Redis的五大数据类型

• string是redis最基本的类型，你可以理解成与Memcached一模一样的类型，一个key对应一个value
• string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象

• Redis 列表是简单的字符串列表，按照插入顺序排序，你可以添加一个元素到列表的头部（左边）或尾部

• Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员，不同的是每个元素都会关联一个double类型的分数
• redis正是通过分数来为集合中的成员进行从小到大的排序。zset的成员是唯一的,但分数(score)却可以重复。

哪里去获得redis常见数据类型操作命令

redis命令参考大全

• ttl key 查看还有多少秒过期，-1表示永不过期，-2表示已过期

lindex，按照索引下标获得元素(从上到下)

• 从left往right删除2个值等于v1的元素，返回的值为实际删除的数量
• LREM list3 0 值，表示删除全部给定的值。零个就是全部值

• 它是一个字符串链表，left、right都可以插入添加；如果键不存在，创建新的链表；如果键已存在，新增内容；如果值全移除，对应的键也就消失了。

• 链表的操作无论是头和尾效率都极高，但假如是对中间元素进行操作，效率就很惨淡了。

scard，获取集合里面的元素个数

1. 差集：sdiff 在第一个set里面而不在后面任何一个set里面的项

KV模式不变，但V是一个键值对

• 不存在赋值，存在了无效

• Limit 作用是返回限制 limit 开始下标步 多少步

• 删除元素，格式是zrem zset的key 项的值，项的值可以是多个,zrem key score某个对应值，可以是多个值

• zcard ：获取集合中元素个数
• zcount ：获取分数区间内元素个数，zcount key 开始分数区间 结束分数区间
• zscore：按照值获得对应的分数

• 配置大小单位,开头定义了一些基本的度量单位，只支持bytes，不支持bit

• 设置tcp的backlog，backlog其实是一个连接队列，backlog队列总和=未完成三次握手队列 + 已经完成三次握手队列。

• 单位为秒，如果设置为0，则不会进行Keepalive检测，建议设置成60

• 格式： save 秒钟 写操作的次数

  • RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，

  • 默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次

• • 如果想禁用RDB持久化的策略，只要不设置任何save指令，或者给save传入一个空字符串参数也可以

• 如果保存出错 停止写操作的意思

• 如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制

• rdbcompression：对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用
  LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能

• rdbchecksum：在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约
  10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能

• 访问密码的查看、设置和取消

• 设置redis同时可以与多少个客户端进行连接。默认情况下为10000个客户端。当你无法设置进程文件句柄限制时，redis会设置为当前的文件句柄限制值减去32，因为redis会为自身内部处理逻辑留一些句柄出来。如果达到了此限制，redis则会拒绝新的连接请求，并且向这些连接请求方发出“max number of clients reached”以作回应。
• 设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过maxmemory-policy来指定。如果redis无法根据移除规则来移除内存中的数据，或者设置了“不允许移除”，
  那么redis则会针对那些需要申请内存的指令返回错误信息，比如SET、LPUSH等。
• 但是对于无内存申请的指令，仍然会正常响应，比如GET等。如果你的redis是主redis（说明你的redis有从redis），那么在设置内存使用上限时，需要在系统中留出一些内存空间给同步队列缓存，只有在你设置的是“不移除”的情况下，才不用考虑这个因素
• Volatile-lru：使用LRU算法移除key，只对设置了过期时间的键
• Volatile-random ：在过期集合中移除随机的key，只对设置了过期时间的键
• Noeviction ：不进行移除，针对写操作，只是返回错误信息
• 设置样本数量，LRU算法和最小TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小，redis默认会检查这么多个key并选择其中LRU的那个

• Always：同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
• Everysec：出厂默认推荐，异步操作，每秒记录 如果一秒内宕机，有数据丢失

1. Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程
   
2. 指定Redis监听端口，默认端口为6379，作者在自己的一篇博文中解释了为什么选用6379作为默认端口，因为6379在手机按键上MERZ对应的号码，而MERZ取自意大利歌女Alessia Merz的名字
   
3. 当 客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能
   
4. 日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null
   
5. 设置数据库的数量，默认数据库为0，可以使用SELECT 命令在连接上指定数据库id
   
6. 指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
   Redis默认配置文件中提供了三个条件：
   分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。
7. 指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大
   
8. 指定本地数据库存放目录
   
9. 设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步
   
10. 设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息
    
11. 指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理 后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区
    
12. 指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no
    
13. 指定更新日志条件，共有3个可选值：
    no：表示等操作系统进行数据缓存同步到磁盘（快）
    always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全）
    everysec：表示每秒同步一次（折衷，默认值）
    
14. 指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析Redis的VM机制）
    
15. Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的 数据大小来设定的，作者建议如果存储很多小对象，page大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不 确定，就使用默认值
    
16. 设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存。
    
17. 设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4
    
18. 设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启
    
19. 指定是否激活重置哈希，默认为开启（后面在介绍Redis的哈希算法时具体介绍）
    
20. 指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件
    

• 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里
• Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失

• Fork的作用是复制一个与当前进程一样的进程，新进程的多有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

• save 命令 迅速备份 快速生成rdb文件

配置文件的位置（参照解析配置文件的快照）

配置文件默认的快照配置

• 默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次

• 都可以迅速 立刻生成dump.rdb文件
• Save：save时只管保存，其它不管，全部阻塞
• BGSAVE：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave
  命令获取最后一次成功执行快照的时间

执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义

对数据完整性和一致性要求不高

在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改

Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

• 以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

AOF启动/修复/恢复

• 恢复：重启redis然后重新加载

• 备份被写坏的AOF文件

• 恢复：重启redis然后重新加载

• AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

• AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

• Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

• 每修改同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
• 每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失

• 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
• Aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储

• AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大

• 只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.

同时开启两种持久化方式

• 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
• RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

• 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
• 如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。
• 如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构

• 可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞

• 一个队列中，一次性、顺序性、排他性的执行一系列命令

• 即使错了，但是加入进队列了queued ，而不是像case3在运行时直接报错并没有加入队列

• 悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁
• 乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量
• 乐观锁策略:提交版本必须大于记录当前版本才能执行更新

初始化信用卡可用余额和欠额

无加塞篡改，先监控再开启multi，保证两笔金额变动在同一个事务内

• 监控了key，如果key被修改了，后面一个事务的执行失效

一旦执行了exec之前加的监控锁都会被取消掉了

• Watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变，比如某个list已被别的客户端push/pop过了，整个事务队列都不会被执行

• 通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败

• 以MULTI开始一个事务

• 将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面

• 执行：由EXEC命令触发事务

• 单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断

• 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题

• 不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚---部分支持事务

Redis的发布和订阅

• 进程间的一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息

先订阅后发布后才能收到消息

• 行话：也就是我们所说的主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主

1.配从(库)不配主(库)

• 每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件

3.修改配置文件细节操作

• 1.切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来，那之前的123是否也可以复制

  答：切入点复制，不需要从头复制

• 2.从机是否可以写？set可否？

  答：从机只读，不可set

• 3.主机shutdown后情况如何？从机是上位还是原地待命

• 4.主机又回来了后，主机新增记录，从机还能否顺利复制

• 5.其中一台从机down后情况如何？依照原有它能跟上大部队吗？

  答：恢复后，会取消之前的主从设置，变为master。 重新slaveof即可

• 上一个Slave可以是下一个slave的Master，Slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master,可以有效减轻master的写压力（去中心化）

• 中途变更转向:会清除之前的数据，重新建立拷贝最新的

• 使当前数据库停止与其他数据库的同步，转成主数据库

1. Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步
2. 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中
3. 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步
4. 但是只要是重新连接master,一次完全同步（全量复制)将被自动执行

• 反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

3.配置哨兵,填写内容

• 上面最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机

• 哨兵监控到原有的主节点失效，自动投票选举新主节点

9.问题：如果之前的master重启回来，会不会双master冲突？

• 保持新选举的master，原先宕机的master，会变成新master的子节点

• 由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重

• 通俗点讲，watch命令就是标记一个键，如果标记了一个键， 在提交事务前如果该键被别人修改过，那事务就会失败，这种情况通常可以在程序中重新再尝试一次

  • 首先标记了键balance，然后检查余额是否足够，不足就取消标记，并不做扣减； 足够的话，就启动事务进行更新操作
  • 如果在此期间键balance被其它人修改， 那在提交事务（执行exec）时就会报错， 程序中通常可以捕获这类错误再重新执行一次，直到成功

如果Jedis在使用过程中出错，则也需要还给JedisPool

1. testOnBorrow：获得一个jedis实例的时候是否检查连接可用性（ping()）；如果为true，则得到的jedis实例均是可用的；

• Redis集群实现了对Redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N
• Redis集群通过分区(partition)来提供一定程度的可用性(availability):即使集群中有一部分节点失效或者无法进行通讯，集群也可以继续处理命令请求

• cluster-node-timeout 15000 设定节点失联时间，超过该时间（毫秒），集群自动进行主从切换

• 一个集群至少要有三个节点
• 选项 --replicas 1 表示我们希望为集群中的每个主节点创建一个从节点
• 分配原则尽量保证每个主数据库运行在不同的IP地址，每个从库和主库不再一个IP地址上

• 集群中的每个节点负责处理一部分插槽，举个例子，如果一个集群可以有主节点，其中：

  • 节点A负责处理0至5500号插槽
  • 节点B负责处理5501号至11000号插槽