100亿内存只需要100MB内存？这个难道离不开Redis？ 1、为什么使用redis分析:在项目

1、为什么使用redis分析:在项目中使用redis ，主要是从两个角度去考虑:性能和并发。当然， redis还具备可以做分布式锁等其他功能，但是如果只是为了分布式锁这些其他功能，完全还有其他中间件(如zookpeer等)代替，并不是非要使用redis 。因此，这个问题主要从性能和并发两个角度去答。
回答:如下所示，分为两点
（一）性能如下图所示，我们在碰到需要执行耗时特别久，且结果不频繁变动地SQL ，就特别适合将运行结果放入缓存。这样，后面的请求就去缓存中读取，使得请求能够迅速响应。
文章插图
题外话：忽然想聊一下这个迅速响应的标准。其实根据交互效果的不同，这个响应时间没有固定标准。不过曾经有人这么告诉我:"在理想状态下，我们的页面跳转需要在瞬间解决，对于页内操作则需要在刹那间解决。另外，超过一弹指的耗时操作要有进度提示，并且可以随时中止或取消，这样才能给用户最好的体验。 "那么瞬间、刹那、一弹指具体是多少时间呢？根据《摩诃僧祗律》记载
一刹那者为一念，二十念为一瞬，二十瞬为一弹指，二十弹指为一罗预，二十罗预为一须臾，一日一夜有三十须臾。
那么，经过周密的计算，一瞬间为0.36 秒,一刹那有 0.018 秒.一弹指长达 7.2 秒。（二）并发如下图所示，在大并发的情况下，所有的请求直接访问数据库，数据库会出现连接异常。这个时候，就需要使用redis做一个缓冲操作，让请求先访问到redis ，而不是直接访问数据库。
文章插图
2、使用redis有什么缺点分析:大家用redis这么久，这个问题是必须要了解的，基本上使用redis都会碰到一些问题，常见的也就几个。回答:主要是四个问题(一)缓存和数据库双写一致性问题(二)缓存雪崩问题(三)缓存击穿问题(四)缓存的并发竞争问题这四个问题，我个人是觉得在项目中，比较常遇见的，具体解决方案，后文给出。
3、单线程的redis为什么这么快分析:这个问题其实是对redis内部机制的一个考察。其实根据博主的面试经验，很多人其实都不知道redis是单线程工作模型。所以，这个问题还是应该要复习一下的。回答:主要是以下三点(一)纯内存操作(二)单线程操作，避免了频繁的上下文切换(三)采用了非阻塞I/O多路复用机制
题外话：我们现在要仔细地说一说I/O多路复用机制，因为这个说法实在是太通俗了，通俗到一般人都不懂是什么意思。博主打一个比方：小曲在S城开了一家快递店，负责同城快送服务。小曲因为资金限制，雇佣了一批快递员，然后小曲发现资金不够了，只够买一辆车送快递。经营方式一客户每送来一份快递，小曲就让一个快递员盯着，然后快递员开车去送快递。慢慢的小曲就发现了这种经营方式存在下述问题

几十个快递员基本上时间都花在了抢车上了，大部分快递员都处在闲置状态，谁抢到了车，谁就能去送快递
随着快递的增多，快递员也越来越多，小曲发现快递店里越来越挤，没办法雇佣新的快递员了
快递员之间的协调很花时间

综合上述缺点，小曲痛定思痛，提出了下面的经营方式经营方式二小曲只雇佣一个快递员。然后呢，客户送来的快递，小曲按送达地点标注好，然后依次放在一个地方。最后，那个快递员依次的去取快递，一次拿一个，然后开着车去送快递，送好了就回来拿下一个快递。
对比上述两种经营方式对比，是不是明显觉得第二种，效率更高，更好呢。在上述比喻中:

每个快递员---------->每个线程
每个快递------------>每个socket(I/O流)
快递的送达地点------>socket的不同状态
客户送快递请求------>来自客户端的请求
小曲的经营方式------>服务端运行的代码
一辆车--------------->CPU的核数

于是我们有如下结论1、经营方式一就是传统的并发模型，每个I/O流(快递)都有一个新的线程(快递员)管理。 2、经营方式二就是I/O多路复用。只有单个线程(一个快递员) ，通过跟踪每个I/O流的状态(每个快递的送达地点) ，来管理多个I/O流。
下面类比到真实的redis线程模型，如图所示

文章插图