漫谈分布式数据复制和一致性!

简介: 漫谈分布式数据复制和一致性!

引子

在分布式系统中,出于多个原因,我们会希望将数据库分布到多台机器上:

  • 可伸缩性:如果数据量、读取负载、写入负载超出单机的处理能力,可以将负载分散到多台计算机上
  • 容错/高可用性:在单台机器故障的时候提供冗余,一台故障时,另一台可以接管
  • 延迟:如果你的用户分布在全国乃至全球范围,可以在多个地点部署服务器,以保证用户可以从最近的数据中心获取服务

共享内存架构:更高端的机器(垂直伸缩),成本增长快于线性增长、容错能力有限

共享磁盘架构:多个独立的处理器和内存,数据存储在共享的磁盘阵列,这些磁盘通过快速网络连接,但竞争和锁定的开销限制了共享磁盘方法的可伸缩性

无共享架构:每个节点只使用各自的处理器、内存和磁盘,也是最普遍的方式

复制:主从同步

复制意味着在通过网络连接的多台机器上保留相同数据的副本。

常见的复制算法分:单领导者、多领导者、无领导者

图:基于领导者的主从复制

同步复制和异步复制

同步复制的优缺点:更强的一致性保证;从库故障,主库无法处理写入操作,因此将所有从库都设置为同步的是不切实际的 ==> 半同步、链式复制

异步复制:不受从库状态影响,但写入不能完全保证持久性

从库宕机:追赶恢复

主库宕机:故障切换(手动或自动),思考:当老主库重新加入集群,未复制的写入怎么办?

复制延迟问题

读己之写(read-your-writes consistency)

  • 个别场景读取走主库(例如,若档案只能由用户自己编辑,对于用户自己的读取访问可以走主库)
  • 监控从库的复制延迟
  • 记录客户端上一次写入的时间戳或者序列号(跨设备问题)
单调读

确保每个用户总是从同一个副本进行读取

一致前缀读

写入按照某个顺序发生,读取也要按同样的顺序出现(多分区时会有这个问题,因为不存在全局写入顺序)==> 有因果关系的写入相同的分区

缓解复制延迟问题的相关实践参考

freno

github.blog/2017-10-13-…

分片(Sharding)

也称为分区(partitions),对于非常大的数据集或非常高的吞吐量,仅仅复制是不够的。

分区的方式

  • 按键的范围(不均衡问题)
  • 按键的散列(失去高效执行范围查询的能力 => 组合索引思路)
  • 热点消除(分割热点键)

关系型数据库的分库分表

分片方式
拆分方式 解释
垂直分库 按微服务分库
垂直分表 冷字段大字段拆分,减少单条记录大小
水平分表 单表记录量变少
水平分库 进一步将单表数据分布到多个实例,突破单实例限制,会引入分布式事务问题
分片下的执行流程

常见的分片与路由策略

Sharding JDBC 分片策略参考

Sharding JDBC 路由方式参考

分片策略 相关算法 解释 备注
标准分片 (StandardShardingStrategy) PreciseShardingAlgorithm 如果选择这种策略,PreciseShardingAlgorithm 必选 适用于 = ,in
RangeShardingAlgorithm between,< , >
复合分片 (ComplexShardingStrategy) 直接将分片键值组合以及分片操作符透传至分片算法,完全由应用开发者实现
行表达式分片 (InlineShardingStrategy) t_user_$->{u_id % 8} 表示t_user表根据u_id模8,而分成8张表,表名称为t_user_0t_user_7 推荐,且为默认的策略
Hint 分片 (HintShardingStrategy) 通过Hint指定分片值而非从SQL中提取分片值的方式进行分片的策略 对应强制路由
分布式主键生成方式
  • 指定设置起始值和步长(引入额外的运维规则,使解决方案缺乏完整性和可扩展性)
  • SnowFlake
  • 美团 Leaf
  • 百度 UidGenerator
实践资料

Sharding JDBC 分库分表配置参考

