基于数据库实现分布式锁 基于数据库的实现方式的核心思想是：在数据库中创建一个表，表中包含方法名等字段，并在方法名字段上创建唯一索引，想要执行某个方法，就使用这个方法名向表中插入数据，成功插入则获取锁，执行完成后删除对应的行数据释放锁。...
PHP+zookeeper实现分布式锁 1、redis分布式锁，其实需要自己不断去尝试获取锁，比较消耗性能；zk分布式锁，获取不到锁，注册个监听器即可，不需要不断主动尝试获取锁，性能开销较小2、如果是redis获取锁的那个客户端bug了或者挂了，那么只能等待超时时间之后才能释放锁；而zk的话，因为创建的是临时znode，只要客户端挂了，znode就没了，此时就自动释放锁。...
PHP+Redis实现分布式锁 分布式锁实现的注意点：1）互斥: 任意时刻, 只能有一个客户端获得锁2）不会死锁: 客户端持有锁期间崩溃, 没有主动解除锁, 能保证后续的其他客户端获得锁3）锁归属标识: 加锁和解锁的必须是同一个客户端, 客户端不能解掉非自己持有的锁(锁应具备标识)4）如果是Redis集群, 还得考虑具有容错性:只要大部分Redis节点正常运行, 客户端就可以加锁和解锁....
分布式锁介绍 由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的应用并不能提供分布式锁的能力。为了解决这个问题就需要一种跨机器的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题...
分布式事务2PC和3PC原理 两阶段提交又称2PC，2PC是一个非常经典的强一致、中心化的原子提交协议。这里所说的中心化是指协议中有两类节点：一个是中心化协调者节点（coordinator）和N个参与者节点（partcipant）。两个阶段：第一阶段：投票阶段 和第二阶段：提交/执行阶段。...
分布式事务解决方案之可靠消息最终一致性 可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息， 事务参与方(消息消费者)一定能够接收消息并处理事务成功 ，此方案强调的是只要消息发给事务参与方最终事务要达到一致。...
分布式事务解决方案之2PC XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。...
分布式事务介绍 分布式系统会把一个应用系统拆分为可独立部署的多个服务，因此需要服务与服务之间远程协作才能完成事务操作，这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务 ，例如用户注册送积分事务、创建订单减库存事务，银行转账事务等都是分布式事务。......
kafka消息丢失解决方案 生产阶段: 在这个阶段，从消息在 Producer 创建出来，经过网络传输发送到 Broker 端。存储阶段: 在这个阶段，消息在 Broker 端存储，如果是集群，消息会在这个阶段被复制到其他的副本上。消费阶段: 在这个阶段，Consumer 从 Broker 上拉取消息，经过网络传输发送到 Consumer 上。...
kafka消息重复消费解决方案 Kafka消费者以消费者组(Consumer Group)的形式消费一个topic，发布到topic中的每个记录将传递到每个订阅的消费者组中的一个消费者实例。Consumer Group 之间彼此独立，互不影响，它们能够订阅相同的一组主题而互不干涉。......
消息队列：消息积压如何处理？ 在使用消息队列遇到的问题中，消息积压这个问题，应该是最常遇到的问题了，并且，这个问题 还不太好解决。我们都知道，消息积压的直接原因，一定是系统中的某个部分出现了性能问题，来不及处理上游发送的消 息，才会导致消息积压。...
消息队列：重复消息如何处理？ 在消息传递过程中，如果出现传递失败的情况，发送方会执行重试，重试的过程中就有可能会产生重复的消息。对使用消息队列的业务系统来说，如果没有对重复消息进行处理，就有可能会导致系统的数据出现错误。...
消息队列：如何确保消息不会丢失 使用消息队列最常遇到的问题，也是最头痛的问题就是丢消息了。对于大部分业务系统来说，丢消息意味着数据丢失，是完全无法接受的。其实，现在主流的消息队列产品都提供了非常完善的消息可靠性保证机制，完全可以做到在消息传递过程中，即使发生网络中断或者硬件故障，也能确保消息的可靠传递，不丢消息。绝大部分丢消息的原因都是由于开发者不熟悉消息队列，没有正确使用和配置消息队列导致的。虽然不同的消息队列提供的 API 不一样，相关的配置项也不同，但是在保证消息可靠传递这块儿，它们的实现原理是一样的。...
关注
