前言

"微服务"这三个字在技术圈已经热了十多年，但"怎么拆"始终是最困扰架构师的问题。拆得太粗——换了个壳的单体；拆得太细——运维成本爆炸，调试像噩梦。

本文不讲微服务的基础概念（假设你已经知道什么是微服务），聚焦于一个核心问题：面对一个单体系统，你该用什么原则来划边界？

第一部分：单体架构的痛点与拆分的时机

1.1 单体不是原罪

在谈拆分之前，必须明确一个观点：单体架构不是原罪。很多成功的系统——包括 GitHub 早期、Stack Overflow——都是单体架构。单体的问题不在于"它是单体"，而在于"它何时变得不可维护"。

概述

在高并发系统中，限流是一种重要的保护机制，用于控制请求流量，防止系统被过多请求冲击导致服务不可用。本文将基于提供的代码实现，详细介绍如何使用Spring AOP和Redis实现一个灵活的分布式限流组件。
该例子利用mysql进行黑名单的自动登记。

限流组件架构

1. 自定义限流注解 - RateLimiter

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface RateLimiter {
    String key() default "rate_limit:";
    int time() default 60;
    int count() default 5;
    LimitType limitType() default LimitType.DEFAULT;
    boolean joinBlackList() default false;
}

多级缓存系统中的数据一致性是一个复杂的问题，尤其是在分布式环境中。为了保证数据的一致性，可以采用以下几种策略和技术：

1. 写直达（Write-Through）：

   • 在这种模式下，当数据被更新时，更新会立即写入到所有层级的缓存和后端存储中。这确保了所有的缓存和存储都包含最新的数据。
   • 优点是数据一致性容易维护，因为每个写操作都会同步更新所有地方的数据。
   • 缺点是写操作的性能可能会受到影响，因为它需要等待所有层级的更新完成。

2. 写回（Write-Back/Write-Behind）：

   • 写回模式下，更新只会在最靠近应用的缓存层进行，并标记为脏数据。之后，这些更新会被异步地传播到较低层级的缓存和持久化存储。
   • 优点是写操作的延迟较低，因为不需要等待所有层级的更新完成。
   • 缺点是在某些情况下可能导致数据不一致，特别是如果在数据从缓存传播到持久存储之前发生了故障。

3. 缓存失效（Cache Invalidation）：

   • 当数据被修改时，不是更新缓存中的数据，而是简单地使相关的缓存项失效。下次访问该数据时，会从持久化存储重新加载数据并填充缓存。
   • 优点是可以避免复杂的同步逻辑，且不会浪费资源去更新可能很快又被覆盖的数据。
   • 缺点是可能会增加读取延迟，特别是在高并发环境下，多个请求可能会同时尝试重新加载相同的数据。

4. 时间戳或版本控制：

   • 每个缓存条目可以附加一个时间戳或版本号。当有新的数据写入时，更新时间戳或版本号。读取时，检查时间戳或版本号以确定是否需要刷新缓存。
   • 优点是可以更精确地管理缓存的有效期，减少不必要的刷新。
   • 缺点是增加了额外的元数据管理和比较开销。

5. 事件驱动的更新：

   • 使用消息队列或发布/订阅机制来通知各个缓存层有关数据变更的信息。每当数据发生变化时，发布一个事件，所有订阅者（如其他缓存节点）都会接收到通知并相应地更新它们的副本。
   • 优点是可以实现近乎实时的一致性，并且适合分布式系统。
   • 缺点是增加了系统的复杂性和依赖于消息传递的可靠性。

6. 一致性哈希（Consistent Hashing）：

   • 用于分布式缓存系统中，通过将键映射到环上的位置，使得添加或移除缓存节点时，只有最小数量的缓存项需要迁移。
   • 优点是减少了缓存不一致的可能性，并提高了系统的可扩展性。
   • 缺点是实现较为复杂，且在某些场景下可能仍会导致部分数据的短暂不一致。

7. 两阶段提交（Two-Phase Commit, 2PC）：

   • 一种强一致性协议，适用于需要严格一致性的事务处理。它涉及到协调者和参与者之间的两个阶段：准备阶段和提交阶段。
   • 优点是能够提供严格的事务一致性。
   • 缺点是性能较低，特别是在网络分区或节点故障的情况下，可能会导致事务长时间挂起。

8. 最终一致性（Eventual Consistency）：

   • 这是一种宽松的一致性模型，允许不同节点上的数据在一定时间内存在差异，但最终会达到一致状态。
   • 优点是提供了较好的性能和可用性。
   • 缺点是在某些应用场景中，可能无法接受数据的临时不一致。

9. 读修复（Read Repair）：

   • 在读取数据时，如果发现数据不一致，可以在返回结果的同时尝试修复不一致的数据。
   • 优点是可以在不影响读取性能的前提下提高数据的一致性。
   • 缺点是增加了读取操作的复杂度，并且可能会引入额外的延迟。

一、需求

在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。

当需要将节点之间在不同时间的交互做唯一标识，数据日渐增长，

对数据库的分库分表后需要有一个唯一ID来标识一条数据或消息，数据库的自增ID显然不能满足需求。

此时一个能够生成全局唯一ID的系统是非常必要的。

二、ID生成的原则：

1、全局唯一性：不能出现重复的ID（最基本的要求）

2、高性能，低延迟。（不要太繁杂的算法）

3、易于存储，（占用较低的空间）

三、相对应的算法：