入门介绍

• 互联网需求的3高
  • 高并发，高可扩，高性能
• Redis 是一种运行速度很快，并发性能很强，并且运行在内存上的NoSql（not only sql）数据库
• NoSQL数据库 和 传统数据库 相比的优势
  • NoSQL数据库无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。
  • 而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段
    简直就是一个噩梦
• Redis的常用使用场景
  • 缓存，毫无疑问这是Redis当今最为人熟知的使用场景。在提升服务器性能方面非常有效；一
    些频繁被访问的数据，经常被访问的数据如果放在关系型数据库，每次查询的开销都会很
    大，而放在redis中，因为redis 是放在内存中的可以很高效的访问
  • 排行榜，在使用传统的关系型数据库（mysql oracle 等）来做这个事儿，非常的麻烦，而利
    用Redis的SortSet(有序集合)数据结构能够简单的搞定；
  • 计算器/限速器，利用Redis中原子性的自增操作，我们可以统计类似用户点赞数、用户访问
    数等，这类操作如果用MySQL，频繁的读写会带来相当大的压力；限速器比较典型的使用场
    景是限制某个用户访问某个API的频率，常用的有抢购时，防止用户疯狂点击带来不必要的压
    力；
  • 好友关系，利用集合的一些命令，比如求交集、并集、差集等。可以方便搞定一些共同好
    友、共同爱好之类的功能；
  • 简单消息队列，除了Redis自身的发布/订阅模式，我们也可以利用List来实现一个队列机制，
    比如：到货通知、邮件发送之类的需求，不需要高可靠，但是会带来非常大的DB压力，完全
    可以用List来完成异步解耦；
  • Session共享，以jsp为例，默认Session是保存在服务器的文件中，如果是集群服务，同一个
    用户过来可能落在不同机器上，这就会导致用户频繁登陆；采用Redis保存Session后，无论
    用户落在那台机器上都能够获取到对应的Session信息。

Redis/Memcache/MongoDB对比

• 都是nosql数据库的著名代表

Redis和Memcache

• Redis和Memcache都是内存数据库。不过memcache还可用于缓存其他东西，例如图片、视频等
  等。
• memcache 数据结构单一kv，redis 更丰富一些，还提供 list，set， hash 等数据结构的存储，有效的减少网络 IO 的次数
• 虚拟内存–Redis当物理内存用完时，可以将一些很久没用到的value交换到磁盘
• 存储数据安全–memcache挂掉后，数据没了（没有持久化机制）；redis可以定期保存到磁盘（持久化）
• 灾难恢复–memcache挂掉后，数据不可恢复; redis数据丢失后可以通过RBD或AOF恢复

Redis和MongoDB

• redis和mongodb并不是竞争关系，更多的是一种协作共存的关系。
• mongodb本质上还是硬盘数据库，在复杂查询时仍然会有大量的资源消耗，而且在处理复杂逻辑时仍然要不可避免地进行多次查询。
• 这时就需要redis或Memcache这样的内存数据库来作为中间层进行缓存和加速。
• 比如在某些复杂页面的场景中，整个页面的内容如果都从mongodb中查询，可能要几十个查询语
  句，耗时很长。如果需求允许，则可以把整个页面的对象缓存至redis中，定期更新。这样
  mongodb和redis就能很好地协作起来

CAP简介

• 传统的关系型数据库事务具备ACID：
  • A：原子性
  • C：一致性
  • I：独立性
  • D：持久性
• 分布式数据库的CAP:
  • C（Consistency）：强一致性
    • “all nodes see the same data at the same time”,即更新操作成功并返回客户端后，所
      有节点在同一时间的数据完全一致，这就是分布式的一致性。一致性的问题在并发系统
      中不可避免，对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问
      题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。
  • A（Availability）：高可用性
    • 可用性指“Reads and writes always succeed”，即服务一直可用，而且要是正常的响应
      时间。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问
      超时等用户体验不好的情况。
  • P（Partition tolerance）：分区容错性
    • 即分布式系统在遇到某节点或网络分区故障时，仍然能够对外提供满足一致性或可用性
      的服务。
    • 分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转
      正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器
      还能够正常运转满足系统需求，对于用户而言并没有什么体验上的影响。

