营销项目--10. 不超卖库存规则实现
1. 秒杀场景和超卖问题在一个高并发的场景下，比如说大营销服务的抽奖活动。可能会有很多用户在同一时间进行某个奖品的获得，比如某个奖品的库存只有10，而很多用户在同一时间都获得了该奖品，如果没有正确的并发控制，可能会卖出比库存更多的奖品 在传统库存扣减场景下如果使用数据库锁在高并发场景下可能会导致 锁导致很多用户等待同一行数据的资源。发生竞争锁资源 如果大量用户都在等待数据库操作，连接资源就会被耗尽，导致服务器响应时间过长甚至崩溃 在这种场景下使用redis管理库存，用一些原子操作避免锁的竞争和等待： 高性能：redis是使用内存存储的，支持高并发，能够应对高访问量 去锁化：在redis中使用一些原子操作避免锁的竞争和等待 Redis中的原子操作decr和setnxdecr: 用于将某个key的值减小1setnx: set if not exists....
HTTP请求方法 GET和POST的区别
HTTP请求方法有哪些？![[Recording 20241024094639.webm]]GET: 从服务器获取资源，包括图片，网页，视频等POST:向服务器提交上传资源，发送一些数据，在服务器端创建新的资源PUT：向服务器更新现有数据HEAD：与GET类似，但是只获取响应头部，也就是判断该资源是否存在DELETE:向服务器删除资源PATCH：和PUT类似，但是只更新部分资源OPTIONS：获取服务器支持的HTTP请求方法 GET和POST的区别是什么？
HTTPS 对称加密和非对称加密
对称加密是什么，非对称加密是什么对称加密即：加密和解密用的是同一个密钥 非对称加密即：加密和解密用的是不同的密钥 —> 公钥负责加密，私钥负责解密。 —> 用公钥加密过的密文，只有用私钥才能解密。 —>...
HTTP缓存 强制缓存 协商缓存
HTTP缓存是因为很多请求的资源有可能已经获得了，那这个时候就没有必要再重复获取了，可以直接在本地服务器获得该资源，缓存可以大幅度降低连接之间的请求资源的时间，带宽等。但是HTTP协议需要一些规定去限定获得资源的时效性。HTTP缓存分为强制缓存和协商缓存 强制缓存强制缓存主要判断点在浏览器也就是客户端。客户端会判断缓存是否过期，没有过期直接返回浏览器的本地缓存。实现字段： Cache-Control和Expires....
HTTP请求报文和响应报文 状态码
HTTP请求报文和响应报文，有哪些关键字段HTTP全称是Hypertext Transfer Protocol 超文本传输协议。也就是在计算机世界里在两点之间传输像图片，文字，视频，网页等超文本的规范和约定。HTTP协议也是在网络模型中的应用层，是用户直接参与的一层协议。HTTP请求报文包括请求行，请求头，请求体。请求行包括HTTP协议和请求方法以及URI： GET WWW.baidu.com HTTP1.1请求头是一系列键值对组成，是HTTP连接的一系列参数，比如Connection: keep-alive就是HTTP1.1中的保持持久化连接。以及像HOST就是请求的主机名，User-Agent: 就包括了一系列客户端的类型信息。请求体是一些请求参数，这个是可选项，比如GET方法就将请求参数放在了URL中![[Recording...
营销项目--9. 模板模式串联抽奖规则
通过模板模式，整合责任链、规则树，定义出抽奖的标准过程。以及让子类做具体调用功能实现。将上一节中的规则树结构设计整合到抽奖过程中。这样整个抽奖过程就会包括：责任链进行抽奖前的规则过滤并计算抽奖结果，基于抽奖结果再进行规则树的过滤，最终返回抽奖结果 开发流程 增加3个po，组装树的po 增加3个po对应的dao操作 视频7分钟 定义dao 对应的mybatis mapper，映射到mysql，并集中在RuleTreeDaoTest中测试，发现了一个bug，在[[Bug记录]] 在仓库StrategyRepository定义queryRuleTreeVOByTreeId函数。可以在redis中存下来这样的树型结构（根据数据库中ruleTree，ruleTreeNode，ruleTreeNodeLine）构建 重构抽奖流程 之前的performRaffle(raffleFactorEntity)流程是 1. 进行抽奖因子的参数校验，userId, strategyId是否合法 2....
营销项目--7. 责任链模式处理抽奖规则
![[Pasted image 20241016140436.png]]这一节主要是通过责任链设计模式重构之前的抽奖前过滤处理。因为在之前处理规则处理的流程中，因为前置规则的校验附带了抽奖的行为处理。让规则负责的事情变多了。 抽奖前置规则：黑名单抽奖策略，权重抽奖策略，白名单抽奖策略等。抽奖前置规则在抽奖中可以抽象为一种策略行为。这些策略行为之间应该为互斥的。所以想到了使用责任链设计模式 开发流程 将之前rule中的所有内容放在rule-filter中，新建rule-chain 增加责任链接口ILogicChain 增加一个抽象类AbstractLogicChain，封装链 实现具体的类，比如黑名单链BlackListLogicChain继承抽象类。以及兜底责任链，权重责任链的逻辑实现. 1. 黑名单根据用户id看数据库里这个id是否是黑名单用户，如果是，直接返回奖品。2. 权重规则，根据用户id查询用户已经消耗的积分值，按照数据库中的配置返回根据rule weight的抽奖结果。3.默认 进行标准抽奖 实现chain的工厂类...
营销项目--8. 抽奖规则树模型结构设计
抽奖前的规则过滤是一条链路执行，规则之间也是互斥行为，链路中的节点有一个成功就直接返回。然而在抽奖中后阶段，单独的责任链模式无法满足，因为有分叉的条件，也不是达成某一个规则就直接返回，因此使用组合模式的决策树模型。![[Pasted image 20241016140744.png]]![[Pasted image 20241016140749.png]] 开发流程 创建vo。RuleLimitTypeVO,RuleTreeNodeLineVO,RuleTreeNodeVO,RuleTreeVO RuleTreeVO 决策树的树根信息，标记出最开始从哪个节点执行「treeRootRuleNode」。 RuleTreeNodeVO 决策树的节点，这些节点可以组合出任意需要的规则树。 RuleTreeNodeLineVO 决策树节点连线，用于标识出怎么从一个节点到下一个节点。 在rule下新增tree package。 在tree下定义ILogicTreeNode 接口，定义一个logic方法，入参是userId, strategyId, awardId....
策略模式
策略模式就是定义了一系列算法（或策略），并将每个算法封装起来，使它们可以互相替换。这种模式让算法的变化独立于使用算法的客户。 例子想象一下你开了一家快餐店，提供三种支付方式：现金支付、信用卡支付和微信支付。顾客可以选择任何一种方式来付款。这里，支付方式就是不同的“策略”。 代码实现 策略接口：定义支付方式的接口。 具体策略：实现不同的支付方式。 上下文：使用策略的地方。 12345678910111213141516// 策略接口 interface PaymentStrategy { void pay(int amount); } // 具体策略：现金支付class CashPayment implements PaymentStrategy { public void pay(int amount) { System.out.println("使用现金支付了 " + amount + " 元"); } } // 具体策略：信用卡支付class...
责任链模式
责任链模式（Chain of Responsibility Pattern）是一种行为设计模式，它允许多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合。责任链模式将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667// 抽象处理者abstract class Handler { protected Handler nextHandler; // 设置下一个处理者 public void setNextHandler(Handler nextHandler) { this.nextHandler = nextHandler; } // 处理请求的抽象方法 public abstract void...
工厂方法模式
避免创建者与具体的产品逻辑耦合、满足单一职责，每一个业务逻辑实现都在所属自己的类中完成、满足开闭原则，无需更改使用调用方就可以在程序中引入新的产品类型。但这样也会带来一些问题，比如有非常多的奖品类型，那么实现的子类会极速扩张。因此也需要使用其他的模式进行优化，这些在后续的设计模式中会逐步涉及到。 工厂设计模式的优点 降低耦合性： 客户端不直接依赖具体类的实现，而是通过工厂创建对象，避免了类之间的高耦合。 符合开闭原则： 新的产品或工厂可以通过扩展类来实现，而不需要修改现有代码。 简化对象创建： 通过工厂模式，复杂的对象创建过程被封装起来，客户端只需要调用工厂方法即可创建对象。 工厂设计模式的缺点 增加类的数量： 工厂模式通常会引入额外的工厂类，可能增加代码的复杂度。 可能增加代码复杂性： 尤其是当产品族变得庞大时，管理和维护不同的工厂类会变得复杂。
单一职责原则
Single Responsibility Principle, 面向对象设计的SOLID原则之一 单一职责原则的定义单一职责原则的核心思想是“变化的原因”，每个类应该有且仅有一个原因引起它的变化。如果一个类负责多项职责，那么当其中一项职责变化时，可能会影响到这个类的其他职责。为了降低这种耦合性，应该将不同的职责分离到不同的类中。 单一职责原则的优点 提高可读性和可维护性： 每个类专注于一个功能，代码结构更加清晰，便于理解和维护。 降低耦合性： 将不同的职责分离后，类之间的依赖减少，修改一个类时，不会影响其他职责或模块。 提高可扩展性： 不同的功能模块各自独立，当某个功能需要扩展时，只需要修改相关类，不会影响其他类。 便于测试： 每个类功能单一，可以更轻松地编写单元测试，从而提高代码的测试性。 如何判断是否违反了单一职责原则可以通过以下问题来判断是否违反了单一职责原则： 该类是否负责多个功能？ 如果一个类同时负责多个功能，说明它承担了多个职责。 当功能发生变化时，是否需要修改多个不相关的地方？ 如果需要频繁修改类中的多个部分，这表明该类可能违反了单一职责原则。