Redis快速度特性及为什么支持多线程及应用场景
转载请注明出处：
目录
1.Redis 访问速度快特性
正常情况下，Redis执行命令的速度非常快，官方给出的数字是读写性能可以达到10万/秒，当然这也取决于机器的性能；Redis使用了单线程架构和I/O多路复用模型来实现高性能的内存数据库服务；为什么Redis使用单线程模型会达到每秒万级别的处理能力呢？可以将其归结为四点：
第一，纯内存访问，Redis将所有数据放在内存中，内存的响应时长大约为100纳秒，这是Redis达到每秒万级别访问的重要基础。
第二，非阻塞I/O，Redis使用epoll作为I/O多路复用技术的实现，再加上Redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件，不在网络I/O上浪费过多的时间
第三，单线程避免了线程切换和竞态产生的消耗。
第四，用C语言实现的，一般来说C语言实现的程序“距离”操作系统更近，执行速度相对会更快。且Redis源代码可以说是精打细磨，曾经有人评价Redis是少有的集性能和优雅于一身的开源代码。
2.Redis 6.0 为什么支持多线程？
Redis处理一个请求的过程：
-
建立连接
-
读取请求
-
解析请求
-
处理请求
-
返回响应
那么这个流程中，性能的瓶颈主要在哪呢？
1）建立连接：这个操作是无法避免的，不予考虑（可以通过长连接来解决）。
2）读取请求：因为多路I/O复用机制（以epoll为例），可将 I/O 事件注册到epoll instance上，当我们通过epoll_wait获取到该可读I/O事件时，请求数据已经存在于Linux Kernel，开销不大。
3）解析请求：因为Redis的命令相对来说比较简单，解析起来并不是CPU密集型，所以也并不是瓶颈。
4）处理请求：同建立连接，这个操作是无法避免的，不予考虑。
5）返回响应：在上述操作执行完毕后，Redis接下来会返回响应至客户端，底层是通过调用write来实现的，它是一个阻塞操作。以客户端与Redis建立的是TCP连接为例，TCP协议是一个可靠的协议，也就是说数据发送方要确保数据接收方获取到的数据是正确的，因此在这段期间内，write调用并不会返回，而网络传输速度显然是慢于内存的读写速度的，确实相对来说比较耗时。
这里除了建立连接之外，其它的操作都是不间断顺序执行的，由于Redis的单线程机制导致在此期间无法处理其它的请求。如果要在此基础上提高性能，本质上来说就是要能够在单位时间内处理更多的请求。
Redis 6.0中的多线程，也只是针对处理网络请求过程采用了多线程，而数据的读写命令，仍然是单线程处理的。
Redis 6.x引入了I/O线程，以并发的方式（主线程+I/O线程）同时读取和解析多个请求，串行的方式（主线程）处理多个请求（减少并发带来的复杂度），最后是以并发的方式（主线程+I/O线程）同时返回多个响应，达到了单位时间内处理更多请求的目的，提高了吞吐量。
那么为什么Redis要引入多线程？因为Redis想在原来的基础上进一步提高单位时间内处理的请求个数，以提高吞吐量。
3.Redis可以做什么
3.1.缓存
缓存机制几乎在所有的大型网站都有使用，合理地使用缓存不仅可以加快数据的访问速度，而且能够有效地降低后端数据源的压力。Redis提供了键值过期时间设置，并且也提供了灵活控制最大内存和内存溢出后的淘汰策略。可以这么说，一个合理的缓存设计能够为一个网站的稳定保驾护航。
3.2.排行榜系统
排行榜系统几乎存在于所有的网站，例如按照热度排名的排行榜，按照发布时间的排行榜，按照各种复杂维度计算出的排行榜，Redis提供了列表和有序集合数据结构，合理地使用这些数据结构可以很方便地构建各种排行榜系统。
3.3.计数器应用
计数器在网站中的作用至关重要，例如视频网站有播放数、电商网站有浏览数，为了保证数据的实时性，每一次播放和浏览都要做加1的操作，如果并发量很大对于传统关系型数据的性能是一种挑战。Redis天然支持计数功能而且计数的性能也非常好，可以说是计数器系统的重要选择。
3.4.社交网络
赞/踩、粉丝、共同好友/喜好、推送、下拉刷新等是社交网站的必备功能，由于社交网站访问量通常比较大，而且传统的关系型数据不太适合保存这种类型的数据，Redis提供的数据结构可以相对比较容易地实现这些功能。
3.5.消息队列系统
消息队列系统可以说是一个大型网站的必备基础组件，因为其具有业务解耦、非实时业务削峰等特性。Redis提供了发布订阅功能和阻塞队列的功能，虽然和专业的消息队列比还不够足够强大，但是对于一般的消息队列功能基本可以满足。
