Python并发编程-并发解决方案概述
作者：尹正杰
版权声明：原创作品，谢绝转载！否则将追究法律责任。
一.并发和并行区别
1>.并行(parallel)
同时做某些事，可以互不干扰的同一个时刻做几件事。
2>.并发(concurrency)
也是同时做某些事，但是强调，一个时间段内有多少事情要处理。
3>.举例
高速公路的车道，双向4车道，所有车辆(数据)可以互不干扰的在自己的车道上行驶(传输)。
在同一时刻，每条车道上可能同时又车辆在跑，是同时发生的概念，这是并行。
在一段时间内，又这么多车要通过，这是并发。
二.并发的常见解决方案
"食堂打饭模型": 中午12点，开饭啦，大家都涌向食堂，这就是并发。如果人很多，就是高并发。
1>.队列，缓冲区
假设只有一个状况，陆续涌入食堂的人，排队大财是比较好的方式。
所以，排队(队列)是一种天然解决并发的办法。
排队就是把人排成队列，先进先出，解决了资源使用的问题。
排成的队列，其实就是一个缓冲地带，就是缓冲区。
假设女生优先，每次都从这个队伍中优先选出女生来打饭，这就是优先队列。
例如Queue模块的类Queue,LifoQueue,PriorityQueue(小顶堆实现)。
2>.争抢
只开一个这状况，有可能没有秩序，也就是谁挤进去就给谁打饭。
挤到窗口的人占据窗口，直到打到饭菜离开。
其他人继续争抢，会有一个人占据着窗口，可以视为锁定窗口，窗口就不能为其他人提供服务了。这就是一种锁机制。
谁抢到资源就上锁，排他性的独占锁，其他人只能等候。
争抢也是一种高并发解决方案，但是，这样可能不好，因为有可能有人很长时间抢不到。
3>.预处理
其实排队不是问题，就算2万人拍成一队等吃饭，如果能10分钟搞定也行。问题就是并处并发的速度太慢了。 经过分析发现，本食堂主要是打菜等候时间太长，因为每个人都是现场点菜现做。 食堂可以提前统计大多数人最爱吃的菜品，将最爱吃的80%的热门菜，提前做好，保证供应，20%的冷门菜，现做。 这样大多数人，就算不排队采用争抢的方式锁定窗口，也很快达到饭菜走了，快速释放窗口。 这是以中国提前加载用户需要的数据的思路，预处理思想，缓存常用。
4>.并行
成百上千人同时来吃饭，一个队伍搞不定的，多开打饭窗口形成多个队列，如同开多个车道一样，并行打菜。
开窗口就得扩大食堂，得多古人再窗口提供服务，造成成本上升。高速公路的多车道是并行方案，多车道提高了通信效率，但是也意味着建造维护成本也高了。
日常可以通过购买更多服务器，或多开进程，线程实现并行处理，来解决并发问题。
注意这些都是水平扩展的思想。并行是解决并发手段之一。
温馨提示:
如果线程在单CPU上处理，就不是真并行了。
但是，现在多数服务器都是多CPU的，至少也是单颗多核CPU，服务的部署往往是多机的，分布式的，这都是并行处理。
5>.提速
提高单个窗口的打饭速度，也是解决并发的方式。
打饭人员提高工作技能，或为单个窗口配更多的服务人员，都是提速的办法。
提高单个CPU性能，或单个服务器安装更多CPU。
这是一种垂直扩展思想。
6>.消息中间件
在北京的上地，西二旗地铁站外九曲回肠的走廊，缓冲人流，进去之后再多口安检进站。
常见的消息中间件又RabbitMQ,ActiveMQ(Apache),RocketMQ(阿里),kafka(Apache)等。
当然海域哦其它手段解决并发问题，但是已经例举出了常用的解决方案，一般来说不同的场景用不同的策略，而策略可能是多种方式的优化组合。
例如开食堂(多地),也可以把食堂建设到宿舍生活区(就近原则),所以说，技术来源于生活。