云河空间

Devops学习路线图

Fri, 28 Jul 2023 11:22:03 +0800

vue配置iframe父级窗口通信

Tue, 07 Feb 2023 14:42:14 +0800

在router/index.js中配置

export default new Router({
  scrollBehavior: () => ({ y: 0 }),
  routes: [
    {
      path: '/',
      name: 'index',
      component: resolve => require(['@/views/index'], resolve),
      meta: {
        keepAlive: true, // 此组件需要被缓存
        isIframe: true // 标记是否是iframe
      }
    }
  ]
})

在入口文件main.js中配置

// 判断当前路由是否需要iframe
router.beforeEach((to, from, next) => {
  if (to.meta.isIframe) {
    window.parent.postMessage({
      type: 'setIframeHeight',
      height: document.documentElement.scrollHeight
    }, '*')
  }
  next()
})

在父页面中添加

<script>
  window.addEventListener('message', function (e) {
    if (e.data.type === 'setIframeHeight') {
      document.querySelector('#iframe').height = e.data.height
    }
  })
</script>

一文读懂，DDD落地数据库设计实战

Sun, 21 Aug 2022 21:34:29 +0800

作者范钢，曾任航天信息首席架构师，《大话重构》一书的作者。本文根据具体实例详细描述了DDD 落实到数据库设计的整个过程

阅读本文之前建议先阅读上一篇文章《万字长文，结合电商支付业务一文搞懂DDD》

过去，系统的软件设计是以数据库设计为核心，当需求确定下来以后，团队首先开始进行数据库设计。因为数据库是各个模块唯一的接口，当整个团队将数据库设计确定下来以后，就可以按照模块各自独立地进行开发了，如下图所示。

在上面的过程中，为了提高团队开发速度，尽量让各个模块不要交互，从而达到各自独立开发的效果。但是，随着系统规模越来越大，业务逻辑越来越复杂，我们越来越难于保证各个模块独立不交互了。

随着软件业的不断发展，软件系统变得越来越复杂，各个模块间的交互也越来越频繁，这时，原有的设计过程已经不能满足我们的需要了。因为如果要先进行数据库设计，但数据库设计只能描述数据结构，而不能描述系统对这些数据结构的处理。因此，在第一次对整个系统的梳理过程中，只能梳理系统的所有数据结构，形成数据库设计；接着，又要再次梳理整个系统，分析系统对这些数据结构的处理过程，形成程序设计。为什么不能一次性地把整个系统的设计梳理到位呢？

现如今，我们已经按照面向对象的软件设计过程来分析设计系统了。当开始需求分析时，首先进行用例模型的设计，分析整个系统要实现哪些功能；接着进行领域模型的设计，分析系统的业务实体。在领域模型分析中，采用类图的形式，每个类可以通过它的属性来表述数据结构，又可以通过添加方法来描述对这个数据结构的处理。因此，在领域模型的设计过程中，既完成了对数据结构的梳理，又确定了系统对这些数据结构的处理，这样就把两项工作一次性地完成了。

在这个设计过程中，其核心是领域模型的设计。以领域模型作为核心，可以指导系统的数据库设计与程序设计，此时，数据库设计就弱化为了领域对象持久化设计的一种实现方式。

领域对象持久化的思想

什么叫领域对象的持久化呢？在当今软件架构设计的主流思想中，面向对象设计成了主流思想，在整个系统运行的过程中，所有的数据都是以领域对象的形式存在的。譬如：

要插入一条记录就是创建一个领域对象；
要更新一条记录就是根据 key 值去修改相应的领域对象；
删除数据则是摧毁这个领域对象。

假如我们的服务器是一台超级强大的服务器，那实际上不需要任何数据库，直接操作这些领域对象就可以了，但在现实世界中没有那么强大的服务器。因此，必须将暂时不用的领域对象持久化存储到磁盘中，而数据库只是这种持久化存储的一种实现方式。

按照这种设计思想，我们将暂时不使用的领域对象从内存中持久化存储到磁盘中。当日后需要再次使用这个领域对象时，根据 key 值到数据库查找到这条记录，然后将其恢复成领域对象，应用程序就可以继续使用它了，这就是领域对象持久化存储的设计思想。

所以，今天的数据库设计，实际上就是将领域对象的设计按照某种对应关系，转换成数据库的设计。同时，随着整个产业的大数据转型，今后的数据库设计思想也将发生巨大的转变，有可能数据库就不一定是关系型数据库了，也许是 NoSQL 数据库或者大数据平台。数据库的设计也不一定遵循 3NF（第三范式）了，可能会增加更多的冗余，甚至是宽表。

