zoukankan      html  css  js  c++  java
  • redis学习

    JVM 内置缓存

    mybatis、hibernate二级缓存(sessionfactory)机制分别基于oscache、ehcache

    OsCache与EhCache区别

    ehcache 主要是对数据库访问的缓存,相同的查询语句只需查询一次数据库,从而提高了查询的速度,使用spring的AOP可以很容易实现这一功能。

    oscache 主要是对页面的缓存,可以整页或者指定网页某一部分缓存,同时指定他的过期时间,这样在此时间段里面访问的数据都是一样的。

    JVM 内置缓存缺点:内存溢出、没有持久化、线程安全、多服务器数据不能共享。

    NoSQL 缓存

    NoSQL 是 Not Only SQL 的缩写,意即"不仅仅是SQL"的意思,泛指非关系型的数据库。强调Key-Value Stores和文档数据库的优点,而不是单纯的反对RDBMS。

    NoSQL产品 Redis、mongodb MembaseHBase 

    Redis

    Redis 是完全开源免费的,遵守BSD协议,是一个高性能的key-value数据库。

    Redis 与其他 key - value 缓存产品有以下三个特点:

    Redis支持数据的持久化,可以将内存中的数据保存在磁盘中,重启的时候可以再次加载进行使用。

    Redis不仅仅支持简单的key-value类型的数据,同时还提供list,set,zset,hash等数据结构的存储。

    Redis支持数据的备份,即master-slave模式的数据备份。

    Redis应用场景:主要能够体现 解决数据库的访问压力。例如:短信验证码时间有效期、session共享解决方案。

    Memcached与Redis的区别?

      1.存储方式不同。memcached把数据全部存在内存之中,断电之后会挂掉,而redis虽然也用到了内存,但是会有部分数据存在硬盘中,保证数据持久性。

      2.数据支持类型不同。memcached对数据支持比较简单,而redis支持数据类型较丰富,如string、list、set、sorted set、hash。

      3.底层实现不同。一般调用系统函数,会消耗比较多的时间去请求,redis自己构建了vm,速度会更快。

    Redis优势

    性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。

    丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。

    原子 – Redis的所有操作都是原子性的,同时Redis还支持对几个操作全并后的原子性执行。

    丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性。

    Redis数据

    容量

    官方说单例能处理key:2.5亿个(Redis can handle up to 2^32 keys, ),一个key或是value大小最大是512M。

    类型

    Redis支持五种数据类型:string(字符串),hash(哈希),list(列表),set(集合)及zset(sorted set:有序集合)。

     https://www.cnblogs.com/dingpeng9055/p/11560445.html

    Redis主从复制

    1、redis的复制功能是支持多个数据库之间的数据同步。一类是主数据库(master)一类是从数据库(slave),主数据库可以进行读写操作,当发生写操作的时候自动将数据同步到从数据库,而从数据库一般是只读的,并接收主数据库同步过来的数据,一个主数据库可以有多个从数据库,而一个从数据库只能有一个主数据库。

    2、通过redis的复制功能可以很好的实现数据库的读写分离,提高服务器的负载能力。主数据库主要进行写操作,而从数据库负责读操作。

    过程:

    1:当一个从数据库启动时,会向主数据库发送sync命令,

    2:主数据库接收到sync命令后会开始在后台保存快照(执行rdb操作),并将保存期间接收到的命令缓存起来

    3:当快照完成后,redis会将快照文件和所有缓存的命令发送给从数据库。

    4:从数据库收到后,会载入快照文件并执行收到的缓存的命令。

    Redis哨兵机制

    Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务:

    ·        监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。

    ·        提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

    ·        自动故障迁移(Automatic failover):当一个Master不能正常工作时,哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

    哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master.

    每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown).

    若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置.

    虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器,你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel)

    Redis数据的淘汰策略?

      1.volatile-lru:从已经设置过期时间的数据集中,挑选最近最少使用的数据淘汰。

      2.volatile-ttl:从已经设置过期时间的数据集中,挑选即将要过期的数据淘汰。

      3.volatile-random:从已经设置过期时间的数据集中,随机挑选数据淘汰。

      4.allkeys-lru:从所有的数据集中,挑选最近最少使用的数据淘汰。

      5.allkeys-random:从所有的数据集中,随机挑选数据淘汰。

      6.no-enviction:禁止淘汰数据。

    Redis的线程模型

     1)文件事件处理器

    redis基于reactor模式开发了网络事件处理器,这个处理器叫做文件事件处理器,file event handler。这个文件事件处理器,是单线程的,redis才叫做单线程的模型,采用IO多路复用机制同时监听多个socket,根据socket上的事件来选择对应的事件处理器来处理这个事件。

     如果被监听的socket准备好执行accept、read、write、close等操作的时候,跟操作对应的文件事件就会产生,这个时候文件事件处理器就会调用之前关联好的事件处理器来处理这个事件。

     文件事件处理器是单线程模式运行的,但是通过IO多路复用机制监听多个socket,可以实现高性能的网络通信模型,又可以跟内部其他单线程的模块进行对接,保证了redis内部的线程模型的简单性。

     文件事件处理器的结构包含4个部分:多个socket,IO多路复用程序,文件事件分派器,事件处理器(命令请求处理器、命令回复处理器、连接应答处理器,等等)。

     多个socket可能并发的产生不同的操作,每个操作对应不同的文件事件IO多路复用程序会监听多个socket,但是会将socket放入一个队列中排队,每次从队列中取出一个socket给事件分派器,事件分派器把socket给对应的事件处理器

     然后一个socket的事件处理完之后,IO多路复用程序才会将队列中的下一个socket给事件分派器。文件事件分派器会根据每个socket当前产生的事件,来选择对应的事件处理器来处理。

     2)文件事件

     当socket变得可读时(比如客户端对redis执行write操作,或者close操作),或者有新的可以应答的sccket出现时(客户端对redis执行connect操作),socket就会产生一个AE_READABLE事件。

     当socket变得可写的时候(客户端对redis执行read操作),socket会产生一个AE_WRITABLE事件。

     IO多路复用程序可以同时监听AE_REABLE和AE_WRITABLE两种事件,要是一个socket同时产生了AE_READABLE和AE_WRITABLE两种事件,那么文件事件分派器优先处理AE_REABLE事件,然后才是AE_WRITABLE事件。

     3)文件事件处理器

    如果是客户端要连接redis,那么会为socket关联连接应答处理器

    如果是客户端要写数据到redis,那么会为socket关联命令请求处理器

    如果是客户端要从redis读数据,那么会为socket关联命令回复处理器

     4)客户端与redis通信的一次流程

    在redis启动初始化的时候,redis会将连接应答处理器跟AE_READABLE事件关联起来,接着如果一个客户端跟redis发起连接,此时会产生一个AE_READABLE事件,然后由连接应答处理器来处理跟客户端建立连接,创建客户端对应的socket,同时将这个socket的AE_READABLE事件跟命令请求处理器关联起来。

     当客户端向redis发起请求的时候(不管是读请求还是写请求,都一样),首先就会在socket产生一个AE_READABLE事件,然后由对应的命令请求处理器来处理。这个命令请求处理器就会从socket中读取请求相关数据,然后进行执行和处理。

    接着redis这边准备好了给客户端的响应数据之后,就会将socket的AE_WRITABLE事件跟命令回复处理器关联起来,当客户端这边准备好读取响应数据时,就会在socket上产生一个AE_WRITABLE事件,会由对应的命令回复处理器来处理,就是将准备好的响应数据写入socket,供客户端来读取。

     命令回复处理器写完之后,就会删除这个socket的AE_WRITABLE事件和命令回复处理器的关联关系。

     

    简单来说,就是我们的 redis-client 在操作的时候,会产生具有不同事件类型的 Socket。

    在服务端,有一段 I/O 多路复用程序,将其置入队列之中。然后,文件事件分派器,依次去队列中取,转发到不同的事件处理器中。

    需要说明的是,这个 I/O 多路复用机制,Redis 还提供了 select、epoll、evport、kqueue 等多路复用函数库。

    为什么Redis把所有数据都放到内存中?

    redis为了达到最快的读写速度,将数据都读到内存中,并通过异步的方式将数据写入磁盘。如果不将数据放在内存中,磁盘IO速度会严重影响redis的性能。

    Redis的并发竞争问题如何解决?

      首先redis为单进程单线程模式,采用队列模式将并发访问变为串行访问。redis本身时没有锁的概念的,redis对多个客户端连接并不存在竞争,但是在Jedis客户端对redis进行并发访问时会产生一系列问题,这些问题时由于客户端连接混乱造成的。有两种方案解决。

      1.在客户端,对连接进行池化,同时对客户端读写redis操作采用内部锁synchronized。

      2.在服务器角度,利用setnx实现锁。

     为什么Redis 是单线程却能支撑高并发?

    1)纯内存操作

    2)核心是基于非阻塞的IO多路复用机制

    3)单线程反而避免了多线程的频繁上下文切换问题(百度)

    Redis性能监控与问题排查

    https://www.cnblogs.com/zhuyeshen/p/10950330.html

    Redis常用命令

    部分来自石杉码农学院

    https://mp.weixin.qq.com/s/_XJmSEGYqxZaeFgoyCWMXQ

  • 相关阅读:
    面向对象设计模式之Facade外观模式(结构型)
    Android 多线程:使用Thread和Handler
    Android源码分析之Handler
    Android View的几个位置坐标关系
    LinearLayout布局问题
    Android app被系统kill的场景
    改变Activity启动时的默认动画
    ViewStub源码分析
    Android measure过程分析
    点击ViewGroup时其子控件也变成pressed状态的原因分析及解决办法
  • 原文地址:https://www.cnblogs.com/dingpeng9055/p/10403603.html
Copyright © 2011-2022 走看看