一.前言

hello，everyone，好久不见。最近几周部门有个大版本发布，一直没有抽出时间来写博。由于版本不断迭代，功能越做越复杂，系统的维护与功能迭代越来越困难。前段领导找我说，能不能在架构上动手做做文章，将架构迁移到DDD。哈哈哈哈，当时我听到这个话的时候瞬间来了精神。说实话，从去年开始从大厂的一些朋友那里接触到DDD，自己平时也会时不时的阅读相关的文章与开源项目，但是一直没有机会在实际的工作中实施。正好借着这次机会可以开始实践一下。

本文由于本文的重点为MVC三层架构如何迁移DDD，因此将先对DDD做一个简要的概念介绍(细化的领域概念不做过多展开),然后对于MVC三层架构迁移至DDD作出迁移方案建议。如有不对之处，欢迎指出，共同进步。

本文尤其感谢一下lilpilot在DDD落地方案上给出的宝贵建议。

DDD系列博客

1. 一文带你落地DDD
   


2. DDD落地之事件驱动模型
   


3. DDD落地之仓储
   


4. DDD落地之架构分层

二.DDD是什么

2.1.DDD简介

相信了解过DDD的同学都听过网上那种官方的介绍：

• 
  

  Domain Drive Design（领域驱动设计）

  
  


• 
  

  六边形架构模型

  
  


• 
  

  领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具

  
  


• 
  

  ....

  
  

  说的都多多少少抽象点了，听君一席话，如听一席话，哈哈哈

  
  

在我看来常规在MVC三层架构中，我们进行功能开发的之前，拿到需求，解读需求。往往最先做的一步就是先设计表结构，在逐层设计上层dao，service，controller。对于产品或者用户的需求都做了一层自我理解的转化。

众所周知，人才是系统最大的bug。

用户需求在被提出之后经过这么多层的转化后，特别是研发需求在数据库结构这一层转化后，将业务以主观臆断行为进行了转化。一旦业务边界划分模糊，考虑不全。大量的逻辑补充堆积到了代码层实现，变得越来越难维护，到处是if/else，传说中***一样代码。

DDD所要做的就是

• 消除信息不对称


• 常规MVC三层架构中自底向上的设计方式做一个反转，以业务为主导，自顶向下的进行业务领域划分


• 将大的业务需求进行拆分，分而治之

说到这里大家可能还是有点模糊DDD与常见的mvc架构的区别。这里以电商订单场景为例。假如我们现在要做一个电商订单下单的需求。涉及到用户选定商品，下订单，支付订单，对用户下单时的订单发货。

MVC架构里面，我们常见的做法是在分析好业务需求之后，就开始设计表结构了，订单表，支付表，商品表等等。然后编写业务逻辑。这是第一个版本的需求，功能迭代饿了，订单支付后我可以取消，下单的商品我们退换货，是不是又需要进行加表，紧跟着对于的实现逻辑也进行修改。功能不断迭代，代码就不断的层层往上叠。

DDD架构里面，我们先进行划分业务边界。这里面核心是订单。那么订单就是这个业务领域里面的聚合逻辑体现。支付，商品信息，地址等等都是围绕着订单而且。订单本身的属性决定之后，类似于地址只是一个属性的体现。当你将订单的领域模型构建好之后，后续的逻辑边界与仓储设计也就随之而来了。

2.2.为什么要用DDD

• 面向对象设计，数据行为绑定，告别贫血模型


• 降低复杂度，分而治之


• 优先考虑领域模型，而不是切割数据和行为


• 准确传达业务规则，业务优先


• 代码即设计


• 它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，可以很容易地实现业务和技术统一的架构演进


• 领域知识共享，提升协助效率


• 增加可维护性和可读性，延长软件生命周期


• 中台化的基石

2.3.DDD术语介绍

战略设计：限界上下文、通用语言，子域

战术设计：聚合、实体、值对象、资源库、领域服务、领域事件、模块

2.3.1.限界上下文与通用语言

限界上下文是一个显式的语义和语境上的边界，领域模型便存在于边界之内。边界内，通用语言中的所有术语和词组都有特定的含义。

通用语言就是能够简单、清晰、准确描述业务涵义和规则的语言。

把限界上下文拆解开看。限界就是领域的边界，而上下文则是语义环境。 通过领域的限界上下文，我们就可以在统一的领域边界内用统一的语言进行交流。

域是问题空间，限界上下文是解决空间

2.3.2.上下文组织和集成模式

防腐层(Anticorruption Layer)：简称ACL，在集成两个上下文，如果两边都状态良好，可以引入防腐层来作为两边的翻译，并且可以隔离两边的领域模型。

2.3.3.实体

DDD中要求实体是唯一的且可持续变化的。意思是说在实体的生命周期内，无论其如何变化，其仍旧是同一个实体。唯一性由唯一的身份标识来决定的。可变性也正反映了实体本身的状态和行为。

实体 = 唯一身份标识 + 可变性【状态 + 行为】

2.3.4.值对象

当你只关心某个对象的属性时，该对象便可作为一个值对象。 我们需要将值对象看成不变对象，不要给它任何身份标识，还应该尽量避免像实体对象一样的复杂性。

值对象=将一个值用对象的方式进行表述，来表达一个具体的固定不变的概念。

2.3.5.聚合

聚合是领域对象的显式分组，旨在支持领域模型的行为和不变性，同时充当一致性和事务性边界。

我们把一些关联性极强、生命周期一致的实体、值对象放到一个聚合里。

2.3.6.聚合根

聚合的根实体，最具代表性的实体

2.3.7.领域服务

当一些逻辑不属于某个实体时，可以把这些逻辑单独拿出来放到领域服务中 理想的情况是没有领域服务，如果领域服务使用不恰当慢慢又演化回了以前逻辑都在service层的局面。

可以使用领域服务的情况：

• 执行一个显著的业务操作


• 对领域对象进行转换


• 以多个领域对象作为输入参数进行计算，结果产生一个值对象

2.3.8.应用服务

应用服务是用来表达用例和用户故事的主要手段。

应用层通过应用服务接口来暴露系统的全部功能。 在应用服务的实现中，它负责编排和转发，它将要实现的功能委托给一个或多个领域对象来实现，它本身只负责处理业务用例的执行顺序以及结果的拼装。通过这样一种方式，它隐藏了领域层的复杂性及其内部实现机制。

应用层相对来说是较“薄”的一层，除了定义应用服务之外，在该层我们可以进行安全认证，权限校验，持久化事务控制，或者向其他系统发生基于事件的消息通知，另外还可以用于创建邮件以发送给客户等。

应用层作为展现层与领域层的桥梁。展现层使用VO（视图模型）进行界面展示，与应用层通过DTO（数据传输对象）进行数据交互，从而达到展现层与DO（领域对象）解耦的目的。

2.3.9.工厂

职责是创建完整的聚合

• 工厂方法


• 工厂类

领域模型中的工厂

• 将创建复杂对象和聚合的职责分配给一个单独的对象，它并不承担领域模型中的职责，但是领域设计的一部份


• 对于聚合来说，我们应该一次性的创建整个聚合，并且确保它的不变条件得到满足


• 工厂只承担创建模型的工作，不具有其它领域行为


• 一个含有工厂方法的聚合根的主要职责是完成它的聚合行为


• 在聚合上使用工厂方法能更好的表达通用语言，这是使用构造函数所不能表达的

聚合根中的工厂方法

• 聚合根中的工厂方法表现出了领域概念


• 工厂方法可以提供守卫措施

领域服务中的工厂

• 在集成限界上下文时，领域服务作为工厂


• 领域服务的接口放在领域模型内，实现放在基础设施层

2.3.10.资源库【仓储】

是聚合的管理，仓储介于领域模型和数据模型之间，主要用于聚合的持久化和检索。它隔离了领域模型和数据模型，以便我们关注于领域模型而不需要考虑如何进行持久化。

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

2.3.11.事件模型

领域事件是一个领域模型中极其重要的部分，用来表示领域中发生的事件。忽略不相关的领域活动，同时明确领域专家要跟踪或希望被通知的事情，或与其他模型对象中的状态更改相关联

领域事件 = 事件发布 + 事件存储 + 事件分发 + 事件处理。

比如下订单后，给用户增长积分与赠送优惠券的需求。如果使用瀑布流的方式写代码。一个个逻辑调用，那么不同用户，赠送的东西不同，逻辑就会变得又臭又长。这里的比较好的方式是，用户下订单成功后，发布领域事件，积分聚合与优惠券聚合监听订单发布的领域事件进行处理。

2.4.DDD架构总览

2.4.1.架构图

严格分层架构:某层只能与直接位于的下层发生耦合。

松散分层架构:允许上层与任意下层发生耦合

依赖倒置原则

高层模块不应该依赖于底层模块，两者都应该依赖于抽象

抽象不应该依赖于实现细节，实现细节应该依赖于接口

简单的说就是面向接口编程。

按照DIP的原则，领域层就可以不再依赖于基础设施层，基础设施层通过注入持久化的实现就完成了对领域层的解耦，采用依赖注入原则的新分层架构模型就变成如下所示：

从上往下

第一层为用户交互层，web请求，rpc请求，mq消息等外部输入均被视为外部输入的请求，可能修改到内部的业务数据。

第二层为业务应用层，与MVC中的service不同的不是，service中存储着大量业务逻辑。但在应用服务的实现中（以功能点为维度），它负责编排、转发、校验等。

第三层为领域层，聚合根是里面最高话事人。核心逻辑均在聚合根中体现【充血模型】，如果当前聚合根不能处理当前逻辑，需要其他聚合根的配合时，则在聚合根的外部包一层领域服务去实现逻辑。当然，理想的情况是不存在领域服务的。

第四层为基础设施层，为其他层提供技术实现支持

相信这里大家还看见了应用服务层直接调用仓储层的一条线，这条线是什么意思呢？

领域模型的建立是为了控制对于数据的增删改的业务边界，至于数据查询，不同的报表，不同的页面需要展示的数据聚合不具备强业务领域，因此常见的会使用CQRS方式进行查询逻辑的处理。

2.4.2.六边形架构(端口与适配器)

对于每一种外界类型，都有一个适配器与之对应。外界接口通过应用层api与内部进行交互。

对于右侧的端口与适配器，我们可以把资源库看成持久化的适配器。

2.4.3.命令和查询职责分离--CQRS

• 一个对象的一个方法修改了对象的状态，该方法便是一个命令(Command)，它不应该返回数据，声明为void。


• 一个对象的一个方法如果返回了数据，该方法便是一个查询(Query)，不应该通过直接或者间接的手段修改对象状态。


• 聚合只有Command方法，没有Query方法。


• 资源库只有add/save/fromId方法。


• 领域模型一分为二，命令模型(写模型)和查询模型(读模型)。


• 客户端和查询处理器 客户端：web浏览器、桌面应用等 查询处理器：一个只知道如何向数据库执行基本查询的简单组件，查询处理器不复杂，可以返回DTO或其它序列化的结果集，根据系统状态自定


• 查询模型：一种非规范化的数据模型，并不反映领域行为，只用于数据显示


• 客户端和命令处理器 聚合就是命令模型 命令模型拥有设计良好的契约和行为，将命令匹配到相应的契约是很直接的事情


• 事件订阅器更新查询模型


• 处理具有最终一致性的查询模型

2.4.4.事件驱动架构

落地指导与实践：DDD落地之事件驱动模型

• 
  

  事件驱动架构可以融入六边型架构，融合的比较好，也可以融入传统分层架构

  
  


• 
  

  管道和过滤器

  
  


• 
  

  长时处理过程

  
  
  
  
  1. 主动拉取状态检查：定时器和完成事件之间存在竞态条件可能造成失败
  
  
  2. 被动检查，收到事件后检查状态记录是否超时。问题：如果因为某种原因，一直收不到事件就一直不过期
  
  
  
  


• 
  

  事件源

  
  
  
  
  1. 对于聚合的每次命令操作，都至少一个领域事 件发布出去，表示操作的执行结果
  
  
  2. 每一个领域事件都将被保存到事件存储中
  
  
  3. 从资源库获取聚合时，将根据发生在聚合上的 事件来重建聚合，事件的重放顺序与其产生顺序相同
  
  
  4. 聚合快照：将聚合的某一事件发生时的状态快 照序列化存储下来。以减少重放事件时的耗时
  
  
  
  

三.落地分享

3.1.事件风暴

EventStorming则是一套Workshop（可以理解成一个类似于头脑风暴的工作坊）方法。DDD出现要比EventStorming早了10多年，而EventStorming的设计虽然参考了DDD的部分内容，但是并不是只为了DDD而设计的，是一套独立的通过协作基于事件还原系统全貌，从而快速分析复杂业务领域，完成领域建模的方法。

针对老系统内的业务逻辑，根据以上方式进行业务逻辑聚合的划分

例如电商场景下购车流程进行事件风暴

3.2.场景识别

事件风暴结束明确业务聚合后，进行场景识别与层级划分

3.3.包模块划分

3.4.迁移说明

3.4.1.仓储层

在我们日常的代码中，使用Repository模式是一个很简单，但是又能得到很多收益的事情。最大的收益就是可以彻底和底层实现解耦，让上层业务可以快速自发展。

以目前逆向模型举例，现有

• OrderDO


• OrderDAO

可以通过以下几个步骤逐渐的实现Repository模式：

1. 生成Order实体类，初期字段可以和OrderDO保持一致


2. 生成OrderDataConverter，通过MapStruct基本上2行代码就能完成


3. 写单元测试，确保Order和OrderDO之间的转化100%正确


4. 生成OrderRepository接口和实现，通过单测确保OrderRepository的正确性


5. 将原有代码里使用了OrderDO的地方改为Order


6. 将原有代码里使用了OrderDAO的地方都改为用OrderRepository


7. 通过单测确保业务逻辑的一致性。

有一点要注意，目前我们用mybatis，dao操作都是含有业务含义的，正常的repository不应该有这种方法，目前repository中的含有业务含义的方法只是兼容方案，最终态都要干掉的。

极端DDD推崇者要求在repository中只存在save与byId两个聚合方法。这个当然需要根据实际业务场景来决定，但是还是建议仅保存这两个方法，其他业务需求查询聚合的方法单独开一个queryRepository实现不同数据的查询聚合与页面数据展示。保证数据的增删改入口唯一

3.4.2. 隔离三方依赖-adapter

思想和repository是一致的，以调用payApi为例：

1. 在domain新建adapter包


2. 新建PayAdapter接口


3. 在infrastructure中定义adapter的实现，转换内部模型和外部模型，调用pay接口，返回内部模型dto


4. 将原先业务中调用rpc的地方改成adapter


5. 单测对比rpc和adapter，保证正确性

3.4.3. 抽离技术组件

同样是符合六边形架构的思想，把mqProducer，JsonUtil等技术组件，在domain定义接口，在infrastructure写实现，替换步骤和adapter类似。

3.4.4. 业务流程模块化-application

如果是用能力链的项目，能力链的service就可以是application。如果原先service中的业务逻辑混杂，甚至连参数组装都是在service中体现的。那么需要把逻辑归到聚合根中，当前聚合根无法完全包裹的，防止在领域模型中体现。在应用服务层中为能力链的体现。

3.4.5. CQRS参数显式化

能力链项目，定义command，query包，通过能力链来体现Command，Query，包括继承CommandService、QueryService，Po继承CommandPo，QueryPo

非能力链项目，在application定义command，query包，参数和类名要体现CQRS。

3.4.6. 战略设计-domain

重新设计聚合和实体，可能和现有模型有差异，如果模型差距不大，直接将能力点内的逻辑，迁移到实体中，

将原来调用repository的含业务含义的方法，换成save，同时删除含业务含义的方法，这个时候可以考虑用jpa替换mybatis，这里就看各个子域的选择了，如果用jpa的话 dao层可以干掉。至此，原biz里的大多数类已迁移完成。

四.迁移过程中可能存在的疑问

迁移过程中一定会存在或多或少不清楚的地方，这里我分享一下我在迁移的过程中遇到的问题。

1.领域服务与应用服务的实际应用场景区别

应用服务：可以理解为是各种方法的编排，不会处理任务业务逻辑，比如订单数修改，导致价格变动，这个逻辑体现在聚合根中，应用服务只负责调用。

领域服务：聚合根本身无法完全处理这个逻辑，例如支付这个步骤，订单聚合不可能支付，所以在订单聚合上架一层领域服务，在领域服务中实现支付逻辑。应用服务调用领域服务。

2.聚合根定义的业务边界是什么？

不以表结构数据进行业务逻辑的划分，一个业务体为一块业务。比如一个订单涉及商品，收货地址，发货地址，个人信息等等。以实体与值对象的方式在聚合内进行定义。

3.一个command修改一个聚合时，会关联修改到别的关联表，这个关联表算不算聚合

关联表不算聚合，算值对象

4.应用服务层如果调用rpc是否必须使用adapter

是的，必须使用，屏蔽外部依赖对于当前业务逻辑的影响。设想一下，你现在需要调用rpc接口，返回的字段有100，你要取其中50个字段。隔了一段时间，调用方改了接口逻辑的返回，数据被包含在实体内。而你调用这个接口的地方特别多，改动就很大了。但是如果有了适配器这一层，你只要定义本身业务需要的数据结构，剩下的业务不需要考虑，完全新人适配器可以将你想要的数据从rpc中加载到。

5.聚合根内部逻辑无法单独处理时，放到领域服务内的话，是否可以调用其他聚合根的领域服务或者应用服务，加入业务强绑定形式，聚合根内部如果需要调用service服务或者仓储时如何做。

可以这么做，但是逻辑要保证尽量内聚。

6.事件通知模式，比如是强绑定形式的，是否还是此种方式，还是与本聚合根无关的逻辑均走事件通知

强依赖形式的走逻辑编排，比如订单依赖支付结果进行聚合修改则走应用服务编排。订单支付后发送优惠券，积分等弱耦合方式走事件通知模式。

7.聚合根，PO,DTO,VO的限界

po是数据库表结构的一一对应。

dto是数据载体，贫血模型，仅对数据进行装载。

vo为dto结构不符合前端展示要求时的包装。

聚合根为一个或者多个po的聚合数据，当然不仅仅是po的组合，还有可能是值对象数据，充血模型，内聚核心业务逻辑处理。

8.查询逻辑单独开设一个repository，还是可以在聚合根的仓储中，划分的依据是什么

单独开设一个仓储。聚合根的仓储应该查询结果与save的参数均为聚合根，但是业务查询可能多样，展示给前端的数据也不一定都是聚合根的字段组成，并且查询不会对数据库造成不可逆的后果，因此单独开设查询逻辑处理，走CQRS模式。

9.返回的结果数据为多个接口组成，是否在应用服务层直接组合

不可以，需要定义一个assember类，单独对外部依赖的各种数据进行处理。

10.save方法做完delete，insert，update所有方法吗？

delete方法单独处理，可以增加一个delete方法，insert与update方法理论上是需要保持统一方法的。

11.查询逻辑如果涉及到修改聚合根怎么处理