数据库设计在发生剧烈的变化，但唯一不变的是领域对象。这样，当系统在大数据转型时，可以保证业务代码不变，变化的是数据访问层（DAO）。这将使得日后大数据转型的成本更低，让我们更快地跟上技术快速发展的脚步。

领域模型的设计

此外，这里有个有趣的问题值得探讨：领域模型的设计到底是谁的职责，是需求分析人员还是设计开发人员？我认为，它是两个角色相互协作的产物。而未来敏捷开发的组织形成，团队将更加扁平化。过去是需求分析人员做需求分析，然后交给设计人员设计开发，这种方式就使得软件设计质量低下而结构臃肿。未来“大前端”的思想将支持更多设计开发人员直接参与需求分析，实现从需求分析到设计开发的一体化组织形式。这样，领域模型就成为了设计开发人员快速理解需求的利器。

总之，**DDD 的数据库设计实际上已经变成了：以领域模型为核心，如何将领域模型转换成数据库设计的过程。**那么怎样进行转换呢？在领域模型中是一个一个的类，而在数据库设计中是一个一个的表，因此就是将类转换成表的过程。

上图是一个绩效考核系统的领域模型图，该绩效考核系统首先进行自动考核，发现一批过错，然后再给一个机会，让过错责任人对自己的过错进行申辩。这时，过错责任人可以填写一张申辩申请单，在申辩申请单中有多个明细，每个明细对应一个过错行为，每个过错行为都对应了一个过错类型，这样就形成了一个领域模型。

接着，要将这个领域模型转换成数据库设计，怎么做呢？很显然，领域模型中的一个类可以转换成数据库中的一个表，类中的属性可以转换成表中的字段。但这里的关键是如何处理类与类之间的关系，如何转换成表与表之间的关系。这时候，就有 5 种类型的关系需要转换，即传统的 4 种关系 + 继承关系。

传统的 4 种关系

传统的关系包含一对一、多对一、一对多、多对多这 4 种，它们既存在于类与类之间，又存在于表与表之间，所以可以直接进行转换。

1. 一对一关系

在以上案例中，“申辩申请单明细”与“过错行为”就是一对“一对一”关系。在该关系中，一个“申辩申请单明细”必须要对应一个“过错行为”，没有一个“过错行为”的对应就不能成为一个“申辩申请单明细”。这种约束在数据库设计时，可以通过外键来实现。但是，一对一关系还有另外一个约束，那就是一个“过错行为”最多只能有一个“申辩申请单明细”与之对应。

也就是说，一个“过错行为”可以没有“申辩申请单明细”与之对应，但如果有，最多只能有一个“申辩申请单明细”与之对应，这个约束暗含的是一种唯一性的约束。因此，将过错行为表中的主键，作为申辩申请单明细表的外键，并将该字段升级为申辩申请单明细表的主键。

2. 多对一关系

是日常的分析设计中最常见的一种关系。在以上案例中，一个过错行为对应一个税务人员、一个纳税人与一个过错类型；同时，一个税务人员，或纳税人，或过错类型，都可以对应多个过错行为。它们就形成了“多对一”关系。在数据库设计时，通过外键就可以建立这种“多对一”关系。因此，我们进行了如下数据库的设计：

多对一关系在数据库设计上比较简单，然而落实到程序设计时，需要好好探讨一下。比如，以上案例，在按照这样的方式设计以后，在查询时往往需要在查询过错行为的同时，显示它们对应的税务人员、纳税人与过错类型。这时，以往的设计是增加一个 join 语句。然而，这样的设计在随着数据量不断增大时，查询性能将受到极大的影响。

也就是说，join 操作往往是关系型数据库在面对大数据时最大的瓶颈之一。因此，一个更好的方案就是先查询过错行为表，分页，然后再补填当前页的其他关联信息。这时，就需要在“过错行为”这个值对象中通过属性变量，增加对税务人员、纳税人与过错类型等信息的引用。

3. 一对多关系

该关系往往表达的是一种主-子表的关系。譬如，以上案例中的“申辩申请单”与“申辩申请单明细”就是一对“一对多”关系。除此之外，订单与订单明细、表单与表单明细，都是一对多关系。一对多关系在数据库设计上比较简单，就是在子表中增加一个外键去引用主表中的主键。比如本案例中，申辩申请单明细表通过一个外键去引用申辩申请单表中的主键，如下图所示。

