秃了也弱了

RBAC(Role-Based Access Control)是一种基于角色的访问控制模型，它可以控制用户对系统资源（一般是对接口）的访问权限。1.用户表(User)：用于存储用户的基本信息，例如用户ID、用户名、密码等。2.角色表(Role)：用于存储角色的基本信息，例如角色ID、角色名、角色描述等。3.权限表(Permission)：用于存储权限的基本信息，例如权限ID、权限名、权限描述等。权限来标识具体的事物（接口、资源、菜单等）

为了确保软件接口的标准化和规范化，实现业务模块的重用性和灵活性，并提高接口的易用性和安全性，OpenAPI规范应运而生。这一规范通过制定统一的接口协议，规定了接口的格式、参数、响应和使用方法等内容，从而提高了接口的可维护性和可扩展性。同时，为了也需要考虑接口的安全性和稳定性，本文将针对这些方面介绍一些具体的实践方式。在提到对于开放接口的安全设计时，一定少不了对于摘要算法的应用（MD5算法是其实现方式之一），在接口设计方面它可以帮助我们完成数据签名的功能，也就是说用来防止请求或者返回的数据被他人篡改。

类别代码为“01”(表示电子产品)，品牌代码为“02”(表示品牌B)，系列代码为“03”(表示系列C)，列号为“0001”。接口分配不同的限流配额，确保关键接口的可用性，但需要维护API接口的限流配置。型号：ABC123（运动鞋的通用型号） 这样，无论你销售多少不同变种的鞋子，它们都被列为同一款产品的不同变种，方便顾客在在线商店中浏览和比较。这种方式可以为不同的请求类型分配不同的限流配额，确保关键操峰的可用性。路由转发：将来自客户端的请求，按照预先定义的路由规则进行转发，使请求能够到达正确的后端服务。

▪ 2.5W/台 x 0.7 = 1.75W / NG，（30W + 3W）/ 2.1W = 16。▪ 5W/台 x 0.7 = 3.5W / NG，（30W + 3W）/ 3.5W = 10。▪ 3W/台 x 0.7 = 2.1W / NG，（30W + 3W）/ 2.1W = 16。20C256G，8K连接数，普通 QPS = 1 - 5W，快的话可达 10W+通过加配置，调参数，10W+ 还是可达的，再厉害点的 15W+ 也是可⾏的。NVMe SSD，写 2000MB/s，读 2000MB/s。

高并发、高性能、高可用，它们是互联网系统架构设计永恒的主题。三高并不是孤立的，而是相互支撑，相互影响的，随着并发量的提高，请求延迟肯定会增大，就越考验系统的可用性和性能。三高方案不是简单的一字一句就能说明白的，是需要日积月累，一步步踩坑踩出来的。只不过现在有一些大厂的案例，供我们来参考，实际落地的时候，还需要根据各个公司不同场景进行不同的设计。

logger.info("获取支付请求参数 => " + requestPayStr);// 1.解密报文logger.info("解密后 => {}", decrypt);// 2.校验流水号，保证幂等if (payPo!= null)return ResponseData.fail("流水号重复");// 3.校验余额return ResponseData.fail("余额不足");// 4.风控校验return ResponseData.fail("风控不通过");

OAuth（Open Authorization）是一个关于授权（authorization）的开放网络标准，允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容。OAuth在全世界得到广泛应用，目前的版本是2.0版。

OpenID：一种开放的身份验证标准。OAuth2.0：OAuth升级版。把一个网站的资源授权给另一个网站的过程。OpenID Connect（OIDC）：OAuth2的一体两面。OAuth2.0授权4大模式：授权码模式：完整、严密，第三方认证和授权的最主流实现。简化模式：令牌用户可见，移动端的常用实现手段。密码模式：用户名密码暴露给用户。客户端模式：后台应用之间进行沟通，用户就是客户端。

