中间件复习之-分布式存储系统

单机存储系统介绍

存储引擎:存储系统的发动机,提供数据的增、删、改、查能力,直接决定存储系统的功能(支持怎么样的查询,锁能锁到什么程度)和性能(增删改查速度)。

  • 性能因素
    • 写入方式
      • 顺序写
      • 随机写
    • 读取方式
      • 随机读
      • 顺序扫描
        无论是HD还是SSD硬盘,都是顺序读写性能高一些。
        在这里插入图片描述

单机存储引擎

  • Hash存储引擎:点查的场景,不适合范围查询
  • B树存储引擎:有序,适合范围查询
  • LSM存储引擎:一颗大树拆分成n多的小树

Hash存储引擎

有一个hashTable,PK经过hash计算,找到了HashTable的位置。
先通过fileid找到文件,再通过pos偏移量找到位置,再通过size得到存储数据。
在这里插入图片描述
特性:

  • 时间复杂度O(1)
  • 满足“=”、“IN”查询
  • 不支持范围查询
  • 不支持排序

代表产品:Redis、Memcached

B树存储引擎

MySQL通过该结构做聚簇索引、二级索引。
查找原素时从根结点指针入口进行查找。如果是聚簇索引,叶子节点跟的就是value,如果不是聚簇索引,跟的就是PK。
各个叶子结点双向链表连接。可以通过DATA指针做全表扫描。
在这里插入图片描述
特性:

  • 根节点常驻内存,最多h-1次磁盘IO
    • 蓝色那一层是在内存中的,最坏的话如图,查找2次。橘色读一次磁盘,红色读一次磁盘。(大多数情况蓝色和橘色都在内存中)
  • 非叶子节点容纳尽量多的元素
    • 一页最大16k
  • 擅长范围查询
  • 随机写问题
    • 因为数据是有序的所以写入文件不是顺序写入。比如写入37,不能直接写到尾节点98的后面。
  • 节点分裂
    • 比如35,36节点页满了,还想插入37,那就要分裂节点重新连接。

代表产品:MySQL-InnoDB

LSM存储引擎

所有的写入(更新、插入、删除)都往MemTable中写(为了方式内存里的数据不丢,会同时写.log文件),写满之后锁住当前的MemTable->Immutable MemTable,往磁盘中刷数据。新的写入新构建一个MemTable。
Immutable MemTable写入Level0层,Level0层有序,但是各个模块数据有交叉。(如第一块0-100,第二块95-195)
Level0内的文件多到一定程度后会往下压缩。
Level1内的文件数据不会有交叉。
在这里插入图片描述
删除、更新如何做?
因为LSM的存储结构是一层层结构,如果更新的话需要找到该数据每一层的位置并执行更新,非常复杂,所以更新使用以下的方式去执行。
更新:往MemTable中写入一个新的记录 K1:V1(原来K1:V0);查找时查找到level0的最新的记录( K1:V1)就直接返回了。
删除:往MemTable中写入一个新的记录 K1:deleted;查找时找到level0的最新记录就直接返回了。
整体的数据一层层往下沉,发现冲突了,就按照最新的记录做合并。

特性:

  • 随机写变顺序写
    • 插入、更新、删除都转换成了顺序写
  • 牺牲读性能
    • Level0读不到读Level1;Level1读不到读Level2
  • 增加后台合并开销
    • 文件往下沉

读可能需要读多层文件 设计初衷是什么?
写入优化比较困难,读的话可以增加多层中间缓存做优化。

LSM存储引擎特性
  • Flush:Immutable MemTable -> Level0
  • SSTFile:L0、L1、L2等文件都称为SSTFile
  • Compaction(压缩):L0多个文件合并成L1,L1多个文件合并成L2
LSM存储引擎优化
  • 布隆过滤器快速判断(读优化)
  • 文件内数据有序(读优化)
代表产品

LevelDB(谷歌项目)、RocksDB(嵌入式存储引擎)

存储模型

数据模型是存储系统的外壳,描述存储系统以什么样的形式存储或管理数据

  • 关系模型(表间的关系)
  • 键值模型(K-V存储)
  • 时序 influxDB:主要用于监控场景
    • 组织结构: 时间戳t1-(。。。。。一些数据),时间戳t2-(。。。。。一些数据)
  • 图 风控、算法场景主要使用

Redis存储原理深入剖析

Redis原理分析

Redis是用C语言开发的一个开源的高性能键值对(key-value)内存数据库。

  • 数据存储原理
  • 数据固化方式
  • 可靠性保障方案

Redis数据存储原理

在这里插入图片描述

  • redisDB(一个数据节点)
  • dict
  • dictht(ht -> hashTable)
  • dictEntry
    • union c语言的一个联合体,内部的数据不是同时有效而是只能存在一个。
      在这里插入图片描述
      一个redisDB代表一个数据节点,包含2个dict,一个dict存储数据,一个dict存储过期时间。
  • RedisObject
    • type:key的类型
    • encoding:key的编码
    • ptr-key的指针:key的值需要一个结构去描述,因此指向一个sds
      • sds
        • len:key的长度
        • alloc:分配空间
        • buf:key的内容

Key对存储效率的影响

dictEntry:16字节
RedisObjct:12字节
sds:8字节+字符串长度
一个10个字节的key需要的空间数量:16+12+8+10+1 = 47,再加上过期时间要存储的dict还需要*2,将近100字节。
redis除了本身要存的数据存储空间还需要额外增加一些其他redis基本存储结构的存储空间。

内存清理

定期删除

