redis总结

cookie用户数据储存形式

• 无需登录,无需查库,保存在游览端
• 优点:性能好,访问块,没有和数据库交互
• 缺点1:换电脑数据会丢失
• 缺点2:非本人登录电脑,存在安全隐患问题

Session形式储存

• 登录后存储用户会话
• 基于服务内存存储
• 初期性能好,访问快
• 缺点1:基于服务器内存,用户量庞大,影响服务器性能
• 缺点2:只能存在当前会话,不适用于集群和分布式系统

数据库形式存储

• 用户登录后将数据存储进数据库
• 优点:数据持久化,可在任何地点和时间段访问
• 缺点:频繁读写数据库,造成数据库压力

redis形式存储数据

• 分布式缓存中间件

• Redis的高并发与高性能都是基于内存的:缓存是基于内存的,如果一味的使用磁盘,缓存将失去意义

• 如果key过期不清理是会一直占用memory的

• redis底层数据结构有:

  1. 简单动态字符串
  2. 双向链表
  3. 字典
  4. 跳跃表
  5. 整数集合
  6. 压缩列表

• 用户登录后将数据存储进redis缓存中

• 分布式会话可以依靠redis去做

• 优点1:数据持久化,可在任何地点,任何时间段访问

• 优点2:频繁读写基于缓存,不会对数据库造成压力

• 适用于集群和可分布式系统,可扩展性强