IM系统就是即时通讯（Instant Messaging）系统的简称。IM其实并不局限于聊天、社交这类“典型”应用中，实际上它已经广泛运用于我们身边形形色色的软件中。聊天、直播、在线客服、物联网等所有需要实时互动、高实时性的场景等，都需要应用IM技术。1）微信、qq、钉钉等主流IM应用：这是IM技术的典型应用场景；2）微博、知乎等社区应用：它们利用IM技术实现了用户私信等点对点聊天；3）抖音、快手等直播/短视频应用：它们利用IM技术实现了与主播的实时互动；

需求是贯穿整个研发、架构设计生命周期的。以下是架构的V型图，从左往右是从业务需求到架构设计，最底下是产品开发到逐层的功能验证。当一个需求完成以后，我们会有新的需求进行迭代，然后不断地循环这个过程。1、明确公司业务战略，明确业务需求和非业务需求。2、了解行业标准、限制和质量要求。3、搞明白公司目前IT状态和架构状况。（已有的架构图、设计文档、资产）3、产出系统上下文。4、产出用例模型。5、找出公司/业内的所有资产（将狗资产、方法论的资产），输入到整个架构设计的环节中。

特定行业的应用，而且这种行业具有一定的普遍性，通过一定的业务娃爱宝，通过一定的行业标准，可以简化一个企业从无到有，从小到大，从弱到强的发展周期。每个企业只要专注于自己的核心业务，对非核心业务比如客户管理、大数据分析、办公管理系统等等，都外包给SaaS平台。还有一些通用的前端业务、人工智能、大数据等核心难点功能，也都可以使用SaaS平台。如果说IaaS是云平台的过去式，PaaS就是云平台的现在式，SaaS才是云平台的未来式。

云是一种比喻说法，就像我们平时看到的云一样，高出不胜寒，站在云端往下看，一切都很渺小。同样的，在云上部署你的应用，可以享受云端很多企业的经验总结，很多坑已经早就被排除掉了。这些企业、软件、系统，会集结成一套标准的套路来使用，所以，就像站在巨人的肩膀上，站在最高点来观察从开发到发布到运维的全过程。云，同样有敏捷的感觉，从发布到弹性伸缩，又高又快。云，主要指基于云计算和云服务的应用。云服务通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源，如IT和软件、互联网相关服务，甚至其他服务。

根据实际业务管理的需要，对硬件、软件以及所要用到的技术进行规格的选择。狭义上的技术选型：团队决定选用哪种技术去解决业务问题。（某种语言、某种框架去开发项目）广义上的技术选型：泛指项目实施过程中的各种技术决策。（制定技术AB方案选其中一套，每个技术决策都是技术选型）在决定采纳某个技术之前，一定要做好调研，并尝试小规模引入，积累经验，经过验证后再大规模采用。总结一下技术选型的简单过程；解决了那些问题；是否达到了预期；哪些地方是值得改进的。如果落地失败，总结失败的原因是什么；总结如何防止再犯；

对刺激（请求）进行快速响应。对事件（event）立即响应。（事件驱动的自然特性使得反应能够立即加载实时，通过避免对共享资源的争用实现可扩展性）对失败（failure）立即响应。（在任何级别都可以建立一个能够实现失败恢复的弹性系统）对用户立即响应。（无论工作在何种负载下，都要满足用户对响应时间的要求）在java.util.concurrent.Flow包下：FlowAPI与Reactive Streams Specification相对应。

（写和读的责任分离）Command：执行动作，返回void。（行动可能会改变聚合、实体、值对象的内容）Query：只查询，不修改对象状态。适用CQRS的风格：事件驱动系统风格、管道过滤器风格。领域驱动设计中，对外提供功能的只有聚合根的功能，聚合根里面的实体尽量只对聚合根提供服务。聚合根的子对象，尽量都用实体对象封装。

