redis的线程模型
来源：12-6 场景思考100W并发——epoll，select和poll
sadcloud
2020-08-01
老师我有三个小问题想请教，在网上看了一些答案也没底，故来请教，希望听下老师的理解
- redis的单线程只是算负责监听socket io吗，那后面真正处理任务的线程又什么呢
- 怎么理解 redis瓶颈在io而非cpu（我看很多地方都这么说 但还是不太理解）
- redis线程模型 从单线程到redis6.0多线程 怎么看这个现象呢
十分感谢！！！
2回答
-
socket是个编程模型，客户端和服务器之间产生一个的TCP/IP连接， 就会产生一个socket。
socket是一个对象（内存中的数据），因此很多用户连接一个服务器的时候，服务器内部会产生很多个socket对象。
另外，每个socket，linux会对应一个文件。网络请求到linux，然后linux将数据写入对应的socket文件，然后socket对象感知到文件的变化，于是执行程序。
线程是对CPU计算资源的抽象，可以一个线程计算一个socket，也可以一个线程计算很多个socket（线程提供计算资源）。如果一个线程要处理多个socket，那么可以用队列根据socket接收信息的顺序进行处理，也可以打一个时间窗口，每次凑够100个socket的变换再一起处理。
redis单线程的弊端在于利用cpu核心不方便，所以早期的redis版本需要启动多个实例（进程），这样从进程的维度去复用多个CPU核心。
、
redis的瓶颈当然是在IO，因为redis本身不对数据进行计算，用户将数据存进去什么样子，取出来什么样子。redis的挑战在于怎么应对大量用户同时读写，怎么应对并发环境的数据一致性。大部分时间redis都在响应请求，然后返回数据。而这些操作，都是IO。
012020-08-10 -
慕圣9470074
2020-08-02
个人理解：1.redis单线程和多线程是适配不同的应用场景，比如redis的gc机制，在不影响程序的其他线程下可以fork线程去执行。
2.不单单是redis的瓶颈在io，其他的BS或者CS架构的服务或者应用程序瓶颈也是在IO。目前的CPU性能是过剩的（比如计算能力），相应的硬件以及适配的软件技术更新迭代也要跟的上。CPU处理的任务类型大致有cpu密集型以及io密集型，IO除了CPU的运算有临界值会进行切换还有读写等IO操作都会切换，以哪种方式去运行程序或者执行任务，带来的开销小也包括的公司的运营以及维护成本，这就是现在要考虑的问题。除了进程和线程还有协程（即微线程）,当前golang语言比较火也是因为golang语言的协程能给公司解决处理高并发性能以及公司维护成本的两大痛点。
3.抛开redis来讲，其他的cs架构的程序也是在适配多线程高并发的时代，这个也是未来的趋势。
有个问题想问下老师：IO模型中的select/poll被称之为异步非阻塞，这个说法是否存在歧义？个人的理解是，内核空间准备好了数据，发送消息通知用户空间的程序去读取，这个中间的缓存区IO等操作数据流转应该是阻塞状态，包括epoll也是如此，调度者管理fd的方式也是通过event来处理，而fd的存储结构也由有序性数据结构升级成了红黑树。还是准确的说aio,才是真正异步非阻塞模型，也是未来的趋势？
00
相似问题