之乎者也·的博客

Spring AOP是Spring框架的一个重要组成部分，它通过在程序运行时动态地将代码切入到类的方法中，实现了横切关注点的模块化。利用AOP，我们能够在不改变原有代码的情况下，通过切入点和通知来实现诸如日志记录、性能监控等横切关注点。

那么今天带来的其实也没啥，就是简简单单的校验，去校验token，然后就好了，但是区别是啥呢，咱们这边有个大冤种就是这个 GateWay。此外这边的全部代码都是在WhiteHolev0.7里面的，可见的。图片由于这个玩意，咱们不好再像以前直接去在拦截器里面去搞事情。而且说实话，请求那么多，如果全部都在GateWay去做的话，我是真的懒得去写那些啥配置了，到时候放行哪些接口都会搞乱。所以问题背景就是在分布式微服务的场景下，如何去更好地校验token。并且通过我们的token我们可以做到单点登录。

微服务架构是一种将单一应用程序划分为一组小的、独立的服务的方法。每个服务运行在其自己的进程中，服务之间通过轻量级的方式（如HTTP REST API）进行通信。

在计算机领域中，重试机制的重要性不言而喻。客户端模式和服务端模式。客户端模式简单易用，但可靠性较低；而服务端模式虽然相对复杂，但能够提供更高的可靠性。无论是客户端模式还是服务端模式，重试机制都是保障系统正常运行的重要一环。选择适合您业务需求的模式，并通过合理的配置项进行优化，将为您的系统带来更好的表现和用户体验。

由于缓存盘写入速度快，数据盘写入数据慢，随着大量的数据写入，没有及时写入到数据盘上的数据是会堆积在缓存盘中的，为了避免缓存盘被写满的情况出现，最佳实践是5：1，即5块大容量NL-SATA盘配置1块固态硬盘，如果是NVMe协议的固态盘，可以配置8：1。PACS应用在医院众多的数字化信息系统中是比较特殊的一个，存储容量需求大，网络访问要求高，在“智慧医院”建设的大环境下，在满足患者看病的同时，还需要满足临床应用、教学、会诊和科研的需要，满足数据安全保护的需要，有完善的数据保护机制。

可观察性不单是一套理论框架，而且并不强制具体的技术规格。其核心在于鼓励团队内化可观察性的理念，并确保由研发人员构建的应用程序具备可观察性。在学术领域中，尽管“可观测性”这一术语是近年来从控制理论中引进的新词，但实际上，它在计算机科学领域已有深厚的实践基础。学者们通常会把可观测性细化为三个更具体的研究方向：事件日志、链路追踪和聚合度量。这三个领域虽然各有侧重点，但并非完全孤立，它们之间存在着天然的交集与互补性。

链路数据采集tracing（调用链数据）和metric（指标）信息并上报，上报通过HTTP或者gRPC方式发送数据到Skywalking Collector： 链路数据收集器，对agent传过来的tracing和metric数据进行整合分析通过Analysis Core模块处理并落入相关的数据存储中，同时会通过Query Core模块进行二次统计和监控告警3. Storage。

变化与机会总是并存的，对于技术不断变革的今天，机会也一直存在，特别是对于银行科技行业职业生涯来说，没有过硬的技术实力是没法在众多技术人员中出类拔萃的，同时新技术带来变革所产生的机会也是稍纵即逝的，一旦错过将错失多年，而对于那些有技术准备的人来说把握机会的概率相比之下会更大。随着企业改革的不断深入，对于银行业的科技部门来说，市场化需求也在不断加强，面对市场化这一趋势，岗位的考核力度不断加大，特别是新技术的岗位需求度不断加大，传统岗位需求度呈下降趋势，如不能满足趋势的要求，注定是要被淘汰，挑战可想而知；

我们知道，应用系统在分布式的情况下，在通信时会有着一个显著的问题，即一个业务流程往往需要组合一组服务，且单单一次通信可能会经过 DNS 服务，网卡、交换机、路由器、负载均衡等设备，而这些服务于设备都不一定是一直稳定的，在数据传输的整个过程中，只要任意一个环节出错，都会导致问题的产生。这样的事情在微服务下就更为明显了，因为业务需要在一致性上的保证。也就是说，如果一个步骤失败了，要么不断重试保证所有的步骤都成功，要么回滚到以前的服务调用。微信搜索公众号：Linux技术迷，回复：linux 领取资料。

