分布式全局id解决方案
「这是我参与11月更文挑战的第3天，活动详情查看：2021最后一次更文挑战」
一、为什么需要分布式全局id?
在互联网系统发展进程中，我们经历过从单体项目逐渐转向分布式项目。分布式项目解决了单体项目的代码臃肿，功能职责不明确，维护困难，不易扩展等毛病。
当并发度越大，数据越大就越需要分布式架构，而大量的分布式数据就越需要唯一标识来识别它们。
例如：
- 淘宝的商品系统有千亿级别商品，订单系统有万亿级别的订单数据，这些数据都是日渐增长，传统的单库单表是无法支撑这种级别的数据，必须对其进行分库分表；
- 一但分库分表，表的自增id就失去了意义；故需要一个全局唯一的id来标识每一条数据。
二、全局唯一id特点？
全局唯一性：整个分布式服务系统中不能出现重复的ID。单调递增：保证生成的下一个ID一定大于上一个ID，单调递增会顺序添加到数据索引的节点的后续位置，当一页写满，就会自动开辟一个新的页，不需要移动数据重构索引树，减少碎片。趋势递增：在一段时间内，生成的ID是递增的趋势，提高写入性能。如：在一段时间内生成的ID在【0，1000】之间，过段时间生成的ID在【1000，2000】之间。但在【0-1000】区间内的时候，ID生成有可能第一次是12，第二次是10，第三次是14。信息安全：如果 ID 是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL即可；如果是订单号就更危险了，竞争对手可以直接知道我们一天的单量。所以在一些应用场景下，会需要无规则、不规则的 ID。
第2、4两个需求是互斥的，无法同时满足。
同时，在大型分布式网站架构中，除了需要满足ID生成自身的需求外，还需要ID生成系统可用性极高。因此，做一个全局唯一id生成系统必须满足以下特点：
- 高可用
- 高QPS。
三、分布式id实现技术有哪些
- UUID
- MySQL多实例主键自增
- snowflake雪花算法
- Redis生成方案
- MongoDB的ObjectId
- 利用zookeeper生成唯一ID
注：本文只讨论redis生成的方案
四、基于Redis实现分布式全局唯一id
INCR 命令主要有以下2个特征：
- Redis的INCR命令具备了“INCR AND GET”的
原子操作，即增加并返回结果的原子操作。这个原子性很方便我们实现获取ID. - Redis是
单进程单线程架构，INCR命令不会出现id重复.
基于以上2个特性，我们可以采用INCR命令来实现分布式全局ID生成。
五、案例实战：采用redis生成全局id
技术思路：
- 采用redis的INCR的命令，从1自增生成ID。
- 由于海量数据，我们不能放到一张表中，故必须对其进行分库分表，每张表的id不能用自增，由redis的incr命令来自动生成。
- 海量数据需要分库分表，例如商品表 product_0,product_1,product_2......product_1023
步骤1：编写全局id封装类
@Service
public class IdGenerator {
@Autowired
private StringRedisTemplate stringRedisTemplate;
private static final String ID_KEY = "id:generator:product";
/**
* 生成全局唯一id
*/
public Long incrementId() {
long n=this.stringRedisTemplate.opsForValue().increment(ID_KEY);
return n;
}
}
复制代码步骤2：模拟创建商品
@RestController
@Slf4j
@RequestMapping(value = "/pruduct")
public class ProductController {
@Autowired
private IdGenerator idGenerator;
@PostMapping(value = "/add")
public void add(Product product) {
//步骤1：生成分布式id
long id=this.idGenerator.incrementId();
//全局id，代替数据库的自增id
product.setId(id);
//步骤2：取模，计算表名
//类似于海量的数据，一般是分为1024张表。
int table=(int)id % 1024;
String tablename="product_"+table;
log.info("插入表名{}，插入内容{}",tablename,obj);
}
}
复制代码
近期评论