除此之外，在程序的值对象设计时，主对象中也应当有一个集合的属性变量去引用子对象。如本例中，在“申辩申请单”值对象中有一个集合属性去引用“申辩申请单明细”。这样，当通过申辩申请单号查找到某个申辩申请单时，同时就可以获得它的所有申辩申请单明细，如下代码所示：

public class Sbsqd {
    private Set<SbsqdMx> sbsqdMxes;
    public void setSbsqdMxes(Set<SbsqdMx> sbsqdMxes){
          this.sbsqdMxes = sbsqdMxes;
    }
    public Set<SbsqdMx> getSbsqdMxes(){
          return this.sbsqdMxes;
    }
    ……}

4. 多对多关系

比较典型的例子就是“用户角色”与“功能权限”。一个“用户角色”可以申请多个“功能权限”；而一个“功能权限”又可以分配给多个“用户角色”使用，这样就形成了一个“多对多”关系。这种多对多关系在对象设计时，可以通过一个“功能-角色关联类”来详细描述。因此，在数据库设计时就可以添加一个“角色功能关联表”，而该表的主键就是关系双方的主键进行的组合，形成的联合主键，如下图所示：

以上是领域模型和数据库都有的 4 种关系。因此，在数据库设计时，直接将相应的关系转换成数据库设计就可以了。同时，在数据库设计时还要将它们进一步细化。如在领域模型中，不论对象还是属性，在命名时都采用中文，这样有利于沟通与理解。但到了数据库设计时，就要将它们细化为英文命名，或者汉语拼音首字母，同时还要确定它们的字段类型与是否为空等其他属性。

继承关系的 3 种设计

第 5 种关系就不太一样了：继承关系是在领域模型设计中有，但在数据库设计中却没有。如何将领域模型中的继承关系转换成数据库设计呢？有 3 种方案可以选择。

1. 继承关系的第一种方案

首先，看看以上案例。“执法行为”通过继承分为“正确行为”和“过错行为”。如果这种继承关系的子类不多（一般就 2 ~ 3 个），并且每个子类的个性化字段也不多（3 个以内）的话，则可以使用一个表来记录整个继承关系。在这个表的中间有一个标识字段，标识表中的每条记录到底是哪个子类，这个字段的前面部分罗列的是父类的字段，后面依次罗列各个子类的个性化字段。

采用这个方案的优点是简单，整个继承关系的数据全部都保存在这个表里。但是，它会造成“表稀疏”。在该案例中，如果是一条“正确行为”的记录，则字段“过错类型”与“扣分”永远为空；如果是一条“过错行为”的记录，则字段“加分”永远为空。假如这个继承关系中各子类的个性化字段很多，就会造成该表中出现大量字段为空，称为“表稀疏”。在关系型数据库中，为空的字段是要占用空间的。因此，这种“表稀疏”既会浪费大量存储空间，又会影响查询速度，是需要极力避免的。所以，当子类比较多，或者子类个性化字段多的情况是不适合该方案（第一种方案）的。

2. 继承关系的第二种方案

如果执法行为按照考核指标的类型进行继承，分为“考核指标1”“考核指标2”“考核指标3”……如下图所示：

并且每个子类都有很多的个性化字段，则采用前面那个方案就不合适了。这时，用另外两个方案进行数据库设计。其中一个方案是将每个子类都对应到一个表，有几个子类就有几个表，这些表共用一个主键，即这几个表的主键生成器是一个，某个主键值只能存在于某一个表中，不能存在于多个表中。每个表的前面是父类的字段，后面罗列各个子类的字段，如下图所示：

如果业务需求是在前端查询时，每次只能查询某一个指标，那么采用这种方案就能将每次查询落到某一个表中，方案就最合适。但如果业务需求是要查询某个过错责任人涉及的所有指标，则采用这种方案就必须要在所有的表中进行扫描，那么查询效率就比较低，并不适用。

3. 继承关系的第三种方案

如果业务需求是要查询某个过错责任人涉及的所有指标，则更适合采用以下方案，将父类做成一个表，各个子类分别对应各自的表（如图所示）。这样，当需要查询某个过错责任人涉及的所有指标时，只需要查询父类的表就可以了。如果要查看某条记录的详细信息，再根据主键与类型字段，查询相应子类的个性化字段。这样，这种方案就可以完美实现该业务需求。

综上所述，将领域模型中的继承关系转换成数据库设计有 3 种方案，并且每个方案都有各自的优缺点。因此，需要根据业务场景的特点与需求去评估，选择哪个方案更适用。