扩展性意味着，系统有可伸缩性/弹性，度量增加系统处理能力的指标。扩展性并不单单是系统能力本身，而是伸缩性&性能&成本等的综合考量的结果。系统处理能力（系统性能）：延迟 - 系统处理单词请求所需时间；吞吐量 - 单位时间内系统处理次数。吞吐量越高越好，延迟越低越好。高伸缩性：添加资源就可以应对处理能力需求增长；意味着用户/流量/数据增长，性能指标不下降。伸缩性差：单用户性能正常；用户增长后性能指标下降；性能提升的成本高。

单体应用时代，全都耦合在一起，牵一发而动全身。所有功能一起上线一起回滚。代码复杂度混乱。微服务时代，业务模式糙快猛，敏捷编程。小步快跑，独立演进，独立部署，快速迭代。团队赋能（每个微服务有各自团队）。边界清晰，以大化小-服务拆分，三高应用-分治。

在一个高可用系统中，当联系着的节点断开联系时（网络等问题），本来为一个整体的系统，分裂成两个独立节点，两个节点开始争抢共享资源造成系统混乱、数据损坏的现象，成为“脑裂”。热点数据：在极短时间内被频繁的高并发访问的数据。（爆款商品、秒杀）在真正的热点数据面前，即便是缓存也是扛不住的。（单机10万QPS，并且无法所有数据做缓存）对于秒杀商品，其实是预知的热点，可以预料到的热点其实不存在技术问题。对系统影响最大的是不可预知的热点，比如说微博热搜。

分析测试结果。

层：软件的逻辑单元。每一层都有特定的功能。组件被分配到不同层。将系统按照之策拆分和组织。上层依赖于直接下层。（下层不可以依赖于上层，不可以跨层访问）高层表示规则，底层实现细节。逻辑内聚自治分组。依据组织职责分工。根据每层的需求各自选定。借鉴成功案例。部署方式局限，选定技术栈。事件驱动架构模式是一种异步分发事件的架构模式。用于高扩展且低耦合的系统。事件为核心，一系列解耦的、单一功能的事件处理器。微内核，就是核心功能资源封装。提供可插拔功能扩展的插件。核心系统提供的接口及版本。

如果我们选择了 CA 而放弃了 P，那么当发生分区现象时，为了保证 C，系统需要禁止写入，当有写入请求时，系统返回 error（例如，当前系统不允许写入），这又和 A 冲突了，因为 A 要求返回 no error 和 no timeout。对于多数大型互联网应用的场景，主机众多、部署分散，分区容忍性是基本要求，否则就失去了价值，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9，即保证P和A，舍弃C（退而求其次保证最终一致性）。开发活动中的生产率和质量是可量度的。

无状态（stateLess），也就是上下文并没有依赖。比如说用户登录状态Session，单机环境下，Session存在服务器本地，用户每次登录需要获取到当前登录的用户信息，这就叫有状态。这样的话，该服务就无法做到横向扩容，增加一个服务节点之后无法做到服务节点之间的Session共享。解决方案也很简单，将Session存储到一个公共存储空间即可比如redis。再比如本地缓存。单机环境下，如果数据库响应过慢，通常会将部分热点数据保存在服务的内存中，但是增加服务节点之后同样会导致多个节点中的内存数据不一致。

接口的幂等性——详细谈谈接口的幂等即解决方案通过token机制来保证幂等是一种非常常见的解决方案，同时也适合绝大部分场景。该方案需要前后端进行一定程度的交互来完成。1）服务端提供获取token接口，供客户端进行使用。服务端生成token后，如果当前为分布式架构，将token存放于redis中，如果是单体架构，可以保存在jvm缓存中。2）当客户端获取到token后，会携带着token发起请求。3）服务端接收到客户端请求后，首先会判断该token在redis中是否存在。

SOA是一种粗颗粒、松耦合的以服务为中心的架构，接口之间通过定义明确的协议和接口进行通信。SOA帮助企业架构师以更快速、可靠和可重用的形式规划整个业务系统，相比传统非服务化架构，SOA更加从容地应对复杂企业系统集成和需求的快速变化。接口采用中立的方式进行定义，独立于硬件平台、操作系统和编程语言（SOAP、WSDL、XML等通用语言）。

