java之学习记录 7 - 2 - redis介绍

1. 概述

1.1 Redis入门介绍

• 互联网需求的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信息。

1.2 Redis/Memcache/MongoDB对比

都是 nosql 数据库的著名代表

 

1.2.1 Redis 和 Memcache

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

1.2.2 Redis 和 MongoDB

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

1.3 分布式数据库CAP原理

1.3.1 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）：分区容错性
    • 即分布式系统在遇到某节点或网络分区故障时，仍然能够对外提供满足一致性或可用性的服务。
  • 分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，对于用户而言并没有什么体验上的影响。

1.3.2 CAP 理论

• CAP理论提出就是针对分布式数据库环境的，所以，P这个属性必须容忍它的存在，而且是必须具备的。
• 因为P是必须的，那么我们需要选择的就是A和C。
• 大家知道，在分布式环境下，为了保证系统可用性，通常都采取了复制的方式，避免一个节点损坏，导致系统不可用。那么就出现了每个节点上的数据出现了很多个副本的情况，而数据从一个节点复制到另外的节点时需要时间和要求网络畅通的，所以，当P发生时，也就是无法向某个节点复制数据时，这时候你有两个选择：
  • 选择可用性 A，此时，那个失去联系的节点依然可以向系统提供服务，不过它的数据就不能保证是同步的了（失去了C属性）。
  • 选择一致性C，为了保证数据库的一致性，我们必须等待失去联系的节点恢复过来，在这个过程中，那个节点是不允许对外提供服务的，这时候系统处于不可用状态(失去了A属性)。
• 最常见的例子是读写分离，某个节点负责写入数据，然后将数据同步到其它节点，其它节点提供读取的服务，当两个节点出现通信问题时，你就面临着选择A（继续提供服务，但是数据不保证准确），C（用户处于等待状态，一直等到数据同步完成）。

1.3.3 CAP 总结

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