简单查询逻辑直接走仓储，复杂逻辑走应用服务，在应用服务中进行聚合根数据修改。

12.逻辑处理的service放置在何处

如果为此种逻辑仅为某个聚合使用，则放置在对应的领域服务中，如果逻辑处理会被多个聚合使用，则将其单独定义一个service，作为一个工具类。

五.总结

本文对DDD做了一个不算深入的概念，架构的介绍。后对现在仍旧还是被最多使用的MVC三层架构迁移至DDD方案做了一个介绍，最后对可能碰到的一些细节疑问点做了问答。

当然不是所有的业务服务都合适做DDD架构，DDD合适产品化，可持续迭代，业务逻辑足够复杂的业务系统，中小规模的系统与团队还是不建议使用的，毕竟相比较与MVC架构，成本很大。

demo演示：DDD-demo

关于MVC分层的微服务架构博主在之前的文章中也给出过一些设计规范，感兴趣的大家可以去看看：

1.看完这篇，你就是架构师

2.求求你，别写祖传代码了

六.更多DDD学习资料

博客资料:

ThoughtWork DDD系列

张逸 DDD系列

欧创新 DDD系列

代码示例：

阿里COLA

github.com/citerus/ddd…

github.com/YaoLin1/ddd…

github.com/ddd-by-exam…

github.com/Sayi/ddd-ca…

七.特别鸣谢

lilpilot

作者最近在开发公司项目时使用到 Redis 缓存，并在翻看前人代码时，看到了一种关于 @Cacheable 注解的自定义缓存有效期的解决方案，感觉比较实用，因此作者自己拓展完善了一番后分享给各位。

Spring 缓存常规配置

Spring Cache 框架给我们提供了 @Cacheable 注解用于缓存方法返回内容。但是 @Cacheable 注解不能定义缓存有效期。这样的话在一些需要自定义缓存有效期的场景就不太实用。

按照 Spring Cache 框架给我们提供的 RedisCacheManager 实现，只能在全局设置缓存有效期。这里给大家看一个常规的 CacheConfig 缓存配置类，代码如下，

@EnableCaching

@Configuration

public class CacheConfig extends CachingConfigurerSupport {

    ...



    private RedisSerializer keySerializer() {

        return new StringRedisSerializer();

    }



    private RedisSerializer

  咦咦咦，各位小可爱，我是你们的好伙伴——bug菌，今天又来给大家普及Java SE相关知识点了，别躲起来啊，听我讲干货还不快点赞，赞多了我就有动力讲得更嗨啦！所以呀，养成先点赞后阅读的好习惯，别被干货淹没了哦~

环境说明：Windows 10 + IntelliJ IDEA 2021.3.2 + Jdk 1.8

前言

  Set是Java集合框架中的一个接口，它继承了Collection接口，并添加了一些独有的方法。Set可看做是没有重复元素的Collection，它的实现类包括HashSet、TreeSet等。本文将从源码的角度来解读Set接口的底层实现原理。

摘要

  本文将对Java Set接口进行详细的解读，包括Set的概述、源代码解析、应用场景案例、优缺点分析、类代码方法介绍和测试用例等方面。

Set接口

概述

  Set是一个不允许重复元素的集合。它继承了Collection接口，最基本的操作包括添加元素、检查元素是否存在、删除元素等。Set接口的实现类包括HashSet、TreeSet等。HashSet是基于哈希表的实现，TreeSet是基于红黑树的实现。

源代码解析

Set

  Set接口是Java集合框架中的一种接口，它表示一组无序且不重复的元素。Set接口继承自Collection接口，因此它具有Collection接口的所有方法，但是在Set接口中，添加重复元素是不允许的。Set接口有两个主要的实现类：HashSet和TreeSet。其中，HashSet基于哈希表实现，对于非Null元素具有O(1)的插入和查找时间复杂度；而TreeSet基于红黑树实现，对于有序集合的操作具有良好的性能表现。在使用Set接口时，可以通过迭代器遍历元素，也可以使用foreach语句遍历元素。

  如下是部分源码截图：

HashSet

  HashSet基于哈希表实现，它使用了一个称为“hash表”的数组来存储元素。当我们向HashSet中添加元素时，首先会对元素进行哈希，并通过哈希值来确定元素在数组中的位置。如果该位置已经有元素了，就会通过equals方法来判断是否重复，如果重复则不添加，如果不重复则添加到该位置。当然，由于哈希表中可能会存在多个元素都哈希到同一个位置的情况，因此这些元素会被存储在同一个位置上，形成一个链表。在查找元素时，先通过哈希值定位到链表的头部，然后在链表中进行搜索，直到找到匹配的元素或到达链表的末尾。

public class HashSet extends AbstractSet implements Set, Cloneable, java.io.Serializable {

    static final long serialVersionUID = -5024744406713321676L;

    private transient HashMap map;

    // Dummy value to associate with an Object in the backing Map

    private static final Object PRESENT = new Object();



    public HashSet() {

        map = new HashMap<>();

    }



    public boolean add(E e) {

        return map.put(e, PRESENT)==null;

    }



    public boolean contains(Object o) {

        return map.containsKey(o);

    }



    public boolean remove(Object o) {

        return map.remove(o)==PRESENT;

    }

}

  这是一个实现了 HashSet 数据结构的 Java 类。HashSet 继承了 AbstractSet 类，同时实现了 Set 接口和 Cloneable 和 Serializable 接口。

  HashSet 内部使用 HashMap 来存储元素，其中元素作为 key ，一个 static final Object 作为 value，即：

private transient HashMap map;

private static final Object PRESENT = new Object();

  在构造器中，HashSet 实例化了一个空的 HashMap 对象：

public HashSet() {

    map = new HashMap<>();

}

  向 HashSet 中添加元素时，HashSet 调用 HashMap 的 put() 方法。当新元素没有在 HashMap 中存在时，put() 方法返回 null ，此时 HashSet 返回 true，表示添加成功。如果元素已经存在于 HashMap（即已经在 HashSet 中），那么 put() 方法返回已经存在的 Object，此时 HashSet 返回 false，表示添加失败。

public boolean add(E e) {

    return map.put(e, PRESENT)==null;

}

  判断 HashSet 是否包含指定元素时，HashSet 调用 HashMap 的 containsKey() 方法。如果 HashMap 中包含该元素，则 HashSet 返回 true，否则返回 false。

public boolean contains(Object o) {

    return map.containsKey(o);

}

  从 HashSet 中移除指定元素时，HashSet 调用 HashMap 的 remove() 方法。如果该元素存在于 HashMap 中（即在 HashSet 中），则返回 true，否则返回 false。

public boolean remove(Object o) {

    return map.remove(o)==PRESENT;

}

  如下是部分源码截图：

TreeSet

  TreeSet基于红黑树实现，它是一种自平衡的二叉查找树。每个节点都有一个额外的颜色属性，只能是红色或黑色。红黑树的基本操作包括插入、删除和查找。当我们向TreeSet中添加元素时，它会根据元素的大小来将元素添加到树中的合适位置。对于每个节点，其左子树的所有元素都比该节点的元素小，右子树的所有元素都比该节点的元素大。在删除时，如果要删除的节点有两个子节点，会先在右子树中找到最小元素，然后将该节点的元素替换为最小元素。删除最小元素就是从根节点开始，一直找到最左侧的节点即可。

public class TreeSet extends AbstractSet implements NavigableSet, Cloneable, java.io.Serializable {

    private transient NavigableMap m;

    private static final Object PRESENT = new Object();



    public TreeSet() {

        this(new TreeMap());

    }



    public TreeSet(NavigableMap m) {

        this.m = m;

    }



    public boolean add(E e) {

        return m.put(e, PRESENT)==null;

    }



    public boolean contains(Object o) {

        return m.containsKey(o);

    }



    public boolean remove(Object o) {

        return m.remove(o)==PRESENT;

    }

}

  这段代码定义了一个泛型类TreeSet，继承了AbstractSet类，并实现了接口NavigableSet,Cloneable和java.io.Serializable。

  类中的m变量是一个NavigableMap类型的成员变量，TreeSet内部实际上是通过使用TreeMap实现的。

  类中还定义了PRESENT静态常量，用于表示在TreeSet中已经存在的元素。

  TreeSet类中的add方法实现了向集合中添加元素的功能，使用了NavigableMap中的put方法，如果添加的元素在集合中不存在，则返回null，否则返回PRESENT。

  contains方法判断集合中是否包含某个元素。使用了NavigableMap中的containsKey方法。

  remove方法实现删除某个元素的功能，使用NavigableMap中的remove方法，如果删除成功，则返回PRESENT。

  如下是部分源码截图：

应用场景案例

  Set的一个常见应用场景就是去重。由于Set中不允许存在重复元素，因此我们可以利用Set来去除列表中的重复元素，代码如下：

代码演示

List list = new ArrayList<>(Arrays.asList(1, 2, 3, 2, 1));

Set set = new HashSet<>(list);

list = new ArrayList<>(set);

System.out.println(list); // output: [1, 2, 3]

代码分析

  根据如上代码，在此我给大家进行深入详细的解读一下测试代码，以便于更多的同学能够理解并加深印象。

  该代码创建了一个包含重复元素的整型列表list，并使用list初始化了一个整型哈希集合set。然后，通过将set转换回一个新的ArrayList对象，生成一个不带重复元素的整型列表list。最后，输出list的元素。 因此，代码输出应该是[1, 2, 3]。

优缺点分析

优点

1. Set接口的实现类可以高效地检查元素是否存在；


2. Set接口的实现类不允许存在重复元素，可以用来进行去重操作；


3. HashSet的添加、删除、查找操作时间复杂度为O(1)；TreeSet的添加、删除、查找操作时间复杂度为O(logN)。

缺点

1. 如果需要有序存储元素，那么需要使用TreeSet，但是由于TreeSet是基于红黑树实现的，因此占用内存空间较大；


2. HashSet在哈希冲突的情况下，会导致链表长度增加，从而影响查找效率；


3. HashSet在遍历元素时，元素的顺序不能保证。

类代码方法介绍

HashSet

1. add(E e)：向集合中添加元素；


2. clear()：清空集合中所有元素；


3. contains(Object o)：判断集合中是否存在指定的元素；


4. isEmpty()：判断集合是否为空；


5. iterator()：返回一个用于遍历集合的迭代器；


6. remove(Object o)：从集合中移除指定的元素；


7. size()：返回集合中元素的数量。

TreeSet

1. add(E e)：向集合中添加元素；


2. ceiling(E e)：返回集合中大于等于指定元素的最小元素；


3. clear()：清空集合中所有元素；


4. contains(Object o)：判断集合中是否存在指定的元素；


5. descendingIterator()：返回一个逆序遍历集合的迭代器；


6. first()：返回集合中的第一个元素；


7. headSet(E toElement, boolean inclusive)：返回集合中小于指定元素的子集；


8. isEmpty()：判断集合是否为空；


9. iterator()：返回一个用于遍历集合的迭代器；


10. last()：返回集合中的最后一个元素；


11. remove(Object o)：从集合中移除指定的元素；


12. size()：返回集合中元素的数量；


13. subSet(E fromElement, boolean fromInclusive, E toElement, boolean toInclusive)：返回集合中大于等于fromElement且小于等于toElement的子集；


14. tailSet(E fromElement, boolean inclusive)：返回集合中大于等于指定元素的子集。

测试用例

下面是一些测试用例，展示了Set接口的一些基本操作：

package com.demo.javase.day61;



import java.util.HashSet;

import java.util.Iterator;

import java.util.Set;



/**

 * @Author bug菌

 * @Date 2023-11-06 10:33

 */

public class SetTest {



    public static void main(String[] args) {



        // 创建一个 HashSet 对象

        Set set = new HashSet();



        // 向集合中添加元素

        set.add("Java");

        set.add("C++");

        set.add("Python");



        // 打印出集合中的元素个数

        System.out.println("集合中的元素个数为：" + set.size());



        // 判断集合是否为空

        System.out.println("集合是否为空：" + set.isEmpty());



        // 判断集合中是否包含某个元素

        System.out.println("集合中是否包含 Python：" + set.contains("Python"));



        // 从集合中移除某个元素

        set.remove("C++");

        System.out.println("从集合中移除元素后，集合中的元素个数为：" + set.size());



        // 使用迭代器遍历集合中的元素

        Iterator iterator = set.iterator();

        System.out.println("遍历集合中的元素：");

        while (iterator.hasNext()) {

            String element = iterator.next();

            System.out.println(element);

        }



        // 清空集合中的所有元素

        set.clear();

        System.out.println("清空集合中的元素后，集合中的元素个数为：" + set.size());

    }

}

该测试用例使用了HashSet作为实现Set接口的具体类，并测试了以下基本操作：

1. 向集合中添加元素


2. 打印出集合中的元素个数


3. 判断集合是否为空


4. 判断集合中是否包含某个元素


5. 从集合中移除某个元素


6. 使用迭代器遍历集合中的元素


7. 清空集合中的所有元素

测试结果

  根据如上测试用例，本地测试结果如下，仅供参考，你们也可以自行修改测试用例或者添加更多的测试数据或测试方法，进行熟练学习以此加深理解。

当运行该测试用例后，我们将得到以下输出结果：

集合中的元素个数为：3

集合是否为空：false

集合中是否包含 Python：true

从集合中移除元素后，集合中的元素个数为：2

遍历集合中的元素：

Java

Python

清空集合中的元素后，集合中的元素个数为：0

具体执行截图如下：

测试代码分析

  根据如上测试用例，在此我给大家进行深入详细的解读一下测试代码，以便于更多的同学能够理解并加深印象。

这段代码演示了如何使用Java中的Set接口和HashSet类。具体来说，代码实现了：

1.创建一个HashSet对象。

2.向集合中添加元素。

3.打印出集合中的元素个数。

4.判断集合是否为空。

5.判断集合中是否包含某个元素。

6.从集合中移除某个元素。

7.使用迭代器遍历集合中的元素。

8.清空集合中的所有元素。

  从这段代码可以看出，Set接口和HashSet类可以帮助我们快速地实现集合的添加、删除、查找等操作，并且还支持迭代器遍历集合中的所有元素。

概述

作为JAVA程序员，应该或多或少跟BigDecimal打过交道。JAVA在java.math包中提供的API类BigDecimal，用来对超过16位有效位的数进行精确的运算。

精度丢失

先从1个问题说起，看如下代码

System.out.println(0.1 + 0.2);

最后打印出的结果是0.30000000000000004，而不是预期的0.3。

有经验的开发同学应该一下子看出来这就是因为double丢失精度导致。更深层次的原因，是因为我们的计算机底层是二进制的，只有0和1，对于整数来说，从低到高的每1位代表了1、2、4、8、16...这样的2的正次数幂，只要位数足够，每个整数都可以分解成这样的2的正次数幂组合，例如7D=111B，13D=1101B。但是到了小数这里，就会发现2的负次数幂值是0.5、0.25、0.125、0.0625这样的值，但是并不是每个小数都可以分解成这样的2的负次数幂组合，例如你无法精确凑出0.1。所以，double的0.1其实并不是精确的0.1，只是通过几个2的负次数幂值凑的近似的0.1，所以会出现前面0.1 + 0.2 = 0.30000000000000004这样的结果。

适用场景

双精度浮点型变量double可以处理16位有效数，但是某些场景下，即使已经做到了16位有效位的数还是不够，比如涉及金额计算，差一点就会导致账目不平。

常用方法

加减乘除

既然BigDecimal主要用于数值计算，那么最基础的方法就是加减乘除。BigDecimal没有对应的数值类的基本数据类型，所以不能直接使用+、-、*、/这样的符号来进行计算，而要使用BigDecimal内部的方法。

public BigDecimal add(BigDecimal augend)

public BigDecimal subtract(BigDecimal subtrahend)

public BigDecimal multiply(BigDecimal multiplicand)

public BigDecimal divide(BigDecimal divisor)

需要注意的是，BigDecimal是不可变的，所以，add、subtract、multiply、divide方法都是有返回值的，返回值是一个新的BigDecimal对象，原来的BigDecimal值并没有变。

设置精度和舍入策略

可以通过setScale方法来设置精度和舍入策略。

public BigDecimal setScale(int newScale, RoundingMode roundingMode)

第1个参数newScale代表精度，即小数点后位数；第2个参数roundingMode代表舍入策略，RoundingMode是一个枚举，用来替代原来在BigDecimal定义的常量，原来在BigDecimal定义的常量已经标记为Deprecated。在RoundingMode类中也通过1个valueOf方法来给出映射关系

/**

 * Returns the {@code RoundingMode} object corresponding to a

 * legacy integer rounding mode constant in {@link BigDecimal}.

 *

 * @param  rm legacy integer rounding mode to convert

 * @return {@code RoundingMode} corresponding to the given integer.

 * @throws IllegalArgumentException integer is out of range

 */

public static RoundingMode valueOf(int rm) {

    return switch (rm) {

        case BigDecimal.ROUND_UP          -> UP;

        case BigDecimal.ROUND_DOWN        -> DOWN;

        case BigDecimal.ROUND_CEILING     -> CEILING;

        case BigDecimal.ROUND_FLOOR       -> FLOOR;

        case BigDecimal.ROUND_HALF_UP     -> HALF_UP;

        case BigDecimal.ROUND_HALF_DOWN   -> HALF_DOWN;

        case BigDecimal.ROUND_HALF_EVEN   -> HALF_EVEN;

        case BigDecimal.ROUND_UNNECESSARY -> UNNECESSARY;

        default -> throw new IllegalArgumentException("argument out of range");

    };

}

我们逐一看一下每个值的含义

• UP
  
  直接进位，例如下面代码结果是3.15

BigDecimal pi = BigDecimal.valueOf(3.141);

System.out.println(pi.setScale(2, RoundingMode.UP));

• DOWN
  
  直接舍去，例如下面代码结果是3.1415

BigDecimal pi = BigDecimal.valueOf(3.14159);

System.out.println(pi.setScale(4, RoundingMode.DOWN));

• CEILING
  
  如果是正数，相当于UP；如果是负数，相当于DOWN。


• FLOOR
  
  如果是正数，相当于DOWN；如果是负数，相当于UP。


• HALF_UP
  
  就是我们正常理解的四舍五入，实际上应该也是最常用的。
  下面的代码结果是3.14

BigDecimal pi = BigDecimal.valueOf(3.14159);

System.out.println(pi.setScale(2, RoundingMode.HALF_UP));

下面的代码结果是3.142

BigDecimal pi = BigDecimal.valueOf(3.14159);

System.out.println(pi.setScale(3, RoundingMode.HALF_UP));

• HALF_DOWN
  
  与四舍五入类似，这种是五舍六入。我们对于HALF_UP和HALF_DOWN可以理解成对于5的处理不同，UP遇到5是进位处理，DOWN遇到5是舍去处理，


• HALF_EVEN
  
  如果舍弃部分左边的数字为偶数，相当于HALF_DOWN；如果舍弃部分左边的数字为奇数，相当于HALF_UP


• UNNECESSARY
  