1、 能否直接遍历过期字典表(expires dict)按照过期时间删除?
不可,redis单工作线程,如果花大代价去过滤所有的过期字典表会影响工作线程。
redis的策略:找到平衡点,随机选择dictEntry判断是否过期然后做清理。如果发现清理的数量大于查找数量的25%了,那redis认为有很多数据已经过期了,那就再执行一次循环,删除过期。
在这里插入图片描述

惰性删除

当客户端尝试访问一个键时,Redis服务器才会检查这个键是否已经过期。如果发现该键已过期,则在返回结果前立即将其从数据库中删除。这种策略节省了CPU资源,因为它只在访问时才进行检查和删除操作,但存在可能长时间不访问而导致内存无法及时释放的风险。

LRU

redis内存不够用了,需要淘汰一些内存。
LRU策略尽量使用volatile-lru。

  1. 每个redisObject中都存在一个LRU_BIITS,标识这条记录最近一次的访问时间。
  2. 定时清理时随机从所有数据中选出几个元素,根据LRU_BIITS做排序,然后淘汰最久没被使用的节点。
    在这里插入图片描述
    在LRU时钟升序队列为5的时候,效果不是很好,当升级到10之后深灰色的点就少很多效果就好很多了。
    在这里插入图片描述

LFU

按照使用频率做淘汰策略,使用频率低的先淘汰。
在这里插入图片描述
先淘汰C。
在这里插入图片描述
同理,LFU优先使用volatile-lfu的策略。LFU重用了LRU_BIITS字段,将他拆分为2段。
时钟:访问的计时,但是精度没原来那么高了。计数器:访问频率,一段时间内的请求数量(目前最多放255)。
因为计数器目前最大只能到255,线上实际环境存在比255大得多的业务场景。因此redis针对这个最大值做了优化。
优化方案:引入lfu-log-factor,调整计数器counter的增长速度。以及调整频率减少的速度。
在这里插入图片描述
factor设置为0时,100次命中则值为104;设置为1时100次命中值为18;10为10;100为8;

Redis数据固化方式

  • RDB
    • 快照
    • 手动/自动触发
  • AOF
    公司目前redis只用作缓存,允许挥发,只针对从库做AOF

RDB快照方式

  • 手动方式
    • 手动调用save方法:工作线程去执行,阻塞当前Redis服务器,直到备份完成RDB过程完成为止。
  • 自动方式
    • bgsave:后台执行,fork子进程,持久化过程由子进程负责,完成后自动结束。
    • 配置项:save m n,m秒存在n次写入,触发bgsave。
    • 优点:
      • 对Redis性能影响低(子进程)
      • 二进制压缩文件体积小(dump镜像,不是日志这种形式,所以是二进制文件体积小,压缩效果比较好)
      • 数据恢复快(文件直接读到内存里就恢复了)
    • 缺点:
      • 由数据丢失可能 save m n,m(时间)到了但是n(次数)没到,此时服务挂了就会丢失数据。
      • 备份文件版本兼容问题 数据固化到磁盘了,不同版本可能存在不同的数据组织方式,可能高版本的固化文件,低版本恢复不了。
  • RDB快照方式存储流程
    • 写临时文件(tmpfile)
      • dump内存数据时可能存在异常,为了不影响源文件,所以先写临时文件
    • 覆盖老文件
    • 在这里插入图片描述

AOF

  • append only file
  • 日志形式记录,写入指令
  • 能做到实时持久化
AOF存储过程

在这里插入图片描述

  • 命令写入
  • 文件同步
    • 文件同步配置(一般当缓存,不会做always)
    • 在这里插入图片描述
  • 文件重写(一直追加,会存在无效数据,恢复的时候会做很多无效操作。因此清除无效的操作,保留最终结果。比如add update 然后又多次update 然后再delete)
    • 整理压缩aof文件(清理无效数据)
      • 整理方式
        • 过期数据(过期的key清除掉)
        • 重复更新(保留最后一条)
        • 删除数据(已删除的也不需要了)
        • 命令聚合
      • 手动触发
        • 调用bgrewriteaof命令
      • 被动触发
        • auto-aof-rewrite-min-size :触发aof重写的最小值
        • auto-aof-rewrite-percentage :(当前大小-上次触发完大小 )/ 上次触发完大小的最小比例
        • aof_current_size:当前AOF文件大小
        • aof_base_size:上一次压缩完以后的大小
        • 被动触发公式:
          • 当前AOF size>auto-aof-rewrite-minsize && (当前AOF size - aof_base_size)/aof_base_size >= auto-aof-rewritepercentage
AOF文件重写过程
  • fork子进程不影响父进程处理请求
  • 子进程双写(双写2个buf,aof_buf、aof_rewrite_buf),确保数据不丢失
    • 如果不做双写的话只写入到aof_rewrite_buf,当写aof_rewrite_buf失败了,那数据就丢失了。
      在这里插入图片描述

Redis重启恢复过程

在这里插入图片描述
redis恢复的小坑:当开启aof,但是没有aof文件时(同时存在rdb文件),**此时启动后空数据会覆盖掉rdb文件导致文件丢失。**应当启动时先关闭aof,等rdb启动恢复完之后再打开aof。

Redis可靠性保障

可用性保障方案

  • 主从模式
  • 哨兵模式
  • 集群模式

主从模式

  • 全量同步
    • Redis Slave新节点启动之后给主节点发送同步请求。
    • 主节点创建快照,缓存些命令(创建快照过程中的新命令会一并缓存后续同步)。
    • 将快照发送给从节点,从节点加载快照
    • 将缓存的命令同步给从节点,从节点装载数据
  • 增量同步:后续新的命令做增量同步
  • 运行ID
    • Master启动时生成
    • 同步给Slave
    • Slave通过运行ID与Master建立关系
  • 复制偏移量
    • 确定同步位置