NoSQL 数据库的设计

前面我们讲的数据库设计，还是基于传统的关系型数据库、基于第三范式的数据库设计。但是，随着互联网高并发与分布式技术的发展，另一种全新的数据库类型孕育而生，那就是NoSQL 数据库。正是由于互联网应用带来的高并发压力，采用关系型数据库进行集中式部署不能满足这种高并发的压力，才使得分布式 NoSQL 数据库得到快速发展。

也正因为如此，NoSQL 数据库与关系型数据库的设计套路是完全不同的。关系型数据库的设计是遵循第三范式进行的，它使得数据库能够大幅度降低冗余，但又从另一个角度使得数据库查询需要频繁使用 join 操作，在高并发场景下性能低下。

所以，NoSQL 数据库的设计思想就是尽量干掉 join 操作，即将需要 join 的查询在写入数据库表前先进行 join 操作，然后直接写到一张单表中进行分布式存储，这张表称为“宽表”。这样，在面对海量数据进行查询时，就不需要再进行 join 操作，直接在这个单表中查询。同时，因为 NoSQL 数据库自身的特点，使得它在存储为空的字段时不占用空间，不担心“表稀疏”，不影响查询性能。

因此，NoSQL 数据库在设计时的套路就是，尽量在单表中存储更多的字段，只要避免数据查询中的 join 操作，即使出现大量为空的字段也无所谓了。

增值税发票票样图

正因为 NoSQL 数据库在设计上有以上特点，因此将领域模型转换成 NoSQL 数据库时，设计就完全不一样了。比如，这样一张增值税发票，如上图所示，在数据库设计时就需要分为发票信息表、发票明细表与纳税人表，而在查询时需要进行 4 次 join 才能完成查询。但在 NoSQL 数据库设计时，将其设计成这样一张表：

{ _id: ObjectId(7df78ad8902c)
  fpdm: '3700134140', fphm: '02309723‘, 
  kprq: '2016-1-25 9:22:45',
  je: 70451.28, se: 11976.72, 
  gfnsr: {
     nsrsbh: '370112582247803',
     nsrmc:'联通华盛通信有限公司济南分公司',…  },
  xfnsr: {
     nsrsbh: '370112575587500',
     nsrmc:'联通华盛通信有限公司济南分公司',…  },
  spmx: [
     { qdbz:'00', wp_mc:'蓝牙耳机 车语者S1 蓝牙耳机', sl:2, dj:68.37,… },
     { qdbz:'00', wp_mc:'车载充电器 新在线', sl:1, dj:11.11,… },
     { qdbz:'00', wp_mc:'保护壳 非尼膜属 iPhone6 电镀壳', sl:1, dj:24,…  }
  ]}

在该案例中，对于“一对一”和“多对一”关系，在发票信息表中通过一个类型为“对象”的字段来存储，比如“购方纳税人（gfnsr）”与“销方纳税人（xfnsr）”字段。对于“一对多”和“多对多”关系，通过一个类型为“对象数组”的字段来存储，如“商品明细（spmx）”字段。在这样一个发票信息表中就可以完成对所有发票的查询，无须再进行任何 join 操作。

同样，采用 NoSQL 数据库怎样实现继承关系的设计呢？由于 NoSQL 数据库自身的特点决定了不用担心“表稀疏”，同时要避免 join 操作，所以比较适合采用第一个方案，即将整个继承关系放到同一张表中进行设计。这时，NoSQL 数据库的每一条记录可以有不一定完全相同的字段，可以设计成这样：

{ _id: ObjectId(79878ad8902c),
  name: ‘Jack’,
  type: ‘parent’,
  partner: ‘Elizabeth’,
  children: [
    { name: ‘Tom’, gender: ‘male’ },
    { name: ‘Mary’, gender: ‘female’}
  ]},{ _id: ObjectId(79878ad8903d),
  name: ‘Bob’,
  type: ‘kid’,
  mother: ‘Anna’,
  father: ‘David’}

以上案例是一个用户档案表，有两条记录：Jack 与 Bob。但是，Jack 的类型是“家长”，因此其个性化字段是“伴侣”与“孩子”；而 Bob 的类型是“孩子”，因此他的个性化字段是“父亲”与“母亲”。显然，在 NoSQL 数据库设计时就会变得更加灵活。

总结