Raft是当前广泛使用的共识算法。流行的系统，如Kafka、Cockroach DB、MongoDB、Neo4j、Splunk等，都使用Raft来实现共识。系统要么是最终一致性的，要么是强一致性的。线性一致性是一致性模型中最强大的，但实现它可能很耗时。键值数据库出现在市场上，以避免SQL数据库的复杂性并提供横向扩展性。get(key)和。

在分布式系统中，MVCC（Multi-Version Concurrency Control）是一种用于处理并发访问的机制，旨在允许多个事务同时访问和修改共享数据，而不会导致数据的混乱或冲突。MVCC 主要用于数据库管理系统和分布式事务处理中，确保并发事务的隔离性和一致性。

共置表格（Colocated Tables）和交错表格（Interleaved Tables）是数据库中的优化技术，用于改善数据存储和查询性能。像每一种优化技术一样，表共置和交错都有其优点和权衡。要确保共置不是你的用例的过早优化，首先在没有共置的情况下运行应用程序工作负载。检查查询执行计划，并应用避免需要共置表格的优化。有时，你只需要创建适当的索引，为 JOIN 操作启用批处理，为页面缓冲区提供更多内存等 — 在看到执行计划之前你永远不会知道。

2PC，全称为两阶段提交（），是一种在分布式系统中用来保证事务原子性和一致性的协议。它主要用于协调分布式数据库或分布式事务环境中的多个参与者，确保所有参与者要么一起成功提交事务，要么一起回滚事务，以保持数据的一致性。在2PC准备阶段（事务协调器接收到发起事务的客户端请求后，向所有参与该事务的资源管理器（例如数据库、服务节点等）发送“准备提交”请求。每个资源管理器执行事务操作，并将事务相关的更改锁定但不提交，然后回复事务协调器它们是否准备好提交事务（根据各自是否能够成功完成事务而定）。提交阶段（

hadoop中HDFS要存储数据，这些数据存储的目录地址，默认值为：/tmp/hadoop-${user.name}，如下图2所示为默认值，在本环境 Linux系统里面是指：/tmp/hadoop-zola，但是 /tmp 目录是1个临时目录，一般Linux系统1个月清理一次。集群完成配置后，在启动集群之前，还需要 配置workers节点 ，集群中有几个节点， /opt/module/hadoop-3.1.3/etc/hadoop/workers配置文件里面对应的就配置几个主机名称。

日常开发中，我们需要对系统中的各种数据使用 ID 唯一表示，比如用户 ID 对应且仅对应一个人，商品 ID 对应且仅对应一件商品，订单 ID 对应且仅对应一个订单。我们现实生活中也有各种 ID，比如身份证 ID 对应且仅对应一个人、地址 ID 对应且仅对应简单来说，ID 就是数据的唯一标识。分布式 ID 是分布式系统下的 ID。分布式 ID 不存在与现实生活中，属于计算机系统中的一个概念。我简单举一个分库分表的例子。我司的一个项目，使用的是单机 MySQL。

比如在我们设计的数据标注系统中，当标注员针对一份点云数据进行标注时，可能会出现成千上万个 Label，我们需要实时统计他的工作量，当前我们选择了在工程侧通用 Kafka 通道连接大数据技术体系，在大数据技术域中进行转换计算等工作，但是如果出现网络延迟、代码问题会出现实时流程丢失极少量数据的情况导致工作量的不准确，结合实际业务场景，工作量的实时指标仅做参考，最终决定结算流程的是项目完成后的最终统计数据。将系统划分为多个层次，每个层次负责特定的功能，有清晰的职责定义和边界划分，来提高系统的可维护性和可扩展性。

