主要作为个人的笔记用，Not For Everyone。

使用开源免费的组件构建一套分布式微服务技术选型推荐

首先，创建一个自定义注解。// 可以定义属性以配置注解，例如设置过期时间等。

在 URL 的定义中，通常不建议使用驼峰写法（CamelCase），因为 URL 应该尽量保持易于阅读和输入。URL 中包含的字母大小写可能会导致访问错误或混淆，因为不是所有的服务器或网络设备都会把 URL 视为大小写不敏感。因此，推荐的好的写法是使用全部小写并通过短划线来分隔单词。这样不仅避免了大小写敏感的问题，也使得 URL 更加清晰易读。

局部性原理描述了一个倾向，即软件在执行过程中所需要访问的数据和指令，倾向于集中在一小块连续的地址空间内。缓存是一种小容量但速度极快的内存，位于CPU和主内存之间，用来临时存储最近或频繁访问的数据，以减少访问主内存的次数，从而提高整体系统性能。空间局部性（Spatial Locality）：空间局部性则是指如果一个数据位置被访问，那么其附近的数据位置很可能很快也会被访问。例如，循环中使用的变量就可能展现出很强的时间局部性，因为在循环过程中，这些变量会被连续多次读取或修改。

常见越权有水平越权、垂直越权和数据越权。

需求正文需求文档：交互文档：功能架构图、业务现状说明用例图流程图规则说明本项目中，设计系统之间的边界、主要领域模型本项目中，设计上下游依赖，时序图如有，请说明缓存失效策略如有，请评估峰值消息量如有，请说明任务调度策略注：不分页或者超过100条数据的列表接口必填，其他可选业务场景描述幂等单号的生成规则幂等失效的影响限售场景限售规则如何限售灰度策略实现方式影响白名单比例灰度监控内容：监控业务场景责任人告警指标核对内容：风险描述风险类型风险识别发现能力责任人应对能力稳定性/一致性T+H核对应用应急步骤描述业务影响

评估回滚影响面，确定回滚顺序，通知相关上下游，并在发布群进行报备。除对服务器压力外，还需要评估数据库/消息/缓存/任务等压力。不是新业务上线，不需要评估业务对当前系统水位的冲击和压力。系统维度修改了那些应用、开了那些分支，以及相关人员。若有外部域系统依赖，发布顺序也需要评估外部域相关系统。不存在数据安全、业务安全，不需要风控团队介入。主要包含外部系统的依赖，非本域依赖。系统 -> 执行人 -> 顺序。系统 -> 执行人 -> 顺序。参考1.5 梳理顺序执行。业务视角修改了哪些内容。

本文总结了提升接口性能的常见优化手段：通过批量处理、缓存机制和避免冗余请求减少请求数量；采用数据压缩、高效序列化格式优化数据传输；利用异步处理、并行计算提高处理效率；通过索引优化、查询改进和读写分离提升数据库性能；实施负载均衡和CDN分发来平衡服务器压力；同时强调代码优化、资源池化、硬件升级和性能监控等综合措施。这些方法从请求处理、数据传输、系统架构等多维度协同作用，可有效提升接口响应速度与系统吞吐量。

当创建一个订单时，将这个订单的ID和过期时间（当前时间加上5分钟）一起放入支持延迟消息的消息队列中（如RabbitMQ的Delayed Message Plugin或者Kafka的延迟队列）。应用层定时器（Application-Level Timer）： 在应用层面，使用编程语言内置的定时器API（例如Java的ScheduledExecutorService，或者Python的sched模块）来设置一个5分钟后执行的定时任务，任务的责任是检查和取消订单。接口，可以用来实现内存里的延迟队列。

这是因为，Seata 通过全局事务 ID 和事务上下文的传递，确保所有相关的微服务调用都在同一个全局事务的范围内执行。: 在这个例子中，应用 A 和应用 B 的事务是分离的。应用 A 的数据库操作不会参与到应用 B 的全局事务中，因为全局事务的上下文是在调用链的下游应用 B 中创建的。在这种情况下，应用 B 的全局事务将不会自动包含应用 A 的任何数据库操作，因为全局事务的上下文是在应用 B 中创建的。： TM负责定义事务的范围，即开始和结束全局事务的边界，它会在适当的时机向TC注册并报告全局事务的状态。

一、架构图