将领域模型落地到系统设计包含 2 部分内容，本文演练了第一部分内容——从 DDD 落实到数据库设计的整个过程：传统的 4 种关系可以直接转换；继承关系有 3 种设计方案；转换成 NoSQL 数据库则是完全不同的思路。

有了 DDD 的指导，可以帮助我们理清数据间的关系，以及对数据的操作。不仅如此，在未来面对大数据转型时更加从容。

号主简介：冯涛，曾任职于阿里巴巴，每日优鲜等互联网公司，任技术总监，15年电商互联网经历。

devops三十六计

Sat, 09 Apr 2022 18:11:38 +0800

Linux Kernel map

Sat, 09 Apr 2022 18:05:58 +0800

运维工具体系

Sat, 09 Apr 2022 18:03:09 +0800

公共DNS

Sat, 26 Mar 2022 09:53:12 +0800

阿里云：
223.6.6.6
223.5.5.5

百度：
180.76.76.76

联通：
123.125.81.6
218.30.118.6

114：
114.114.114.114

附：

地区    主服务器    备服务器    
北京联通DNS    202.106.196.115    202.106.46.151    
202.106.0.20    202.106.195.68    
重庆联通DNS    221.5.203.98    221.7.92.98    
广东联通DNS    210.21.196.6    221.5.88.88    
河北联通DNS    202.99.160.68    202.99.166.4    
河南联通DNS    202.102.224.68    202.102.227.68    
黑龙江联通DNS    202.97.224.69    202.97.224.68    
吉林联通DNS    202.98.0.68    202.98.5.68    
江苏联通DNS    221.6.4.66    221.6.4.67    
内蒙古联通DNS    202.99.224.68    202.99.224.8    
山东联通DNS    202.102.128.68    202.102.152.3    
202.102.134.68    202.102.154.3    
山西联通DNS    202.99.192.66    202.99.192.68    
陕西联通DNS    221.11.1.67    221.11.1.68    
上海联通DNS    210.22.70.3    210.22.84.3    
四川联通DNS    119.6.6.6    124.161.87.155    
天津联通DNS    202.99.104.68    202.99.96.68    
浙江联通DNS    221.12.1.227    221.12.33.227


中国公共dns
百科 >中国公共dns
说明：
阿里、腾讯dns不错；谷歌的8.8.8.8虽然不错，但国内访问确实不稳定，还会碰到解析记录更新不及时问题；114之前试了，正常用挺好的，但如果公司访问非常多的情况下，怀疑限频阈值较低，有时会解析不了。

为什么要用公共dns呢？那是因为使用了多家运营商商务宽带，但各运营商dns要嘛限制只对自家网络开放，要嘛限频限得非常低。这时候就需要用公共dns了，当然自己在公网内网搭建dns更好。

具体：
阿里公共DNS 
阿里公共DNS是阿里巴巴集团推出的DNS递归解析系统，目标是成为国内互联网基础设施的组成部分，面向互联网用户提供“快速”、“稳定”、“智能”的免费DNS递归解析服务.
官网：https://www.alidns.com/
IPv4首选：223.5.5.5
IPv4备用：223.6.6.6
IPv6首选：2400:3200::1
IPv6备用：2400:3200:baba::1

腾讯公共DNS（同DNSPod）
腾讯公共DNS是腾讯DNSPod 提供的公共 DNS 服务，基于 BGP AnyCast，支持 edns-client-subnet 技术，精准调度，多地集群容灾，面向所有互联网用户免费使用。
官网：https://www.dnspod.cn/Products/Public.DNS
IPv4首选：119.29.29.29
IPv4备用：
IPv6首选：
IPv6备用：


百度公共DNS
百度公共DNS是百度系统部推出的递归DNS解析服务。拥有云防护、无劫持、更精准等特性,让您上网更快更安全。
官网：https://dudns.baidu.com/intro/publicdns/
IPv4首选：180.76.76.76
IPv4备用：
IPv6首选：2400:da00::6666
IPv6备用：

谷歌公共DNS（Google Public DNS）
Google Public DNS 是Google面对大众推出的一个公共免费域名解析服务。
官网：https://developers.google.com/speed/public-dns
IPv4首选：8.8.8.8
IPv4备用：8.8.4.4
IPv6首选：2001:4860:4860::8888
IPv6备用：2001:4860:4860::8844

114DNS：
114DNS是由多个基础电信运营商与南京信风共建共享，但由南京信风提供技术支持的公共DNS。
官网：https://www.114dns.com/about.html
IPv4首选：114.114.114.114
IPv4备用：114.114.115.115
IPv6首选：
IPv6备用：