哨兵模式

  • 哨兵模式可以认为就是一个监控:不断地检查Master和Slave是否运作正常;
  • 提醒:发现故障通知管理员和客户端;
  • 故障转移:自动主从切换,更新配置信息;
  • 集群配置信息提供 :客户端应用初始化时连接Sentinel(哨兵)获取节点信息;
    在这里插入图片描述
    如果客户端直连master的话,当集群发生故障切换主从时,客户端还得感知变化。因此引入VIP层的概念,架构图如下:哨兵模式架构:对client完全透明
    在这里插入图片描述

集群模式(分布式方案)

  • 无需Sentinel哨兵
  • 支持水平扩容
  • 自动迁移
    在这里插入图片描述
    集群模式引入的问题:不支持批量操作(同时查多个key),因为多个key不知道分散在哪个槽,因此只能一个个查询。
    集群模式的实现:
  • 客户端路由
  • 两次交互:给集群中的任意一个master发请求,计算key是否在自身,不是的话告诉客户端应该访问哪个节点。
  • 存在性能问题:集群越多,两次交互的概率就更大。
    在这里插入图片描述

集群模式(Codis)

  • codis-redis-group:一主一从
  • codis-proxy:redis协议代理,对客户端来说连接的都是一样的codis-proxy(proxy做路由,不需要2次交互)

特点:

  • 数据分片策略对客户端透明
  • Zookeeper作为name server (存储分片信息)
  • 提供支持Redis协议的Proxy
  • Proxy负责请求路由
    在这里插入图片描述

MySQL InnoDB存储原理深入剖析

MySQL记录存储格式

  • 页头:记录页面的控制信息,共占56字节,包括页的左右兄弟页面指针、页面空间使用情况等。
  • 虚记录:标识页面记录的范围
    • 最大虚记录:比页内最大主键还大(innoDB数据按主键聚簇索引有序)
    • 最小虚记录:比页内最小主键还小
  • 记录堆:行记录存储区,分为有效记录和已删除记录两种
  • 自由空间链表:已删除记录组成的链表
  • 未分配空间:页面未使用的存储空间
  • Slot区
  • 页尾:页面最后部分,占8个字节,主要存储页面的校验信息
    在这里插入图片描述

页内记录维护

  • 顺序保证:如何保证顺序?
  • 插入策略:如何插入?优先往哪里写?
  • 页内查询:如何定位page?
    在这里插入图片描述

顺序保证

  • 物理连续(类似数组,往前插入的话就往后挪)
  • 逻辑连续(链表连接)
    在这里插入图片描述

为了方便空间利用率,因此选择逻辑连续。
在这里插入图片描述
在这里插入图片描述

页内也是逻辑连接。

插入策略

  • 自由空间链表(蓝色的已删除记录):为了增加内存利用率,优先使用该空间。
  • 未使用空间:其次使用未使用
    在这里插入图片描述

页内查询

  • 遍历(直接一个个查询,性能不好)
  • 二分查找(物理连续+定长),可以使用二分查找,但是mysql是逻辑连续。
    • 引入Slot槽位,根据页面里的一些值的特性定义多个槽位,通过Slot去连接起来,比如S0指向Record0,Sn指向Recordn,其余指向中间。这时候找数据时,就可以先在n多个槽位内做二分查找,然后再在链表中做遍历。实现一个近似二分查找的功能。
      在这里插入图片描述

变长数据存储-InnoDB

  • PageSize 16KB;
  • 每页至少两条数据
    • 单行最大8KB;
  • 最多存储10个大字段;
    • 数据段最大768;
    • 超出部分存储在溢出页;
    • (768+20)*10 < 8K; (最大10个的原因)
  • VARCHAR
    • 1或2个字节描述字符长度;
    • 实际内容存储在长度字节之后;如下
      VARCHAR(255) 1个长度字节+内容
      VARCHAR(256) 2个长度字节(一个不够了)+内容

MySQL InnoDB索引实现原理及使用优化分析

索引原理分析

  • 聚簇索引(主键索引和数据放在一起)
  • 二级索引(非聚簇索引都叫二级索引,key对应的data是主键值,要回到聚簇索引拿值)
  • 联合索引
    在这里插入图片描述
聚簇索引特性
  • 数据存储在主键索引中
  • 数据按主键顺序存储
  • 自增主键 VS 随机主键??如何选择
    • 自增主键:顺序写,没有页分裂的情况。
    • 随机主键:
二级索引特性
  • 除主键索引以外的索引都叫做二级索引
  • 叶子中存储主键值(Primary Key)
  • 一次查询需要走两遍索引(回查聚簇索引)
  • 主键大小会影响所有索引的大小(主键如果很大的话,二级索引的叶子结点data就会很大)
    在这里插入图片描述
联合索引特性
  • Key由多个字段组成
  • 最左匹配原则,先匹配第一个
  • 一个索引只创建一棵树,如下图
  • 按第一列排序,第一列相同按第二列排序
    在这里插入图片描述
    如果不是按照最左开始查找,无法使用索引,不能跳过中间列。某列使用范围查询,后面的列不能使用索引。如a、b、c为联合索引,当用where b=xxx,c=xxx来查询的话是无法使用联合索引的;where a=xxx,c=xxx 只能使用a=xxx;where a=xxx,b>xxx,c=xx 这样也无法用上c的索引

索引使用优化分析

  • 存储空间
  • 主键选择
  • 联合索引使用
  • 字符串索引
