redis--总结
其他
2021-03-08 00:24:54
阅读次数: 0
互联网发展与架构演变
- 小型网站LAMP架构(一台server平天下)
- 独立部署,提高并发(应用服务器、数据库服务器、文件服务器)
- 添加缓存（本地缓存和分布式缓存）
- 应用服务器集群化，提高并发
- 读写分离，改善数据库负载压力
- 反向代理及CDN，加速网站响应
- 分布式文件系统和分布式数据库
- Nosql和搜索引擎
- 业务拆分产品分团队管理
- 分布式服务面向服务架构SOA
Nosql诞生的原因：
- 互联网“三高”
高并发的读写高效率的存储和访问高可扩展性和高可用性
- 关系型数据库的某些特性被弱化甚至成为负担
Nosql的定义
- 是非关系型数据存储的广义定义
数据存储不需要固定的表结构，减少时间空间开销
Nosql的特点
- 易扩展
- 共同点去掉关系型数据库的关系型特性，数据之间无关系，容易扩展
- 大数据量，高性能
- 灵活的数据模型
- 无需事先建立字段，随时可以存储自定义的数据格式，规避了关系型数据库增删字段麻烦的弊端
- 高可用
- Cassandra，HBase模型，通过复制模型也能实现高可用。
Nosql数据库分类
键值存储数据库（数据模型：KV）
- 代表：
Redis
- 应用：
内容缓存，处理大量数据的高访问负载
- 优势：查询快
- 劣势：存储的数据缺少结构化
列式存储数据库（数据模型：列簇存储，同一列数据在一起）
- 代表：
HBase
- 应用：
分布式文件系统
- 优势：查询快，可扩展性强，更容易分布式扩展
- 劣势：功能相对局限
文档型数据库（数据模型：KV）
- 代表：
MongoDB
- 应用：Web应用（Value一般是Json）
- 优势：数据结构要求不严格
- 劣势：查询性能不高，缺乏统一的查询语法
图形数据库（数据模型:图结构）
- 代表：
Neo4j
- 应用：社交网络
- 优势：利用图结构相关算法
- 劣势:需要对整个图做计算才能得出结果，不容易做分布式集群方案
Redis特点
- 高效性
- 原子性
支持多种数据结构（string，list，set，zset，hash）稳定性（持久化，主从复制）- 其他特性：支持过期时间，支持半事务，消息订阅
- 缺点：
ACID（原子性，一致性，隔离性，持久性）处理简单
Redis和Memcached的区别
Redis数据类型
String:过期时间（短信验证码)，计数（防超卖）
list：模拟阻塞队列，双端队列，栈；微博评论列表；分页
set：去重（UV统计），交集（共同好友/爱好。。。）
zset：分值（排行榜）
hash：存储JavaBean（购物车）
Redis持久化
RDB
- 原理：
定时快照
- 优点：对性能影响小；
方便恢复；底层存储二进制
- 缺点：不易读，可能在定时时间内丢失数据；
dump全量
AOF
- 原理：
将命令追加到AOF文件，类似（HBase的WAL预写） 提供三种同步时机（交给系统；每写一条；每秒）
- 优点：
安全；AOF文件易读；rewrite机制合并无效文件
- 缺点：
AOF不是二进制，大；配置always会影响性能；数据恢复需要重演AOF文件，慢
Redis主从复制
- 容灾备份（主从数据一样）
- 读写分离（主读写，从只读）
- 缺点：
主挂了就不能写了
Redis哨兵机制
- 监控所有服务器，当主节点挂了，在它下属从节点选新的主节点
- 本质：
是一个后台进程，不断和Redis服务器做通信/心跳检测
- 缺点：集群无法水平扩展
Redis集群
- 本质：Redis-Cluster就是一个
多分片多副本的模式
- 注意:Redis-Cluster的多个master(多个分片)是平等的
- 特点：几乎不需要担心宕机；重复利用所有机器性能；没有中心节点；根据数据key的hash均匀分散到每个master/分片中（总共16384个槽）
Redis发布订阅
Redis事务
- 事务中的所有命令串行化顺序执行，期间不会为其他客户端请求提供服务
- Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以
Redis 事务的执行并不是原子性的。
- Redis支持事务, 但是不够严格完整,只能说是
半事务
- 若在事务队列中存在
命令性错误（类似于java编译性错误），则执行EXEC命令时，所有命令都不会执行–和之前一样
- 若在事务队列中存在
语法性错误（类似于java的1/0的运行时异常），则执行EXEC命令时，其他正确命令会被执行，错误命令抛出异常。–和之前不一样,并没有完全回滚
缓存雪崩/穿透/降级…名词解释
缓存雪崩（由于原有缓存失效，新缓存未到期间）
- 解决:
1.加锁2.队列3.将缓存失效时间分散开
- 总之保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上
缓存穿透（查数据，数据库没有，自然在缓存中也不会有，会进行缓存、数据库两次无用查询）
- 解决：
1.布隆过滤器2.将空结果进行缓存（过期时间不能太长，比如可以5分钟）
缓存预热
系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！- 解决：定时刷新缓存
缓存降级
- 当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要
保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。
- 目的：保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。
- 解决:常见的做法：Redis出现问题，不去数据库查询，而是直接返回默认值给用户
Redis线程安全问题
- 不存在
Redis6.0之前都是单线程的!但是利用的IO多路复用技术 + 底层是C语言实现的, 所以数据还是很快（我们说的单线程是对外服务,操作数据的线程只有一个, 后台进程做备份什么的不算在内的…)Redis6.0之后支持多线程了，默认不开启, 如果开启了,也会有底层的阻塞队列保证同一时刻只有一条命令被执行所以我们不需要去考虑控制 key、lua、事务，LPUSH/LPOP 等等的并发及线程安全问题。
转载自blog.csdn.net/qq_46893497/article/details/114199506