Redis上

最新推荐文章于 2024-01-12 08:00:00 发布

JUSTHUSKY

最新推荐文章于 2024-01-12 08:00:00 发布

阅读量142

点赞数

文章标签： redis 分布式

本文链接：https://blog.csdn.net/JUSTHUSKY/article/details/115961904

版权

本文深入探讨了Redis的使用，从互联网架构的演变背景出发，介绍了Redis的入门知识，包括它作为NoSQL数据库的优势。接着，文章对比了Redis与Memcache、MongoDB的特性，讨论了分布式数据库的CAP原理。详细阐述了Redis的下载安装过程，并详细讲解了Redis的五大数据类型：String、List、Set、Hash和Zset，及其各种操作。最后，文章提供了实际操作示例，如键的模糊查询和不同数据类型的使用场景。

摘要由CSDN通过智能技术生成

1.概述

1.1 互联网架构的演变历程

第一阶段
- 数据访问量不大，简单的架构即可搞定。
第2阶段
- 数据访问量大，使用缓存技术来缓解数据库的压力。
- 不同的业务访问不同的数据库。（分库）
第3阶段
- 主从读写分离
- 一个数据库负责写(主库)，一个数据库负责读（从库)。分工合作
第4阶段
- mysql集群

1.2 Redis入门介绍

互联网三高需求：高并发，高可扩，高性能。
Redis 是一种运行速度很快，并发性能很强，并且运行在内存上的NoSql（not only sql）数据库。
NoSQL数据库和传统数据库相比的优势：
1. NoSQL数据库无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。
Redis的常用使用场景：
- 缓存：一些频繁被访问的数据，放在内存中的可以很高效的访问。
- 排行榜：利用Redis的SortSet(有序集合)数据结构能够简单的搞定。
- 计算器/限速器：原子自增操作；限制某个用户访问某个API的频率。
- 好友关系：利用集合命令（交集、并集、差集）。
- 简单消息队列：
- Session共享：集群服务中，采用Redis保存Session后，无论用户落在那台机器上都能够获取到对应的Session信息。不会出现不同机器要求频繁登录。

1.3 Redis/Memcache/MongoDB对比

1.3.1 Redis和Memcache

竞争关系，从存储的内容、存储的数据结构、是否定期存到磁盘、数据是否可以恢复来看。

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

1.3.2 Redis和MongoDB

是一种协作共存的关系。
mongodb本质上还是硬盘数据库，这时就需要redis或Memcache这样的内存数据库来作为中间层进行缓存和加速。

1.4 分布式数据库CAP原理

1.4.1 传统关系型数据库事务

ACID
- A：原子性：每个事务都是一个整体，不可再拆分，事务中所有的 SQL 语句要么都执行成功，要么都失败。
- C：一致性：事务在执行前数据库的状态与执行后数据库的状态保持一致。
- I：独立性：事务与事务之间不应该相互影响，执行时保持隔离的状态.
- D：持久性：一旦事务执行成功，对数据库的修改是持久的。

1.4.2 分布式数据库的CAP:

C（Consistency）：强一致性
- 更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致。
A（Availability）：高可用性
- 服务一直可用。
P（Partition tolerance）：分区容错性
- 即分布式系统在遇到某节点或网络分区故障时，仍然能够对外提供满足一致性或可用性的服务。

1.4.2 CAP理论

CAP理论提出就是针对分布式数据库环境的，P属性是必须存在，而C、A二者选其一。
最常见的例子是读写分离，某个节点负责写入数据，然后将数据同步到其它节点，其它节点提供读取的服务，当两个节点出现通信问题时，你就面临着选择A（继续提供服务，但是数据不保证准确），C（用户处于等待状态，一直等到数据同步完成）。