存储空间
  • 索引文件大小是由什么决定的?
  • 字段大小->页内节点个数->决定page的数量->树的层数;
    16KB -> 一个PageSize
    BIGINT类型主键3层可以存储约10亿条数据
    16KB/(8B(key-主键数据)+8B(指针))=1K
    10^3 * 10^3 * 10^3 = 10亿
    32字节主键3层可以存储6400W
主键选择
  • 自增主键,顺序写入,效率高;
  • 随机主键,结点分裂、分裂后就需要做数据移动;

**自增主键:写入磁盘利用率高,每次查询走两级索引;(业务键做查询,查询到PK后回查数据) **
随机主键:写入磁盘利用率低,每次查询走两级索引;
业务主键:写入、查询磁盘利用率都高,可以使用一级索引;(用递增的业务主键会比自增主键更好,推荐使用)
联合主键:影响索引大小,不易维护,不建议使用;

联合索引使用
  • 按索引区分度排序(索引区分度高的放前面,第一个条件能筛掉80%的数据,剩下的就不多了,区分度就高)
  • 覆盖索引(查询的结果直接在联合索引中)
字符串索引
  • 字符串的比较是按照字节去比较,比如abc和abb比较,先aa比较,再bb比较,再cb比较。
  • 若要设置成索引的话,就需要设置合理的长度
  • 不支持%开头的模糊查询(直接全表扫描)

MySQL InnoDB存储引擎内存管理

InnoDB内存管理

  • 预分配内存空间(频繁的分配和销毁内存空间开销比较大,因此做预分配)
  • 数据以页为单位加载
  • 数据内外存交换(磁盘数据加载到空页,内存数据发生变更同步到磁盘)
    在这里插入图片描述

InnoDB内存管理—技术点

  • 内存池(预留一片空间作为预分配空间)
  • 内存页面管理
    • 页面映射(内存页和磁盘页映射)
    • 页面数据管理
  • 数据淘汰(内存页空间小于磁盘页,当要加载新数据时且内存页满情况下,需要淘汰老的内存页数据)
    • 内存页都被使用
    • 需要加载新数据
InnoDB内存管理—页面管理
  • 空闲页(无数据页)
  • 数据页(有数据页,只用于读,暂时没有写入,随时可淘汰)
  • 脏页(page内有更新或者插入)
InnoDB内存管理—页面淘汰
  • LRU
    每一个节点代表每个页面。访问哪个页面,该页面就变成链表头,没有空间了就在尾部淘汰页。
    在这里插入图片描述
    思考: 全表扫描对内存的影响?
    对于一个数据库来说,不能简单做LRU,当全表扫描一次后,内存里的数据一直滚动清除,只剩下某一张表的数据。

解决问题:避免热数据被淘汰
思路:

  • 访问时间 + 频率?lru+lfu
  • 两个LRU表?冷热分离
    MySQL是如何解决的…?

MySQL内存管理

  • Buffer Pool
  • 预分配的内存池
  • Page
  • Buffer Pool的最小单位
  • Free list
  • 空闲Page组成的链表
  • Flush list
  • 脏页链表
  • Page hash 表
  • 维护内存Page和文件Page的映射关系
  • 查询数据先从内存中找,找不到再去磁盘中查找
  • LRU List(所有有数据页都在这个链表下)
  • 内存淘汰算法
    在这里插入图片描述
LRU

内存管理操作:

  • 页面装载
    • 磁盘数据到内存
  • 页面淘汰
  • 位置移动(new和old间的位置移动)
  • LRU_new的操作

lru分了两段

  • LRU_new
  • LRU_old
  • Midpoint(指向链表中间,左边new,右边old)
  • 分成两段的初衷就是为了做冷热分离,若发生全表扫描,则只在old里发生淘汰,不在new里做淘汰。
    在这里插入图片描述
页面装载
  • 磁盘数据到内存
    1. 从空闲链表取出空闲页
    1. 写入映射关系
    1. 链入LRU-old(新数据先放到old中)
      在这里插入图片描述
页面淘汰
  • LRU尾部淘汰
  • Flush LRU淘汰:LRU链表中将第一个脏页刷盘并“释放”
    • 释放:淘汰完后直接放到FreeList中(MySQL5.x做的优化,以前是放到LRU尾部)
      在这里插入图片描述
      没有空闲页时:
      Free list中取 > LRU List中淘汰 (如果取不到Free list)> LRU Flush(如果LRU不能淘汰,则从后往前找找到第一个脏页然后释放)

在这里插入图片描述

位置移动(new和old间的位置移动)
  • old到new

    • 移动时机思考
      • 假设一个page有很多条记录,一次全表扫描就会短时间内多次访问这个page,那是否该放到new?
      • innodb_old_blocks_time:old区存活时间,大于此值,有机会(虽然存活时间长,但是没被访问的话就没法触发进入new)进入new区
      • 每次访问该page时判断now-放入时间
        在这里插入图片描述
  • new到old(热数据到冷数据)

    • 当发生old -> new,或者old淘汰,都会发生链表长度变更。只要在每次链表长度发生变更时保持好Midpoint:指向5/8位置,就实现了new到old的变更。
      在这里插入图片描述
LRU_new的操作

LRU_new内部的一些操作:链表操作效率很高,每次有新的针对LRU——new访问的时候将LRU_new里的节点移动到表头Head?
因为链表移动需要加锁,所以频繁移动会有性能开销,因此针对移动MySQL做了策略。

MySQL设计思路:减少移动次数
两个重要参考:
1、freed_page_clock:Buffer Pool淘汰页数(每淘汰一个页freed_page_clock就++)
2、LRU_new长度1/4
当前freed_page_clock - 上次移动到Header时freed_page_clock > LRU_new长度1/4
从上次成为Header到现在,整个内存发生了多少次的页面淘汰。 如果淘汰次数大于LRU_new长度1/4,就认为可能比较危险了,需要再次将节点移动到头。

