在复杂的分布式系统中，往往需要对大量的数据进行唯一标识，如在金融、电商、支付等产品的系统中，随着数据的日益增长，数据库的自增ID显然不能作为某个订单的唯一标识。除此之外还有其他分布式场景对分布式ID有一些要求，本文针对多中方案进行介绍，包括UUID、数据库自增ID、号段模式、Reids INCR、Twitte（雪花算法）、滴滴（TinyID）、美团（Leaf）、百度（Uidgenerator）。

在多线程环境下，为了保证数据的线程安全，我们通常用加锁的方式，使同一时刻只有一个线程可以对这个共享资源进行操作，在单服务系统我们常用JVM锁——Synchronized、ReentrantLock等。然而在多台服务系统的情况下，JVM锁就无法在多个服务器之间生效了，这时候我们就需要用分布式锁来解决线程安全的问题。分布式锁的实现方式有很多，主流的就是基于数据库、zookeeper以及redis，当然

一致性哈希环顺时针映射优先考虑的是：如何实现最少的节点数据发生数据迁移，当增加或移除节点，只有离新节点最近的节点会涉及到数据迁移。redis cluster哈希槽是静态映射，优先考虑的是如何实现数据均匀分布，当增加或移除节点时，所有的节点都会参与进来平摊压力。（我们搞集群的目的是啥？还不是单机容量不足，需要扩容多机组成集群，然后将数据尽可能的均匀分布吗）。同时，redis cluster哈希槽静态

最近一个新项目需要做功能和性能测试，公司给我分配了两台机器，于是我就把项目分别部署在了两台机器上，用postman测试一下，返回结果如下：然后本能地去查看日志，才明白错误的原因：原来是服务器hosts文件中没有配置当前主机名对应的ip，那么知道原因那就好解决了。

今天就深受其害，虽说不重要，但也挺闹心的，网上搜了半天没有可用的方案，好在功夫不负有心人，自己摸索出来了，话不多说，上教程：

由于篇幅原因，在上篇文章我们只介绍了redis实现分布式锁的两种方式——setnx和Redission，并对Reidssion加锁和看门狗机制的源码进行了分析，但这两种方案在极端情况下都会出现或多或少的问题。那么针对上述问题，比较主流的解决方案有两种：RedLock和Zookeeper实现的分布式锁。

滑动窗口限流是一种流量控制策略，用于控制在一定时间内允许执行的操作数量或请求频率。它的工作方式类似于一个滑动时间窗口，对每个时间窗口的请求数量进行计数，并根据预先设置的限流策略来限制或调节流量，通常包括以下几个要素：

在Redis中，跳跃表是有序集合（zSet）数据类型的实现之一，也在集群节点中用作内部数据结构，除此之外，跳跃表在Redis里面没有其它用途。跳跃表支持O(logN)、最坏O(N)复杂度的节点查找，还可以通过顺序性操作来批量处理节点，在大部分情况下，跳跃表的效率可以和红黑树、AVL树不相上下，但跳表原理更加简单、实现起来也更简单直观。

外观模式（门面模式）是一种结构型设计模式。一、什么是外观模式 二、角色组成 三、优缺点 四、应用场景 4.1 生活场景 4.2 java场景 五、代码实现 5.0 UML类图 5.1 外观（Facade）——旅行社预定服务5.2 子系统（SubSystem）5.3 外观实现类5.4 TestFacade——客户端六、总结

中介者模式是一种行为型设计模式，它主要用于减少对象之间互相通信的复杂性。一、什么是中介者模式 二、角色组成 三、优缺点 四、应用场景 4.1 生活场景 4.2 java场景五、代码实现 5.0 UML类图 5.1抽象中介者（Mediator）——LogisticsCenter5.2抽象同事类（Colleague）——Participant5.3具体同事类（Concrete Colleague）Tr