cookie用户数据储存形式
- 无需登录,无需查库,保存在游览端
- 优点:性能好,访问块,没有和数据库交互
- 缺点1:换电脑数据会丢失
- 缺点2:非本人登录电脑,存在安全隐患问题
Session形式储存
- 登录后存储用户会话
- 基于服务内存存储
- 初期性能好,访问快
- 缺点1:基于服务器内存,用户量庞大,影响服务器性能
- 缺点2:只能存在当前会话,不适用于集群和分布式系统
数据库形式存储
- 用户登录后将数据存储进数据库
- 优点:数据持久化,可在任何地点和时间段访问
- 缺点:频繁读写数据库,造成数据库压力
redis形式存储数据
-
分布式缓存中间件
-
Redis的高并发与高性能都是基于内存的:缓存是基于内存的,如果一味的使用磁盘,缓存将失去意义
-
如果key过期不清理是会一直占用memory的
-
redis底层数据结构有:
-
用户登录后将数据存储进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算法:对02^32-1,进行取模,使用节点ip或者主机名进行Hash算法,这样每台节点都会在0232-1的范围之间,将key也按Hash算法进行取模操作,在0~232-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,那么这些请求全部就会进入数据库中,缓存雪崩只能缓解无法彻底解决
- 缓存雪崩预防:
- 永不过期
- 过期时间错开:将批量key的过期时间错开
- 多缓存结合:多缓存中间件结合使用,redis和Memcache结合,两个缓存中间件中存入相同的key,过期时间设置一长一短
- 采购第三方redis
- 查询key时尽量使用批量优化查询
- 使用redis管道功能优化批量查询,pipeline管道
-
形容词用接口,名词用抽象类,方法用动词
- 接口通常用于描述一个事物有怎样的属性与功能,比如:喜欢,听说,发火,公开等等…
- 抽象类通常用来表示更加具体的一类事物,比如:人,动物,食物,汽车,武器等等…
暴力递归到动态规划
- 常用模型来说一共有四种模型
- 第一种从左往右的尝试模型
- 范围上的模型
- 四边形不等式