  非必要舍入。如果除去小数的后导0后，位数小于等于scale，那么就是去除scale位数后面的后导0；位数大于scale，抛出ArithmeticException。
  
  下面代码结果是3.14

BigDecimal pi = BigDecimal.valueOf(3.1400);

System.out.println(pi.setScale(2, RoundingMode.UNNECESSARY));

下面代码抛出ArithmeticException

BigDecimal pi = BigDecimal.valueOf(3.1400);

System.out.println(pi.setScale(1, RoundingMode.UNNECESSARY));

常见问题

创建BigDecimal对象

先看下面代码

BigDecimal a = new BigDecimal(0.1);

System.out.println(a);

实际输出的结果是0.1000000000000000055511151231257827021181583404541015625。其实这跟我们开篇引出的精度丢失是同一个问题，这里构造方法中的参数0.1是double类型，本身无法精确表示0.1，虽然BigDecimal并不会导致精度丢失，但是在更加上游的源头，double类型的0.1已经丢失了精度，这里用一个已经丢失精度的0.1来创建不会丢失精度的BigDecimal，精度还是会丢失。类似于使用2K的清晰度重新录制了一遍原始只有360P的视频，清晰度也不会优于原始的360P。

所以，我们应该尽量避免使用double来创建BigDecimal，确实源头是double的，我们可以使用valueOf方法，这个方法会先调用Double.toString(val)来转成String，这样就不会产生精度丢失，下面的代码结果就是0.1

BigDecimal a = BigDecimal.valueOf(0.1);

System.out.println(a);

顺便说一下，BigDecimal还内置了ZERO、ONE、TEN这样的常量可以直接使用。

toString

这个问题比较隐蔽，在数据比较小的时候不会遇到，但是看如下代码

BigDecimal a = BigDecimal.valueOf(987654321987654321.123456789123456789);

System.out.println(a);

最后实际输出的结果是9.8765432198765427E+17。原因是System.out.println会自动调用BigDecimal的toString方法，而这个方法会在必要时使用科学计数法，如果不想使用科学计数法，可以使用BigDecimal的toPlainString方法。另外提一下，BigDecimal还提供了一个toEngineeringString方法，这个方法也会使用科学技术法，不一样的是，这里面的10都是3、6、9这样的幂，对应我们在查看大数的时候，很多都是每3位会增加1个逗号。

comparTo 和 equals

这个问题出现的不多，有经验的开发同学在比较数值的时候，会自然而然使用comparTo方法。这里说一下BigDecimal的equals方法除了比较数值之外，还会比较scale精度，不同精度不会equles。

例如下面代码分别会返回0和false

BigDecimal a = new BigDecimal("0.1");

BigDecimal b = new BigDecimal("0.10");

System.out.println(a.compareTo(b));

System.out.println(a.equals(b));

不能除尽时ArithmeticException异常

上面提到的加减乘除的4个方法中，除法会比较特殊，因为可能出现除不尽的情况，这时如果没有设置精度，就会抛出ArithmeticException，因为这个是否能除尽是跟具体数值相关的，这会导致偶现的bug，更加难以排查。

例如下面代码就会抛出ArithmeticException异常

BigDecimal a = new BigDecimal(1);

BigDecimal b = new BigDecimal(3);

System.out.println(a.divide(b));

应对的方法是，在除法运算时，注意设置结果的精度和舍入模式，下面的代码就能正常输出结果0.33

BigDecimal a = new BigDecimal(1);

BigDecimal b = new BigDecimal(3);

System.out.println(a.divide(b, 2, RoundingMode.HALF_UP));

总结

BigDecimal主要用于double因为精度丢失而不满足的某些特殊业务场景，例如会计金额计算。在可以忍受略微不精确的场景还是使用内部提供的add、subtract、multiply、divide方法来进行基础的加减乘除运算，运算后会返回新的对象，原始的对象并不会改变。在使用BigDecimal的过程中，要注意创建对象、toString、比较数值、不能除尽时需要设置精度等问题。

大家好，我是小❤，一个漂泊江湖多年的 985 非科班程序员，曾混迹于国企、互联网大厂和创业公司的后台开发攻城狮。

1. 引言

前些天所在部门出去团建，于是公司行政和 HR 拉了一个微信群，发布一些跟团和集合信息。

当我正在查看途径路线和团建行程时，忽然一条带着喜意的消息扑面而来，消息上赫然带着八个大字：恭喜发财，大吉大利。

抢红包！！原来是公司领导在群里发了个红包，于是引得群员哄抢，气氛其乐融融。

毕竟，团不团建无所谓，不上班就很快乐；抢多抢少无所谓，有钱进就很开心。

打工人果然是最容易满足的生物！

我看着群里嬉戏打闹的聊天，心中陷入了沉思：微信这个集齐了陌生人聊天、文件分享和抢红包功能的群聊设计确实有点意思，如果在面试或者工作中让我们设计一个群聊系统，需要从哪些方面来考虑呢？

群聊系统设计

面试官：微信作为 10 亿用户级别的全民 App，有用过吧？

我：（内心 OS，说没用过你也不会相信啊~）当然，亲爱的面试官，我经常使用微信来接收工作消息和文件，并且经常在上面处理工作内容。

面试官：（内心 OS：这小伙子工作意识很强嘛，加分！）OK，微信的群聊功能是微信里面核心的一个能力，它可以将数百个好友或陌生人放进一个群空间，如果让你设计一个用户量为 10 亿用户的群聊系统，你会怎么设计呢？

2. 系统需求

2.1 系统特点与功能需求

我：首先群聊功能是社交应用的核心能力之一，它允许用户创建自己的社交圈子，与家人、朋友或共同兴趣爱好者进行友好地交流。

以下是群聊系统常见的几个功能：

• 
  

  创建群聊：用户可以创建新的聊天群组，邀请其他好友用户加入或与陌生人面对面建群。

  
  


• 
  

  群组管理：群主和管理员能够管理群成员，设置规则和权限。

  
  


• 
  

  消息发送和接收：允许群成员发送文本、图片、音频、视频等多种类型的消息，并推送给所有群成员。

  
  


• 
  

  实时通信：消息应该能够快速传递，确保实时互动。

  
  


• 
  

  抢红包：用户在群聊中发送任意个数和金额的红包，群成员可以抢到随机金额的红包。

  
  

2.2 非功能需求

除了功能需要，当我们面对 10 亿微信用户每天都可能使用建群功能的情景时，还需要处理大规模的用户并发。

这就引出了系统的非功能需求，包括：

• 高并发：系统需要支持大量用户同时创建和使用群组，以确保无延迟的用户体验。


• 高性能：快速消息传递、即时响应，是数字社交的关键。


• 海量存储：系统必须可扩展，以容纳用户生成的海量消息文本、图片及音视频数据。

面试官：嗯，不错，那你可以简要概述一下这几个常用的功能吗？

3. 核心组件

我：好的，我们首先做系统的概要设计，这里涉及到群聊系统的核心组件和基本业务的概要说明。

3.1 核心组件

群聊系统中，会涉及到如下核心组件和协议。

• 客户端：接收手机或 PC 端微信群聊的消息，并实时传输给后台服务器；


• Websocket传输协议：支持客户端和后台服务端的实时交互，开销低，实时性高，常用于微信、QQ 等 IM 系统通信系统；


• 长连接集群：与客户端进行 Websocket 长连接的系统集群，并将消息通过中间件转发到应用服务器；


• 消息处理服务器集群：提供实时消息的处理能力，包括数据存储、查询、与数据库交互等；

• 
  

  消息推送服务器集群：这是信息的中转站，负责将消息传递给正确的群组成员；

  
  


• 
  

  数据库服务器集群：用于存储用户文本数据、图片的缩略图、音视频元数据等；

  
  


• 
  

  分布式文件存储集群：存储用户图片、音视频等文件数据。

  
  

3.2 业务概要说明

在业务概要说明里，我们关注用户的交互方式和数据存储......

面试官：稍等一下，群聊系统的好友建群功能比较简单，拉好友列表存数据就可以了！你用过面对面建群吧，可以简要说一下如何设计面对面建群功能吗？

我：（内心 OS，还好之前在吃饭时用过面对面建群结账，不然就G了），好的，群聊系统除了拉好友建群外，还支持面对面建群的能力。

4. 面对面建群

用户发起面对面建群后，系统支持输入一个 4 位数的随机码，周围的用户输入同一个随机码便可加入同一个群聊，面对面建群功能通常涉及数据表设计和核心业务交互流程如下。

4.1 数据库表设计

0. 
   

   User 表：存储用户信息，包括用户 ID、昵称、头像等。

   
   


1. 
   

   Gr0up 表：存储群组信息，包括群 ID、群名称、创建者 ID、群成员个数等。

   
   


2. 
   

   Gr0upMember 表：关联用户和群组，包括用户 ID 和群 ID。

   
   


3. 
   

   RandomCode 表：存储面对面建群的随机码和关联的群 ID。

   
   

4.2 核心业务交互流程

用户 A 在手机端应用中发起面对面建群，并输入一个随机码，校验通过后，等待周围（50 米之内）的用户加入。此时，系统将用户信息以 HashMap 的方式存入缓存中，并设置过期时间为 3min。

{随机码，用户列表[用户A(ID、名称、头像)]}

用户 B 在另一个手机端发起面对面建群，输入指定的随机码，如果该用户周围有这样的随机码，则进入同一个群聊等待页面，并可以看到其它群员的头像和昵称信息。

此时，系统除了根据随机码获取所有用户信息，也会实时更新缓存里的用户信息。

成员A进群

当第一个用户点击进入该群时，就可以加入群聊，系统将生成的随机码保存在 RandomCode 表中，并关联到新创建的群 ID，更新群成员的个数。

然后，系统将用户信息和新生成的群聊信息存储在 Gr0up、Gr0upMember 表中，并实时更新群成员个数。

成员B加入

然后，B 用户带着随机码加入群聊时，手机客户端向服务器后端发送请求，验证随机码是否有效。后台服务检查随机码是否存在于缓存中，如果存在，则校验通过。

然后，根据 Gr0up 中的成员个数，来判断当前群成员是否满员（目前普通用户创建的群聊人数最多为 500 人）。

如果验证通过，后台将用户 B 添加到群成员表 Gr0upMember 中，并返回成功响应。

面试官：如果有多个用户同时加入，MySQL 数据库如何保证群成员不会超过最大值呢？

我：有两种方式可以解决。一个是通过 MySQL 的事务，将获取 Gr0up 群成员数和插入 Gr0upMember 表操作放在同一个事务里，但是这样可能带来锁表的问题，性能较差。

另一种方式是采用 Redis 的原子性命令incr 来记录群聊的个数，其中 key 为群聊ID，value 为当前群成员个数。

当新增群员时，首先将该群聊的人数通过 incr 命令加一，然后获取群成员个数。如果群员个数大于最大值，则减一后返回群成员已满的提示。

使用 Redis 的好处是可以快速响应，并且可以利用 Redis 的原子特性避免并发问题，在电商系统中也常常使用类似的策略来防止超卖问题。

位置算法

同时，在面对面建群的过程中相当重要的能力是标识用户的区域，比如 50 米以内。这个可以用到 Redis 的 GeoHash 算法，来获取一个范围内的所有用户信息。

由于篇幅有限，这里不展开赘述，想了解更多位置算法相关的细节，可以看我之前的文章：听说你会架构设计？来，弄一个公交&地铁乘车系统。

面试官：嗯不错，那你再讲一下群聊系统里的消息发送和接收吧！

5. 消息发送与接收

我：当某个成员在微信群里发言，系统需要处理消息的分发、通知其他成员、以及确保消息的显示。

在群聊系统中保存和展示用户的图片、视频或音频数据时，通常需要将元数据和文件分开存储。

其中元数据存储在 MySQL 集群，文件数据存储在分布式对象存储集群中。

5.1 交互流程

消息发送和接收的时序图如下所示：

0. 
   

   用户A在群中发送一条带有图片、视频或音频的消息。

   
   


1. 
   

   移动客户端应用将消息内容和媒体文件上传到服务器后端。

   
   


2. 
   

   服务器后端接收到消息和媒体文件后，将消息内容存储到 Message 表中，同时将媒体文件存储到分布式文件存储集群中。在 Message 表里，不仅记录了媒体文件的 MediaID，以便关联消息和媒体；还记录了缩略图、视频封面图等等。

   
   


3. 
   

   服务器后端会向所有群成员广播这条消息。移动客户端应用接收到消息后，会根据消息类型（文本、图片、视频、音频）加载对应的展示方式。

   
   


4. 
   

   当用户点击查看图片、视频或音频缩略图时，客户端应用会根据 MediaID 到对象存储集群中获取对应的媒体文件路径，并将其展示给用户。

   
   

5.2 消息存储和展示

除了上述建群功能中提到的用户表和群组表以外，存储元数据还需要以下表结构：

0. Message表： 用于存储消息，每个消息都有一个唯一的 MessageID，消息类型（文本、图片、视频、音频），消息内容（文字、图片缩略图、视频封面图等），发送者 UserID、接收群 Gr0upID、发送时间等字段。


1. Media表： 存储用户上传的图片、视频、音频等媒体数据。每个媒体文件都有一个唯一的 MediaID，文件路径、上传者 UserID、上传时间等字段。


2. MessageState表： 用于存储用户消息状态，包括 MessageID、用户 ID、是否已读等。在消息推送时，通过这张表计算未读数，统一推送给用户，并在离线用户的手机上展示一个小数字代表消息未读数。

面试官：我们时常看到群聊有 n 个未读消息，这个是怎么设计的呢？

我：MessageState 表记录了用户的未读消息数，想要获取用户的消息未读数时，只需要客户端调用一下接口查询即可获取，这个接口将每个群的未读个数加起来，统一返回给客户端，然后借助手机的 SDK 推送功能加载到用户手机上。

面试官：就这么简单吗，可以优化一下不？

我：（内心 OS，性能确实很差，就等着你问呢）是的，我们需要优化一下，首先 MySQL 查询 select count 类型的语句时，都会触发全表扫描，所以每次加载消息未读数都很慢。

为了查询性能考虑，我们可以将用户的消息数量存入 Redis，并实时记录一个未读数值。并且，当未读数大于 99 时，就将未读数值置为 100 且不再增加。

当推送用户消息时，只要未读数为 100，就将推送消息数设置为 99+，以此来提升存储的性能和交互的效率。

面试官：嗯，目前几乎所有的消息推送功能都是这么设计的。那你再说一下 10 亿用户的群聊系统应该如何在高并发，海量数据下保证高性能和高可用吧！

我：我想到了几个点，比如采用集群部署、消息队列、多线程、缓存等。

集群部署：可扩展

在群聊系统中，我们用到了分布式可扩展的思想，无论是长连接服务、消息推送服务，还是数据库以及分布式文件存储服务，都是集群部署。

一方面防止单体故障，另一方面可以根据业务来进行弹性伸缩，提升了系统的高可用性。

消息队列：异步、削峰

在消息推送时，由于消息量和用户量很多，所以我们将消息放到消息队列（比如 Kafka）中异步进行消费和推送，来进行流量削峰，防止数据太多将服务打崩。

多线程

在消息写入和消费时，可以多线程操作，一方面节省了硬件开销，不至于部署太多机器。另一方面提升了效率，毕竟多个流水线工作肯定比单打独斗更快。

其它优化

缓存前面已经说到了，除了建群时记录 code，加群时记录群成员数，我们还可以缓存群聊里最近一段时间的消息，防止每个用户都去 DB 拉取一遍数据，这提升了消息查阅的效率。

除此之外，为了节省成本，可以记录流量的高峰时间段，根据时间段来定时扩缩节点（当然，这只是为了成本考虑，在实际业务中这点开销不算什么大问题）。

6. 小结

后续

面试官：嗯不错，实际上的架构中也没有节省这些资源，而是把重心放在了用户体验上。（看了看表）OK，那今天的面试就到这，你有什么想问的吗？

我：（内心 OS，有点慌，但是不能表现出来）由于时间有限，之前对系统高并发、高性能的设计，以及对海量数据的处理浅尝辄止，这在系统设计的面试中占比如何？

面试官：整体想得比较全，但是还不够细节。当然，也可能是时间不充分的原因，已经还不错了！

我：（内心 OS，借你吉言）再想问一下，如果我把这些写出来，会有读者给我点赞、分享、加入在看吗？

面试官：……

结语

群聊系统是社交应用的核心功能之一，每个社交产品几乎都有着群聊系统的身影：包括但不限于 QQ、微信、抖音、小红书等。

上述介绍的技术细节可能只是群聊系统的冰山一角，像常见的抢红包、群内音视频通话这些核心功能也充斥着大量的技术难点。

但正是有了这些功能，才让我们使用的 App 变得更加有趣。而这，可能也是技术和架构的魅力所在吧~

由于篇幅有限，本文到这就结束了。后续可能会根据阅读量、在看数的多寡，判断是否继续更新抢红包、群内音视频通话等核心功能，感兴趣的小伙伴可以关注一下。

昨天，一个在掘金认识的小伙伴，进入了美团专门做 IDE 的基建组，心底真是替他高兴，这本来就是他应得的。

刚认识的时候还是一个工作一年的小毛孩，整天逮着我问各种问题，模板引擎、Babel、Electron、Jest、Rollup…

虽然没见过面，不知道他长什么样，在我脑海里，他就是两样放着光，对技术充满好奇心、自我驱动力很强小伙子。

我就知道他能成，因为我多少也是这样子的，尽管我现在有些倦怠。

后来，随着工作越来越忙，博客也停更了，我们便很少联系了。

不过，后面我招人，尤其是校招生或者初级开发，我都是按照他这个范本来的。我也时常跟别人提起，我认识北京这样一个小伙子。

也有可能我们这边庙太小了，这样的小伙伴屈指可数。

平台和好奇心一样重要。

大部分人智商条件不会有太多的差距，尤其是程序员这个群体，而好奇心可以让你比别人多迈出一步，经过长时间的积累就会拉开很大的差距。

而平台可以让你保持专注，与优秀的人共事，获得更多专业的经验和知识、财富，建立自己的竞争壁垒。

回到正题。

我觉得是时候阶段性地总结和回望回顾我过去这三年，却发现大部分都是泡沫。跨端、业务、质量管理、低代码、领域驱动设计... 本文话题可能会比较杂

2020 年七月，口罩第二年。我选择了跳槽，加入了一家创业公司

跨端开发的泡沫

2020 年，微信小程序已经成为国内重要的流量入口，事实也证明，我们过去几年交付的 C 端项目几乎上都是小程序。更严谨的说，应该是微信小程序，尽管很多巨头都推出了自己的小程序平台，基本上都是陪跑的。

Taro 2.x

进来后接手的第一个项目是原生小程序迁移到 Taro。

那时候，我们的愿景是“一码多端”，期望一套程序能够跑在微信小程序、支付宝小程序等小程序平台、H5、甚至是原生 App。

那时候 Taro 还是 2.x 版本，即通过语法静态编译成各端小程序的源码。

我们迁移花了不少的时间，尽管 Taro 官方提供了自动转换的工具，但是输出的结果是不可靠的，我们仍需要进行全量的回归测试，工作量非常大。 期间我也写了一个自动化代码迁移 CLI 来处理和 Lint 各种自动迁移后的不规范代码。

重构迁移只是前戏。难的让开发者写好 Taro，更难的是写出跨端的 Taro 代码。

我总结过，为什么 Taro(2.x) 这么难用：

• 很多初级开发者不熟悉 React。在此之前技术栈基本是 Vue


• 熟悉 React 的却不熟悉 Taro 的各种约束。


• 即使 Taro 宣称一码多端，你还是需要了解对应平台/端的知识。 即使是小程序端，不同平台的小程序能力和行为都有较大的区别。而 Taro 本身在跨端上并没有提供较好的约束，本身 Bug 也比较多。


• 如果你有跨端需求，你需要熟知各端的短板，以进行权衡和取舍。强调多端的一致和统一会增加很多复杂度, 对代码的健壮性也是一个比较大的考验。


• 我们还背着历史包袱。臃肿、不规范、难以维护、全靠猜的代码。

在跨端上，外行人眼里‘一码多端’就是写好一端，其他端不用改就可以直接运行起来，那有那么简单的事情？

每个端都有自己的长板和短板：

我们从拆分两个维度来看各端的能力：

放在一个基线上看：

跨端代码写不好，我们不能把锅扔给框架，它仅仅提供了一种通用的解决方案，很多事情还是得我们自己去做。

实际上要开发跨平台的程序，最好的开发路径就是对齐最短的板，这样迁移到其他端就会从而很多，当然代价就是开发者负担会很重：

为了让开发者更好的掌握 Taro， 我编写了详细的 Wiki， 阐述了 React 的各种 trick、Taro 如何阉割了 React、Taro 的原理、开发调试、跨端开发应该遵循的各种规范。

Taro 3.0

我们的 Taro 项目在 2020 年底正式在生产使用，而 Taro 3.0 在 2020 年 / 7 月就正式发布了，在次年 5 月，我们决定进行升级。

技术的发展就是这么快，不到 5 个月时间，Taro 2.x 就成为了技术债。

Taro 2.x 官方基本停止了新功能的更新、bug 也不修了，最后我们不得不 Fork Taro 仓库，发布在私有 npm 镜像库中。

Taro 2.x 就是带着镣铐跳舞，实在是太痛苦，我写了一篇文档来历数了它的各种‘罪行’：

• 2.x 太多条条框框，学习成本高


• 这是一个假的 React


• 编译慢


• 调试也太反人类


• …

Taro 3.x 使用的是动态化的架构，有很多优势：

3.x 架构 和数据流

• 动态化的架构。给未来远程动态渲染、低代码渲染、使用不同的前端框架(支持 Vue 开发)带来了可能


• 不同端视图渲染方式差异更小，更通用，跨端兼容性更好。


• 2.x 有非常多的条条框框，需要遵循非常多的规范才能写出兼容多端的代码。3.x 使用标准 React 进行开发，有更好的开发体验、更低的学习成本、更灵活的代码组织。


• 可以复用 Web 开发生态。

使用类似架构的还有 Remax、Alita、Kbone, 我之前写过一篇文章实现的细节 自己写个 React 渲染器: 以 Remax 为例(用 React 写小程序)。

而 Taro 不过是新增了一个中间层：BOM/DOM，这使得 Taro 不再直接耦合 React, 可以使用任意一种视图框架开发，可以使用 Vue、preact、甚至是 jQuery, 让 Web 生态的复用成为可能。

升级 3.x 我同样通过编写自动化升级脚本的形式来进行，这里记录了整个迁移的过程。

重构了再重构

我在 2B or not 2B: 多业态下的前端大泥球 讲述过我们面临的困境。

21 年底，随着后端开启全面的 DDD 重构(推翻现有的业务，重新梳理，在 DDD 的指导下重新设计和开发)，我们也对 C 端进行了大规模的重构，企图摆脱历史债务，提高后续项目的交付效率

上图是重构后的结果，具体过程限于篇幅就不展开了：

• 基础库：我们将所有业务无关的代码重新进行了设计和包装。
  
  
  