附录：
中国电信各地DNS服务器，https://www.66office.com/article.php?id=267
中国联通各地DNS服务器，https://www.66office.com/article.php?id=266

最常用的架构模式

Tue, 08 Mar 2022 19:00:56 +0800

观其设计知其人
A MAN is KNOWN by the DESIGN he keeps

原文:Most Useful Software Architecture Patterns by Shadman Jamil

分层模式 (Layered Pattern (n-tier))

分层架构模式是最常见的模式之一。分层模式背后的理念是，具有相同功能的组件将被组织成水平层。因此，每一层在应用程序中都扮演着特定的角色。

在这种模式中，我们对应用程序可以拥有的层数没有限制。在这方面，我们还提倡关注点分离的概念。分层模式风格抽象了整个软件的视图；同时提供足够的细节，以了解各个层的角色和职责以及它们之间的关系。分层模式的典型实现如下：

UI展示层(UI / Presentation Layer): 渲染并运行用户界面，向服务器应用程序发送请求。
应用层(Application Layer): 包含表示层、应用程序层、域对象层和持久化层。
域对象层/业务层(Domain / Business Layer): 该层包含所有业务逻辑、实体、事件和其他包含业务逻辑的对象类型。
数据库层(Database Layer): 这是数据层，用于持久化数据，应用服务器将使用这些数据。

例子: 桌面应用程序、电子商务、web应用程序等。

参考例子： go-clean-arch

客户端-服务器模式 (Client-Server Pattern)

这是最简单的架构模式，由一台服务器和多个客户端组成。这种模式是一种分布式架构，在资源/服务的提供者（称为服务器）和服务请求者（称为客户端）之间划分任务/工作负载。

在客户端-服务器模式中，当客户端向服务器发送数据请求时，服务器接受请求的进程，并向客户机发送所需的数据。客户不共享他们的任何资源。

例子: Email、文档共享、银行等

事件总线模式 (Event-Bus Pattern (Event-Driven Architecture))

该模式是一种分布式异步体系架构模式，用于创建高度可扩展的响应式应用程序。适用于从小型到复杂的各级应用程序技术栈。此模式的主要思想是异步传递和处理事件。

这个模式包含四个组件:

事件源(Event Source)
事件监听器(Event Listener)
通道(Channel)
事件总线(Event Bus)

源将消息发布到事件总线上的特定通道。监听器订阅特定的频道，监听器可以获取发布到其订阅的频道的消息。

例子: 电子商务、手机应用程序、通知服务等

代理人模式(Broker Pattern)

此模式可用于构造具有通过远程服务调用进行交互的解耦组件的分布式系统。代理组件负责协调组件之间的通信；例如转发请求，以及传输结果和异常。

服务器将其能力（服务和特性）发布给代理(Broker)。客户端向代理请求服务，然后代理将客户端的请求重定向到合适的服务。

例子: 消息Broker程序，如Apache ActiveMQ、Apache Kafka、RabbitMQ、JBOSS Messaging等

微服务模式 (Microservices Pattern)

在这种模式中，服务通过使用HTTP/REST等同步协议或AMQP（高级消息队列协议）等异步协议进行通信。服务可以独立开发和部署，每个服务都有自己的数据库。服务之间的数据一致性是通过使用Saga模式（一系列本地事务）来维护的。

例子: 可以在许多用例上实现，尤其是广泛的数据管道处理上

点对点模式 (Peer-to-Peer Pattern)

在通用客户端-服务器体系架构中，多个客户端与中央服务器通信。但P2P模式由分散的对等网络组成。

在这种模式中，节点的行为类似于客户端和服务器。对等点既可以作为客户端向其他对等点请求服务，也可以作为服务器向其他对等点提供服务。

P2P网络在节点之间分配工作负载，所有节点贡献并消耗网络中的资源，而不需要集中的服务器。对等方可能会随着时间动态地改变其角色。

例子: 文件分享网络、多媒体协议PDTP,P2PTV、比特币、区块链等

黑板模式(Blackboard Pattern)

这种模式对于不知道确定性解决方案策略的问题很有用。

所有部件都可以接触到黑板。组件可能会产生新的数据对象，这些对象将被添加到黑板上。组件在黑板上寻找特定类型的数据，并通过与现有知识源的模式匹配找到这些数据。

这个模式包含三个组件：

黑板(blackboard): 含解决方案空间中的对象的结构化全局内存
知识源(knowledge source:):具有自己表示形式的专用模块
控制组件(control component):选择、配置和执行模块。