…系统是一个……的系统，是公司……战略的核心系统，承担着公司……的目标任务。系统主要功能包括……，使用者包括……。

本人也是初次接触CAS，有问题还请指正CAS单点登录图解

什么是事务？举个生活中的例子：你去小卖铺买东西，“一手交钱，一手交货”就是一个事务的例子，交钱和交货必须全部成功，事务才算成功，任一个活动失败，事务将撤销所有已成功的活动。明白上述例子，再来看事务的定义：事务可以看做是一次大的活动，它由不同的小活动组成，这些活动要么全部成功，要么全部失败。2PC即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2是指两个阶段，P是指准备阶段，C是指提交阶段。

RocketMQ 是一个来自阿里巴巴的分布式消息中间件，于 2012 年开源，并在 2017 年正式成为 Apache 顶级项目。据了解，包括阿里云上的消息产品以及收购的子公司在内，阿里集团的消息产品全线都运行在 RocketMQ 之上，并且最近几年的双十一大促中，RocketMQ 都有抢眼表现。Apache RocketMQ 4.3之后的版本正式支持事务消息，为分布式事务实现提供了便利性支持。

Hmily是一个高性能分布式事务TCC开源框架。基于Java语言来开发（JDK1.8），支持Dubbo，Spring Cloud等RPC框架进行分布式事务。支持嵌套事务(Nested transaction support).采用disruptor框架进行事务日志的异步读写，与RPC框架的性能毫无差别。支持SpringBoot-starter 项目启动，使用简单。RPC框架支持 : dubbo,motan,springcloud。

之前画了一个单点登录的逻辑图，其中有很多细节没有展现清楚。终于把单点登录完整流程图画明白了！史上最完整的CAS单点登录完整图解！今天就来讨论一下，认证服务器登录完成之后，如何与客户端保持session过期时间的统一？...

目录写在前面第一范式（1NF）：原子性（存储的数据应该具有“不可再分性”）第二范式（2NF）：唯一性 (消除非主键部分依赖联合主键中的部分字段)（一定要在第一范式已经满足的情况下）第三范式（3NF）：独立性，消除传递依赖(非主键值不依赖于另一个非主键值)总结写在前面很多数据库设计者，都是按照自己的性子和习惯来设计数据库数据表，其实不然。其实，数据库的设计也有要遵循的原则。范式，就是规范，就是指设计数据库需要（应该）遵循的原则。每个范式，都是用来规定某种结构或数据要求—

分布式锁的应用场景就是高并发，高并发下如果锁出了任何问题，就可能会导致脏数据的产生，那么，用redis做分布式锁真的安全吗？未必！如果你的业务⽆关紧要，如果你的业务是可以挂掉的内部系统，如果你的业务可以接受出错的时候，直接返回错误给⽤户，那⼀个单节点 Redis 或关系型数据库的分布式锁就能满⾜你的需求。如果你的业务不允许随意宕机，那我们就要来好好讨论容错性了。讨论“分布式”，意味着可能会发⽣各种各样的错误，Google 公布的数据显示：参考引⽤：https://research.google.co

秒杀大家都不陌生，而且是电商项目必备的一个技能点。但是真正的秒杀服务是非常复杂的，秒杀具有瞬间高并发的特点，所以解决瞬间高并发的问题，就可以解决秒杀的问题。今天就将秒杀系统完整的实现分解开，一起研究一下吧。（有问题还请指正）秒杀服务是有很大风险的，一不小心就会造成服务宕机或者一瞬间占用大量服务器资源，所以秒杀服务必须独立部署，而且秒杀服务只做秒杀功能。防止恶意攻击，防止有人模拟秒杀请求造成服务器更大的压力；防止链接暴露，防止工作人员提前秒杀商品。秒杀系统读多写少，我们可以先将库存总数预热，存入red

