1 生产者消费者模型应用场景及优势？
什么是生产者消费者模型
在 工作中，大家可能会碰到这样一种情况：某个模块负责产生数据，这些数据由另一个模块来负责处理（此处的模块是广义的，可以是类、函数、线程、进程等）。产 生数据的模块，就形象地称为生产者；而处理数据的模块，就称为消费者。在生产者与消费者之间在加个缓冲区，我们形象的称之为仓库，生产者负责往仓库了进商 品，而消费者负责从仓库里拿商品，这就构成了生产者消费者模型。结构图如下：
生产者消费者模型的优点：
a、解耦
假设生产者和消费者分别是两个类。如果让生产者直接调用消费者的某个方法，那么生产者对于消费者就会产生依赖（也就是耦合）。将来如果消费者的代码发生变化， 可能会影响到生产者。而如果两者都依赖于某个缓冲区，两者之间不直接依赖，耦合也就相应降低了。
举个例子，我们去邮局投递信件，如果不使用邮筒（也就是缓冲区），你必须得把信直接交给邮递员。有同学会说，直接给邮递员不是挺简单的嘛？其实不简单，你必须 得认识谁是邮递员，才能把信给他（光凭身上穿的制服，万一有人假冒，就惨了）。这就产生和你和邮递员之间的依赖（相当于生产者和消费者的强耦合）。万一哪天邮递员换人了，你还要重新认识一下（相当于消费者变化导致修改生产者代码）。而邮筒相对来说比较固定，你依赖它的成本就比较低（相当于和缓冲区之间的弱耦合）。
b、支持并发
由于生产者与消费者是两个独立的并发体，他们之间是用缓冲区作为桥梁连接，生产者只需要往缓冲区里丢数据，就可以继续生产下一个数据，而消费者只需要从缓冲区了拿数据即可，这样就不会因为彼此的处理速度而发生阻塞。
接上面的例子，如果我们不使用邮筒，我们就得在邮局等邮递员，直到他回来，我们把信件交给他，这期间我们啥事儿都不能干（也就是生产者阻塞），或者邮递员得挨家挨户问，谁要寄信（相当于消费者轮询）。
c、支持忙闲不均
缓冲区还有另一个好处。如果制造数据的速度时快时慢，缓冲区的好处就体现出来了。当数据制造快的时候，消费者来不及处理，未处理的数据可以暂时存在缓冲区中。 等生产者的制造速度慢下来，消费者再慢慢处理掉。
为了充分复用，我们再拿寄信的例子来说事。假设邮递员一次只能带走1000封信。万一某次碰上情人节（也可能是圣诞节）送贺卡，需要寄出去的信超过1000封，这时 候邮筒这个缓冲区就派上用场了。邮递员把来不及带走的信暂存在邮筒中，等下次过来 时再拿走。
Python示例：
利用队列实现简单的生产者消费者模型，生产者产生时间放入队列，消费者取出时间打印
class Consumer(threading.Thread):
def __init__(self, queue):
threading.Thread.__init__(self)
self._queue = queue
def run(self):
while True:
msg = self._queue.get()
if isinstance(msg, str) and msg == 'quit':
break
print "I'm a thread, and I received %s!!" % msg
print 'Bye byes!'
def producer():
queue = Queue.Queue()
worker = Consumer(queue)
worker.start() # 开启消费者线程
start_time = time.time()
while time.time() - start_time < 5:
queue.put('something at %s' % time.time())
time.sleep(1)
queue.put('quit')
worker.join()
if __name__ == '__main__':
producer()使用多线程，在做爬虫的时候，生产者用着产生url链接，消费者用于获取url数据，在队列的帮助下可以使用多线程加快爬虫速度。
import time
import threading
import Queue
import urllib2
class Consumer(threading.Thread):
def __init__(self, queue):
threading.Thread.__init__(self)
self._queue = queue
def run(self):
while True:
content = self._queue.get()
print content
if isinstance(content, str) and content == 'quit':
break
response = urllib2.urlopen(content)
print 'Bye byes!'
def Producer():
urls = [
'http://211.103.242.133:8080/Disease/Details.aspx?id=2258',
'http://211.103.242.133:8080/Disease/Details.aspx?id=2258',
'http://211.103.242.133:8080/Disease/Details.aspx?id=2258',
'http://211.103.242.133:8080/Disease/Details.aspx?id=2258'
]
queue = Queue.Queue()
worker_threads = build_worker_pool(queue, 4)
start_time = time.time()
for url in urls:
queue.put(url)
for worker in worker_threads:
queue.put('quit')
for worker in worker_threads:
worker.join()
print 'Done! Time taken: {}'.format(time.time() - start_time)
def build_worker_pool(queue, size):
workers = []
for _ in range(size):
worker = Consumer(queue)
worker.start()
workers.append(worker)
return workers
if __name__ == '__main__':
Producer()2 什么是cdn？
CDN的全称是Content Delivery Network,即内容分发网络
这个问题的解答，需要分五步。
第一步，HTML的文件引用：
HTML的文件头（也有文件中，文件尾）那边常有其他文件引用，比如CSS以及JS的引用。
就以bootstrap常用的引用来举个栗子
你常见的引用可能会是这样的：
<head>
<title>Mushroom</title>
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no" charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge,Chrome=1" />
<meta http-equiv="X-UA-Compatible" content="IE=9" />
<!-- 引入 Bootstrap -->
<link href="/css/bootstrap.min.css" rel="stylesheet">
<!-- jQuery (Bootstrap 的 JavaScript 插件需要引入 jQuery) -->
<script src="/js/jquery.min.js"></script>
<!-- 包括所有已编译的插件 -->
<script src="/js/bootstrap.min.js"></script>
</head>这之中，<script src="/js/bootstrap.min.js"></script> 这段就是外部脚本文件的一个链接，当前的这种链接是相对URL，指向站点内的文件，即你本项目里对应路径下面放置的文件。可以在 HTML <script> 标签的 src 属性 查看这个标签的具体属性。
属性值
值 描述
URL 外部脚本的 URL。可能的值有：
•绝对 URL - 指向其他站点（比如 src="www.example.com/example.js"）
•相对 URL - 指向站点内的文件（比如 src="/scripts/example.js"）
通过查看可以得知，URL的引用有两种方式，绝对和相对，绝对的方式就是直接引用其他站点的js地址，比如我把上方的引用改为
<script src="http://apps.bdimg.com/libs/bootstrap/3.3.0/js/bootstrap.min.js"></script>这样即是引用其他站点的js。
CSS文件的引用与此类似：HTML <link> 标签的 href 属性
图片以及其他文件的引用也类似，不赘述。
第二步，系统的资源引用
在一个网站项目中，页面里经常会有许多js以及css的引用，接触过开发项目的一般都会了解，大部分界面里的脚本引用并不是像第一步里的那么精简，如果是直接引用项目内文件的话，他们可能是这样的：
<SCRIPT src="/iforums/templates/default/js/common.js" type=text/javascript></SCRIPT>
<SCRIPT src="/iforums/templates/default/js/ajax.js" type=text/javascript></SCRIPT>
<SCRIPT type=text/javascript src="/iforums/ueditor/third-party/jquery-1.10.2.min.js"></SCRIPT>
<SCRIPT type=text/javascript src="/iforums/ueditor/ueditor.config.js"></SCRIPT>
<SCRIPT type=text/javascript src="/iforums/ueditor/ueditor.parse.js"></SCRIPT>
<SCRIPT type=text/javascript src="/iforums/ueditor/ueditor.all.js"></SCRIPT>可能甚至引用的更多，这样将资源文件与业务代码一锅炖的方式适用于小型的，应用服务器压力并不是太大的系统（并发、带宽、存储空间、资源等等）。这种方式的优点是开发省力，发布省力，对服务器要求小，省钱，没有具体公网接入需求。许多小型，内部使用型的网站系统往往采取这种形式放置资源文件。
第三步，系统访问量变高了，速度变慢了怎么办
怎么办？优化系统部署呗。
怎么优化？优化方式有很多，读写分离，负载均衡，这方面的东西可以讲上三天三夜。具体到本问题的范畴内，那就是资源服务器与应用服务器的分离。粗暴的理解方式就是，就是应用安在应用服务器（一台或者是集群），资源部署在资源服务器（单台或者是集群），这时候，js以及css的引用就需要更改为绝对URL，指向对应的资源服务器。
比如知乎的引用：
<link rel="apple-touch-icon-precomposed" href="http://static.zhihu.com/static/img/ios/zhihu(57px).png" />
<link rel="apple-touch-icon-precomposed" href="http://static.zhihu.com/static/img/ios/zhihu(72px).png" sizes="72x72" />
<link rel="apple-touch-icon-precomposed" href="http://static.zhihu.com/static/img/ios/zhihu(76px).png" sizes="76x76" />
<link rel="apple-touch-icon-precomposed" href="http://static.zhihu.com/static/img/ios/zhihu(114px).png" sizes="114x114" />
<link rel="apple-touch-icon-precomposed" href="http://static.zhihu.com/static/img/ios/zhihu(120px).png" sizes="120x120" />
<link rel="apple-touch-icon-precomposed" href="http://static.zhihu.com/static/img/ios/zhihu(152px).png" sizes="152x152" />
<script src="http://static.zhihu.com/static/revved/js/-/vendor.min.5a2082ff.js"></script>
<script src="http://static.zhihu.com/static/revved/js/-/closure/app_core.fb4023ac.js"></script>
<script src="http://static.zhihu.com/static/revved/js/-/closure/sign.e0ca7b10.js"></script>
<script src="http://static.zhihu.com/static/revved/js/-/closure/app.9eaaec15.js"></script>
<script src="http://static.zhihu.com/static/revved/js/-/closure/rich_text_editor.3a07c473.js"></script>有兴趣的话，你可以打开这个链接看看是什么页面：http://static.zhihu.com/
也可以打开这个看看：http://static.zhihu.com/static
第四步，网络方面的优化
网站的访问速度，只基于一点，那就是页面包含的内容传输到用户电脑的速度，服务器搭的再好再完美，如果用户到服务器的链路之间有一段比较缓慢的话，整体速度也会被拉的十分差劲。
想象一下，你给公司做了个运行于公司内网的网站，一切运行良好，分布式部署也已搭建完毕，一切都很完美。
后来，你公司运营良好，开了一个十分遥远的分公司（不要问为什么遥远，再问自绝经脉），你们的内网也同时连了过去（对，就是那种很直接的搭了几条网线就把两个局域网连成一个局域网的黑科技）。但是因为太远了线节点太多了，分公司访问公司的系统十分缓慢，这时候你就愁啊，这可咋办？那不行就在分公司那边部署一套内容缓存好了，内容进行同步，这样至少分公司的网页访问速度能提升很多，你也可以立功升职加薪了。
紧接着，因为你的出色表现，你们公司扩展十分厉害，在全国各地都建立了分公司，你又开始愁了，这不能每个分公司都搭一套啊，累得慌啊。思来想去，那就华东一套华北一套华南一套东北一套这样分吧，然后搭一些分发服务器，接入访问地址，然后跳转到就近的内容缓存服务器进行内容读取，OK，又到了升职加薪的时刻了~
对，到这里，你已经完成了一套简易CDN的建设。
第五步，CDN是什么？
你的搭建只是基于你公司的大型局域网，而现行的流行CDN则是基于地球搭建的超大型局域网--因特网。它的好处是什么呢？
比如你这么写：
<!-- 引入 Bootstrap -->
<link href="http://apps.bdimg.com/libs/bootstrap/3.3.0/css/bootstrap.min.css" rel="stylesheet">
<!-- HTML5 Shim and Respond.js IE8 support of HTML5 elements and media queries -->
<!--[if lt IE 9]>
<script src="http://apps.bdimg.com/libs/html5shiv/3.7/html5shiv.min.js"></script>
<script src="http://apps.bdimg.com/libs/respond.js/1.4.2/respond.min.js"></script>
<![endif]-->
<!-- jQuery (Bootstrap 的 JavaScript 插件需要引入 jQuery) -->
<script src="http://apps.bdimg.com/libs/jquery/2.1.4/jquery.min.js"></script>
<!-- 包括所有已编译的插件 -->
<script src="http://apps.bdimg.com/libs/bootstrap/3.3.0/js/bootstrap.min.js"></script>上面的地址是百度CDN的链接地址。
那么用户在读取网页内容的时候，就会去百度的就近服务器上掏这些js和css，而不是在你的服务器里捞。
好处呢，第一，一般来说，访问速度有保障，稳定性也有保障；第二，你可以省下资源服务器的一部分资源负担，节省空间节省流量，艰苦创业，能省则省啊。
这时候你会问了，为什么只有js和css呢？其他的图片啊html内容啊不能放进CDN吗？
能啊为啥不能，CDN服务就靠这赚钱呢为啥不能，非广告非广告非广告，你看：
CDN-Content Delivery Network-百度开放云
同类产品还有阿里云等等等等。。
你看的文章中的CDN，一般都是指js和css文件的CDN存储，而对于你的两个问题，遗憾的告诉你，不是，不能。
