标签:分表 name 模块 系统 分区 数据库架构 触发器 协议 并行复制
数据库架构设计 - 高可用,度性能,一致性,扩展性 - 数据冗余带来一致性问题
单库->分片(路由,范围,哈希,路由服务)->分片+分组
冗余读库,写库单点
冗余写库-双写可能冲突,两个写库不同的初始值相同的补偿来避免,业务层自己生成唯一ID避免冲突
双主当主从用,两个主只有一个主提供服务(读+写),两一个座位影子服务保证高可用
提升度性能,写库不建立索引,线上读库建立uid索引,线下读库简历time索引,增加读库,增加缓存
业务部直接面向db和cache,服务层屏蔽了底层负责性,不管如何,一致性都是问题
解决一致性问题,1. 中间件,某一个Key有写操作,在不一致窗口内,中间件会将这个key的读操作也路由到主库上 2. 强制读主
如果写操作:淘汰cache,写库;读操作室读cache,读库,放回cache,则可能从库读到旧数据如cache导致不一致
解决
缓存双淘汰,淘汰cache,写数据库,在主从同步延迟窗口时间后,再次发起一个异步淘汰cache的请求
更简单就是cache设超时,这个没啥好说的吧
=======================================================================================
冗余表数据一致性
因为数据库水平切分,不是分区键的查询可能扫描多库,为提升性能,所以需要冗余
Order(oid, info_detail)
T(buyer_id, seller_id, oid)
如果用buyer_id来分库,seller_id的查询就需要扫描多库。
如果用seller_id来分库,buyer_id的查询就需要扫描多库。
T1(buyer_id, seller_id, oid)
T2(seller_id, buyer_id, oid)
同一个数据,冗余两份,一份以buyer_id来分库,满足买家的查询需求;
一份以seller_id来分库,满足卖家的查询需求。
服务层同步写冗余数据
服务层异步写,数据的双写并不再由服务来完成,服务器异步发出一个消息,通过消息总线发给一个专门的数据复制服务来写入冗余数据
线下异步写,数据的双写不再由服务层来完成,而是由线下的另一个服务或者任务来完成,比如通过binlog,最终一致性
根据业务影响的大小,谁小谁先执行
用户下单时,如果“先插入buyer表T1,再插入seller冗余表T2”,当第一步成功、第二步失败时,出现的业务影响是“买家能看到自己的订单,卖家看不到推送的订单”
相反,如果“先插入seller表T2,再插入buyer冗余表T1”,当第一步成功、第二步失败时,出现的业务影响是“卖家能看到推送的订单,卖家看不到自己的订单”
由于这个生成订单的动作是买家发起的,买家如果看不到订单,会觉得非常奇怪,并且无法支付以推动订单状态的流转,此时即使卖家看到有人下单也是没有意义的。
因此,在此例中,应该先插入buyer表T1,再插入seller表T2。
如何保证数据的一致性?
线下启动一个离线扫描工具,不停的对比正表和反表,发现数据不一致,就进行补偿修复
线下扫描增量数据,减小不一致时间窗口
实时线上消息对检测,写入T1发msg1,写入T2发msg2,这时实时订阅服务不停的收消息,假设在一小段时间内没有收到正确的消息对,则发现不一致,进行补偿
=======================================================================================
缓存架构设计
读多写少加缓存优化性能,减少db查询。读取(读取缓存,命中返回,没命中查db再写入缓存)
所以当数据出现变化的时,就会出现不一致的问题,先更新缓存还是淘汰,先操作数据库还是先操作缓存等等问题
更新缓存:数据不但写入数据库,还会写入缓存。缓存不会增加一次未命中,命中率高
淘汰缓存,数据只写入数据库,不写入缓存,会将缓存数据淘汰 - 优选
如果更新缓存的代价很小,则更新缓存,如果代价大则淘汰缓存。因为有的缓存是计算出来的,而不仅仅是更新一个简单的值
当写操作发生时,先写库再淘汰缓存,还是先淘汰缓存,再写库? 如果出现不一致,谁先做对业务影响小谁先执行
结论,先淘汰缓存,再写数据库
缓存架构优化(业务同时关注db和缓存,加入服务层屏蔽数据库和缓存的细节,非主流方案是异步缓存更新,业务线所有的写操作走db,读操作走缓存,由一个异步工具(binlog读取同步)做数据之间的数据同步)
=======================================================================================
缓存与数据库的一致性
先操作缓存,在写库之前,如果读请求发生,可能导致旧数据入缓存,引发数据不一致
如何能做到先发的请求一定先执行? 串行化思路,任务队列其实已经做了任务串行化的工作,多节点部署,多请求队列,多数据库连接
任务队列不能保证串行化,单任务多数据库连接不能保证串行化,多服务单数据库连接不能保证串行化,单服务单数据库连接可能保证串行化,但吞吐量极低,不可行
***结论,不需要全局串行化,只需要让同一个数据的访问能串行化就行,让同一个数据的访问通过同一条db连接执行(连接池选特定的)***
怎么解决全局问题?对服务连接池也改下,加入特定参数
=======================================================================================
主从DB与Cache一致性
单库,服务层的并发读写,缓存与db交差进行,A写操作,淘汰缓存-停,B读操作,缓存未命中,读db加入缓存,A继续写库,后发起的请求B再先发起的请求A中间完成了,可能读到旧数据入缓存
主从同步,读写分离的情况下,同步延迟,读从库读到旧数据
解决,用一个异步的timer或者消息总线异步,写请求发个消息,消费者收到消息之后,异步在1S后淘汰缓存,即使在1S内有脏数据入缓存也会被再次淘汰
还可以无侵入业务系统,新增一个线下读Binlog的异步淘汰模块,读取binlog中的数据,异步淘汰缓存
=======================================================================================
DB主从一致性架构优化
读多写少,一主多从,读写分离,冗余多个读库,写入完成后,主从同步有一个时间差
解决方案: 半同步复制,写请求在主从同步完成之后才返回成功;强制读主库;
数据库中间件,通常情况下,写请求路由到主库,读请求路由到从库,记录所有路由到写库的Key,在经验时间窗内,如果有读请求访问中间件,将请求路由到主库
由于中间件方案成本较高,可以在cache里
=======================================================================================
多库多事物
一般 start transaction do 1 2 3 4 5 commit; 但互联网数据量大高并发,所以每个操作可能在不同的库不同的实例上,无法保证数据一致性
补偿事物:在业务端实施业务逆向操作事物,来保证数据的一致性
事物拆分分析与后置提交优化:想到两阶段提交,先预留资源,协商,最后提交,减少不一致的可能性,原理都是非常类似的
trx1.exec();
trx1.commit();
trx2.exec();
trx2.commit();
优化为:
trx1.exec();
trx2.exec();
trx1.commit();
trx2.commit();
这个小小的改动(改动成本极低),不能彻底解决多库分布式事务数据一致性问题,但能大大降低数据不一致的概率,带来的副作用是数据库连接占用时间会增长,吞吐量会降低。对于一致性与吞吐量的折衷,还需要业务架构师谨慎权衡折衷。
=======================================================================================
Mysql并行复制: ( 主从复制 -> 从库使用单线程重放relaylog)
想要多线程并行,但。。。如何分割relaylog才能让并行操作可以保证一致性
1. 相同库上的写操作,使用相同的线程来重复日志,不同库上的写操作可以用多个线程并发重放日志; 如果是单库单表就没戏了- 作者非常支持多库方式构建db架构,可以降低主从同步的延迟
2. 单库情况下,数据的修改和事物的执行在主库也是并行操作的,利用这个,可以将主库上同事并行执行的事物分组,回放时并行执行
3. 新版Mysql将组提交信息存放在GTID中,使用mysqlbinlog工具可以看到组提交内部信息;具有相同的last_committed说明他们在一个组,可以并发回放执行
作者给出了版本对比
mysql5.5 -> 不支持并行复制,对大伙的启示:升级mysql吧
mysql5.6 -> 按照库并行复制,对大伙的启示:使用“多库”架构吧
mysql5.7 -> 按照GTID并行复制
=======================================================================================
Mysql分区表 VS 分库分表
文章看下来就是分区表灵活度不如分库分表,运用不到分区键会很惨,不如分库分表灵活
=======================================================================================
快速回复删掉的数据库
一般数据库架构: 主从结构、主主结构;
全量备份,增量备份: 打包,scp等; 发生问题逐层找回
延迟从库,每隔1小时同步一次主库,同步完之后立即断开
双份1小时延迟从库
可以在从库进行一些允许延时的业务,从而让资源得到充分利用
=======================================================================================
表格属性增加技巧
增加列的问题, alter table add 列锁表时间太长;新表加触发器耗性能不一定装得下,而且可能经常扩展变更
方案
触发器方案
(1)先创建一个扩充字段后的新表user_new(uid, name, passwd, age, sex)
(2)在原表user上创建三个触发器,对原表user进行的所有insert/delete/update操作,都会对新表user_new进行相同的操作
(3)分批将原表user中的数据insert到新表user_new,直至数据迁移完成
(4)删掉触发器,把原表移走(默认是drop掉)
(5)把新表user_new重命名(rename)成原表user
版本号+通用列; 动态扩展,新旧同事存在,但无法建立索引,ext中key冗余
user(uid, name, version, ext)
(1)uid和name有查询需求,必须设计为单独的列并建立索引
(2)version是版本号字段,它对ext进行了版本解释
(3)ext采用可扩展的字符串协议载体,承载被查询的属性
扩展行;也可以动态扩展,新旧同时存在,迁移方便,各个属性都能查;一条记录会变很多行,行数会增加很多
user(uid, key, value)
很早以前有个公司还真用的就是这种;
=======================================================================================
数据库垂直拆分、水平拆分 - 降低数据库大小,提升性能
垂直拆分:将一个属性较多,一行数据较大的表,将属性拆分到不同的表中,以降低单库的大小; - 结构不一样,属性有主键交集
垂直切分的依据:长度较短、访问频率较高的属性放在主表,长度长访问频率低的表放在扩展表,经常一起访问的属性放在一个起
因为row buffer,小而访问频率高的容易加载到Buffer,缓存更多数据,提高命中率
高并发需要主表和扩展表数据,通过服务层访问,不建议join,会消耗过多性能增加复杂度。建议两次查询
水平拆分:以某字段按规则将一个库表上的数据拆分到多个库表上,降低单库表大小 - 结构一样数据不一样
切分规则关系到负载、扩容等因素,切分后按照切分键查询Ok,但如果不按照切分键就麻烦了
针对用户侧的非uid需求,采用建立非Uid属性到uid属性的映射关系架构 - 建立一个索引表记录从查询属性到uid的映射 -> 将映射关系放入缓存 ->可否直接计算映射
计算优化 - 感觉这个还挺有意思的,记录下来
假设分8库,采用uid%8路由,潜台词是,uid的最后3个bit决定这条数据落在哪个库上,这3个bit就是所谓的“基因”。
解决方案:
?在用户注册时,设计函数login_name生成3bit基因,login_name_gene=f(login_name),如上图粉色部分
?同时,生成61bit的全局唯一id,作为用户的标识,如上图绿色部分
?接着把3bit的login_name_gene也作为uid的一部分,如上图屎黄色部分
?生成64bit的uid,由id和login_name_gene拼装而成,并按照uid分库插入数据
?用login_name来访问时,先通过函数由login_name再次复原3bit基因,login_name_gene=f(login_name),通过login_name_gene%8直接定位到库
针对运营侧,采用前台与后台分离的架构设计方案,容忍延迟的批量处理任务,可以参考下图,通过MQ或线下异步同步数据处理
=======================================================================================
平滑扩容
双主同步,keepalived,虚拟IP
=======================================================================================
跨库分页,跨多个水平切分数据库,且分库依据与排序依据为不同属性,并需要进行分页查询
单库比如 select * from t_msg order by time offset 200 limit 100
分库时,取3页数据,每个都取3页,再在内存中排序,这种增加了网络传输消耗,服务层二次排序消耗CPU,随着页码增大性能几句下降
从业务上规避,禁止跳页查询,就像我们刷网页,拉下来一点刷出来一点;
这种方式将查询order by time offset 100 limit 100,改写成order by time where time>$time_max limit 100,以后每次查询可以利用前次的时间作为条件,减少后面每次查询的网络传输量
如果业务上可以接受损失精度,可以一些统计类属性可以假定每个库差不多,所以统计db0间接可以假定db1.。。也差不多
二次查询法:???还是没理解透
将select * from T order by time offset 1000 limit 5
改写为select * from T order by time offset 500 limit 5
并投递给所有的分库,注意,这个offset的500,来自于全局offset的总偏移量1000,除以水平切分数据库个数2。
找到返回数据的最小值,二次查询
(1)将order by time offset X limit Y,改写成order by time offset X/N limit Y
(2)找到最小值time_min
(3)between二次查询,order by time between $time_min and $time_i_max
(4)设置虚拟time_min,找到time_min在各个分库的offset,从而得到time_min在全局的offset
(5)得到了time_min在全局的offset,自然得到了全局的offset X limit Y
标签:分表 name 模块 系统 分区 数据库架构 触发器 协议 并行复制
原文地址:https://www.cnblogs.com/it-worker365/p/10008828.html