  • 组件库：符合 UI 规范的组件库，我们在这里也进行了一些平台差异的抹平
  
  
  • api: Taro API 的二次封装，抹平一些平台差异
  
  
  • utils: 工具函数库
  
  
  • rich-html、echart：富文本、图表封装
  
  
  • router：路由导航库，类型安全、支持路由拦截、支持命名导航、简化导航方法…
  
  
  • …
  
  
  
  


• 模块化：我们升级到 Taro 3.x 之后，代码的组织不再受限于分包和小程序的约束。我们将本来单体的小程序进行了模块的拆分，即 monorepo 化。按照业务的边界和职责拆分各种 SDK


• 方案：一些长期积累开发痛点解决方案，比如解决分包问题的静态资源提取方案、解决页面分享的跳板页方案。


• 规范和指导实现。指导如何开发 SDK、编写跨平台/易扩展的应用等等

巨头逐鹿的小程序平台，基本上是微信小程序一家独大

跨端框架，淘汰下来，站稳脚跟的也只有 taro 和 uniapp

时至今日，我们吹嘘许久的“一码多端”实际上并没有实现；

大而全 2B 业务的泡沫

其实比一码多端更离谱的事情是“一码多业态”。

所谓一码多业态指的是一套代码适配多个行业，我在 2B or not 2B: 多业态下的前端大泥球 中已经进行了深入的探讨。

这是我过去三年经历的最大的泡沫，又称屎山历险记。不要过度追求复用，永远不要企图做一个大而全的 2B 产品

低代码的泡沫

2021 年，低代码正火，受到的资本市场的热捧。

广义的低代码就是一个大箩筐，什么都可以往里装，比如商城装修、海报绘制、智能表格、AI 生成代码、可视化搭建、审核流程编排…

很多人都在蹭热点，只要能粘上一点边的，都会包装自己是低代码，包括我们。在对外宣称我们有低代码的时候，我们并没有实际的产品。现在 AI 热潮类似，多少声称自己有大模型的企业是在裸泳呢？

我们是 2B 赛道，前期项目交付是靠人去堆的，效率低、成本高，软件的复利几乎不存在。

低代码之风吹起，我们也期望它能破解我们面临的外包难题（我们自己都在质疑这种软件交付方式和外包到底有什么区别）。

也有可能是为了追逐资本热潮，我们也规划做自己的 PaaS、aPaaS、iPaaS… 各种 “aaS”(不是 ass)。

但是我们都没做成，规划和折腾了几个月，后面不了了之，请来的大神也送回去了。

在我看来，我们那时候可能是钱多的慌。但并没有做低代码的相关条件，缺少必要的技术积累和资源。就算缩小范围，做垂直领域的低代码，我们对领域的认知和积累还是非常匮乏。

在这期间, 我做了很多调研，也单枪匹马撸了个 “前端可视化搭建平台”：

由于各种原因, 这个项目停止了开发。如今社区上也有若干个优秀的开源替代物，比如阿里的低代码引擎、网易云的 Tango、华为云的 TinyEngine。如果当年坚持开发下去，说不定今天也小有成就了。

不管经过这次的折腾，我越坚信，低代码目前还不具备取代专业编程的能力。我在《前端如何破解 CRUD 的循环》也阐述过相关的观点。

大型项目的规模之大、复杂度之深、迭代的周期之长，使用低代码无疑是搬石头砸自己的脚。简单预想一下后期的重构和升级就知道了。

低代码是无代码和专业编码之间的中间形态，但这个中间点并不好把握。比如，如果倾向专业编码，抽象级别很低，虽然变得更加灵活，但是却丧失了易用性，最终还是会变成专业开发者的玩具。

找对场景，它就是一把利器。不要期望它能 100% 覆盖专业编码，降低预期，覆盖 10%？20%？再到 30%？ 已经是一个不错的成就。

低代码真正可以提效不仅在于它的形式(可视化)，更在于它的生态。以前端界面搭建为例，背后开箱即用的组件、素材、模板、应用，才是它的快捷之道。

在我看来，低代码实际上并不是一个新技术，近年来火爆，更像是为了迎合资本的炒作而稍微具象化的概念。

而今天，真正的’降本增效‘的大刀砍下来，又有多少’降本增效‘的低代码活下来了呢？

质量管理的泡沫

2021 年四月，我开始优化前端开发质量管理，设计的开发流程如下：

开发环境：

• 即时反馈：通过 IDE 或者构建程序即时对问题进行反馈。


• 入库前检查：这里可以对变动的源代码进行统一格式化，代码规范检查、单元测试。如果检查失败则无法提交。

集成环境：

• 服务端检查：聪明的开发者可能绕过开发环境本地检查，在集成环境我们可以利用 Gerrit + Jenkins 来执行检查。如果验证失败，该提交会被拒绝入库。


• CodeReview：CodeReview 是最后一道防线，主要用于验证机器无法检验的设计问题。


• 自动化部署：只有服务端检查和 CodeReview 都通过才能提交到仓库
  
  
  
  • 测试环境：即时部署，关闭安全检查、开启调试方便诊断问题
  
  
  • 生产环境：授权部署
  
  
  
  

生产环境：

前端应用在客户端中运行，我们通常需要通过各种手段来监控和上报应用的状态，以便更快地定位和解决客户问题。

原则一：我认为“自动化才是秩序”：

文档通常都会被束之高阁，因此单靠文档很难形成约束力。尤其在迭代频繁、人员构造不稳定的情况。规范自动化、配合有效的管理才是行之有效的解决办法。

• 规范自动化。能够交给机器去执行的，都应该交给机器去处理, 最大程度降低开发者的心智负担、犯错率。可以分为以下几个方面：
  
  
  
  • 语言层面：类型检查，比如 Typescript。严格的 Typescript 可以让开发者少犯很多错误。智能提示对开发效率也有很大提升。
  
  
  • 风格层面：统一的代码格式化风格。例如 Prettier。
  
  
  • 规范层面：一些代码规范、最佳实践、反模式。可以遵循社区的流行规范, 例如 JavaScript Standard
  
  
  • 架构层面：项目的组织、设计、关联、流程。可以通过脚手架、规范文档、自定义 ESLint 规则。
  
  
  
  


• 管理和文化: 机器还是有局限性，更深层次的检查还是需要人工进行。比如单元测试、CodeReview。这往往需要管理来驱动、团队文化来支撑。这是我们后面需要走的路。

原则二：不要造轮子

我们不打算造轮子，建立自己的代码规范。社区上有很多流行的方案，它们是集体智慧的结晶，也最能体现行业的最佳实践:

没必要自己去定义规则，因为最终它都会被废弃，我们根本没有那么多精力去维护。

实现

企业通知 Code Review

我们这套代码质量管理体系，主要基于以下技术来实现：

• Jenkins： 运行代码检查、构建、通知等任务


• Gerrit：以 Commit 为粒度的 CodeReview 工具


• wkfe-standard: 我们自己实现渐进式代码检查 CLI

如果你想了解这方面的细节，可以查看以下文档：

• 开发规范


• 代码规范与渐进式检查


• Gerrit 开发者手册


• Gerrit 管理者手册


• Code Review CheckList

我推崇的自动化就是秩序目的就是让机器来取代人对代码进行检查。然而它只是仅仅保证底线。

人工 CodeReview 的重要性不能被忽略，毕竟很多事情机器是做不了的。

为了推行 CodeReview，我们曾自上而下推行了 CCC（简洁代码认证） 运动，开发者可以提交代码让专家团队来 Code Review，一共三轮，全部通过可以获得证书，该证书可以成为绩效和晋升的加分项；除此之外还有代码规范考试…

然而，这场运动仅仅持续了几个月，随着公司组织架构的优化、这些事情就不再被重视。

不管是多么完善的规范、工作流，人才是最重要的一环，到最后其实是人的管理

DDD / 中台的泡沫

近年来，后端微服务、中台化等概念火热，DDD 也随之而起。

上图的 DDD Google 趋势图，一定程度可以反映国内 DDD 热度的现实情况：

• 在 14 年左右，微服务的概念开始被各方关注，我们可以看到这年 DDD 的搜索热度有明显的上升趋势


• 2015 年，马某带领阿里巴巴集团的高管，去芬兰的赫尔辛基对一家名叫 supercell 的游戏公司进行商务拜访，中台之风随着而起，接下来的一两年里，DDD 的搜索热度达到了顶峰。


• 2021 ～ 2022 年，口罩期间，很多公司业务几乎停摆，这是一个’内修‘的好时机。很多公司在这个阶段进行了业务的 DDD 重构，比较典型的代表是去哪儿（业务瘦身 42%+效率提升 50% ：去哪儿网业务重构 DDD 落地实践）。

上文提到，我们在 2021 年底也进行了一次轰轰烈烈的 DDD 重构战役，完全推翻现有的项目，重新梳理业务、重新设计、重新编码。

重构需要投入了大量的资源，基本公司 1 / 3 的研发资源都在里面了，这还不包括前期 DDD 的各种预研和培训成本。

在现在看来，这些举措都是非常激进的。而价值呢？现在还不’好说‘(很难量化)

DDD 落地难

其实既然开始了 DDD 重构, 就说明我们已经知道 ’怎么做 DDD‘ 了，在重构之前，我们已经有了接近一年的各种学习和铺垫，且在部分中台项目进行了实践。

但我至今还是觉得 DDD 很难落地，且不说它有较高的学习成本，就算是已落地的项目我们都很难保证它的连续性(坚持并贯彻初衷、规范、流程)，烂尾的概率比较高。

为了降低开发者对 DDD 的上手门槛，我们也进行了一些探索。

低代码 + DDD?

可视化领域建模

2022 下半年，我们开始了 ’DDD 可视化建模‘ 的探索之路，如上图所示。

这个平台的核心理念和方法论来源于我们过去几年对 DDD 的实践经验，涵盖了需求资料的管理、产品愿景的说明、统一语言、业务流程图、领域模型/查询模型/领域服务的绘制(基于 CQRS)，数据建模(ER)、对象结构映射(Mapper)等多种功能，覆盖了 DDD 的整个研发流程。

同时它也是一个知识管理平台，我们希望在这里聚合业务开发所需要的各种知识，包括原始需求资料、统一语言、领域知识、领域建模的结果。让项目的二开、新团队成员可以更快地入手。

最终，建模的结果通过“代码生成器”生成代码，真正实现领域驱动设计，而设计驱动编码。

很快我们会完全开源这套工具，可以关注我的后续文章。

DDD 泡沫

即使我们有’低代码‘工具 + 代码自动生成的加持，实现了领域驱动设计、设计驱动编码，结果依旧是虎头蛇尾，阻止不了 DDD 泡沫的破裂。

我也思考了很多原因，为什么我们没有’成功‘？

• DDD 难？学习曲线高


• 参与的人数少，DDD 受限在后端开发圈子里面，其他角色很少参与进来，违背了 DDD 的初衷


• 重术而轻道。DDD 涵括了战略设计和战术设计，如果战略设计是’道‘、战术设计就是’术‘，大部分开发者仅仅着眼于术，具体来说他们更关注编码，思维并没有转变，传统数据建模思维根深蒂固


• 中台的倒台，热潮的退去

扩展阅读：

• 我的 DDD 学习笔记

一些零碎的事

过去三年还做了不少事情，限于篇幅，就不展开了：

• 前端容器化部署，CI/CD 流程的优化。详见：使用 Docker 实现前端应用的标准化构建、部署和运行


• 微前端升级。详见：微前端的落地和治理实战、管理端开发框架


• 管理端组件库。详见：如何实现支持跨 Vue 2/3 的组件库、前端如何破解 CRUD 的循环

过去三年经历时间轴：

• 2020 年 7 月，换了公司，开始接手真正迁移中的 Taro 项目


• 2020 年 10 月，Taro 2.x 小程序正式上线


• 2020 年 10 月 ～ 11 月 优化代码质量管理体系，引入开发规范、Gerrit Code Review 流程


• 2020 年 12 月 ～ 2021 年 4 月，业务开发


• 2021 年 1 月 博客停更


• 2021 年 5 月 Taro 3.x 升级


• 2021 年 7 月 ～ 10 月 前端低代码平台开发


• 2021 年 11 月 ～ 2022 年 5 月， DDD 大规模重构，C 端项目重构、国际化改造


• 2022 年 6 月 ～ 2022 年 11 月，B 端技术升级，涉及容器化改造、微前端升级、组件库开发等


• 2022 年 12 月～ 2023 年 4 月，可视化 DDD 开发平台开发


• 2023 年 5 月 ～ 至今。业务开发，重新开始博客更新

总结

我们都有美好的愿望

重构了又重构，技术的债务还是高城不下

推翻了再推翻，我们竟然是为了‘复用’？

降本增效的大刀砍来

泡沫破碎，回归到了现实

潮水退去，剩下一些裸泳的人

我又走到了人生的十字路口，继续苟着，还是换个方向？

1. 概述

现代生活中已经离不开网盘，比如百度网盘。在使用网盘的过程中，有没有想过它是如何工作的？在本文中，我们将讨论如何设计像百度网盘这样的系统的基础架构。

2. 系统需求

2.1. 功能性需求

1. 用户能够上传照片/文件。


2. 用户能够创建/删除目录。


3. 用户能够下载文件。


4. 用户能够共享上传的文件。


5. 能够在所有的用户设备之间同步数据。


6. 即使网络不可用，用户也能上传文件/照片，只是存储在离线文件中，当网络可用时，离线文件将同步到在线存储。

2.2 非功能性需求

1. 
   

   可用性： 指系统可用于处理用户请求的时间百分比。我们通常将可用性称为5个9、4个9。5个9意味着 99.999% 的可用性，4 个9意味着 99.99% 的可用性等。

   
   


2. 
   

   持久性： 即使系统发生故障，用户上传的数据也应永久存储在数据库中。系统应确保用户上传的文件应永久存储在服务器上，而不会丢失任何数据。

   
   


3. 
   

   可靠性： 指系统对于相同输入给出预期的输出。

   
   


4. 
   

   可扩展性： 随着用户数量的不断增加，系统应该能处理不断增加的流量。

   
   


5. 
   

   ACID： 原子性、一致性、隔离性和持久性。所有的文件操作都应该遵循这些属性。

   
   
   
   
