登录
首页 >  Golang >  Go问答

单线程多路复用和多线程加锁的区别

来源:SegmentFault

时间:2023-01-18 21:51:02 341浏览 收藏

怎么入门Golang编程?需要学习哪些知识点?这是新手们刚接触编程时常见的问题;下面golang学习网就来给大家整理分享一些知识点,希望能够给初学者一些帮助。本篇文章就来介绍《单线程多路复用和多线程加锁的区别》,涉及到go、C、Linux、unix,有需要的可以收藏一下

问题内容

看介绍说

redis
是单线程的,通过
epool
实现多路复用。由于是单线程所以对资源的访问是串行的,不会产生资源竞争。然后突然有个疑惑,既然对资源的访问是串行的,也就是说如果我某个请求要set,而前面排着K个同样要set的操作,我还是得等它们set完成我再能set。然后有几点疑问,希望大牛不吝赐教:
  • 通过多路复用单线程串行地访问资源和多线程并发访问然后给资源加互斥锁有什么区别呢?

  • 抛开线程创建的开销,两者的性能如何呢

  • golang
    goroutine
    一定程度上减轻了线程创建的开销,高并发场景下多个
    goroutine
    访问资源时加互斥锁,和redis的单线程访问资源性能差异大吗
  • golang
    没有
    epool
    的库,或者说有个
    goroutine+channel
    还需要
    epool

正确答案

来回答前同事的一部分问题

首先你要知道redis除了持久化,几乎所有操作都是在操作内存,比如像简单的set get操作都非常快,具体多快我觉得你可以自己来做一个benchmark,并不难
如果你关注新闻的话可以知道双11阿里的交易巅峰值是14w笔/s
这基本已经是国内it界最高的并发了(那种几亿同时在线的不算),你再去想想操作内存的时间,不考虑事务,我只把14w条数据记下来看起来并不是什么难事对不对

一台写不过来我十台总行了吧,所以除非你的set的value本身特别大,不用担心在操作时的等待时间,就算有1w个请求过来,你还是在操作内存,严格意义上说,redis本身应对的业务场景并不是一个高并发的场景,你看一下redis本身默认的连接数设置应该也就懂了

应对这种场景,你用多线程+锁也没有什么问题(当然性能可能会差一点点),之前tim大神做过一个memcached和redis的性能对比,虽然年代久远,不过也可以说明一些问题,要知道memcached就是多线程+锁的模型,两者看起来差别也没有太过夸张。虽然结果是redis好一些。

看到这里你是不是觉得单线程+io复用赢了?这可真不一定。。只是在这种场景下赢了而已,本身单线程io复用和多线程+锁其实只是两种编程模型,两种模型也都是为了解决问题,哪种优要看具体的业务场景,这里还是要说了,不服跑分啊

go的goroutine本质是green threads,runtime来调度的用户态线程,其实这种概念在其他语言里也有,只是其他语言都是以第三方库来做这件事情,go把它集成在了语言内,并且不用你自己去管理调度的事情,go语言里的实现只是让你可以更方便地写而已,所以这东西并不是银弹,不用太过迷信,go所带来的更重要的是开发效率的提升,并没有解决什么具体的问题。

关于epoll,go语言的net库底层也是用epoll来做io复用的(仅指linux平台),epoll这个东西只是linux下的一种io复用的实现,在其他的发行版里还有其他变种,而程序员们其实不太想关心你这些事情,他们希望在linux下写的程序去freebsd还能跑,所以libevent棒棒哒,当然你写go的话,这些事情不用操心。

到这里,我们也就讲完了《单线程多路复用和多线程加锁的区别》的内容了。个人认为,基础知识的学习和巩固,是为了更好的将其运用到项目中,欢迎关注golang学习网公众号,带你了解更多关于golang的知识点!

声明:本文转载于:SegmentFault 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>
评论列表