Redis初识
Redis介绍
Redis是一个使用C语言编写的，开源的高性能非关系型（NOSQL）的键值对数据库。
Redis可以存储键和五种不同类型的值之间的映射。键的类型只能为字符串，值支持五种数据类型：字符串、列表、集合、散列表、有序集合。
与传统数据库不同的是Redis的数据是存在内存当中的，所以读写速度非常快，因此Redis被广泛应用于缓存方向，每秒可以处理超过10万次读写操作，是已知性能最快的Key-ValueDB。另外，Redis也经常用来做分布式锁。除此之外，Redis支持事务、持久化、LUA脚本、LRU驱动事件、多种集群方案。
在这里所提出的问题就是：为什么要把数据存储在内存当中？直接定义一个变量来存储数据，不就能在内存中访问了吗？
没错，在单主机的进程当中，确实可以通过变量来存储数据，让整个进程来使用。但是Redis是在分布式系统中才能发挥威力的，分布式就是系统中的多个模块被部署于不同服务器之上，即可以将该系统称为分布式系统。如 Web 服务器与数据库分别⼯作在不同的服务器上，或者多台 Web 服务器被分别部署在不同服务器上。由于进程之间具有隔离性，当存在多台计算机同时工作时，此时一个变量就无法让其它计算机进行访问。要想访问的话，最常见的方法就是通过网络，而Redis就是基于网络，将内存中的数据供其它计算机进行使用。比如，为了更好的满足现实需要，⼀个在同⼀个办公场地的工作小组被分散到多个城市的不同工作场地中进⾏远程配合⼯作完成目标。跨主机之间的模块之间的通信基本要借助⽹络⽀撑完成。
通过后面的学习，我们还可以将Redis作为数据库来使用，现在主流的数据库，如MySql、postgreSql等，它们都是把数据存储在硬盘当中，读写的速度很慢，而Redis是在内存当中进行读写，速度非常快。当前很多互联网产品中，对于性能的要求是很高的，所以Redis才能让程序员们备受青睐。
那么，既然Redis这么优秀，是不是可以抛弃其它数据库呢。这肯定是不可以的，和MySQL相比，Redis最大的劣势就是存储空间是有限的，它不能存储大量的数据。当今最常见的情况就是把Redis和其它的数据库联合起来进行使用，例如，将MySQL作为数据库，用Redis做缓存。把需要经常访问的数据放在Redis中，每次用户进行访问的时候，可以先在Redis中查找，没有的话，再去MySQL中查找。
这里可以引出一个经典概念，就是“二八原则”，在计算机当中，这个原则的意思就是“20%的数据，可以满足80%的访问需求”。
优点和缺点
优点
- 读写性能优异， Redis能读的速度是110000次/s，写的速度是81000次/s。
- 支持数据持久化，支持AOF和RDB两种持久化方式。
- 支持事务，Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行。
- 数据结构丰富，除了支持string类型的value外还支持hash、set、zset、list等数据结构。
- 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。
缺点
- 数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
- Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
- 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
- Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。
分布式架构
- 单机架构：只有一台服务器，这个服务器负责所有的工作。
假定有一个电商网站，它们的架构图如下所示：
上面的应用服务程序相当于是服务器程序，写的是HTTP服务，数据库服务是MySQL，MySQL是一个客户端服务器结构的程序，本体是MySQL服务器（存储和组织数据的部分）。在单机程序中，能不能把数据库服务器也去掉，光留一个应用服务器既负责业务，有负责数据存储。答案是可以的，但是就是会比较麻烦。
现在绝大部分的公司的产品，都使用的是这种单机架构。因为现在的计算机硬件发展速度是非常快的，就算只有一台主机的性能也是很高的，可以支持非常高的并发和非常大的数据存储。
例如初期，我们需要利用我们精⼲的技术团队，快速将业务系统投⼊市场进⾏检验，并且可以迅速响应变化要求。但好在前期⽤⼾访问量很少，没有对我们的性能、安全等提出很⾼的要求，⽽且系统架构简单，⽆需专业的运维团队，所以选择单机架构是合适的。但是随着产品更新的越来越好，用户量和数据量都水涨船高，这个时候一台主机显然是难以应付的，那么就需要引入更多的主机和硬件资源。
当然一台主机的硬件资源是有上限的，比如有CPU、内存、硬盘等等，服务器每次收到一个请求，都是需要消耗一些这些资源的，处理的请求越多，就可能会导致某个硬件资源不够用，产生的结果就是服务器请求处理的时间变长，甚至出错。
要想解决这种服务器不够用的场景，有两种解决方案，第一种是“节流”，也就是在软件上进行优化，例如换一种更好的算法，减少资源消耗，这种对程序员的水平要求比较高；第二种就是“开源”，就是增加更多的硬件资源，但是计算机中的硬件多少取决于主板的扩展能力，要是扩展到极限还是不能满足需要、那只能引入更多的主机了，一旦引入更多台主机，我们的系统就可以称为是“分布式系统”。
- 应用数据分类架构
随着系统的上线，我们不出意外地获得了成功。市场上出现了⼀批忠实于我们的用户，使得系统的访问量逐步上升，逐渐逼近了硬件资源的极限，同时团队也在此期间积累了对业务流程的⼀批经验。面对当前的性能压力，我们需要未雨绸缪去进⾏系统重构、架构挑战，以提升系统的承载能力。但由于预算仍然很紧张，我们选择了将应用和数据分离的做法，可以最小代价的提升系统的承载能力。
应用服务器，里面可能包含很多的业务逻辑，可能会吃CPU和内存；数据库服务器，需要更大的硬盘空间，更快的数据访问速度，另外可以配置更大的服务器，甚至还可以上固态硬盘。让应用服务器和存储服务器分离，可以达到更高的性价比。
- 应用服务集群架构
要用到这个模式的架构，说明单台应用服务器已经满足不了我们的需求了，需要引入更多的应用服务器节点。如下图所示：
用户的请求，会先到达负载均衡服务器(单独的服务器)，这里的负载均衡就像一个公司的一个组的领导一样，要负责管理，把一个大的任务分成若干个小任务让下面的成员去完成。假设有1w个用户请求，有2个应用服务器，此时按照负载均衡的方式，就可以让每个应用服务器承担5千的访问量。这个就像我们之前所学的多线程一样。
不过要想实现负载均衡，需要知道相关的算法，我们会在后面的学习中进行讲解。
- 读写分离/主从分离架构
在上一个架构中，我们把用户的请求通过负载均衡分发到不同的应⽤服务器之后，可以并行处理了，并且可以随着业务的增长，可以动态扩张服务器的数量来缓解压力。但是现在的架构里，无论扩展多少台服务器，这些请求最终都会从数据库读写数据，到⼀定程度之后，数据的压力称为系统承载能力的瓶颈点。
我们可以像扩展应⽤服务器⼀样扩展数据库服务器么？答案是否定的，因为数据库服务有其特殊性：如果将数据分散到各台服务器之后，数据的⼀致性将⽆法得到保障。所谓数据的⼀致性，此处是指：针对同⼀个系统，无论何时何地，我们都应该看到⼀个始终维持统⼀的数据。想象⼀下，银⾏管理的账户金额，如果收到⼀笔转账之后，⼀份数据库的数据修改了，但另外的数据库没有修改，则用户得到的存款金额将是错误的。
针对这种情况，解决办法是保留一个主要的数据库作为主数据库，其它的数据库作为从属数据库。从库的所有数据全部来自主库的数据，经过同步后，从库可以维护着与主库一致的数据，然后为了分担数据库的压力，我们可以将写数据请求全部交给主库处理，但读请求分散到各个从库中。这是因为，大部分都情况下，读请求的次数要比写请求次数多，所以只要将读请求由各个从库分担之后，数据库的压力就没有那么大了。当然这个过程不是⽆代价的，主库到从库的数据同步其实是由时间成本的，但这个问题我们暂时不做进⼀步探讨。
- 冷热分离架构
随着访问量继续增加，发现业务中⼀些数据的读取频率远大于其他数据的读取频率。我们把这部分数据称为热点数据，与之相对应的是冷数据。想一下，自己手机中从前的照片，你还会经常去看吗，绝大多数情况下，人们都是喜新厌旧的。针对热数据，为了提升其读取的响应时间，可以增加
本地缓存，并在外部增加分布式缓存，缓存热门商品信息或热门商品的 html页面等。通过缓存能把绝大多数请求在读写数据库前拦截掉，大大降低数据库压力。这就是开头我们所说的二八原则。
图片中的缓存服务器，就可以使用Redis来实现，存储服务器存储的仍然是完整的全部数据。
- 分离架构
随着业务量的逐渐增大，一台服务器可能支持不了这么大的数据，那么就需要更多台服务器来进行存储。比如我们常用的抖音软件，每个视频包含视频主体、评论、点赞、链接等元素，我们可以引入多个数据库服务器，每个数据库服务器存储一个或一部分数据。原来只有一个数据库服务器，对数据库进行进一步的拆分，这个就叫做分库分表。
只要实时操作的表数据量足够小，请求能够足够均匀的分发到多台服务器上的小表，那数据库就能通过水平扩展的方式来提高性能。
- 微服务架构
之前的应用服务器，一个服务器程序里面做了很多的业务，这可能会导致这一个服务器端代码变的越来越复杂。所以为了更方便于代码的维护，就可以把这样的一个复杂的服务器，拆分成更多的，功能更单一，但是更小的服务器。微服务就是服务器的种类和数量都增加了。
Redis特性
市面上有许多的数据库可供选择，可Redis最受欢迎，这与它的特性有很大的关系。
- 速度快
由于Redis是在内存中存储数据，这导致了访问的效率非常高，官⽅给出的数字是读写性能可以达到 10 万 / 秒，当然这也取决于机器的性能。Redis主要是通过“键值对”的方式来存储组织数据的，它是一直“非关系型数据库”。而且Redis 使用了单线程，预防了多线程可能产生的竞争问题。(Redis 在 6.0 版本引⼊了多线程机制，但主要也是在处理网络和 IO，不涉及到数据命令，即命令的执行仍然采⽤了单线程模式)。 - 丰富的数据类型
Redis 不仅支持基本的键值存储(键只能是string)，还提供了丰富的数据类型，包括字符串、列表、集合、哈希表、有序集合等。这些数据类型为开发者提供了灵活的数据操作能力，使得Redis可以适应各种不同的应用场景。 - 持久化
Redis 支持数据的持久化，可以将内存中的数据保存到磁盘中，以便在系统重启后恢复数据。这为 Redis 提供了数据安全性，确保数据不会因为系统故障而丢失。主要是以内存为主，磁盘为辅，如果Redis重启了，就会在重启时加载磁盘中的备份数据，使Redis的内存恢复到重启前的状态。 - 支持脚本
Redis 支持使用 Lua 脚本来编写复杂的操作，这些脚本可以在服务器端执行，提供了更多的灵活性和强大的功能。 - 丰富的特性集
Redis 还支持 publish/subscribe（发布/订阅）模式、通知、key 过期等高级特性。这些特性使得 Redis 可以用于消息队列、实时数据分析等复杂的应用场景。 - 可扩展性高
Redis提供了一组API，通过C、C++、Rust语言可以编写Redis扩展。比如Redis自身已经提供了很多的数据结构和命令，通过扩展，让Redis支持更多的数据结构以及支持更多的命令。