   1. 原子性：对文件执行的任何操作都应该是完整的或不完整的，不应该是部分完整的。即如果用户上传文件，操作的最终状态应该是文件已 100% 上传或根本没有上传。
   
   
   2. 一致性: 保证操作完成之前和之后的数据是相同的。
   
   
   3. 隔离性：意味着同时运行的2个操作应该是独立的，并且不会影响彼此的数据。
   
   
   4. 持久性：参考第二点关于持久性的解释。
   
   
   
   

3. 容量估算

假设我们有 5 亿总用户，其中 1 亿是每日活跃用户。

那么，每分钟的活跃用户数：

1亿 / (24小时 * 60分钟）= 0.07万

再假设下高峰期每分钟有 100 万活跃用户，平均每个用户上传 5 个文件，则每分钟将有 500 万次上传。

如果1次上传平均100KB的文件，则1分钟上传的总文件大小为：

100KB * 5 = 500TB

4. API设计

4.1 上传文件

POST: /uploadFile

Request {

  filename: string,

  createdOnInUTC: long,

  createdBy: string, 

  updatedOnInUTC: long,

  updatedBy: string

}



Response: {

  fileId: string,

  downloadUrl: string

}

上传文件分为2步：

1. 上传文件元数据


2. 上传文件

4.2 下载文件

GET: /file/{fileId}

Response: {

  fileId: string,

  downloadUrl: string

}

通过返回的downloadURL进行文件下载。

4.3 删除文件

DELETE: /file/{fileId}

4.4 获取文件列表

GET: /folders/{folderId}?startIndex={startIndex}&limit={limit}



Response: {

  folderId: string,

  fileList: [ 

    {

      fileId: string,

      filename: string,

      thumbnail_img: string,

      lastModifiedDateInUTC: string

      creationDateInUTC: string

    }

  ]

}

由于文件数量可能会很大，这里采用分页返回的方式。

5. 关键点的设计思考

1. 文件存储： 我们希望系统具有高可用性和耐用性来存储用户上传的内容。为此，我们可以使用对象存储的系统作为文件存储，可选的有AWS的S3、阿里云的对象存储等。我们采用S3。


2. 存储用户数据及其上传元数据： 为了存储用户数据及其文件元数据，我们可以使用关系型数据库和非关系型数据库结合的方式，关系型数据库采用MySQL， 非关系型数据库采用MongoDB。


3. 离线存储： 当用户的设备离线时，用户完成的所有更新都将存储在其本地设备存储中，一旦用户上线，设备会将更新同步到云端。


4. 上传文件： 用户上传的文件大小可能很大，为了将文件从任何设备上传到服务器而不出现任何失败，我们必须将其分段上传。目前常见的对象存储中都支持分段上传。


5. 下载/共享文件： 通过分享文件的URL来实现共享和下载。如果文件存储是S3的话，也可以使用预签名的URL来实现此功能。

默认情况下，所有 S3 对象都是私有的，只有对象所有者有权访问它们。但是，对象所有者可以通过创建预签名 URL 与其他人共享对象。预签名 URL 使用安全凭证授予下载对象的限时权限。URL 可以在浏览器中输入或由程序使用来下载对象。

6. 
   

   设备之间同步： 当用户在其中一台设备上进行更改时，当用户登录其他设备时，这些更改应同步在其他设备上。有两种方法可以做到这一点。

   
   
   
   
   1. 一旦用户从一台设备更新，其他设备也应该更新。
   
   
   2. 当用户登录时更新其他设备进行更新。
   
   
   
   

   我们采用第二种方法，因为即使用户不使用其他设备，它也可以防止对其他设备进行不必要的更新。如果用户在两个不同的设备上在线怎么办？那么在这种情况下我们可以使用长轮询。用户当前在线的设备将长时间轮询后端服务器并等待任何更新。因此，当用户在一台设备上进行更新时，另一台设备也会收到更新。

   
   

6. 数据库设计

用户表

userId: string

username: string

emailId: string

creationDateInUtc: long

文件源数据表

fileId: string

userId: string

filename: string

fileLocation: string

creationDateInUtc: long

updationDateInUtc: long

7. 架构设计

1. 
   

   File MetaData Service： 该服务负责添加/更新/删除用户上传文件的元数据。客户端设备将与此服务通信以获取文件/文件夹的元数据。

   
   


2. 
   

   File Upload Service： 该服务负责将文件上传到 S3 存储桶。用户的设备将以块的形式将文件流式传输到此服务，一旦所有块都上传到 S3 存储桶，上传就会完成。

   
   


3. 
   

   Synchronization Service： 同步服务，两种情况需要同步。

   
   
   
   
   1. 当用户在其设备上打开应用程序时，在这种情况下，我们将从同步服务同步用户的该设备与用户当前查看的目录的最新快照。
   
   
   2. 当用户从一个先后登录两个不同设备时，我们需要同步用户的第一个设备的数据，故而我们使用长轮询来轮询该目录/文件在服务器上的最新更改内容。
   
   
   
   


4. 
   

   S3 存储桶： 我们使用 S3 存储桶来存储用户文件/文件夹。根据用户 ID 创建文件夹，每个用户的文件/文件夹可以存储在该用户的文件夹中。

   
   


5. 
   

   Cache： 使用缓存来减少元数据检索的延迟，当客户端请求文件/文件夹的元数据时，它将首先查找缓存，如果在缓存中找不到，那么它将查找数据库。

   
   


6. 
   

   负载均衡 ： 我们希望我们的服务能够扩展到数百万用户，为此我们需要水平扩展我们的服务。我们将使用负载均衡器将流量分配到不同的主机。这里我们采用Nginx做负载均衡。

   
   


7. 
   

   UserDevices： 用户可以使用移动设备、台式机、平板电脑等多种设备来访问驱动器。我们需要保证所有用户设备的数据都是相同的，并且不能存在数据差异。

   
   

8. 总结

本文讨论了如何设计一个网盘系统的架构，综合功能性需求和非功能性需求，设计了API、数据库和服务架构。但是没有讨论权限设计和数据安全的部分，也欢迎大家补充改进。

项目上线时，突然发现时间与正常时间对不上，少了八个小时；但我丝毫不慌，这不就是个时区的问题吗，简单，但是这一次它给我深深的上了一课，一起来看整个排查过程吧；

开始排查

1、排查数据库

一般的时区问题都是数据库配置或数据链接参数的配置问题，于是我立马就定位到了问题，应该是数据库的时区设置错了，于是我愉快的查看了数据库时区

命令：show variables like '%time_zone%';

1、system_time_zone：全局参数，系统时区，在MySQL启动时会检查当前系统的时区并根据系统时区设置全局参数system_time_zone的值。值为CST，与系统时间的时区一致。

2、ime_zone：全局参数，设置每个连接会话的时区，默认为SYSTEM，使用全局参数system_time_zone的值。

CST时间

CST时间：中央标准时间。
CST可以代表如下4个不同的时区：

● Central Standard Time (USA) UT-6:00，美国
● Central Standard Time (Australia) UT+9:30，澳大利亚
● China Standard Time UT+8:00，中国
● Cuba Standard Time UT-4:00，古巴

再次分析

很显然，这里与UTC时间无关，它只是时间标准。目前Mysql中的system_time_zone是CST，而CST可以代表4个不同的时区，那么，Mysql把它当做哪个时区进行处理了呢？

简单推算一下，中国时间是UT+8:00，美国是 UT-6:00，当传入中国时间，直接转换为美国时间（未考虑时区问题），时间便慢了14个小时。

既然知道了问题，那么解决方案也就有了。

解决方案

方案一：修改数据库时区

既然是Mysql理解错了CST指定的时区，那么就将其设置为正确的。

连接Mysql数据库，设置正确的时区：

set global time_zone = '+8:00';

set time_zone = '+8:00';

flush privileges;

再次执行show命令查看：show variables like '%time_zone%';

这里我选择方案2：修改数据库连接参数

## 原配置

serverTimezone=GMT%2B8

##修改 serverTimezone=Asia/Shanghai 



url: jdbc:mysql://localhost:3306/aurora_admin?useUnicode=true&characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&useSSL=true&serverTimezone=Asia/Shanghai&autoReconnect=true&rewriteBatchedStatements=true&allowMultiQueries=true

到这里，我想着问题肯定已经解决了；愉快的测了一手；
结果还是差八个小时？但是本地项目的时间是正常的啊，我开始有了不祥的预感;
于是我本地连上线上的数据库开始测试，发现时间是正常的。
到这里，就基本排查出不是MySQL的问题；

2、排查 Linux

我开始怀疑是不是 linux 系统的时区有问题；

查看硬件的时间：hwclock --show

查看系统的时间： date -R

发现Linux的时间四年没问题的，于是开始查服务器的时区配置
查看时区 TZ配置：echo $TZ

发现为空，于是查看系统配置；
查看系统配置命令：env

发现确实没有 TZ 的配置，现并未设置TZ变量，而是通过localtime指定时区；于是我修改 localtime的指定

先删除TZ环境变量：unset TZ

再执行： ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
命令etc目录下创建名称是localtime的快捷键指定到上海时区文件上；

修改完成后，果断重启项目测试，结果令人失望，时间依旧没有变化，于是尝试直接加上 TZ配置

命令：export TZ=Asia/Shanghai

再次查看：

可以看到 TZ配置已经设置成功，到这里我似乎看到了希望；于是再次测试，然后我人傻了，时间依旧少八个小时；
到这里，我实在是不知道还有什么是没排查的了，于是脑海里重新过一遍排查的过程，
1、本地连线上的数据库测试是正常的，所以数据库肯定是没问题的，
2、项目程序也没问题： @JsonFormat(）并没有指定其他时区，字段类型也对的上；
3、Linux时间也没问题，时区也设置了；

3、排查Docker

我突然想到项目是通过Docker 来构建的，难道是Docker内部的时区有问题，这是唯一还没有排查的地方了，于是查看Dockerfile配置文件

很简单的配置呀，没理由出问题呀，为了保险起见；决定手动给他指定一个时区，最终的配置文件；
添加配置：

# 安装tzdata(如果 设置时区不生效使用)

# RUN apk add --no-cache tzdata

# 设置时区

ENV TZ="Asia/Shanghai"

重新构建项目运行，再次测试，时间正常了，

总结

整个排查过程虽然艰辛，但好在是解决了，我们在排查问题的时候，一定要胆大心细，多个地方考虑，很小伙伴可能想到是数据库的问题，但是发现修改配置后依然不行，可能会想是不是数据库版本问题呀，或者是不是我们项目哪儿写的有问题呀，把代码，配置看了一遍又一遍，虽然有这个可能，但是我们的思想就局限到这个地方了，就不敢去想，或者不愿去相信会是服务器问题，或其他的问题；我们应该培养这种发散的思想。

JDK1.7的线程安全问题

JDK7版本的HashMap底层采用数组加链表的形式存储元素，假设需要存储的键值对通过计算发现存放的位置已经有元素了，那么HashMap就会用头插法将新节点插入到这个位置。

这一点我们可以从put方法去验证，它会根据key计算获得元素的存放位置，如果位置为空则直接调用addEntry插入，如果不为空，则需要判断该位置的数组是否存在一样的key。如果存在key一致则覆盖并返回，若遍历当前索引的整个链表都不存在一致的key则通过头插法将元素添加至链表首部。

public V put(K key, V value) {

    //判断是否是空表

    if (table == EMPTY_TABLE) {

        //初始化

        inflateTable(threshold);

    }

    //判断是否是空值

    if (key == null)

        return putForNullKey(value);

    int hash = hash(key);

    int i = indexFor(hash, table.length);

     //得到元素要存储的位置table[i]，如果位置不为空则进行key比对，若一样则进行覆盖操作并返回，反之继续向后遍历，直到走到链表尽头为止

    for (Entry<K,V> e = table[i]; e != null; e = e.next) {

        Object k;

        if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {

            V oldValue = e.value;

            e.value = value;

            e.recordAccess(this);

            return oldValue;

        }

    }

    modCount++;

    //封装所需参数，准备添加

    addEntry(hash, key, value, i);

    return null;

}

addEntry方法是完成元素插入的具体实现，它会判断数组是否需要扩容，如果不需要扩容则直接调用createEntry，如果需要扩容，会将容量翻倍，然后调用createEntry通过头插法将元素插入。

void addEntry(int hash, K key, V value, int bucketIndex) {

    //判断是否需要扩容

    if ((size >= threshold) && (null != table[bucketIndex])) 

        //扩容

        resize(2 * table.length);

        //重新计算hash值

        hash = (null != key) ? hash(key) : 0;

        //计算所要插入的桶的索引值

        bucketIndex = indexFor(hash, table.length);

    }

    //使用头插法将节点插入

    createEntry(hash, key, value, bucketIndex);

}

那么当HashMap扩容的时候，它具体会如何实现呢？且看下文源码分析

void resize(int newCapacity) {

        Entry[] oldTable = table;

        int oldCapacity = oldTable.length;

        

        if (oldCapacity == MAXIMUM_CAPACITY) {

            threshold = Integer.MAX_VALUE;

            return;

        }



		//创建新的容器

        Entry[] newTable = new Entry[newCapacity];

        //将旧的容器的元素转移到新数组中

        transfer(newTable, initHashSeedAsNeeded(newCapacity));

        table = newTable;

        threshold = (int)Math.min(newCapacity * loadFactor, MAXIMUM_CAPACITY + 1);

    }

可以看出它会根据newCapactity创建出一个新的容器newTable，然后将原数组的元素通过transfer方法转移到新的容器中。接下来我们看看transafer的源码：

void transfer(Entry[] newTable, boolean rehash) {

        int newCapacity = newTable.length;

        for (Entry<K,V> e : table) {

            while(null != e) {

            //记录要被转移到新数组的e节点的后继节点

                Entry<K,V> next = e.next;

                if (rehash) {

                    e.hash = null == e.key ? 0 : hash(e.key);

                }

                //计算e节点要存放的新位置i

                int i = indexFor(e.hash, newCapacity);

                //e的next指针指向i位置的节点

                e.next = newTable[i];

                //i位置的指针指向e

                newTable[i] = e;

                //e指向后继，进行下一次循环转移操作

                e = next;

            }

        }

    }

那么通过源码了解整体过程之后，接下来我们来聊聊今日主题，JDK1.7中HashMap在多线程中容易出现死循环，下面我们从这段代码分析死循环的情况。

public class HashMapDeadCycle {



    public static void main(String[] args) {

        HashMapThread thread0 = new HashMapThread();

        HashMapThread thread1 = new HashMapThread();

        HashMapThread thread2 = new HashMapThread();

        HashMapThread thread3 = new HashMapThread();

        HashMapThread thread4 = new HashMapThread();

        thread0.start();

        thread1.start();

        thread2.start();

        thread3.start();

        thread4.start();

    }

}



class HashMapThread extends Thread {

    private static final AtomicInteger ATOMIC_INTEGER = new AtomicInteger();

    private static final Map<Integer, Integer> MAP = new HashMap<>();



    private static final Integer SIZE = 1000_000;



    @Override

    public void run() {

        while (ATOMIC_INTEGER.get() < SIZE) {

            MAP.put(ATOMIC_INTEGER.get(), ATOMIC_INTEGER.get());

            ATOMIC_INTEGER.incrementAndGet();

        }

    }

}

上诉代码就是开启多个线程不断地进行put操作，然后AtomicInteger和HashMap全局共享，运行几次后就会出现死循环。
运行过程中可能还会出现数组越界的情况

当出现死循环后我们可以通过jps和jstack命令来分析死循环的情况。

在上图中我们从堆栈信息可以看到死循环是发生在HashMap的resize方法中，根源在transfer方法中。transfer方法在对table进行扩容到newTable后，需要将原来数据转移到newTable中，使用的是头插法，也就是链表的顺序会翻转，这里也是形成死循环的关键点。我们不妨通过画图的方式来了解一下这个过程。
我们假设map的sieze=2，我们插入下一个元素到0索引位置时发现，0索引位置的元素个数已经等于2，此时触发扩容。

于是创建了一个两倍大小的新数组

在迁移到新容器前，会使用e和next两个指针指向旧容器的元素

此时经过哈希计算，旧容器中索引0位置的元素存到新容器中的索引3上。e的next指向新容器中的索引i位置上，由于是第一次插入，newTable[i]实际上等于NULL。因为有next指向，所以当e指向的元素插入到新数组中时指向消失，next指向的元素不会被垃圾清除。

此时新数组i索引位置的指针指向e，此时逻辑上e已经存在到新数组中。

此时e指向next，然后准备下一次的插入

因为当前e没有后继节点，故而next指向null；此时当前e节点经过计算，位置也是在3索引，所以next域指向3索引头节点

此时新数组i索引位置的指针指向当前的e，完成迁移，此时循环发现next为null结束本次循环，继而迁移旧容器的其他索引位置的节点。

上诉就是单线程情况正常扩容的一个流程，但是在多线程情况下会出现什么呢，我们这里简化假设只有两个线程同时执行操作。
未resize前的数据结构如下:

我们假设线程A，执行到Entry<K,V> next = e.next;时线程被挂起，此时线程A的新容器和旧容器如下图所示:

线程A挂起后，此时线程B正常执行，并完成resize操作，结果如下：

此时切换到线程A，在线程A挂起时内存中值如下：e指向3，next指向7，此时结果如下：

接下来我们不妨按照代码逻辑继续往下看，首先e的next域指向头节点，此时3的next指针指向7，可以看到此时7和3构成了一个环，

我们接着往下看，执行 newTable[i] = e;代码，此时将3插入到7前面；

然后e指向next，而next为7，再次循环，此时e.next=3，而在上次循环中3.next=7，出现环形链表，构成一个死循环，最终导致CPU100。

JDK1.8的线程安全问题

JDK1.8中对HashMap进行了优化，发生hash碰撞时不再采用头插法，而是使用尾插法，因此不会出现环形链表的情况，但是JDK1.8就安全了吗？
我们来看看JDK1.8中的put操作代码，整体逻辑大概可以分为四个分支：

1. 如果没有hash碰撞，则直接插入元素


2. 如果算出来索引位置有值且转成红黑树则调用插入红黑树节点的方法完成插入


3. 如果算出来索引位置有值且转为链表则遍历链表将节点插入到末端。


4. 如果key已存在则覆盖原有的value

final V putVal(int hash, K key, V value, boolean onlyIfAbsent,

                   boolean evict) {

        Node<K,V>[] tab; Node<K,V> p; int n, i;

        if ((tab = table) == null || (n = tab.length) == 0)

            n = (tab = resize()).length;

            //如果没有hash碰撞，则直接插入元素

        if ((p = tab[i = (n - 1) & hash]) == null)

            tab[i] = newNode(hash, key, value, null);

        else {

            Node<K,V> e; K k;

            if (p.hash == hash &&

                ((k = p.key) == key || (key != null && key.equals(k))))

                e = p;

                //如果算出来索引位置有值且转成红黑树则调用插入红黑树节点的方法完成插入

            else if (p instanceof TreeNode)

                e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);

            else {

            //如果算出来索引位置有值且是链表则遍历链表，将节点追加到末端

                for (int binCount = 0; ; ++binCount) {

                    if ((e = p.next) == null) {

                        p.next = newNode(hash, key, value, null);

                        if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st

                            treeifyBin(tab, hash);

                        break;

                    }

                    //如果key已存在则覆盖原有的value

                    if (e.hash == hash &&

                        ((k = e.key) == key || (key != null && key.equals(k))))

                        break;

                    p = e;

                }

            }

            if (e != null) { // existing mapping for key

                V oldValue = e.value;

                if (!onlyIfAbsent || oldValue == null)

                    e.value = value;

                afterNodeAccess(e);

                return oldValue;

            }

        }

        ++modCount;

        if (++size > threshold)

            resize();

        afterNodeInsertion(evict);

        return null;

    }

其中这段代码不难看出有点问题

