- 感知阶段
随着软件业的发展，互联网用户的日渐增多，并发这门艺术的兴起似乎是那么合情合理。每日PV十多亿的淘宝，处理并发的手段可谓是业界一流。用户访问淘宝首页的平均等待时间只有区区几秒，但是服务器所处理的流程十分复杂。首先负责首页的服务器就有好几千台，通过计算把与用户路由最近的服务器处理首页的返回。其次是网页上的资源，就JS和CSS文件就有上百个，还有图片资源等。它能在几秒内加载出来可见阿里几千名顶尖工程师的智慧是如何登峰造极。
而在大型电商网站中，他们的服务或者应用解耦之后，是通过消息队列在彼此间通信的。消息队列和应用之间的架构关系就是生产者消费者模型。
在介绍之前，先找找现实间的模型。笔者最近发觉，很多技术模型是和生活中的模型息息相关的。相信多数人都进过肯德基和麦当劳消费，笔者进店消费的时候发现他们的点单流程和并发模型十分接近。虽然每家店的流程有所差异，但是大概就只有两种模型。在肯德基里，你点单之后点单员会把所点的食物完成封装之后拿来你面前，然后让你结账，有时候有些耗时操作没完成就会留下一个餐台号稍后送来。而在麦当劳的点餐模型大致是，你点完快餐之后要求你立即付款，付完款之后下一位点餐，而取餐的是在旁边等待，另一个服务员专责负责配餐。
肯德基流程
麦当劳点餐图
在并发模型中，肯德基比较倾向于一个线程把所有的服务都做完，而麦当劳倾向于服务解耦，让他们更专注于自己的业务。而肯德基的模型与BIO服务器的模型设计类似，麦当劳的模型则与生产者消费者模型十分相似。
- 生产消费者模型
生产者消费者模型具体来讲，就是在一个系统中，存在生产者和消费者两种角色，他们通过内存缓冲区进行通信，生产者生产消费者需要的资料，消费者把资料做成产品。生产消费者模式如下图。
在日益发展的服务类型中，譬如注册用户这种服务，它可能解耦成好几种独立的服务（账号验证，邮箱验证码，手机短信码等）。它们作为消费者，等待用户输入数据，在前台数据提交之后会经过分解并发送到各个服务所在的url，分发的那个角色就相当于生产者。消费者在获取数据时候有可能一次不能处理完，那么它们各自有一个请求队列，那就是内存缓冲区了。做这项工作的框架叫做消息队列。
- 生产者消费者模型的实现
生产者是一堆线程，消费者是另一堆线程，内存缓冲区可以使用List数组队列，数据类型只需要定义一个简单的类就好。关键是如何处理多线程之间的协作。这其实也是多线程通信的一个范例。
在这个模型中，最关键就是内存缓冲区为空的时候消费者必须等待，而内存缓冲区满的时候，生产者必须等待。其他时候可以是个动态平衡。值得注意的是多线程对临界区资源的操作时候必须保证在读写中只能存在一个线程，所以需要设计锁的策略。
下面这个例子是书上介绍的，生产者负责生产一个数字并存入缓冲区，消费者从缓冲区中取出数据并且求出它的平方并输出。
因为BlockingQueue是一个阻塞队列，它的存取可以保证只有一个线程在进行，所以根据逻辑，生产者在内存满的时候进行等待，并且唤醒消费者队列，反过来消费者在饥饿状态下等待并唤醒生产者进行生产。
下面的两个版本是使用notify/wait()和await()/signal()方法进行设计的。在结构上是一致遵从模型图的。
await的版本我个人写出来之后感觉，每次控制台只输出了一句话，说明在同一时间内生产者或者消费者只有一个是激活的，而wait的版本，一次可能有多个生成者激活。我个人觉得wait的版本更接近我的构想。
- 生产消费者模型思维
下午翻书，偶然发现并行计算的流水线思维。并行计算的要点就是分治法思维，如果能证明分割的两部分在因果上没有关联，则可以进行并行计算。譬如书上的例子（A+B）*C，这个算式是不能使用并行计算分割的，因为它的结果是A+B之后的结果乘以C。但是并行流水线的思维是，我们可以请两个工人，每个工人负责一步的处理。
分解后的架构是：P1：D = A + B；P2：R = D*3；
在这两个线程处理中并不需要存在因果，所以他们可以并行计算了。
设计这个模式是基于生产消费者模型的，流水线需要使用流水线传递半成品，流水线就是内存缓冲区，对于P2来说，P1就是生产者，而对于系统需要的结果来说，P2就是生产者。
- 后记
偶然读到一本书，上面提到的建立高速公路的学习方法是十分高效的学习方法，在学习新的技术的时候它们或多或少都会在现实中有所映射，所以读万卷书行万里路，经历和学术需要并行增长。技术模型不仅应用在技术领域，管理领域也可以参照思考，learn more，study less。
扫一扫
867
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