MySQL事务管理机制原理

MySQL事务基本概念

  • 事务特性
  • 并发问题
  • 隔离级别

事务特性

  • A(Atomicity原子性):全部成功或全部失败
  • I(Isolation隔离性):并行事务之间互不干扰
  • D(Durability持久性):事务提交后,永久生效
  • C(Consistency一致性):通过AID保证

并发问题(找相关的demo资料)

  • 脏读(Drity Read):读取到未提交的数据
  • 不可重复读(Non-repeatable read):两次读取结果不同
  • 幻读(Phantom Read):select 操作得到的结果所表征的数据状态无法支撑后续的业务操作

隔离级别

  • Read Uncommitted(读取未提交内容):最低隔离级别,会读取到其他事务未提交的数据,脏读
  • Read Committed(读取提交内容):事务过程中可以读取到其他事务已提交的数据,不可重复读
  • Repeatable Read(可重复读):每次读取相同结果集,不管其他事务是否提交,幻读
  • Serializable(串行化):事务排队,隔离级别最高,性能最差;

MySQL事务机制原理分析

  • MVCC
  • undo log
  • redo log
MVCC

多版本并发控制,解决读-写冲突问题,通过隐藏列(DB_TRX_ID-,DB_ROLL_PTR)实现。

隐藏列:

  • DB_TRX_ID:不管是记录创建插入、还是更新,都在一个事务内。MySQL InnoDB事务id全局唯一,全局递增。

  • DB_ROLL_PTR:回滚指针,指向上一个记录。

  • 当前读(读数据的最新版本,加锁)

  • 快照读(有一个比较策略,判断本次要读的是哪个历史的某个版本)
    在这里插入图片描述

  • 可见性判断

    • 查询时创建快照这一刻,还存在未提交的事务,那看不到本次事务。
    • 创建快照之后创建的事务,本次查询也看不到。
  • Read View(可见性判断的实现通过Read View来做)

    • 快照读 活跃事务列表
      • 在select这一刻会把当前活跃的事务id(已经创建的事务单未提交的)全部取出来。
    • 获取列表中最小事务ID
    • 获取列表中最大事务ID(不存在的事务ID,当前最大的事务+1)

查询的时候判断能否看到这条记录的逻辑:

  • 查询到db里的记录并获取到TX_ID,如果比活跃事务链表里最小的还小,那db里这条记录可见。
  • 如果查询到的记录的TX_ID比最大的还大,那最新数据是在查询生成快照这一刻之后生成的事务,本次快照查询就查不到db里的这条记录,然后通过回滚指针找上一个版本。
    在这里插入图片描述
    MVCC需要历史数据的支持,历史数据是怎么支持的?存储结构是如何的?
    请看下面undo log和redo log。
undo log
  • 回滚日志:用来做事务回滚(保存个历史版本)
  • 保证事务原子性(用回滚日志来保证都成功或者都失败)
  • 实现数据多版本
  • delete undo log:用于回滚,提交即清理;
  • update undo log:用于回滚,同时实现快照读,不能随便删除
    在这里插入图片描述
    回滚指针指向undo_log
    undolog如何清理??
    依据系统活跃的最小活跃事务ID做一个 Read view。如果这条记录都可见了,那之前的记录都可以删除了。
redo log

用于实现事务持久性

  • 记录修改(记录本次的修改)
  • 用于异常恢复(事务没来及刷盘,就挂了,用于恢复本次修改)
  • 循环写文件
    • Write Pos:写入位置
    • Chick Point:刷盘位置(Chick Point往右到Write Pos表示没刷盘的数据)
    • Chick Point -> Write Pos:待落盘数据
      在这里插入图片描述

写入流程

  • 记录页的修改,状态为prepare
  • 事务提交,将事务记录为commit状态(生效redolog)
    在这里插入图片描述

刷盘时机:innodb_flush_log_at_trx_commit
下图是commit后做的事情,分三种策略。
在这里插入图片描述
redolog存在意义(为什么不拿Page直接刷盘?)

  • 体积小,记录的是页面的修改,不是整个页面,比写入页代价低。
  • 末尾追加,随机写变顺序写(page的刷盘随机写),发生改变的页不固定。

MySQL使用及调优实践分析

索引使用技巧

  • 联合索引:优于多列独立索引
  • 索引顺序:选择性高的在前面
  • 覆盖索引:二级索引存储主键值更有利
  • 索引排序:索引同时满足查询和排序

分库分表设计

  • 是否分表
    • 建议单表不超过1KW
  • 分表方式
    • 取模:存储均匀&访问均匀
    • 按时间:冷热库
  • 分库
    • 按业务垂直分
    • 水平查分多个库

使用建议

  • 数据库字符集使用utf8mb4;
  • VARCHAR按实际需要分配长度;
  • 文本字段建议使用VARCHAR;
  • 时间字段建议使用long;
  • bool字段建议使用tinyint;
  • 枚举字段建议使用tinyint;
  • 交易金额建议使用long;
  • 禁止使用“%”前导的查询;
  • 禁止在索引列进行数学运算,会导致索引失效;
    • select * from t1 where id+1 >1121 **不会使用索引 **
    • select * from t1 where id >1121 - 1 会使用索引
  • 表必须有主键,建议使用业务主键;
  • 单张表中索引数量不超过5个;
  • 单个索引字段数不超过5个;
  • 字符串索引使用前缀索引,前缀长度不超过10个字符;

RocksDB数据库存储原理分析