		//如果没有hash碰撞，则直接插入元素

        if ((p = tab[i = (n - 1) & hash]) == null)

            tab[i] = newNode(hash, key, value, null);

假设有两个线程A、B都在进行put操作，并且算出来的插入下标一致，当线程A执行完上面这段代码时时间片耗尽被挂起，此线程B抢到时间片完成插入元素，然后线程A重新获得时间片继续往下执行代码，直接插入，这就会导致线程B插入的数据被覆盖，从而线程不安全。接下来我们画图加深理解。
1.线程A执行到 if ((p = tab[i = (n - 1) & hash]) == null)，判断到索引2为空后被挂起。

2.线程B判断到索引也是2且为空后执行完代码直接插入。

3.线程1被唤醒执行后续逻辑，这就会导致线程2的key被覆盖。

那么下面我们从这段代码验证一下键值对覆盖问题，创建一个size为2的map，然后设置两个线程A、B往map同一个索引位置插入数据。

public class DeadCycle {

    private static final HashMap<String, String> MAP = new HashMap<>(2, 1.5f);

    public static void main(String[] args) throws InterruptedException {



        CountDownLatch countDownLatch = new CountDownLatch(2);



        new Thread(() -> {

            MAP.put("3", "zayton");

            countDownLatch.countDown();

        }, "t1").start();



        new Thread(() -> {

            MAP.put("5", "squid");

            countDownLatch.countDown();

        }, "t2").start();

        

        countDownLatch.await();



        System.out.println(MAP.get("3"));

        System.out.println(MAP.get("5"));

        

    }

}

在put方法中的if ((p = tab[i = (n - 1) & hash]) == null)处打上断点，然后调试模式设置为thread，设置条件

"t1".equals(Thread.currentThread().getName())||"t2".equals(Thread.currentThread().getName()) 

然后启动程序，当t1完成判断，准备创建节点时将线程切换成t2。

可以看到t2将(5,squid)键值对准备放入数组中，然后我们放行代码。

此时线程自动切换成t1，t1再上面已经完成判断认为当前索引位置的数组为null，所有在这里可以看到t2插入的键值对被覆盖成了(3,zayton)

此时放行代码，然后可以看出map.get("5")为null，即验证了hashMap在多线程情况下会出现索引覆盖问题。

参考文献

面试官：HashMap 为什么线程不安全？
大厂常问的HashMap线程安全问题，看这一篇就够了！

在众多程序猿中，存在一个令人头痛的问题：为什么90%的人编写的登录接口都存在安全风险？这个问题很值得探讨。或许是因为这些开发者过于自信，认为自己的代码无懈可击，或者是因为他们缺乏安全意识，未意识到安全问题的重要性。然而，这种做法是非常危险的，因为一个不安全的登录接口可能会威胁用户的安全和隐私。那么，为什么在编写登录接口时总容易出现安全漏洞呢？很可能是因为这些程序猿过于注重代码的功能性和实现细节，却忽视了安全问题的重要性，或者对安全措施缺乏足够的了解。这种情况下，他们很少考虑登录接口可能存在的安全问题，或者没有意识到潜在的严重后果。在这种情况下，网络安全员就显得非常重要了。他们是保护登录接口安全的专家，可以帮助程序员识别潜在的安全风险并提出有效的解决方案，从而提高整个系统的安全性。网络安全员需要考虑哪些安全风险呢？

首先，存在SQL注入攻击漏洞的风险。如果程序猿没有对输入参数进行处理，就可能被利用生成有害的SQL语句来攻击网站。其次，不添加盐值的密码处理是另一个安全风险。如果程序员未将随机盐值结合在密码中，可能会因"彩虹表"破解而带来风险。这种情况下，攻击者可以对密码进行逆向破解，并进一步攻击其他网站。第三，存在页面跨站点攻击（XSS）漏洞的风险。如果程序员未对输入的HTML文本进行过滤，就可能受到XSS攻击。这种情况下，攻击者可以注入有害代码到HTML页面中，在用户浏览页面时盗取用户信息。最后，缺乏防止暴力破解的保护措施也是一个常见的安全问题。如果程序员未对登录失败次数进行限制，就会存在暴力破解风险，攻击者可以尝试多次猜测用户名和密码进行登录，进而对密码进行暴力破解。总而言之，对于程序猿来说，编写一个安全的登录接口非常重要。如果你还没有特别的网络安全背景，也不用担心，本文将为你针对以上几种安全风险列出相对应的措施，帮助你提高系统的安全性，保障用户安全。

一、对于SQL注入攻击的安全风险：

解决方案：使用预定义的SQL语句，避免直接使用用户输入的值。另外，为了增加数据安全性，可以使用参数化查询语句，而非拼接SQL语句的方式。角色和设定：程序猿需要与数据库管理员共同开发或执行安全方案，并规定非法字符与关键字的过滤编码方法。

PreparedStatement statement = connection.prepareStatement("SELECT * FROM table_name WHERE column_name = ?");

statement.setString(1, userInput);

ResultSet resultSet = statement.executeQuery();

二、对于不添加盐值的密码处理安全风险：

解决方案：使用密码哈希和盐值加密技术进行密码处理，以避免针对单一密钥的攻击和彩虹表攻击。

角色和设定：程序猿需要与安全管理员共同开发或实现密码处理方案，并规定随机盐值的生成方法。

public String getHashedPassword(String password, String salt) {

    String saltedPassword = password + salt;

    MessageDigest messageDigest = MessageDigest.getInstance("SHA-256");

    byte[] hash = messageDigest.digest(saltedPassword.getBytes(StandardCharsets.UTF_8));

    return new String(Base64.getEncoder().encode(hash));

}

三、对于页面跨站点攻击（XSS）风险：

解决方案：过滤用户提供的所有输入，特别是HTML文本，以防止恶意脚本被注入。可以使用现有的工具库，如JSoup、OWASP ESAPI等，来过滤并转义HTML文本和特殊字符。

角色和设定：程序猿需要与Web管理员共同配置和使用预定义的规则，以及相应的过滤编码方法。

String unsafeHtml = "<script>alert("Hello, world!");</script>";

String safeHtml = Jsoup.clean(unsafeHtml, Whitelist.basic());

四、对于缺乏防止暴力破解的保护措施风险：

解决方案：使用失败次数限制、暂停时间间隔等措施，防止暴力破解攻击。另外，可以使用多因素身份验证来增强登录安全性。

角色和设定：Java开发人员需要与安全管理员共同开发或实现防止暴力破解的策略，并规定每个账户的限制尝试次数。

public class LoginService {

    private Map<String, Integer> failedAttempts = new HashMap<>();

    private final int MAX_ATTEMPTS = 3;

​

    public boolean validateCredentials(String username, String password) {

        // 根据数据库验证凭据

    }

​

    public boolean isAccountLocked(String username) {

        Integer attempts = failedAttempts.get(username);

        if (attempts != null && attempts >= MAX_ATTEMPTS) {

            return true;

        }

        return false;

    }

​

    public boolean processLogin(String username, String password) {

        if (isAccountLocked(username)) {

            throw new AccountLockedException("Account is locked due to too many failed attempts.");

        }

        boolean result = validateCredentials(username, password);

        if (!result) {

            if (!failedAttempts.containsKey(username)) {

                failedAttempts.put(username, 1);

            } else {

                failedAttempts.put(username, failedAttempts.get(username) + 1);

            }

        } else {

            // 重置失败尝试计数器

            failedAttempts.remove(username);

        }

        return result;

    }

}

程序猿需要注重安全问题，并积极与网络安全员合作，以确保登录接口的安全性和系统可靠性。同时，他们需要不断加强自己的技能和知识，以便适应不断变化的安全需求和挑战。

除了以上列举的安全风险和解决方案，还有一些其他的安全措施也需要注意。比如，程序猿需要确保应用程序和系统组件的版本都是最新的，以修复已知的漏洞并增强安全性。另外，程序猿还需要对敏感信息进行正确的管理和保护，如用户密码、个人身份信息等。在这种情况下，可以使用加密技术、访问控制等手段来保护敏感信息的安全。例如，在应用程序中使用HTTPS加密协议来保护数据传输过程中的安全性。此外，Java开发人员还需要定期进行代码安全审查、漏洞扫描等工作，以及建立相应的应急响应计划，以应对可能出现的安全漏洞和攻击行为。总之，Java开发人员需要以安全为先的理念，全面提高安全性意识和技能水平，与网络安全员密切合作和交流，从而保障系统和用户的安全。

网络安全是一个不断发展和变化的领域，Java开发人员需要不断跟进新的安全趋势和技术，以保证系统和应用程序的安全性。以下是一些建议，可供Java开发人员参考：

1. 学习网络安全基础知识，包括常见的安全漏洞、攻击技术、安全协议等。

2. 使用安全的编码实践，如输入验证、错误处理、数据加密、访问控制等，以提高代码的健壮性和安全性。3. 阅读应用程序和系统组件的文档、安全更新和漏洞报告，及时修复已知的漏洞和安全问题。


3. 定期进行代码安全审查和漏洞扫描，及时发现和修复潜在的安全漏洞，防止恶意攻击。


4. 使用最新的开发工具和库，以快速构建和部署安全性可靠的应用程序和系统组件。


5. 将安全性融入软件开发生命周期中，包括需求分析、设计、开发、测试和部署等方面。7. 与网络安全专家紧密合作，了解系统和应用程序的安全性状态，及时采取必要的措施，防止安全漏洞和攻击。总之，Java开发人员需要具备一定的安全意识和技能，以建立安全性可靠的应用程序和系统组件，从而保护用户的隐私和数据安全，促进信息化建设的可持续发展。

此外，Java开发人员还需要关注一些特定的安全问题，如：1. 跨站脚本攻击（XSS）：XSS是一种常见的Web攻击方式，攻击者通过注入恶意脚本，窃取用户的敏感信息或欺骗用户执行某些恶意操作。Java开发人员应该使用输入验证和输出编码等技术，过滤用户的输入和输出，避免XSS攻击。2. SQL注入攻击：SQL注入攻击是一种网络攻击方式，攻击者通过注入SQL语句，窃取或破坏数据库中的数据。Java开发人员应该避免使用拼接SQL语句的方式来操作数据库，而是应该使用参数化查询或ORM框架等技术，避免SQL注入攻击。3. 不安全的密钥管理：Java应用程序中使用的加密技术通常需要密钥来保护敏感信息，例如SSL证书、对称加密密钥等。Java开发人员需要正确管理密钥和证书，避免泄漏和被攻击者恶意利用。4. 未授权的访问：Java应用程序中可能包含一些敏感的资源、函数或API，需要进行授权才能访问。Java开发人员应该使用访问控制等技术，限制未经授权的访问，从而保护系统和应用程序的安全性。总之，Java开发人员需要不断提高自己的安全意识和技能，了解新的安全趋势和技术，避免常见的安全漏洞和攻击，保护应用程序和系统组件的安全可靠性。

在使用 Redis 的过程中，如果未能及时发现并处理 Big keys（下文称为“大Key”），可能会导致服务性能下降、用户体验变差，甚至引发大面积故障。

本文将介绍大Key产生的原因、其可能引发的问题及如何快速找出大Key并将其优化的方案。

一、大Key的定义

在Redis中，大Key是指占用了较多内存空间的键值对。大Key的定义实际是相对的，通常以Key的大小和Key中成员的数量来综合判定，例如：

graph LR

A(大Key)

B(Key本身的数据量过大)

C(Key中的成员数过多)

D(Key中成员的数据量过大)

E(一个String类型的Key 它的值为5MB)

F(一个ZSET类型的Key 它的成员数量为1W个)

G(一个Hash类型的Key 成员数量虽然只有1K个但这些成员的Value总大小为100MB)



A --> B --> E

A --> C --> F

A --> D --> G



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

style F fill:#B2FFFF,stroke:#B2FFFF,stroke-width:2px

style G fill:#E6E6FA,stroke:#E6E6FA,stroke-width:2px

注意：上述例子中的具体数值仅供参考，在实际业务中，您需要根据Redis的实际业务场景进行综合判断。

二、大Key引发的问题

当Redis中存在大量的大键时，可能会对性能和内存使用产生负面影响，影响内容包括

• 
  

  客户端执行命令的时长变慢。

  
  


• 
  

  Redis内存达到maxmemory参数定义的上限引发操作阻塞或重要的Key被逐出，甚至引发内存溢出（Out Of Memory）。

  
  


• 
  

  集群架构下，某个数据分片的内存使用率远超其他数据分片，无法使数据分片的内存资源达到均衡。

  
  


• 
  

  对大Key执行读请求，会使Redis实例的带宽使用率被占满，导致自身服务变慢，同时易波及相关的服务。

  
  


• 
  

  对大Key执行删除操作，易造成主库较长时间的阻塞，进而可能引发同步中断或主从切换。

  
  

上面的这些点总结起来可以分为三个方面：

graph LR

A(大Key引发的问题)

B(内存占用)

C(网络传输延迟)

D(持久化和复制延迟)



A ---> B

A ---> C

A ---> D



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

三、大Key产生的原因

未正确使用Redis、业务规划不足、无效数据的堆积、访问量突增等都会产生大Key，如：

• 
  

  在不适用的场景下使用Redis，易造成Key的value过大，如使用String类型的Key存放大体积二进制文件型数据；

  
  


• 
  

  业务上线前规划设计不足，没有对Key中的成员进行合理的拆分，造成个别Key中的成员数量过多；

  
  


• 
  

  未定期清理无效数据，造成如HASH类型Key中的成员持续不断地增加；

  
  


• 
  

  使用LIST类型Key的业务消费侧发生代码故障，造成对应Key的成员只增不减。

  
  

上面的这些点总结起来可以分为五个方面：

graph LR

A(大Key产生的原因)

B(存储大量数据)

C(缓存过期策略错误)

D(冗余数据)

E(序列化格式选择不当)

F(数据结构选择不当)



A ---> B

A ---> C

A ---> D

A ---> E

A ---> F



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

style F fill:#B2FFFF,stroke:#B2FFFF,stroke-width:2px

四、如何快速找出大Key

要快速找出Redis中的大键，可以使用Redis的命令和工具进行扫描和分析。以下是一些方法：

• 
  

  使用Redis命令扫描键：Redis提供了SCAN命令，可以用于迭代遍历所有键。您可以使用该命令结合适当的模式匹配来扫描键，并在扫描过程中获取键的大小（使用MEMORY USAGE命令）。通过比较键的大小，您可以找出占用较多内存的大键。

  
  


• 
  

  使用Redis内存分析工具：有一些第三方工具可以帮助您分析Redis实例中的内存使用情况，并找出大键。其中一种常用的工具是Redis的官方工具Redis Memory Analyzer (RMA)。您可以使用该工具生成Redis实例的内存快照，然后分析快照中的键和它们的大小，以找出大键。

  
  


• 
  

  使用Redis命令和Lua脚本组合：您可以编写Lua脚本，结合Redis的命令和Lua的逻辑来扫描和分析键。通过编写适当的脚本，您可以扫描键并获取它们的大小，然后筛选出大键。

  
  

现在大部分都是使用的云Redis，其本身一般也提供了多种方案帮助我们轻松找出大Key，具体可以参考一下响应云Redis的官网使用文档。

五、大Key的优化方案

大Key会给我们的系统带来性能瓶颈，所以肯定是要进行优化的，那么下面来介绍一下大Key都可以怎么优化。

5.1 对大Key进行拆分

例如将含有数万成员的一个HASH Key拆分为多个HASH Key，并确保每个Key的成员数量在合理范围。在Redis集群架构中，拆分大Key能对数据分片间的内存平衡起到显著作用。

5.2 对大Key进行清理

将不适用Redis能力的数据存至其它存储，并在Redis中删除此类数据。

注意

• 
  

  Redis 4.0及之后版本：可以通过UNLINK命令安全地删除大Key甚至特大Key，该命令能够以非阻塞的方式，逐步地清理传入的Key。

  
  


• 
  

