线程性能到达瓶颈，并发还是并行？
获奖详情：http://bbs.chinaunix.net/thread-4241378-1-1.html首先，跟大家分享个陈年趣事:
几年前，我去某软公司应聘，电话面试中与面试官有如下一番对话。 面试官：你了解多线程并发吗？
我：不了解，我之前做业务系统，多线程很大程度上都是委托给容器的……
面试官：我理解了。你不太熟悉并发是吗？
我：是的。
面试官：那我们还是来聊一聊并发吧。
祝大家线程安全。
案列介绍：
最初是一个单线程程序性能到达瓶颈后，通过将整个作业切成一个个小任务，每一个任务执行一个线程，运行结果发现居然和之前差不多，通过调试发现其中一个任务执行时间过长，再动态调节该任务的线程数，当发现队列过多时启动新线程来同时进行，结果性能上升不大，再定位发现多个线程竞争需要同步访问同一个资源，修改为静态线程池，再由上游哈希将数据放置不同的线程队列中。
进一步的性能提升发现怎么增大线程数性能都是这样了，再检查发现之前下游任务需要等待上游线程全部完成才能进一步操作，通过查阅资料找到一个算法只要上游有数据就可以开始进行计算，这样到上游全部陆续完成时该步骤也只需要计算少量的数据就可以了。针对此问题您有什么更好的解决方法？
讨论话题：（可任选一个或几个）
1. 阐述一下你设计过的最满意的并发/并行软件架构。
2. 详细描述一下在多线程/进程/协程方式下遇到过的最难解决的问题以及如何解决的
3. 详细讲述一下曾经使用过的最好的并发/并行组件
4. 对并行/并发的某一个理论进行详细的说明
讨论时间：2015年12月15日—2016年1月15日
奖励设置：
活动结束后，我们将选取5位讨论精彩的同学，各送技术图书《七周七并发模型》一本。
http://images.china-pub.com/ebook3770001-3775000/3771014/zcover.jpg
作者： (美)Paul Butcher
译者： 黄炎
丛书名： 图灵程序设计丛书
出版社：人民邮电出版社
ISBN：9787115386069
上架时间：2015-3-13
出版日期：2015 年4月
开本：16开
页码：234
版次：1-1
内容简介：并发编程近年逐渐热起来，Go等并发语言也对并发编程提供了良好的支持，使得并发这个话题受到越来越多人的关注。本书延续了《七周七语言》的写作风格，通过以下七个精选的模型帮助读者了解并发领域的轮廓：线程与锁，函数式编程，Clojure，actor，通信顺序进程，数据级并行，Lambda架构。书中每一章都设计成三天的阅读量。每天阅读结束都会有相关练习，巩固并扩展当天的知识。每一章均有复习，用于概括本章模型的优点和缺陷。
样章试读：
---------------------------------------------------------分割线---------------------------------------------------------------------
其实案例我想描述的更清楚一些，因为当时没有时间，现在补充如下：
软件功能描述，通过libpcap抓取Mysql的包，并按照Mysql协议分解后将数据发送到Kafka供后续的分析实现，软件架构如下：
pcapThread---->TcpProcThread----->MysqlProcThread----->KafkaSendThread
各线程作用比较清晰，pcap线程调用libpcap的接口获取抓包，并根据配置排除掉不属于本机或黑名单中的抓包，并将TCP/IP头域将解开有用的放到一个数据结构中
TcpProc线程负责TCP的排序，包括乱序重传等处理，将有效的消息发送到Mysql线程处理，MySQL线程根据MySQL协议提取SQL语句和结果元数据信息组成json格式并调用rdkafka库发送
之前开发为简便实现，各线程之间通信采用出入队列方式，同步采用互斥锁，在QPS比较小的机器上测试正常，但上线到QPS比较大机器上，pcapThread出现丢包且比较严重
同时CPU飚的很高，直接占据单个核的100%，当前通过一些手段，如锁改为条件变量、使用无锁队列等，CPU下降到30%，丢包从30%以上下降到10%以下，但优化还未完成，如果大家有兴趣也可以直接根据这个现实的案例来思考发散。
这个好像很难，没人回了...... 才看到，居然没有人回答 ... 支持一下，期待大牛回答
主要是没用到过 其实案例我想描述的更清楚一些，因为当时没有时间，现在补充如下：
软件功能描述，通过libpcap抓取Mysql的包，并按照Mysql协议分解后将数据发送到Kafka供后续的分析实现，软件架构如下：
pcapThread---->TcpProcThread----->MysqlProcThread----->KafkaSendThread
各线程作用比较清晰，pcap线程调用libpcap的接口获取抓包，并根据配置排除掉不属于本机或黑名单中的抓包，并将TCP/IP头域将解开有用的放到一个数据结构中
TcpProc线程负责TCP的排序，包括乱序重传等处理，将有效的消息发送到Mysql线程处理，MySQL线程根据MySQL协议提取SQL语句和结果元数据信息组成json格式并调用rdkafka库发送
之前开发为简便实现，各线程之间通信采用出入队列方式，同步采用互斥锁，在QPS比较小的机器上测试正常，但上线到QPS比较大机器上，pcapThread出现丢包且比较严重
同时CPU飚的很高，直接占据单个核的100%，当前通过一些手段，如锁改为条件变量、使用无锁队列等，CPU下降到30%，丢包从30%以上下降到10%以下，但优化还未完成
后续做完后有时间总结一下发到这里更合适一些{:qq26:} 大牛在下面回复了，可以给大家普及写各位不懂的领域，希望大家能得到更多回复 4# sjf0115
回复 6# 王楠w_n
恩就是希望在这个平台学到自己感兴趣的知识 本帖最后由 laputa73 于 2015-12-17 21:08 编辑
一直觉得线程狠复杂，性能也狠差。
基于线程模型的java服务器，跑到500并发已经狠了不起了。
基于事件的就可以轻松上万并发。但是回调写起来让头大。
最早接触协程是通过erlang.这个对后续的影响很大。
但是erlang的学习门槛确实比较高。
后来又陆续看了lua的协程和perl的coro,python的stackless和gevent.
感觉协程确实是个好东西，高大上，但是组件级别的支持还是比较别扭。
golang一出，语言级支持协程并发，而且还同时支持多核并行。
没有什么可犹豫的，直接拥抱go吧。
java的同学，估计转scala比较容易。 回复 5# heguangwu
看描述，pcapThread用来抓包，然后还处理。当QPS高的时候，处理慢了，丢包正常。
建议 抓包和处理数据分开。
pcapThread抓包后，直接发到kafka，然后多个消费者取包，然后处理，再继续后面的处理，根据量还可增加消费者
如：
宝突然增加的时候，kafka也可以积压存储，保证丢包率比较低
pcapThread(抓包)--> kafka --> 增加一个程序（根据配置排除掉不属于本机或黑名单中的抓包，并将TCP/IP头域将解开有用的放到一个数据结构中） --> kafka --> TcpProcThread --> kafka -->MysqlProcThread -->KafkaSendThread
pcapThread并没有做业务处理，只是做了一些及其简单的过滤，如去掉了长度为0的包，这个不是丢包的原因，因为哪怕我直接将数据放入下一个线程的队列同样会丢包
回复 9# chenxing2