例子: 速度识别、蛋白质结构识别、声纳信号解释、机器学习程序等。

组件模式 (Component-based Pattern)

基于组件的软件工程（Component-based software engineering，简称CBSE）或基于组件的开发（Component-Based Development，简称CBD）是针对系统的广泛功能，进行关注点分离的软件工程方式。此方式是以复用为基础的作法，定义、实现许多松耦合的独立组件（Component），再将组件组合成为系统。此作法的目的是希望在软件本身的短期益处以及开发软件组织的长期益处之间获取平衡。

一旦组件进行了划分，可以将组件分布式的开发部署，就会演化成面向服务或者微服务的架构。

例子: 常见大型项目中或者单个服务中。

管道模式 (Pipes 和 filters)

管道(pipeline)由一系列处理元素（进程、线程、协同程序、函数等）组成，每个元素的输出都是下一个元素的输入；这个名字类似于一个物理管道。通常在连续元素之间提供一定量的缓冲。在这些管道中流动的信息通常是记录流、字节流或比特流，管道中的元素可以称为过滤器(filter)；这也称为管道和过滤器设计模式。将元素连接到管道中类似于函数合成。

管道模式可以将数据的处理解耦，并且可以动态的增加或者删除特定的处理流程。每个处理单元可以结合下面插件模式，实现定制化。

例子: 多任务操作系统、数据处理程序等。

插件模式

在计算技术中，插件（或插件、外接程序、外接程序、外接程序或外接程序）是一种软件组件，用于向现有计算机程序添加特定功能。当程序支持插件时，它会启用自定义功能。

插件模式可以方便对程序进行扩展，以及动态实现功能的开启和禁用等功能，方便进行定制化。

例子: IDE程序如Eclipse，IDEA Intellj、网络应用程序入netty等。

什么是“堆”,"栈","堆栈","队列",它们的区别

Fri, 11 Feb 2022 19:04:32 +0800

如果你学过数据结构，就一定会遇到“堆”,"栈","堆栈","队列"，而最关键的是这些到底是什么意思？最关键的是即使你去面试，这些都还会问到，所以如果你不懂对你是损失很大的。

堆栈都是一种数据项按序排列的数据结构，只能在一端(称为栈顶(top))对数据项进行插入和删除。

要点：堆：顺序随意 栈：后进先出(Last-In/First-Out)

堆

堆：什么是堆？又该怎么理解呢？

①堆通常是一个可以被看做一棵树的数组对象。堆总是满足下列性质：

·堆中某个节点的值总是不大于或不小于其父节点的值；

·堆总是一棵完全二叉树。

将根节点最大的堆叫做最大堆或大根堆，根节点最小的堆叫做最小堆或小根堆。常见的堆有二叉堆、斐波那契堆等。

②堆是在程序运行时，而不是在程序编译时，申请某个大小的内存空间。即动态分配内存，对其访问和对一般内存的访问没有区别。

③堆是应用程序在运行的时候请求操作系统分配给自己内存，一般是申请/给予的过程。

④堆是指程序运行时申请的动态内存，而栈只是指一种使用堆的方法(即先进后出)。

栈

栈：什么是栈？又该怎么理解呢？

①栈（stack）又名堆栈，它是一种运算受限的线性表。其限制是仅允许在表的一端进行插入和删除运算。这一端被称为栈顶，相对地，把另一端称为栈底。

②栈就是一个桶，后放进去的先拿出来，它下面本来有的东西要等它出来之后才能出来（先进后出）

③栈(Stack)是操作系统在建立某个进程时或者线程（在支持多线程的操作系统中是线程）为这个线程建立的存储区域，该区域具有FIFO的特性，在编译的时候可以指定需要的Stack的大小。

堆栈

堆栈：什么是堆栈？又该怎么理解呢？

注意：其实堆栈本身就是栈，只是换了个抽象的名字。

堆栈的特性：最后一个放入堆栈中的物体总是被最先拿出来，这个特性通常称为后进先出(LIFO)队列。堆栈中定义了一些操作。两个最重要的是PUSH和POP。 PUSH操作在堆栈的顶部加入一个元素。POP操作相反，在堆栈顶部移去一个元素，并将堆栈的大小减一。

总结：

堆、栈区别总结：

1.堆栈空间分配

①栈（操作系统）：由操作系统自动分配释放，存放函数的参数值，局部变量的值等。其操作方式类似于数据结构中的栈。