  Redis 4.0之前的版本：建议先通过SCAN命令读取部分数据，然后进行删除，避免一次性删除大量key导致Redis阻塞。

  
  

5.3 对过期数据进行定期清理

堆积大量过期数据会造成大Key的产生，例如在HASH数据类型中以增量的形式不断写入大量数据而忽略了数据的时效性。可以通过定时任务的方式对失效数据进行清理。

注意：在清理HASH数据时，建议通过HSCAN命令配合HDEL命令对失效数据进行清理，避免清理大量数据造成Redis阻塞。

5.4 特别说明

如果你用的是云Redis服务，要注意云Redis本身带有的大key的优化方案

六、总结

本文介绍了大Key在Redis中的定义以及可能引发的问题。介绍了快速找出大Key的方法以及对于大Key的优化方案。通过合理的优化方案，可以提升Redis的性能和用户体验。

希望本文对您有所帮助。如果有任何错误或建议，请随时指正和提出。

同时，如果您觉得这篇文章有价值，请考虑点赞和收藏。这将激励我进一步改进和创作更多有用的内容。

感谢您的支持和理解！

是的，我就是那个背着公司偷偷出去面试的小猪佩琪。上次被面试官蹂躏了一顿后，回去好好的恶补一下，然后准备继续战斗。我的誓言：地球不毁灭，宇宙不爆炸，那就越挫越勇的面试下去吧。

由于简历上的自我介绍和技术栈里，写了精通高并发和分布式系统架构，还很低调的写了熟悉redis（是的，没敢写精通），然后被敏锐的面试官，似乎抓到了简历上亮点；然后就是一阵疯狂的灵魂拷问redis的问题。面试官很低调的开口就问了我一个问题：你们数据库里的数据和缓存是如何保持一致的？

我不假思索，条件反射般的立刻回答到：在操作数据库成功后，立刻就操作缓存，以此来让他们保持一致。然后面试官就让我回去等通知了，然后就没有然后了。。。。。。

目前业界里有哪些方案，让数据库和缓存的数据保持一致了？

大概有以下四种

大厂模式（监听binlog+mq）

大厂模式主要是通过监听数据库的binlog(比如mysql binlog)；通过binlog把数据库数据的更新操作日志（比如insert,update,delete），采集到后，通过MQ的方式，把数据同步给下游对应的消费者；下游消费者拿到数据的操作日志并拿到对应的业务数据后，再放入缓存。

大概流程图：

优点：

1、把操作缓存的代码逻辑，从正常的业务逻辑里解耦出来；业务代码更加清爽和简洁，两者互不干扰和影响，独立发展。用非人类的话说，减少对业务代码的侵入性。

2、曾经有幸在大厂里实践过此种方案，速度还贼快，虽然从库到缓存经过了类canel和mq中间件，但基本上耗时都是在毫秒级，99.9%都是10毫秒内能完成库里的数据和缓存数据同步（大厂的优势出来了）

缺点：

1、技术方案和架构，非常复杂

2、中间件的运维和维护，是个不小的工作量

3、由于引入了MQ需要解决引入MQ后带来的问题。比如数据乱序问题：同一条数据先发后至，后发先至的到达消费者后，从而引起的MQ乱序消费问题。但一般都能解决（比如通过redis lua+数据的时间戳比较方案，解决并发问题和数据乱序问题）

在大厂里，不缺类似canel这种伪装为数据库slave节点的自研中间件，并且大厂里也有足够的技术高手+物料，运维资源更是不缺；对小厂来说，慎用吧。

中小厂模式（定时+增量查询）

定时更新+增量查询：主要是利用库里行数据的更新时间字段+定时增量查询。

具体为：每次更新库里的行数据，记录当前行的更新时间；然后把更新时间做为一个索引字段（加快查询速度嘛）

定时任务：会每隔5秒钟（间隔时间可自定义）；把库里最近更新5秒钟的数据查询出来；然后放入缓存，并记录本次查询结束时间。

整个查询过程和放入缓存的过程都是单线程执行；所以不会存在并发更新缓存问题。另外每次同步成功后，会记录同步成功时间；下次定时任务再执行时，会拿上次同步成功时间，做为本次查询开始时间条件；当前时间做为查询结束时间，以此达到增量查询的目标。

再加上查询条件里更新时间是个索引，性能也差不到哪里去。

即使偶尔的定时任务执行失败或者没有执行，也不会丢失数据，只要定时任务恢复了。

优点：

1、实现方案，和架构很简单。是的，比起大厂那套方案，简直不要太轻量。

2、也能把缓存逻辑和业务逻辑进行解耦

3、三方依赖也比较少。如果有条件可以上个分布式定时中间件比如 xxl-job，实在不行就用redis做个分布式锁也能用

缺点：

1、数据库里的数据和缓存中数据，会在极短时间内，存在不一致，但最终会是一致的。这个极短的时间，取决于定时调度间隔时间，一般在秒级。

2、如果是分库分表的业务，编写这个查询逻辑，估计会稍显复杂。

如果业务上不是要求毫秒级的及时性，也不是类似于价格这种非常敏感的数据，这种轻量级方案还真不错。无并发问题，也无数据乱序问题；秒级数据量超过几十万的增量数据并且还需要缓存的，怕是只有大厂才有的场景吧；怎么看此方案都非常适合中小公司。

小厂原始模式（缓存单删）

小厂原始模式，即业界俗称的 缓存删除模式。在更新数据前先删除缓存；然后在更新库，每次查询的时候发现缓存无数据，再从库里加载数据放入缓存。

图 缓存删除

图 缓存加载

此方案主要解决的是佩琪当时在面试回答方案中的弊端；为什么不更新数据时同步进行缓存的更新了？

主要是有些缓存数据，需要进行复杂的计算才能获得；而这些经过复杂计算的数据，并不一定是热点数据；所以采取缓存删除，当需要的时候在进行计算放入缓存中，节省系统开销和缓存中数据量（毕竟缓存容量有限，单价又不像磁盘那样低廉，公司有矿的请忽略这条建议）

另外一个原因：面对简单场景时，缓存删除成功，库更新失败；那么也没有关系，因为读缓存时，如果发现没有命中，会从库里再加载数据放入到缓存里。

优点：

• 此种实现方案简单


• 无需依赖三方中间件


• 缓存中的数据基本能和库里的数据保持一致

缺点：

• 缓存逻辑和正常业务逻辑耦合在一起


• 在高并发的读流量下，还是会存在缓存和库里的数据不一致。见下图

图 缓存单删 数据不一致情况

time1下： T1线程执行缓存删除

time2下： T2线程查询缓存，发现没有，查库里数据，放入缓存中

time3下： T1线程更新库

time4下： 此时数据库数据是最新数据，而缓存中数据还是老版本数据

此方案非常适合业务初期，或者工期较紧的项目；读流量并发不高的情况下，属于万能型方案。

小厂优化模式（延迟双删）

延迟双删其实是为了解决缓存单删，在高并发读情况下，数据不一致的问题。具体过程为：
操作数据前，先删除缓存；接着操作DB；然后延迟一段时间，再删除缓存。

此种方案好是好，可是延迟一段时间是延迟多久了？延迟时间不够长，还是存在单删时，缓存和数据不一致的问题；延迟时间足够长又担心影响业务响应速度。实在是一个充满了玄学的延时时间

优点
1、技术架构上简单

2、不依赖三方中间件

3、操作速度上挺快的，直接操作DB和缓存

缺点
1、落地难度有点大，主要是延迟时间太不好确认了

2、缓存操作逻辑和业务逻辑进行了耦合

此种方案放那个厂子，估计都不太合适，脑壳痛。

方案这么多，我该选择那种方案了？

为了方便大家选择，列了个每种方案的对比图。请根据自身情况进行选择

佩琪你在那里BI了这么久，到底有没有现成的工具呀？

推荐款适合中小公司的缓存加载方案吧。基于Redisson，主要是利用
 MapLoader接口做实现；主要功能：发现缓存里没有，则从数据库加载；（其实自己封装个类似的应该也不难，想偷懒的可以试试）

MapLoader<String, String> mapLoader = new MapLoader<String, String>() {



    @Override

    public Iterable<String> loadAllKeys() {

        List<String> list = new ArrayList<String>();

        Statement statement = conn.createStatement();

        try {

            ResultSet result = statement.executeQuery("SELECT id FROM student");

            while (result.next()) {

                list.add(result.getString(1));

            }

        } finally {

            statement.close();

        }



        return list;

    }



    @Override

    public String load(String key) {

        PreparedStatement preparedStatement = conn.prepareStatement("SELECT name FROM student where id = ?");

        try {

            preparedStatement.setString(1, key);

            ResultSet result = preparedStatement.executeQuery();

            if (result.next()) {

                return result.getString(1);

            }

            return null;

        } finally {

            preparedStatement.close();

        }

    }

};

使用例子

MapOptions<K, V> options = MapOptions.<K, V>defaults()

                              .loader(mapLoader);



RMap<K, V> map = redisson.getMap("test", options);

// or

RMapCache<K, V> map = redisson.getMapCache("test", options);

// or with boost up to 45x times 

RLocalCachedMap<K, V> map = redisson.getLocalCachedMap("test", options);

// or with boost up to 45x times 

RLocalCachedMapCache<K, V> map = redisson.getLocalCachedMapCache("test", options);

总结

数据库和缓存数据保持一致的问题，本质上还是数据如何在多个系统间保持一致的问题。

能不能给我一颗银弹，然后彻底的解决它了？

对不起，没有。请结合自己实际环境，人力，物力，工期紧迫度，技术熟悉度，综合选择。

是的，当我的领导在问我技术方案，在来挑战我缓存和数据库保持一致时，我会把表格扔到他脸上，请选择一个吧，我来做你选择后的实现。

原创不易，请 点赞，留言，关注，转载 4暴击^^

大家好，我是小趴菜，在工作中我们经常要做的一个就是登陆功能，然后获取这个用户的token，后续请求都会带上这个token来验证用户的请求。

问题背景

我们经常使用的JWT就是其中一种，如下

//生成Token  

public static String generateToken(Map<String, Object> payloads) {

        Map<String, Object> map = new HashMap<>(2);

        map.put("alg", "HS256");

        map.put("typ", "JWT");

        Date date = new Date(System.currentTimeMillis() + EXPIRE);

        JWTCreator.Builder jwtBuilder = JWT

                .create()

                .withHeader(map)

                .withExpiresAt(date);

        for (Map.Entry<String, Object> entry : payloads.entrySet()) {

            jwtBuilder.withClaim(entry.getKey(), entry.getValue().toString());

        }

        return jwtBuilder.sign(Algorithm.HMAC256(SECRET));

    }



//校验Token

public static Map<String, Claim> verifyToken(String token) {

    try{

        JWTVerifier verifier = JWT

                .require(Algorithm.HMAC256(SECRET))

                .build();

        DecodedJWT jwt = verifier.verify(token);

        return jwt.getClaims();

    }catch (Exception e){

        throw new GlobalException(ResponseEnums.TOKEN_VERIFY_FAIL_ERROR);

    }

}

我们会给每一个Token设置一个过期时间，前端拿到这个token以后，在之后的用户每一次请求都会带上这个Token进行校验，如果过期了或者Token格式不对，我们就不让请求通过，直接返回错误信息给前端

        //从请求头中拿到token key : token

        String headerToken = request.getHeader(TokenConstant.TOKEN_HEADER);

        if (StrUtil.isBlank(headerToken)) {

            throw new GlobalException(ResponseEnums.TOKEN_IS_NULL_ERROR);

        }

        

        //解析token

        Map<String, Claim> claimMap = JwtUtil.verifyToken(headerToken);

        return true;

    }

这看上去是一件很美好的事情，因为我们解决了用户请求校验的问题，但是这个Token是存储在前端的缓存中的。当我们点击退出登陆的时候，前端也只是把缓存的这个Token给清掉，这样用户后续的请求就没有这个Token，也就会让用户去重新登陆了。这看起来是没有问题的。

但是如果你这个Token还没有过期，这时候你的Token被其他人截取了，这时候，即使你退出登陆但是这个Token一样是可以通过校验的。所以其他人还是可以拿你这个Token去请求对应的接口。这时候就会有安全问题了。那有没有解决办法呢？

解决办法

其实是有的。我们可以把这个Token保存到Redis中。每次请求的时候，判断一下Redis中有没有这个Token，有就放行，没有就返回错误信息给前端。

当用户点击退出登陆的时候，把Redis的这个Token给删除掉就行了，这样后续即使用人截取了你这个Token，由于Redis没有，那么第一步返回fasle，就可以直接返回错误信息给前端，不会去执行这个请求

思考

既然我们使用了Redis那用JWT的意义在哪呢？我们Redis也可以设置过期时间，还可以给Token续期，很多JWT做不到的事Redis都可以做到。那为什么还要使用JWT呢？

提出需求

相信很多时候，你可能有这样的需求，比如A对象的属性1、属性2是你需要的，其余属性是空值，而B对象的属性3、属性4是你需要的，其余属性是空值，那么如何将A对象的属性与B对象的属性结合呢？

思路解析

要实现将两个对象的属性结合，需要用到反射技术，遍历每个对象的属性，将非null的属性复制给null的属性，最后实现合并属性的效果。

常用的复制对象属性的方法（传统方案）

使用Java Bean Utils，这是Apache Commons BeanUtils库中的一个工具类，使用此工具类，则需要自己去实现判断属性的业务逻辑。

这个工具类有两个复制属性的方法，copyProperties和copyProperty。

copyProperties方法会将orig（第二个对象）的属性复制给dest（第二个对象），这种复制是完全复制，会完全覆盖dest的属性。

copyProperty方法将复制value给bean的特定属性。

hutool合并对象的方案

Hutool是一个Java工具包类库，对文件、流、加密解密、转码、正则、线程、XML等JDK方法进行封装，组成各种Util工具类。

hutool常常被广大spring程序员唾弃，抱怨其在项目中的稳定性，bug问题。但我认为，hutool是一个在不断迭代和维护的库，虽然是国内程序员开发的，但是其中很多功能仍然是简单好用的，不能够以偏概全的全面否定它。

回归正题，下面做详细的说明

pom导入合并对象所必须的hutool库

<dependency>

    <groupId>cn.hutool</groupId>

    <artifactId>hutool-core</artifactId>

    <version>5.8.16</version>

</dependency>

方法解释

• cn.hutool.core.bean.BeanUtil

hutool的复制对象方法copyProperties有4个重载类型，在apache common beanutils的基础上，增加了一些复制选项，这些选项是非常实用的，比如忽略大小写、忽略某些属性、某些特定的复制选项等。

copyProperties(Object source, Object target, CopyOptions copyOptions)

因为我实际用了copyProperties(Object source, Object target, CopyOptions copyOptions)，重点讲解此方法的传入参数。

CopyOptions包括以下的一些属性或选项，可以根据你的项目需求来选择

自己写的合并工具类

该工具类仅供参考，可以根据自己情况调整

public class MergeUtil {

    private static final CopyOptions options = CopyOptions.create().setIgnoreNullValue(true).setOverride(false);

    private static final CopyOptions optionsAllowOverride = CopyOptions.create().setIgnoreNullValue(true).setOverride(true);



    //将sourceBean中的属性合并到tagetBean，忽略Null值，非Null值不允许覆盖

    public static Object merge(Object sourceBean, Object targetBean) {

        BeanUtil.copyProperties(sourceBean, targetBean, options);



        return targetBean;

    }



    //将sourceBean中的属性合并到tagetBean，忽略Null值，非Null值允许覆盖

    public static Object mergeAllowOverride(Object sourceBean, Object targetBean) {

        BeanUtil.copyProperties(sourceBean, targetBean, optionsAllowOverride);



        return targetBean;

    }

}

1.这篇文章写什么？

在工作中碰到了这样一个需求，要从数据库里面读取一段时间内，每天某些时刻对应的温度数据，一天可能会设置有多个时间点，导出到excel中的模板需要支持多种格式的，比如一个月，一个季度，上半年，下半年等，并且需要支持灵活的配置导出的时间段范围。超过温度的点需要用红色来进行标识

2.为什么写这篇文章

在工作中碰到了需要导出excel报表的需求，写这篇文章记录从需求到实现的过程，供后续参考和改进

3.如何实现？

要实现导出excel，首先就想到了easyexcel，它可以支持读、写、填充excel，针对现在这个需求，如果需要自定义时间的话可以通过配置字典，前端读取字典用dayjs来进行解析，把解析到的时间范围给到后端，后端再根据时间范围去导出数据，至于excel方面，想到了先用占位符在excel模板中预设好位置，然后用代码进行填充，主要的实现流程就大概有了

4.具体实现

根据上面的主要流程，下面就来进行每一步的细化，首先是前端

4.1 解析时间

通过字典来读取时间范围的代码，至于为什么不用后端来实现，之前也考虑过，不过因为无法确定具体的时间，就没用后端去实现，因为一个月不固定有多少天，不固定有多少周，如果用后端去实现的话可能会得不到准确的时间，反观前端的dayjs，就可以很简单的实现这个功能，通过解析dayjs代码来实现时间的获取，代码如下：

<template>

  <div>

    {{getDates()}}

  </div>

</template>



<script lang="ts" setup>

import dayjs from "dayjs";

const getDates = () =>{

  const str =  "const startTime = dayjs().startOf('year').format('YYYY-MM-DD HH:mm:ss');const endTime = dayjs().endOf('year').format('YYYY-MM-DD HH:mm:ss');return [startTime, endTime]"

  const timeFunc = new Function('dayjs', str);

  const data =  timeFunc(dayjs)

  console.log(data[0])

  console.log(data[1])

  return timeFunc(dayjs)

}

</script>

用str来模拟从字段中读取到的时间范围代码，用dayjs解析出来，这样页面上就会直接打印出当前的时间：
[ "2023-01-01 00:00:00", "2023-12-31 23:59:59" ]

到此，前端解析时间的任务就完成了

4.2 导出excel

万丈高台起于垒土，要实现本次需求，首先要能导出excel，然后再考虑样式，最后再考虑现有可行方案的兼容性，能否兼容多种格式的模板。经过考察官网，发现了两种看起来比较可行和符合目前需求的导出方式：
首先把依赖导入先：

<dependency>  

    <groupId>com.alibaba</groupId>  

    <artifactId>easyexcel</artifactId>  

    <version>3.2.1</version>  

</dependency>

方式1: 定义一个模板，里面就搞几个占位符，每个占位符替换一个内容

直接上代码：

@Test

public void simpleFill() {

    // 模板注意 用{} 来表示你要用的变量 如果本来就有"{","}" 特殊字符 用"\{","\}"代替

    String templateFileName = "F:/excel/" + "simple.xlsx";

    // 方案1 根据对象填充

    String fileName = "F:/excel/" + System.currentTimeMillis() + ".xlsx";

    // 这里会填充到第一个sheet， 然后文件流会自动关闭

    Map<String, Object> map = new HashMap<>();

    map.put("name", "张三");

    map.put("number", 5.2);

    map.put("month", 5);

    EasyExcel.write(fileName).withTemplate(templateFileName)

            .sheet().doFill(map);

}

看效果，替换成功了，能正常替换，这种方式能跑：

方式2 定义一个模板，里面搞几个占位符，以.开头的为循环的占位符

直接上代码：

    @Test

    public void horizontalFill() {

        String templateFileName = "F:/excel/" + "simpleHeng.xlsx";

        String fileName = "F:/excel/" + System.currentTimeMillis() + "heng" + ".xlsx";

        // 方案1

        try (ExcelWriter excelWriter = EasyExcel.write(fileName).withTemplate(templateFileName)

                .build()) {

            WriteSheet writeSheet = EasyExcel.writerSheet().build();

            excelWriter.write(data(),writeSheet);

        }

    }

private List<FillData> data() {

    List<FillData> list = ListUtils.newArrayList();

    for (int i = 0; i < 10; i++) {

        FillData fillData = new FillData();

        list.add(fillData);

        fillData.setName("张三" + i);

        fillData.setNumber(5.2);

        fillData.setDate(new Date());

    }

    return list;

}

@Getter

@Setter

@EqualsAndHashCode

public class FillData {

    private String name;

    private double number;

    private Date date;

}

看效果，替换成功(虽然哪里感觉不对劲)：

现在基本的替换模板实现了，那么就进一步深入，给表格里面的内容添加颜色样式

经过网上搜索了一下，发现自定义样式需要写一个类去实现CellWriteHandler，从而自定义样式

@Slf4j

public class CustomCellWriteHandler implements CellWriteHandler {



    @Override

    public void afterCellDispose(CellWriteHandlerContext context) {

        Cell cell = context.getCell();

        Workbook workbook = context.getWriteWorkbookHolder().getWorkbook();

        CellStyle cellStyle = workbook.createCellStyle();

        Font writeFont = workbook.createFont();

        writeFont.setColor(IndexedColors.RED.getIndex());

        writeFont.setBold(true);

        cellStyle.setFont(writeFont);

        cell.setCellStyle(cellStyle);

        context.getFirstCellData().setWriteCellStyle(null);

    }

}

然后在原有导出代码的基础上加个registerWriteHandler(new CustomCellWriteHandler())

EasyExcel.write(fileName).withTemplate(templateFileName)

        .registerWriteHandler(new CustomCellWriteHandler())

        .sheet().doFill(map);

然后就可以看到导出的效果了

再试试第二种方式，也就是循环写入的，加个样式：

WriteSheet writeSheet = EasyExcel.writerSheet().registerWriteHandler(new CustomCellWriteHandler()).build();

然后导出，发现这种方式的导出的excel未能成功设置颜色，后面也尝试了很多次，确定了这种方式没法带上样式，所以就放弃这种方式了

到这里就只剩下excel中每个位置的都用一个占位符来占位替换的方式了

4.3 实现思路