RocksDB:使用C++编写的嵌入式kv存储引擎,其键值均允许使用二进制流。由Facebook基于levelDB开发。

  • Log Structured-Merge Tree
  • LSM的设计依据
  • 随机写转换成顺序写(提升写性能)
  • 优化读性能
  • 三种数据结构
    • MenTable
    • logfile
    • sstfiles
      在这里插入图片描述

RocksDB写入

  • 插入
    • 记录log
    • MenTable写入新记录
  • 更新
    • 记录log
    • MenTable写入新记录
  • 删除
    • 记录log
    • MenTable标记key删除
      WAL:write-ahead log,先记录日志,再写数据。确保数据不丢失 全部是内存写入,没有磁盘I/O
      MenTable写满后写入磁盘,顺序I/O

LSM读

  • 读MemTable
  • 定位sslFile(每个sslFile都是一个小的SLM tree,数据有序),文件内查找。数据有交叉,第一层查询时每个文件都需要查一下。
    在这里插入图片描述

RocksDB读优化

  • 数据冗余:定时压缩,清除冗余数据,减少文件数量;
  • 布隆过滤器:提高检索效率;
  • 文件分层
  • 页面缓存

RocksDB性能问题

  • 读放大:按层查找
  • 空间放大:顺序写造成,更新和插入都是新记录。
  • 写放大:压缩造成

分布式存储技术

原理分析

CAP定理:在一个分布式计算机系统中,一致性,可用性和分区容错性这三种保证无法同时得到满足。

  • Consistency 一致性
  • Availability 可用性
  • Partition Tolerance分区容错性
    在这里插入图片描述
    CAP取舍
  • CP:发生分区,需要牺牲用户的体验,等待所有数据全部一致了之后再让用户访问系统。
  • AP:发生分区,为了高可用,每个节点只能用本地数据提供服务,会导致全局数据的不一致性。
    理想情况下 单机数据库 AC;
    分布式数据 库系统 CP;

单机数据库分布式解决方案

  • 垂直拆分
  • 水平拆分
  • 读写分离
    业务侵入大,维护成本高 带来分布式事务问题!

分布数据库特性

  • 存储量不受单机容量限制(存储量按机器数量水平扩展)
  • 计算能力不受单机资源限制
  • 扩展性强
  • 容错能力强
  • 数据可靠性高

分布数据库设计思路

  • 多副本存储(一份数据做多个副本,raft协议同步)
    • 保证数据一致性
    • 一般使用KV存储模型
  • 主从模式
    • 提供数据分片路由支持

多副本存储方式

  • 不是一份完整的数据,一张表的数据可能分散在多个实例
  • 底层KV存储
  • 数据一致性协议(raft)
    在这里插入图片描述
技术难点
  • 热点数据(读写请求都到Leader)
    • 数据分块(可能一个Node上的数据全部都是Leader)
    • 热数据迁移(需要均匀分散每台机器的Leader)
  • 原子性
热点数据

倘若Node2的Leader过多,则可以在Node1的节点上加一个新的block节点,然后将Node2的Leader-block下线。
实时调整块位置将读写频繁的块均匀分布在各个存储节点
调整前:
在这里插入图片描述
调整后:
在这里插入图片描述

原子性

保障多个Key写入的原子性,Percolator 谷歌分布式事务模型

  • 乐观锁方式实现事务:以下是2个事务执行的动作。
    在这里插入图片描述

  • 两阶段提交

    • prewrite 获取锁 写入数据(写入内存)
    • commit 提交变更
  • 隐藏列:L列(锁)&W列(事务更新时间戳)

  • 前提:T1时刻开启事务,T3时刻提交。提交时T1>X 表示在T1事务开启之后,这条记录没有被改过,因此可以上锁。

  • 加锁成功后修改记录,将write修改成T3

  • T4时刻提交T2时刻开启的事务,此时T2<T3,有冲突,提交失败。
    在这里插入图片描述
    在这里插入图片描述

常见分布式存储产品

  • MongoDB
  • Pika(360)
  • Pegasus(小米)
  • Titan(美图)
  • Codis(Redis分布式解决方案)
  • TiDB

分布式存储技术产品选型及适用场景分析

分布式存储分类

数据模型维度

  • NoSQL
    • MongoDB
    • Pika(360)
    • Pegasus(小米)
    • Titan(美图)
    • Codis
  • 关系型
    • TiDB
      持久化维护
  • 内存
    • Codis
  • 固化
    • TiDB
    • MongoDB
    • Pika
    • Pegasus
    • Titan

MongoDB

  • 文档型数据库
  • 支持主从同步
  • 支持副本集模式
  • 支持数据分片
  • 快速水平扩展
  • 高效数据压缩
    在这里插入图片描述
    Mongos是路由节点,客户端访问路由节点。

TiDB

  • SQL语句支持(支持关系型查询)
  • 水平线性弹性扩展
  • 分布式事务
  • 数据强一致性保证
  • 故障自恢复的高可用
TiDB架构
  • 基于RocksDB
  • Raft一致性协议(TiKV Cluster-Storage 集群)
  • Etcd存储元数据(定位的Key在哪放在TiPD-PD Cluster)
  • 支持OLTP(线上业务)
  • 支持OLAP(线下分析,开启读写分离)
    在这里插入图片描述

Codis

redis分布式解决方案
在这里插入图片描述

Pika

  • 360开源
  • 可持久化
  • 容量受单机磁盘限制
  • 支持主从部署
  • 支持Redis协议
    结合Codis的Proxy 提供分布式解决方案
    将上图codis-redis的位置换成pika
实现原理
  • 基于RocksDB存储
  • 提供Redis协议代理
  • 基于BinLog实现主从同步
  • 磁盘换内存
    在这里插入图片描述
