高性能的实践方案 集群部署，通过负载均衡减轻单机压力。 多级缓存，包括静态数据使用CDN、本地缓存、分布式缓存等，以及对缓存场景中的热点key、缓存穿透、缓存并发、数据一致性等问题的处理。 分库分表和索引优化，以及借助搜索引擎解决复杂查询问题。 考虑NoSQL数据库的使用，比如HBase、TiDB等，但是团队必须熟悉这些组件，且有较强的运维能力。 异步化，将次要流程通过多线程、MQ、甚至延时任务进

分布式事务 刚性事务 严格遵循 ACID 原则（原子性、一致性、隔离性、持久性），要求事务在执行过程中必须满足强一致性。典型的实现是 两阶段提交（2PC） 和 三阶段提交（3PC）。 柔性事务 以 BASE 理论（基本可用、柔性状态、最终一致）为设计原则，允许事务在执行过程中存在短暂的不一致，但最终会通过补偿机制达成一致。典型实现包括 TCC（Try-Confirm-Cancel）、Saga

分布式锁 分布式锁是一种在分布式系统中协调多个进程或服务对共享资源进行互斥访问的机制。它的核心目标是确保在分布式环境下，同一时刻只有一个节点（或实例）能够访问或操作某个共享资源（如数据库、文件、缓存等），从而避免数据不一致或并发冲突。 为何需要分布式锁 避免不同节点重复相同的工作：比如用户执行了某个操作有可能不同节点会发送多封邮件； 避免破坏数据的正确性：如果两个节点在同一条数据上同时进行操作，可

分布式全局ID生成方案UUID 基于时间的UUID - 版本1 这个一般是通过当前时间，随机数，和本地Mac地址来计算出来，可以通过 org.apache.logging.log4j.core.util包中的 UuidUtil.getTimeBasedUuid()来使用或者其他包中工具。由于使用了MAC地址，因此能够确保唯一性，但是同时也暴露了MAC地址，私密性不够好。 DCE安全的UUID

分布式系统中session一致性问题Redis实现 我们只需在用户首次登陆的时候将用户信息放到 Token并缓存到 Redis 中，同时设置一个过期时间。 定义一个拦截器 SessionInterceptor，当访问 web 接口的时候检验用户的 token 信息，判断用户是否登陆，未登录的情况下一些业务接口是无法访问的，以及在登陆的情况下拿到我们需要的用户信息， 式简单易用，而且Redis 在分

服务幂等幂等的场景 前端重复提交：提交订单，用户快速重复点击多次，造成后端生成多个内容重复的订单。 接口超时重试：对于给第三方调用的接口，为了防止网络抖动或其他原因造成请求丢失，这样的接口一般都会设计成超时重试多次。 消息重复消费：MQ消息中间件，消息重复消费。 幂等的实现方式Token机制 类似于前端重复提交、重复下单的场景就可以通过 Token 的机制实现 针对前端重复连续多次点击的情况，

缓存常见的缓存更新策略Cache Aside Pattern（旁路缓存模式） 应用直接管理缓存，缓存层独立于数据库 比较适合读请求比较多的场景 写 先更新DB 直接删除cache 读 先从cache中读取数据，读取到就直接返回 cache读取不到的话，就从DB中读取返回 再把DB中读取到的数据放到cache中 写操作为什么是删除cache而不是更新cache？ 对服务端资源造成浪费，因为ca

负载均衡与代理技术 LB,也可以写成SLB，Service load balance 一般来说四层LB，说的是按照ip进行负载均衡，六层SLB是按照URL进行负载均衡 职责：服务发现，健康检查，负载均衡 好处 命名抽象：客户端通过统一的访问机制（如 DNS 或内置库）连接到负载均衡器，无需关心后端服务器的拓扑结构或配置细节。 容错能力：通过健康检查和负载均衡算法，将请求分配至正常运行的后端服务器。

一致性哈希 一致性哈希是一种特殊的哈希，当重新调整哈希表的大小并使用一致性哈希时，平均只需要重新映射 k/n 个键，其中 k 是键的数量，n 是槽的数量。 相比之下，在大多数传统的哈希表中，数组槽数量的变化导致几乎所有键都被重新映射 将hash结构做成环状，为了减少扩容哈希桶时，数据迁移的成本 为了解决哈希算法中，取模为固定的数，无法扩展的缺点，采用一致性哈希算法，在一致性哈希算法中，为

命令命令的类型 可执行程序，这一类程序可以是用诸如 C 和 C++语言写成的程序编译的二进制文件, 也可以是由诸如shell，perl，python，ruby等等脚本语言写成的程序 。 一个内建于 shell 自身的命令。bash 支持若干命令，内部叫做 shell 内部命令 (builtins)。例如，cd 命令，就是一个 shell 内部命令。 是一个 shell 函数。这些是小规模的 she