确定了可行的实现方式，现在就要在这种方式上思考如何实现兼容多种时间段，多种模板的导出。需求中每天可能会设置若干个点，也可能需要导出不同时间段的温度数据，例如月、季度、半年等，或者是其他更细的时间点，每次的模板可能也不大一样，例如下面的几种：

老王的模板

老张的模板

老李的模板

可以看出需要兼容不同的模板确实是个伤脑筋的事情，后面发现了个比较折中的办法：因为目前能实现excel上导出带样式的就只有替换占位符的方法，如何在不改代码的前提下适配多种模板呢，就直接把模板上每个格子都对应一个占位符，只要后端每次都是按照固定规则去生成数据的，那么只要设置好模板里每个格子的占位符就可以解决问题了。只要每次生成数据的顺序都是按照{t1}、{t2}、{t3}这样，依次类推下去，只要模板配置好占位符即可。例如每天一个监测点，那{t1}就对应第一天监测点的温度，{t2}就对应第二天监测点的温度，如果每天两个监测点，那么{t1}和{t2}就分别对应第一天的第一、第二个监测点的温度。这样就可以实现导出月、季度、半年的数据而不用改代码了，如果要导出某个时间段的，例如1月15日到2月15日的，这种时间段的话就使用大一级的模板，使用季度的模板即可兼容。

4.4 代码实现

有了上面的思路，大致实现流程就出来了

4.4.1 前端解析字符串，获取时间范围

这个上面有提及，这里就不再赘述，跳过

4.4.2 后端获取每天配置的时间点

由于配置的时间点是12、13、15这种，并不是具体的一个时间，因此需要结合时间范围来解析成具体的时间，首先需要获取时间段里面的每一天，然后再根据配置的时间点得到每个具体的时间点，获取到了时间点之后就可以去数据库中查询这个时间点对应的数据，模拟代码如下：
首先说明，这里引入了hutool来处理时间

<dependency>  

    <groupId>cn.hutool</groupId>  

    <artifactId>hutool-all</artifactId>  

    <version>5.8.18</version>  

</dependency>

public static void main(String[] args) {

        DateTime startTime = DateUtil.parse("2023-07-01 00:00:00");

        DateTime endTime = DateUtil.parse("2023-10-31 23:59:59");

        List<Date> timeRangeDates = getTimeRangeDates(startTime, endTime);

        List<String> times = Arrays.asList("12");

        Map<DateTime, Float> resultMap = getTemperature(timeRangeDates, times);

    }



    /**

     * 获取要导出数据的Map, key为时间,value为时间对应的值

     *

     * @param timeRangeDates 时间范围

     * @param times          每天定义的时间点

     * @return 导出的map

     */

    private static Map<DateTime, Float> getTemperature(List<Date> timeRangeDates, List<String> times) {

        Map<DateTime, Float> resultMap = new HashMap<>();

        for (Date timeRangeDate : timeRangeDates) {

            for (String time : times) {

                // eg: 12 ==> 2023-11-07 12:00:00

                String tempTime = DateUtil.formatDateTime(timeRangeDate).substring(0, 11) + time + ":00:00";

                DateTime recordTime = DateUtil.parse(tempTime);

                // 如果是将来的时间,就不执行查询,认为是没有数据的

                if (recordTime.isAfter(new Date())) {

                    resultMap.put(recordTime, null);

                    continue;

                }

                // 模拟从数据库拿到的温度,10.5 °C

                resultMap.put(recordTime, selectTemperature());

            }

        }

        return resultMap;

    }



    /**

     * 模拟从数据库查询数据,随机生成2到10之间的一个数字,保留一位小数

     *

     * @return 2到10之间的一个数字, 保留一位小数

     */

    private static float selectTemperature() {

        Random random = new Random();

        float minValue = 2.0f;

        float maxValue = 10.0f;

        float range = maxValue - minValue;

        float randomFloat = (random.nextFloat() * range) + minValue;

        DecimalFormat df = new DecimalFormat("#.0");

        String formattedFloat = df.format(randomFloat);

        return Float.parseFloat(formattedFloat);

    }



    /**

     * 获取起止时间内的每一天

     *

     * @param start 开始时间

     * @param end   结束时间

     * @return 每天

     */

    private static List<Date> getTimeRangeDates(Date start, Date end) {

        List<Date> dates = new ArrayList<>();

        DateTime current = DateUtil.date(start);

        DateTime endTime = DateUtil.date(end);

        while (current.isBefore(endTime)) {

            dates.add(current.toJdkDate());

            current = current.offset(DateField.DAY_OF_MONTH, 1);

        }

        return dates;

    }

经过上面一通操作，就可以得到了一个Map，里面的key是时间点，value是时间点对应的温度。
按道理来说，map已经构造好了，直接编写模板导出就完事了，就在这时，又碰到了一个问题，map上的{t1}、{t2}等占位符如何跟时间匹配的问题，模板上肯定是每个月都以最大的时间来定义，也就是31天，但并不是每个月都有31天，因此要在导出数据的时候把那些应该为空的占位符也计算出来，拿老王的模板来举例子：

今年是2023年，9月只有30天，那么模板上31号的占位符应该导出的时候就应该设置个空值，也就是在碰到{t93}的时候需要把值设置为空，然后再导出excel

完整代码如下：

package com.example.demo.test;



import cn.hutool.core.date.DateField;

import cn.hutool.core.date.DateTime;

import cn.hutool.core.date.DateUtil;

import com.alibaba.excel.EasyExcel;

import com.example.demo.handler.CustomCellWriteHandler;



import java.text.DecimalFormat;

import java.time.YearMonth;

import java.time.ZoneId;

import java.util.*;

import java.util.concurrent.atomic.AtomicInteger;

import java.util.stream.Collectors;



public class ExportTest {



    public static void main(String[] args) {

        DateTime startTime = DateUtil.parse("2023-07-01 00:00:00");

        DateTime endTime = DateUtil.parse("2023-12-31 23:59:59");

        List<Date> timeRangeDates = getTimeRangeDates(startTime, endTime);

        List<String> times = Collections.singletonList("12");

        Map<DateTime, Float> resultMap = getTemperature(timeRangeDates, times);

        // 获取日期范围内的月份

        List<Integer> distinctMonths = getDistinctMonths(timeRangeDates);

        // 获取月份对应的天数

        Map<Integer, Integer> daysInMonths = getDaysInMonths(timeRangeDates);

        // 获取应该置空的下标

        List<Integer> emptyIndexList = getEmptyIndexList(daysInMonths, times.size());

        // 获取理论上一共有多少天,按照一个月31天算

        int totalDaysCount = getTotalDaysCount(distinctMonths, timeRangeDates.size());

        Map<String, Object> exportDataMap = new HashMap<>();

        // i快 j慢

        for (int i = 0, j = 0; i < totalDaysCount; i++) {

            int currentDateIndex = j;

            int currentCount = (i + 1) * times.size() - (times.size() - 1);

            for (String time : times) {

                // 本月不足31天的填充null

                if (emptyIndexList.contains(currentCount)) {

                    exportDataMap.put("t" + currentCount++, null);

                    continue;

                }

                // 12 ==> 2023-10-25 12:00:00

                String tempTime = DateUtil.formatDateTime(timeRangeDates.get(currentDateIndex))

                        .substring(0, 11) + time + ":00:00";

                if (currentDateIndex == j) {

                    j++;

                }

                // 根据date查询数据

                DateTime recordTime = DateUtil.parse(tempTime);

                exportDataMap.put("t" + currentCount++, resultMap.get(recordTime));

            }

        }

        // 模板注意 用{} 来表示你要用的变量 如果本来就有"{","}" 特殊字符 用"\{","\}"代替

        String templateFileName = "F:/excel/" + "老王.xlsx";

        // 方案1 根据对象填充

        String fileName = "F:/excel/" + System.currentTimeMillis() + "老王.xlsx";

        EasyExcel.write(fileName).withTemplate(templateFileName)

                .registerWriteHandler(new CustomCellWriteHandler())

                .sheet().doFill(exportDataMap);

    }



    private static int getTotalDaysCount(List<Integer> distinctMonths, int timeRangeSize) {

        if (timeRangeSize <= 31) {

            return Math.min(distinctMonths.size() * 31, timeRangeSize);

        }

        return distinctMonths.size() * 31;

    }

    

    private static List<Integer> getEmptyIndexList(Map<Integer, Integer> daysInMonths, int pointCount) {

        List<Integer> list = new ArrayList<>();

        AtomicInteger count = new AtomicInteger();

        daysInMonths.forEach((key, value) -> {

            // 本月的开始长度

            int monthLength = count.get();

            // 总本月虚拟长度

            count.addAndGet(31 * pointCount);

            // 本月实际长度

            int realLength = value * pointCount;

            // 本月开始下标

            int startIndex = monthLength + realLength;

            // 多出的下标

            int extraCount = count.get() - realLength - monthLength;

            // 记录需要存空值的占位符位置

            for (int i = startIndex + 1; i <= startIndex + extraCount; i++) {

                list.add(i);

            }

        });

        return list;

    }

    

    /**

     * 获取今年的某些月份的天数

     *

     * @param timeRangeDates 时间范围

     * @return 该月份对应的年

     */

    private static Map<Integer, Integer> getDaysInMonths(List<Date> timeRangeDates) {

        List<Integer> distinctMonths = getDistinctMonths(timeRangeDates);

        Date firstDate = timeRangeDates.get(0);

        Calendar calendar = Calendar.getInstance();

        calendar.setTime(firstDate);

        int currentYear = calendar.get(Calendar.YEAR);

        return distinctMonths.stream()

                .collect(Collectors.toMap(

                        month -> month,

                        month -> YearMonth.of(currentYear, month).lengthOfMonth()

                ));

    }



    /**

     * 获取时间范围内的所有月份、去重、转成String类型

     *

     * @param timeRangeDates 时间范围集合

     * @return 月份集合

     */

    public static List<Integer> getDistinctMonths(List<Date> timeRangeDates) {

        return timeRangeDates.stream()

                .map(date -> date.toInstant().atZone(ZoneId.systemDefault()).toLocalDate().getMonthValue())

                .distinct()

                .sorted()

                .collect(Collectors.toList());

    }



    /**

     * 获取要导出数据的Map, key为时间,value为时间对应的值

     *

     * @param timeRangeDates 时间范围

     * @param times          每天定义的时间点

     * @return 导出的map

     */

    private static Map<DateTime, Float> getTemperature(List<Date> timeRangeDates, List<String> times) {

        Map<DateTime, Float> resultMap = new HashMap<>();

        for (Date timeRangeDate : timeRangeDates) {

            for (String time : times) {

                // eg: 12 ==> 2023-11-07 12:00:00

                String tempTime = DateUtil.formatDateTime(timeRangeDate).substring(0, 11) + time + ":00:00";

                DateTime recordTime = DateUtil.parse(tempTime);

                // 如果是将来的时间,就不执行查询,认为是没有数据的

                if (recordTime.isAfter(new Date())) {

                    resultMap.put(recordTime, null);

                    continue;

                }

                // 模拟从数据库拿到的温度,10.5 °C

                resultMap.put(recordTime, selectTemperature());

            }

        }

        return resultMap;

    }



    /**

     * 模拟从数据库查询数据,随机生成2到10之间的一个数字,保留一位小数

     *

     * @return 2到10之间的一个数字, 保留一位小数

     */

    private static float selectTemperature() {

        Random random = new Random();

        float minValue = 2.0f;

        float maxValue = 10.0f;

        float range = maxValue - minValue;

        float randomFloat = (random.nextFloat() * range) + minValue;

        DecimalFormat df = new DecimalFormat("#.0");

        String formattedFloat = df.format(randomFloat);

        return Float.parseFloat(formattedFloat);

    }



    /**

     * 获取起止时间内的每一天

     *

     * @param start 开始时间

     * @param end   结束时间

     * @return 每天

     */

    private static List<Date> getTimeRangeDates(Date start, Date end) {

        List<Date> dates = new ArrayList<>();

        DateTime current = DateUtil.date(start);

        DateTime endTime = DateUtil.date(end);

        while (current.isBefore(endTime)) {

            dates.add(current.toJdkDate());

            current = current.offset(DateField.DAY_OF_MONTH, 1);

        }

        return dates;

    }

}

自定义设置样式

package com.example.demo.handler;



import com.alibaba.excel.write.handler.CellWriteHandler;

import com.alibaba.excel.write.handler.context.CellWriteHandlerContext;

import lombok.extern.slf4j.Slf4j;

import org.apache.poi.ss.usermodel.*;



@Slf4j

public class CustomCellWriteHandler implements CellWriteHandler {



    @Override

    public void afterCellDispose(CellWriteHandlerContext context) {

        Cell cell = context.getCell();

        double numericCellValue;

        try {

            numericCellValue = cell.getNumericCellValue();

        } catch (Exception e) {

            log.error("解析到了非数值类型,直接返回");

            return;

        }

        if (numericCellValue >= 2 && numericCellValue <= 8) {

            return;

        }

        Workbook workbook = context.getWriteWorkbookHolder().getWorkbook();

        CellStyle cellStyle = workbook.createCellStyle();

        Font writeFont = workbook.createFont();

        writeFont.setColor(IndexedColors.RED.getIndex());

        writeFont.setBold(true);

        cellStyle.setFont(writeFont);

        cell.setCellStyle(cellStyle);

        context.getFirstCellData().setWriteCellStyle(null);

    }

}

运行效果如下：
9月31日有占位符，但是9月只有30日，因此31日无数据，并且数据不在2和8范围之间的数据都可以用红色字体展示

至于返回数据给前端这里就省略了，毕竟文件都能生成了，其他的都是小问题了

5. 小结

本次的设计实现了支持不同模板，按照月(月初到月末)、季度、半年的数据进行导出，初步实现了功能，但是面对更复杂的场景，例如需要支持不同模板在某一段时间的导出功能暂时没法实现。不过也算是积累了一次使用easyexcel导出报表的经验，以此来记录本次开发的过程，为后续类似功能的开发提供借鉴

代码存放链接: gitee.com/szq2021/eas… (主要是怕找不着了,先存着)

小菜的一次接口优化：从68474ms到1329ms

前言

突然，有人大喊一声：小菜，你过来一下

小菜被吓得抖了一抖，连忙切出开发界面，看了一眼，原来是项目经理在喊

小菜屁颠屁颠的过去后

项目经理：小菜，有空你看看后台管理里的商品信息导出Excel功能，导出数据只有几千条但是要等特别久

小菜：没问题，等我忙完手上的活就来看看怎么回事

分析与优化

小菜回到工位后，立马看了看后台管理系统的商品信息导出功能

该功能是通过导入规定格式的Excel（比如商品名称），然后导出这些商品的所有信息

小菜用对应的模板（大概数据量5千）使用此功能，大概等了1分钟多才导出结果

小菜：我可以先用arthas的trace监听这个接口，看看接口里哪些方法耗时，再具体进行分析

使用arthas的trace命令监听端口后，发现总耗时70284ms，其中XXMessage耗时68s，导出Excel花费1.8s

小菜：那具体的业务处理应该在XXMessage里了，我先来看看

     public List<ExportVO> xxMessage(MultipartFile file, HttpServletRequest request, HttpServletResponse response) {

         //导出结果

         List<ExportVO> exportVOS = new ArrayList<>();

         try {

             //EasyExcel 读取模板数据

             //使用AnalysisEventListener 在读取数据时加入导出结果，在读完后进行封装操作

             EasyExcel.read(file.getInputStream(), Product.class, new AnalysisEventListener<Product>() {

                 private final List<Product> list = new ArrayList<>();

 

                 //解析完一行后如何处理

                 @Override

                 public void invoke(Product p, AnalysisContext analysisContext) {

                     doLine(p);

                 }

 

                 //解析完所有数据后如何处理

                 @Override

                 public void doAfterAllAnalysed(AnalysisContext analysisContext) {

                     doAfter();

                 }

             }).sheet().doRead();

         } catch (IOException e) {

             e.printStackTrace();

         }

         return exportVOS;

     }

小菜：使用的EasyExcel读取，那真正的处理应该在实现的AnalysisEventListener中

小菜：让我先来看看每解析一行如何处理的

 //存储要处理的数据

 List<Product> products = new ArrayList<>();

 

 private void doLine(Product data) {

     try {

         //拿到所有使用ExcelProperty的字段 

         List<Field> fields = Arrays.stream(data.getClass().getDeclaredFields())

             .filter(f -> f.isAnnotationPresent(ExcelProperty.class))

             .collect(Collectors.toList());

         

         //判断字段是否为空，为空则集合添加false不为空添加true

         List<Boolean> lines = new ArrayList<>(fields.size());

         for (Field field : fields) {

             field.setAccessible(true);

             Object value = field.get(data);

             if (value == null) {

                 lines.add(Boolean.TRUE);

             } else {

                 lines.add(Boolean.FALSE);

             }

         }

         

         //ExcelProperty的所有字段不为空 就加入集合

         if(lines.stream().allMatch(Boolean.TRUE::equals)){

             products.add(data);

         }

     } catch (Exception e) {

         log.error("parse data fail: " + e.getMessage());

     }

 }

（ExcelProperty注解用于标记表格中的列）

小菜拿出做算法题分析时间复杂度的思路

小菜：这里总共有三个循环分别是：获取使用ExcelProperty的字段、判断每个字段是否为空、allMatch匹配数组中所有元素为true

小菜：那么用时间复杂度表示就是O（3N），N为数据量，而这些集合的数据量则是使用ExcelProperty的字段，好像是固定的，并不会随着Excel表格中数据量的提升而提升，那么可以把它们看成常量，那最终时间复杂度就是常量级别O（1）

小菜：但是还用了反射会有些性能开销

小菜：咦？为啥要判断实体每个字段不为空才加入要处理的集合呢？

小菜：好像直接判断该商品名不为空就可以了吧？

小菜：用反射来实现通用性，难道这段代码是前辈复制的？

于是，小菜洋洋得意的将代码改成：

 //存储要处理的数据

 List<Product> products = new ArrayList<>();

 

 private void doLine(Product data) {

     if (StringUtils.isNotEmpty(data.getProductName())) {

          products.add(data);

     }

 }

为了担心自己改错，小菜还保留原始代码，方便回滚

再来看下解析完数据后的处理方法

小菜看着这一望无际一百多行没有注释、多层if嵌套的代码，整个人都呆了

大致观看了一遍后，小菜将shit mountain代码梳理成以下代码：

 //存储要处理的数据

 List<Product> products = new ArrayList<>();

 

 private void doLine(Product data) {

     if (StringUtils.isNotEmpty(data.getProductName())) {

          products.add(data);

     }

 }

 

 private void doAfter() {

     //要处理的数据为空直接返回

     if (Empty.isEmpty(products)) {

         return;

     }

     

     //循环处理数据

     products.forEach(product->{

         //根据商品名查询出商品列表 IO

         List<Sku> skus = skuService.list(product.getProductName());

         //查到商品数据为空跳过

         if (Empty.isEmpty(skus)) {

             continue;

         }

         

         //查询商品具体数据 IO

         

         //查询分类、规格... IO

         

         //封装实体 添加到导出列表

     });

 }