首先和大家分享下大语言模型的发展背景。过去的几年内，无论从数据量的维度还是从模型规模的维度，语言模型规模都扩大了非常多的数量级。随着数据量和模型规模的扩大，也面临着一些挑战。其中涉及的挑战主要可以分为两部分。首先是计算方面，这里给了一个来自于Megatron 论文的公式去计算一个模型训练时需要的计算 FLOPS，我们可以简单推算一下，GPT-3 175B 模型使用现在比较合理的 1.5T Tokens 数据量训练，大概需要 128 个 DGX A100 节点(*仅供技术交流使用），共计 1024 张 A10

MapReduce 是一种编程模型（没有集群的概念，会把任务提交到 yarn 集群上跑），用于大规模数据集（大于1TB）的并行运算。概念"Map（映射）"和"Reduce（归约）"，是它们的主要思想，都是从函数式编程语言里借来的，还有从矢量编程语言里借来的特性。它极大地方便了编程人员在不会分布式并行编程的情况下，将自己的程序运行在分布式系统上。

Kafka采用了分布式存储和分区机制，使得不同的数据分散存储在不同的节点上，并可水平扩展，从而实现高吞吐量。此外，Kafka还采用基于磁盘的存储方式，较少使用内存，因此可以存储更大量的数据。Kafka是一个开源的分布式流处理平台，主要用于处理高吞吐量的数据流和消息队列系统。相比其他消息队列系统，Kafka最大的优势在于它的高吞吐量和可靠性。Kafka的分区机制是指将数据划分为多个分区，每个分区存储在不同的节点上。每个分区中的消息是有序的，因此可以保证消息的顺序性，同时还可以提高并发处理的能力。

在分布式系统的生命周期中，架构演进和版本管理是很重要的两个环节。本部分会介绍分布式系统架构演进的原则、策略以及版本管理的最佳实践，以帮助研发团队更好地应对需求变化、技术发展和系统升级。采用渐进式演进的原则，避免一次性大规模的变革，在实际操作过程中，通过小步快跑的方式逐步迭代升级，降低风险。模块化设计有助于降低系统的耦合度，使得每个模块可以独立演进，便于系统整体的升级和优化。根据新技术的发展，逐步升级系统的底层技术栈，以提升性能、安全性和开发效率。

在传统的单体系统中，事务处理通常相对简单，但是在分布式环境中，多个独立组件之间通过网络相互通信，协同工作，在这个过程中，事务处理变得相对更复杂些，事务需要在多个组件之间进行协调和同步，需要面对一系列挑战，如数据一致性、隔离性、性能等多个方面。在分布式系统中，数据通常被分片存储在多个节点上，这意味着一个分布式事务可能涉及到多个数据分片的操作，如果其中一个数据分片的操作失败，那整个事务就需要回滚来保证数据的完整性，然后由于网络延迟、节点故障等原因，数据分片之间的操作可能不同步，导致原子性难以保证。

然后，要想构建高性能、可扩展的分布式系统，对性能优化和可扩展设计的深入理解和掌握对架构师和专业的后端研发人员来说是必备能力要求。通过微服务架构、分库分表、弹性设计等策略，结合无状态服务、消息队列和API网关等技术，可以实现系统的高可用性、高性能和高弹性，适应不断增长的用户和数据规模。在涉及分布式事务处理的场景，要对事务进行合理的拆分，将大事务拆分成多个小事务，减少锁竞争。采用微服务架构是提高可扩展性的有效途径，将系统拆分成小而自治的服务，每个服务负责一个特定的业务功能，便于水平扩展和独立部署。

在现代的软件研发过程中，分布式系统的安全性和稳定性已经成为至关重要的因素。随着数据量和用户规模的增长，确保系统不受恶意攻击、保护用户隐私以及保证服务的可用性变得越来越重要。

在有些情况下，一些中间件或技术可能会提供对单播和广播的支持，但他们通常不是专门为了实现这两种通信模式而设计的，比如一些网络库，像BSD Sockets（C/C++）、Java 的 java.net.Socket 类、Python 的 socket 模块等。对于单播通信场景和广播通信场景，尽管是网络通信的基本场景，但是在分布式系统中，通常不会直接使用特定的框架/组件来实现这些通信场景，而是通过更高级别的抽象来完成，比如编程语言提供的网络库、操作系统提供的套接字 API、其他中间件等。

在 HBase 中，事务可以跨越多个节点进行操作，为了保证事务的原子性和一致性，HBase 采用了 Write-Ahead-Logging（WAL）机制：当事务开始时，HBase 会将所有操作记录到 WAL 中，当事务提交时，HBase 会将这些操作应用到实际的数据中，如果事务失败，HBase 可以根据 WAL 中的记录进行回滚操作，以保证数据的完整性和一致性。加解密技术可以保护数据的机密性和完整性，访问控制可以限制用户对数据的访问权限，审计可以记录用户对数据的操作行为，从而确保数据的可靠性。

好了，总结一下。这篇文章，我们主要探讨了基于 Redis 实现的分布式锁，究竟是否安全这个问题。从最简单分布式锁的实现，到处理各种异常场景，再到引出 Redlock，以及两个分布式专家的辩论，引申出分布式系统 NPC 问题。最后我们还对比了基于 ZooKeeper、Etcd 的分布式锁的安全问题，以及与 Redis 的差异。对于分布式锁可以总结下：分布式锁并不是 100% 安全，无论是基于 Redis、ZooKeeper 还是 Etcd。

首先客户端Producer通过sendMessageInTransaction方法发送事务消息，Broker判断是事务消息就将消息topic存入到RMQ_SYS_TRANS_HALF_TOPIC返回给客户端，客户端继续执行逻辑。然后调用endTransaction方法去提交本地事务通过endTransactionOneway将消息提交给Broker端，Broker端通过Code为END_TRANSACTION的处理器去处理消息调用processRequest方法来处理对应的消息，

分布式锁其实就是，控制分布式系统不同进程共同访问共享资源的一种锁的实现。如果不同的系统或同一个系统的不同主机之间共享了某个临界资源，往往需要互斥来防止彼此干扰，以保证一致性。「互斥性」: 任意时刻，只有一个客户端能持有锁。「锁超时释放」：持有锁超时，可以释放，防止不必要的资源浪费，也可以防止死锁。「可重入性」:一个线程如果获取了锁之后,可以再次对其请求加锁。「高性能和高可用」：加锁和解锁需要开销尽可能低，同时也要保证高可用，避免分布式锁失效。

Redis分布式锁，顾名思义，是一种基于Redis实现的分布式锁，主要解决分布式系统下多个节点同时访问同一资源时可能造成的数据竞争问题。Redis分布式锁可以在多个节点之间保证原子性、可重入性、互斥性等特性。本文介绍了Redis分布式锁的实现原理、优势，以及在使用过程中的要点和注意事项，希望能对大家在实际应用时有所帮助。Redis分布式锁尽管使用便捷、性能优越、功能强大，但也有诸多注意事项需要遵循，使用时需要谨慎，相信通过注意这些问题，大家在使用Redis分布式锁时一定能够事半功倍。

说到分布式存储，我们先来看一下传统的存储是怎么个样子。传统的存储也称为集中式存储， 从概念上可以看出来是具有集中性的，也就是整个存储是集中在一个系统中的，但集中式存储并不是一个单独的设备，是集中在一套系统当中的多个设备，比如下图中的 EMC 存储就需要几个机柜来存放。在这个存储系统中包含很多组件，除了核心的机头（控制器）、磁盘阵列（ JBOD ）和交换机等设备外，还有管理设备等辅助设备。结构中包含一个机头，这个是存储系统中最为核心的部件。通常在机头中有包含两个控制器，互为备用，避免硬件故障导致整个存储系统的

限流组件使用的是guava包中的实现，任务注册时需要分别配置主实例和子实例执行的限流值，限流也在任务类型维度来做，调度时根据任务的key取到对应的限流器。以上解决的是业务应用重启时实例执行中断的问题，如果任务中心应用重启，也会导致对实例的部分操作中断（如子实例分发），同样也用心跳时间探活来解决，对超时的实例，重新执行当前状态的操作，防止实例永久停留在中间状态。如果在更新子实例状态前机器重启，利用mq的重试机制，对于幂等的任务类型，可直接重新执行，不支持幂等的任务类型在消息重试时子实例直接更新为失败即可。

RPC是一种计算机通信协议，它允许程序在网络上请求服务而不需要了解底层网络细节。RPC 的基本思想：本地计算机上的客户端程序调用远程服务器上的过程或子程序，就像调用本地过程一样，而不用关心底层网络通信的细节。RPC 的工作原理/步骤客户端调用：客户端通过本地调用远程服务的方式，就像调用本地方法一样数据序列化：客户端将调用的参数序列化为可以在网络上传输的格式，如二进制流或 JSON网络传输：序列化后的数据通过网络传输到远程服务器数据反序列化：服务器接收到数据后，将其反序列化为原始参数服务端执行。

本地ID生成器是指在本地环境中生成唯一标识符（ID）的工具或算法。本地ID生成器是相对于 分布式ID生成器而言的。二者的区分不是ID的用途，而是生产ID是否存在 网络IO开销：本地ID生成器在本地生产ID，没有网络IO开销；分布式ID生成器 需要进行远程调用生产ID，有网络IO开销；总之，本地ID生成器所生产的ID并不是仅仅用于本地，也会用于分布式系统，拥有分布式系统中唯一标识实体或资源，例如数据库记录、消息、文件等。唯一性：生成的ID必须在整个系统中是唯一的，以避免冲突。可排序性。

性能测试就是通过特定的方式对被测试系统按照一定测试策略施加压力，获取该系统的响应时间、TPS、吞吐量、资源利用率等性能指标，来检测系统上线后能否满足用户需求的过程。JMeter是Apache公司基于java开发的一款开源压力测试工具，不仅体积小功能全，而且使用起来也非常方便和简单。它是主要用于web应用程序的负载测试，同时它还支持单元测试和有限的功能测试。

eBay 的架构师 Dan Pritchett 源于对大规模分布式系统的实践总结，在 ACM 上发表文章提出 BASE 理论，BASE 理论是对 CAP 理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。（基本可用）分布式系统在出现不可预知故障的时候，允许损失部分可用性Soft state。

Seata是 阿里巴巴开源的分布式事务中间件，以高效并且对业务0侵入的方式，解决微服务场景下面临的分布式事务问题。事实上，官方在GitHub已经给出了多种环境下的Seata。官网代码示例中，依赖太多，分不清哪些有什么作用Seata相关资料较少，笔者在搭建的过程中，遇到了一些坑，记录一下。

今天我们讲讲分布式锁，网上相关的内容有很多，但是比较分散，刚好自己刚学习完总结下，分享给大家，文章内容会比较多，我们先从思维导图中了解要讲的内容。分布式锁是控制分布式系统之间同步访问共享资源的一种方式，通过互斥来保持一致性。主要用来给方法、代码块加锁。当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效果，因为线程锁的实现在根本上是依靠线程之间共享内存实现的，比如Synchronized、Lock等。

我们在分布式开发中经常听到的一个词就是在理解“服务治理”的概念之前让我们先理解什么是，分布式系统之间如何通过（Remote Procedure Call，远程过程调用），以及如何，这样才能真正地理解服务治理的分布式系统指的是通过网络连接让多台计算机协同解决单台计算机所不能解决的计算、存储等问题，多台计算机之间通过 RPC 方式通信。在使用分布式系统前，首要解决的问题是。通过使用多台计算机分布式解决问题，让分布式系统中的每台机器都负责解决原问题的一个子集。一般来说，可以使用或者对复杂的系统进行拆分。

对于锁，大家应该都不陌生，手机上可以加锁，想用时候解锁，不用的时候上锁，那自行车、房门同样可以加把锁，道理属于类似的情况。在日常开发工作中，我们为了保证资源操作的最终一致性，同样需要用到锁来进行操作控制。本Chat结合自己工作中的经验沉淀，来跟大家一起聊聊 分布式锁的那些事，分享一些实用内容给大家。上面的几种分布式锁的实现，需要根据不同的应用场景选择最适合的实现方式。在分布式环境中，对资源进行上锁有时候是很重要的，比如秒杀、抢购某一资源，这时候使用分布式锁就可以很好地控制资源。

在微服务架构下，由于数据库和应用服务的拆分，导致原本一个事务单元中的多个 DML 操作，变成了跨进程或者跨数据库的多个事务单元的多个 DML 操作，而传统的数据库事务无法解决这类的问题，所以就引出了分布式事务的概念。分布式事务本质上要解决的就是跨网络节点的多个事务的数据一致性问题，业内常见的解决方法有两种：1、强一致性就是所有的事务参与者要么全部成功，要么全部失败，全局事务协调者需要知道每个事务参与者的执行状态，再根据状态来决定数据的提交或者回滚！2、最终一致性，也叫弱一致性，