越努力，越幸运，
本文已收藏在GitHub中JavaCommunity, 里面有面试分享、源码分析系列文章，欢迎收藏，点赞
https://github.com/Ccww-lx/Ja...

在实际的工作项目中， 缓存成为高并发、高性能架构的关键组件 ，那么Redis为什么可以作为缓存使用呢？首先可以作为缓存的两个主要特征：

• 在分层系统中处于内存/CPU具有访问性能良好，
• 缓存数据饱和，有良好的数据淘汰机制

由于Redis 天然就具有这两个特征，Redis基于内存操作的，且其具有完善的数据淘汰机制，十分适合作为缓存组件。

其中，基于内存操作，容量可以为32-96GB，且操作时间平均为100ns，操作效率高。而且数据淘汰机制众多，在Redis 4.0 后就有8种了促使Redis作为缓存可以适用很多场景。

那Redis缓存为什么需要数据淘汰机制呢？有哪8种数据淘汰机制呢？

数据淘汰机制

Redis缓存基于内存实现的，则其缓存其容量是有限的，当出现缓存被写满的情况，那么这时Redis该如何处理呢？

Redis对于缓存被写满的情况，Redis就需要缓存数据淘汰机制，通过一定淘汰规则将一些数据刷选出来删除，让缓存服务可再使用。那么Redis使用哪些淘汰策略进行刷选删除数据？

在Redis 4.0 之后，Redis 缓存淘汰策略6+2种，包括分成三大类：

• 不淘汰数据

  • noeviction ，不进行数据淘汰，当缓存被写满后，Redis不提供服务直接返回错误。

• 在设置过期时间的键值对中，

  • volatile-random ，在设置过期时间的键值对中随机删除
  • volatile-ttl ，在设置过期时间的键值对，基于过期时间的先后进行删除，越早过期的越先被删除。
  • volatile-lru ， 基于LRU(Least Recently Used) 算法筛选设置了过期时间的键值对， 最近最少使用的原则来筛选数据
  • volatile-lfu ，使用 LFU( Least Frequently Used ) 算法选择设置了过期时间的键值对, 使用频率最少的键值对,来筛选数据。

• 在所有的键值对中，

  • allkeys-random， 从所有键值对中随机选择并删除数据
  • allkeys-lru， 使用 LRU 算法在所有数据中进行筛选
  • allkeys-lfu， 使用 LFU 算法在所有数据中进行筛选

Note: LRU( 最近最少使用，Least Recently Used)算法， LRU维护一个双向链表 ，链表的头和尾分别表示 MRU 端和 LRU 端，分别代表最近最常使用的数据和最近最不常用的数据。

LRU 算法在实际实现时，需要用链表管理所有的缓存数据，这会带来额外的空间开销。而且，当有数据被访问时，需要在链表上把该数据移动到 MRU 端，如果有大量数据被访问，就会带来很多链表移动操作，会很耗时，进而会降低 Redis 缓存性能。

其中，LRU和LFU 基于Redis的对象结构redisObject的lru和refcount属性实现的:

typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    // 对象最后一次被访问的时间
    unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
                            * LFU data (least significant 8 bits frequency
    // 引用计数                        * and most significant 16 bits access time). */
    int refcount;
    void *ptr;
} robj;

Redis的LRU会使用redisObject的lru记录最近一次被访问的时间，随机选取参数maxmemory-samples 配置的数量作为候选集合，在其中选择 lru 属性值最小的数据淘汰出去。

在实际项目中，那么该如何选择数据淘汰机制呢？

• 优先选择 allkeys-lru算法，将最近最常访问的数据留在缓存中，提升应用的访问性能。
• 有顶置数据使用 volatile-lru算法 ,顶置数据不设置缓存过期时间，其他数据设置过期时间，基于LRU 规则进行筛选 。

在理解了Redis缓存淘汰机制后，来看看Redis作为缓存其有多少种模式呢？

Redis缓存模式

Redis缓存模式基于是否接收写请求，可以分成只读缓存和读写缓存：

只读缓存：只处理读操作，所有的更新操作都在数据库中，这样数据不会有丢失的风险。

• Cache Aside模式

读写缓存，读写操作都在缓存中执行，出现宕机故障，会导致数据丢失。缓存回写数据到数据库有分成两种同步和异步：

• 同步：访问性能偏低，其更加侧重于保证数据可靠性

  • Read-Throug模式
  • Write-Through模式

• 异步：有数据丢失风险，其侧重于提供低延迟访问

  • Write-Behind模式

Cache Aside模式

查询数据先从缓存读取数据，如果缓存中不存在，则再到数据库中读取数据，获取到数据之后更新到缓存Cache中，但更新数据操作，会先去更新数据库种的数据，然后将缓存种的数据失效。

而且Cache Aside模式会存在并发风险：执行读操作未命中缓存，然后查询数据库中取数据，数据已经查询到还没放入缓存，同时一个更新写操作让缓存失效，然后读操作再把查询到数据加载缓存，导致缓存的脏数据。

Read/Write-Throug模式

查询数据和更新数据都直接访问缓存服务，缓存服务同步方式地将数据更新到数据库。出现脏数据的概率较低，但是就强依赖缓存，对缓存服务的稳定性有较大要求，但同步更新会导致其性能不好。

Write Behind模式

查询数据和更新数据都直接访问缓存服务，但缓存服务使用异步方式地将数据更新到数据库（通过异步任务） 速度快，效率会非常高，但是数据的一致性比较差，还可能会有数据的丢失情况，实现逻辑也较为复杂。

在实际项目开发中根据实际的业务场景需求来进行选择缓存模式。那了解上述后，我们的应用中为什么需要使用到redis缓存呢？

在应用使用Redis缓存可以提高系统性能和并发，主要体现在

• 高性能：基于内存查询，KV结构，简单逻辑运算
• 高并发： Mysql 每秒只能支持2000左右的请求，Redis轻松每秒1W以上。让80%以上查询走缓存，20%以下查询走数据库，能让系统吞吐量有很大的提高

虽然使用Redis缓存可以大大提升系统的性能，但是使用了缓存，会出现一些问题，比如，缓存与数据库双向不一致、缓存雪崩等，对于出现的这些问题该怎么解决呢？

使用缓存常见的问题

使用了缓存，会出现一些问题，主要体现在：

• 缓存与数据库双写不一致
• 缓存雪崩: Redis 缓存无法处理大量的应用请求，转移到数据库层导致数据库层的压力激增;
• 缓存穿透：访问数据不存在在Redis缓存中和数据库中，导致大量访问穿透缓存直接转移到数据库导致数据库层的压力激增;
• 缓存击穿：缓存无法处理高频热点数据，导致直接高频访问数据库导致数据库层的压力激增;

缓存与数据库数据不一致

只读缓存(Cache Aside模式)

对于只读缓存(Cache Aside模式)， 读操作都发生在缓存中，数据不一致只会发生在删改操作上（新增操作不会，因为新增只会在数据库处理），当发生删改操作时，缓存将数据中标志为无效和更新数据库 。因此在更新数据库和删除缓存值的过程中，无论这两个操作的执行顺序谁先谁后，只要有一个操作失败了就会出现数据不一致的情况。

总结出，当不存在并发的情况使用重试机制（消息队列使用），当存在高并发的情况，使用延迟双删除(在第一次删除后，睡眠一定时间后，再进行删除)，具体如下：

NOTE:

延迟双删除伪代码：

redis.delKey(X)
db.update(X)
Thread.sleep(N)
redis.delKey(X)

读写缓存（Read/Write-Throug、Write Behind模式 ）

