基础功能

基础功能 #

分布式锁 #

设计原则 #

  • 互斥性：同一个时间只能有一个线程持有锁。
  • 容错性：即使某一个持有锁的线程异常退出，其他线程仍可获得锁。
  • 隔离性：线程只能释放自己的锁，不能释放其他线程的锁。

数据库唯一索引 #

建立唯一索引，加锁时插入数据，释放锁时删除数据。

# 加锁
insert into locks values('lock_method_name');
# 释放锁
delete from locks where method_name = 'lock_method_name';
  • 优点：实现简单；通过DB实现强一致性。
  • 缺点：并发度较低；需自行实现超时时间。
  • 适合场景：批处理任务防重。

Redis单节点锁 #

通过Redis进行加锁，设置超时时间。

# Redis层面
set key value [ex <second>|px <mill>] nx
# Java Client层面
template.opsForValue().setIfAbsent(key, value, timeout, TimeUnit.SECONDS);
  • 优点：实现简单、高效，支持超时时间。
  • 缺点：
    • 由于Redis采用异步复制，可能会出现脑裂，导致多个客户端持有锁；
    • 超时时间难以预估，可能因FGC等原因造成任务执行中就释放锁，此时也会出现多个客户端持有锁。只能通过将value设为唯一值避免原线程释放了此时已不属于自己的锁。
  • 优化：
    • 设置超时时间时添加一段缓冲时间，也就是说把超时时间设得更长一点。
    • 在获取锁前先获得版本号，获得锁后执行修改前检查版本号。

Redission单节点锁（Watchdog） #

通过Watchdog机制定期延长加锁时间，可以有效防止FGC等原因造成业务未执行完毕就释放锁的问题。不过对于异步复制引起的脑裂问题仍然没有办法。

  • 优点：通过Watchdog确保业务拥有足够时间执行完毕。
  • 缺点：
    • 脑裂引起的多客户端持有锁问题仍然存在。
    • Watchdog虽然在大部分场合都适用，但FGC还是可能导致锁被提前释放。
  • 优化：同单节点锁。

Redlock集群加锁 #

尝试在所有Redis节点加锁，并统计一半以上节点的加锁完成时间是否在阀值内，没有超时则加锁成功。

  • 优点：多节点加锁以解决脑裂问题。
  • 缺点：依赖时间，时钟漂移可能会产生问题；加锁顺序也存在数据安全隐患。目前争议较大，少有实施案例。

Zookeeper #

客户端尝试在Zookeeper上创建临时节点，创建成功的即获得锁。删除节点或断开连接时即释放锁。

  • 优点：通过ZK实现强一致性，Leader切换时不提供服务，解决了脑裂问题。
  • 缺点：依赖Leader提供服务，并发度低。

分布式ID #

设计原则 #

  • 全局唯一
  • 单调递增
  • 无序（无法推断规模）
  • 高可用、高并发、低延迟
考虑到数据量大到一定规模后都会进行归档。为了确保新生成的ID和归档中的ID也不一致，最简单的实现办法就是在ID中包含时间标识。

数据库自增主键 #

使用多台数据库分摊压力，每台起始值和步长=节点数。为了防止主从切换导致计数器丢失，需要将集群配置为半同步复制模式。

  • 优点：实现简单；依靠数据库自身特性避免了页分裂。
  • 缺点：依赖数据库性能；数据有序可被推测规模。

数据库+代理服务 #

在数据库中建立分布式主键表，字段包含max_id、step和biz_type。代理服务每次获取一批ID保存在内存中，同时修改数据库的max_id的值。应用通过代理服务的接口获取ID。代理服务可以通过双缓冲机制避免ID用完后加载新ID过程中引起的性能突刺。

  • 优点：ID趋势递增。代理服务有缓存，DB宕机后也能工作一段时间。
  • 缺点：ID有序。实现较复杂，引入了中间服务，存在性能损耗。

数据库+预置数据 #

每天日切后生成一批随机ID保存在数据库的未使用ID表中。应用或代理服务通过双缓冲机制获取ID，同时将表中ID移动到已使用ID表中。由于数据量够大，哪怕已使用ID表中的数据最终未被使用，也不用进行回滚。

  • 优点：数据随机。长度短，如果选择Base64算法每一位表示64位数据，那么6位数字就足够表示数百亿数据。
  • 缺点：实现复杂。数据无序，直接用作主键会引起页分裂。

Snowflake算法 #

64位 = 保留位(1位) + 时间序列(41位) + Worker_ID(10位) + 自增序号(12位）

当同一机器两次获取的时间戳一致时，序列号就递增；当序列号用完后，程序就自旋直到下一个时间戳到来。为了防止时间漂移生成重复ID，需要引入ZooKeeper等手段保存上次ID的生成时间，当发生时钟回拨时不提供服务，进入自旋一直到服务器追上当前时间。

  • 优点：高效，可以不依赖第三方组件（忽略时钟回拨的情况下）。
  • 缺点：强依赖时钟，会有时钟回拨问题。默认实现下时间序列从1970年开始最多记录69年。数据长度太长。QPS不高情况下自增序号可能一直为1，无法作为分区键。
  • 优化：
    • 在QPS不高的情况下，可以将时间序列改为以秒为基准，确保自增序号不会总是1，或者每次时间拨动时自增序号的起始值做一下随机。
    • 使用更紧凑的时间格式和机器ID。例如：20位 = yy（年的后2位） + mmddHHmmssSSS + IP第4位 + 4位序列号。

MD5/Hash算法（幂等性） #

为每个系统分配一个系统标识，一般3个英文字母即可。然后对（系统标识+数据）进行Hash计算，将结果作为分布式ID。

  • 优点：实现简单。ID全局唯一。
  • 缺点：数据无序，直接用作主键会引起页分裂。数据长度过长，MD5也有128位。同样的数据只会生成同样的ID。

在某些情况下可以用来实现幂等性，确保同样的数据不会被重复执行。