我们都知道，缓存是为了提高数据的读取速度的，应对的场景是读多写少的场景。读数据我们通常先读缓存，如果缓存没有再读数据库然后更新缓存。从查询数据库性能优化谈到redis缓存-谈一谈缓存的穿透、雪崩、击穿当缓存的数据需要修改的时候，既要修改缓存，又要修改数据库，如何保证缓存和数据库中的数据是一致的呢？双写模式就是先写数据库，再写缓存：高并发下，由于卡顿等原因，导致写缓存2在最前，写缓存1在后面，就导致了缓存与数据库数据不一致的情况，也就是出现了脏数据。但是，这种脏数据只是暂时的，取决于缓存的过期时间，当缓存

接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因 为多次点击而产生了副作用；比如说支付场景，用户购买了商品支付扣款成功，但是返回结 果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结 果成功，用户查询余额返发现多扣钱了，流水记录也变成了两条．．．,这就没有保证接口 的幂等性。用户多次点击按钮用户页面回退再次提交微服务互相调用，由于网络问题，导致请求失败。feign 触发重试机制其他业务情况以 SQL 为例，有些操作是天然幂等的。SELECT

实现了页面需要的功能，但是考虑到该页面是被用户高频访问的，所以性能必须进行尽可能的优化。一般一个系统最大的性能瓶颈，就是数据库的io操作。从数据库入手也是调优性价比最高的切入点。一般分为两个层面，一是提高数据库sql本身的性能，二是尽量避免直接查询数据库。提高数据库本身的性能首先是优化sql，包括：使用索引，减少不必要的大表关联次数，控制查询字段的行数和列数。另外当数据量巨大是可以考虑分库分表，以减轻单点压力。对于mysql的优化，请自行学习，这里不再赘述。MySQL高级-索引是个什么东西？explain

目录悲观锁乐观锁悲观锁实现方式乐观锁实现方式如何选择悲观锁当我们要对一个数据库中的一条数据进行修改的时候，为了避免同时被其他人修改，最好的办法就是直接对该数据进行加锁以防止并发。这种借助数据库锁机制在修改数据之前先锁定，再修改的方式被称之为悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）。之所以叫做悲观锁，是因为这是一种对数据的修改抱有悲观态度的并发控制方式。我们一般认为数据被并发修改的概率比较大，所以需要在修

目录1.添加机器状态监控节点（node集群配置：每台要监控的服务器都需要安装一个node）2.安装prometheus（只需要安装一个总控prometheus，yml配置文件中配置好各个node节点）3.安装grafana（只需要安装一个grafana，配置上面安装的prometheus）4.prometheus的API1.添加机器状态监控节点（node集群配置：每台要监控的服务器都需要安装一个node）//下载地址（根据需要下载，注意32位和64位系统）https://gith

目录分布式锁定义目的基于redis分布式锁基于zookeeper实现的分布式锁edis、zookeeper、etcd实现分布式锁的比较分布式锁定义分布式环境下，锁定全局唯一资源。请求处理串行化、实际表现为互斥锁。目的 交易订单锁定：防止重复下单、解决业务层幂等问题。 MQ消息消费幂等性：发送消息重复、消息消费端去重、比如手机提现。 在用户对商品下单后，订单状态为待支付，在某一时刻用户正在对该订单做支付操作，商家对该订单进行改价操作：状态的修改...

目录什么是幂等？读和写请求都需要做幂等吗？系统的哪部分需要做幂等？数据访问层的增删改查都需要做幂等处理吗？数据库的修改做幂等（age++的情况展开讨论）分布式系统的ID如何生成？什么是幂等？系统中的重复操作，不管执行多少次，都产生一样的效果，或返回一样的结果。读和写请求都需要做幂等吗？读请求不需要做幂等（因为读请求不会对数据发生改变）。写请求需要做幂等（对数据发生改变了就根据需要做幂等）。系统的哪部分需要做幂等？因为数据访问层和数据库直接联系，涉及到数据的