LeanCloud 的控制台会展示一个应用列表，应用列表会展示该用户的所有应用，以及每个应用的基本信息，例如总用户数、昨天请求量和本月请求量等。我们最多允许每个用户创建 50 个应用。伪代码大概是这样: (defn add-app-info "添加应用统计信息。" [app] (assoc app :yesterday_reqs (count-reqs app 7) :monthly_reqs (count-reqs app 30) :total_users (count-users app))) (defn get-client-apps "获取用户的应用列表" [client_id] (->> client_id (db/find-apps-by-client-id) (map add-app-info))) 显然，这里每个应用为了获取这些请求信息，都至少要请求三次。虽然这些统计请求本身已经有了缓存，但是假设有 50 个应用（实际中，部分开发者的应用数量包括协作应用在内会更多），那就需要发起 150 个请求，这个过程如果完全串行处理的话，假设 add-app-info 的开销至少是 1~3 毫秒，串行处理下来也需要 50~150 毫秒，加上传输的时间，那么用户的体验的就相当差了。 这时候，我们可以用并发处理来加速了，你只需要替换一个函数，将 get-client-apps 的 map 替换为 pmap 即可： (defn get-client-apps "获取用户的应用列表" [client_id] (->> client_id (db/find-apps-by-client-id) (pmap add-app-info))) 关于 pmap 的讨论参见 并发函数pmap、pvalues和pcalls。因为 pmap 对于 chunked sequnce 的处理是批量处理，因此最多同时使用 32 个并发任务在处理，这个线程数量在这个场景下是可以接受的。加速后的性能也可以估算出来 (Math/round (/ n 32.

Clojure 的并发方面的详细介绍可以参考我过去总结的 wiki —— Clojure 并发。 这次又想写个系列，介绍下实际编程中对这些并发机制的应用。 不过，很可能不会涉及 STM。 LeanCloud 本质上是一个 web 型的应用，基础的并发模型已经由 web server 和后端存储决定了，STM 的适应场景没有出现过。 这一篇先从 future 和 promise 开始。 最近处理这么一个任务，有一段业务代码要调用一个第三方接口来查询域名备案号，但是呢，这个第三方接口非常不稳定，经常查询出错或者超时，导致这个业务经常不可用。 (defn query-icp [domain] ;; HTTP 调用第三方接口 API 。 (query-icp-from-thirdparty1 domain)) 为了提高这个接口的稳定性，我们引入另一个查询服务，想让两个服务来竞争，谁能返回正常结果，就用谁的。假设这个服务封装成了函数 query-icp-from-thirdparty2。 ok，我们先加个 or 上去 (defn query-icp [domain] (or (query-icp-from-thirdparty1 domain) (query-icp-from-thirdparty2 domain))) 先尝试从一个服务查询，如果没有返回就尝试第二个服务。 但是这样有个问题，第三方服务的调用我们是一定要设置一个超时的。这个 or 改动我们改变了 query-icp 的超时承诺，原来最多等待 query-icp-from-thirdparty1 超时，现在可能遇到最高两倍的超时时间（假设两个服务都遇到超时），因为两个是顺序调用的，这肯定是不能接受的。 第一时间想到，我们将查询并发，启个线程去同时去查询两个服务，这时候就可以用 future。其次，任何一个服务如果有结果返回，我们就使用它，不等另一个服务的结果。在 Java 里我们可以用 CountDownLatch 或者 CompletionService。 在 Clojure 里我们可以用 promise + deliver。 (defn- do-query-icp [p f domain] (future (when-let [ret (f domain)] (deliver p ret)))) (defn query-icp [domain] (let [p (promise)] (do-query-icp p query-icp-from-thirdparty1 domain) (do-query-icp p query-icp-from-thirdparty2 domain) (deref p :5000 nil))) 在 do-query-icp 里我们利用 future 来异步调用接口，当接口有返回的时候，使用 deliver 将结果 ret 喂给 promise。