分片存储-细碎设计系列
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 分片,那么问题来了~
-
基于 UID 分片,前台服务登录时没有 UID,只有 user_name,不清楚账号数据落在哪张表,遍历扫全库么?性能低的丑陋。
用UID分片,如何高效实现查询?
这是本文要讨论的问题。
-
数据既然分片了,后台服务的多维度检索,跨分片汇总数据分页查询怎么搞?继续遍历全库内存计数么?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:学习不要光靠脑袋记,沉淀下来记到本子上才是自己的。
收工
打完收工,感谢阅读!
以上是关于分片存储-细碎设计系列的主要内容,如果未能解决你的问题,请参考以下文章