• 分布式锁可选项


    CAP理论:
        Consistency,一致性:多个操作同时生效,不会出现部分生效的情况
        Availability,可用性:客户端的每个请求在服务端能够正确被响应
        Partition tolerance,分区容错性:分区中部分节点挂了不会影响整体服务可用性
                                        分区容错性是一个分布式系统最基本的要求,因此一般分布式系统都会满足分区容错性
    分布式系统一般会在C(一致性)和A(可用性)上做出取舍

    例:
    server-01 (update i = 1) => server-02 通信网络故障时,user请求获取server-02 的i ,由于数据未同步,什么办呢?
    1、牺牲一致性,响应旧的i 给user
    2、牺牲可用性,阻塞等待 直到网络回复,数据更新完,在响应给user
    AP:放弃了强一致性
    CP:放弃了可用性,影响用户体验。
    一般情况下,都需要牺牲强一致性来换取系统的高可用性。
    牺牲掉系统的'强一致性',最终是一致的,既'弱一致性'或'最终一致性',服务延迟或down机整个系统不可用,也是强一致性的表现。

    为了保证数据的最终一致性,需要很多的技术方案来支持,比如分布式事务、分布式锁等

    分布式锁一般有三种实现方式:
    一、数据库锁
         数据库中创建一个method_lock表 method_name做唯一约束,然后通过操作该表中的数据来实现了
         要锁住某个方法或资源时,我们就在该表中增加一条记录,想要释放锁的时候就删除这条记录
         基于数据库锁的缺点:
            1.1、基于数据库 影响可用性和性能,需要双机部署 数据同步 主备切换,同时依赖数据库一些资源开销等
            1.2、不可重入
            1.3、没有锁失效机制:如 insert成功 down机了 对应数据没有删除,服务恢复后一致获取不到锁
            1.4、不具备阻塞锁特性

    二、Redis的分布式锁
           基于缓存来实现、可以集群部署
           使用setnx加锁,并使用expire命令为锁添加一个超时时间,超过该时间自动释放锁

    三、基于ZooKeeper的分布式锁
           基于zookeeper临时有序节点可以实现的分布式锁 (对应的方法临时有序结点)
           每个客户端对某个方法加锁时,在zookeeper上的与该方法对应的指定节点的目录下,生成一个唯一的瞬时有序节点。
    判断是否获取锁的方式很简单,只需要判断有序节点中序号最小的一个。
    当释放锁的时候,只需将这个瞬时节点删除即可。
           同时,可以避免服务宕机导致的锁无法释放,而产生的死锁问题。
          具备高可用、可重入、阻塞锁特性、可解决失效死锁问题,因为需要频繁的创建和删除节点,性能上不如Redis方式


    相对于CAP理论:BASE是对CAP中一致性和可用性权衡的结果
    BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)

    群交流(262200309)
  • 相关阅读:
    【SQL】CASE与DECODE
    【SQL】通过rowid查找及删除重复记录
    【SQL】联合语句
    【PLSQL】游标
    【SQL】IN、EXISTS和表连接三者的效率比较
    【SQL】CONNECT BY 层次化查询
    【SQL】MERGE
    【SQL】多表查询
    【Python算法】遍历(Traversal)、深度优先(DFS)、广度优先(BFS)
    【Python算法】归纳、递归、归简
  • 原文地址:https://www.cnblogs.com/webster1/p/12346315.html
Copyright © 2020-2023  润新知