3.5Redis的性能问题

1）Redis为单线程，但是为什么性能会很高呢？
2）既然是单线程那么它能不能保证线程安全和原子性问题呢？
下面看解答：
1）Redis单线程模式不代表所有的客户端请求都会去排队它内部采用的是多路复机制
首先我们来了解一下多线程。
多线程的好处是可以充分的利用CPU资源，尤其对于多核。
但是Redis的性能瓶颈并不是在资源利用方面，那么他的性能瓶颈在什么地方呢？
我来告诉你！！！
Redis的性能瓶颈出现在内存和网络带宽这两个方面。
那么针对这两个方面Redis做了哪些努力呢？
客户在使用Redis的时候，不建议使用较长的key，以减少网络开销。

---

在讲多路复用之前我想先来一个开胃小菜：
同步、异步：用户线程和内核的一个交互方式
阻塞、非阻塞：线程调用内核资源操作IO的时候，操作方式是阻塞还是非阻塞

多路复用机制
Redis提高性能的机制是并不会让客户端的请求进行排队，线性执行客户端的请求。
先说同步阻塞 即 BIO
我们来假设一个场景：
在医院取药这个场景吧我觉得这个最合适！！
小明病已经看完了现在去取药；拿着医生给他的鬼画符一样的药单，到窗口交给里面的小护士。护士说啦：我要去库房给你准备药边上等着去！然后小明就找了一个板凳，臆想着什么时候可以约小护士；这时候小刚来了也要取药，发现小护士不在那么小刚只能等着。等到小护士把小明的要拿出来交给他以后，再处理小刚的请求；
这就是一个BIO过程，这里存在两个等待。对于客户进程/线程-- 小明和小刚两个人来讲，他俩需要等小护士。对于内核空间–小护士来讲他需要等到把上一个人多客户的请求处理结束以后才能处理下一个请求
上图：

同步非阻塞 NIO
还是上面那个场景，小护士接受了小明的请求以后又接受了小刚，小李，小张…总之很多人的请求之后小护士也会接受后面来的客户请求。由于人数太多小护士忙不过来了就告诉已经交了药单的客户需要自己来窗口认领—就是说客户有一个轮训的过程。只是这个轮训过程会浪费很多CPU资源，因为对于很多人来讲，这是一个无效的循环。
上图：

异步阻塞IO 也叫（IO多路复用）
经过BIO的效率低下，NIO的资源浪费以后呢医院领导痛定思痛，决定给取药窗口增加一个小护士，此时有两个护士了 ，一个是御姐，一个是女神。
小明提交药单 女神接待了他，御姐去帮他准备药。 并告诉他可以去吃饭或做点别的事情，总之不用等在这里了，小刚也来了，女神也接受了他的请求并告诉可以做点别的事情。当药准备好了以后呢。女神喊他：小明先森，您的药准备好了，然后接收小刚的请求。如此周而复始。
这时，女神充当了一个监视的功能。实际上这是一个事件的操作。
那么多路复用的优势就是 客户端不用在等待数据这个环节上浪费时间，客户端可以先去处理别的事情。
上图：

这里讲的就是Redis的多路复用

---

2）虽然是单线程依然会存在线程安全问题，原子性问题是会存在的
所谓原子性问题：
我不想用银行存钱的场景那就用计工分的场景吧。
说杨白劳在黄世仁的钻石矿里挖钻石 边上有两个看场子的就叫水杯和罐子吧，后面有一个计工分的人叫黑板。
杨白劳挖到一颗钻石记一个工分。水杯和罐子吆喝黑板给杨白劳加一分。
这一天，杨白劳挖到一颗钻石，水杯和罐子同时吆喝后面的黑板“板个给杨白劳加一分”，由于接到两个通知，在黑板上杨白劳是挖到两个钻石的。 这就是一个数据原子性问题–即不安全。
那么单线程里还有一个效率问题：
还是杨白劳的场景：
这一天水杯请假了，只剩下罐子。昨天被黄世仁打了一顿的罐子，长记性了。今天他要先问杨白劳有几分，在已有的数据基础上加一分，这样就不会出错了。这里有两个动作就是要先吆喝一下黑板问杨白劳有几分，得到答复以后把杨白劳应的分数告诉黑板。
这样两个命令之间是存在一个依赖的。
那么由于需要千里传音最后罐子和黑板练就了一身的狮吼功—由此可以看出网络开销很大；每一次都需要吼。

由以上我们得出两个问题
a)减少网络开销去执行多个指令
b)满足原子性问题
c)复用性

万能的程序员提供了完美解决上述问题的方案------Lua闪亮登场

请看Lua文章 这个文章不是我原创的，是为了赶进度，暂时引用一下。后续我会在整理以后，把自己原创lua脚本学习的文章贴出来