常见注意事项
  • 查询语句尽量使用分片键,避免广播路由
  • 不支持 INSERT ON DUPLICATE KEY UPDATE (sharding-jdbc 的限制)
  • 不支持 REPLACE INTO
  • 4.x不支持子查询,支持的版本子查询和外部也都必须指定一定的分片键
  • 慎用分页,不要在全分片扫描的时候使用非常大的offset,可能导致OOM (limit offset, count会被改写为limit 0, offset+count,该条查询语句会到每个分表中都捞取offset+count 这么多条数据,然后全部存到内存里,数据条数是分表数*(offset+count),有可能会导致OOM的情况发生)
  • 单库单表转分库分表简化 roadMap

分区带来的问题

《高性能MySQL》:如非必要,尽量不分片

  • 架构复杂性的提升
  • 分区不平衡问题(resharding)
  • 分布式事务问题
  • 决定分片前的考虑:索引、缓存、读写分离是否已足够、冷数据归档...

文章内容收录到个人网站,方便阅读hardyfish.top/

参考文献

相关文章
|
4月前
|
存储 缓存 NoSQL
Redis常见面试题(二):redis分布式锁、redisson、主从一致性、Redlock红锁;Redis集群、主从复制,哨兵模式,分片集群;Redis为什么这么快,I/O多路复用模型
redis分布式锁、redisson、可重入、主从一致性、WatchDog、Redlock红锁、zookeeper;Redis集群、主从复制,全量同步、增量同步;哨兵,分片集群,Redis为什么这么快,I/O多路复用模型——用户空间和内核空间、阻塞IO、非阻塞IO、IO多路复用,Redis网络模型
Redis常见面试题(二):redis分布式锁、redisson、主从一致性、Redlock红锁;Redis集群、主从复制,哨兵模式,分片集群;Redis为什么这么快,I/O多路复用模型
|
30天前
|
消息中间件 缓存 算法
分布式系列第一弹:分布式一致性!
分布式系列第一弹:分布式一致性!
|
3月前
|
存储 算法 NoSQL
(七)漫谈分布式之一致性算法下篇:一文从根上儿理解大名鼎鼎的Raft共识算法!
Raft通过一致性检查,能在一定程度上保证集群的一致性,但无法保证所有情况下的一致性,毕竟分布式系统各种故障层出不穷,如何在有可能发生各类故障的分布式系统保证集群一致性,这才是Raft等一致性算法要真正解决的问题。
108 11
|
3月前
|
存储 算法 索引
(六)漫谈分布式之一致性算法上篇:用二十六张图一探Raft共识算法奥妙之处!
现如今,大多数分布式存储系统都投向了Raft算法的怀抱,而本文就来聊聊大名鼎鼎的Raft算法/协议!
111 8
|
3月前
|
存储 算法 Java
(五)漫谈分布式之一致性算法篇:谁说Paxos晦涩难懂?你瞧这不一学就会!
没在时代发展的洪流中泯然于众的道理很简单,是因为它们并不仅是空中楼阁般的高大上理论,而是有着完整落地的思想,它们已然成为构建分布式系统不可或缺的底层基石,而本文则来好好聊聊分布式与一致性思想的落地者:Paxos与Raft协议(算法)。
|
3月前
|
存储 NoSQL MongoDB
(四)成为分布式高手必经之路:理解那些工作在分布式系统底层的一致性模型
在分布式领域里,一致性成为了炙手可热的名词,缓存、数据库、消息中间件、文件系统、业务系统……,各类分布式场景中都有它的身影,因此,想要更好的理解分布式系统,必须要理解“一致性”这个概念。本文就展开聊聊 分布式系统里的一致性模型。
|
3月前
|
Oracle 关系型数据库
分布式锁设计问题之Oracle RAC保证多个节点写入内存Page的一致性如何解决
分布式锁设计问题之Oracle RAC保证多个节点写入内存Page的一致性如何解决
|
3月前
|
消息中间件 存储 监控
消息队列在分布式系统中如何保证数据的一致性和顺序?
消息队列在分布式系统中如何保证数据的一致性和顺序?
|
3月前
|
消息中间件 存储 C#
分布式事务之最终一致性实现方案
分布式事务之最终一致性实现方案
76 0
|
4月前
|
消息中间件
分布式篇问题之通过本地消息表实现分布式事务的最终一致性问题如何解决
分布式篇问题之通过本地消息表实现分布式事务的最终一致性问题如何解决
175 0

热门文章

最新文章