claude code配置
配置MCP先安装MCP-Router 导入以下配置 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748{ "mcpServers": { "ddg-search": { "command": "uvx", "args": [ "duckduckgo-mcp-server" ], "env": {} }, "context7": { "command": "npx", "args": [ "-y", "@upstash/context7-mcp" ...
数据库优化
1. 分库分表1.1 分库分表算法待定 1.2 如何解决分库分表后的join问题水平拓展后可能会导致库表发布到不同的MySQL实例上，这使得原有的单数据源关联查询变为多库源关联。 可以通过以下方法解决 绑定表（Binding Table） 指分片规则一致的一组分片表。 使用绑定表进行多表关联查询时，必须使用分片键进行关联，否则会出现笛卡尔积关联或跨库关联，从而影响查询效率。 例如：t_order 表和 t_order_item 表，均按照 order_id 分片，并且使用 order_id 进行关联，则此两张表互为绑定表关系。 绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升。 举例说明，如果 SQL 为： 1SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10, 11); 在不配置绑定表关系时，假设分片键 order_id 将数值 10 路由至第 0 片，将数值 11 路由至第 1 片，那么路由后的 SQL 应该为 4...
Mysql事务隔离级别Rc、RR
12345678910CREATE TABLE `t` ( `id` int(11) NOT NULL, `c` int(11) DEFAULT NULL, `d` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `c` (`c`) ) ENGINE=InnoDB; insert into t values(0,0,0),(5,5,5), (10,10,10),(15,15,15),(20,20,20),(25,25,25); 这张表是当前文章的测试表。 1. RR在「可重复读」隔离级别下，可能发生幻读现象，但是不可能脏读和不可重复读现象； MySQL InnoDB 引擎的默认隔离级别虽然是「可重复读」，但是它很大程度上避免幻读现象 针对快照读（普通 select 语句），是通过 MVCC 方式解决了幻读，因为可重复读隔离级别下，事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，即使中途有其他事务插入了一条数据，是查询不出来这条数据的，所以就很好了避免幻读问题。 针对当前读（select …...
分布式ID
1. 分布式id生成需满足的条件 全局唯一：分布式ID必须全局唯一，确保数据可以被唯一确定。 高性能：高并发场景下分布式ID必须快速响应生成。 高并发：分库分表数据存储大概率会出现高并发量的请求，所以这套方案必须在高并发场景下快速生成id。 高可用:：需要无限接近百分百的可用，避免因为因为分布式ID生成影响其他业务运行。 易用：方案必须易于使用，不大量侵入业务代码。 递增：尽可能保证递增，确保ID有序插入以保证插入性能和索引维护开销。 2. 常见id生成方法2.1 UUIDUUID有着全球唯一的特性，符合全局唯一、高性能、高并发、高可用、易用的特性。但是它却有以下缺点: 字符串类型：因为是字符类型，占用大量存储空间。 无序：因为生成的无规律，因为大量的随机添加势必导致MySQL底层大量的B+ tree的节点分裂，耗费大量计算资源，严重影响数据库性能，进而导致查询耗时增加。 所以不推荐 2.2 数据库自增id单表生成的id不是全局唯一，不考虑。 2.3...
接口幂等如何保证
1. 基础可以先定义一个注解@Idempotent 12345678910111213141516171819@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface Idempotent { /** * 设置防重令牌 Key 前缀 */ String keyPrefix() default ""; /** * 通过 SpEL 表达式生成的唯一 Key */ String key(); /** * 设置防重令牌 Key 过期时间，单位秒，默认 1 小时 */ long keyTimeout() default 3600L; } 通过Aop来进行幂等性保证，这里先提供一个获得方法上注解的方法 12345public static Idempotent getIdempotent(ProceedingJoinPoint joinPoint)...
Rpc
1. 启动流程首先看@RpcScan注解 123456789@Target({ElementType.TYPE, ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) @Import(CustomScannerRegistrar.class) @Documented public @interface RpcScan { String[] basePackage(); } 使用时将其加在服务端启动类上，并指定扫描路径 1234567@SpringBootApplication @RpcScan(basePackage = {"github.javaguide"}) public class ServerApplication { public static void main(String[] args) { SpringApplication.run(ServerApplication.class, args); ...
共识算法
1. Paxos 协议Paxos 算法由 Leslie Lamport 在 1990 年提出，它是少数在工程实践中被证实的强一致性、高可用、去中心的分布式 协议。Paxos 协议用于在多个副本之间在有限时间内对某个决议达成共识。Paxos 协议运行在允许消息重复、丢失、 延迟或乱序，但没有拜占庭式错误的网络环境中，它利用“大多数 (Majority)机制”保证了 2n+1 的容错能力，即 2n+1 个节点的系统最多允许 n 个节点同时出现故障。 关于节点数量： 2n + 1的意思是节点数量最好是基数，大多数机制要求至少还有超过一半数量的节点正常，这个集群才算正常。假如集群有5个节点，这里就运行至多2个节点挂掉。 假设是偶数个节点，比如说6个，6 / 2 + 1 = 4个，还是之多允许2个节点挂掉，和节点为5个的情况没区别，反而增加了成本，所以节点数最好是奇数。这与后面的投票机制是差不多的。 拜占庭错误 与 非拜占庭错误 一般地，把出现故障( crash 或 fail-stop，即不响应)但不会伪造信息的情况称为“非拜占庭错误”(...
RocketMQ
1. 架构模型 Broker 做了集群并且还进行了主从部署 ，由于消息分布在各个 Broker 上，一旦某个 Broker 宕机，则该 Broker 上的消息读写都会受到影响。所以 Rocketmq 提供了 master/slave 的结构，salve 定时从 master 同步数据(同步刷盘或者异步刷盘)，如果 master 宕机，则 slave 提供消费服务，但是不能写入消息 (后面我还会提到哦)。 为了保证 HA ，NameServer 也做了集群部署，但是请注意它是 去中心化 的。也就意味着它没有主节点，你可以很明显地看出 NameServer 的所有节点是没有进行 Info Replicate 的，在 RocketMQ 中是通过 单个 Broker 和所有 NameServer 保持长连接 ，并且在每隔 30 秒 Broker 会向所有 Nameserver 发送心跳，心跳包含了自身的 Topic 配置信息，这个步骤就对应这上面的 Routing Info 。 在生产者需要向 Broker 发送消息的时候，需要先从 NameServer 获取关于...
分布式事务
1. CAP 定理 Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。 Availability（可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。 Partition tolerance （分区容错性）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区，在集群出现分区时，整个系统也要持续对外提供服务 这其中的组合就有 CP、AP，但是没有 CA，因为一旦出现网络分区，如果你要保证可用性，那么就可能会导致出现数据不一致，两者互相矛盾。 ZooKeeper 保证的是 CP。 任何时刻对 ZooKeeper 的读请求都能得到一致性的结果，但是， ZooKeeper 不保证每次请求的可用性比如在 Leader 选举过程中或者半数以上的机器不可用的时候服务就是不可用的。 Eureka 保证的则是 AP。 Eureka 在设计的时候就是优先保证 A （可用性）。在 Eureka 中不存在什么 Leader 节点，每个节点都是一样的、平等的。因此 Eureka 不会像 ZooKeeper...
Redis
1. Redis 线程模型1.1 IO 模型 阻塞 IO（Blocking IO） 非阻塞 IO（Nonblocking IO） IO 多路复用（IO Multiplexing） 信号驱动 IO（Signal Driven IO） 异步 IO（Asynchronous IO） 1.1.1 阻塞 IO应用程序想要去读取数据，他是无法直接去读取磁盘数据的，他需要先到内核里边去等待内核操作硬件拿到数据，这个过程就是 1，是需要等待的，等到内核从磁盘上把数据加载出来之后，再把这个数据写给用户的缓存区，这个过程是 2，如果是阻塞 IO，那么整个过程中，用户从发起读请求开始，一直到读取到数据，都是一个阻塞状态。阶段一： 用户进程尝试读取数据（比如网卡数据） 此时数据尚未到达，内核需要等待数据 此时用户进程也处于阻塞状态 阶段二： 数据到达并拷贝到内核缓冲区，代表已就绪 将内核数据拷贝到用户缓冲区 拷贝过程中，用户进程依然阻塞等待 拷贝完成，用户进程解除阻塞，处理数据 1.1.2 非阻塞...