• redis主从架构:

  • master(主):主要用来作写请求,主要作分发请求,将这些请求平均的分发给从节点

  • RDB为全量备份,AOF是增量备份

  • slave(奴隶从节点):主要用来作读请求

  • 单节点QPS(并发)如果是5万,那么两个就应该达到10万

  • 主节点将数据复制给从节点

  • 主从原理:当主从节点启动后,从节点会发送一个ping包给主节点告诉主节点自己已启动,主节点会把数据复制给从节点(注意这里的数据是一个全量的复制),这里的复制是以一个RDB的模式,也就是文件的模式,先在将这份RDB文件放置一份在磁盘,再从内存中拷贝一份新的文件通过内网传输分发给salve节点,salve先会通过内网下载这份RDB文件放入磁盘里,再从磁盘里加载到内从中,这个过程是第一次发生,称之为初始化过程,这时如果有一条写操作命令进入,master会将这条命令同步到salve节点,这时salve会修正自己内存中的数据,通过这样的方式master和salve就会做到一个数据同步,通过这样的方式salve就会为外部访问系统提供一个读请求服务

  • 以上操作是不会造成master的写操作以及salve的读操作的,这里是因为使用的是历史数据来完成数据同步操作的,数据完成同步后会用新的数据来替换老的历史数据

  • 第一次数据同步是一个全量式的数据同步,而之后是增量式的数据同步(延时队列)

  • 如果salve节点宕机一个时间段,当这个salve重新恢复后,Master节点会将这一时间段内的增量数据再次同步到这台salve节点

  • 注意:如果要使用主从复制,主节点必须开启持久化服务,如果主节点不开启持久化服务,当这太master重启后,此时主节点内存中是无任何数据的,会把从节点中的数据清空

  • 最多使用的模式:One Master vs. Two Salve(一主二从)

  • 无磁盘化复制:RDB文件直接通过redis内部网络来进行传输,不会经过磁盘,对网络带宽要求较高,而且现在只是在试用阶段

  • redis缓存过期机制:

    • 定期删除(主动):redis会一每隔一段时间内,会抽查随机的key hz(每秒检查次数),可自行设置,但是设置的越高对Cpu的占用就会越高,redis默认是每秒检查10次
    • 惰性删除(被动):当用户去get some one keys 时,if 这个key不存在,那么redis就会delete掉这个key
    • 定期删除优点:比较智能化,自动删除过期key,缺点会一直占用Cpu
    • 惰性删除优点:不会一直占用Cpu,缺点是过期key无法及时删除,会一直占用Memory

  • 内存淘汰管理机制:

    • Memory Management : Set Memory Limit(设置内存阈值),当内存达到一定阈值后,redis会开启自动清理(自动清理算法) :allKeys-lfu(自动清理最少用到的历史缓存)
    • noeviction: 旧缓存永不过期，新缓存设置不了，返回错误
    • volatile-lfu:针对有过期时间最少使用的key进行删除
    • volatile-random:针对有过期时间的key随机删除
    • volatile-ttl:在设置过期时间key的基础上,优先清除即将要过期的key
    • LRU:针对于时间的,也就是设置过过期时间的key
    • LFU:针对于次数,也就是针对于动作的
    • Maxmemory:最大内存限制
    • 当RDB文件超过6G,主从节点之间同步数据将异常缓慢, 通过细致分析full resync和masterslave这两行日志的时间差，可以算出rdb文件从创建到传输完毕消耗的总时间 , 如果总时间超过repl-timeout所配置的值（默认60秒），从节点将放弃接受rdb文件并清理已经下载的临时文件，导致全量复制失败。
    • 针对数据量较大的节点，建议调大repl-timeout参数防止出现全量同步数据超时。
    • 例如对于千兆网卡的机器，网卡带宽理论峰值大约每秒传输100MB，在不考虑其他进程消耗带宽的情况下，6GB的rdb文件至少需要60秒传输时间，默认配置下，极易出现主从数据同步超时。
    • 如果主节点创建和传输RDB的时间过长，对于高流量写入场景非常容易造成主节点复制客户端缓冲区溢出。默认配置为client-output-buffer-limit slave 256MB 64MB 60，如果60秒内缓冲区消耗持续大于64MB或者直接超过256MB时，主节点将直接关闭复制客户端连接，造成全量同步失败。
    • 如果只使用ip+port的方式识别主节点，那么主节点重启变更了整体数据集（如替换rdb/aof文件），从节点再基于偏移量复制数据将是不安全的，因此当运行ID变化后从节点将做全量复制

  • Redis的Sentinel(哨兵机制):

    • Sentinel:用于监控各个Master和Salve的状态,如果Master宕机了,Sentinel会将集群中一个Salve服务升级成为Master,这里的哨兵也是以集群的方式搭建的
    • Sentinel down-after-milliseconds mymaster 30000 : Sentinel认定Master的失效时间
    • sentinel failover-timeout mymaster 180000 : 主备切换的超时时间，哨兵要去做故障转移，这个时候哨兵也是一个进程，如果他没有去执行，超过这个时间后，会由其他的哨兵来处理
    • 假如有一主二从redis集群:当这个master宕机后,会在余下的两台salve中选举出一台作为master,之前宕机的那台master恢复会作为salve来服务于集群
    • 配置时设置为后台启动 : daemonize yes 将后台启动开启,redis默认情况下是 no
    • 日志存放位置: logfile + 路径(这是哨兵集群log的位置)
    • 并行同步数据可设置
    • 在设置redis集群时,Master和Salve要设置为互相通信密码一致,且要保证内网集群互相ping通,如果是虚拟机关闭防火墙,如果是云主机将相应的端口开放
    • masterauth(主节点密码)
    • redis-cli -p 26379 (redis连接哨兵命令)
    • Sentinel master 加主机昵称:查看哨兵集群状态等信息
    • Sentinel salve - Master+名称 : 查看当前Master下的所有从节点
    • parallel-syncs 2 设置有几台salve从节点,并行同步数据
    • 主观下线:就是当有一个哨兵认为Master下线时,像这个种情况,可能是由网络延迟波动造成的,在哨兵集群中超过半数以上(奇数台)检测到有一个Master下线时,才会开启选举机制,quorum=x(正整数值设置的是当前哨兵集群有几台哨兵同时检测到一台Master)
    • 一组哨兵可以监听多组主从redis节点(通常来说一组哨兵监听一组主从redis服务器)
    • redis经典集群配置为三主三从(总共是6个节点),需要在集群中开启集群模式,设置三台Master的通信超时时间,还要把每台单节点中的RDB和AOF文件删除
    • z早期要通过ruby的脚本构建集群:在redis的src源码文件中,ls.*rb(搜索)redis-trib.rb脚本文件
    • redis5.0版本以上使用 redis-cli --cluster create +IP和端口号,有几台节点就要配置几个IP和端口号,来构建主从集群, redis - cli - help, 查看当前集群下所有的命令,同时配置Master与Salve之间的比值,一般跟一个正整数作为比值,如果设置为1,代表当前是一个Master与一个Salve匹配,在构建的时候要加上密码权限
    • 在Master中有内存插槽slots,有多台Master内存插槽会平均分配,而从节点Salve是没有内存插槽的,所有的数据都是保存在这些内存插槽中的,每一个插入的key会进行Hash求余算法,每一个插入的key对总插槽数进行求余,每个key放入哪个Master取决于求出的内存插槽余生来决定
    • 一致性Hash算法:对0_{2^32-1,进行取模,使用节点ip或者主机名进行Hash算法,这样每台节点都会在0}2^{32-1的范围之间,将key也按Hash算法进行取模操作,在0~2}32-1的原形环上按顺时针寻找最近的一台服务器,将此key归类为这台服务器,这样在群架服务增减的过程中其它key将不受到影响
    • 数据倾斜问题:一致性Hash算法引入了虚拟节点机制,就是对每台服务器节点计算多个Hash值,在每个Hash值结果处都放入当前这台节点服务器的虚拟ip,可将每台服务器节点后方或者前方加入随机数或者时间戳来处理,然后将虚拟节点ip与真实服务器ip做映射
    • redis 作get key操作时会进行节点的切换,如果使用keys * 在当前节点是无法看到其它节点中的key的
    • redis缓存穿透问题如何避免:在将集合中的数据放入redis前做一些非空判断
    • redis布隆过滤器:以二进制的形式做存储,迅速判断一个元素是否在redis中,也就是说以二进制数组来维护一个元素是否在redis中,0代表不存在,1代表存在,有可能在一个数组位中同时存在多个key在这一位置,布隆过滤器会在到达redis缓存之前,先行拦截请求,布隆过滤器会存在1%的误判率,如果一个key从db和redis中删除后,但是这个key是无法从布隆过滤器中删除的,因为如果一个位置存在多个key,此时布隆过滤器将这个数组位置的值从1改为0,那么对应的这个位置其它的key也一并会被删除
    • 向量:有大小且有方向的量称之为向量,有大小无方向的量称之为标量,几何向量也被称之为矢量
    • 这里布隆过滤器中的向量是数学中的向量空间的概念,而不是物理中的向量,在线性代数中的向量是经过抽象的,不一定具有物理中向量的大小和方向的特性
    • 布隆过滤器思想:通过多个Hash(散列)映射函数与向量空间加元素过滤来实现,如果判断一个k-v对一定不存在的话是一定没问题,如果判断它一定存在的话是不准确的
    • 模拟与数字
      • 模拟在现实中是连续的
      • 数字在现实中是离散的
    • redis缓存雪崩:redis缓存中存在大量过期的key,在这时有大量请求查询当前这批过期的key,那么这些请求全部就会进入数据库中,缓存雪崩只能缓解无法彻底解决
    • 缓存雪崩预防:
      1. 永不过期
      2. 过期时间错开:将批量key的过期时间错开
      3. 多缓存结合:多缓存中间件结合使用,redis和Memcache结合,两个缓存中间件中存入相同的key,过期时间设置一长一短
      4. 采购第三方redis
    • 查询key时尽量使用批量优化查询
    • 使用redis管道功能优化批量查询,pipeline管道

形容词用接口,名词用抽象类,方法用动词

• 接口通常用于描述一个事物有怎样的属性与功能,比如:喜欢,听说,发火,公开等等…
• 抽象类通常用来表示更加具体的一类事物,比如:人,动物,食物,汽车,武器等等…

暴力递归到动态规划

• 常用模型来说一共有四种模型
• 第一种从左往右的尝试模型
• 范围上的模型
• 四边形不等式