Pika List存储设计
  • 元素节点
  • 元数据节点
    在这里插入图片描述

Pegasus

  • 小米开源
  • 持久化KV存储系统
  • 支持Redis协议
  • 支持数据压缩
  • 可水平扩展
  • 数据强一致
实现原理
  • 基于RocksDB
  • PacificA一致性协议
    • 类似Zab,Raft基于任期和事务ID
  • Redis固化、分布式解决方案
    在这里插入图片描述

Titan

  • 美图开源
  • 持久化KV存储系统
  • 支持Redis协议
  • 可水平扩展
  • 支持热点数据迁移
  • 基于TiKV
实现原理
  • Redis固化和分布式解决方案
  • 基于TiKV
  • Redis协议代理
    在这里插入图片描述

综合对比分析

  • 协议(支持redis)
  • 持久化
  • 存储模型(底层kv存储)
  • 分布式方案

MySQL到TiDB迁移案例

MySQL使用问题

  • 数据量大,快速水平扩展存储比较难;
  • 大数据量下,快速 DDL可能锁表;
  • 分库分表造成业务逻辑非常复杂;
  • 常规 MySQL 主从故障转移会导致业务访问短暂不可用

TiDB测试数据

在这里插入图片描述

读写均匀的情况下表现不是特别好,读多写少的情况下表现比较稳定。

模拟业务场景测试

  • 选择场景
    • IM联系人列表
  • 测试验证
    • 构造数据
    • 模拟流量
      在这里插入图片描述

读写均匀的情况下测试:
mysql虽然表现还好,但是毛刺比较多。
TiDB虽然耗时稍微多了一点,但是非常平稳。