CAP总结

• 分区是常态，不可避免，三者不可共存
• <b style="color:red">可用性和一致性是一对冤家</b>
  • 一致性高，可用性低
  • 一致性低，可用性高
• 因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大
  类：
  • CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
  • CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。
  • AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

Redis 五大数据类型

• 字符串String
  • set/get/del/append/strlen 保存/获取/删除/追加/返回数据长度
  • incr/decr/incrby/decrby：加减操作，操作的必须是数字类型 自增1/自减1/自定义增加数字/自定义减少数字
  • getrange/setrange 类似between...and...
  • setex 添加数据的同时设置生命周期
  • setnx 添加数据的时候判断是否已经存在，防止已存在的数据被覆盖掉
  • mset/mget/msetnx
• List
  • lpush/rpush/lrange
  • lpop/rpop：移除第一个元素（上左下右）
  • lindex：根据下标查询元素（从左向右，自上而下）
  • llen：返回集合长度
  • lrem：删除n个value
  • ltrim：截取指定范围的值，别的全扔掉
  • rpoplpush：从一个集合搞一个元素到另一个集合中（右出一个，左进一个）
  • lset：改变某个下标的某个值
  • linsert：插入元素（指定某个元素之前/之后）
• Set 不允许重复
  • sadd/smembers/sismember：添加/查看/判断是否存在
  • scard：获得集合中的元素个数
  • srem：删除集合中的元素
  • srandmember：从集合中随机获取几个元素
  • spop：随机出栈（移除）
  • smove：移动元素：将key1某个值赋值给key2
  • 数学集合类
    • 交集：sinter
    • 并集：sunion
    • 差集：sdiff
• Hash
  • hset/hget/hmset/hmget/hgetall/hdel：添加/得到/多添加/多得到/得到全部/删除属性
  • hlen：返回元素的属性个数
  • hexists：判断元素是否存在某个属性
  • hkeys/hvals：获得属性的所有key/获得属性的所有value
  • hincrby/hincrbyfloat：自增（整数）/自增（小数）
  • hsetnx：添加的时候，先判断是否存在
• Zset 有序集合
  • zadd/zrange （withscores）：添加/查询
  • zrangebyscore：模糊查询
  • zrem：删除元素
  • zcard/zcount/zrank/zscore：集合长度/范围内元素个数/得元素下标/通过值得分数
  • zrevrank：逆序找下标（从下向上）
  • zrevrange：逆序查询
  • zrevrangebyscore：逆序范围查找

Redis中的持久化

• RDB
  • Redis Database
  • 在指定的时间间隔内，将内存中的数据集的快照写入磁盘；
  • 默认保存在/usr/local/bin中，文件名dump.rdb;
  • 自动配备，修改改redis.conf文件配置
  • 手动备份，执行save命令
• AOF
  • Append Only File
  • 以日志的形式记录每个写操作；
  • 将redis执行过的写指令全部记录下来（读操作不记录）；
  • 只许追加文件，不可以改写文件；
  • redis在启动之初会读取该文件从头到尾执行一遍，这样来重新构建数据；

事务

三大特性

• 隔离性：所有命令都会按照顺序执行，事务在执行的过程中，不会被其他客户端送来的命令打断
• 没有隔离级别：队列中的命令没有提交之前都不会被实际的执行，不存在“事务中查询要看到事务里的更新，事务外查询不能看到”这个头疼的问题
• 不保证原子性：冤有头债有主，如果一个命令失败，但是别的命令可能会执行成功，没有回滚

watch监控

可以监控某个key的变化，如果在事务中的某个key被其他事务先操作了，那么这次的事务会失败

Redis主从复制原理

哨兵模式

• Sentinel是Redis的高可用性解决方案：
  • 由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级
    为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。
• 哨兵模式的缺点
  • 由于所有的写操作都是在master上完成的；
  • 然后再同步到slave上，所以两台机器之间通信会有延迟；
  • 当系统很繁忙的时候，延迟问题会加重；
  • slave机器数量增加，问题也会加重