学了一段时间的redis,觉得以前对Redis的了解太过浅薄了, 现在内心有种强烈的冲动想要把最近学到的知识和我对Redis的理解给写出来。

Redis是什么

Redis是一个基于键值对NoSQL数据库,与很多键值对数据库不同,Redis 提供了丰富的 值数据存储结构,包括 stringhashlistsetzset(有序集合)等。

为什么要使用Redis

![image-20210205174819181](/Users/weijiezhu/Library/Application Support/typora-user-images/image-20210205174819181.png)

随着互联网用户的不断增加,早在90年代单靠一个MySQL就能支撑起整个网站的数据服务已经不复存在了,因为在如今的大数据时代,MySQL数据已经无法满足现在的需求了,所以有了Memcached这样的缓存服务器

Memcached + MySQL

Memcached 作为一个独立的分布式的缓存服务器,为多个 web 服务器提供了一个共享的高性能缓存服务,在 Memcached 服务器上,又发展了根据 hash 算法来进行多台 Memcached 缓存服务的扩展,然后又出现了一致性 hash 来解决增加或减少缓存服务器导致重新 hash 带来的大量缓存失效的弊端。

Mencached解决了MySQL的读取压力,但是写入的压力还没解决,随即就有了MySQL的主从复制技术。

MySQL主从复制

主从复制简单来讲就是由一个主服务器和一个或者多个从服务器转换成的服务器架构,目的是为了将读写分离开来减少服务器压力。

主服务器上的任何修改都会保存在二进制日志Binary log中,然后从服务器会通过I/O也就是客户端去连接主服务器读取二进制日志,然后将二进制日志写到本地的Relay log中。同时从服务器会开启一个SQL线程,监控Relay log,如果有改动就立即执行更改内容。

分表分库

随着 web2.0 的继续高速发展,在 Memcached 的高速缓存,MySQL 的主从复制,读写分离的基础之上,这时 MySQL 主库的写压力开始出现瓶颈,而数据量的持续猛增,由于 MyISAM 使用表锁,在高并发下会出现严重的锁问题,大量的高并发 MySQL 应用开始使用 InnoDB 引擎代替 MyISAM。同时,开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候,分表分库成了一个热门技术,是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候,MySQL 推出了还不太稳定的表分区,这也给技术实力一般的公司带来了希望。虽然 MySQL 推出了 MySQL Cluster 集群,但是由于在互联网几乎没有成功案例,性能也不能满足互联网的要求,只是在高可靠性上提供了非常大的保证。

MySQL 的扩展性瓶颈

大数据量高并发环境下的 MySQL 应用开发越来越复杂,也越来越具有技术挑战性。分表分库的规则把握都是需要经验的。虽然有像淘宝这样技术实力强大的公司开发了透明的中间件层来屏蔽开发者的复杂性,但是避免不了整个架构的复杂性。分库分表的子库到一定阶段又面临扩展问题。还有就是需求的变更,可能又需要一种新的分库方式。

MySQL 数据库也经常存储一些大文本字段,导致数据库表非常的大,在做数据库恢复的时候就导致非常的慢,不容易快速恢复数据库。

关系数据库很强大,但是它并不能很好的应付所有的应用场景。MySQL 的扩展性差(需要复杂的技术来实现),大数据下 IO 压力大,表结构更改困难,正是当前使用 MySQL 的开发人员面临的问题。

MySQL相比NoSQL存在的缺点

其实MySQL是能够支持海量数据的,但是由于它的扩展困难读写速度缓慢再加上横向扩展的局限性才延伸出了NoSQL这样的缓存数据库技术

  • 扩展困难: 由于存在join这样的多表查询机制,如果要扩展需要不断的拆表拆库,十分艰难;
  • 读写速度缓慢: 当数据量达到一定规模的时候,因为关系型数据库逻辑十分复杂,多表查询的速度被逻辑的复 杂度所影响,速度下滑很严重,甚至还会出现死锁的情况;
  • 容量有限:现有关系型解决方案还无法支撑Google这样海量的数据存储;