对于读写缓存，写操作都发生在缓存中，后再更新数据库，只要有一个操作失败了就会出现数据不一致的情况。

总结出，当不存在并发的情况使用重试机制（消息队列使用），当存在高并发的情况，使用分布锁。具体如下：

缓存雪崩

缓存雪崩，由于缓存中有大量数据同时过期失效或者缓存出现宕机，大量的应用请求无法在 Redis 缓存中进行处理，进而发送到数据库层导致数据库层的压力激增，严重的会造成数据库宕机。

对于缓存中有大量数据同时过期，导致大量请求无法得到处理， 解决方式：

• 数据预热，将发生大并发访问前手动触发加载缓存不同的key， 可以避免在用户请求的时候，先查询数据库
• 设置不同的过期时间，让缓存失效的时间点尽量均匀
• 双层缓存策略， 在原始缓存上加上拷贝缓存，原始缓存失效时可以访问拷贝缓存，且原始缓存失效时间设置为短期，拷贝缓存设置为长期
• 服务降级 ， 发生缓存雪崩时，针对不同的数据采取不同的降级方案 ，比如，非核心数据直接返回预定义信息、空值或是错误信息

对于缓存出现宕机，解决方式：

• 业务系统中实现服务熔断或请求限流机制，防止大量访问导致数据库出现宕机

缓存穿透

缓存穿透，数据在数据库和缓存中都不存在，这样就导致查询数据，在缓存中找不到对应key的value，都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询）。

当有大量访问请求，且其绕过缓存直接查数据库，导致数据库层的压力激增，严重的会造成数据库宕机。

对于缓存穿透，解决方式：

• 缓存空值或缺省值，当一个查询返回的数据为空时， 空结果也将进行缓存，并将它的过期时间设置比较短，下次访问直接从缓存中取值，避免了把大量请求发送给数据库处理，造成数据库出问题。
• 布隆过滤器( BloomFilter )，将所有可能查询数据key哈希到一个足够大的bitmap中 , 在查询的时候先去BloomFilter去查询key是否存在，如果不存在就直接返回，存在再去查询缓存，缓存中没有再去查询数据库 ，从而避免了数据库层的压力激增出现宕机。

缓存击穿

缓存击穿，针对某个访问非常频繁的热点数据过期失效，导致访问无法在缓存中进行处理，进而会有导致大量的直接请求数据库，从而使得数据库层的压力激增，严重的会造成数据库宕机。

对于缓存击穿，解决方式：

• 不设置过期时间，对于访问特别频繁的热点数据，不设置过期时间。

总结

在大多数业务场景下，Redis缓存作为只读缓存使用。针对只读缓存来说， 优先使用先更新数据库再删除缓存的方法保证数据一致性 。

其中，缓存雪崩，缓存穿透，缓存击穿三大问题的原因和解决方式

谢谢各位点赞，没点赞的点个赞支持支持
最后，微信搜《Ccww技术博客》观看更多文章，也欢迎关注一波

