文章目录
一、理解Redis
1、什么是Redis?
Redis是一个开源的内存中的数据结构存储系统，它可以用作：数据库、缓存和消息中间件
redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。
Redis 是一个高性能的key-value数据库。
redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部分场合可以对关系数据库起到很好的补充作用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客户端，使用很方便。
Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。
redis的官网地址，非常好记，是redis.io。（域名后缀io属于国家域名，是british Indian Ocean
territory，即英属印度洋领地） 目前，Vmware在资助着redis项目的开发和维护。
2、为什么要使用Redis?
从性能和并发两方面考虑：
在我们日常的Java Web开发中，无不都是使用数据库来进行数据的存储，由于一般的系统任务中通常不会存在高并发的情况，
所以这样看起来并没有什么问题，可是一旦涉及大数据量的需求，比如一些商品抢购的情景，或者是主页访问量瞬间较大的时候，
单一使用数据库来保存数据的系统会因为面向磁盘，磁盘读/写速度比较慢的问题而存在严重的性能弊端，一瞬间成千上万的请求到来，
需要系统在极短的时间内完成成千上万次的读/写操作，这个时候往往不是数据库能够承受的，极其容易造成数据库系统瘫痪，
最终导致服务宕机的严重生产问题。
3、redis单线程+多路I/O复用模型
单线程的模式解决了数据存储的顽疾：数据并发安全，任何运行多线程同时访问数据库都会存在这个问题，所以才有了mysql的mvcc和锁， Memcached 的cas 乐观锁，来保证数据不会出现并发导致的数据问题，但是redis 使用单线程就不存在这个问题：1，单线程足够简单，无论在redis的实现还是作为调用方，都不需要为数据并发提心吊胆，不需要加锁。 2.不会出现不必要的线程调度，你知道多线程，频繁切换上下文，也会带来很多性能消耗
什么是切换上下文？
线程每次执行需要把数据从主内存读到工作内存，然而当线程被调度到阻塞的时候，这些工作内存的数据需要被快照到线程上下文中，其实就是一个记录各个线程状态的存储结构，等到线程被唤醒的时候，再从上下文中读取，称之为上下文切换；减少上下文切换操作，也是使用单线程的奥妙
多路 I/O 复用模型，这个也是java 的NIO体系使用的IO模型，也是linux诸多IO模型中的一种，说白了就是当一个请求来访问redis后，redis去组织数据要返回给请求，这个时间段，redis的请求入口不是阻塞的，其他请求可以继续向redis发送请求，等到redis io流完成后，再向调用者返回数据，这样一来，单线程也不怕会影响速度了
- 这里“多路”指的是多个网络连接
- “复用”指的是复用同一个线程
我们使用单线程的方式是无法发挥多核CPU 性能，不过我们可以通过在单机开多个Redis 实例来完善
5、什么是缓存击穿？
缓存一般作为RDS（后端数据库）的前置系统和服务器直连，减轻rds的负担，常理而言，如果服务器查询缓存而不得的话，需要从rds中获取然后更新到缓存中，但是如果在“从rds中获取然后更新到缓存中”，这个阶段，缓存尚未更新成功，大量请求进来的话，rds势必压力暴增，甚至雪崩，或者歹人恶意攻击，一直查询rds和缓存中未存在key，也会导致缓存机制失效，rds压力暴增，称之为缓存击穿
解决方法：
缓存永不失效，定时同步rds redis，不允许应用直接请求查询rds，所有的查询以缓存中为准
在大并发的情况下，所有的请求直接访问数据库，数据库会出现连接异常。这个时候，就需要使用 Redis 做一个缓冲操作，让请求先访问到 Redis，而不是直接访问数据库
6、Redis 的过期策略和内存淘汰机制
Redis 采用的是定期删除+惰性删除策略
（1）采用定期删除+惰性删除就没其他问题了么？
不是的，如果定期删除没删除掉 Key。并且你也没及时去请求 Key，也就是说惰性删除也没生效。这样，Redis 的内存会越来越高
（2）如果一个键过期了，那么它什么时候会被删除呢？
定时删除:在设置键的过期时间的同时，创建一个定时器( timer ). 让定时器在键的过期时间来临时，立即执行对键的删除操作。
惰性删除:放任键过期不管，但是每次从键空间中获取键时，都检查取得的键是否过期，如果过期的话，就删除该键;如果没有过期，就返回该键。
定期删除: 每隔一段时间，程序就对数据库进行一次检查，删除里面的过期键。至于要删除多少过期键，以及要检查多少个数据库， 则由算法决定。
在这三种策略中，第一种和第三种为主动删除策略， 而第二种则为被动删除策略
（3）定时删除
定时删除策略对内存是最友好的:通过使用定时器，定时删除策略可以保证过期键会尽可能快地被删除，并释放过期键所占用的内存。另一方面，定时删除策略的缺点是，它对CPU 时间是最不友好的:在过期键比较多的情况下，删除过期键这一行为可能会占用相当一部分CPU 时间，在内存不紧张但是CPU 时间非常紧张的情况下.将CPU 时间用在删除和当前任务无关的过期键上，无疑会对服务器的响应时间和吞吐量造成影响。
例如，如果正有大量的命令请求在等待服务器处理，并且服务器当前不缺少内存，那么服务器应该优先将CPU 时间用在处理客户端的命令请求上面，而不是用在删除过期键上面。除此之外，创建一个定时器需要用到Redis 服务器中的时间事件，而当前时间事件的实现方式一一无序链表，查找一个事件的时间复杂度为O(N)一并不能高效地处理大量时间事件。
因此，要让服务器创建大量的定时器，从而实现定时删除策略，在现阶段来说并不现实。
（4）惰性删除
惰性删除策略对CPU 时间来说是最友好的:程序只会在取出键时才对键进行过期检查，这可以保证删除过期键的操作只会在非做不可的情况下进行， 并且删除的目标仅限于当前处理的键，这个策略不会在删除其他无关的过期键上花费任何CPU时间。
惰性删除策略的缺点是，它对内存是最不友好的: 如果一个键已经过期，而这个键又仍然保留在数据库中，那么只要这个过期键不被删除，它所占用的内存就不会释放。在使用惰性删除策略时，如果数据库中有非常多的过期键，而这些过期键又恰好没有被访问到的话，那么它们也许永远也不会被删除(除非用户手动执行FLUSHDB),我们甚至可以将这种情况看作是一种内存泄漏一一无用的垃圾数据占用了大量的内存，而服务器却不会自己去释放它们，这对于运行状态非常依赖于内存的Redis服务器来说，肯定不是一个好消息。
举个例子，对于一些和时间有关的数据，比如日志(log) ，在某个时间点之后，对它们的访问就会大大减少，甚至不再访问，如果这类过期数据大量地积压在数据库中，用户以为服务器已经自动将它们删除了，但实际上这些键仍然存在， 而且键所占用的内存也没有释放，那么造成的后果肯定是非常严重的。
（5）定期删除
从上面对定时删除和惰性删除的讨论来看，这两种删除方式在单一使用时都有明显的缺陷:
定时删除占用太多CPU 时间，影响服务器的响应时间和吞吐量。惰性删除浪费太多内存，有内存泄漏的危险。
定期删除策略是前两种策略的一种整合和折中:
定期删除策略每隔一段时间执行一次删除过期键操作，并通过限制删除操作执行的时长和频率来减少删除操作对CPU 时间的影响。除此之外，通过定期删除过期键，定期删除策略有效地减少了因为过期键而带来的内存浪费。定期删除策略的难点是确定删除操作执行的时长和频率:
如果删除操作执行得太频繁，或者执行的时间太长，定期删除策略就会退化成定时删除策略，以至于将C P U 时间过多地消耗在删除过期键上面。
如果删除操作执行得太少，或者执行的时间太短，定期删除策略又会和惰性删除策略一样，出现浪费内存的情况。
因此，如果采用定期删除策略的话，服务器必须根据情况，合理地设置删除操作的执行时长和执行频率。
7、Redis的事务功能
注意：如果对数据有强一致性要求，不能放缓存
（1）Redis会将一个事务中的所有命令序列化，然后按顺序执行。
Redis不可能在一个Redis事务的执行过程中插入执行另一个客户端发出的请求。这样便能保证Redis将这些命令作为一个单独的隔离操作执行。 > 在一个Redis事务中，Redis要么执行其中的所有命令，要么什么都不执行。因此，Redis事务能够保证原子性。EXEC命令会触发执行事务中的所有命令。因此，当某个客户端正在执行一次事务时，如果它在调用MULTI命令之前就从Redis服务端断开连接，那么就不会执行事务中的任何操作；相反，如果它在调用EXEC命令之后才从Redis服务端断开连接，那么就会执行事务中的所有操作
（2）为什么Redis不支持回滚？
回滚（Rollback）指的是程序或数据处理错误，将程序或数据恢复到上一次正确状态的行为。删除由一个或多个部分完成的事务执行的更新。
如果你具备关系型数据库的知识背景，你就会发现一个事实：在事务运行期间，虽然Redis命令可能会执行失败，但是Redis仍然会执行事务中余下的其他命令，而不会执行回滚操作，你可能会觉得这种行为很奇怪然而，这种行为也有其合理之处：
只有当被调用的Redis命令有语法错误时，这条命令才会执行失败（在将这个命令放入事务队列期间，Redis能够发现此类问题），或者对某个键执行不符合其数据类型的操作：实际上，这就意味着只有程序错误才会导致Redis命令执行失败，这种错误很有可能在程序开发期间发现，一般很少在生产环境发现。
Redis已经在系统内部进行功能简化，这样可以确保更快的运行速度，因为Redis不需要事务回滚的能力。
对于Redis事务的这种行为，有一个普遍的反对观点，那就是程序有可能会有缺陷（bug）。但是，你应当注意到：事务回滚并不能解决任何程序错误。例如，如果某个查询会将一个键的值递增2，而不是1，或者递增错误的键，那么事务回滚机制是没有办法解决这些程序问题的。请注意，没有人能解决程序员自己的错误，这种错误可能会导致Redis命令执行失败。正因为这些程序错误不大可能会进入生产环境，所以我们在开发Redis时选用更加简单和快速的方法，没有实现错误回滚的功能
8、redis的持久化
Redis也提供了持久化的选项，这些选项可以让用户将自己的数据保存到磁盘上面进行存储。根据实际情况，可以每隔一定时间将数据集导出到磁盘（快照），或者追加到命令日志中（AOF只追加文件），他会在执行写命令时，将被执行的写命令复制到硬盘里面。您也可以关闭持久化功能，将Redis作为一个高效的网络的缓存数据功能使用
Redis不使用表，他的数据库不会预定义或者强制去要求用户对Redis存储的不同数据进行关联
Redis的应用：
存储 缓存 用的数据；
需要高速读/写的场合使用它快速读/写；
9、redis实现的技术
- 持久化：持久化是最简单的高可用方法（有时甚至不被归为高可用的手段），主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。
- 复制：复制是高可用Redis的基础，哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷是故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。
- 哨兵：在复制的基础上，哨兵实现了自动化的故障恢复。缺陷是写操作无法负载均衡；存储能力受到单机的限制。
- 集群：通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。
二、Mysql和Redis数据库的区别
（1）mysql和redis的数据库类型
mysql是关系型数据库，主要用于存放持久化数据，将数据存储在硬盘中，读取速度较慢。
redis是NOSQL，即非关系型数据库，也是缓存数据库，即将数据存储在缓存中，缓存的读取速度快，能够大大的提高运行效率，但是保存时间有限
（2）mysql的运行机制
mysql作为持久化存储的关系型数据库，相对薄弱的地方在于每次请求访问数据库时，都存在着I/O操作，如果反复频繁的访问数据库。第一：会在反复链接数据库上花费大量时间，从而导致运行效率过慢；第二：反复的访问数据库也会导致数据库的负载过高，那么此时缓存的概念就衍生了出来。
（3）缓存
缓存就是数据交换的缓冲区（cache），当浏览器执行请求时，首先会对在缓存中进行查找，如果存在，就获取；否则就访问数据库。
缓存的好处就是读取速度快
（4）redis数据库
redis数据库就是一款缓存数据库，用于存储使用频繁的数据，这样减少访问数据库的次数，提高运行效率。
（5）redis和mysql的区别总结
类型上：
从类型上来说，mysql是关系型数据库，redis是缓存数据库
作用上：
mysql用于持久化的存储数据到硬盘，功能强大，但是速度较慢
redis用于存储使用较为频繁的数据到缓存中，读取速度快
速度上：
redis的速度:单机读可达10000次/s 写可达5000/s
mysql 经过了这么多年优化 才1000次/S,500次/S
需求上：
mysql和redis因为需求的不同，一般都是配合使用。
MySQL是关系型数据库，是持久化存储的，查询检索的话，会涉及到磁盘IO操作，为了提高性能，可以使用缓存技术，而memcached就是内存数据库，数据存储在内存中（当然也可以进行持久化存储），可以用作缓存数据库。用户首先去memcached查询数据，如果未查询到（即缓存未命中），才去MySQL中查询数据，查询到的数据会更新到缓存数据库中，提供给下次可能进行的查询。提高了数据查询方面的性能。
Redis和memcached都是缓存数据库，可以大大提升高数据量的web访问速度。
但是memcached只是提供了简单的数据结构string，而Redis的value可以是string、list、set、hash、sorted set这些，功能更加强大。
web应用中一般采用MySQL+Redis的方式，web应用每次先访问Redis，如果没有找到数据，才去访问MySQL。
Redis是内存数据库，数据保存在内存中，访问速度快。MySQL是关系型数据库，功能强大，存储在磁盘中，数据访问速度慢。像memcached，MongoDB，Redis等，都属于No sql系列。
三、Memcached和Redis对比
| 对比内容 | 具体阐述 |
|---|---|
| 性能 | 平均每一个核Redis在存储小数据时比Mencached性能更高，100k以上时Mencached性能高于redis |
| 内存空间和数据量大小 | Memcached可以修改最大内存，采用LRU算法，Redis增加了VM的特性，突破了物理内存的限制 |
| 操作方便性 | Memcached结构数据单一，仅用来缓存数据，而Redis支持更丰富的数据类型，也可以在服务器端进行丰富的操作，这样可以减少网络IO次数和数据体积 |
| 可靠性 | Memcached不支持数据持久化，断电或重启后数据消失，但其稳定性是有保证的，Redis支持数据持久化和数据恢复，允许单点故障，但是同时也会付出性能代价 |
| 应用场景 | Memcached：动态系统中减轻数据库的负担，提升性能，作缓存，适合多读少写，大数据量的情况。Redis：适合于对读写效率要求都很高，数据处理业务复杂和对安全性要求较高的系统 |
| 单个key-value的大小 | Memcached最大支持1MB。Redis最大支持512MB |
四、sql和nosql的区别
（1）概念
SQL (Structured Query Language) 数据库，指关系型数据库。主要代表：SQL Server，Oracle，MySQL(开源)，PostgreSQL(开源)
NoSQL（Not Only SQL）泛指非关系型数据库。主要代表：MongoDB，Redis，CouchDB
（2）区别
存储方式
SQL数据存在特定结构的表中，通常以数据库表形式存储数据；而NoSQL则更加灵活和可扩展，存储方式可以是JSON文档、哈希表或者其他方式。
表/数据集合的数据的关系
在SQL中，必须定义好表和字段结构后才能添加数据，例如定义表的主键(primary key)，索引(index),触发器(trigger),存储过程(stored procedure)等。表结构可以在被定义之后更新，但是如果有比较大的结构变更的话就会变得比较复杂。
在NoSQL中，数据可以在任何时候任何地方添加，不需要先定义表。
NoSQL也可以在数据集中建立索引。以MongoDB为例，会自动在数据集合创建后创建唯一值_id字段，
这样的话就可以在数据集创建后增加索引。
从这点来看，NoSQL可能更加适合初始化数据还不明确或者未定的项目中。
外部数据存储
SQL中如果需要增加外部关联数据的话，规范化做法是在原表中增加一个外键，关联外部数据表。
而在NoSQL中除了这种规范化的外部数据表做法以外，我们还能用非规范化方式把外部数据直接放到原数据集中，以提高查询效率。
SQL中的JOIN查询
SQL中可以使用JOIN表链接方式将多个关系数据表中的数据用一条简单的查询语句查询出来。
NoSQL暂未提供类似JOIN的查询方式对多个数据集中的数据做查询。所以大部分NoSQL使用非规范化的数据存储方式存储数据。
数据耦合性
SQL中不允许删除已经被使用的外部数据，以保证数据完整性。而NoSQL中则没有这种强耦合的概念，可以随时删除任何数据。
事务
SQL中如果多张表数据需要同批次被更新，即如果其中一张表更新失败的话其他表也不能更新成功。
这种场景可以通过事务来控制，可以在所有命令完成后再统一提交事务。
而NoSQL中没有事务这个概念，每一个数据集的操作都是原子级的。
查询性能
在相同水平的系统设计的前提下，因为NoSQL中省略了JOIN查询的消耗，故理论上性能上是优于SQL的。
目前许多大型互联网项目都会选用MySQL（或任何关系型数据库） + NoSQL的组合方案。
关系型数据库适合存储结构化数据，如用户的帐号、地址：
1）这些数据通常需要做结构化查询，比如join，这时候，关系型数据库就要胜出一筹
2）这些数据的规模、增长的速度通常是可以预期的
3）事务性、一致性
NoSQL适合存储非结构化数据，如文章、评论：
1）这些数据通常用于模糊处理，如全文搜索、机器学习
2）这些数据是海量的，而且增长的速度是难以预期的，
3）根据数据的特点，NoSQL数据库通常具有无限（至少接近）伸缩性
4）按key获取数据效率很高，但是对join或其他结构化查询的支持就比较差
基于它们的适用范围不同，目前主流架构才会采用组合方案，一个也不能少。
目前为止，还没有出现一个能够通吃各种场景的数据库，而且根据CAP理论，这样的数据库是不存在的。
NoSQL 技术
为了克服上述的问题，Java Web项目通常会引入NoSQL技术，这是一种基于内存的数据库，并且提供一定的持久化功能。
Redis和MongoDB是当前使用最广泛的NoSQL，而就Redis技术而言，它的性能十分优越，可以支持每秒十几万此的读/写操作，
其性能远超数据库，并且还支持集群、分布式、主从同步等配置，原则上可以无限扩展，让更多的数据存储在内存中，
更让人欣慰的是它还支持一定的事务能力，这保证了高并发的场景下数据的安全和一致性。
redis是Nosql数据库，是一个key-value存储系统
虽然redis是key-value的存储系统，但是redis支持的value存储类型是非常的多，比如字符串、链表、集合、有序集合和哈希
那么为什么要使用类似redis这样的Nosql数据库呢？
（1）当数据量的总大小一个机器放不下时；
（2）数据索引一个机器的内存放不下时；
（3）访问量（读写混合）一个实例放不下时。
单机时代，存储只用一台机器装mysql，如果每次存储成千上万条数据，这样很会导致mysql的性能很差，存储以及读取速度很慢，然后就演变成缓存+mysql+垂直拆分的方式。
Cache作为中间缓存时代，将所有的数据先保存到缓存中，然后再存入mysql中，减小数据库压力，提高效率。
但是当数据再次增加到又一个量级，上面的方式也不能满足需求，由于数据库的写入压力增加，缓存只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。
主从分离模式时代，在redis的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。
