并发、消息队列、缓存

"并发"会引发关于"顺序"的问题，及如何能够在使用高并发提高效率的同时，又在一定程度上能够“控制/维持”一定的操作顺序。更广泛的，有关并发的"锁"操作，也都会围绕同样的思路来解决问题。

没有银弹。

想要在维持并发的同时，通过什么魔法来同时维持顺序是不可能的。最基本的核心想法是，将并发的操作变为串行，那么操作也就自然会有了顺序。

这是一个看似有些矛盾的解决方案。并发的目的不就是为了提高效率么？！如果将并发变成串行，那之前的并发还有什么意义？

这是一个非常微妙的问题，如果不仔细考虑，很容易在表面上陷入上面的矛盾纠葛之中。而调和这两者的基本思路是：

• “使用并发"来提高效率和"放弃并发"来顺序化，这两个过程可以完全不必发生在同一个地方。可以让效率的瓶颈部分"计算"并行化，而让结果的聚合过程"顺序化”。
• 可以根据"顺序化"的要求来建立独立的分组，让一个过程在group之间并行化，而在这个group内部做细致的串行，从而在保证局部顺序的同时在全局建立效率更高的并行化。

那么最基本的，使用一个队列来顺序化一些列的并发结果，是非常显而易见的。

为什么考虑queue这样的数据结构？正如其名字所暗示的，当有成群的人从四面八方涌来进入一个入口时，保证有序化的一个最基本的方式是：让他们排队。

而这种思想并不需要局限在人群中，而可以抽象出来，为任何抽象的并发任务提供一个解答思路：让所有从四面八方同时冒出来的任务排好队，也即是让它们都进入到一个queue的数据结构中。而为了保证出队、入队的有序性，具备加锁功能的blockingQueue是必须的。

如此就形成了并发任务顺序化的基本思路：让这些并发任务都进入到一个blockingQueue中，出队的过程自然保证了这些任务的有序性。

而把这一思路规模化、稳健化的一个中间件，便是Kafka了。而如果只是轻量级小范围的使用，例如Java中的一个局部，则只需要使用好库里面的BlockingQueue就行了。

“排队"这种思想不只可以应用于"控制并发任务的顺序”，也能够被用来解决任务的加锁问题。诸如Java中的synchronized关键字，在背后所依赖的数据结构也是多个blockingQueue。道理很简单，当你想要控制一堆任务的访问权限，那么，让它们进入一个队列依次获取权限就可以了。

下一个问题是，okay，我知道消息队列可以保存一堆任务，可是，我的任务涉及一大堆的函数执行和数据调度，一个小小的queue能够保存那么多的数据或者操作过程吗？又或是，我的任务只是单纯的执行任务，是一个个的"动作"，这东西怎么能够被保存在queue中呢？这些疑问基本上会基于我们潜意识的一个印象，queue所保存的是一个string，可我需要保存的类型多种多样，甚至不是数据而是操作，一堆string的queue真的够吗？

同样的问题会发生在"缓存"的使用上，例如大名鼎鼎的Redis/Memcached。都说缓存很有用，但同样的问题是，在这些中间件中存储一个string能够满足我们的需求吗？

这就涉及到对序列化的讨论，特别地，对json数据的转换。无论你是做并发的"操作"，还是有大量的数据需要运行，你都可以将其逐层分解为几个核心的、互相配合的数据块。你并不需要将所有的东西都放在缓存中，只需要将那个能够带动其他东西完成整个流程的关键部分放入到缓存中。

在以前的client-server交互中，前后端耦合非常厉害。而基于json数据格式的Restful API之所以能够流行起来，就在于json数据本身成为了前后端之间的不变量，从而可以实现真正意义上的前后端分离。在这里，json数据充当了前后端的业务协议，是真正不变的business logic。

那么同样的，你的缓存中真正应该存储的，就是能够带动各种并发操作的不变量，它可以以json的形式展示，也可以以对象被序列化之后的别的形式展示。但无论是哪一种，都可以被表示为string。更一般地，按照Unix的哲学，一切皆文件。而文件是什么？无非是一堆二进制码，即string。所谓的"信息工程"，information的基本表示方式不就是string么。由此我们便能回答之前提出的问题：小小的string能干什么呢？Everything。

如此，提高效率使用缓存中间件(如Redis/Memcached)，顺序化、整合复杂的并发任务使用消息队列(如Kafka/RabbitMQ)，都是在捣鼓string。而只要能够将string的运输批量化、系统化，那么任何的操作和数据都可以如法炮制。

如此来看，作为重要和酷炫技术的缓存和消息队列，其牛鼻子就是最简单的排队和信息的字符串表示。只要牵住了这个牛鼻子，其它建立在其上的复杂技艺便能够迎刃理解。