`

你是否还在为微服务应该拆多小而争论不休？到底如何才能设计出收放自如的微服务？怎样才能保证业务领域模型与代码模型的一致性？或许本文能帮你找到答案。

本文是基于 DDD 的微服务设计和开发实战篇，通过借鉴领域驱动设计思想，指导微服务项目团队进行设计和开发（理论篇详见《当中台遇上 DDD，我们该如何设计微服务？》）。本文包括三部分内容：第一部分讲述领域驱动设计基本知识，包括：分层架构、服务视图、数据视图和领域事件发布和订阅等；第二部分讲述微服务设计方法、过程、模板、代码目录、设计原则等内容；最后部分以一个项目为例讲述基于 DDD 的微服务设计过程。

一、目标

本文采用 DDD（领域驱动设计）作为微服务设计指导思想，通过事件风暴建立领域模型，合理划分领域逻辑和物理边界，建立领域对象及服务矩阵和服务架构图，定义符合 DDD 分层架构思想的代码结构模型，保证业务模型与代码模型的一致性。通过上述设计思想、方法和过程，指导团队按照 DDD 设计思想完成微服务设计和开发。

通过领域模型和 DDD 的分层思想，屏蔽外部变化对领域逻辑的影响，确保交付的软件产品是边界清晰的微服务，而不是内部边界依然混乱的小单体。在需求和设计变化时，可以轻松的完成微服务的开发、拆分和组合，确保微服务不易受外部变化的影响，并稳定运行。

二、适用范围

本文适用于按照 DDD 设计方法进行微服务设计和开发的项目及相关人员。

以下情况不适用：

1. “我们的目标是按期盖出一栋大楼来，不要跟我提什么方法，有这啰嗦的时间，还不如抓紧点时间搬砖，把楼给我快点盖好！”。
2. “我的工作就是让软件运行起来，能工作一切就 OK！我不需要那么多约束，什么设计方法、扩展性、业务变化、领域模型、响应能力与我无关。别耽误工期啦！先上线再说！”。
3. “好的软件是自己演进出来的，我们不需要设计！”。

哈哈，开个玩笑啦！其实设计不会花太多时间的！

不耽误大家时间了，言归正传。

三、DDD 分层架构视图

DDD 分层架构包括：展现层、应用层、领域层和基础层。

DDD 分层架构各层职能如下：

展现层

展现层负责向用户显示信息和解释用户指令。

应用层

应用层是很薄的一层，主要面向用户用例操作，协调和指挥领域对象来完成业务逻辑。应用层也是与其他系统的应用层进行交互的必要渠道。应用层服务尽量简单，它不包含业务规则或知识，只为下一层的领域对象协调任务，使它们互相协作。应用层还可进行安全认证、权限校验、分布式和持久化事务控制或向外部应用发送基于事件的消息等。

领域层

领域层是软件的核心所在，它实现全部业务逻辑并且通过各种校验手段保证业务正确性。它包含业务所涉及的领域对象（实体、值对象）、领域服务以及它们之间的关系。它负责表达业务概念、业务状态以及业务规则，具体表现形式就是领域模型。

基础层

基础层为各层提供通用的技术能力，包括：为应用层传递消息、提供 API 管理，为领域层提供数据库持久化机制等。它还能通过技术框架来支持各层之间的交互。

四、服务视图

微服务内的服务视图

微服务内有 Facade 接口、应用服务、领域服务和基础服务，各层服务协同配合，为外部提供服务。

1、接口服务

接口服务位于用户接口层，用于处理用户发送的 Restful 请求和解析用户输入的配置文件等，并将信息传递给应用层。

2、应用服务

应用服务位于应用层。用来表述应用和用户行为，负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装。

应用层的服务包括应用服务和领域事件相关服务。

应用服务可对微服务内的领域服务以及微服务外的应用服务进行组合和编排，或者对基础层如文件、缓存等数据直接操作形成应用服务，对外提供粗粒度的服务。

领域事件服务包括两类：领域事件的发布和订阅。通过事件总线和消息队列实现异步数据传输，实现微服务之间的解耦。

3、领域服务

领域服务位于领域层，为完成领域中跨实体或值对象的操作转换而封装的服务，领域服务以与实体和值对象相同的方式参与实施过程。

领域服务对同一个实体的一个或多个方法进行组合和封装，或对多个不同实体的操作进行组合或编排，对外暴露成领域服务。领域服务封装了核心的业务逻辑。实体自身的行为在实体类内部实现，向上封装成领域服务暴露。

为隐藏领域层的业务逻辑实现，所有领域方法和服务等均须通过领域服务对外暴露。

为实现微服务内聚合之间的解耦，原则上禁止跨聚合的领域服务调用和跨聚合的数据相互关联。

4、基础服务

基础服务位于基础层。为各层提供资源服务（如数据库、缓存等），实现各层的解耦，降低外部资源变化对业务逻辑的影响。

基础服务主要为仓储服务，通过依赖反转的方式为各层提供基础资源服务，领域服务和应用服务调用仓储服务接口，利用仓储实现持久化数据对象或直接访问基础资源。

微服务外的服务视图

1. 前端应用与微服务

微服务中的应用服务通过用户接口层组装和数据转换后，发布在 API 网关，为前端应用提供数据展示服务。

2. 微服务与外部应用

跨微服务数据处理时，对实时性要求高的场景，可选择直接调用应用服务的方式（新增和修改类型操作需关注事务一致性）。对实时性要求不高的场景，可选择异步化的领域事件驱动机制（最终数据一致性）。

五、数据视图

DDD 分层架构中数据对象转换的过程如下图。

数据视图应用服务通过数据传输对象（DTO）完成外部数据交换。领域层通过领域对象（DO）作为领域实体和值对象的数据和行为载体。基础层利用持久化对象（PO）完成数据库的交换。

DTO 与 VO 通过 Restful 协议实现 JSON 格式和对象转换。

前端应用与应用层之间 DTO 与 DO 的转换发生在用户接口层。如微服务内应用服务需调用外部微服务的应用服务，则 DTO 的组装和 DTO 与 DO 的转换发生在应用层。

领域层 DO 与 PO 的转换发生在基础层。

六、领域事件和事件总线

领域事件是领域模型中非常重要的部分，用来表示领域中发生的事件。一个领域事件将导致进一步的业务操作，有助于形成完整的业务闭环。领域事件主要用于解耦微服务，各个微服务之间不再是强一致性，而是基于事件的最终一致性。

微服务内的领域事件

微服务内的领域事件可以通过事件总线或利用应用服务实现不同聚合之间的业务协同。当微服务内发生领域事件时，由于大部分事件的集成发生在同一个线程内，不一定需要引入消息中间件。但一个事件如果同时更新多个聚合数据，按照 DDD“一个事务只更新一个聚合根”的原则，可以考虑引入消息中间件，通过异步化的方式，对微服务内不同的聚合根采用不同的事务。

微服务之间的领域事件

微服务之间的数据交互方式通常有两种：应用服务调用和领域事件驱动机制。

领域事件驱动机制更多的用于不同微服务之间的集成，实现微服务之间的解耦。事件库（表）可以用于微服务之间的数据对账，在应用、网络等出现问题后，可以实现源和目的端的数据比对，在数据暂时不一致的情况下仍可根据这些数据完成后续业务处理流程，保证微服务之间数据的最终一致性。

应用服务调用方式通常应用于实时性要求高的业务场景，但一旦涉及到跨微服务的数据修改，将会增加分布式事务控制成本，影响系统性能，微服务之间的耦合度也会变高。

事件总线

事件总线位于基础层，为应用层和领域层服务提供事件消息接收和分发等服务。其大致流程如下：

1、服务触发并发布事件。

2、事件总线事件分发。

• 如果是微服务内的订阅者（微服务内的其它聚合），则直接分发到指定订阅者。
• 如果是微服务外的订阅者，则事件消息先保存到事件库（表）并异步发送到消息中间件。
• 如果同时存在微服务内和外订阅者，则分发到内部订阅者，并将事件消息保存到事件库（表）并异步发送到消息中间件。为了保证事务的一致性，事件表可以共享业务数据库。也可以采用多个微服务共享事件库的方式。当业务操作和事件发布操作跨数据库时，须保证业务操作和事件发布操作数据的强一致性。

事件数据持久化

事件数据的持久化存储可以有两种方案，在项目实施过程中根据具体场景选择最佳方案。

1. 事件数据保存到微服务所在业务数据库的事件表中，利用本地事务保证业务操作和事件发布操作的强一致性。
2. 事件数据保存到多个微服务共享的事件库中。需要注意的一点是：这时业务操作和事件发布操作会跨数据库操作，须保证事务的强一致性（如分布式事务机制）。

事件数据的持久化可以保证数据的完整性，基于这些数据可以完成跨微服务数据的一致性比对。

七、微服务设计方法

事件风暴

本阶段主要完成领域模型设计。

基于 DDD 的微服务设计通常采用事件风暴方法。通过事件风暴完成领域模型设计，划分出微服务逻辑边界和物理边界，定义领域模型中的领域对象，指导微服务设计和开发。事件风暴通常包括产品愿景、场景分析、领域建模、微服务设计和拆分等过程。本文不对事件风暴详细方法做深入描述，如感兴趣可查阅相关资料。

1、产品愿景

产品愿景是对产品的顶层价值设计，对产品目标用户、核心价值、差异化竞争点等信息达成一致，避免产品偏离方向。建议参与角色：业务需求方、产品经理和开发组长。

2、场景分析

场景分析是从用户视角出发，探索业务领域中的典型场景，产出领域中需要支撑的场景分类、用例操作以及不同子域之间的依赖关系，用以支撑领域建模。

建议参与角色：产品经理、需求分析人员、架构师、开发组长和测试组长。

3、领域建模

领域建模是通过对业务和问题域进行分析，建立领域模型，向上通过限界上下文指导微服务边界设计，向下通过聚合指导实体的对象设计。

建议参与角色：领域专家、产品经理、需求分析人员、架构师、开发组长和测试组长。

4、微服务拆分和设计

结合业务限界上下文与技术因素，对服务的粒度、分层、边界划分、依赖关系和集成关系进行梳理，完成微服务拆分和设计。

微服务设计应综合考虑业务职责单一、敏态与稳态业务分离、非功能性需求（如弹性伸缩要求、安全性等要求）、团队组织和沟通效率、软件包大小以及技术异构等因素。

建议参与角色：产品经理、需求分析人员、架构师、开发组长和测试组长。

八、 领域对象及服务矩阵和代码模型设计

本阶段完成领域对象及服务矩阵文档以及微服务代码模型设计。

1、领域对象及服务矩阵

根据事件风暴过程领域对象和关系，对产出的限界上下文、聚合、实体、值对象、仓储、事件、应用服务、领域服务等领域对象以及各对象之间的依赖关系进行梳理，确定各对象在分层架构中的位置和依赖关系，建立领域对象分层架构视图，为每个领域对象建立与代码模型对象的一一映射。

建议参与角色：架构师和开发组长。

2、微服务代码模型

根据领域对象在 DDD 分层架构中所在的层、领域类型、与代码对象的映射关系，定义领域对象在微服务代码模型中的包、类和方法名称等，设计微服务工程的代码层级和代码结构，明确各层间的调用关系。

建议参与角色：架构师和开发组长。

领域对象及服务矩阵样例说明

领域对象及服务矩阵主要用来记录事件风暴和微服务设计过程中产出的领域对象属性，如：各领域对象在 DDD 分层架构中的位置、属性、依赖关系以及与代码对象的映射关系等。通过建立领域对象与代码对象的映射关系，可指导软件开发人员准确无误的按照设计文档完成微服务开发。

以下为领域对象及服务矩阵样例（部分数据，仅供参考）。

各栏说明如下：

层：定义领域对象位于 DDD 分层架构中的哪一层。如：接口层、应用层、领域层以及基础层等。

聚合：在事件风暴过程中将关联紧密的实体和值对象等组合形成聚合。本栏说明聚合名称。

领域对象名称：领域模型中领域对象的具体名称。如：“请假审批已通过”是类型为“事件”的领域对象；“请假单”是领域类型为“实体”的领域对象。

领域类型：在领域模型中根据 DDD 知识域定义的领域对象的类型，如：限界上下文、聚合、聚合根（实体）、实体、值对象、事件、命令、应用服务、领域服务和仓储服务等。

依赖对象名称：根据业务对象依赖或分层调用依赖关系建立的领域对象的依赖关系（如服务调用依赖、关联对象聚合等）。本栏说明领域对象需依赖的其他领域对象，如上层服务在组合和编排过程中对下层服务的调用依赖、实体之间或者实体与值对象在聚合内的依赖等。

包名：代码模型中的包名，本栏说明领域对象所在的软件包。

类名：代码模型中的类名，本栏说明领域对象的类名。

方法名：代码模型中的方法名，本栏说明领域对象实现或操作的方法名。

九、微服务代码结构模型

微服务代码模型最终结果来源于领域对象及服务矩阵。在代码模型设计时须建立领域对象和代码对象的一一映射，保证业务模型与代码模型的一致性，即使不熟悉业务的开发人员或者不熟悉代码的业务人员也可以很快定位到代码位置。

微服务代码总目录 基于 DDD 的代码模型包括 interfaces、application、domain 和 infrastructure 四个目录。

Interfaces（用户接口层）：本目录主要存放用户接口层代码。前端应用通过本层向应用服务获取展现所需的数据。本层主要用于处理用户发送的 Restful 请求和解析用户输入的配置文件等，并将信息传递给 Application 层。主要代码形态是数据组装以及 Facade 接口等。

Application（应用层）：本目录主要存放应用层代码。应用服务代码基于微服务内的领域服务或微服务外的应用服务完成服务编排和组合。为用户接口层提供各种应用数据展现支持。主要代码形态是应用服务和领域事件等。

Domain（领域层）：本目录主要存放领域层代码。本层代码主要实现核心领域逻辑，其主要代码形态是实体类方法和领域服务等。

Infrastructure（基础层）：本目录存放基础层代码，为其它各层提供通用技术能力、三方软件包、配置和基础资源服务等。

用户接口层代码模型

用户接口层代码模型目录包括：assembler、dto 和 facade。

相关文章：
基于 DDD 的微服务设计和开发实战
浅谈我对DDD领域驱动设计的理解
领域驱动设计在前端中的应用

你是否还在为微服务应该拆多小而争论不休？到底如何才能设计出收放自如的微服务？怎样才能保证业务领域模型与代码模型的一致性？或许本文能帮你找到答案。

本文是基于 DDD 的微服务设计和开发实战篇，通过借鉴领域驱动设计思想，指导微服务项目团队进行设计和开发（理论篇详见《当中台遇上 DDD，我们该如何设计微服务？》）。本文包括三部分内容：第一部分讲述领域驱动设计基本知识，包括：分层架构、服务视图、数据视图和领域事件发布和订阅等；第二部分讲述微服务设计方法、过程、模板、代码目录、设计原则等内容；最后部分以一个项目为例讲述基于 DDD 的微服务设计过程。

一、目标

本文采用 DDD（领域驱动设计）作为微服务设计指导思想，通过事件风暴建立领域模型，合理划分领域逻辑和物理边界，建立领域对象及服务矩阵和服务架构图，定义符合 DDD 分层架构思想的代码结构模型，保证业务模型与代码模型的一致性。通过上述设计思想、方法和过程，指导团队按照 DDD 设计思想完成微服务设计和开发。

通过领域模型和 DDD 的分层思想，屏蔽外部变化对领域逻辑的影响，确保交付的软件产品是边界清晰的微服务，而不是内部边界依然混乱的小单体。在需求和设计变化时，可以轻松的完成微服务的开发、拆分和组合，确保微服务不易受外部变化的影响，并稳定运行。

二、适用范围

本文适用于按照 DDD 设计方法进行微服务设计和开发的项目及相关人员。

以下情况不适用：

1. “我们的目标是按期盖出一栋大楼来，不要跟我提什么方法，有这啰嗦的时间，还不如抓紧点时间搬砖，把楼给我快点盖好！”。
2. “我的工作就是让软件运行起来，能工作一切就 OK！我不需要那么多约束，什么设计方法、扩展性、业务变化、领域模型、响应能力与我无关。别耽误工期啦！先上线再说！”。
3. “好的软件是自己演进出来的，我们不需要设计！”。

哈哈，开个玩笑啦！其实设计不会花太多时间的！

不耽误大家时间了，言归正传。

三、DDD 分层架构视图

DDD 分层架构包括：展现层、应用层、领域层和基础层。

DDD 分层架构各层职能如下：

展现层

展现层负责向用户显示信息和解释用户指令。

应用层

应用层是很薄的一层，主要面向用户用例操作，协调和指挥领域对象来完成业务逻辑。应用层也是与其他系统的应用层进行交互的必要渠道。应用层服务尽量简单，它不包含业务规则或知识，只为下一层的领域对象协调任务，使它们互相协作。应用层还可进行安全认证、权限校验、分布式和持久化事务控制或向外部应用发送基于事件的消息等。

领域层

领域层是软件的核心所在，它实现全部业务逻辑并且通过各种校验手段保证业务正确性。它包含业务所涉及的领域对象（实体、值对象）、领域服务以及它们之间的关系。它负责表达业务概念、业务状态以及业务规则，具体表现形式就是领域模型。

基础层

基础层为各层提供通用的技术能力，包括：为应用层传递消息、提供 API 管理，为领域层提供数据库持久化机制等。它还能通过技术框架来支持各层之间的交互。

四、服务视图

微服务内的服务视图

微服务内有 Facade 接口、应用服务、领域服务和基础服务，各层服务协同配合，为外部提供服务。

1、接口服务

接口服务位于用户接口层，用于处理用户发送的 Restful 请求和解析用户输入的配置文件等，并将信息传递给应用层。

2、应用服务

应用服务位于应用层。用来表述应用和用户行为，负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装。

应用层的服务包括应用服务和领域事件相关服务。

应用服务可对微服务内的领域服务以及微服务外的应用服务进行组合和编排，或者对基础层如文件、缓存等数据直接操作形成应用服务，对外提供粗粒度的服务。

领域事件服务包括两类：领域事件的发布和订阅。通过事件总线和消息队列实现异步数据传输，实现微服务之间的解耦。

3、领域服务

领域服务位于领域层，为完成领域中跨实体或值对象的操作转换而封装的服务，领域服务以与实体和值对象相同的方式参与实施过程。

领域服务对同一个实体的一个或多个方法进行组合和封装，或对多个不同实体的操作进行组合或编排，对外暴露成领域服务。领域服务封装了核心的业务逻辑。实体自身的行为在实体类内部实现，向上封装成领域服务暴露。

为隐藏领域层的业务逻辑实现，所有领域方法和服务等均须通过领域服务对外暴露。

为实现微服务内聚合之间的解耦，原则上禁止跨聚合的领域服务调用和跨聚合的数据相互关联。

4、基础服务

基础服务位于基础层。为各层提供资源服务（如数据库、缓存等），实现各层的解耦，降低外部资源变化对业务逻辑的影响。

基础服务主要为仓储服务，通过依赖反转的方式为各层提供基础资源服务，领域服务和应用服务调用仓储服务接口，利用仓储实现持久化数据对象或直接访问基础资源。

微服务外的服务视图

1. 前端应用与微服务

微服务中的应用服务通过用户接口层组装和数据转换后，发布在 API 网关，为前端应用提供数据展示服务。

2. 微服务与外部应用

跨微服务数据处理时，对实时性要求高的场景，可选择直接调用应用服务的方式（新增和修改类型操作需关注事务一致性）。对实时性要求不高的场景，可选择异步化的领域事件驱动机制（最终数据一致性）。

五、数据视图

DDD 分层架构中数据对象转换的过程如下图。

数据视图应用服务通过数据传输对象（DTO）完成外部数据交换。领域层通过领域对象（DO）作为领域实体和值对象的数据和行为载体。基础层利用持久化对象（PO）完成数据库的交换。

DTO 与 VO 通过 Restful 协议实现 JSON 格式和对象转换。

前端应用与应用层之间 DTO 与 DO 的转换发生在用户接口层。如微服务内应用服务需调用外部微服务的应用服务，则 DTO 的组装和 DTO 与 DO 的转换发生在应用层。

领域层 DO 与 PO 的转换发生在基础层。

六、领域事件和事件总线

领域事件是领域模型中非常重要的部分，用来表示领域中发生的事件。一个领域事件将导致进一步的业务操作，有助于形成完整的业务闭环。领域事件主要用于解耦微服务，各个微服务之间不再是强一致性，而是基于事件的最终一致性。

微服务内的领域事件

微服务内的领域事件可以通过事件总线或利用应用服务实现不同聚合之间的业务协同。当微服务内发生领域事件时，由于大部分事件的集成发生在同一个线程内，不一定需要引入消息中间件。但一个事件如果同时更新多个聚合数据，按照 DDD“一个事务只更新一个聚合根”的原则，可以考虑引入消息中间件，通过异步化的方式，对微服务内不同的聚合根采用不同的事务。

微服务之间的领域事件

微服务之间的数据交互方式通常有两种：应用服务调用和领域事件驱动机制。

领域事件驱动机制更多的用于不同微服务之间的集成，实现微服务之间的解耦。事件库（表）可以用于微服务之间的数据对账，在应用、网络等出现问题后，可以实现源和目的端的数据比对，在数据暂时不一致的情况下仍可根据这些数据完成后续业务处理流程，保证微服务之间数据的最终一致性。

应用服务调用方式通常应用于实时性要求高的业务场景，但一旦涉及到跨微服务的数据修改，将会增加分布式事务控制成本，影响系统性能，微服务之间的耦合度也会变高。

事件总线

事件总线位于基础层，为应用层和领域层服务提供事件消息接收和分发等服务。其大致流程如下：

1、服务触发并发布事件。

2、事件总线事件分发。

• 如果是微服务内的订阅者（微服务内的其它聚合），则直接分发到指定订阅者。
• 如果是微服务外的订阅者，则事件消息先保存到事件库（表）并异步发送到消息中间件。
• 如果同时存在微服务内和外订阅者，则分发到内部订阅者，并将事件消息保存到事件库（表）并异步发送到消息中间件。为了保证事务的一致性，事件表可以共享业务数据库。也可以采用多个微服务共享事件库的方式。当业务操作和事件发布操作跨数据库时，须保证业务操作和事件发布操作数据的强一致性。

事件数据持久化

事件数据的持久化存储可以有两种方案，在项目实施过程中根据具体场景选择最佳方案。

1. 事件数据保存到微服务所在业务数据库的事件表中，利用本地事务保证业务操作和事件发布操作的强一致性。
2. 事件数据保存到多个微服务共享的事件库中。需要注意的一点是：这时业务操作和事件发布操作会跨数据库操作，须保证事务的强一致性（如分布式事务机制）。

事件数据的持久化可以保证数据的完整性，基于这些数据可以完成跨微服务数据的一致性比对。

七、微服务设计方法

事件风暴

本阶段主要完成领域模型设计。

基于 DDD 的微服务设计通常采用事件风暴方法。通过事件风暴完成领域模型设计，划分出微服务逻辑边界和物理边界，定义领域模型中的领域对象，指导微服务设计和开发。事件风暴通常包括产品愿景、场景分析、领域建模、微服务设计和拆分等过程。本文不对事件风暴详细方法做深入描述，如感兴趣可查阅相关资料。

1、产品愿景

产品愿景是对产品的顶层价值设计，对产品目标用户、核心价值、差异化竞争点等信息达成一致，避免产品偏离方向。建议参与角色：业务需求方、产品经理和开发组长。

2、场景分析

场景分析是从用户视角出发，探索业务领域中的典型场景，产出领域中需要支撑的场景分类、用例操作以及不同子域之间的依赖关系，用以支撑领域建模。

建议参与角色：产品经理、需求分析人员、架构师、开发组长和测试组长。

3、领域建模

领域建模是通过对业务和问题域进行分析，建立领域模型，向上通过限界上下文指导微服务边界设计，向下通过聚合指导实体的对象设计。

建议参与角色：领域专家、产品经理、需求分析人员、架构师、开发组长和测试组长。

4、微服务拆分和设计

结合业务限界上下文与技术因素，对服务的粒度、分层、边界划分、依赖关系和集成关系进行梳理，完成微服务拆分和设计。

微服务设计应综合考虑业务职责单一、敏态与稳态业务分离、非功能性需求（如弹性伸缩要求、安全性等要求）、团队组织和沟通效率、软件包大小以及技术异构等因素。

建议参与角色：产品经理、需求分析人员、架构师、开发组长和测试组长。

八、 领域对象及服务矩阵和代码模型设计

本阶段完成领域对象及服务矩阵文档以及微服务代码模型设计。

1、领域对象及服务矩阵

根据事件风暴过程领域对象和关系，对产出的限界上下文、聚合、实体、值对象、仓储、事件、应用服务、领域服务等领域对象以及各对象之间的依赖关系进行梳理，确定各对象在分层架构中的位置和依赖关系，建立领域对象分层架构视图，为每个领域对象建立与代码模型对象的一一映射。

建议参与角色：架构师和开发组长。

2、微服务代码模型

根据领域对象在 DDD 分层架构中所在的层、领域类型、与代码对象的映射关系，定义领域对象在微服务代码模型中的包、类和方法名称等，设计微服务工程的代码层级和代码结构，明确各层间的调用关系。

建议参与角色：架构师和开发组长。

领域对象及服务矩阵样例说明

领域对象及服务矩阵主要用来记录事件风暴和微服务设计过程中产出的领域对象属性，如：各领域对象在 DDD 分层架构中的位置、属性、依赖关系以及与代码对象的映射关系等。通过建立领域对象与代码对象的映射关系，可指导软件开发人员准确无误的按照设计文档完成微服务开发。

以下为领域对象及服务矩阵样例（部分数据，仅供参考）。

各栏说明如下：

层：定义领域对象位于 DDD 分层架构中的哪一层。如：接口层、应用层、领域层以及基础层等。

聚合：在事件风暴过程中将关联紧密的实体和值对象等组合形成聚合。本栏说明聚合名称。

领域对象名称：领域模型中领域对象的具体名称。如：“请假审批已通过”是类型为“事件”的领域对象；“请假单”是领域类型为“实体”的领域对象。

领域类型：在领域模型中根据 DDD 知识域定义的领域对象的类型，如：限界上下文、聚合、聚合根（实体）、实体、值对象、事件、命令、应用服务、领域服务和仓储服务等。

依赖对象名称：根据业务对象依赖或分层调用依赖关系建立的领域对象的依赖关系（如服务调用依赖、关联对象聚合等）。本栏说明领域对象需依赖的其他领域对象，如上层服务在组合和编排过程中对下层服务的调用依赖、实体之间或者实体与值对象在聚合内的依赖等。

包名：代码模型中的包名，本栏说明领域对象所在的软件包。

类名：代码模型中的类名，本栏说明领域对象的类名。

方法名：代码模型中的方法名，本栏说明领域对象实现或操作的方法名。

九、微服务代码结构模型

微服务代码模型最终结果来源于领域对象及服务矩阵。在代码模型设计时须建立领域对象和代码对象的一一映射，保证业务模型与代码模型的一致性，即使不熟悉业务的开发人员或者不熟悉代码的业务人员也可以很快定位到代码位置。

微服务代码总目录 基于 DDD 的代码模型包括 interfaces、application、domain 和 infrastructure 四个目录。

Interfaces（用户接口层）：本目录主要存放用户接口层代码。前端应用通过本层向应用服务获取展现所需的数据。本层主要用于处理用户发送的 Restful 请求和解析用户输入的配置文件等，并将信息传递给 Application 层。主要代码形态是数据组装以及 Facade 接口等。

Application（应用层）：本目录主要存放应用层代码。应用服务代码基于微服务内的领域服务或微服务外的应用服务完成服务编排和组合。为用户接口层提供各种应用数据展现支持。主要代码形态是应用服务和领域事件等。

Domain（领域层）：本目录主要存放领域层代码。本层代码主要实现核心领域逻辑，其主要代码形态是实体类方法和领域服务等。

Infrastructure（基础层）：本目录存放基础层代码，为其它各层提供通用技术能力、三方软件包、配置和基础资源服务等。

用户接口层代码模型

用户接口层代码模型目录包括：assembler、dto 和 facade。

相关文章：
基于 DDD 的微服务设计和开发实战
浅谈我对DDD领域驱动设计的理解
领域驱动设计在前端中的应用

守护进程(daemon)
守护进程是一类在后台运行的特殊进程，用于执行特定的系统任务。很多守护进程在系统引导的时候启动，并且一直运行直到系统关闭。另一些只在需要的时候才启动，完成任务后就自动结束。

nohup
nohup 是后台作业的意思， nohup运行的进程将会忽略终端信号运行。即后台运行一个命令。
nohup COMMAND & 用nohup运行命令可以使命令永久的执行下去，和用户终端没有关系，例如我们断开SSH连接都不会影响它的运行。

supervisor
supervisor是用Python开发的一套通用的进程管理程序，能将一个普通的命令行进程变为后台daemon，并监控进程状态，异常退出时能自动重启。

之前一直使用nohup启动进程，之后接触了supervisor，感觉更为合适，所以自己安装了一遍，简单记录了步骤：

1、安装supervisor

执行以下命令

yum install python-setuptools
easy_install supervisor

或者

#如果easy_install不好使就从官方下载：
wget https://pypi.python.org/packages/80/37/964c0d53cbd328796b1aeb7abea4c0f7b0e8c7197ea9b0b9967b7d004def/supervisor-3.3.1.tar.gz
#然后通过python安装：
tar zxf supervisor-3.3.1.tar.gz
cd supervisor
python setup.py install

2、配置Supervisor

a.创建文件夹和配置文件

mkdir /etc/supervisor
echo_supervisord_conf > /etc/supervisor/supervisord.conf

b.修改/etc/supervisor/supervisord.conf文件内容
在文件结尾[include]节点处
把;files = relative/directory/*.ini

改为files = conf.d/*.conf

c.若supervisor已经启动，需要执行supervisorctl reload命令使配置文件生效。
d.在/etc/supervisor/下创建conf.d文件夹，及ProjectName.conf(以项目名称命名的)
e.打开laravel.conf文件，添加内容如下：

[program:laravel]
process_name=%(program_name)s_%(process_num)02d
command=/usr/local/php/bin/php /data/wwwroot/laravel/artisan queue:listen --tries=3
autostart=true
autorestart=true
user=www
numprocs=2
redirect_stderr=true
stdout_logfile=/data/wwwlogs/worker.log

3、运行supervisord，查看是否生效，执行以下命令：

#运行
supervisord -c /etc/supervisor/supervisord.conf
#查看进程 (ps -ef | grep ProjectName)
ps -ef|grep laravel

4、配置supervisord开机启动

a.在指定目录下创建文件supervisord.service

vim /usr/lib/systemd/system/supervisord.service

b.输入以下内容：

[Unit]
Description=Supervisor daemon

[Service]
Type=forking
ExecStart=/usr/bin/supervisord -c /etc/supervisor/supervisord.conf
ExecStop=/usr/bin/supervisorctl shutdown
ExecReload=/usr/bin/supervisorctl reload
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

c.执行以下命令：

systemctl enable supervisord

d.验证是否为开机启动：

#提示 enabled 表示成功
systemctl is-enabled supervisord

5、常用命令

service supervisord start #启动
service supervisord stop #停止
service supervisord status #状态
supervisorctl shutdown #关闭所有任务
supervisorctl stop|start program_name #启动或停止服务
supervisorctl status #查看所有任务状态

守护进程(daemon)
守护进程是一类在后台运行的特殊进程，用于执行特定的系统任务。很多守护进程在系统引导的时候启动，并且一直运行直到系统关闭。另一些只在需要的时候才启动，完成任务后就自动结束。

nohup
nohup 是后台作业的意思， nohup运行的进程将会忽略终端信号运行。即后台运行一个命令。
nohup COMMAND & 用nohup运行命令可以使命令永久的执行下去，和用户终端没有关系，例如我们断开SSH连接都不会影响它的运行。

supervisor
supervisor是用Python开发的一套通用的进程管理程序，能将一个普通的命令行进程变为后台daemon，并监控进程状态，异常退出时能自动重启。

之前一直使用nohup启动进程，之后接触了supervisor，感觉更为合适，所以自己安装了一遍，简单记录了步骤：

1、安装supervisor

执行以下命令

yum install python-setuptools
easy_install supervisor

或者

#如果easy_install不好使就从官方下载：
wget https://pypi.python.org/packages/80/37/964c0d53cbd328796b1aeb7abea4c0f7b0e8c7197ea9b0b9967b7d004def/supervisor-3.3.1.tar.gz
#然后通过python安装：
tar zxf supervisor-3.3.1.tar.gz
cd supervisor
python setup.py install

2、配置Supervisor

a.创建文件夹和配置文件

mkdir /etc/supervisor
echo_supervisord_conf > /etc/supervisor/supervisord.conf

b.修改/etc/supervisor/supervisord.conf文件内容
在文件结尾[include]节点处
把;files = relative/directory/*.ini

改为files = conf.d/*.conf

c.若supervisor已经启动，需要执行supervisorctl reload命令使配置文件生效。
d.在/etc/supervisor/下创建conf.d文件夹，及ProjectName.conf(以项目名称命名的)
e.打开laravel.conf文件，添加内容如下：

[program:laravel]
process_name=%(program_name)s_%(process_num)02d
command=/usr/local/php/bin/php /data/wwwroot/laravel/artisan queue:listen --tries=3
autostart=true
autorestart=true
user=www
numprocs=2
redirect_stderr=true
stdout_logfile=/data/wwwlogs/worker.log

3、运行supervisord，查看是否生效，执行以下命令：

#运行
supervisord -c /etc/supervisor/supervisord.conf
#查看进程 (ps -ef | grep ProjectName)
ps -ef|grep laravel

4、配置supervisord开机启动

a.在指定目录下创建文件supervisord.service

vim /usr/lib/systemd/system/supervisord.service

b.输入以下内容：

[Unit]
Description=Supervisor daemon

[Service]
Type=forking
ExecStart=/usr/bin/supervisord -c /etc/supervisor/supervisord.conf
ExecStop=/usr/bin/supervisorctl shutdown
ExecReload=/usr/bin/supervisorctl reload
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

c.执行以下命令：

systemctl enable supervisord

d.验证是否为开机启动：

#提示 enabled 表示成功
systemctl is-enabled supervisord

5、常用命令

service supervisord start #启动
service supervisord stop #停止
service supervisord status #状态
supervisorctl shutdown #关闭所有任务
supervisorctl stop|start program_name #启动或停止服务
supervisorctl status #查看所有任务状态

作者：东哥起飞
首发于公众号：Python数据科学

对于Pandas运行速度的提升方法，之前已经介绍过很多回了，里面经常提及Dask，很多朋友没接触过可能不太了解，今天就推荐一下这个神器。

1、什么是Dask？

Pandas和Numpy大家都不陌生了，代码运行后数据都加载到RAM中，如果数据集特别大，我们就会看到内存飙升。但有时要处理的数据并不适合RAM，这时候Dask来了。

Dask是开源免费的。它是与其他社区项目（如Numpy，Pandas和Scikit-Learn）协调开发的。

官方：https://dask.org/

Dask支持Pandas的DataFrame和NumpyArray的数据结构，并且既可在本地计算机上运行，也可以扩展到在集群上运行。

基本上，只要编写一次代码，使用普通的Pythonic语法，就可在本地运行或部署到多节点集群上。这本身就是一个很牛逼的功能了，但这还不是最牛逼的。

我觉得Dask的最牛逼的功能是：它兼容大部分我们已经在用的工具，并且只需改动少量的代码，就可以利用自己笔记本电脑上已有的处理能力并行运行代码。而并行处理数据就意味着更少的执行时间，更少的等待时间和更多的分析时间。

下面这个就是Dask进行数据处理的大致流程。

2、Dask支持哪些现有工具？

这一点也是我比较看中的，因为Dask可以与Python数据处理和建模的库包兼容，沿用库包的API，这对于Python使用者来说学习成本是极低的。而像Hadoop、Spark这种大数据处理是有很高的学习门槛和时间成本的。

目前，Dask可支持pandas、Numpy、Sklearn、XGBoost、XArray、RAPIDS等等，光是这几项我觉得就足够用了，至少对于常用的数据处理、建模分析是完全覆盖得掉的。

3、Dask安装

可以使用 conda 或者 pip，或从源代码安装dask 。

conda install dask

因为dask有很多依赖，所以为了快速安装也可用下面代码，将安装运行Dask所需的最少依赖关系集。

conda install dask-core

再有就是通过源来安装。

git clone https://github.com/dask/dask.git
cd dask
python -m pip install .

4、Dask如何使用？

Numpy、pandas

Dask引入了3个并行集合，它们可以存储大于RAM的数据，这些集合有DataFrame、Bags、Arrays。这些集合类型中的每一个都能够使用在RAM和硬盘之间分区的数据，以及分布在群集中多个节点上的数据。

Dask的使用是非常清晰的，如果你使用NumPy数组，就从Dask数组开始，如果你使用Pandas DataFrame，就从Dask DataFrame开始，依此类推。

import dask.array as da
x = da.random.uniform(low=0, high=10, size=(10000, 10000),  # normal numpy code
                      chunks=(1000, 1000))  # break into chunks of size 1000x1000

y = x + x.T - x.mean(axis=0)  # Use normal syntax for high level algorithms

# DataFrames
import dask.dataframe as dd
df = dd.read_csv('2018-*-*.csv', parse_dates='timestamp',  # normal Pandas code
                 blocksize=64000000)  # break text into 64MB chunks

s = df.groupby('name').balance.mean()  # Use normal syntax for high level algorithms

# Bags / lists
import dask.bag as db
b = db.read_text('*.json').map(json.loads)
total = (b.filter(lambda d: d['name'] == 'Alice')
          .map(lambda d: d['balance'])
          .sum())

这些高级接口在略微变化的情况下复制了标准接口。对于原始项目中的大部分API，这些接口会自动为我们并行处理较大的数据集，实现上不是很复杂，对照Dask的doc文档即可一步步完成。

Delayed

下面说一下Dask的 Delay 功能，非常强大。

Dask.delayed是一种并行化现有代码的简单而强大的方法。之所以被叫做delayed是因为，它没有立即计算出结果，而是将要作为任务计算的结果记录在一个图形中，稍后将在并行硬件上运行。

有时问题用已有的dask.array或dask.dataframe可能都不适合，在这些情况下，我们可以使用更简单的dask.delayed界面并行化自定义算法。例如下面这个例子。

def inc(x):
    return x + 1

def double(x):
    return x * 2

def add(x, y):
    return x + y

data = [1, 2, 3, 4, 5]

output = []
for x in data:
    a = inc(x)
    b = double(x)
    c = add(a, b)
    output.append(c)

total = sum(output)
45

上面代码在单个线程中按顺序运行。但是，我们看到其中很多可以并行执行。Dask delayed函数可修饰inc、double这些函数，以便它们可延迟运行，而不是立即执行函数，它将函数及其参数放入计算任务图中。

我们简单修改代码，用delayed函数包装一下。

import dask

output = []
for x in data:
    a = dask.delayed(inc)(x)
    b = dask.delayed(double)(x)
    c = dask.delayed(add)(a, b)
    output.append(c)

total = dask.delayed(sum)(output)

代码运行后inc、double、add和sum都还没有发生，而是生成一个计算的任务图交给了total。然后我们用visualizatize看下任务图。

total.visualize()  

上图明显看到了并行的可能性，所以毫不犹豫，使用compute进行并行计算，这时才完成了计算。

>>> total.compute()
45

由于数据集较小无法比较时间，这里只介绍下使用方法，具体可自己动手实践下。

Sklearn机器学习

关于机器学习的并行化执行，由于内容较多，东哥会在另一篇文章展开。这里简单说下一下dask-learn。

dask-learn项目是与Sklearn开发人员协作完成的。现在可实现并行化有Scikit-learn的Pipeline、GridsearchCV和RandomSearchCV以及这些的变体，它们可以更好地处理嵌套的并行操作。

因此，如果你将sklearn替换为dklearn，那么速度将会提升很多。

# from sklearn.grid_search import GridSearchCV
  from dklearn.grid_search import GridSearchCV
# from sklearn.pipeline import Pipeline
  from dklearn.pipeline import Pipeline
下面是一个使用Pipeline的示例，其中应用了PCA和逻辑回归。
from sklearn.datasets import make_classification

X, y = make_classification(n_samples=10000,
                           n_features=500,
                           n_classes=2,
                           n_redundant=250,
                           random_state=42)

from sklearn import linear_model, decomposition
from sklearn.pipeline import Pipeline
from dklearn.pipeline import Pipeline

logistic = linear_model.LogisticRegression()
pca = decomposition.PCA()
pipe = Pipeline(steps=[('pca', pca),
                       ('logistic', logistic)])


grid = dict(pca__n_components=[50, 100, 150, 250],
            logistic__C=[1e-4, 1.0, 10, 1e4],
            logistic__penalty=['l1', 'l2'])

# from sklearn.grid_search import GridSearchCV
from dklearn.grid_search import GridSearchCV

estimator = GridSearchCV(pipe, grid)

estimator.fit(X, y)

结果是：sklearn会在40秒钟左右执行此计算，而dask-learn替代品大约需要10秒钟。
另外，如果添加以下代码可以连接到集群，通过Client可以展示整个计算过程的dashboard，由Bokeh实现。

from dask.distributed import Client
c = Client('scheduler-address:8786')

5、总结

以上就是Dask的简单介绍，Dask的功能是非常强大的，且说明文档也非常全，既有示例又有解释。感兴趣的朋友可以自行去官网或者GitHub学习，东哥下次分享使用Dask进行机器学习的一些实例。

原创不易，觉得不错点个赞。

欢迎关注我的个人公众号：Python数据科学

数据科学学习网站：datadeepin

作者：东哥起飞
首发于公众号：Python数据科学

对于Pandas运行速度的提升方法，之前已经介绍过很多回了，里面经常提及Dask，很多朋友没接触过可能不太了解，今天就推荐一下这个神器。

1、什么是Dask？

Pandas和Numpy大家都不陌生了，代码运行后数据都加载到RAM中，如果数据集特别大，我们就会看到内存飙升。但有时要处理的数据并不适合RAM，这时候Dask来了。

Dask是开源免费的。它是与其他社区项目（如Numpy，Pandas和Scikit-Learn）协调开发的。

官方：https://dask.org/

Dask支持Pandas的DataFrame和NumpyArray的数据结构，并且既可在本地计算机上运行，也可以扩展到在集群上运行。

基本上，只要编写一次代码，使用普通的Pythonic语法，就可在本地运行或部署到多节点集群上。这本身就是一个很牛逼的功能了，但这还不是最牛逼的。

我觉得Dask的最牛逼的功能是：它兼容大部分我们已经在用的工具，并且只需改动少量的代码，就可以利用自己笔记本电脑上已有的处理能力并行运行代码。而并行处理数据就意味着更少的执行时间，更少的等待时间和更多的分析时间。

下面这个就是Dask进行数据处理的大致流程。

2、Dask支持哪些现有工具？

这一点也是我比较看中的，因为Dask可以与Python数据处理和建模的库包兼容，沿用库包的API，这对于Python使用者来说学习成本是极低的。而像Hadoop、Spark这种大数据处理是有很高的学习门槛和时间成本的。

目前，Dask可支持pandas、Numpy、Sklearn、XGBoost、XArray、RAPIDS等等，光是这几项我觉得就足够用了，至少对于常用的数据处理、建模分析是完全覆盖得掉的。

3、Dask安装

可以使用 conda 或者 pip，或从源代码安装dask 。

conda install dask

因为dask有很多依赖，所以为了快速安装也可用下面代码，将安装运行Dask所需的最少依赖关系集。

conda install dask-core

再有就是通过源来安装。

git clone https://github.com/dask/dask.git
cd dask
python -m pip install .

4、Dask如何使用？

Numpy、pandas

Dask引入了3个并行集合，它们可以存储大于RAM的数据，这些集合有DataFrame、Bags、Arrays。这些集合类型中的每一个都能够使用在RAM和硬盘之间分区的数据，以及分布在群集中多个节点上的数据。

Dask的使用是非常清晰的，如果你使用NumPy数组，就从Dask数组开始，如果你使用Pandas DataFrame，就从Dask DataFrame开始，依此类推。

import dask.array as da
x = da.random.uniform(low=0, high=10, size=(10000, 10000),  # normal numpy code
                      chunks=(1000, 1000))  # break into chunks of size 1000x1000

y = x + x.T - x.mean(axis=0)  # Use normal syntax for high level algorithms

# DataFrames
import dask.dataframe as dd
df = dd.read_csv('2018-*-*.csv', parse_dates='timestamp',  # normal Pandas code
                 blocksize=64000000)  # break text into 64MB chunks

s = df.groupby('name').balance.mean()  # Use normal syntax for high level algorithms

# Bags / lists
import dask.bag as db
b = db.read_text('*.json').map(json.loads)
total = (b.filter(lambda d: d['name'] == 'Alice')
          .map(lambda d: d['balance'])
          .sum())

这些高级接口在略微变化的情况下复制了标准接口。对于原始项目中的大部分API，这些接口会自动为我们并行处理较大的数据集，实现上不是很复杂，对照Dask的doc文档即可一步步完成。

Delayed

下面说一下Dask的 Delay 功能，非常强大。

Dask.delayed是一种并行化现有代码的简单而强大的方法。之所以被叫做delayed是因为，它没有立即计算出结果，而是将要作为任务计算的结果记录在一个图形中，稍后将在并行硬件上运行。

有时问题用已有的dask.array或dask.dataframe可能都不适合，在这些情况下，我们可以使用更简单的dask.delayed界面并行化自定义算法。例如下面这个例子。

def inc(x):
    return x + 1

def double(x):
    return x * 2

def add(x, y):
    return x + y

data = [1, 2, 3, 4, 5]

output = []
for x in data:
    a = inc(x)
    b = double(x)
    c = add(a, b)
    output.append(c)

total = sum(output)
45

上面代码在单个线程中按顺序运行。但是，我们看到其中很多可以并行执行。Dask delayed函数可修饰inc、double这些函数，以便它们可延迟运行，而不是立即执行函数，它将函数及其参数放入计算任务图中。

我们简单修改代码，用delayed函数包装一下。

import dask

output = []
for x in data:
    a = dask.delayed(inc)(x)
    b = dask.delayed(double)(x)
    c = dask.delayed(add)(a, b)
    output.append(c)

total = dask.delayed(sum)(output)

代码运行后inc、double、add和sum都还没有发生，而是生成一个计算的任务图交给了total。然后我们用visualizatize看下任务图。

total.visualize()  

上图明显看到了并行的可能性，所以毫不犹豫，使用compute进行并行计算，这时才完成了计算。

>>> total.compute()
45

由于数据集较小无法比较时间，这里只介绍下使用方法，具体可自己动手实践下。

Sklearn机器学习

关于机器学习的并行化执行，由于内容较多，东哥会在另一篇文章展开。这里简单说下一下dask-learn。

dask-learn项目是与Sklearn开发人员协作完成的。现在可实现并行化有Scikit-learn的Pipeline、GridsearchCV和RandomSearchCV以及这些的变体，它们可以更好地处理嵌套的并行操作。

因此，如果你将sklearn替换为dklearn，那么速度将会提升很多。

# from sklearn.grid_search import GridSearchCV
  from dklearn.grid_search import GridSearchCV
# from sklearn.pipeline import Pipeline
  from dklearn.pipeline import Pipeline
下面是一个使用Pipeline的示例，其中应用了PCA和逻辑回归。
from sklearn.datasets import make_classification

X, y = make_classification(n_samples=10000,
                           n_features=500,
                           n_classes=2,
                           n_redundant=250,
                           random_state=42)

from sklearn import linear_model, decomposition
from sklearn.pipeline import Pipeline
from dklearn.pipeline import Pipeline

logistic = linear_model.LogisticRegression()
pca = decomposition.PCA()
pipe = Pipeline(steps=[('pca', pca),
                       ('logistic', logistic)])


grid = dict(pca__n_components=[50, 100, 150, 250],
            logistic__C=[1e-4, 1.0, 10, 1e4],
            logistic__penalty=['l1', 'l2'])

# from sklearn.grid_search import GridSearchCV
from dklearn.grid_search import GridSearchCV

estimator = GridSearchCV(pipe, grid)

estimator.fit(X, y)

结果是：sklearn会在40秒钟左右执行此计算，而dask-learn替代品大约需要10秒钟。
另外，如果添加以下代码可以连接到集群，通过Client可以展示整个计算过程的dashboard，由Bokeh实现。

from dask.distributed import Client
c = Client('scheduler-address:8786')

5、总结

以上就是Dask的简单介绍，Dask的功能是非常强大的，且说明文档也非常全，既有示例又有解释。感兴趣的朋友可以自行去官网或者GitHub学习，东哥下次分享使用Dask进行机器学习的一些实例。

原创不易，觉得不错点个赞。

欢迎关注我的个人公众号：Python数据科学

数据科学学习网站：datadeepin