并发不是并行，它更好！
英文原文： Concurrency is not Parallelism (it's better)
现代社会是并行的：多核、网络、云计算、用户负载，并发技术对此有用。
Go 语言支持并发，它提供了：并发执行（goroutines），同步和消息（channels）和多路并发控制（select）。
当 Go 声称是并发时，人们说：“并发很酷！耶，我可以并行运行了！”，但这是个错误的。因为很多人都不了解他们间的差别。“我用四个处理器来做质数筛选，但是更慢了。”
并发(Concurrency)：以可独立执行的进程集合的方式编程（进程是出了名的难定义，这里是通常意义上的进程，不是 Linux 进程）
并行(Parallelism)：以可同时执行的（可能相关的）计算指令方式编程。
两者的区别：并发是同时处理(dealing)很多的事情，并行是同时做(doing)很多的事情。不同，但也相关。一个是关于代码结构，一个是关于代码执行。并发为可能的（不是必须的）并行问题提供了一种解决方案。
一个类比：
鼠标、键盘、显示器、磁盘驱动是并发结构的。
向量点积是并行的。
并发带有通信：
并发是一种构造程序的方式，把任务分解为一个个独立运行的小任务。通信是协调这些小任务的手段。
Go 的模型（还有 Erlang 等）都是基于 CPS (Communicating sequential processes, 通信顺序进程)：其论文C. A. R. Hoare: Communicating Sequential Processes (CACM 1978)
以上讲得太抽象了，我们举实际点的例子。
我们的问题：把一堆废弃语言的说明书运到火炉里，一只地鼠会花费很长时间。
更多的地鼠
单单更多的地鼠也不解决问题，它们需要更多的推车。
更多的地鼠、更多的推车
这样会加快速度，但它们会在那堆书和炉子那边遇上瓶颈。同时也要同步两只地鼠，可以通过消息的方式实现。
全部加倍
这样会以两倍的速度运送。这是两个地鼠程序的并发构成（concurrent composition）。
但这种设计不是自发并行的，如果一次只有一只地鼠在运会怎样？
这种设计仍是并发，不是并行。[译者注：一只地鼠运一次上面那堆书，然后第二只地鼠再运一次下面那堆书。一次只允许一只地鼠运送，这样就不是并行的。]
然而，这种场景是可以自发并行的。并发构成可以考虑下其他模型。
另一种设计
三只地鼠在工作，但可能会有延误。每只地鼠是个独立的步骤，附加协调（通信）。
更细粒度的并发
增加一只地鼠用来运回空推车。四只地鼠在工作，运行得更加流畅，每只地鼠都在做一个简单的任务。
如果我们把事情安排的足够好（现实中很难但不是不可能），速度会是最先只有一只地鼠的那个设计的四倍。
观察结论：我们在一个已有的设计（指三个地鼠的那个设计）中添加一个并发的步骤（第四只地鼠）增强了系统的性能。更多的地鼠干了更多的活，系统运行得更好。并发比简单的并行对问题要有更深的洞察。
我们有四个并发的步骤：1.装书到推车上 2. 把推车运到火炉边 3. 把书卸到火炉里 4. 运回空推车
不同的并发设计能以不同的方式来并行。
更多的并行
我们以另一个维度来并行，并行使这样的设计变的容易。八只地鼠，都在繁忙工作。
但也可能根本没有并行
谨记：即使一次只能有一只地鼠在工作（零并行），这也不失为一个良好的并发的解决方案。
另一种设计
下面也是一种用并发组成来解决问题的设计。两只地鼠，再加上一个中转堆。
以一般的方式来并行
用更多的并发程序来提高吞吐量
或者一种不同的方式
在多地鼠并发模型中引入中转堆
全面优化
使用我们所有的技术，16 只地鼠都开足马力。
学到内容
我们有很多方法把问题分解，这才是并发设计。一旦我们分解了问题，并行就自然而然的产生了，正确性也变得很容易。
回到计算
我们关于运书的问题，可以看做是如下的类比：书堆是 Web 数据，地鼠是 CPU，推车是调度、渲染或是网络，火堆是代理、浏览器或是其他的消费者。地鼠提供网络数据，这就是一个可扩展的 Web 服务的并发设计了。