分片存储-细碎设计系列

Posted 晓旭z

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了分片存储-细碎设计系列相关的知识,希望对你有一定的参考价值。

摘要

系统设计中数据存储模型是核心部分,量级大、QPS 高,通常会通过分库降低CPU/内存/磁盘 IO 等系统瓶颈,通过分表降低单表量级过大从而导致的性能问题。那么类似分片存储后从业务角度看会有什么问题?索引法、基因法有是什么呢?

前言

大量的数据存储,常见的水平分片算法:

  • Range
  • Hash

水平分片算法比较普及,只是为了承上启下简单码了一些,懂的同学可以快速跳过!

Range

基于 Unique Key按照范围分片。切分的维度:

  • 基于固定量级分表,比如千万级分表。tb1:0-1000W、tb2:1000W- 2000W。
  • 基于时间维度分表,比如年、月。

优点:

  • 路由策略简单,按照资源范围快速定位到分片。
  • 扩展性,水平创建日后需要的表即可。

不足:

  • 数据分布严重不均匀。
  • 热点数据集中,单表过热。
  • 量级分表,Unique Key必须满足递增属性。

Hash

基于 Unique Key 取模,均匀分片。

优点:

  • 路由策略简单,Hash Unique Key快速定位分片。
  • 数据存储&请求量均匀分配,只要Unique Key是均匀的。

不足:

  • 扩展性差,扩容时成本较高。

以上是预热部分,当数据分片后对业务带来了哪些问题呢?

例子

Passport Service几乎是每一个公司必备的基础服务。

之前团队中负责设计passport 服务时有过 user 存储的思考和设计,简单说说。

Passport Service是一个非常常见的基础服务,主要提供账号通行证相关能力, 在使用场景中比如登录、注册、登出、登录态校验、更新等,其核心存储是一张 user 表:

比如:

CREATE TABLE `tb_user0` (
  `id` int(10) NOT NULL AUTO_INCREMENT COMMENT '表自增ID',
  `uid` bigint(20) NOT NULL DEFAULT '0' COMMENT '用户ID',
  `user_name` varchar(255) NOT NULL DEFAULT '' COMMENT '用户名,不区分大小些;统一成大写,加密后入库',
  `pwd` char(40) NOT NULL DEFAULT '' COMMENT '密码',
  
  `......`
  
  `update_time` int(10) NOT NULL DEFAULT '0' COMMENT '最后更新时间',
  `create_time` int(10) NOT NULL DEFAULT '0' COMMENT '创建时间',
  PRIMARY KEY (`id`),
  KEY `idx_uid` (`uid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户主表';

user_name 为登录用户名,通常会是手机号,需要脱敏

ok,这张表如何设计呢?

单表实现不合理,结合业务场景,水平分片是必须要有的。

账号量级大,请求量高,需要保证高可用和高一致性。UID作为 Unique Key,基于UID是高频查询,那么就基于 UID 水平分表。

前台服务相对核心的操作:

  • 登录。 基于 user_name+pwd实现登录,量级占大盘<=1%此处 UID 为结果数据
  • 校验登录态。基于 token 解析出 UID,判断登录态获取用户信息,量级占大盘>= 99%此处 UID 为起始数据

后台服务(MIS或运营管理后台) 操作:

  • 超多维度检索
  • 批量分页查询

问题

基于 UID 分片,那么问题来了~

  1. 基于 UID 分片,前台服务登录时没有 UID,只有 user_name,不清楚账号数据落在哪张表,遍历扫全库么?性能低的丑陋。

    用UID分片,如何高效实现查询?

    这是本文要讨论的问题。

  2. 数据既然分片了,后台服务的多维度检索,跨分片汇总数据分页查询怎么搞?继续遍历全库内存计数么?mysql 抗的住么?就算 Mysql 抗的住,后台用户等的起么?就算后台用户脾气好,客户端不会超时么?

    如何多分片高效检索汇总?

    这是本文要讨论的问题++。

方案

issue1: 用UID分片,如何高效实现查询?

方案一:索引法

思路:UID可以定位分片,user_name 无法直接定位,那么通过 user_name 定位 UID,进而定位分片。

方案

  • 基于 Mysql 建立索引表,存储user_name 与 UID 的 Mapping 关系。
  • 登录校验时基于索引表通过 user_name 查询到 UID,然后路由到指定分片获取数据。
  • 索引表属性少,理论上单行小,容量千万级没问题。
  • 整体模型就是:基于 Index索引表 +Meta 元数据表(分片)

问题:多一次 DB查询,性能相对降低。


方案二: 持久化缓存映射

思路:接受不了多一次 DB 查询,那就将映射关系持久化到缓存中。

方案:

  • 基于 缓存(Redis)存储映射关系
  • 登录校验时通过 user_name 到缓存中查询 UID,然后路由到指定分片。
  • 如果缓存没有查到,扫全库获取映射关系持久化到缓存

问题

  • 多一次 Redis 查询,其实也没啥。
  • 缓存击穿风险, Cache 中不存在,当高并发请求打进来,全部去 DB扫全库,引起 DB 压力瞬间陡增。
  • 缓存穿透风险,当 UID 在 Cache 和 DB 中都不存在,并且不断请求,这种攻击也会导致数据库压力过大。

普通场景下,索引+缓存就可以解决大部分问题


方案三:基于 username 生成 uid

思路:不想单独存储映射关系,直接通过 username 生成 uid

方案:这种通过字符串生成ID 的 Hash 函数很多,f(username) = uid

问题:

  • Hash 碰撞,UID 冲突的风险
  • username 不能更新

方案四: 基因法

思路: 从 username 中提取基因,加入到 uid 生成规则中。

方案:

这里需要引入分布式全局唯一ID 生成能力,该基因法依赖分布式 ID,后续会输出《分布式发号器》的文字,先简单普及下分布式 ID 生成的一种常见算法,Snowflake雪花

SnowFlake算法生成id的结果是一个64bit大小的整数,它的结构如下图:

在这里插入图片描述

  • 1bit,不用,因为二进制中最高位是符号位,1表示负数,0表示正数。生成的id一般都是用整数,所以最高位固定为0
  • 41bit-时间戳,用来记录时间戳,毫秒级
  • 10bit-工作机器id,用来记录集群+机器id
  • 12bit-序列号,序列号,用来记录同毫秒内产生的不同id,支持步长自增。

所谓基因算法就是提取 username的分片基因,合并到全局唯一的 ID 上,生成一个全新的 UID。如下图:

在这里插入图片描述

直接上 Demo 源码吧:

Demo 源码全局唯一 ID 基于 SnowFlake算法生成,对每个 Block 的 Bit 数简单调整了一下。

基础配置:

const (
	GENE_NODEIDID_BITS int64 = 10	// 机器节点 10Bit
	GENE_SEQ_BITS      int64 = 13	// 同时间同节点序列号 13Bit
	GENE_BITS          int64 = 12	// 分片基因 12Bit

	GENE_NODEID_MAX int64 = -1 ^ (-1 << GENE_NODEIDID_BITS)	// 机器节点最大值 1024
	GENE_SEQ_MAX    int64 = -1 ^ (-1 << GENE_SEQ_BITS)			// 序列号最大值 8192

	// 这块放弃了时间,为了保留基因。timestemp 单位 s,28个 bit 大约7 8年
	GENE_TIMESTEMP_SHIFT       = GENE_NODEIDID_BITS + GENE_SEQ_BITS + GENE_BITS
	GENE_NODEIDID_SHIFT  int64 = GENE_SEQ_BITS + GENE_BITS
	GENE_SEQ_SHIFT       int64 = GENE_BITS

	// 拒绝浪费,珍惜时间
	GENE_EPOCH int64 = 1624258189

	// 默认步长
	GENE_DEFAULT_STEP_LONG = 1
)

这是个 Demo,GENE_BITS位数需要根据分片数量决定,比如分16片,那么 GENE_BITS 4个 bit 就可以

基因 ID 实例:

type GeneID struct {
	m         sync.Mutex	// 读写锁
	timestemp int64				// 当前时间戳
	nodeID    int64				// 机器节点
	seq       int64				// 序列号
	geneID    int64				// 基因
	step      int64				// 序列号增长步长
}

样本基因提取:

// 基于基因样本提取基因ID
func ExtractGene(geneSample []byte) int64 {
	gene := md5.Sum(geneSample)
	hashGeneValue := fmt.Sprintf("%x", gene)[29:32]
	geneID, _ := strconv.ParseInt(hashGeneValue, 16, 64)
	return geneID
}
  • 样本 Hash 生成32位 MD5
  • 取末尾三个字符
  • 将字符串作为16进制转化成 int64 000-fff
  • 结果为基因 ID

基于雪花算法生成完整 ID:

func (g *GeneID) Generate() int64 {
	g.m.Lock()
	defer g.m.Unlock()

	now := time.Now().UnixNano() / 1e9 // 纳秒转秒
	if now == g.timestemp {
		g.seq = g.seq + g.step
		if g.seq > GENE_SEQ_MAX {
			for now <= g.timestemp {
				now = time.Now().UnixNano() / 1e9
			}
			g.seq = 0
		}
	} else {
		g.seq = 0
	}
	g.timestemp = now
	return g.timeBlock() | g.nodeBlock() | g.seqBlock() | g.geneBlock()
}

完整 Demo 源码可访问:https://github.com/xiaoxuz/idgenerator

不足: username 不能更新


issue2 : 如何多分片高效检索汇总?

思路 1:前后台数据解耦,资源存储隔离,避免后台低效查询引发前台查询抖动。

思路2:接受数据冗余存储设计,采用其他存储服务作为后台存储组件,数据双写异步写入

思路3:后台存储组件可以基于数据时效性选择:

  • 时效性要求高:选择Elasticsearch,基于其分布式倒排索引的特性,实时同步前台数据,并为后台服务提供多维度检索和聚合能力。
  • 时效性要求低:选择大数据相关服务,比如 小时级或天级 数据入 Hive

之前基于Elasticsearch做过前后台数据隔离设计,大概设计如下:

在这里插入图片描述

基于阿里开源的 Canal服务实时订阅消费前台 Mysql 的binlog,将 binlog 发布到 消息队列Kafka中。

下游可以通过 Flink 实时计算服务或者通过 Golang 实现的 Consumer来消费 Kafka 中的 Binlog,解析并且转存到Elasticsearch

后台服务基于Elasticsearch的 RESTful API实现实时检索和聚合需求。

总结

Issue1 : 用UID分片,如何高效实现查询?

  • 索引法
  • 缓存映射
  • username 生成 uid
  • 基因法

Issue2:如何多分片高效检索汇总?

  • 前后台资源隔离,冗余存储设计
  • 基于 Es 或大数据相关服务对后台数据进行存储,并提供实时&离线的数据能力。

思考

记忆力好比缓存,记笔记好比落盘。缓存总会失效,硬盘你可以多副本保留。

tips:学习不要光靠脑袋记,沉淀下来记到本子上才是自己的。

在这里插入图片描述

收工

打完收工,感谢阅读!

在这里插入图片描述

以上是关于分片存储-细碎设计系列的主要内容,如果未能解决你的问题,请参考以下文章

分片存储-细碎设计系列

分片存储-细碎设计系列

熔断-架构细碎设计系列

熔断-架构细碎设计系列

熔断-架构细碎设计系列

solr分布式索引实战分片配置读取:工具类configUtil.java,读取配置代码片段,配置实例