宜飞思工业设计网站,东莞网络问政平台,外国出名的设计网站,安阳网站优化文章目录 1.读写分离2.分库分表3.动静分离4.冷热分离5.重写轻读6.数据异构参考文献 任何一个系统#xff0c;从单机到分布式#xff0c;从前端到后台#xff0c;功能和逻辑各不相同#xff0c;但干的只有两件事#xff1a;读和写。而每个系统的业务特性可能都不一样#… 文章目录 1.读写分离2.分库分表3.动静分离4.冷热分离5.重写轻读6.数据异构参考文献 任何一个系统从单机到分布式从前端到后台功能和逻辑各不相同但干的只有两件事读和写。而每个系统的业务特性可能都不一样有的侧重读、有的侧重写有的两者兼备本节主要探讨在不同业务场景下存储读写的一些方法论。 1.读写分离
大多数业务都是读多写少为了提高系统处理能力可以采用读写分离的方式将主节点用于写从节点用于读如下图所示。 读写分离架构有以下几个特点 1数据库服务为主从架构 2主节点负责写操作从节点负责读操作 3主节点将数据复制到从节点
基于读写分离思想可以设计出多种主从架构如主-主-从、主-从-从等。主从节点也可以是不同的存储如MySQLRedis。
读写分离的主从架构一般采用异步复制会存在数据复制延迟的问题适用于对数据一致性要求不高的业务。可采用以下几个方式尽量避免复制滞后带来的问题。
写后读一致
即读自己的写适用于用户写操作后要求实时看到更新。典型的场景是用户注册账号或者修改账户密码后紧接着登录此时如果读请求发送到从节点由于数据可能还没同步完成用户登录失败这是不可接受的。针对这种情况可以将自己的读请求发送到主节点上查看其他用户信息的请求依然发送到从节点。
二次读取
优先读取从节点如果读取失败或者跟踪的更新时间小于某个阀值则再从主节点读取。
区分场景
关键业务读写主节点非关键业务读写分离。
单调读
保证用户的读请求都发到同一个从节点避免出现回滚的现象。如用户在 M 主节点更新信息后数据很快同步到了从节点 S1用户查询时请求发往 S1看到了更新的信息。接着用户再一次查询此时请求发到数据同步没有完成的从节点 S2用户看到的现象是刚才的更新的信息又消失了即以为数据回滚了。
2.分库分表
读写分离虽然可以明显的提示查询的效率但是无法解决更高的并发写入请求的场景这时候就需要进行分库分表提高并发写入的能力。
通常在以下情况下需要进行分库分表
1单表的数据量达到了一定的量级如 MySQL 一般为千万级读写的性能会下降。这时索引也会很大性能不佳需要分解单表。
2数据库吞吐量达到瓶颈需要增加更多数据库实例来分担数据读写压力。
分库分表按照特定的条件将数据分散到多个数据库和表中分为垂直切分和水平切分两种模式。
垂直切分
按照一定规则如业务或模块类型将一个数据库中的多个表分布到不同的数据库上。以电商平台为例将商品数据、订单数据、用户数据分别存储在不同的数据库上如下图所示 优点 1切分规则清晰业务划分明确 2可以按照业务的类型、重要程度进行成本管理扩展也方便 3数据维护简单。
缺点 1不同表分到了不同的库中无法使用表连接Join。不过在实际的业务设计中也基本不会用到 Join 操作一般都会建立映射表通过两次查询或者写时构造好数据存到性能更高的存储系统中。 2事务处理复杂原本在事务中操作同一个库的不同表不再支持。这时可以采用柔性事务或者其他分布式事物方案。
水平切分
按照一定规则如哈希或取模将同一个表中的数据拆分到多个数据库上。可以简单理解为按行拆分拆分后的表结构是一样的。如用户信息记录日积月累表会越来越大可以按照用户 ID 或者用户注册日期进行水平切分存储到不同的数据库实例中。
优点 1切分后表结构一样业务代码不需要改动 2能控制单表数据量有利于性能提升。
缺点 1Join、count、记录合并、排序、分页等问题需要跨节点处理 2相对复杂需要实现路由策略
综上所述垂直切分和水平切分各有优缺点通常情况下这两种模式会一起使用。
3.动静分离
动静分离将经常更新的数据和更新频率低的数据进行分离。最常见于 CDN一个网页通常分为静态资源图片/JS/CSS等和动态资源JSP、PHP等采取动静分离的方式将静态资源缓存在 CDN 边缘节点上只需请求动态资源即可减少网络传输和服务负载。
在数据库和 KV 存储上也可以采取动态分离的方式。动静分离更像是一种垂直切分将动态和静态的字段分别存储在不同的库表中减小数据库锁的粒度同时可以分配不同的数据库资源来合理提升利用率。
4.冷热分离
冷热分离可以说是每个存储产品和海量业务的必备功能MySQL、ElasticSearch 等都直接或间接支持冷热分离。将热数据放到性能更好的存储设备上冷数据下沉到廉价的磁盘从而节约成本。
5.重写轻读
基本思路就是写入数据时多写点冗余写降低读的压力。
社交平台中用户可以互相关注查看关注用户的最新消息形成 Feed 流。
用户查看 Feed 流时系统需要查出此用户关注了哪些用户再查询这些用户所发的消息按时间排序。
为了满足高并发的查询请求可以采用重写轻读提前为每个用户准备一个收件箱。
每个用户都有一个收件箱和一个发件箱。比如一个用户有1000个粉丝他发布一条消息时写入自己的发件箱即可后台异步的把这条消息放到那1000个粉丝的收件箱中。
这样用户读取 Feed 流时就不需要实时查询聚合了直接读自己的收件箱就行了。把计算逻辑从”读”移到了”写”一端因为读的压力要远远大于写的压力所以可以让”写”帮忙干点活儿提升整体效率。
上面展示了一个重写轻度的一个例子在实际应用中可能会遇到一些问题。如
1写扩散这是个写扩散的行为如果一个大 V 的粉丝很多这写扩散的代价也是很大的而且可能有些人万年不看朋友圈甚至屏蔽了朋友。需要采取一些其他的策略如粉丝数在某个范围内是才采取这种方式数量太多采取推拉结合和分析一些活跃指标等。
2信箱容量一般来说查看 Feed 流如微信朋友圈不会不断地往下翻页查看这时候应该限制信箱存储条目数超出的条目从其他存储查询。
6.数据异构
数据异构顾名思义就是存储不同结构的数据有很多种含义
数据格式的异构
数据的存储格式不同可以是关系型如 MySQL、SQL Server、DB2等也可以是 KV 格式如 Redis、Memcache等还可以是文件行二维数据如 txt、CSV、XLS等。
数据存储地点的异构
据存储在分散的物理位置上此类情况大多出现在大型机构中如销售数据分别存储在北京、上海、日本、韩国等多个分支机构的本地销售系统中。
数据存储逻辑的异构
相同的数据按照不同的逻辑来存储比如按照不同索引维度来存储同一份数据。
这里主要说的是按照不同的维度建立索引关系以加速查询。如京东、天猫等网上商城一般按照订单号进行了分库分表。由于订单号不在同一个表中要查询一个买家或者商家的订单列表就需要查询所有分库然后进行数据聚合。可以采取构建异构索引在生成订单的时同时创建买家和商家到订单的索引表这个表可以按照用户 ID 进行分库分表。 参考文献
一文搞懂后台高性能服务器设计的常见套路, BAT 高频面试系列
