mysql 单进程多线程_谈单进程(单线程)与单进程(多线程)程序设计

http://blog.csdn.net/pecywang/article/details/8682431

本文单进程指单进程(单线程)模式;单线程也指单进程单线程;多线程指单进程(多线程模式),下同。

最近在B部门做项目,用到的平台框架都是基于单进程模式的,在以前的A部门做过的项目都是多线程模式的,在使用的过程中,也思考了一些问题,引发了对这两种类型的线程的对比和自己的一些看法(仅是个人观点)。

先讲下单进程模式和多线程模式的优劣:

1.单进程开发简单;多线程开发复杂

2.单进程在处理高并发时一般采用多启动进程的方式;多线程仅需启动多个线程。进程的切换开销比线程大

3.多进程之间如果有信息通信则相对多线程效率较低,因为多线程属于同一地址空间的访问,效率相对较高(暂不涉及锁等一致性策略的影响)

4.多进程稳定好,一个进程死了不影响其他进程;多线程中,任意一个出现问题,将影响到所有。

5。。。

最近的项目中使用框架app platform(后面简称AP框架),了解到它的实现是单进程模拟用户空间多线程的方式,这个手法在学习计算机OS的时候都有接触过,就是CPU时间分片,模拟用户多任务并发。该框架也是使用了这种,它的级别不是进程间,而是进程内模拟。

研究了下,模型简单化:请求-> 接收-> 处理 ->发送  大体框架流程如下:

1363487424_1328.jpg

AP框架原来的设计是完整的接收到数据包,然后调用用户的处理代码,最后再将数据包提交到发送队列。这样的话,因为是单线程,所以在处理一个远程调用时(用户接口),需要等待接收完整的数据,无法从用户接口直接退出切换到主线程,那么对其他有事件到来的请求将被阻塞,不能很快的被处理,吞吐量必然会很低。对于大多数业务部门的代码逻辑,任务都是轻量级的,最主要的瓶颈在IO上。原来的架构在IO上不能够及时处理,导致阻塞,有了保存请求上下文(参见libpth)的方法之后,当前的请求在收发数据包未完成且需要等待时,主动调用schedule方法,保存现场,出让cpu。对每个请求而言,它看到的是自己一直在运行,而对系统而言,挂起需等待的请求,处理另外一个数据已经到来的请求,肯定效率会更高一些,并发度也会提高很多。

实际上对于IO的设计一直是高吞吐网络应用程序设计的关键,一般是采用Reactor模式,在Linux中大部分使用select或epoll,并将IO单独交由一个或多个线程来处理,把IO和用户逻辑分开,使得他们能高效执行。

AP框架正是有效的利用了网络收发这段等待时间来处理其他任务,进一步提高了效率和并发度,实现上和CPU出让时间片的方法是类似的,单线程模拟用户多任务。

但单线程还是单线程,即使提高了IO的收发效率,用户的逻辑比较轻,也是存在一定问题的。AP框架作者把这个实现在单进程里面,且用户的请求切换都是在用户态进行的,开销很小。作者当时也考虑过多线程的实现方法,但担心多线程的内核态切换开销过大,影响性能,所以没有采用。据说也做了实验,性能很差,所以就否定了。不过我注意到作者当时在测试时采用的模型是2个线程分别管理收发,队列里有多少个请求就开启多少个线程,请求和线程是1:1的,这样当请求过多时就会导致进程内线程非常多,线程切换的开销也会随之变得很大。这在谁看来都是不太能够接受的方案。

作者这里的线程1:1方案本身设计上就有问题,业务逻辑很轻,为什么把使用一个线程池(线程池线程几个应该就可以,无需1:1)呢,当接收数据线程R,每收到部分数据时就将数据包投递到线程池线程的队列中,并从epoll中删除,由线程池线程来判断数据包是否结束(数据包完整由用户来判断,框架本身无法知道),如果数据包不完整,继续投递到R线程的epoll接收队列。完整的数据包由线程池线程处理后直接投递到发送线程S,这样各司其责,收发线程只处理和IO有关的,线程池线程处理用户逻辑。想必性能不会差到哪里去。

以上所讲的内容都是在当前的多核server下的,服务器都是8核,16核甚至更多,将上面的线程分别绑定到不同的CPU上,线程间仅需较小粒度的锁即可保证数据一致性,整体性能应该会有不错的表现。AP框架的模式可以解决大部分问题,性能应该还是可以继续提高。

(我没有做测试实验,仅是个人的理论分析,欢迎批评指正)

参与评论 您还未登录,请先 登录 后发表或查看评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:1024 设计师:我叫白小胖 返回首页

打赏作者

大奥子

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值