数据及流量迁移

  • 数据迁移

    • 主从同步(mysql同步到TiDB,主从建立好后就可以认为两边数据追齐了)在这里插入图片描述

    • 双写(断掉主从同步,写mysql数据库的时候发个MQ事务消息,消费端消费消息并写入TiDB)在这里插入图片描述

  • 流量迁移

    • 切读(灰度切流,切一部分的流量,最终把读流量全部切换到TiDB在这里插入图片描述在这里插入图片描述

    • 停双写(用比较新的技术的话要特别关注,双写这个动作可以保留个半年再去停)在这里插入图片描述

迁移时遇到的问题

锁冲突问题

业务场景——手机通知栏推送

  • 用户 — 设备ID 映射
  • 数据变更场景
    • 1账号登陆多手机(U1之前用的是P1,之后换成了P3这个设备)在这里插入图片描述在这里插入图片描述
    • 1手机登陆多账号(U2使用P3,需要修改绑定关系并删除原来U2这条记录)在这里插入图片描述在这里插入图片描述
      部分山寨机的Token不是标准的Token,取不到Token时前端会给一个Default默认值,那此时出现1手机登陆多账号时就会出现一直更新default对应U3的这条记录,导致出现大量锁冲突。
      在这里插入图片描述
      在这里插入图片描述
      解决方案:优化业务,过滤默认值的数据
乐观锁的问题

商品状态流转

  • 发布者想下架商品 状态:0-1
  • 买家拍下商品 状态:0-2
    在这里插入图片描述
MySQL处理方式

在这里插入图片描述

TiDB处理方式

TiDB使用乐观锁模型,导致T2 set xxx锁不住,导致中间多了很多MQ或者RPC
在这里插入图片描述
解决方案:使用分布式锁,串行化处理

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/350773.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

Linux DMA-Buf驱动框架

一、DMABUF 框架 dmabuf 是一个驱动间共享buf 的机制&#xff0c;他的简单使用场景如下&#xff1a; 用户从DRM&#xff08;显示驱动&#xff09;申请一个dmabuf&#xff0c;把dmabuf 设置给GPU驱动&#xff0c;并启动GPU将数据输出到dmabuf&#xff0c;GPU输出完成后&#xf…

javaWeb项目-ssm+vue网上租车系统功能介绍

本项目源码&#xff1a;java-基于ssmvue的网上租车系统源码说明文档资料资源-CSDN文库 项目关键技术 开发工具&#xff1a;IDEA 、Eclipse 编程语言: Java 数据库: MySQL5.7 框架&#xff1a;ssm、Springboot 前端&#xff1a;Vue、ElementUI 关键技术&#xff1a;springboot、…

Perl 语言学习进阶

一、如何深入 要深入学习Perl语言的库和框架&#xff0c;可以按照以下步骤进行&#xff1a; 了解Perl的核心模块&#xff1a;Perl有许多核心模块&#xff0c;它们提供了许多常用的功能。了解这些模块的功能和用法是深入学习Perl的第一步。一些常用的核心模块包括&#xff1a;S…

ArcGIS 10.2软件安装包下载及安装教程!

今日资源&#xff1a;ArcGIS 适用系统&#xff1a;WINDOWS 软件介绍&#xff1a; ArcGIS是一款专业的电子地图信息编辑和开发软件&#xff0c;提供一种快速并且使用简单的方式浏览地理信息&#xff0c;无论是2D还是3D的信息。软件内置多种编辑工具&#xff0c;可以轻松的完成…

docker-compose部署FastDFS分布式文件系统

文章目录 一、技术选型二、fastDFS组成部分三、docker-compose文件四、客户端nginx配置五、存储器spring Boot集成参考文献 一、技术选型 还有一个更好的google FS&#xff08;但是他不开源&#xff0c;我也没找到社区版一类的可以不要钱使用的&#xff09;。 最后考虑到我们存…

非对称加密系统解析

目录 1. 概述 2. 非对称加密标准 2.1 RSA 2.2 SM2 2.2.1 SM2私钥 2.2.2 SM2公钥 2.2.3 加密数据格式 2.2.4 签名数据格式 1. 概述 非对称加密中&#xff0c;密钥分为加密密钥和解密密钥两种。发送者用加密密钥对消息进行加密&#xff0c;接收者用解密密钥对密文进行解密…

【redis的基本数据类型】

基本数据类型 Redis的基本数据类型有五种&#xff0c;分别是 StringListHashSetSortedSet 这些基本的数据类型构成了其他数据类型的基石&#xff0c;而这些基本数据类型又对应着不同的底层实现&#xff0c;不同的底层实现往往是针对不同的使用场景做的特殊的优化&#xff0c;…

# RocketMQ 实战:模拟电商网站场景综合案例(六)

RocketMQ 实战&#xff1a;模拟电商网站场景综合案例&#xff08;六&#xff09; 一、RocketMQ 实战 &#xff1a;项目公共类介绍 1、ID 生成器 &#xff1a;IDWorker&#xff1a;Twitter 雪花算法。 在 shop-common 工程模块中&#xff0c;IDWorker.java 是 ID 生成器公共类…

第 18章 安全架构设计理论与实践

安全架构是架构面向安全性方向上的一种细分&#xff0c;可关注三个安全方面&#xff0c;即产品安全架构、安全技术体系架构和审计架构&#xff0c;这三个方面可组成三道安全防线。本章主要分析安全威胁、介绍安全模型&#xff0c;在此基础上&#xff0c;就系统、信息、网络和数…

mysql和redis的双写一致性问题

一&#xff0c;使用方案 在使用redis作为缓存的场景下&#xff0c;我们一般使用流程如下 二&#xff0c;更新数据场景 我们此时修改个某条数据&#xff0c;如何保证mysql数据库和redis缓存中的数据一致呢&#xff1f; 按照常规思路有四种办法&#xff0c;1.先更新mysql数据&a…

tcp协议机制的总结(可靠性,提高性能),基于tcp的应用层协议,用udp如何实现可靠传输

目录 总结 引入 可靠性 ​编辑 分析 三次握手 提高性能 其他 常见的基于tcp应用层协议 用udp实现可靠传输 总结 引入 为什么tcp要比udp复杂的多? 因为它既要保证可靠性,又要兼顾性能 可靠性 分析 其中,序列号不止用来排序,还可以用在重传时去重 确认应答是机制中的…

嵌入式软件工程师入何突破瓶颈?

各位关注嵌入式软件工程师发展的朋友们&#xff0c;下面来探讨一下嵌入式软件工程师该如何突破瓶颈。首先要强调的是&#xff0c;不要仅仅将自己局限在嵌入式软件工程师这一角色定位上。 事实上&#xff0c;嵌入式软件工程师已经掌握了诸多业务层面的内容&#xff0c;完全有能力…

硬件SPI读写W25Q64

硬件SPI读写W25Q64 接线图&#xff08;和软件SPI一样&#xff09; 使用SPI1&#xff0c;SCK&#xff0c;接PA5&#xff1b;MISO&#xff0c;接PA6&#xff1b;MOSI&#xff0c;接PA7&#xff1b;NSS&#xff0c;可接PA4。 接线图对应&#xff1a;PA5接CLK引脚&#xff0c;PA6…

34 Debian如何配置ELK群集

作者:网络傅老师 特别提示:未经作者允许,不得转载任何内容。违者必究! Debian如何配置ELK群集 《傅老师Debian知识库系列之34》——原创 ==前言== 傅老师Debian知识库特点: 1、拆解Debian实用技能; 2、所有操作在VMware虚拟机实测完成; 3、致力于最终形成Debian知识手…

ChatGPT魔法背后的原理:如何做到词语接龙式输出?

介绍 我们都知道 ChatGPT 是 AIGC 工具&#xff0c;其实就是生成式人工智能。大家有没有想过这些问题 &#x1f914;️&#xff1a; 1、我们输入一段话&#xff0c;就可以看见它*噼里啪啦的一顿输出*&#xff0c;那么它的原理到底是什么&#xff1f; 2、到底它是怎么锁定这些…

GitLab教程(二):快速上手Git

文章目录 1.将远端代码克隆到本地2.修改本地代码并提交到远程仓库3.Git命令总结git clonegit statusgit addgit commitgit pushgit log 首先&#xff0c;我在Gitlab上创建了一个远程仓库&#xff0c;用于演示使用Gitlab进行版本管理的完整流程&#xff1a; 1.将远端代码克隆到本…

宝藏速成秘籍(7)堆排序法

一、前言 1.1、概念 堆排序&#xff08;Heapsort&#xff09;是指利用堆这种数据结构所设计的一种排序算法 。堆是一个近似 完全二叉树 的结构&#xff0c;并同时满足堆积的性质&#xff1a;即子结点的键值或索引总是小于&#xff08;或者大于&#xff09;它的父节点。 1.2、排…

重生之 SpringBoot3 入门保姆级学习(19、场景整合 CentOS7 Docker 的安装)

重生之 SpringBoot3 入门保姆级学习&#xff08;19、场景整合 CentOS7 Docker 的安装&#xff09; 6、场景整合6.1 Docker 6、场景整合 6.1 Docker 官网 https://docs.docker.com/查看自己的 CentOS配置 cat /etc/os-releaseStep 1: 安装必要的一些系统工具 sudo yum insta…

React state(及组件) 的保留与重置

当在树中相同的位置渲染相同的组件时&#xff0c;React 会一直保留着组件的 state return (<div><Counter />{showB && <Counter />} </div> ) // 当 showB 为 false, 第二个计数器停止渲染&#xff0c;它的 state 完全消失了。这是因为 React…