• Sword DB主从一致性的解决方法



    起源
    现在基本所有的程序中都会用到数据库,而数据库其实就是对所有业务逻辑处理结果的保存,所以不论在什么情况下数据的丢失都不被允许的,最坏的情况也要最小化数据的丢失程度,所以一般情况下,数据源都会至少配有两个节点,一个业务处理使用的节点,一个甚至多个从节点,这些从节点就是我们常说的冷备,业务处理节点(主节点)和备份节点一定的时间间隔内进行数据同步,从而来保证当一个数据源坏掉之后,数据也不会丢失,或着丢失很少(主要看同步的时间间隔)。但是为了提高资源的使用效率,所以有人就提出了,可不可以让冷备也被利用起来,替主节点分担部分压力,所以就提出了读写分离的方案。

    读写分离

    读写分离提高了资源的利用效率的同时也引出了一个问题,就是由于延时(网络传输,操作)而引起的数据库主从不一致的问题,对于这个问题,给一下集中解决方案。

    1-半同步复制
    主从不一致的原因是延时引起的,所以要消除这个延时的影响,可以从主库进行CUD操作时进行规避,办法就是等主从同步完成之后,主库上的写请求再返回,就是大家常说的“半同步复制”semi-sync。

    请求请求主库主库从库从库CUD操作开始同步同步完成CUD操作完成
    方案优点:利用数据库原生功能,比较简单
    方案缺点:主库的写请求时延会增长,吞吐量会降低

    2-缓存记录写key法
    CUD操作
    (1)将某个库上的某个key要发生写操作,记录在cache里,并设置“经验主从同步时间”的cache超时时间,例如500ms
    (2)修改数据库

    R操作
    (1)先到cache里查看,对应库的对应key有没有相关数据
    (2)如果cache hit,有相关数据,说明这个key上刚发生过写操作,此时需要将请求路由到主库读最新的数据
    (3)如果cache miss,说明这个key上近期没有发生过写操作,此时将请求路由到从库,继续读写分离

    方案优点:相对数据库中间件,成本较低
    方案缺点:方案缺点:为了保证“一致性”,引入了一个cache组件,并且读写数据库时都多了一步cache操作

  • 相关阅读:
    20165306 Exp4 恶意代码分析
    20165306 Exp3 免杀原理与实践
    20165306 Exp2 后门原理与实践
    20165306 Exp1 PC平台逆向破解
    20165306 Exp0 Kali安装 Week1
    2018-2019-2 网络对抗技术 20165216 Exp9 Web安全基础
    2018-2019-2 网络对抗技术 20165216 Exp8 WEB基础
    2018-2019-2 网络对抗技术 20165216 Exp7 网络欺诈防范
    2018-2019-2 网络对抗技术 20165216 Exp6 Exp6 信息搜集与漏洞扫描
    2018-2019-2 网络对抗技术 20165216 Exp5 MSF基础应用
  • 原文地址:https://www.cnblogs.com/zhanggaofeng/p/12129197.html
Copyright © 2020-2023  润新知