NoSQL的优点

易扩展

NoSQL 数据库种类繁多,但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系,这样就非常容易扩展。也无形之间,在架构的层面上带来了可扩展的能力。

高性能,读写速度快

Redis为例,由于其逻辑简单,而且纯内存操作,使得其性能非常出色,官方数据表示Redis读的速度是110000次/秒,写的速度是81000次/秒。

支持海量数据

NoSQL 数据库都具有非常高的读写性能,尤其在大数据量下,同样表现优秀。这得益于它的无关系性,数据库的结构简单。一般 MySQL 使用 Query Cache,每次表的更新 Cache 就失效,是一种大粒度的 Cache,在针对 web2.0 的交互频繁的应用,Cache 性能不高。而 NoSQLCache 是记录级的,是一种细粒度的 Cache,所以 NoSQL 在这个层面上来说就要性能高很多了。

灵活的数据模型

NoSQL 无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式。而在关系数据库里,增删字段是一件非常麻烦的事情。如果是非常大数据量的表,增加字段简直就是一个噩梦。这点在大数据量的 web2.0 时代尤其明显。

而在众多NoSQL数据库中如:MongoDBMembaseNeo4jCassandraRedis中以Redis的速度最快,这也是为什么众多互联网公司都偏爱使用Redis

小结

这里花了太多篇幅讲为什么使用Redis,所以稍微做个小结。

随着互联网用户的增加,目前MySQL无法独自支撑起有着海量用户的网站了,它的扩展性,性能等一些列原因导致我们不得不借助NoSQL类数据库来帮助MySQL解决这些问题,虽然我们也尝试用了主从复制,分库分表等服务器架构模式来减少MySQL的性能压力,但是NoSQL的易扩展、高速读写能力,支持海量数据和灵活的数据模型实在是太香了。

Redis的应用场景

场景一 数据库表经常需要加字段

比如在线商城,维护产品的属性经常要增加字段,如果该表的数据量过百万,新增字段会带来额外开销(重建索引等)。NoSQL应用在这种场景,可以极大提升DB的可伸缩性,开发人员可以将更多的精力放在业务层。

1. 缓存

将热点数据缓存起来,同时设置内存的最大使用量和淘汰策略来保证缓存的命中率。

2. session服务器

使用redis作为统一的session服务器,则后端可以进行集群部署。

3. 社交朋友圈

Set可以实现交集、并集等操作,从而实现共同好友等功能

4. 排行榜

ZSet可以实现有序性操作,从而实现排行榜等功能(以访问量为分数进行排列)

5. 分布式锁

由于Redis的单线程特性,其实也是很重要的应用场景,最常用的就是分布式锁。

6.分布式和持久化有效应对海量数据和高并发

Redis初期的版本官方只是支持单机或者简单的主从,大多应用则都是自己去开发集群的中间件,但是随着应用越来越广泛,用户关于分布式的呼声越来越高,所以Redis 3.0版本时候官方加入了分布式的支持,主要是两个方面:

  • Redis服务器主从热备,确保系统稳定性
  • Redis分片应对海量数据和高并发

Redis虽然是一个内存缓存,数据存在内存,但是Redis支持多种方式将数据持久化,写入硬盘,所有,Redis数据的稳定性也是非常有保障的,结合Redis的集群方案,有的系统已经将Redis当做一种NoSql数据存储来适用。

总结

NoSQL作为横空出世的数据库,很好的弥补了MySQL目前部分功能的不足,极大地节省了开发成本和维护成本同时也提升了部分性能。Redis作为NoSQL数据库的代表,读写速度快作为它的招牌菜已经成为了大部分互联网公司的首选NoSQL数据库。

MySQLNoSQL的结合是web2.0时代的神兵利器,也给我们开发者带来了很多新思路。希望越来越多的开发者能关注这些产品,多花些心思在这些工具上,共勉。