数据同步系统设计
数据同步系统设计
摘要:在大型分布式应用中,经常需要对数据进行跨库或跨网络进行同步,出于资金或数据安全的方面考虑,不能过多依赖硬件或数据库进行同步,因此需要一种安全和高性能的数据同步解决方案,本文讨论了在不依赖数据库的基础上,实现数据同步的功能,并在性能和可扩展性上进行了优化。在分布式领域有个CAP理论,是说Consistency(一致性), Availability(可用性), Partition tolerance(分区和容错) 三部分在系统实现只可同时满足二点,无法三者兼顾。
关键词:数据同步 分布式应用 CAP理论
一、应用场景
在大型分布式应用中,我们经常碰到在多数据库之间的数据同步问题,比如说一款游戏,在玩家注册后,可以马上登陆进入服务器,即数据在一个IDC更新,其它IDC立即可见。为了简化思路,我们这里称玩家注册的数据库(数据来源库)为中心库,同步目的地的数据库为分站库。
能做的
数据快速搬运到指定的IDC节点
数据传递过程中失败时,重新传递
监控数据传递流程
故障转移
数据版本控制
不能做的
不参与业务行为,业务操作只能通过注册的方式集成
不保存业务数据,不提供传递的业务的查询
二、系统要求
1.数据快速同步:除去网络原因,正常情况下从来源库同步到接收库的时间不超过300m
甘肃天水疫情最新数据消息
2.高并发:单应用每秒同步2000条记录
3.可伸缩性,在资源达到上限时能通过增加应用分散处理后期增长的压力
4.数据完整性要求,在数据同步过程中保证数据不丢失和数据安全
5.故障转移和数据恢复功能
三、设计思路
系统优化,最常用的就是进行业务切割,将总任务切割为许多子任务,分区块分析系统中可能存在的性能瓶颈并有针对性地进行优化,在本系统中,主要业务包含以下内容:
1.Syncer:外部接口,接收同步数据请求,初始化同步系统的一些必要数据
2.Delivery:将同步数据按照业务或优先级进行分发,并记录分发结果
3.Batch:分站库收到同步数据后,根据不同的业务类型调用相应的业务逻辑处理数据
基于以上三块业务功能,我们可以把整个数据同步流程切割为3个应用,具体如下图显示。
在Syncer端应用中,我们需要将原始同步数据和分发的分站进行存储,以备失败恢复,此时如果采用数据库进行存储,势必会受限于数据库性能影响,因此我们采用了高效的key-value风格存储的redis服务来记录数据,同时在不同应用之间采用队列(Httpsqs服务)的方式来进行通讯,同时也保证的数据通讯的顺序性,为之后的顺序同步做好基础。
Httpsqs提供了http风格的数据操作模式,业务编码非常简单,同时也提供了web形式的队列处理情况查询,这是选择它做队列服务很大一部分原因:方便业务操作和性能监控。
队列处理
根据业务划分队列名称,每个队列再划分为三个关联队列:正常队列(Normal)、重试队列(Retry)、死亡队列(Death),处理流程为:动漫 推荐
1.【进程A】把数据先放入正常队列,如果放置失败写恢复日志
2.【进程B】监听正常队列,获取队列数据并进行业务处理,处理失败放入重试队列
3.【进程C】监听重试队列,过几秒获取队列数据并重新进行业务处理,处理失败放入死亡队列
4.【进程D】监听死亡队列,获取队列数据并重新进行业务处理,处理失败重新放入死亡队列尾部,等待下一次轮回
数据同步流程
1.发送数据,支持Http POST:curl -d “经过URL编码的文本消息”
2.sync-syncer接收到同步数据请求,创建sid并分解出需要同步的节点个数,把原始数据和子任务写入redis中,sid写入httpsqs中
玉与翡翠的区别 3.sync-delivery监听中心httpsqs队列,根据sid从redis获取到原始数据和需要同步的节点地址,往其他节点发送数据,流程如按”队列处理流程”进行
4.sync-batch监听分节点的httpsqs队列,调用已经注册的处理器处理队列数据,流程如按”队列处理流程”进行
四、恢复和监控
恢复数据源
httpsqs中的死亡队列 - 业务处理暂时处理不了的数据
recovery日志文件 - 其它异常下的数据,例如网络无法连接、内部服务不可用
数据恢复
独立的应用来处理正常流程中没有完成的任务,主要功能有:
监听死亡队列,进行业务重做,再次执行失败时将执行次数+1,最大执行次数为5(默认),超出上限则记录到恢复日志中
读取恢复日志,重新放入死亡队列
应用监控
使用scribe日志框架服务业务日志的采集和监控
收集重要的业务操作日志
动态的开启/关闭某类业务日志
对redis进行监控
对httpsps,监控队列个数,每个队列的状态
护士长年终工作总结 五、数据结构
sid(sync id) - 全局id
v(version) - 版本号
data - 业务数据软卧和硬卧有什么区别
ctime(create time) - 创建时间(毫秒)
exec - 可选,执行次数
湖南城市学院专业 六、编码及测试结果
经过编码和测试,在内网环境下,在无数据库限制的情况下,单应用可以同步1500条/秒,基本满足业务需求。同时在性能不明显下降的情况下,如果需进一步扩展,可采用分布集
式布署,吞吐量将成倍的增长。
参考文献:
[1](澳)赖利.Java网络编程与分布式计算,机械工业出版社,2003:64-150
[2]许骏.面向服务的网格计算—新型分布式计算休憩系与中间件,科学出版社,2009:86-312
[3]林昊.分布式Java应用:基础与实践,电子工业出版社,2010:57-84

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。