②堆（操作系统）：一般由程序员分配释放，若程序员不释放，程序结束时可能由OS回收，分配方式倒是类似于链表。

2.堆栈缓存方式

①栈使用的是一级缓存，他们通常都是被调用时处于存储空间中，调用完毕立即释放。

②堆则是存放在二级缓存中，生命周期由虚拟机的垃圾回收算法来决定（并不是一旦成为孤儿对象就能被回收）。所以调用这些对象的速度要相对来得低一些。

3.堆栈数据结构区别

①堆（数据结构）：堆可以被看成是一棵树，如：堆排序。

②栈（数据结构）：一种先进后出的数据结构。

队列：

队列：什么是队列？又该怎么理解呢？

①队列是一种特殊的线性表，特殊之处在于它只允许在表的前端（front）进行删除操作，而在表的后端（rear）进行插入操作，和栈一样，队列是一种操作受限制的线性表。进行插入操作的端称为队尾，进行删除操作的端称为队头。

②队列中没有元素时，称为空队列。

③建立顺序队列结构必须为其静态分配或动态申请一片连续的存储空间，并设置两个指针进行管理。一个是队头指针front，它指向队头元素；另一个是队尾指针rear，它指向下一个入队元素的存储位置。

④队列采用的FIFO(first in first out)，新元素（等待进入队列的元素）总是被插入到链表的尾部，而读取的时候总是从链表的头部开始读取。每次读取一个元素，释放一个元素。所谓的动态创建，动态释放。因而也不存在溢出等问题。由于链表由结构体间接而成，遍历也方便。（先进先出）

区别:

堆、栈、队列之间的区别是？

①堆是在程序运行时，而不是在程序编译时，申请某个大小的内存空间。即动态分配内存，对其访问和对一般内存的访问没有区别。

②栈就是一个桶，后放进去的先拿出来，它下面本来有的东西要等它出来之后才能出来。（后进先出）

③队列只能在队头做删除操作,在队尾做插入操作.而栈只能在栈顶做插入和删除操作。（先进先出）

Vue 加载本地Excel实时预览

Mon, 24 Jan 2022 19:40:49 +0800

#template

<template>
   <div>
        <input type="file" id="files" ref="upload" accept=".xls,.xlsx" style="display: none">
        <el-button slot="trigger" type="warning" @click="clickLoad" style="margin-right: 20px">从Excel加载</el-button>
   </div>
</template>


methods(){
    clickLoad() {
      this.$refs.upload.dispatchEvent(new MouseEvent('click'))
    },
    readExcel(e) {//表格导入
      let that = this;
      const files = e.target.files;
      let validRule = /\.(xls|xlsx)$/
      if (files.length <= 0) {//如果没有文件名
        return false;
      } else if (!validRule.test(files[0].name.toLowerCase())) {
        this.$Message.error('上传格式不正确，请上传xls或者xlsx格式');
        return false;
      }
      const fileReader = new FileReader();
      fileReader.onload = (e) => {
        try {
          const data = e.target.result;
          const workData = XLSX.read(data, {
            type: 'binary'
          });
          // console.log(workData)// 文件的内容
          const wsName = workData.SheetNames[0];//取第一张表
          const ws = XLSX.utils.sheet_to_json(workData.Sheets[wsName]);//生成json表格内容
          // console.log(ws);  //自第二行开始的内容
          //{  这里可以做相应的处理 }
          //{  这里可以做相应的处理 }
          // console.log("table:", this.tablesData)
          for (let i = 0; i < this.tablesData.length; i++) {
            let item = this.tablesData[i]
            let allKey = Object.keys(item)
            for (let j = 0; j < ws.length; j++) {
              let item2 = ws[j]
              let key1 = item['a'] + "_" + item['b'] + "_" + item['c']
              let key2 = item2['a'] + "_" + item2['b'] + "_" + item2['c']
              if (key1 === key2) {
                for (let key of allKey) {
                  //只对20开头的key做值更新
                  if (key.indexOf("20") === 0) {
                    console.log("key1:", key1, "key2:", key2, "key:", key, "value:", item2[key])
                    this.$set(this.tablesData[i], key, item2[key])
                  }
                }
              }
            }
          }
          this.$refs.upload.value = ''; // 处理完成 清空表单值
        } catch (e) {
          this.$message.error("解析表格失败")
          return false;
        }
      };
      fileReader.readAsBinaryString(files[0]);
    }

},

mounted(){
    //注册事件
    this.$refs.upload.addEventListener('change', e => {
          this.readExcel(e)
    })
}